Жила-была компания Motorola, еще в стародавние времена когда она была американской. И работали в ней люди, которые очень любили оценивать трудозатраты. Год из году они работали над тем чтобы оценивать точно, но постоянно они промахивались. Но люди были упорные, проводили ретро, создавали списки причин которые могут повлиять на неточность оценок. Движ был нешуточный. А время шло.
Короче, через четыре года они на это плюнули. Но вы конечно можете повторить.
В оценке трудозатрат есть одна м-а-аленькая проблемка. Они становятся понятны только после выполнения задачи. Всё остальное - гадательное с разной степенью достоверности. Но раз вы просите, ваши сотрудники же не дураки. Они сначала закладывают х3-x10 а потом тянут до последнего, потому что неверная оценка создает проблемы. А, ну скорее всего у вас есть один-два "дурачка" которые оценивают супер-оптимистично а потом не вылезают с работы до ночи и пролюбливают сроки. Такие везде есть. В результате все счастливы. Люблю хэппи энды.
Кроме того, не забывайте: не все используют кубы, кто-то и на docker compose сидит. А последний в rolling deploy не умеет в принципе!
У нас с вами нет противоречий. Есть задача - под нее можно подбирать инструмент который соответствует желаемым метрикам. Я обычно руководствуюсь двумя метриками - "Time to market" и "Cost of ownership". Так вот в плане скорости разработки в подавляющем большинстве случаев выгоднее выбирать инструмент которым уже владеешь профессионально. А в плане стоимости владения лучше избегать экзотики, т.к. рынок кандидатов довольно тощий.
Двадцать лет назад разрыв был в 10 раз. Сейчас я знаю примеры когда JIT дает более высокое быстродействие чем нативный код. Ни в коем случае не говорю что это правило, но тот разрыв что был 20 лет назад сейчас пренебрежимо мал. Другое дело что да, JIT требует "прогрева", тут не спорю.
Оптимизация в реальном времени: JIT компиляторы работают во время выполнения программы, что позволяет им собирать информацию о её поведении и использовании в реальном времени. Это дает возможность применять специфичные для контекста оптимизации, которые могут быть недоступны AOT компиляторам, работающим без знания конкретного контекста использования кода.
Специализация кода: JIT компиляция может адаптировать и оптимизировать код под конкретную аппаратную платформу и текущую нагрузку. Например, если JIT определяет, что определённая функция вызывается часто, он может оптимизировать её более агрессивно, включая инлайнинг маленьких функций и специализацию кода под текущие данные.
Адаптивная оптимизация: Поскольку JIT компиляторы анализируют программу в процессе её выполнения, они могут адаптировать оптимизацию в ответ на изменяющееся поведение программы. Например, оптимизации, базирующиеся на профилировании, могут учитывать частоту и условия выполнения определенных участков кода и адаптировать их для максимальной производительности.
Удаление недостижимого кода и динамическая девиртуализация: В процессе выполнения JIT может обнаружить код, который никогда не выполняется, и опустить его, или упростить вызовы виртуальных функций, которые всегда вызывают один и тот же метод.
Так это же не бесплатно (за исключением случаев когда вы начинаете новый проект и вас окружают специалисты по Micronaut). Обычно Micronaut сравнивают со SpringBoot, и вот если рассматривать цену миграции ради 2 секунд экономии времени старта то это очень спорное решение. Опять же в плане рынка мало и проектов на Micronaut и специалистов.
Ну вы откровенно подменяете понятия. Приложение на Micronaut не работает быстрее в 10 раз. Оно только быстрее стартует. Происходит это только по причине компайл-тайм инъекций зависимостей. Все, точка. Неоткуда больше взяться приросту скорости.
Обратите внимание на разницу времени старта: 1548ms vs 144ms. Впечатляет? При этом аналогичная версия на SpringBoot стартует около 3000ms
Не впечатляет от слова совсем. Если вам нужен непрерывно работающий сервис, недоступность даже 144ms так же плоха как и 3s. Вам нужны несколько подов бегущих параллельно и наверное масштабирующиеся от нагрузки. В этом плане экономия на старте пода это экономия на спичках. Если вам не нужен непрерывно работающий сервис, 3 секунды на старт ничем не хуже 144 мс.
Ох не соврать бы, вроде enum Singleton были "нормальными" в java 1.4 или 1.5. И я сейчас даже не могу припомнить почему. В 2024 году сам шаблон Singleton основательно потускнел, ну или по крайней мере его смысл поменялся (говорим спасибо облакам, кластерам, докеру). Как верно написал @n43jl сейчас мы мыслим категориями scope (контекст). Контекст, а в 99% случаях это Spring Context, сам определяет кого, сколько и в каких случаях инстанцировать. Даже зная что скоуп по умолчанию в спринге Singleton, при проектировании приложений нам необходимо закладывать множество инстансов приложения запущенных параллельно.
У меня вопрос финансового характера, статья называется "Как я зарабатывал $10,000 в месяц...", это я так понимаю "в прыжке" и на двоих? А можно увидеть совокупные оборот/доход с ноября 2020 по время закрытия? Хотя бы порядок :)
Самая жопа что выгоду от кроилова получают люди, которые успевают спрыгнуть с поезда попадалова. И через это схема воспроизводит себя постоянно без угроз и издержек "кроителям".
Мне вот интересно, статья написана по делу, на стыке IT технологий и бизнеса. При этом даунвоутов накидали и статье и автору без единого комментария. Я понимаю страх, я понимаю неприятие "буржуев", которые "эксплуатируют" подневольный трудовой класс. Копирайтинг (наряду с Поддержкой) является отраслью на острие конфликта AI-NI и смотреть за ним надо в оба глаза. Среди нас только зубные доктора "в домике".
Да все как обычно с учеными и журналистами. По личному опыту качество ответа именно в ответах по программированию очень сильно зависит от постановки вопроса. От того, насколько хорошо предоставлен контекст проблемы и критерии качества.
Заметил что если вопрос сформулирован с "предубеждением" (типа я хочу решить проблему X и хочу для этого использовать инструмент Y) то чат переубеждать не будет если уж не совсем какая-то дичь. Постарается дать ответ исходя из пожеланий оператора. Если же сформулировать вопрос более общим способо (я хочу решить проблему X, посоветуй какие вообще варианты обычно применяются), то качество ответов резко улучшается. У меня порой складывается впечатление что он работает по принципу "спрашивай меня или что делать или как делать, но не оба сразу".
Сколько лет работал с индийцами, столько удивлялся насколько они не умеют работать со сложностью. Поначалу у меня даже складывалось впечатление что их прям предмет такой есть "как сделать простые вещи максимально сложным и кривым способом". Как итог, если их оставить одних, они очень быстро доводят любую систему до состояния когда никто не понимает как это работает и дальше херачат брутфорс подбором кода.
За 15 лет привыкаешь что мир программирования это не розовые пони, и часто тратить две недели на рефакторинг куска говна чтоб реализовать хотелку бизнеса слишком долго/дорого. И с чего бы это код вызывал какие-то чувства. Это просто работа.
Жила-была компания Motorola, еще в стародавние времена когда она была американской. И работали в ней люди, которые очень любили оценивать трудозатраты. Год из году они работали над тем чтобы оценивать точно, но постоянно они промахивались. Но люди были упорные, проводили ретро, создавали списки причин которые могут повлиять на неточность оценок. Движ был нешуточный. А время шло.
Короче, через четыре года они на это плюнули. Но вы конечно можете повторить.
В оценке трудозатрат есть одна м-а-аленькая проблемка. Они становятся понятны только после выполнения задачи. Всё остальное - гадательное с разной степенью достоверности. Но раз вы просите, ваши сотрудники же не дураки. Они сначала закладывают х3-x10 а потом тянут до последнего, потому что неверная оценка создает проблемы. А, ну скорее всего у вас есть один-два "дурачка" которые оценивают супер-оптимистично а потом не вылезают с работы до ночи и пролюбливают сроки. Такие везде есть. В результате все счастливы. Люблю хэппи энды.
Участвую в этой хрени уже сколько лет. Мотивации у участников - ноль. Тупо бюрократическая процедура ради галочки.
У нас с вами нет противоречий. Есть задача - под нее можно подбирать инструмент который соответствует желаемым метрикам. Я обычно руководствуюсь двумя метриками - "Time to market" и "Cost of ownership". Так вот в плане скорости разработки в подавляющем большинстве случаев выгоднее выбирать инструмент которым уже владеешь профессионально. А в плане стоимости владения лучше избегать экзотики, т.к. рынок кандидатов довольно тощий.
Двадцать лет назад разрыв был в 10 раз. Сейчас я знаю примеры когда JIT дает более высокое быстродействие чем нативный код. Ни в коем случае не говорю что это правило, но тот разрыв что был 20 лет назад сейчас пренебрежимо мал. Другое дело что да, JIT требует "прогрева", тут не спорю.
Так это же не бесплатно (за исключением случаев когда вы начинаете новый проект и вас окружают специалисты по Micronaut). Обычно Micronaut сравнивают со SpringBoot, и вот если рассматривать цену миграции ради 2 секунд экономии времени старта то это очень спорное решение. Опять же в плане рынка мало и проектов на Micronaut и специалистов.
Ну вы откровенно подменяете понятия. Приложение на Micronaut не работает быстрее в 10 раз. Оно только быстрее стартует. Происходит это только по причине компайл-тайм инъекций зависимостей. Все, точка. Неоткуда больше взяться приросту скорости.
Не впечатляет от слова совсем. Если вам нужен непрерывно работающий сервис, недоступность даже 144ms так же плоха как и 3s. Вам нужны несколько подов бегущих параллельно и наверное масштабирующиеся от нагрузки. В этом плане экономия на старте пода это экономия на спичках. Если вам не нужен непрерывно работающий сервис, 3 секунды на старт ничем не хуже 144 мс.
Капец, на каждом устройстве проходить эту канитель заново (пусть и рандомно тыкать кнопки). Это днище UX.
Долго пытался пристегнуть copilot к своему процессу разработки. По итогу плюнул. У меня acceptance rate сгенерированного кода был в районе 10%.
Ох не соврать бы, вроде enum Singleton были "нормальными" в java 1.4 или 1.5. И я сейчас даже не могу припомнить почему. В 2024 году сам шаблон Singleton основательно потускнел, ну или по крайней мере его смысл поменялся (говорим спасибо облакам, кластерам, докеру). Как верно написал @n43jl сейчас мы мыслим категориями scope (контекст). Контекст, а в 99% случаях это Spring Context, сам определяет кого, сколько и в каких случаях инстанцировать. Даже зная что скоуп по умолчанию в спринге Singleton, при проектировании приложений нам необходимо закладывать множество инстансов приложения запущенных параллельно.
Поправьте аннотации, у вас невалидный код. Должно быть типа:
У меня вопрос финансового характера, статья называется "Как я зарабатывал $10,000 в месяц...", это я так понимаю "в прыжке" и на двоих? А можно увидеть совокупные оборот/доход с ноября 2020 по время закрытия? Хотя бы порядок :)
Самая жопа что выгоду от кроилова получают люди, которые успевают спрыгнуть с поезда попадалова. И через это схема воспроизводит себя постоянно без угроз и издержек "кроителям".
Мне вот интересно, статья написана по делу, на стыке IT технологий и бизнеса. При этом даунвоутов накидали и статье и автору без единого комментария. Я понимаю страх, я понимаю неприятие "буржуев", которые "эксплуатируют" подневольный трудовой класс. Копирайтинг (наряду с Поддержкой) является отраслью на острие конфликта AI-NI и смотреть за ним надо в оба глаза. Среди нас только зубные доктора "в домике".
Сергей Алексашенко хорошо эту тему разобрал
На злобу дня. Цифровой рубль это не денежная реформа, это хуже @evgeny.kiselev - YouTube
Одна из интересных и не особо афишируемых особенностей, на сбережения в виде "цифровых рублей" не начисляются проценты.
Да все как обычно с учеными и журналистами. По личному опыту качество ответа именно в ответах по программированию очень сильно зависит от постановки вопроса. От того, насколько хорошо предоставлен контекст проблемы и критерии качества.
Заметил что если вопрос сформулирован с "предубеждением" (типа я хочу решить проблему X и хочу для этого использовать инструмент Y) то чат переубеждать не будет если уж не совсем какая-то дичь. Постарается дать ответ исходя из пожеланий оператора. Если же сформулировать вопрос более общим способо (я хочу решить проблему X, посоветуй какие вообще варианты обычно применяются), то качество ответов резко улучшается. У меня порой складывается впечатление что он работает по принципу "спрашивай меня или что делать или как делать, но не оба сразу".
Сколько лет работал с индийцами, столько удивлялся насколько они не умеют работать со сложностью. Поначалу у меня даже складывалось впечатление что их прям предмет такой есть "как сделать простые вещи максимально сложным и кривым способом". Как итог, если их оставить одних, они очень быстро доводят любую систему до состояния когда никто не понимает как это работает и дальше херачат брутфорс подбором кода.
Вы серьезно считаете что статья из мема и видосика на хабре это прям попасть в целевую аудиторию?
За 15 лет привыкаешь что мир программирования это не розовые пони, и часто тратить две недели на рефакторинг куска говна чтоб реализовать хотелку бизнеса слишком долго/дорого. И с чего бы это код вызывал какие-то чувства. Это просто работа.