Как стать автором
Обновить
26
Карма
0
Рейтинг

Пользователь

35 лет DNS, системе доменных имён

До сих пор не могу простить создателям dns'а перевёрнутый "арабский" способ написания адресов. Знаю историю, понимаю, почему они так сделали, но простить не могу. Жутко бесит.

Что делать если команда не хочет проводить Ретро? (Часть 1)

Сказал прямо в душу. Смело могу нотариально подписаться под каждым абзацем и отвечать за это в суде.

Интересное наблюдение:

  1. Люди, которые приходят в "большое ИТ" с производств наиболее адекватны и наиболее нацелены на результат. С ними приятно работать, они никогда не подведут. Если что-то начинает идти не так, они не будут рефлексировать, плакать в подушку и дожидаться ретро. Они просто громко заявят о проблеме.

  2. Люди, которые попали в "большое ИТ" сразу, принимают весь этот скрам-бред как должное, они просто не видели другого. И вот с ними работать очень сложно: хнык-хнык, плак-плак, к моему мега-реквесту написали аж пять замечаний, значит, меня здесь не любят, вот дождусь ретро и заявлю об этом...

Второй пункт, конечно, не про всех. Как и первый. Но моя личная статистика такова.

Что делать если команда не хочет проводить Ретро? (Часть 1)

Типичное мнение скрам-мастера. "Без меня ничего не заработает".

Был у меня в универе случай. Попросили перетащить большой кондовый стол с этажа на этаж. Все тащили, а один чел, наверняка будущий скрам-мастер, бегал вокруг и типа рулил: "так, так, левее, ещё левее, теперь прямо, ага". Когда мы потные таки дотащили эту дуру до места назначения, он на полном серьёзе сказал: "ну вот видите, при грамотном руководстве всё возможно". Был послан и "в" и "на".

Что делать если команда не хочет проводить Ретро? (Часть 1)

PPS: когда я был молодым и зелёным, мне очень помогла книжка Йордана "Смертельный марш. Полное руководство для разработчика программного обеспечения по выживанию
в безнадежных проектах". Скорее всего, сейчас она покажется мне наивной и где-то даже смешной, но мне зелёному она подсветила тёмные углы всей этой ИТ-кухни и действительно помогла избежать нескольких заманчивых, но мертворождённых проектов.

Что делать если команда не хочет проводить Ретро? (Часть 1)

Менеджеров как правило не пускают на ретро, ибо есть риск, что никто не сознается в косяках.

Без менеджеров тоже никто не сознается, если что-то прокатило, никто не заметил и это не стало причиной чего-то нехорошего. Когда у человека будет следующая задача на подобную тему, он зафиксит косяк в ней и получит дополнительную звёздочку за прозорливость и неравнодушие.

Опять же, если человек увидел баальшой косяк, но было поздно, то "добровольное признание смягчает вину" и приводит к получению дополнительной звёздочки за прозорливость и неравнодушие.

Что, кстати, подразумеваете под "классическим стилем" Ретро?

Классический стиль в моём понимании - это стиль победившего менеджмента.

Надо, не надо - ретро устраивается, потому что это обязательная церемония. Потому что если мы не устроим ретро, это будет не скрам, а если это будет не скрам, то мы работаем неправильно. А если мы работаем неправильно, то это не скрам виноват (он идеален), это вы долбо^W несовершенные и вас надо подгонять под прокрустово ложе идеального скрама, где первичны церемонии, а не результат.

Обязательно будет вводное слово, потом поочерёдно четыре части: "чего мы добились", "какие проблемы поимели", "что я/мы могли бы сделать лучше", "а кто у нас скушал всю кашку и заслуживает звёздочки?". В обязательном порядке по каждому пункту будут опрошены все поимённо, по итогу в жыру упадёт документ с четырьмя колонками и прикольными картинками. Ну и финальное слово, конечно. "Советский Союз и Коммунистическая Партия сталкиваются с всё новыми и новыми вызовами, но мы, как комсомольцы и патриоты Компании, остаёмся верны делу Ленина и Партии..."

Что делать если команда не хочет проводить Ретро? (Часть 1)

А бывает так, что в команду, где сидят 20-летние патриархи, приходит свежий "масленок", и тупо боится лишний раз задать вопрос, и днями тупит на простенькими задачами.

