По моему мнению, это ровно то что позволяет снижать когнитивную нагрузку на разработчика: сервисы на Go будут очень похожи друг на друга вне зависимости от конкретного набора библиотек.
С одной стороны это плюс, но с другой стороны это является ограничением для создателей библиотек и не очень способствует конкуренции, имхо.
Я довольно подробно объяснил, почему строгая типизация без завтипов
Обратимся к тексту:
Типы могут принести очень много пользы, если они «граждане первого сорта». Ни в одном более-менее распространенном языке, кроме авангарда типа Coq/Rocq, Agda и Lean, и не покидающего стадию пре-альфа Idris, — нет зависимых типов. Строгая типизация без завтипов — детская игрушка.
SQL не является моей основной специализацией поэтому я уже делаю почти так же. Сначала говорю нейронке структуру базы, а потом что надо найти. Получаю почти всегда правильный SQL и иногда немного его правлю. Имхо, так и будет работать, вряд ли в бэкенд приложение будут вставлять непредсказуемый запрос на русском, вместо отлаженного надёжного SQL.
чтобы оно не зависло навсегда и не тормозило при наличии хотя бы 2 юзеров
добавляя по 0.5-1 секунде к задержке ответа
Это откровенная неправда. Сам знаком с людьми, которые пишут довольно популярных ботов и на JS, и на .NET, и на JVM. Поэтому претензия к блокирующим вызовам выглядит скорее вкусовщиной.
Скорее всего мои боты пока не дошли до того, что это является проблемой (да и вряд ли дойдут).
Сам пишу ботов на Java с использованием TelegramBots и проблем у меня с библиотекой примерно никаких. Всё апи поддерживается, если чего-то мне не хватает, то это косяк апи телеграма, а не библиотеки.
В общем, интересно узнать, что за требования такие к библиотекам.
если вы захотите написать телеграм бота, то вы (были) вынуждены делать это на python. Библиотеки на других языках непопулярны и зачастую не выполняют даже минимальных требований
Только данное утверждение выглядит крайне безосновательно, а по личному опыту даже не является правдой.
Как правило стараемся закрывать функциональность фича флагами, чтобы не тормозить другие команды. Но если что-то падает есть два варианта. Первый - реверт коммита. Второй, если никому сейчас сервис не нужен и можно быстро пофиксить, то сразу фиксим.
В целом, выше написали, история похожая. Разработчик делает фичу, пишет на неё тесты, если необходимо закрывает фича флагом. Далее мерж в мастер, прогонка e2e тестов, по необходимости ручное тестирование. После релиза, мониторинг ситуации на проде, по необходимости доп. тест на проде, иногда сразу на всех раскатываем иногда на часть. За факапы у нас отвечает команда, которая пилит фичу.
Не может быть никаких исключений. В сколько-нибудь серьёзном проекте (где в принципе присутствует иерархия руководства) у программистов просто не должно быть доступа на прод.
Мне кажется релиз по инициативе разработчика нажатием одной кнопки в CI это уже стандарт по индустрии.
Фичи не должны напрямую мержиться в мастер. Сначала в релизный бранч, где всё в комплексе тестируется, и только после того, как QA дали добро – в мастер и на прод.
Есть много подходов. В Tunk Based Development есть только мастер, очень удобная методология кстати.
Во-вторых, что вы делаете, если синьор уволился? Говорите мидлу: "Гарри, ты теперь синьор"? И повышаете ли ему зп? Или он просто начинает работать за себя и за того парня? Или вы нанимаете больше стажёров? Сколько стажёров может заменить синьора?
В-третьих, если вы будете нанимать только стажёров, не боитесь технического застоя в компании? У стажёров нет опыта. А новые специалисты с рынка могут принести в компанию в том числе и новые подходы, чтобы проект эволюционировал.
Развивать надо, но они форки, и JB оказывает на них сильное влияние. Отсюда и разбор новостей.
Java сделал очень большой шаг в развитии, частые итерации, много полезных фичей, язык открытый насколько это возможно. Не пониманию претензии
А на чём основывается авторитет? Почему именно эти университеты? Звучит сомнительно.
он даже на обычный линукс тригерится
С одной стороны это плюс, но с другой стороны это является ограничением для создателей библиотек и не очень способствует конкуренции, имхо.
Обратимся к тексту:
Подробного объяснения нет, один наброс.
SQL не является моей основной специализацией поэтому я уже делаю почти так же. Сначала говорю нейронке структуру базы, а потом что надо найти. Получаю почти всегда правильный SQL и иногда немного его правлю. Имхо, так и будет работать, вряд ли в бэкенд приложение будут вставлять непредсказуемый запрос на русском, вместо отлаженного надёжного SQL.
Потихоньку пилю бота с игрой для чатов https://github.com/Homyakin/project-seeker
Это откровенная неправда. Сам знаком с людьми, которые пишут довольно популярных ботов и на JS, и на .NET, и на JVM. Поэтому претензия к блокирующим вызовам выглядит скорее вкусовщиной.
Скорее всего мои боты пока не дошли до того, что это является проблемой (да и вряд ли дойдут).
Сам пишу ботов на Java с использованием TelegramBots и проблем у меня с библиотекой примерно никаких. Всё апи поддерживается, если чего-то мне не хватает, то это косяк апи телеграма, а не библиотеки.
В общем, интересно узнать, что за требования такие к библиотекам.
За старания, конечно, лайк.
Только данное утверждение выглядит крайне безосновательно, а по личному опыту даже не является правдой.
Насколько знаю, многие сидят на Java версии, в том числе из-за модов.
Не используем ORM
Если процесс построен правильно, то менторство - это такая же рабочая задача. И других задач должно становиться пропорционально меньше.
Начинание очень классное! Сам вот в процессе создания игры и open-source вселенной к ней, но этапы очень ранние
Как правило стараемся закрывать функциональность фича флагами, чтобы не тормозить другие команды. Но если что-то падает есть два варианта. Первый - реверт коммита. Второй, если никому сейчас сервис не нужен и можно быстро пофиксить, то сразу фиксим.
В целом, выше написали, история похожая. Разработчик делает фичу, пишет на неё тесты, если необходимо закрывает фича флагом. Далее мерж в мастер, прогонка e2e тестов, по необходимости ручное тестирование. После релиза, мониторинг ситуации на проде, по необходимости доп. тест на проде, иногда сразу на всех раскатываем иногда на часть. За факапы у нас отвечает команда, которая пилит фичу.
Я буквально так работаю уже много лет.
Как-то всё очень категорично
Мне кажется релиз по инициативе разработчика нажатием одной кнопки в CI это уже стандарт по индустрии.
Есть много подходов. В Tunk Based Development есть только мастер, очень удобная методология кстати.
Во-первых стажёры это хорошо.
Во-вторых, что вы делаете, если синьор уволился? Говорите мидлу: "Гарри, ты теперь синьор"? И повышаете ли ему зп? Или он просто начинает работать за себя и за того парня? Или вы нанимаете больше стажёров? Сколько стажёров может заменить синьора?
В-третьих, если вы будете нанимать только стажёров, не боитесь технического застоя в компании? У стажёров нет опыта. А новые специалисты с рынка могут принести в компанию в том числе и новые подходы, чтобы проект эволюционировал.