Если бы в статье говорилось, что программистам платят за то, что они каждый день осознают какой большой вес имеют архитектура и планирование, я бы не имел возражений.
А насчёт стандартного подхода — так если почитать статьи менеджеров, то это не просто стандартный подход — это вообще идеал, к которому надо стремиться.
Количество публикаций, посвящённых тому, что надо решать задачи быстро и качественно просто зашкаливает.
Однако, если посмотреть внимательнее, авторы таких статей обычно хотят, чтобы программист сделал грубый хак за полчаса, поклялся, что он ничего не сломал и перешёл к следующей задаче. Если хак что-то сломал — виноват очевидно программист, а не тот, кто требует «быстро и качественно».
Чему можно научиться, решая такие задачи каждый день?
После того, как пишешь git add -p, появляется окошко с редактором, в котором виден текущий чанк. И, если он слишком большой, есть возможность разбить текущий чанк на чанки поменьше. Если чанк представляет из себя очень длинную строку, можно будет разбить его на части?
Кто-то заметил проблему длинных строк, она решабельна, но тогда скорее всего сломается git diff, поэтому пока что советую в редакторе, в котором вы редактируете маркдаун включить перенос строк.
Я создал ишью в оригинальном репе по этому поводу. Надеюсь автор что-нибудь с этим сделает.
Кстати, почему на Хабре до сих пор нет маркдауна? Местная разметка — убогий отстой. OMG, Emoji тут тоже не поддерживаются
Пятьдесят раз да! Тысячу раз да! Вы, кстати, как статьи пишете? Я пишу в маркдауне, потом конвертирую в html, вставляю в хабраредактор и правлю.
Напомню, что md файл представляет из себя исходник, который потом преобразуется в нужный формат. В процессе преобразования строки склеиваются и в зависимости от целевого формата определённым образом подгоняются вод ширину экрана. Поэтому читать строки в виде грустных столбиков никому не придётся.
Кроме того, напомню, что системы контроля версий (по крайней мере git) считают изменения в файле построчно и при изменении одного символа в строке изменённой будет считаться вся строка. Смотреть изменения, сделанные в коммите, как unified diff становится очень неудобно. Исключать изменения, которые делать не нужно — тоже.
Markdown это не обычный текст, это исходник, с которым предполагается работать с помощью системы контроля версий. Это многое меняет.
Есть некоторая разница между «не мешает» и «вынуждает». Кроме того, git add -p как делать в таком случае? Слать лесом часть git workflow из-за ничем не мотивированного наличия длинных строк?
Самое страшное, что может случиться из-за этого — это придётся 15-20 секунд потратить на ручное слияние одновременных исправлений от двух разных людей в одном блоке.
Да щас :). Если поправить 2 — 3 опечатке в строке и отправить пулл реквест автору, то просмотрщик диффов покажет только, что строка именена. Целиком. И дальше играем в игру — найди неизвестно сколько отличий в двух почти идентичных строках длиной с бассейн Амазонки и засеки сколько времени это займёт. Никак не 15 — 20 секунд :).
Огромное спасибо за статью, форкнул репозиторий, нашёл неточности перевода, сделаю pull request.
А теперь немного чистой, незамутнённой ненависти!
В оригинальном тексте, как и во всех переводах, строки длиной по несколько метров!
Если бы там был какой-нибудь plain text это можно было бы не простить, но хотя бы понять. Ну то есть автор хотел, чтобы ширина строки адаптировалась к ширине окна. Но там же маркдаун. Который при просмотре строки склеивает! Специально созданный в том числе для этого!
Какого лешего! Как вышло так, что автор, рассказывающий об искусстве владения командной строкой отформатировал текст так, что при исправлении опечатки в одном слове, гит считает изменённым весь абзац целиком? Файл, внутри которого содержится рекомендация изучить и использовать vim, нельзя нормально редактировать с помощью этого текстового редактора, это как? Такого тонкого глумежа я не видал уже давно!
Нельзя смонтировать fsa. Именно поэтому гугл отвечает, что смонтировать fsa нельзя. То, что предлагаете вы правильнее было бы поместить под заголовок «Как посмотреть содержимое fsa». Но я, когда погуглил, наткнулся на эту ссылку ubuntuforums.org/showthread.php?t=1381103. Вроде как раз примерно то же, что у вас.
А про умников, которые знают и не пишут — поддерживаю. Не умников, а вас, конечно. Простые и известные вещи надо повторять почаще.
Ну у меня сейчас запуск тестов. Просто, чтобы убедиться, что не сломал чего случайно. Тут либо планировщиком его регулярно запускать, либо асинхронным вызовом консольной команды из vim. Я выбрал второе, но думал, может какие ещё варианты есть.
А насчёт стандартного подхода — так если почитать статьи менеджеров, то это не просто стандартный подход — это вообще идеал, к которому надо стремиться.
Однако, если посмотреть внимательнее, авторы таких статей обычно хотят, чтобы программист сделал грубый хак за полчаса, поклялся, что он ничего не сломал и перешёл к следующей задаче. Если хак что-то сломал — виноват очевидно программист, а не тот, кто требует «быстро и качественно».
Чему можно научиться, решая такие задачи каждый день?
А вот те, кто платит — они вот говорят, что платят за решение конкретных задач.
Спасибо за color-words кстати. Я про него был не в курсе.
После того, как пишешь git add -p, появляется окошко с редактором, в котором виден текущий чанк. И, если он слишком большой, есть возможность разбить текущий чанк на чанки поменьше. Если чанк представляет из себя очень длинную строку, можно будет разбить его на части?
Я создал ишью в оригинальном репе по этому поводу. Надеюсь автор что-нибудь с этим сделает.
Пятьдесят раз да! Тысячу раз да! Вы, кстати, как статьи пишете? Я пишу в маркдауне, потом конвертирую в html, вставляю в хабраредактор и правлю.
Кроме того, напомню, что системы контроля версий (по крайней мере git) считают изменения в файле построчно и при изменении одного символа в строке изменённой будет считаться вся строка. Смотреть изменения, сделанные в коммите, как unified diff становится очень неудобно. Исключать изменения, которые делать не нужно — тоже.
Markdown это не обычный текст, это исходник, с которым предполагается работать с помощью системы контроля версий. Это многое меняет.
Да щас :). Если поправить 2 — 3 опечатке в строке и отправить пулл реквест автору, то просмотрщик диффов покажет только, что строка именена. Целиком. И дальше играем в игру — найди неизвестно сколько отличий в двух почти идентичных строках длиной с бассейн Амазонки и засеки сколько времени это займёт. Никак не 15 — 20 секунд :).
Вот как раз линк на такой пулл реквест. github.com/olegberman/the-art-of-command-line/pull/3/files?diff=split. И это, кстати, исправления от одного человека. О разруливании конфликтов речи пока не идёт.
А теперь немного чистой, незамутнённой ненависти!
В оригинальном тексте, как и во всех переводах, строки длиной по несколько метров!
Если бы там был какой-нибудь plain text это можно было бы не простить, но хотя бы понять. Ну то есть автор хотел, чтобы ширина строки адаптировалась к ширине окна. Но там же маркдаун. Который при просмотре строки склеивает! Специально созданный в том числе для этого!
Какого лешего! Как вышло так, что автор, рассказывающий об искусстве владения командной строкой отформатировал текст так, что при исправлении опечатки в одном слове, гит считает изменённым весь абзац целиком? Файл, внутри которого содержится рекомендация изучить и использовать vim, нельзя нормально редактировать с помощью этого текстового редактора, это как? Такого тонкого глумежа я не видал уже давно!
А про умников, которые знают и не пишут — поддерживаю. Не умников, а вас, конечно. Простые и известные вещи надо повторять почаще.