Мотивация: работа в консоли позволяет заметить свои рутинные операции и быстро их ускорить. Даже 10% меньшей рутины на длинной дистанции - это много. Многих останавливает проблема входа: как правило, люди поколения, не заставшего ZX Spectrum, начинают свой путь с архитепического “GUI-программиста”, привыкнув к конкретным практикам по принципу наименьшего сопротивления. Не понятно, с чего начать, если базовые операции занимают больше времени, а консоль представляется в виде километровых команд git bash винды. Непонятно даже, зачем начинать, ведь и так работа работается.
Поэтому вот список советов, банальных и не очень, как начать получать пользу от консоли. Целевая аудитория, наверное, начинающий ML и CV пипл, потому что какие-нибудь девопсы и без меня разберутся, со своими ansible и докерами.
Общий стиль работы
- Печать вслепую. Это лучшая и универсальная инвестиция в собственное образование после английского языка. Следует учитывать, что программист печатает не так, как типичный офисный работник. В ворде есть исправление орфографии и достаточно печатать быстро с приемлемым уровнем ошибок. Программисту умение находить быстро буквы сильно работу не ускорит. Ускоряет работу слепой поиск горячих клавиш и спецсимволов с безошибочным поиском букв. Это означает, что большая часть тренажеров и методов “для обычных людей” обучает не тому, что требуется. С моей субъективной точки зрения, десятипальцевый метод не нужен и ведет к проблемам из-за статичного положения рук, а лучше печатать медленнее, но уметь находить символ @ из любого положения рук, не приучая себя к тому, что это всегда безымянный палец, пока указательный лежит на клавише f с пупыркой.
- Стремиться нужно к тому, чтобы одно нажатие кнопки запускало все, что нужно, включая тесты, и выдавало их результаты для анализа и повторения цикла. Если после нажатия на кнопку сборки приходится делать десяток кликов мышки, чтобы посмотреть результат, тут что-то не то.
- Не должно пугать то, что попытка автоматизации этих десяти кликов мышки заняла в 10 раз больше времени. Навык делать это на автомате придет только если этим заниматься.
- Учиться следует на работе, в рабочее время. Если это не устраивает с этической точки зрения, не просите повышения, когда научитесь и станете эффективнее. Но только ставя себе вызов, реально чему-то научиться. Мозг ленив, и если чередовать плохие практики и хорошие, хорошие не будут заучиваться, и так и останутся в зачаточном состоянии. Выучить слепую печать занимает месяц страданий, но можно потратить на это дело несколько лет и суммарно больше энергии, и остаться в ситуации, когда смотреть на клавиатуру эффективнее. То же касается и освоения консоли, хотя не так беспощадно, потому что это более интеллектуальный процесс, чем научивание моторной коры.
- IDE, питоньи ноутбуки и отладчик хороши в определенной нише, но есть тендеция прикипать к ним и использовать их там, где они уже только замедляют разработку. Например, когда часами накликивается step-in/over вместо того, чтобы писать в файл подробный лог и проанализировать историю изменения величины. Или когда для запуска тренировки нейронки нужно кликнуть на десяток ячеек в ноутбуке в определенном порядке. Или когда запускают IDE для правки одного файла.
- Если после git clone проекта нужно два дня что-то настраивать, это нужно починить.
Файловая структура
- Об автодополнении нужно думать сразу. Не надо называть файлы с разным назначением близкими префиксами. В идеале, каждый файл должен автодополняться по буква[tab].
- Cтруктура, в которой много папок, а в них мало файлов - это для GUI, потому что в большом списке искать глазами неудобно. В консоли вполне можно работать, имея тысячу файлов в директории. Баланс для GUI и консоли находится где-то в районе “список еле влезает на экран”.
- Пути должны быть короткими.
- При совместной работе, когда структуру проекта поменять невозможно, можно создать симлинки.
Команды
Я просмотрел history и обнаружил, что команд использую не очень много. Основная работа заключается в правке файлов, а сложное поведение реализуется на питоне.
ls -ltr - список файлов, отсортированный по дате (мнемоника типа list time reverse). Самые релевантные внизуrsync - позволяет копировать файлы между машинами, копируя только те, которые изменились, при этом не тормозя на куче мелких файлов, в отличие от scp. scp, если кто не знает, это копирование файлов по ssh.sshfs user@server:/ localfolder превращает удаленную папку в локальную. Возможные сценарии использования: редактирование файлов на сервере на каналах с большой задержкой. Просмотр файлов, сгенерированных удаленно. Открытие локальным скриптом удаленных файлов для рисования всяческих графиков.ssh -t выполняет одну команду на сервере, например, ssh -t dmitry@server "ls". Естественно, нужно настроить доступ по ключам. Хорошо работает в паре с sshfs.nano - если его настроить и запомнить пяток экзотических сочетаний клавиш, он становится весьма неплохим редактором для мелких правок. Для меня это переход к началу и концу строки, поиск, поиск с заменой, копирование-вставка, отмена. Под настройкой я понимаю две строки в .nanorc: set tabsize 4 и set tabstospaces. Больше всего он себя раскрывает при работе через терминал на телефоне. Например, в дороге обнаружил, что обучение упало из-за глупой ошибки. Как пофиксить? Хорошо, если ноутбук с собой.tmux - позволяет создавать на удаленном сервере сессию, которая не закрывается при разлогине, с окошками, вкладками и чем угодноxdg-open - эмулятор открытия файла в файловом менеджере. Какое приложение по умолчанию в системе, то и откроется. Позволяет не помнить, а как называется просмотрщик картинок в убунте, например- imagemagick и ffmpeg - автоматизируют обработку мультимедиа (слово-то какое). Например, по запросу “ffmpeg video for twitter” находится следующее заклинание:
ffmpeg -i input.mp4 -vcodec libx264 -pix_fmt yuv420p -acodec aac output.mp4.