Решил написать небольшой обзор по редактору Remarkable

Озадачился выбором markdown-редактора под Linux. После недолгих поисков с легким и приятным удивлением нашел две программы под эту операционную систему. Все течет, все меняется и вот теперь под Linux есть два достойных markdown-редактора.

Первый редактор - это Remarkable, второй редактор - это Haroopad. После недолгого сравнения обеих программ оставил в своей коллекции редактор Remarkable по нескольким причинам.

Обзор Remarkable

Чем мне понравился Remarkable? Это простая и интуитивно понятная программа, с таким же приятным и понятным интерфейсом. Что называется - установил и пользуйся.

Одна особенность этого редактора - на момент написания статьи существует только версия под Linux (преимущественно под Ubuntu).

После установки и запуска редактор будет иметь такой примерный вид:

Remarkable - markdown editor

Вверху видим панель инструментов, одного взгляда на которую достаточно, чтобы разобраться - что для чего предназначено.

Вставка, открытие и сохранение документа; иконки Undo и Redo; форматирование текста - Bold, Italic, Stroke; удобные кнопки для вставки на страницу изображения, ссылки или timestamp:

Remarkable - insert images and links

Окно редактора Remarkable разбито на две части - левая для редактирования, правая - для предпросмотра. Все как и должно быть в нормальном markdown-редакторе.

Предварительный просмотр можно отключить:

Remarkable - disable live preview

Есть также “ночной” режим работы:

Remarkable - night mode

Программа поддерживает синтаксис Github Flavoured Markdown:

Markdown Support

Markdown Support

На GitHub имеется подробный пример markdown-синтаксиса - Remarkable Demo, созданного в этом редакторе. Там есть что посмотреть и чему поучиться - своеобразная реклама редактора Remarkable.

Ниже приведен официальный демо-ролик, показывающий возможности редактора Remarkable:

Одна приятная и мощная особенность редактора - возможность экспортирования в HTML или PDF.

Remarkable автоматически подсчитывает число строк, слов и символов в тексте и отображает эту информацию в строке состояния.

Заключение

Мой субъективный вывод - программа Remarkable является отличным выбором markdown-редактора под Linux. Простая, удобная, интуитивно понятная.

В качестве редактора для ежедневной работы контент-менеджера - лучший выбор под операционной системой Linux. Все самое нужное - под рукой и ничего лишнего. Стоит ли упоминать, что данная статья написана в редакторе Remarkable.

На этом все.


Продолжаю изучение темы Git и GitHub. На повестке дня стоит вопрос - каким образом можно изменить ссылку существующего репозитория?

Нет - не так! Попробую зайти с другой стороны и сказать иначе. Имеется готовый репозиторий Template, размещенный на сервере GitHub. Этот репозиторий является шаблоном (template starter) при создании разнообразных проектов. Нечто похожим на известный HTML5 Boilerplate.

Репозиторий Template клонируется на локальную машину с именем разрабатываемого проекта, такой командой:

$ git clone https://github.com/gearmobile/template.git project

Затем в созданном репозитории Project разрабатывается требуемый проект.

Но есть одно НО - необходимо преобразовать видоизмененный репозиторий Project в отдельный, самостоятельный репозиторий. Конечно, по большому счету, это уже и есть отдельный, самостоятельный репозиторий.

Но вот ссылка у репозитория Project указывает на оригинал - репозиторий Template. И если произвести push на GitHub, то произойдет обновление репозитория Template.

А этого крайне нежелательно допустить, так как этот репозиторий является стартовым, чистым листом для всех новых проектов!

У меня же стоит такая задача - скопировать стартовый репозиторий Template на локальную машину, преобразовать его в конкретный проект, вновь залить на GitHub уже как самостоятельный репозиторий с именем проекта в качестве имени репозитория. Как поступить?

Можно решить вопрос несколькими способами. Ниже приведу пару из них - самых простых и доступных для моего понимания вечного newbie в Git\GitHub. Может быть, по мере освоения темы дополню статью более универсальным и грамотным способом.

Правка config

У клонированного на локальную машину репозитория ссылка на его удаленный оригинал размещена в конфигурационном файле config по пути .git/config, в секции [remote “origin”], в переменной с именем url:

$ cat .git/config

