Мне кажется, вы меня не слышите. Действительно, vim дает возможность удобно редактировать текст. Но разница с современными редакторами (что IDE, что Atom/VSCode/...) незначительна.
Есть проекты в которых не принципиально наличие дополнительных функций из IDE. Например, сам не использовал IDE для Ruby on Rails проектов на несколько разработчиков на несколько лет: и объем кода небольшой, и динамические языки тяжело поддерживаются IDE (при этом был купленный RubyMine, но не пошел).
Если же объем кода большой и язык со строгой типизацией, есть много подсказок в IDE по типичным ошибка программирования на этом языке и на этой платформе (как в IDEA для Java), то слишком расточительно не пользоваться этим.
По поводу обвинений в некомпенетности (тесты, cli, микросервисы), то не надо так. В предыдущем комменте писал, что это моветон. Применение этих техник не означает, что VIM по сумме показателей вдруг становится более эффективным, чем IDE. Вы правда думаете, что новые редакторы (Atom и Visual Studio Code) написали люди, которые ничего не слышали о VIM? Если их написали таким образом, каким написали, то все-таких Emacs победил в споре с VIM, хотя и сам умер.
Работать с плохим руководителем очень плохо для сотрудников, но это не имеет отношения к IDE или сложности проектов на тысячи человеколет с несколькими поколениями программистов в текущем модуле.
Такая вероятность есть. Обычно закрывается компромиссным вариантов в виде обучения в течении недели, а затем техническое проектирование перед написанием кода и code review после товарищами, которые более знакомы с проектом.
Для проектов 10+ лет в большинстве случаев это не опция, а данность. Даже если оно спроектировано более-менее, то все равно размер и ограниченность в сроках не позволяет сначала досконально понять приложение, а уже только потом что-то в нем дорабатывать.
Еще раз: vim может быть эффективней для отдельных видов работ, но их объем в командах (в которых работал) незначителен, а, из-за минусов, программист с VIM проигрывает программистам с IDE (при прочих равных).
Например, даже 1 ошибка, замеченная IDE и исправленная оперативно, может экономить минуты и, иногда, часы времени, а разница в скорости правки столько не даст. Довольно много раз находил NPE в Java проектах при code review таким образом (ну как находил… просто читал подсказку, которую не осилил прочитать первоначальный программист).
Удивляет частая аргументация, что vim лучше, а если кто-то думает не так, то он:
— некомпенентент
— не умеет работать в vim
— если даже умеет (например, использую его для правки настроек на тестовых серверах, хотя все реже с внедрением практик DevOps), то, значит, умеет недостаточно
Не знаю приложений, которые лучше справятся с отладкой, чем IDE. Да и про другие приложения как-то примеры на ум не приходят.
А про Unix way вы сами себе противоречите (ниже в комментарии): то IDE вызывают внешние команды (и это плохо), то IDE реализуют что-то внутри (и это плохо). Понятно, что сейчас никто не будет что-то реализовывать самостоятельно, если есть возможность адекватно переиспользовать что-то существующее.
Можно посмотреть со стороны сценариев использования редакторов:
— Чтение и навигация по коду
IDE лучше: доп. подсказки (error, warnings), остальное на +- том же уровне, если донастраивать VIM
— Вставка текста (режим INSERT в VIM)
IDE лучше: доп. подсказки (error, warnings), автоисправления, остальное на +- том же уровне, если донастраивать VIM
— Отладка: IDE лучше, очень много всякого в деталях и UI
— Небольшие правки: не важна скорость правок, т.к. примерно то же самое, а вот
доп. анализ как раз хорош (и возможность интеграции с дебагером)
— Более крупные правки: тут как раз VIM заявляет о своем превосходстве. Такие правки
распадаются на вставку текста, рефакторинги и действительно изменения текстаю В IDE
предусмотрены рефакторинги, которые закрывают значительное количество случаев
необходимости правки в нескольких местах (переименование, выделение переменных и методов,
перенос методов между классами, изменение сигнатур методов). При этом исключен
человеческих фактор (опечатки, что-то где-то забыл допереименовать). Т.е. признаю,
что множество мелких правок удобнее делать в VIM, но таких случаев крайне мало
в моей практике крайне мало, а в остальном IDE удобнее.
IDE слабы в поддержке экзотических языков, но для этого есть соверменные
редакторы (по сути полуIDE): Atom/VSCode.
VIM лучше:
— изменение конфигов на сервере через ssh (хотя не очень хорошая практика)
— слабая машина, которая не тянет и современные редакторы Atom/VSCode
— ореол избранности (он на VIM пишет), вполне адекватная причина использования
— действительно приходится много редактировать без возможности использовать
рефакторинги и автопроверки IDE
Красивое переиспользование сервисов из default namespace.
API-шлюз не нравится, в kubernetes есть отдельные абстракции (Service) для этого. Но, может, просто специфики не понимаю (это же не выкатка на staging-production, чтобы частично трафик раздавать). Ssl-offloader похож на Ingress абстракцию, но можно оставить и так, если всем хватает одной универсальной настройки.
Есть автоматическое удаление playground при удалении соответствующей ветки? Еще можно сделать рассылку еженедельную со списком долгоживущих веток и временем их жизни и их «стоимостью» в cpu/ram.
Непонятна эмоциональность в экономике. Обычные процессы для нового рынка.
Да, индустрия активно развивается. Есть возможность построить огромные компании очень быстро по меркам других индустрий. Именно по этому идут инвестиции. Сейчас много экспериментов, нужен быстрый поиск продуктов и их развитие. Базовые технологии (прежде всего Hardware и Open Source) так же активно развиваются. Это обуславливает определенные требования к кадрам. Желаемые кадры в дефиците, поэтому предлагаются различные плюшки в конкурентной борьбе за сотрудников. Например, если настольный футбол позволит нанять хотя бы одного инженера выше среднего, то он сразу же окупается.
Понятно, что это все закончится рано или поздно. Большинство затрат на исследования порежут, остальные подразделения будут активно оптимизировать.
И создатели компаний, и инвесторы в массе своей адекватные люди. Текущие действия показывают текущий уровень развития венчурного предпринимательства, как бы банально это не звучало.
Что реально будет в будущем очень сложно сказать, т.к. идет автоматизация практически всего и со временем стоимость этого уменьшается, а, значит, увеличивается охват. Прежде чем программисты станут не нужны, они успеют автоматизацией уволить большую часть остального населения. А чем займут миллиарды людей без работы посмотрим…
При этом такие тенденции как работа из дома и различные сообщества не особо зависят от стадий развития индустрии/компании/продукта.
Как-то желто. Java остается, MySQL остается, VirtualBox остается, может еще что-то, особо не разбирался что входило в Sun на момент покупки. Только Solaris и Co перестают развивать, давно к этому шло, мало кто делает новые решения на базе Solaris.
Важно! Если вы не обладаете знаниями в перечисленных ниже технологиях, укажите в заявке, какие технологии вы будете использовать при реализации прототипа.
ФРОНТАЛЬНЫЕ ПРИЛОЖЕНИЯ:
Angular, TypeScript, SCSS, Gulp/Grunt, Java Swing
Формулировка выглядит так, что если я знаю Gulp/Grunt, но хочу использовать Webpack, то не надо так.
Есть 2 места уточнения реализации: в определении и в месте вставки. Самое простое — в одном из определений прописать Default. Тогда в месте вставки не будет неопределенности какой бин использовать.
Так же можно создать собственную аннотацию, использовать ее в определении и в месте вставки. Тогда могут существовать и другие реализации того же интерфейса/класса, но они не будут использованы.
Еще в месте определения можно добавлять условия на используемый профиль Спринга или любое конфигурационное свойство. Таким образом, можно во время запуска можно подключать одну реализацию из нескольких.
> Возможность иметь точки сборки, время жизни которых меньше времени работы приложения.
Обычно смотрят на это немного по другому: точка сборки та же, но вот время жизни компонента выставляют через соотвествующий scope. В принципе, получается то же самое. Есть стандартные scope для веб-приложений, можно делать собственные.
> Если я правильно понимаю, Spring реализует точку сборки сам, не давая это сделать программисту.
Основной способ работы со Спрингом сейчас — через аннотации. Либо Component (и специализации), либо сочетание @Configuration/@Bean. Плюс, есть возможность через xml прописать. Я практически уверен, что можно подменить стандартный класс, который это делает, только не вижу особой причины.
8 часов в день на тестирование — явно занижено. Во-первых, на обед вряд ли эффективно выключать (+1 час). Во-вторых, если тестируют несколько человек и свободный график, то редко все приходят в одно время (+2-3 часа). Ещё люблю время от времени на ночь оставлять для отработки на более-менее реальном объеме.
Но важнее другое. Сравнивается bare metal и публичное облако. Сразу хочется вспомнить о приватном облаке. Тема сложная, нужно учитывать все проекты, а не только один, квалификацию людей на внедрение и поддержку, но в таких расчетах тоже стоит учитывать.
Несколько удивила концовка. Проблема не в альфах, там все понятно. Проблема в стабильных версиях (как в примере с энергопотреблением Идеи). Особенно во всяких SaaS, где тебя не особо спрашивают удобно тебе обновляться или нет.
Есть проекты в которых не принципиально наличие дополнительных функций из IDE. Например, сам не использовал IDE для Ruby on Rails проектов на несколько разработчиков на несколько лет: и объем кода небольшой, и динамические языки тяжело поддерживаются IDE (при этом был купленный RubyMine, но не пошел).
Если же объем кода большой и язык со строгой типизацией, есть много подсказок в IDE по типичным ошибка программирования на этом языке и на этой платформе (как в IDEA для Java), то слишком расточительно не пользоваться этим.
По поводу обвинений в некомпенетности (тесты, cli, микросервисы), то не надо так. В предыдущем комменте писал, что это моветон. Применение этих техник не означает, что VIM по сумме показателей вдруг становится более эффективным, чем IDE. Вы правда думаете, что новые редакторы (Atom и Visual Studio Code) написали люди, которые ничего не слышали о VIM? Если их написали таким образом, каким написали, то все-таких Emacs победил в споре с VIM, хотя и сам умер.
Например, даже 1 ошибка, замеченная IDE и исправленная оперативно, может экономить минуты и, иногда, часы времени, а разница в скорости правки столько не даст. Довольно много раз находил NPE в Java проектах при code review таким образом (ну как находил… просто читал подсказку, которую не осилил прочитать первоначальный программист).
Удивляет частая аргументация, что vim лучше, а если кто-то думает не так, то он:
— некомпенентент
— не умеет работать в vim
— если даже умеет (например, использую его для правки настроек на тестовых серверах, хотя все реже с внедрением практик DevOps), то, значит, умеет недостаточно
Не знаю приложений, которые лучше справятся с отладкой, чем IDE. Да и про другие приложения как-то примеры на ум не приходят.
А про Unix way вы сами себе противоречите (ниже в комментарии): то IDE вызывают внешние команды (и это плохо), то IDE реализуют что-то внутри (и это плохо). Понятно, что сейчас никто не будет что-то реализовывать самостоятельно, если есть возможность адекватно переиспользовать что-то существующее.
Кстати, их можно отключить, если все или часть раздражают.
— Чтение и навигация по коду
IDE лучше: доп. подсказки (error, warnings), остальное на +- том же уровне, если донастраивать VIM
— Вставка текста (режим INSERT в VIM)
IDE лучше: доп. подсказки (error, warnings), автоисправления, остальное на +- том же уровне, если донастраивать VIM
— Отладка: IDE лучше, очень много всякого в деталях и UI
— Небольшие правки: не важна скорость правок, т.к. примерно то же самое, а вот
доп. анализ как раз хорош (и возможность интеграции с дебагером)
— Более крупные правки: тут как раз VIM заявляет о своем превосходстве. Такие правки
распадаются на вставку текста, рефакторинги и действительно изменения текстаю В IDE
предусмотрены рефакторинги, которые закрывают значительное количество случаев
необходимости правки в нескольких местах (переименование, выделение переменных и методов,
перенос методов между классами, изменение сигнатур методов). При этом исключен
человеческих фактор (опечатки, что-то где-то забыл допереименовать). Т.е. признаю,
что множество мелких правок удобнее делать в VIM, но таких случаев крайне мало
в моей практике крайне мало, а в остальном IDE удобнее.
IDE слабы в поддержке экзотических языков, но для этого есть соверменные
редакторы (по сути полуIDE): Atom/VSCode.
VIM лучше:
— изменение конфигов на сервере через ssh (хотя не очень хорошая практика)
— слабая машина, которая не тянет и современные редакторы Atom/VSCode
— ореол избранности (он на VIM пишет), вполне адекватная причина использования
— действительно приходится много редактировать без возможности использовать
рефакторинги и автопроверки IDE
В остальном все-таки IDE эффективнее.
API-шлюз не нравится, в kubernetes есть отдельные абстракции (Service) для этого. Но, может, просто специфики не понимаю (это же не выкатка на staging-production, чтобы частично трафик раздавать). Ssl-offloader похож на Ingress абстракцию, но можно оставить и так, если всем хватает одной универсальной настройки.
Есть автоматическое удаление playground при удалении соответствующей ветки? Еще можно сделать рассылку еженедельную со списком долгоживущих веток и временем их жизни и их «стоимостью» в cpu/ram.
По идее это информационный терминал и должен быть во внешней сети, так что ни о каких ПД речь не идет.
Да, индустрия активно развивается. Есть возможность построить огромные компании очень быстро по меркам других индустрий. Именно по этому идут инвестиции. Сейчас много экспериментов, нужен быстрый поиск продуктов и их развитие. Базовые технологии (прежде всего Hardware и Open Source) так же активно развиваются. Это обуславливает определенные требования к кадрам. Желаемые кадры в дефиците, поэтому предлагаются различные плюшки в конкурентной борьбе за сотрудников. Например, если настольный футбол позволит нанять хотя бы одного инженера выше среднего, то он сразу же окупается.
Понятно, что это все закончится рано или поздно. Большинство затрат на исследования порежут, остальные подразделения будут активно оптимизировать.
И создатели компаний, и инвесторы в массе своей адекватные люди. Текущие действия показывают текущий уровень развития венчурного предпринимательства, как бы банально это не звучало.
Что реально будет в будущем очень сложно сказать, т.к. идет автоматизация практически всего и со временем стоимость этого уменьшается, а, значит, увеличивается охват. Прежде чем программисты станут не нужны, они успеют автоматизацией уволить большую часть остального населения. А чем займут миллиарды людей без работы посмотрим…
При этом такие тенденции как работа из дома и различные сообщества не особо зависят от стадий развития индустрии/компании/продукта.
Формулировка выглядит так, что если я знаю Gulp/Grunt, но хочу использовать Webpack, то не надо так.
Ощущение, что вместо фана будет корпоративное рабство на 48 часов.
Есть 2 места уточнения реализации: в определении и в месте вставки. Самое простое — в одном из определений прописать Default. Тогда в месте вставки не будет неопределенности какой бин использовать.
Так же можно создать собственную аннотацию, использовать ее в определении и в месте вставки. Тогда могут существовать и другие реализации того же интерфейса/класса, но они не будут использованы.
Еще в месте определения можно добавлять условия на используемый профиль Спринга или любое конфигурационное свойство. Таким образом, можно во время запуска можно подключать одну реализацию из нескольких.
> Возможность иметь точки сборки, время жизни которых меньше времени работы приложения.
Обычно смотрят на это немного по другому: точка сборки та же, но вот время жизни компонента выставляют через соотвествующий scope. В принципе, получается то же самое. Есть стандартные scope для веб-приложений, можно делать собственные.
> Если я правильно понимаю, Spring реализует точку сборки сам, не давая это сделать программисту.
Основной способ работы со Спрингом сейчас — через аннотации. Либо Component (и специализации), либо сочетание @Configuration/@Bean. Плюс, есть возможность через xml прописать. Я практически уверен, что можно подменить стандартный класс, который это делает, только не вижу особой причины.
Но важнее другое. Сравнивается bare metal и публичное облако. Сразу хочется вспомнить о приватном облаке. Тема сложная, нужно учитывать все проекты, а не только один, квалификацию людей на внедрение и поддержку, но в таких расчетах тоже стоит учитывать.