Все еще хуже. Со всеми курсами давно связаны крупные фирмы: направляют своих лекторов, спонсируют курсы или вообще являются владельцами компании, которая эти курсы проводит. Как следствие по-настоящему хорошие кандидаты сразу вылавливаются и не приходят на hh.
А это баг самой Волны. У меня такая проблема была и в мобильном навигаторе. Как я понял, есть некоторая связь между количеством залайканых композиций и волной. Возможно волна перестраивается только при изменении списка избранного или есть более сложная корреляция. Но пока я не сиал активно лайкать и волна и плейлист дня не обновлялись.
Мне кажется уменьшение кодовой базы своего рода легендой. Не очень понятно почему оно должно уменьшится. Вся кодовая база это грубо говоря два крупных блока: бизнес логика и обслуживающий код.
Бизнес логика имеет примерно одинаковый объем при любом раскладе и может уменьшится только переходом на более абстрактный DSL.
А объем служебного кода в микросервисах не так уж и мал, как об этом принято говорить. Например разнообразный код связанный с безопасность, авторизацией и подобным путешествует из одного сервиса в другой в виде связанных библиотек (что хорошо) или даже наколеночных частных реализаций (что плохо). По этой же причине невозможно писать сервисы на совсем уж любом языке. Все упирается в наличие нужных библиотек под твой язык.
Меня всегда интересовало, а зачем покупать хайдипиай мышу и включать ее только на разминке? Логично всегда в игре ставить максимум, а сенсу занижать, чтоб точность повысить и плавность.
Это устоявшийся термин скорее историографического характера. Он не выражен в конкретных цифрах. Просто в эти периоды было заметно проще жить в Европе, чем в соседние периоды, когда климат был холоднее.
Наивно считать, что авторы языка «деды» и ничего не знают о ФП подходах.
Да нет тут никакой наивности. Вспомните как они сделали go get и сравните это с rust, ruby или php. Ну видно же, что люди по-прежнему на autotools сидят. Или реализация Generic, которую выпрашивали миллион лет и которая осталась слегка недоделаной.
Вы спросите: почему бы по умолчанию не использовать знакомый многим Either и не шатать мозги? Монады по-настоящему раскрываются только в случае если используются в связке с другими монадами.
Не думаю, что надо весь ФП тянуть. Например Rust и без этого справляется. Точно нужны полноценные макросы и нормальная система типов. Не как в Haskell, конечно, но постараться можно было.
Потрясающая статья: человек в течении многих лет старательно убеждает себя в том, что выбор был правильным и полностью игнорирует проблемы.
Да, подход C++ и Java (довольно старые языки), вызывает проблемы, но и подход Go тоже с сюрпризами. Почему-то, в этих статьях от "больших" специалистов полностью игнорируются такие вещи как Option типы и связанные с этим макросы, которые распространены в других языках типа Haskell, Rust, Kotlin.
Причина такой "избирательности" в банальной старости авторов языка: они не знают ничего за пределами C/C++ похоже.
Почему-то во всех этих минималистиных клавах никто не уделяет внимание подставкам под запястья. У ergodox ez есть, но имхо, до удобства MS Sculpt далековато.
Для этого на эргономичных клавах есть "слои". Это как режимы в вим. Нажал кнопку и hjkl начинают отдавать стрелки. Это сделано на уровне микрухи в самой клавиатуре.
Мне кажется инструменты не поспевают за ожиданиями рынка. Те же JS фреймворки. Вроде почитаешь ТТХ и преимущества React над JQuery кажется неоспоримым, но почему-то затраченное время на разработку осталось тем же.
А корень это проблемы в том, что есть большая разница в ожиданиях пользователя сейчас и 15 лет назад при казалось бы той же бизнес задаче. Например бизнес задача показать табличку с фильтрами и сортировкой. Но возникает много нефукнциональных дополнений по типу того, что табличка должна хорошо работать на мобилке и на ПК или код работающий с табличкой должен легко переиспользоваться или еще что-нибудь подобное.
Вроде, по слухам, они скомпенсировали делистинг. И даже по некоторым направлениям стали рыночную цену давать, поскольку потери в людях оказвлись большими.
Как седло велосипеда. Если не сложилось с совместмостью сиденья и седалища, то будет больно. Но спине и правда легче, чем в обычном офисном кресле (даже дорогом).
Я долгое время использую систему с тремя стульями: седло, обычное кресло и мешок (тут конечно на ноут приходится переходить). В каждом из вариантов болит разное :)
Также надо понимать, что для седла нужен регулируемый стол, поскольку позиция меняется
Ок. Мы проставили теги. Возможно мы много тегов проставили, поскольку оцениваем несколько качеств. Как дальше мы на основе текстовых тегов приоритезируем бэклог?
При всех этих подходах необходимо разделение бэклогов (даже для одно приложения) на пользовательские и, скажем так, системные. Все что связанно с архитектурными изменениями, рефакторингами и т.д. должно оцениваться в разрезе снижения костов или повышения качества, а это уже не ICE/RICE.
Такой подход наиболее эффективен при очень большом бэклоге для компании на b2c рынке. Там фишка в том, что 80% бэклога никогда не будет сделано и надо делать то, что горит прям сейчас ибо конкуренты не дремлют. Отсюда довольно простая логика сводящаяся к сравнению циферок.
Ну и добавлять в мониторинг каждый раз новый сайт неудобно, а так у нас вместо тысячи проверок на тысячу сайтов всего одна проверка с сутью "все LE сертификаты свежи".
Все еще хуже. Со всеми курсами давно связаны крупные фирмы: направляют своих лекторов, спонсируют курсы или вообще являются владельцами компании, которая эти курсы проводит. Как следствие по-настоящему хорошие кандидаты сразу вылавливаются и не приходят на hh.
А это баг самой Волны. У меня такая проблема была и в мобильном навигаторе. Как я понял, есть некоторая связь между количеством залайканых композиций и волной. Возможно волна перестраивается только при изменении списка избранного или есть более сложная корреляция. Но пока я не сиал активно лайкать и волна и плейлист дня не обновлялись.
Мне кажется уменьшение кодовой базы своего рода легендой. Не очень понятно почему оно должно уменьшится. Вся кодовая база это грубо говоря два крупных блока: бизнес логика и обслуживающий код.
Бизнес логика имеет примерно одинаковый объем при любом раскладе и может уменьшится только переходом на более абстрактный DSL.
А объем служебного кода в микросервисах не так уж и мал, как об этом принято говорить. Например разнообразный код связанный с безопасность, авторизацией и подобным путешествует из одного сервиса в другой в виде связанных библиотек (что хорошо) или даже наколеночных частных реализаций (что плохо). По этой же причине невозможно писать сервисы на совсем уж любом языке. Все упирается в наличие нужных библиотек под твой язык.
Меня всегда интересовало, а зачем покупать хайдипиай мышу и включать ее только на разминке? Логично всегда в игре ставить максимум, а сенсу занижать, чтоб точность повысить и плавность.
Это устоявшийся термин скорее историографического характера. Он не выражен в конкретных цифрах. Просто в эти периоды было заметно проще жить в Европе, чем в соседние периоды, когда климат был холоднее.
Да нет тут никакой наивности. Вспомните как они сделали go get и сравните это с rust, ruby или php. Ну видно же, что люди по-прежнему на autotools сидят. Или реализация Generic, которую выпрашивали миллион лет и которая осталась слегка недоделаной.
Не думаю, что надо весь ФП тянуть. Например Rust и без этого справляется. Точно нужны полноценные макросы и нормальная система типов. Не как в Haskell, конечно, но постараться можно было.
Потрясающая статья: человек в течении многих лет старательно убеждает себя в том, что выбор был правильным и полностью игнорирует проблемы.
Да, подход C++ и Java (довольно старые языки), вызывает проблемы, но и подход Go тоже с сюрпризами. Почему-то, в этих статьях от "больших" специалистов полностью игнорируются такие вещи как Option типы и связанные с этим макросы, которые распространены в других языках типа Haskell, Rust, Kotlin.
Причина такой "избирательности" в банальной старости авторов языка: они не знают ничего за пределами C/C++ похоже.
Почему-то во всех этих минималистиных клавах никто не уделяет внимание подставкам под запястья. У ergodox ez есть, но имхо, до удобства MS Sculpt далековато.
Для этого на эргономичных клавах есть "слои". Это как режимы в вим. Нажал кнопку и hjkl начинают отдавать стрелки. Это сделано на уровне микрухи в самой клавиатуре.
Странное сравнение. Это скорее похоже на Application Server из мира Java, чем на Docker.
Мне кажется инструменты не поспевают за ожиданиями рынка. Те же JS фреймворки. Вроде почитаешь ТТХ и преимущества React над JQuery кажется неоспоримым, но почему-то затраченное время на разработку осталось тем же.
А корень это проблемы в том, что есть большая разница в ожиданиях пользователя сейчас и 15 лет назад при казалось бы той же бизнес задаче. Например бизнес задача показать табличку с фильтрами и сортировкой. Но возникает много нефукнциональных дополнений по типу того, что табличка должна хорошо работать на мобилке и на ПК или код работающий с табличкой должен легко переиспользоваться или еще что-нибудь подобное.
Вроде, по слухам, они скомпенсировали делистинг. И даже по некоторым направлениям стали рыночную цену давать, поскольку потери в людях оказвлись большими.
Как седло велосипеда. Если не сложилось с совместмостью сиденья и седалища, то будет больно. Но спине и правда легче, чем в обычном офисном кресле (даже дорогом).
Я долгое время использую систему с тремя стульями: седло, обычное кресло и мешок (тут конечно на ноут приходится переходить). В каждом из вариантов болит разное :)
Также надо понимать, что для седла нужен регулируемый стол, поскольку позиция меняется
Ну тогда это выходит эквивалентно выставлению одного числа. Например priority. Т.е. я не вижу какой-либо принципиально разницы с тем что в статье.
Ок. Мы проставили теги. Возможно мы много тегов проставили, поскольку оцениваем несколько качеств. Как дальше мы на основе текстовых тегов приоритезируем бэклог?
Не очень понятно что вы понимаете под "качественной" моделью. Так-то I в ICE/RICE это тоже вполне себе качество.
При всех этих подходах необходимо разделение бэклогов (даже для одно приложения) на пользовательские и, скажем так, системные. Все что связанно с архитектурными изменениями, рефакторингами и т.д. должно оцениваться в разрезе снижения костов или повышения качества, а это уже не ICE/RICE.
Такой подход наиболее эффективен при очень большом бэклоге для компании на b2c рынке. Там фишка в том, что 80% бэклога никогда не будет сделано и надо делать то, что горит прям сейчас ибо конкуренты не дремлют. Отсюда довольно простая логика сводящаяся к сравнению циферок.
А это действительно интересно.
Любая система мониторинга умеет в шаблоны.