Лично моё мнение - это его проблемы. Если человек боится задать вопрос, у него в любой сфере будут проблемы. Другое дело, когда он боится задать вопрос из-за постоянного рыка "ты что, тупой?" Но это уже крайняя стадия, и любому человеку должно быть понятно, что оттуда надо валить.

Сам я, слава яйцам, с таким не сталкивался, но моему бывшему коллеге (на тот момент уже бородатый сеньор) пришлось пройти через подобное. Команда патриархов в "возрасте дожития" устроила себе болотце а-ля Шрек и делало всё, чтобы никто в него не заходил. Непредоставление информации и игнорирование были частью стратегии по выдавливанию нежелательных элементов.

Другое дело - оговорка "ХОРОШАЯ" команда. Все команды хорошие? Все команды дорастают до хороших? И еще - все команды способны дорасти до хороших?

Есть специально выделенный человек: начальник отдела (ака тимлид). Одна из его функций - построить в команде процессы и общий климат. Если тимлид этим не занимается, любая группа хороших людей никогда не станет хорошей командой. Исключение - наличие в команде "серого кардинала", который имеет авторитет и рулит всем по-тихому, не привлекая внимания санитаров.

Чесать ЧСВ - полезно, особенно для тех, кто еще до 20-летних "помидоров" не дорос.

Зачем для этого отдельная церемония? Это делается в ревью, на дейликах и просто в прямой связи: "чувак, клёвое решение!", "Вау, третий релиз без одного бага! Продолжай в том же духе, подтягивай {технологияХ} и будем думать про перевод тебя в миддлы", ...

Правильная формула: одобрение - прилюдное, порицание - тет-а-тет.

Моменты работы над ошибками и совершенствование команды должно быть всегда. Форма - вторична.

+++++

PS: в целом не имею ничего против вашего комментария, хороший противовес моему.

Что делать если команда не хочет проводить Ретро? (Часть 1)

Ретро... Одна из наиболее бесполезных штук в рабочем процессе. Бесполезнее только сами скрам-мастеры.

"Серёженька сегодня первый скушал кашку, давайте похвалим Серёженьку, вот тебе звёздочка. А Виталик недоел салатик. Кушай лучше, Виталик, тебе тогда тоже дадут звёздочку". Буээ.

  • В любой команде все и так знают, кто как кушает.

  • Обсуждение проблем - очень полезная штука, но зачем ждать ретро? В хорошей команде это постоянный непрекращающийся процесс. Формат ретро "давайте обозначим проблемы, а потом запланируем отдельное совещание" - бредовый полностью, лишний ненужный этап.

  • Обсуждение достижений - зачем? Почесать СЧВ?

Зато для менеджера ретро это просто песня. Минус час рабочего времени, по итогу можно написать красивый отчёт "заслушали, постановили", обязательно приложить к нему прикольные картинки, которые будут выбираться ещё два часа (запись в отчёте: подготовка к ретро).

Я в разработке 20+ лет и повидал всякое. Но вот ретро в классическом "скрамном" стиле лучше бы не видел.

Можно ли считать DateTimeImmutable примитивным типом?

DTO - это набор данных, которые можно однозначно сериализовать (ок, маршализировать) на одном конце и десериализовать на другом. Никаких требований к "примитивности" нет.

Дата, время, деньги - сериализуются однозначно. Использоаать в DTO можно.

Почему интеграционная БД это отстой

  1. давайте разберём первоначальный пример: вы предлагаете делать отдельные базы под каждый способ регистрации? Если да, то как со всем этим работать? Если нет - зачем тогда это всё?

  2. Что меняется с более простым примером? Проблема просто переносится с уровня БД на уровень АПИ. И отследить её становится гораздо сложнее. Версионность АПИ может помочь, но далеко не всегда.

Я не против самодостаточных микросервисов (какими они и должны быть), но примеры в статье, мягко говоря, странные.

Почему интеграционная БД это отстой

один сервис занимается регистрацией пользователей через web, а другой регистрирует через реферальную программу

