Кек! Тоже не поклонник Дяди Боба, но приводить местечковый подкаст в качестве аргумента против всемирно известного автора книг и общепринятой практики - это мощно.
На SOLID может и не надо молиться, как и на любые рекомендации по проектированию, но как показывает практика, прям ненависть к SOLID испытывают те, кто никогда ничего сложного не писал и больше года над проектом не работал.
"если спринт не закрыли", то "задавать вопросы" уже поздно
Чего это вдруг? Вся суть спринтов в том, чтобы быстро получать промежуточные результаты и обратную связь. Если в спринте не сделаны или плохо сделаны пара задач, то для проекта это не должно быть чувствительным. Есть время и для ретроспективы, и для второй попытки, и для 1-1. Если всё это не помогло и разработчик продолжает не справляться с работой, то нужно просто с ним попрощаться. Самое что ни на есть управление, на основе фактов, а не ощущений тревожного менеджера.
Во-первых, мелкому менеджеру вообще нефиг что-то спрашивать у разработчика, пусть с тимлидом общается. Во-вторых, на планировании командой оценили сложность задач, набили бэклог спринта и всё, увидимся после спринта не ретроспективе, где можно будет задать вопросы, если спринт не закрыли. С каскадом в целом так же, если менеджеры не обгадились с процессами, то синхронизация на майлстоунах через руководителя группы. Если менеджер, как описано в статье, регулярно дёргает разработчиков, то он однозначно плохо делает свою работу.
Один раз говоришь микроменеджеру, что ты так не работаешь, если он не понял, пишешь заявление. Когда у него из команды уйдут все уважающие себя разработчики, и качество работы упадёт ниже плинтуса, тогда он научится не страдать хернёй или вышестоящее руководство сменит его на нормального.
Не буду говорить про все (хоть и очень хочется), но в очень многих случаях применение аутсорсинга - это признак эффективного менеджмента, не думающего дальше ближайшей премии, любяшего подход "херак-херак и в прод", считающего техдолг проблемой следующего менеджера и желающего покупать рабов безропотных исполнителей, а не строить долгосрочные партнёрские отношения с коллективом.
Всегда угараю с людей без софтскиллов, вы же вообще не понимаете как работает институт репутации и какую большую роль в отрасли играют неформальные контакты. Дело ваше, накручивайте опыт, когда поймают, отзывайте согласие на обработку и хранение персональных данных. Потом пишите на Хабр статью, как пузырь ИТ лопнул и рынок труда отрасли обвалился, потому что вы полгода ищете работу, но на сотни откликов нет ни одного ответа, а после спорьте с удивлёнными комментариями от тех, кого нон-стоп хантят на 300к в секунду.
Не надо иметь паспортные данные, чтобы идентифицировать кандидата, достаточно контактных. Ещё хорошо в идентификации помогают места и годы учёбы, а также места, должности и годы работы. К тому же, когда я в прошлый раз собеседовался, то подписывал бумажку о разрешении на обработку и хранение моих ПД перед проверкой моей кандидатуры, так что с позиции закона всё в порядке. Да и тому же HeadHunter'у мы даём такое согласие при регистрации, а оно включает право передачи данных нанимателям. Можете, конечно, нигде резюме не публиковать и после каждого собеседования официально отзывать своё согласие, но не удивляйтесь потом, что вас совсем перестанут на собеседования приглашать.
Обыденная реальность российских компаний. Если мы говорим не про мидла в области натягивания ворованных шаблонов на WordPress для сайта самого крупного магазина чебуреков в Сызрани, конечно.
Сторонникам Rust надо просто форкнуть ядро и переписать его на Rust полностью. Так им никто мешать не будет. И если получится версия ничуть не хуже, но безопаснее, все естественным образом начнут переезжать на неё, голосуя этим за превосходство Rust.
Помню, когда виртуальные потоки находились ещё в разработке, весь интернет, включая Хабр, пестрел статьями о том, как они сразу же и волшебным образом поднимут производительность многопоточных программ на Java, не требуя никаких изменений в коде. Тогда комментарии с моими сомнениями на этот счёт обильно минусовали. Сильна у людей вера в чудеса и страсть к халяве.
Всё равно не объясняет избирательность недоступности ресурсов. Если ТСПУ реализовано так, что при недоступности блэклиста блокирует всё, то DDoS должен был привести к недоступности всех ресурсов. Если ТСПУ при недоступности блэклиста разрешает всё, то должны были перестать действовать все блокировки.
Даже интереснее: как организовать такую атаку, чтобы операторы потеряли возможность предоставлять доступ только к отдельным ресурсам, но через VPN те же ресурсы прекрасно открывались.
Автор свалил всё в кучу, пробежал верхами, местами ввёл в заблуждение и не сказал про действительно важные моменты. Прежде всего, СУРБД - это системы с очень широкой областью применения, они подойдут в большинстве задач. В то время, как остальные перечисленные системы - это более узкоспециализированные инструменты, которые обычно требуются для решения специфических проблем. Кроме того, PostgreSQL требует намного меньше ресурсов, чем например MongoDB или Datomic. Кстати про Datomic, это графовая СУБД, а не реляционная.
Это не так. Правовые отношения в процессе сделки возникают у покупателя с продавцом, всю ответственность несёт продавец. Впоследствии он может выставить регрессивный иск поставщику. В случае описанного в статье правильный порядок претензий - от покупателя маркетплейсу, от маркетплейса издательству, от издательства автору книги.
На википедии в статьях "ABBYY" и "Ян, Давид Евгеньевич" тоже война правок идёт. Хорошо, что Интернет всё помнит!
Кек! Тоже не поклонник Дяди Боба, но приводить местечковый подкаст в качестве аргумента против всемирно известного автора книг и общепринятой практики - это мощно.
На SOLID может и не надо молиться, как и на любые рекомендации по проектированию, но как показывает практика, прям ненависть к SOLID испытывают те, кто никогда ничего сложного не писал и больше года над проектом не работал.
Чего это вдруг? Вся суть спринтов в том, чтобы быстро получать промежуточные результаты и обратную связь. Если в спринте не сделаны или плохо сделаны пара задач, то для проекта это не должно быть чувствительным. Есть время и для ретроспективы, и для второй попытки, и для 1-1. Если всё это не помогло и разработчик продолжает не справляться с работой, то нужно просто с ним попрощаться. Самое что ни на есть управление, на основе фактов, а не ощущений тревожного менеджера.
Во-первых, мелкому менеджеру вообще нефиг что-то спрашивать у разработчика, пусть с тимлидом общается. Во-вторых, на планировании командой оценили сложность задач, набили бэклог спринта и всё, увидимся после спринта не ретроспективе, где можно будет задать вопросы, если спринт не закрыли. С каскадом в целом так же, если менеджеры не обгадились с процессами, то синхронизация на майлстоунах через руководителя группы. Если менеджер, как описано в статье, регулярно дёргает разработчиков, то он однозначно плохо делает свою работу.
Один раз говоришь микроменеджеру, что ты так не работаешь, если он не понял, пишешь заявление. Когда у него из команды уйдут все уважающие себя разработчики, и качество работы упадёт ниже плинтуса, тогда он научится не страдать хернёй или вышестоящее руководство сменит его на нормального.
Да тысячи их! Man bun - самая популярная хипстерская причёска последние лет десять.
Про неё даже шутки уже бородатые
Не буду говорить про все (хоть и очень хочется), но в очень многих случаях применение аутсорсинга - это признак эффективного менеджмента, не думающего дальше ближайшей премии, любяшего подход "херак-херак и в прод", считающего техдолг проблемой следующего менеджера и желающего покупать
рабовбезропотных исполнителей, а не строить долгосрочные партнёрские отношения с коллективом.Китайские наниматели конкурируют на рынке труда, а тайваньские работники не крепостные, оказывается - каковы негодяи!
Это не про округление пары месяцев. На пару месяцев всем плевать, конечно.
Всегда угараю с людей без софтскиллов, вы же вообще не понимаете как работает институт репутации и какую большую роль в отрасли играют неформальные контакты. Дело ваше, накручивайте опыт, когда поймают, отзывайте согласие на обработку и хранение персональных данных. Потом пишите на Хабр статью, как пузырь ИТ лопнул и рынок труда отрасли обвалился, потому что вы полгода ищете работу, но на сотни откликов нет ни одного ответа, а после спорьте с удивлёнными комментариями от тех, кого нон-стоп хантят на 300к в секунду.
Не надо иметь паспортные данные, чтобы идентифицировать кандидата, достаточно контактных. Ещё хорошо в идентификации помогают места и годы учёбы, а также места, должности и годы работы. К тому же, когда я в прошлый раз собеседовался, то подписывал бумажку о разрешении на обработку и хранение моих ПД перед проверкой моей кандидатуры, так что с позиции закона всё в порядке. Да и тому же HeadHunter'у мы даём такое согласие при регистрации, а оно включает право передачи данных нанимателям. Можете, конечно, нигде резюме не публиковать и после каждого собеседования официально отзывать своё согласие, но не удивляйтесь потом, что вас совсем перестанут на собеседования приглашать.
Даже и не знаю каким эпитетом оценить совет врать и накручивать опыт, чтобы потом на проверке получить чёрную метку.
Обыденная реальность российских компаний. Если мы говорим не про мидла в области натягивания ворованных шаблонов на WordPress для сайта самого крупного магазина чебуреков в Сызрани, конечно.
Какой климат на вашей планете?
За 125к сейчас только джуна одногодку нанять можно. Мидлы ниже 300к даже разговаривать не будут.
6 вакансий на одного мидла и 160 джунов на одну вакансию скорее.
Сторонникам Rust надо просто форкнуть ядро и переписать его на Rust полностью. Так им никто мешать не будет. И если получится версия ничуть не хуже, но безопаснее, все естественным образом начнут переезжать на неё, голосуя этим за превосходство Rust.
Помню, когда виртуальные потоки находились ещё в разработке, весь интернет, включая Хабр, пестрел статьями о том, как они сразу же и волшебным образом поднимут производительность многопоточных программ на Java, не требуя никаких изменений в коде. Тогда комментарии с моими сомнениями на этот счёт обильно минусовали. Сильна у людей вера в чудеса и страсть к халяве.
Всё равно не объясняет избирательность недоступности ресурсов. Если ТСПУ реализовано так, что при недоступности блэклиста блокирует всё, то DDoS должен был привести к недоступности всех ресурсов. Если ТСПУ при недоступности блэклиста разрешает всё, то должны были перестать действовать все блокировки.
Даже интереснее: как организовать такую атаку, чтобы операторы потеряли возможность предоставлять доступ только к отдельным ресурсам, но через VPN те же ресурсы прекрасно открывались.
Автор свалил всё в кучу, пробежал верхами, местами ввёл в заблуждение и не сказал про действительно важные моменты. Прежде всего, СУРБД - это системы с очень широкой областью применения, они подойдут в большинстве задач. В то время, как остальные перечисленные системы - это более узкоспециализированные инструменты, которые обычно требуются для решения специфических проблем. Кроме того, PostgreSQL требует намного меньше ресурсов, чем например MongoDB или Datomic. Кстати про Datomic, это графовая СУБД, а не реляционная.
Это не так. Правовые отношения в процессе сделки возникают у покупателя с продавцом, всю ответственность несёт продавец. Впоследствии он может выставить регрессивный иск поставщику. В случае описанного в статье правильный порядок претензий - от покупателя маркетплейсу, от маркетплейса издательству, от издательства автору книги.