Какую задержку между событием и откликом на него вы считаете приемлемой?
Несмотря на ультрамощное железо некоторые современные приложения на electron или какая-нибудь IDE, могут легко дать задержку с полсекунды на всплывание какого-нибудь автокомплита! Это совершенно неприемлемо, не потому что полсекунды — это как полвечности, а потому что таких событий у опытного разработчика во время работы с кодом могут происходить десятки на полминуты. И если отклик на рядовое событие будет длиться полсекунды, или даже 300-400мс — это замедлит работу в несколько раз (компьютер не поспевает за ходом мысли/рефлексами пишущего код), не говоря уже об общей раздражительности от дискомфорта использования таких решений, когда начинаешь ощущать, что тебе нужно ждать.
Если у вас всё хорошо с 10 fingers typing, у вас развиты рефлексы работы в вашем окружении, то такие задержки сразу начинают ощущаться и доставлять дискомфорт, чем их меньше, тем лучше, желательно чтобы любой отклик на действие укладывался в 100мс.
Да. Копипаста в отдельное место. Одно неверное движение в вашем однострочнике или опечатка — и вы, матерясь, будете воспроизводить всю последовательность действий с начала, начиная с выделения (я в курсе про историю ex команд и ключ /c, это не сильно помогает).
Я искренне округляю глаза, когда читаю это. Ну ладно, отвечу в виде шутки.
… и вы, матерясь, будете воспроизводить всю последовательность действий с начала, начиная с выделения...
Допустим опечатался я в однострочке, и о ужас, я вдыхаю полную грудь воздуха и нажимаю ugv, вернул всё как было и даже выделение вернул, ну всё, я весь взмок, суставы ломятся от перенапряжения, в глазах темнеет, пойду прилягу, и на всякий случай вызову доктора, а пока доктор мчит, смерю давление, материться и сил никаких не осталось, 3 кнопки нажать последовательно — это не какой-то там уголь из шахты тащить. Но вот я отлежался, силы вернулись ко мне, перетягиваю на себе пояс, чтобы вернуться к команде из истории, фух, жму ":↑", уже сползая со стола от изнеможения успеваю нажать Ctrl+f, всё; несите ручку и салфетку, пока не поздно написать завещание!
Для набора в десяток строк — да, именно так. Сравните это долбление со сложностью набора вашего /s/-выражения (как по количеству символов, так и по частоте покидания home row, а также по ментальному усилию). Плюс в моём способе будет визуальное подтверждение прогресса (ок, решается ключом /c в вашем способе).
Усилий едва ли больше, зато когда мне это понадобится во второй и третий раз, — мне не придётся весь этот монотонный нонсенс с рычагом и виноградом повторять снова и снова.
И я не понимаю какое-такое визуальное подтверждение будет в вашем способе, которого не будет в моём? Чем ваш !sort (хотя вы наверное имели в виду просто sort, или точнее sort i, т.к. нужна регистро-независимость, встроенный в Vim, иначе чем это вообще отличается от моего варианта в плане наглядности?) более наглядно, чем мой вариант с командой (вызов внешней команды не может не заменить выделение, как бы между-прочим)?
А про home row открою сокровенную тайну за семью печатями, Vim можно конфигурировать, вот пара строчек из моего конфига:
" moving between history in command mode
cno <C-p> <Up>
cno <C-n> <Down>
Этого уже достаточно чтобы не покидать home row. Но у лично у меня ситуация ещё интереснее, т.к. я несколько лет уже использую собственную софтверную прослойку для клавиатуры, которая позволяет мне нажимать стрелки и всякого рода home/end/pgup/pgdown/delete/etc. не покидая home row.
Предлагаю ознакомиться с лэйаутом ниже:
Но даже более того, с некоторого времени я обзавёлся эргономичной клавиатурой, на которой кроме как home row ничего другого и нет (хотя ещё раньше я пользовался 60% клавиатурами, к которым это также применимо). Предлагаю также ознакомиться с кастомным лэйаутом на уровне прошивки клавиатуры. В общем поинт с покиданием home row тут по целому ряду причин — попадание мимо, стреляя из пушки в упор.
А ссылаюсь на "стрелку вверх" я исключительно для понятности остальным, как в стандартном конфиге, мой конфиг же, очень далёк от стандартного.
И как же вы быстро узнаете N в середине файла с 3-4 значными номерами строк (как мы помним, вы против перебрасывания набора строк в отдельный буфер)?
Я же даже подсказку в скобках оставил, которую вы же и процитировали! Включите se rnu и посмотрите на экран, или :h rnu наберите и почитайте про стандартную и древнюю как мир фичу Vim-а. На всякий случай отмечу, то N — это N раз, а не N номер строки.
В идеальном мире, где запятые образуют ровный visual block
Я привёл конкретный случайный пример из жизни, где это так, и мы обсуждаем проблему и её решение именно в этом контексте. Когда то, с чем нужно иметь дело, выглядит иначе — это уже другое решение (невероятно, но это потребует лишнего ментального усилия, и доблить j.j.j.j.j. уже не получится).
Нет, я до такого идиотизма не дохожу, но и ваш способ не лучший (по соотношению сложность/стабильность).
Со стабильностью как-раз всё отлично, автоматизированно, повторяемо, переиспользуемо, корректируемо, полагаемся на хладнокровный код, а не на human factor.
Я бы склеил все строки в одну через J (да, опять долбёжкой, мне нужно визуальное подтверждение и я не знаю численного префикса)
Численного префикса не знаете как раз потому, что не знаете об se rnu.
и затем выполнил бы s/, /, \n/g.
Вот! Наконец прозрение! Я сам хотел привести в пример автозамену, но что-то забыл. А теперь внимание! Вернёмся к тому "сложному и дремучему" что я понаписал, а написал я 2-3 таких реплейса (синтаксис sed идентичен по сути vim-у) + sort -f (он же sort i в VimL), при этом вот это всё доблить j.j.j.j.j. исчезает.
Но я против и другой крайности, когда в жертву уменьшению кол-ва нажатий клавиш приносится вообще всё, в частности простота процесса и устойчивость к ошибкам.
Про простоту процесса я уже говорил, это потом всё легко повторяется из истории, я один раз такое пишу, а потом из истории переиспользую десятки раз. Это как раз-таки и упрощает всё, а не наоборот.
А вот про устойчивость к ошибкам — это совершенно мимо, наоборот, это именно что и устойчиво к ошибкам, в первую очередь к ошибкам ЧФ.
P.S. Для пущего веселья, вот как выглядел оригинальный пример, который я укоротил и дополнил модулями с капсом в имени, чтобы нагляднее продемонстрировать регистро-независимость:
X11
, base
, containers
, data-default
, data-maybe-preserve
, dbus
, deepseq
, directory
, extra
, lens
, linux-evdev
, mtl
, process
, qm-interpolated-string
, safe
, stm
, template-haskell
, text
, time
, transformers
, type-operators
, unix
Молю вас, запишите на камеру, как вы обдолбите этот список с помощью j., я буду показывать это в качестве эталонного образца "как не надо пользоваться Vim-ом".
P.P.S. У меня нет цели высмеять лично вас, обидеть кого-то, или что-то в этом духе, надеюсь вы тоже отнесётесь к этому с юмором.
Для меня нет ничего сложного. И если достаточно практиковаться делать такие вещи, то это делается на легке, к тому же навык пригодится и за пределами Vim-а. Никакой крутизны (однострочник к тому же предельно простой, тот который на баше, тут и выделываться нечем), решение рутинных задач, автоматизированно, не полагаясь на собственную несовершенную внимательность.
vap (или чем вы там выделяете диапазоны) ---> копипаста в отдельное место --->встать на первую строчку с запятой ---> dw ---> долбим j.j.j.j.j.j.<…> ---> выделяем ---> !sort
"Копипаста в отдельное место"? "долбим j.j.j.j.j.j."? Да я себя макакой-резусом почувтсвую сразу, которую за виноград научили дёргать за рычаг. И вы предлагаете делать это каждый раз, как я добавлю новый пакет в список зависимостей? Я учился пользоваться Vim-ом не для того, чтоб как рядовой пользователь какой-нибудь IDE, монотонно клацать по стрелочкам и руками повторять одинаковые секвенсы N times in a row, или мышкой прицеливаться "стрелять" по кнопкам. Я хотел быть эффективным, а это входит в прямое противоречие с "долбим j.j.j.j.j.j." Это пример "как не надо пользоваться Vim-ом".
В конце-концов можно макрос записать и сделать N@x (где N кол-во строк se rnu в помощь). Можно нажать Ctrl-V+l для блочного выделения в 2 столбца с запятыми, потом Njx чтобы выделить все запятые и удалить их. Далее gv:sort! i<cr> и gvojI,. Как-то так. Но "долбим j.j.j.j.j.j." — это просто комично, простите. Да и вы в своём примере забыли запятые вернуть на место. Наверное должно выглядеть как i, <esc> и "долбим" hj.hj.hj.hj.hj.
По части интеграций, есть частные решения, не универсальные, для отдельных языков, есть разные реализации LSP (см. ALE, LanguageClient-neovim), в roadmap Neovim-а включена встроенная реализация LSP. Есть всякие GUI для Neovim, которые сразу поставляются с интеграцией под javascript, напр. veonim.
Лёгкость использования какой-либо сторонней программы или баш скрипта, по отношению к куску кода в IDE ощутимо сложнее (я если честно не видел чего-то, кроме make-скриптов, что очень далеко от того, что можно делать в Vim), чем нажатие одной клавиши (!) в Vim, чтобы этим кто-то часто и по любому поводу стал пользоваться. Будет гораздо лучше если покажите пример как в какой-нибудь IDE можно выполнить вот этот скрипт по отношению к выделенным строкам в коде:
sed 's/[, ] \([^, ]\)/\1/' | sort -f | sed -e '1s/\w/ &/' -e '2,$s/\w/, &/'
Расписав последовательность действий/нажатий клавиш, или, прости Дарвин, прицеливаний и кликов мышью.
Иногда бывает и не с первого раза, особенно если задача условно новая, но с опытом приходит хорошее понимание того, что ты пишешь (ну или просто набирается достаточное количество рабочих паттернов) и получается с первого раза как надо.
Засорение истории для меня никогда не было такой проблемой, т.к. самая правильная команда — последняя и найдётся первой. Я же не ищу сразу по всей истории просто перебирая, я набираю пару первых символов, и это уже сильно сокращает выборку по поиску, и в подавляющем большинстве случаев по этим пару символам плюс стрелка вверх сразу даёт нужный вариант. А если прямо реально что-то нужно где-то отыскать, жмётся Ctrl+f и / и дальше дело за малым (в моём конфиге вообще есть хоткей <leader>; который открывает FZF по истории команд, что делает это непозволительно лёгким), но я пользуюсь им крайне редко, т.к. обычно способ описанный выше сразу приводит к желаемому результату.
А касательно переключения контекстов, то лично я не испытываю на этом какого-либо существенного ментального проседания. Наверное всё-таки тут опыт играет роль, и когда это делать легко, то ощутимого смещения внимания не происходит.
Проблем со вспоминанием того, что команды делают я тоже не помню чтобы испытывал. Я могу их прочитать и понять что они делают. Но вообще как правило по визуальному образу я вспоминаю сразу зачем эта команда писалась. В конце-концов для меня нет проблемы взять и написать заново, если я не могу отыскать в истории, я мой поинт также в том, что хорошо бы практиковаться время от времени, чтобы мочь в любой момент написать такой кусок заново на ходу и не дорожить историей команд как сокровищем.
По поводу "графичности", у Neovim есть различные GUI, например есть такой с поддержкой лигатур в шрифтах.
Есть и всякие экзотические проекты вроде onivim, которые сильно изменяют привычный облик vim, делая его более похожим на какой-нибудь sublime или atom, предоставляя различные не-текстовые элементы интерфейса.
Полный список доступных GUI для Neovim можно найти тут.
Это очень индивидуально, также сильно зависит от предыдущего бэкграунда.
Для начала нужно освоить базу, пройти какой-нибудь vimtutor, пройти VIM Adventures. Начать работать в Vim сначала "по-тупому", но время от времени добавлять к своим навыкам что-то новое, можно найти какой-нибудь ресурс, который раз в день постит новый хоткей или описание фичи, и как этим пользоваться. Выписывать интересное на бумажку и стараться сразу начать употреблять.
Считаю также для эффективности крайне полезным сразу освоить слепую 10-и пальцевую печать, для этого полно онлайн-ресурсов. Vim как никакой другой редактор для этого очень приспособлен прямо "из коробки".
Смысл не в том чтобы сразу загрузить в себя большой массив знаний, навыков, умений. А в том, чтобы начать с чего-то, и постепенно улучшать этот навык, расширять понимание и кругозор в плане фич, возможностей, способов сделать что-то.
Вообще могу от себя дать хороший совет: наблюдать за тем, как ты работаешь в Vim, если ты чувствуешь что повторяешь что-то рутинно, шаблонно, по 10 раз одну последовательность действий, — значит самое время подумать или поискать в интернете или на форумах, как это можно автоматизировать или упростить.
Когда я пишу бекенд на NodeJS, он сам собой как-то получается в функциональной парадигме.
Мне доводилось видеть некоторое дерьмо, когда бекенд писали на, простите за ругательство, недостойное приличного человека, — "NodeJS". В этом контексте данное предложение невольно вызывает судорожный смех.
Можно "форспушнуть", у приличных людей такая практика считается моветоном, Линус Торвальдс за такое сечёт розгами ярко-выраженного социального неодобрения.
Так что, возможно, лет через 5–7 мы закончим с производствами и пойдём к вам домой. Для безопасности. Это в ваших же интересах, гражданин!
Так точно! Сити 17 — лучший город на земле!
Не зря ведутся дискуссии на тему того, как жить без GPS-маячка в виде GSM-связи и без оплаты по банковским картам. Мы слишком долго жуём сопли, скоро думать будет поздно и большой брат будет проникать в каждый дом, а закончится это всё почитанием великого и солнцеликого утром, в обед и за ужином.
Какую задержку между событием и откликом на него вы считаете приемлемой?
Несмотря на ультрамощное железо некоторые современные приложения на electron или какая-нибудь IDE, могут легко дать задержку с полсекунды на всплывание какого-нибудь автокомплита! Это совершенно неприемлемо, не потому что полсекунды — это как полвечности, а потому что таких событий у опытного разработчика во время работы с кодом могут происходить десятки на полминуты. И если отклик на рядовое событие будет длиться полсекунды, или даже 300-400мс — это замедлит работу в несколько раз (компьютер не поспевает за ходом мысли/рефлексами пишущего код), не говоря уже об общей раздражительности от дискомфорта использования таких решений, когда начинаешь ощущать, что тебе нужно ждать.
Если у вас всё хорошо с 10 fingers typing, у вас развиты рефлексы работы в вашем окружении, то такие задержки сразу начинают ощущаться и доставлять дискомфорт, чем их меньше, тем лучше, желательно чтобы любой отклик на действие укладывался в 100мс.
А почему для Raku указана бесконечность? Не дождались финиша бенчмарка?
Реквестирую вариант с Tcl.
Я искренне округляю глаза, когда читаю это. Ну ладно, отвечу в виде шутки.
Допустим опечатался я в однострочке, и о ужас, я вдыхаю полную грудь воздуха и нажимаю
ugv, вернул всё как было и даже выделение вернул, ну всё, я весь взмок, суставы ломятся от перенапряжения, в глазах темнеет, пойду прилягу, и на всякий случай вызову доктора, а пока доктор мчит, смерю давление, материться и сил никаких не осталось, 3 кнопки нажать последовательно — это не какой-то там уголь из шахты тащить. Но вот я отлежался, силы вернулись ко мне, перетягиваю на себе пояс, чтобы вернуться к команде из истории, фух, жму ":↑", уже сползая со стола от изнеможения успеваю нажатьCtrl+f, всё; несите ручку и салфетку, пока не поздно написать завещание!Усилий едва ли больше, зато когда мне это понадобится во второй и третий раз, — мне не придётся весь этот монотонный нонсенс с рычагом и виноградом повторять снова и снова.
И я не понимаю какое-такое визуальное подтверждение будет в вашем способе, которого не будет в моём? Чем ваш
!sort(хотя вы наверное имели в виду простоsort, или точнееsort i, т.к. нужна регистро-независимость, встроенный в Vim, иначе чем это вообще отличается от моего варианта в плане наглядности?) более наглядно, чем мой вариант с командой (вызов внешней команды не может не заменить выделение, как бы между-прочим)?А про home row открою сокровенную тайну за семью печатями, Vim можно конфигурировать, вот пара строчек из моего конфига:
Этого уже достаточно чтобы не покидать home row. Но у лично у меня ситуация ещё интереснее, т.к. я несколько лет уже использую собственную софтверную прослойку для клавиатуры, которая позволяет мне нажимать стрелки и всякого рода home/end/pgup/pgdown/delete/etc. не покидая home row.
Предлагаю ознакомиться с лэйаутом ниже:
Но даже более того, с некоторого времени я обзавёлся эргономичной клавиатурой, на которой кроме как home row ничего другого и нет (хотя ещё раньше я пользовался 60% клавиатурами, к которым это также применимо). Предлагаю также ознакомиться с кастомным лэйаутом на уровне прошивки клавиатуры. В общем поинт с покиданием home row тут по целому ряду причин — попадание мимо, стреляя из пушки в упор.
А ссылаюсь на "стрелку вверх" я исключительно для понятности остальным, как в стандартном конфиге, мой конфиг же, очень далёк от стандартного.
Я же даже подсказку в скобках оставил, которую вы же и процитировали! Включите
se rnuи посмотрите на экран, или:h rnuнаберите и почитайте про стандартную и древнюю как мир фичу Vim-а. На всякий случай отмечу, то N — это N раз, а не N номер строки.Я привёл конкретный случайный пример из жизни, где это так, и мы обсуждаем проблему и её решение именно в этом контексте. Когда то, с чем нужно иметь дело, выглядит иначе — это уже другое решение (невероятно, но это потребует лишнего ментального усилия, и доблить
j.j.j.j.j.уже не получится).Со стабильностью как-раз всё отлично, автоматизированно, повторяемо, переиспользуемо, корректируемо, полагаемся на хладнокровный код, а не на human factor.
Численного префикса не знаете как раз потому, что не знаете об
se rnu.Вот! Наконец прозрение! Я сам хотел привести в пример автозамену, но что-то забыл. А теперь внимание! Вернёмся к тому "сложному и дремучему" что я понаписал, а написал я 2-3 таких реплейса (синтаксис sed идентичен по сути vim-у) +
sort -f(он жеsort iв VimL), при этом вот это всё доблитьj.j.j.j.j.исчезает.Про простоту процесса я уже говорил, это потом всё легко повторяется из истории, я один раз такое пишу, а потом из истории переиспользую десятки раз. Это как раз-таки и упрощает всё, а не наоборот.
А вот про устойчивость к ошибкам — это совершенно мимо, наоборот, это именно что и устойчиво к ошибкам, в первую очередь к ошибкам ЧФ.
P.S. Для пущего веселья, вот как выглядел оригинальный пример, который я укоротил и дополнил модулями с капсом в имени, чтобы нагляднее продемонстрировать регистро-независимость:
Молю вас, запишите на камеру, как вы обдолбите этот список с помощью
j., я буду показывать это в качестве эталонного образца "как не надо пользоваться Vim-ом".P.P.S. У меня нет цели высмеять лично вас, обидеть кого-то, или что-то в этом духе, надеюсь вы тоже отнесётесь к этому с юмором.
[Удалено] пост не в ту ветку...
Для меня нет ничего сложного. И если достаточно практиковаться делать такие вещи, то это делается на легке, к тому же навык пригодится и за пределами Vim-а. Никакой крутизны (однострочник к тому же предельно простой, тот который на баше, тут и выделываться нечем), решение рутинных задач, автоматизированно, не полагаясь на собственную несовершенную внимательность.
"Копипаста в отдельное место"? "долбим j.j.j.j.j.j."? Да я себя макакой-резусом почувтсвую сразу, которую за виноград научили дёргать за рычаг. И вы предлагаете делать это каждый раз, как я добавлю новый пакет в список зависимостей? Я учился пользоваться Vim-ом не для того, чтоб как рядовой пользователь какой-нибудь IDE, монотонно клацать по стрелочкам и руками повторять одинаковые секвенсы N times in a row, или мышкой прицеливаться "стрелять" по кнопкам. Я хотел быть эффективным, а это входит в прямое противоречие с "долбим j.j.j.j.j.j." Это пример "как не надо пользоваться Vim-ом".
В конце-концов можно макрос записать и сделать N@x (где N кол-во строк
se rnuв помощь). Можно нажатьCtrl-V+lдля блочного выделения в 2 столбца с запятыми, потомNjxчтобы выделить все запятые и удалить их. Далееgv:sort! i<cr>иgvojI,. Как-то так. Но "долбим j.j.j.j.j.j." — это просто комично, простите. Да и вы в своём примере забыли запятые вернуть на место. Наверное должно выглядеть какi, <esc>и "долбим"hj.hj.hj.hj.hj.Про LSP см. соседний комментарий.
По части интеграций, есть частные решения, не универсальные, для отдельных языков, есть разные реализации LSP (см. ALE, LanguageClient-neovim), в roadmap Neovim-а включена встроенная реализация LSP. Есть всякие GUI для Neovim, которые сразу поставляются с интеграцией под javascript, напр. veonim.
Лёгкость использования какой-либо сторонней программы или баш скрипта, по отношению к куску кода в IDE ощутимо сложнее (я если честно не видел чего-то, кроме make-скриптов, что очень далеко от того, что можно делать в Vim), чем нажатие одной клавиши (
!) в Vim, чтобы этим кто-то часто и по любому поводу стал пользоваться. Будет гораздо лучше если покажите пример как в какой-нибудь IDE можно выполнить вот этот скрипт по отношению к выделенным строкам в коде:Расписав последовательность действий/нажатий клавиш, или, прости Дарвин, прицеливаний и кликов мышью.
Иногда бывает и не с первого раза, особенно если задача условно новая, но с опытом приходит хорошее понимание того, что ты пишешь (ну или просто набирается достаточное количество рабочих паттернов) и получается с первого раза как надо.
Засорение истории для меня никогда не было такой проблемой, т.к. самая правильная команда — последняя и найдётся первой. Я же не ищу сразу по всей истории просто перебирая, я набираю пару первых символов, и это уже сильно сокращает выборку по поиску, и в подавляющем большинстве случаев по этим пару символам плюс стрелка вверх сразу даёт нужный вариант. А если прямо реально что-то нужно где-то отыскать, жмётся
Ctrl+fи/и дальше дело за малым (в моём конфиге вообще есть хоткей<leader>;который открывает FZF по истории команд, что делает это непозволительно лёгким), но я пользуюсь им крайне редко, т.к. обычно способ описанный выше сразу приводит к желаемому результату.А касательно переключения контекстов, то лично я не испытываю на этом какого-либо существенного ментального проседания. Наверное всё-таки тут опыт играет роль, и когда это делать легко, то ощутимого смещения внимания не происходит.
Проблем со вспоминанием того, что команды делают я тоже не помню чтобы испытывал. Я могу их прочитать и понять что они делают. Но вообще как правило по визуальному образу я вспоминаю сразу зачем эта команда писалась. В конце-концов для меня нет проблемы взять и написать заново, если я не могу отыскать в истории, я мой поинт также в том, что хорошо бы практиковаться время от времени, чтобы мочь в любой момент написать такой кусок заново на ходу и не дорожить историей команд как сокровищем.
По поводу "графичности", у Neovim есть различные GUI, например есть такой с поддержкой лигатур в шрифтах.
Есть и всякие экзотические проекты вроде onivim, которые сильно изменяют привычный облик vim, делая его более похожим на какой-нибудь sublime или atom, предоставляя различные не-текстовые элементы интерфейса.
Полный список доступных GUI для Neovim можно найти тут.
Это очень индивидуально, также сильно зависит от предыдущего бэкграунда.
Для начала нужно освоить базу, пройти какой-нибудь vimtutor, пройти VIM Adventures. Начать работать в Vim сначала "по-тупому", но время от времени добавлять к своим навыкам что-то новое, можно найти какой-нибудь ресурс, который раз в день постит новый хоткей или описание фичи, и как этим пользоваться. Выписывать интересное на бумажку и стараться сразу начать употреблять.
Считаю также для эффективности крайне полезным сразу освоить слепую 10-и пальцевую печать, для этого полно онлайн-ресурсов. Vim как никакой другой редактор для этого очень приспособлен прямо "из коробки".
Смысл не в том чтобы сразу загрузить в себя большой массив знаний, навыков, умений. А в том, чтобы начать с чего-то, и постепенно улучшать этот навык, расширять понимание и кругозор в плане фич, возможностей, способов сделать что-то.
Вообще могу от себя дать хороший совет: наблюдать за тем, как ты работаешь в Vim, если ты чувствуешь что повторяешь что-то рутинно, шаблонно, по 10 раз одну последовательность действий, — значит самое время подумать или поискать в интернете или на форумах, как это можно автоматизировать или упростить.
Ну так это смотря в каком байте. Не любой байт октет.
Это оскорбительно по отношению к автору, полагать что он всё это всерьёз.
Legacy & Copy-Paste
Логично, прямо как vertical/horizontal split в tmux.
Мне доводилось видеть некоторое дерьмо, когда бекенд писали на, простите за ругательство, недостойное приличного человека, — "NodeJS". В этом контексте данное предложение невольно вызывает судорожный смех.
Можно "форспушнуть", у приличных людей такая практика считается моветоном, Линус Торвальдс за такое сечёт розгами ярко-выраженного социального неодобрения.
недавно работал, есть практика сваливать самый условно-полезный или просто интересный код в публичные репозитории с целью не потерять его со временем.
Так точно! Сити 17 — лучший город на земле!
Не зря ведутся дискуссии на тему того, как жить без GPS-маячка в виде GSM-связи и без оплаты по банковским картам. Мы слишком долго жуём сопли, скоро думать будет поздно и большой брат будет проникать в каждый дом, а закончится это всё почитанием великого и солнцеликого утром, в обед и за ужином.