Я не понял многие доводы, но этот, имхо, где-то за гранью. Два отдельных сервиса для регистрации пользователя? Ну ок, это может быть и правильно в некоторых случаях, но тогда это должны быть эдакие "прокси-сервисы", которые тупо мапят специфику в "настоящий" сервис пользователей. Надеюсь, вы не предлагаете создавать отдельную базу под каждый способ регистрации?

Скорее всего, я просто не допёр или выпустил из текста что-то важеое..

Матрица вероятностей (рисков) и влияния управления проектов

Тема хорошая, но не рабочая, как и всё остальное, построенное на экспертных оценках. Все эксперты будут существенно завышать риски реальных проблем, вплоть до зоны "кроваво-красно, аж глаза вытекают". Проблемы из жёлтых и зелёных зон будут придумываться на ходу и не будут иметь никакого отношения к реальной ситуации.

Если вы действительно хотите управлять рисками, просто регулярно устраивайте опрос: назовите ДВЕ причины, по которым, по вашему мнению, всё в скором времени полетит в жпп.

Лазерный станок: Россия vs Китай

Есть ещё момент с эффективностью использования. Что лучше купить за те же деньги: один трактор JSB или два трактора Беларусь?

С одной стороны, JSB надёжней, удобней и производительней. С другой, двум "Белярусям" можно одновременно дать разные задачи, если один встанет на ТО, другой продолжит работать, детали Беларуси хреновенькие, но дешёвые.

Конечно, эффективность и полную стоимость владения надо считать в каждом случае отдельно, но чисто интуитивно мне больше импонирует вариант с двумя дешёвыми пепяками, вместо одной дорогой, но брендовой.

Вышел PhpStorm 2021.3

Может, кто подскажет, куда исчезла опция 'replace with import'? (Примерно как-то так называлась). Сейчас во всех случаях предлагается только 'replace with alias', что в большинстве случаев бессмысленно.

+23% к защите от депрессии

Совы в два раза чаще депрессуют!

Да потому их жаворонки своими звонками в 10 утра выбешивают.

Инженер купил 220 нерабочих плат Raspberry Pi Model B и начал их ремонтировать

Я так ровнял ножки процессорам, пока они у них были...

Отломал таки...

PHP-Дайджест № 185 (20 июля – 3 августа 2020)

Потому что автор слишком уж узко мыслит.


Валидность данных не должна зависеть от какого-то там условного ларавеля. Сегодня это только ларавел, завтра к нему добавились дотнет и питон. А послезавтра автор запушил релиз с багом в валидаторе и как наташины котики уронил вообще всё.


Уникальные и внешние ключи, NOT NULL и прочее — они не только про валидацию, они ещё и про построение модели данных, которой очень охотно пользуется оптимизатор.


Так что я на 100% согласен с предыдущем комментарием — советы очень вредные, особенно для использования в больших системах. Сначала автор не описал в СУБД модель данных, через полгода появилась необходимость создать парочку реплик базы, потому что всё тормозит, через год у вас в штате уже есть табунчик девопсов. Зато DDD и феншуй.1)


1) Феншуй в понимании его автором статьи с вредными советами.

PHP Code Style Conventions

Запрещены отрицательные логические названия
Почему? Меня лично раздражает выискивать глазами восклицательный знак и в уме инвертировать условие. Особенно, если надо в одном IF'е проверить пару условий.

Другое дело, если условия с отрицанием поддерживаются в самом языке:
if ($component->enabled()) { 
    print "OK"; 
}

unless ($component->enabled()) {
    print "Whoops";
}
тогда да, правило становится полезным.

На CES 2020 представили ноутбук Aurora 7 с семью экранами

Функция складывания пока что на стадии разработки.

JetBrains запустит новый продукт 5 декабря

Шестого декабря я напишу здесь очень важный комментарий. Не пропустите! Подписывайтесь на мой комментарий, ставьте лайки!

JSON-RPC? Возьмите хитрый REST

Да понятно, про то и речь. Автор сравнивает совершенно разные вещи и делает из этого выводы. Где-то показал сферическое преимущество, где-то умолчал о нетривиальности реализации...


Ps: в целом статья очень даже хорошая.

Информация

В рейтинге
Не участвует
Откуда
Новокузнецк, Кемеровская обл., Россия
Дата рождения
Зарегистрирован
Активность