[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
  ignorecase = true
  precomposeunicode = true

[remote "origin"]
  url = https://github.com/gearmobile/template.git
  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
  remote = origin
  merge = refs/heads/master

Поэтому в локальном репозитории Project можно просто изменить эту ссылку с помощью любого текстового редактора.

Отредактирую файл config и изменю в нем ссылку с:

https://github.com/gearmobile/template.git

… на:

https://github.com/gearmobile/project.git

… где последняя - это ссылка на новый пустой репозиторий Project, который я создал на GitHub.

Теперь конфигурационный файл config для локального репозитория Project будет выглядеть таким образом (обратить внимание на переменную url):

$ cat .git/config

[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
  ignorecase = true
  precomposeunicode = true

[remote "origin"]
  url = https://github.com/gearmobile/project.git
  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
  remote = origin
  merge = refs/heads/master

Все - теперь локальный репозиторий Project является абсолютно самостоятельным и уникальным репозиторием, связанным ссылкой со своей удаленной копией на сервере GitHub.

Осталось только сделать push, чтобы залить на GitHub. Правда, здесь придется воспользоваться ключом -f (как это описано в предыдущей статье Откат коммитов на GitHub):

$ git push -f

Команда set-url

Второй способ практически идентичен предыдущему за тем лишь исключением, что он более правильный, так как для изменения url-адреса репозитория используется предназначенная для этого консольная команда Git - set-url.

Точно также создаю на локальной машине копию Another Project удаленного репозитория Template:

$ git clone https://github.com/gearmobile/template.git another-project

Ссылка в новом репозитории Another-Project все также указывает на свой оригинал - репозиторий Template:

$ cat .git/config

[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
  ignorecase = true
  precomposeunicode = true

[remote "origin"]
  url = https://github.com/gearmobile/template.git
  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
  remote = origin
  merge = refs/heads/master

Создаю на GitHub новый репозиторий Another-Project, который будет удаленной копией локального (уже существующего) репозитория Another-Project. И изменяю ссылку на вновь созданный удаленный репозиторий Another-Project:

$ git remote set-url origin https://github.com/gearmobile/another-project.git

Проверяю, изменилась ли ссылка в конфигурационном файле config (переменная url):

$ cat .git/config

[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
  ignorecase = true
  precomposeunicode = true

[remote "origin"]
  url = https://github.com/gearmobile/another-project.git
  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
  remote = origin
  merge = refs/heads/master

Да, ссылка была успешно изменена на новый удаленный репозиторий Another-Project. Можно вносить изменения и выполнять push на GitHub.

Небольшое заключение

Преимущество двух описанных выше способ в том, что не теряется история коммитов.

На этом пока все.


Небольшая статья, посвященная вопросу отката коммитов в GitHub.

В чем заключается вопрос, собственно? В том, что имеется определенный репозиторий, размещенный на сервере GitHub. У этого удаленного репозитория есть локальная синхронизированная версия на рабочей машине автора. Этот репозиторий изменяется с большей или меньшей периодичностью; все изменения фиксируются соответствующими коммитами.

И вот в один прекрасный момент в репозиторий было внесено изменение, которое затем было закоммичено и отправлено на GitHub. Однако, от этого изменения нужно избавиться - оно ошибочное.

Но как это сделать, если коммит уже находится на GitHub? В интерфейсе сервиса GitHub я не нашел нужной кнопки, чтобы удалять конкретный коммит и тем самым возвращать репозиторий до нужного состояния.

Это потому, что управление коммитами на GitHub производится через локальный репозиторий. Ниже приведу три несложных шага для того, чтобы показать, каким образом это выполняется.

Шаг первый

Первое - необходимо получить список hash-сумм последних коммитов репозитория. Это и понятно - нужно иметь перед собой дерево коммитов, чтобы видеть - куда двигаться. В дереве коммитов hash-суммы являются опорными точками, идентификационными номерами каждого из коммитов:

$ git log

Ниже показан краткий вывод команды git log - четыре самых поздних коммита репозитория:

commit ee3a2ae6888fb87d5013786f6cf3b18da63f7bbb
Author: gearmobile <gearmobile@gmail.com>
Date:   Mon Apr 6 17:48:08 2015 +0300

    End

commit 6d92268e42eace0c78a5150144645333b769623d
Author: gearmobile <gearmobile@gmail.com>
Date:   Mon Apr 6 17:06:35 2015 +0400

    Close to end

commit 855404bf39b5fabd45ba0c6f5702e7a28949a02e
Author: gearmobile <gearmobile@gmail.com>
Date:   Mon Apr 6 15:24:04 2015 +0400

    End 2014-07-16

commit 3eb55145a79f9f8f732338a0e80bd71b2325b6da
Author: gearmobile <gearmobile@gmail.com>
Date:   Mon Apr 6 12:48:17 2015 +0400

    End

Мне нужно вернуть репозиторий из состояния, описанного в коммите ee3a2ae6888fb87d, в состояние, зафиксированное в коммите 6d92268e42eace0c.

Шаг второй

Для этого я воспользуюсь командой reset, с ключом –hard. Эта команда мне подходит потому, что я не собираюсь сохранять изменения, зафиксированные в коммите ee3a2ae6888fb87d, так как они полностью ошибочны.

Как подробно описывается в статье Отмена изменений в Git, такую задачу можно выполнить командой:

$ git reset --hard 6d92268e42eace0c

где 6d92268e42eace0c - начальные 16 символов hash-суммы коммита, на который я хочу “перепрыгнуть”. Полный вид hash-суммы в 40 символов можно не использовать - достаточно 16 символов для надежной идентификации конкретного коммита.

После выполнения этой команды локальный репозиторий будет сброшен к состоянию, зафиксированному в коммите 6d92268e42eace0c. Другими словами, я избавился от последних ошибочных изменений и вернул репозиторий в предыдущее его состояние.

Однако, это всего лишь половина дела, так как откат коснулся только локального репозитория. В этой статье речь идет прежде всего об удаленном репозитории, размещенном на GitHub. Как добиться внесения аналогичных изменений на GitHub?

Казалось бы - просто! Достаточно выполнить команду:

$ git push

Но, на самом деле это не получится сделать - Git не позволит это выполнить. По той причине, что на данный момент состояние локального репозитория имеет более раннюю версию, нежели состояние удаленного репозитория.

Вместо этого Git предложит выполнить комнаду git pull, чтобы привести локальный репозиторий к удаленному.

Шаг третий

Чтобы заставить Git выполнить обратную задачу - привести удаленный репозиторий к локальному, необходимо использовать ключ -f.

То есть, форсировать внесение изменений и тем самым “сказать” Git - синхронизировать удаленный репозиторий с локальным репозиторием несмотря на то, что последний имеет более ранюю версию:

$ git push -f

Заключение

Теперь, если проверить состояние удаленного репозитория на сервере GitHub, то увидим, что оно идентично состоянию локального репозитория. Но самое главное - удален последний ошибочный коммит, чего я и добивался.

На этом все.


Как оказалось, работа в программе EasyTAG - это нетривиальная задача. Интерфейс программы не является интуитивно понятным (по крайней мере - для меня).

У меня стояло несколько задач для обработки файлов аудио-книг:

  • одновременное редактирование тегов для нескольких mp3-файлов
  • добавление изображений к mp3-файлу
  • переименование mp3-файлов по их тегам

Во всех трех случаях мне пришлось заглядывать в справку F1 программы EasyTAG, чтобы разобраться с вопросами.

EasyTAG - редактирование нескольких mp3-файлов

Если стоит задача редактирования тегов для нескольких mp3-файлов одновременно (а такая задача возникает часто), для этого необходимо выполнить несложную последовательность действий.

  1. Выделить в окне EasyTAG все редактируемые mp3-файлы
  2. Изменить значение тега
  3. Нажать на значок “Ab” в поле тега

Редактирования нескольких файлов одновременно

  1. Сохранить внесенные изменения

EasyTAG - добавление изображения

Для добавления изображений (обложек) к аудио-файлам, нужно воспользоваться соответствующей вкладкой в панели редактирования тегов EasyTAG. Значок плюса добавляет изображение к файлу (можно добавить несколько изображений); но есть еще два значка, не столь очевидных.

Первый значок (шестренка) служит для открытия окна редактирования изображения (обложки) файла. Можно изменить заголовок изображения, а также его тип.

Второй значок служит для того, чтобы назначить изображение для всех выбранных mp3-файлов. Это аналог значка “Ab”, только для изображений.

Добавление изображения

EasyTAG - переименование mp3-файлов по тегам

Еще одна крайне важная и полезная функция, которая необходима в программе EasyTAG - это переименование mp3-файлов по значениям тега этого mp3-файла.

Другими словами, имеется mp3-файл такого (примерного) вида - 2013-04-02-Альфред-ван-Вогт-Зачарованная деревня.mp3. Это mp3-файл нужно переименовать в программе EasyTAG и привести к виду Альфред-ван-Вогт - Зачарованная деревня.mp3.

Программа EasyTAG обладает такой возможностью, вот только “добраться” (точнее - догадаться) до этой функции с первого раза не получиться. Ниже приведена последовательность действий для достижения этой цели.

  1. Выделить в окне EasyTAG все редактируемые mp3-файлы
  2. Нажать иконку “Show scanner”. Откроется окно “Tag and Filename Scan”, в котором в поле “Scanner” из выпадающего списка необходимо выбрать запись “Rename File and Directory”. Во втором поле окна размещен обширный список готовых масок для переименования файлов. Можно выбрать готовую маску, а можно создать свою - это очень просто сделать. Должно получиться нечто похожее на следующее:

Переименование файлов по тегам

  1. Нажать кнопку “Scan Files”, чтобы применить маску к ранее выбранным mp3-файлам.
  2. Закрыть окно “Tag and Filename Scan”, нажав кнопку “Close”.
  3. Сохранить внесенные изменения. При этом появиться окно с предупреждением о переименовании mp3-файла (-ов)

Подтверждение переименования файлов

В принципе, на это все.


Тема статьи - конвертация mp3-тегов, созданных в кодировке windows-1251, в кодировку utf-8, под управлением операционной системы Linux.

В чем проблема

Причина возникновения такого вопроса заключается в том, что я уже достаточно давно стал поклонником аудио-книг. И передачи “Модель для сборки” - в частности. И хотя сама передача уже давно закрыта, ее архивы в Интернете доступны для скачивания.

Дома у меня имеются только две операционные системы - Mac OS X 10.10 и Linux Mint 17 Cinnamon. И вот тут возникает небольшая проблема, связанная с тем, что Audacious под Linux и iTunes под Mac не отображают правильно мета-информацию проигрываемых mp3-файлов аудио-книг, если эти файлы созданы под Windows.

Другими словами, аудио-проигрыватель “читает” аудио-книгу, но вот понять визуально - какую, нельзя. Не видно названия книги, ее автора, имени чтеца. Происходит это потому, что оба вышеназванных проигрывателя не могут правильно отображать мета-данные mp3-файлов, если эти мета-данные созданы в кодировке windows-1251.

Как решить проблему

Решением вопроса является перекодировка мета-данных mp3-файлов, перевод символов из кодировки windows-1251 в кодировку utf-8, с которой умеют работать Audacious и iTunes.

Решение оказалось на удивление простое и “под рукой”. Популярный редактор mp3-тегов под Linux с названием EasyTAG в два счета справляется с задачей. Главное - нужно правильно настроить чтение mp3-тегов этой программой.

Последовательность действий по настройке EasyTAG

  1. Устанавливаем программу EasyTAG

  2. Переходим в настройки программы EasyTAG - “Edit - Preferences”

  3. К окне настроек программы EasyTAG переходим на вкладку “ID3 Tag Settings”

  4. Устанавливаем параметры программы EasyTAG так, как это показано на скриншоте:

Параметры программы EasyTAG

Если описать двумя словами, то необходимо для “ID3v1 tags” выбрать кодировку Windows-1251, для “ID3v1 tags” выбрать кодировку utf-8. Для поля “Character Set for reading ID3 tags” также выбрать кодировку windows-1251.

Конвертация в программе EasyTAG

Когда программа EasyTAG настроена, то процесс конвертации mp3-тегов из кодировки windows-1251 в кодировку utf-8 выполнить проще простого.

  1. Открываем в программе EasyTAG папку с коллекцией mp3-файлов, которые необходимо обработать (переконвертировать).

  2. Выделяем в окне программы EasyTAG все эти файлы.

  3. Сохраняем их.

Да, именно так - “открыл-сохранил”, ничего больше. И теперь Audacious вместе с iTunes прекрасно читают обработанные файлы музыки (и аудио-книг).

На этом все.