Использую Prettier почти три года и могу сказать, что у него есть свои плюсы и минусы, как и у любого другого инструмента.
Порой Prettier совсем невнятно форматирует код или форматирование может зависеть от любопытных хаков. Например год назад я предложил вот такой https://github.com/prettier/prettier/issues/1974#issuecomment-385277713, правда теперь он уже не нужен, так как по итогам обсуждения обновили правила форматирования и теперь оно такое, какое я и хотел, по-дефолту))). Не всегда изменения, сделанные им, удобно просматривать в diff-ах.
Но в то же время, даже если не использовать Prettier как основной форматтер, он довольно удобен для форматирования вспомогательных файлов. Markdown, JSON, Yaml, вот это вот все. Я на проектах использую его вместе с ESLint и вполне доволен. Кстати ESLint еще может определять и частично исправлять всякие дурацкие ошибки, поэтому в плане чистоты кода пользы от него намного больше. Prettier предназначен исключительно для форматирования кода, и хотя его и пытаются иногда притянуть на проект в качестве линтера, это неправильно. Но вместе они позволяют на ревью обсуждать действительно важные вещи: что и как этот код делает, а не всякую фигню, вроде отсутствия/наличия пробелов в каких-то конструкциях.
Так что Prettier вполне успешно можно использовать в качестве форматтера поверх линтеров, а также для файлов, для которых линтер не особо нужен, а вот форматирование было бы выдерживать неплохо. При этом на проекте будет стайлгайд "prettier-like". Если Prettier чем-то не понравился (например ньюансами как в https://habr.com/ru/company/skyeng/blog/484992/#comment_21186642), помимо него есть еще куча "zero config" решений: xo, Lynt например. Можно тот же ESLint использовать и для форматирования с каким-нибудь популярным готовым набором правил, от airbnb например. Какой бы инструмент не был бы выбран, на хуки гита его можно повесить с одинаковым успехом и он так же перед коммитом поправит форматирование кода. Стайлгайд только будет немного отличаться. Но что останется неизменным — так это то, что стиль кода внутри проекта будет одинаковым. Чего собственно и добивались, и это экономит силы и нервы людей на проекте. Удачного code review!
Если речь только об установке конкретной системы, то возможно. Но скелетон не дает возможности контроля "абсолютно всех" параметров системы (хотя можно при пересборке дистра выпилить лишнее/добавить нужное). Не дает возможности что-то поменять "постфактум", добавив что-то новое и корректно откатив лишнее. То есть у меня задачи объединяют и настройку после установки и обновление конфигурации (возможно разных вариантов конфигурации). Кроме того, Ansible дает плюс в универсальности использования. Все это впрочем не отменяет того, что /etc/skel может оставаться маленькой частью конфигурации, чтобы при создании пользователя у него нужные настройки применялись штатно. Спасибо за идею, для меня одного работа с разными пользователями не слишком актуальна, но админов на работе думаю заинтересует.
Безотносительно дистрибутива можно еще и настройку автоматизировать, с помощью Ansible например. Для Ubuntu я недавно вынес некоторые настройки в https://github.com/shimarulin/workstation-config, по большей части потому, что мне лень настраивать руками что-то при необходимости смены диска/компа. Это конечно не уровень "юзерфрендли GUI", но для конечного пользователя не сложно. Запустил команду и пошел на обед, пока рождается клон твоего десктопа. Для Arch/Manjaro/etc то же самое можно сделать, что разницу в настройке нивелирует до нуля, было бы кому заниматься. Буду на арче — и под него для себя сделаю.
Полностью согласен. Вопросы, представленные выше, не решают задач собеседования от слова "совсем". За условный час, отведенный на собес, сложно узнать о человеке достаточное количество информации. Собеседование — это стресс, для обоих сторон. Кандидат может не знать какой-то детали или просто ее забыть. Но при этом может быть отличным разработчиком, подкованным "в целом". Поэтому стараюсь подходить к собесу примерно так: давайте расслабимся, мы расскажем, что мы тут делаем, ты, если тебе все еще будет интересно, расскажешь, что ты умеешь, делаешь и что можешь предложить. Потом попробуем что-нибудь поделать, а затем выпьем чай/кофе при желании, подумаем и зададим друг другу вопросы, которые возникнут. Однажды мы так разговаривали с кандидатом и я понял, что мне больше нет смысла задавать вопросы, которые он предугадывает, а я предугадываю его ответ) И вот сейчас я думаю, если бы я начал с каких-нибудь дурацких вопросов, какого бы классного коллегу я бы потерял...
Любопытно, что когда я в детстве мечтал о появлении электромобилей, я предполагал, что они будут не только экономичнее, но и дешевле обычных автомобилей как по стоимости, так и в обслуживании. Не, ну правда, с одной стороны ДВС со всем обвесом для поддержания своей работы и сложная трансмиссия, а с другой — моторчик на колесо и батарейка. Кто же знал, что еще и за ПО для управления этим будут цену заламывать)
К сожалению, судя по тому, как двигаются некоторые автомобили на дороге, на текущий момент ими управляет интеллект намного слабее существующих алгоритмов ИИ)
Очень сложно сравнивать разный интеллект в целом, но в определенном контексте задач все может сводиться к относительно "простым" требованиям: способность к распознаванию и анализу, способность выбирать из списка возможных альтернатив, способность при принятии решения учитывать вероятности ошибок распознавания и анализа, скорость обработки информации. Но не бывает двух одинаковых ситуаций, необходим механизм адаптации, "творчества", чтобы в нестандартной ситуации, учитывая доступные показатели, физику, геометрию и предыдущий опыт, все же попытаться избежать ДТП. Добавим к этому "социальную" составляющую ИИ: непрерывный обмен информацией о дорожно-транспортной обстановке между отдельными представителями ИИ, об использованных вариантах и результатах разрешения отдельных ситуаций. Если добиться успеха по всем пунктам, то получим практически идеальных водителей. В распознавании и адаптации человеческий интеллект пока в основном превосходит интеллект машины. В ряде других требований он никогда не сможет сравниться с машинным интеллектом. В основном сейчас решаются проблемы обработки нестандартных ситуаций на дороге, но ведь можно их решать и иначе: например, устранить причину их возникновения — человека. Однако проблема любого ИИ, подключенного к сети, в том, что даже если он будет идеален и для него будут подобраны идеальные условия — его все же можно взломать) Ну или взломать систему, которой он управляет.
Я кажется понял) Вы используете Boost Note вместо Boostnote ))) Один разработчик, практически идентичные названия, но это — разные приложения. У Boostnote нет браузерной версии (хотя ее можно запросто получить из исходников). Boost Note похоже пишется полностью с нуля, но на основе опыта с Boostnote. Бегло просмотрел — все другое, что-то лучше, что-то хуже. Поддержку flowchart видимо не завезли пока
В просмотре flowchart рендерится нормально. В примере по ссылке есть ошибка — экранируются символы обратных апострофов. Надо заменить \`\`\` на ``` в начале и в конце блока
Для активных пользователей Vim выглядит очень удачным решением. У меня один из коллег примерно так же использует vim-notes, а еще в последнее время что-то мутил с fzf и вот этой штукой https://github.com/Alok/notational-fzf-vim
Фишка Sparkle Share в том, что под капотом он может использовать обычные репозитории Git, только коммитит в них в автоматическом режиме. Я прямым текстом написал, что использую Git. Спросите: а почему бы не вручную коммитить? Для заметок особого смысла в этом нет, это не код. Любое сохранение файла — повод для коммита. Вместо Sparkle Share можно было бы с тем же успехом использовать inotify напрямую, только настраивать дольше. Как бы то ни было, результатом я доволен. Я люблю программы, которые экономят время людей и упрощают их работу, в конце концов именно для этого я их и пишу.
Я не знаю, в курсе или нет автор поста "современных инструментов", но рискну предположить, что блокнот ему необходим для решения его задач, известных лишь ему, и оценочные суждения, пожалуй, тут будут неуместны. Инструменты от JetBrains действительно хороши, особенно когда их используешь по назначению — для написания кода. Редактирование Markdown разметки в них осуществляется через встроенный плагин, но это — не самая основная функция IDE, да и рендер предпросмотра не всегда может дать представление о том, как текст будет выглядеть в действительности. Если хочется чуть больше удобства — есть сторонний плагин Markdown Navigator, полный фарш доступен за символические $16 в год.
Что касается Ctrl+L (вероятно речь о Ctrl+Alt+L, судя по моим IDE и официальной справке, но мало ли у кого как шорткаты "под себя" настроены, а может от системы зависит), то могу только сказать, что пользуюсь встроенным форматтером только в уникальных случаях, например баш-скрипт какой-нибудь отформатировать иной раз. Не потому, что он плох, а потому что ребята в команде вольны использовать что угодно, кое-кто вообще на Vim сидит, и ничего, менее крутым разработчиком от этого не стал. Но при этом хотят единые стайлгайды по коду. И их есть у меня — для командной работы, и не только, умные люди придумали всякие *lint: ESLint, Pylint, которые не привязаны к редактору и внезапно еще и код отформатируют единообразно. Желательно вообще без участия человека, есть же хуки. Не хочется заморачиваться с настройкой — Prettier в помощь.
И вот для всего этого "markdown блокноты" не нужны, потому что у них свой спектр применения (например заметки по технологиям для себя набросать, заготовку статьи, да что угодно). Кому-то Word удобнее может, кто-то Google Notes и Google Docs использует для этого, дело вкуса. Markdown тут выигрывает исключительно благодаря своим возможностям экспорта-импорта и форматирования. Хотя кто-то может просто не слышал про Markdown-редакторы, не все же "сильно в курсе современных инструментов" ;) Но может им это просто и не надо?)
В Typora я обычно редактирую документацию, иногда заметки накидываю прямо там же, просто потому что редактор открыт и надо записать «прямо сейчас», пока мысль не ушла и чтобы не отвлекаться от основного процесса. Потом копирую в Boostnote, если заметка стоящая.
Попробуйте Typora, у него довольно удобное редактирование, но он заточен на работу с отдельными файлами/каталогами. Если нужен «блокнот», в котором помимо редактирования хранятся все записи, то возможно хорошей альтернативой будет Boost Note, это обновленная версия Boostnote. Я пока на новую версию не переходил, но надеюсь там ничего не сломали). Синхронизирую заметки через гит с помощью Sparkle Share — довольно удобно, даже когда работаю на одном компе — это же бесконечный undo/redo) Как-то удалил вроде неважную заметку, а она потом понадобилась — восстановил, ничего не пропало
Не совсем так, вы видимо немного запутались. Я на заводе получал в 6 раз больше, чем на первой своей работе в IT, потому что был специалистом высшей категории по своей основной профессии и был близок к этому в смежных. А вот зарплата грузчика была всего лишь в 1.2 раза выше, чем на той первой работе в IT. Уровень ЗП в той конторе вполне объясним — аутсорс маленькой московской конторы в регионы за копейки на грани прожиточного минимума. Хотя, например, в Нижнем Новгороде в то время были и самостоятельные студии, которые платили сотрудникам такие же копейки. Зато написали в трудовой, что я — программист. Мне это нужно было, так как без этого не получалось в те годы в нормальную компанию попасть, а вот почему там остальные работали — хороший вопрос.
Я нигде и не утверждаю, что мои успехи — исключительно моя заслуга. Вовсе нет, наоборот, я хотел перечислить как можно больше людей, которые послужили мне примером и помогли мне. Это не обязательно должны быть родственники. И увы, я перечислил далеко не всех.
У других бывает так, что не поддерживает вообще никто… Но может, порой мы просто не хотим замечать эту поддержку, потому что она не всегда бывает такой, какую мы ожидаем? Почему хороших людей так много было в моей жизни и так мало в других? Чем я так уникален? Да ничем, вот прямо скажем, совсем.
Но любая поддержка будет бесполезна, если человек просто ничего не хочет. Ну или хочет, но прямо здесь и сейчас и не желает работать на долгосрочную перспективу. Не хочет пожертвовать своим уютом, чтобы двигаться дальше. У меня есть несколько примеров, когда одни ребята все просадили и бросили, а другие справились с трудностями и двинулись дальше в абсолютно таких же условиях.
А то, что поддержки не было, может просто о ней не пишут?
Использую Prettier почти три года и могу сказать, что у него есть свои плюсы и минусы, как и у любого другого инструмента.
Порой Prettier совсем невнятно форматирует код или форматирование может зависеть от любопытных хаков. Например год назад я предложил вот такой https://github.com/prettier/prettier/issues/1974#issuecomment-385277713, правда теперь он уже не нужен, так как по итогам обсуждения обновили правила форматирования и теперь оно такое, какое я и хотел, по-дефолту))). Не всегда изменения, сделанные им, удобно просматривать в diff-ах.
Но в то же время, даже если не использовать Prettier как основной форматтер, он довольно удобен для форматирования вспомогательных файлов. Markdown, JSON, Yaml, вот это вот все. Я на проектах использую его вместе с ESLint и вполне доволен. Кстати ESLint еще может определять и частично исправлять всякие дурацкие ошибки, поэтому в плане чистоты кода пользы от него намного больше. Prettier предназначен исключительно для форматирования кода, и хотя его и пытаются иногда притянуть на проект в качестве линтера, это неправильно. Но вместе они позволяют на ревью обсуждать действительно важные вещи: что и как этот код делает, а не всякую фигню, вроде отсутствия/наличия пробелов в каких-то конструкциях.
Так что Prettier вполне успешно можно использовать в качестве форматтера поверх линтеров, а также для файлов, для которых линтер не особо нужен, а вот форматирование было бы выдерживать неплохо. При этом на проекте будет стайлгайд "prettier-like". Если Prettier чем-то не понравился (например ньюансами как в https://habr.com/ru/company/skyeng/blog/484992/#comment_21186642), помимо него есть еще куча "zero config" решений: xo, Lynt например. Можно тот же ESLint использовать и для форматирования с каким-нибудь популярным готовым набором правил, от airbnb например. Какой бы инструмент не был бы выбран, на хуки гита его можно повесить с одинаковым успехом и он так же перед коммитом поправит форматирование кода. Стайлгайд только будет немного отличаться. Но что останется неизменным — так это то, что стиль кода внутри проекта будет одинаковым. Чего собственно и добивались, и это экономит силы и нервы людей на проекте. Удачного code review!
Если речь только об установке конкретной системы, то возможно. Но скелетон не дает возможности контроля "абсолютно всех" параметров системы (хотя можно при пересборке дистра выпилить лишнее/добавить нужное). Не дает возможности что-то поменять "постфактум", добавив что-то новое и корректно откатив лишнее. То есть у меня задачи объединяют и настройку после установки и обновление конфигурации (возможно разных вариантов конфигурации). Кроме того, Ansible дает плюс в универсальности использования. Все это впрочем не отменяет того, что /etc/skel может оставаться маленькой частью конфигурации, чтобы при создании пользователя у него нужные настройки применялись штатно. Спасибо за идею, для меня одного работа с разными пользователями не слишком актуальна, но админов на работе думаю заинтересует.
Безотносительно дистрибутива можно еще и настройку автоматизировать, с помощью Ansible например. Для Ubuntu я недавно вынес некоторые настройки в https://github.com/shimarulin/workstation-config, по большей части потому, что мне лень настраивать руками что-то при необходимости смены диска/компа. Это конечно не уровень "юзерфрендли GUI", но для конечного пользователя не сложно. Запустил команду и пошел на обед, пока рождается клон твоего десктопа. Для Arch/Manjaro/etc то же самое можно сделать, что разницу в настройке нивелирует до нуля, было бы кому заниматься. Буду на арче — и под него для себя сделаю.
Полностью согласен. Вопросы, представленные выше, не решают задач собеседования от слова "совсем". За условный час, отведенный на собес, сложно узнать о человеке достаточное количество информации. Собеседование — это стресс, для обоих сторон. Кандидат может не знать какой-то детали или просто ее забыть. Но при этом может быть отличным разработчиком, подкованным "в целом". Поэтому стараюсь подходить к собесу примерно так: давайте расслабимся, мы расскажем, что мы тут делаем, ты, если тебе все еще будет интересно, расскажешь, что ты умеешь, делаешь и что можешь предложить. Потом попробуем что-нибудь поделать, а затем выпьем чай/кофе при желании, подумаем и зададим друг другу вопросы, которые возникнут. Однажды мы так разговаривали с кандидатом и я понял, что мне больше нет смысла задавать вопросы, которые он предугадывает, а я предугадываю его ответ) И вот сейчас я думаю, если бы я начал с каких-нибудь дурацких вопросов, какого бы классного коллегу я бы потерял...
Любопытно, что когда я в детстве мечтал о появлении электромобилей, я предполагал, что они будут не только экономичнее, но и дешевле обычных автомобилей как по стоимости, так и в обслуживании. Не, ну правда, с одной стороны ДВС со всем обвесом для поддержания своей работы и сложная трансмиссия, а с другой — моторчик на колесо и батарейка. Кто же знал, что еще и за ПО для управления этим будут цену заламывать)
К сожалению, судя по тому, как двигаются некоторые автомобили на дороге, на текущий момент ими управляет интеллект намного слабее существующих алгоритмов ИИ)
Очень сложно сравнивать разный интеллект в целом, но в определенном контексте задач все может сводиться к относительно "простым" требованиям: способность к распознаванию и анализу, способность выбирать из списка возможных альтернатив, способность при принятии решения учитывать вероятности ошибок распознавания и анализа, скорость обработки информации. Но не бывает двух одинаковых ситуаций, необходим механизм адаптации, "творчества", чтобы в нестандартной ситуации, учитывая доступные показатели, физику, геометрию и предыдущий опыт, все же попытаться избежать ДТП. Добавим к этому "социальную" составляющую ИИ: непрерывный обмен информацией о дорожно-транспортной обстановке между отдельными представителями ИИ, об использованных вариантах и результатах разрешения отдельных ситуаций. Если добиться успеха по всем пунктам, то получим практически идеальных водителей. В распознавании и адаптации человеческий интеллект пока в основном превосходит интеллект машины. В ряде других требований он никогда не сможет сравниться с машинным интеллектом. В основном сейчас решаются проблемы обработки нестандартных ситуаций на дороге, но ведь можно их решать и иначе: например, устранить причину их возникновения — человека. Однако проблема любого ИИ, подключенного к сети, в том, что даже если он будет идеален и для него будут подобраны идеальные условия — его все же можно взломать) Ну или взломать систему, которой он управляет.
Я кажется понял) Вы используете Boost Note вместо Boostnote ))) Один разработчик, практически идентичные названия, но это — разные приложения. У Boostnote нет браузерной версии (хотя ее можно запросто получить из исходников). Boost Note похоже пишется полностью с нуля, но на основе опыта с Boostnote. Бегло просмотрел — все другое, что-то лучше, что-то хуже. Поддержку flowchart видимо не завезли пока
В общем для меня есть смысл оставаться на старом Boostnote. 10 дней назад был очередной релиз, что говорит о его активной поддержке. Установить можно из официальных пакетов https://github.com/BoostIO/boost-releases/releases/tag/v0.14.0
Конечно, когда-нибудь (и возможно скоро) эта версия умрет, но такова жизнь)
Для активных пользователей Vim выглядит очень удачным решением. У меня один из коллег примерно так же использует vim-notes, а еще в последнее время что-то мутил с fzf и вот этой штукой https://github.com/Alok/notational-fzf-vim
вот в этой ветке есть ответ) https://habr.com/ru/post/482186/#comment_21070618
Фишка Sparkle Share в том, что под капотом он может использовать обычные репозитории Git, только коммитит в них в автоматическом режиме. Я прямым текстом написал, что использую Git. Спросите: а почему бы не вручную коммитить? Для заметок особого смысла в этом нет, это не код. Любое сохранение файла — повод для коммита. Вместо Sparkle Share можно было бы с тем же успехом использовать inotify напрямую, только настраивать дольше. Как бы то ни было, результатом я доволен. Я люблю программы, которые экономят время людей и упрощают их работу, в конце концов именно для этого я их и пишу.
Я не знаю, в курсе или нет автор поста "современных инструментов", но рискну предположить, что блокнот ему необходим для решения его задач, известных лишь ему, и оценочные суждения, пожалуй, тут будут неуместны. Инструменты от JetBrains действительно хороши, особенно когда их используешь по назначению — для написания кода. Редактирование Markdown разметки в них осуществляется через встроенный плагин, но это — не самая основная функция IDE, да и рендер предпросмотра не всегда может дать представление о том, как текст будет выглядеть в действительности. Если хочется чуть больше удобства — есть сторонний плагин Markdown Navigator, полный фарш доступен за символические $16 в год.
Что касается
Ctrl+L(вероятно речь оCtrl+Alt+L, судя по моим IDE и официальной справке, но мало ли у кого как шорткаты "под себя" настроены, а может от системы зависит), то могу только сказать, что пользуюсь встроенным форматтером только в уникальных случаях, например баш-скрипт какой-нибудь отформатировать иной раз. Не потому, что он плох, а потому что ребята в команде вольны использовать что угодно, кое-кто вообще на Vim сидит, и ничего, менее крутым разработчиком от этого не стал. Но при этом хотят единые стайлгайды по коду. И их есть у меня — для командной работы, и не только, умные люди придумали всякие *lint: ESLint, Pylint, которые не привязаны к редактору и внезапно еще и код отформатируют единообразно. Желательно вообще без участия человека, есть же хуки. Не хочется заморачиваться с настройкой — Prettier в помощь.И вот для всего этого "markdown блокноты" не нужны, потому что у них свой спектр применения (например заметки по технологиям для себя набросать, заготовку статьи, да что угодно). Кому-то Word удобнее может, кто-то Google Notes и Google Docs использует для этого, дело вкуса. Markdown тут выигрывает исключительно благодаря своим возможностям экспорта-импорта и форматирования. Хотя кто-то может просто не слышал про Markdown-редакторы, не все же "сильно в курсе современных инструментов" ;) Но может им это просто и не надо?)
У других бывает так, что не поддерживает вообще никто… Но может, порой мы просто не хотим замечать эту поддержку, потому что она не всегда бывает такой, какую мы ожидаем? Почему хороших людей так много было в моей жизни и так мало в других? Чем я так уникален? Да ничем, вот прямо скажем, совсем.
Но любая поддержка будет бесполезна, если человек просто ничего не хочет. Ну или хочет, но прямо здесь и сейчас и не желает работать на долгосрочную перспективу. Не хочет пожертвовать своим уютом, чтобы двигаться дальше. У меня есть несколько примеров, когда одни ребята все просадили и бросили, а другие справились с трудностями и двинулись дальше в абсолютно таких же условиях.
А то, что поддержки не было, может просто о ней не пишут?