Отвечу на последний абзац. Задача сущности, а точнее, агрегата, оперирующего своими сущностями - соблюсти целостность и непротиворечивость данных. Плюс, конечно, обеспечить удобный интерфейс. На этом его функции заканчиваются. Если вам нужны какие-то побочные действия по результату создания заказа - киньте событие. Если другому домену оно интересно, он его поймает и сделает свою часть работы.
Вообще-то нет, mysqli не deprecated. Для меня новость, что для кого-то это новость :)
Спасибо. Видимо, это это была ложная память.
У вас какое-то странное представление о РНР
Нормальное представление, в сорцах ориентируюсь довольно свободно. Кроме поддержки utf. Лол. Три-четыре уровня макросов, пока доберёшься до кода, уже забудешь, зачем пришёл.
Я по-дефолту плюсую статьи про пхп, просто потому что сейчас процентов 80 времени пишу на нём. Но поверхностное описание сишной либы, даже если примеры даны на пхп, не делают это статьёй про пхп.
До сих пор не могу простить создателям dns'а перевёрнутый "арабский" способ написания адресов. Знаю историю, понимаю, почему они так сделали, но простить не могу. Жутко бесит.
Сказал прямо в душу. Смело могу нотариально подписаться под каждым абзацем и отвечать за это в суде.
Интересное наблюдение:
Люди, которые приходят в "большое ИТ" с производств наиболее адекватны и наиболее нацелены на результат. С ними приятно работать, они никогда не подведут. Если что-то начинает идти не так, они не будут рефлексировать, плакать в подушку и дожидаться ретро. Они просто громко заявят о проблеме.
Люди, которые попали в "большое ИТ" сразу, принимают весь этот скрам-бред как должное, они просто не видели другого. И вот с ними работать очень сложно: хнык-хнык, плак-плак, к моему мега-реквесту написали аж пять замечаний, значит, меня здесь не любят, вот дождусь ретро и заявлю об этом...
Второй пункт, конечно, не про всех. Как и первый. Но моя личная статистика такова.
Типичное мнение скрам-мастера. "Без меня ничего не заработает".
Был у меня в универе случай. Попросили перетащить большой кондовый стол с этажа на этаж. Все тащили, а один чел, наверняка будущий скрам-мастер, бегал вокруг и типа рулил: "так, так, левее, ещё левее, теперь прямо, ага". Когда мы потные таки дотащили эту дуру до места назначения, он на полном серьёзе сказал: "ну вот видите, при грамотном руководстве всё возможно". Был послан и "в" и "на".
PPS: когда я был молодым и зелёным, мне очень помогла книжка Йордана "Смертельный марш. Полное руководство для разработчика программного обеспечения по выживанию в безнадежных проектах". Скорее всего, сейчас она покажется мне наивной и где-то даже смешной, но мне зелёному она подсветила тёмные углы всей этой ИТ-кухни и действительно помогла избежать нескольких заманчивых, но мертворождённых проектов.
Менеджеров как правило не пускают на ретро, ибо есть риск, что никто не сознается в косяках.
Без менеджеров тоже никто не сознается, если что-то прокатило, никто не заметил и это не стало причиной чего-то нехорошего. Когда у человека будет следующая задача на подобную тему, он зафиксит косяк в ней и получит дополнительную звёздочку за прозорливость и неравнодушие.
Опять же, если человек увидел баальшой косяк, но было поздно, то "добровольное признание смягчает вину" и приводит к получению дополнительной звёздочки за прозорливость и неравнодушие.
Что, кстати, подразумеваете под "классическим стилем" Ретро?
Классический стиль в моём понимании - это стиль победившего менеджмента.
Надо, не надо - ретро устраивается, потому что это обязательная церемония. Потому что если мы не устроим ретро, это будет не скрам, а если это будет не скрам, то мы работаем неправильно. А если мы работаем неправильно, то это не скрам виноват (он идеален), это вы долбо^W несовершенные и вас надо подгонять под прокрустово ложе идеального скрама, где первичны церемонии, а не результат.
Обязательно будет вводное слово, потом поочерёдно четыре части: "чего мы добились", "какие проблемы поимели", "что я/мы могли бы сделать лучше", "а кто у нас скушал всю кашку и заслуживает звёздочки?". В обязательном порядке по каждому пункту будут опрошены все поимённо, по итогу в жыру упадёт документ с четырьмя колонками и прикольными картинками. Ну и финальное слово, конечно. "Советский Союз и Коммунистическая Партия сталкиваются с всё новыми и новыми вызовами, но мы, как комсомольцы и патриоты Компании, остаёмся верны делу Ленина и Партии..."
А бывает так, что в команду, где сидят 20-летние патриархи, приходит свежий "масленок", и тупо боится лишний раз задать вопрос, и днями тупит на простенькими задачами.
Лично моё мнение - это его проблемы. Если человек боится задать вопрос, у него в любой сфере будут проблемы. Другое дело, когда он боится задать вопрос из-за постоянного рыка "ты что, тупой?" Но это уже крайняя стадия, и любому человеку должно быть понятно, что оттуда надо валить.
Сам я, слава яйцам, с таким не сталкивался, но моему бывшему коллеге (на тот момент уже бородатый сеньор) пришлось пройти через подобное. Команда патриархов в "возрасте дожития" устроила себе болотце а-ля Шрек и делало всё, чтобы никто в него не заходил. Непредоставление информации и игнорирование были частью стратегии по выдавливанию нежелательных элементов.
Другое дело - оговорка "ХОРОШАЯ" команда. Все команды хорошие? Все команды дорастают до хороших? И еще - все команды способны дорасти до хороших?
Есть специально выделенный человек: начальник отдела (ака тимлид). Одна из его функций - построить в команде процессы и общий климат. Если тимлид этим не занимается, любая группа хороших людей никогда не станет хорошей командой. Исключение - наличие в команде "серого кардинала", который имеет авторитет и рулит всем по-тихому, не привлекая внимания санитаров.
Чесать ЧСВ - полезно, особенно для тех, кто еще до 20-летних "помидоров" не дорос.
Зачем для этого отдельная церемония? Это делается в ревью, на дейликах и просто в прямой связи: "чувак, клёвое решение!", "Вау, третий релиз без одного бага! Продолжай в том же духе, подтягивай {технологияХ} и будем думать про перевод тебя в миддлы", ...
Ретро... Одна из наиболее бесполезных штук в рабочем процессе. Бесполезнее только сами скрам-мастеры.
"Серёженька сегодня первый скушал кашку, давайте похвалим Серёженьку, вот тебе звёздочка. А Виталик недоел салатик. Кушай лучше, Виталик, тебе тогда тоже дадут звёздочку". Буээ.
В любой команде все и так знают, кто как кушает.
Обсуждение проблем - очень полезная штука, но зачем ждать ретро? В хорошей команде это постоянный непрекращающийся процесс. Формат ретро "давайте обозначим проблемы, а потом запланируем отдельное совещание" - бредовый полностью, лишний ненужный этап.
Обсуждение достижений - зачем? Почесать СЧВ?
Зато для менеджера ретро это просто песня. Минус час рабочего времени, по итогу можно написать красивый отчёт "заслушали, постановили", обязательно приложить к нему прикольные картинки, которые будут выбираться ещё два часа (запись в отчёте: подготовка к ретро).
Я в разработке 20+ лет и повидал всякое. Но вот ретро в классическом "скрамном" стиле лучше бы не видел.
DTO - это набор данных, которые можно однозначно сериализовать (ок, маршализировать) на одном конце и десериализовать на другом. Никаких требований к "примитивности" нет.
Дата, время, деньги - сериализуются однозначно. Использоаать в DTO можно.
давайте разберём первоначальный пример: вы предлагаете делать отдельные базы под каждый способ регистрации? Если да, то как со всем этим работать? Если нет - зачем тогда это всё?
Что меняется с более простым примером? Проблема просто переносится с уровня БД на уровень АПИ. И отследить её становится гораздо сложнее. Версионность АПИ может помочь, но далеко не всегда.
Я не против самодостаточных микросервисов (какими они и должны быть), но примеры в статье, мягко говоря, странные.
один сервис занимается регистрацией пользователей через web, а другой регистрирует через реферальную программу
Я не понял многие доводы, но этот, имхо, где-то за гранью. Два отдельных сервиса для регистрации пользователя? Ну ок, это может быть и правильно в некоторых случаях, но тогда это должны быть эдакие "прокси-сервисы", которые тупо мапят специфику в "настоящий" сервис пользователей. Надеюсь, вы не предлагаете создавать отдельную базу под каждый способ регистрации?
Скорее всего, я просто не допёр или выпустил из текста что-то важеое..
Тема хорошая, но не рабочая, как и всё остальное, построенное на экспертных оценках. Все эксперты будут существенно завышать риски реальных проблем, вплоть до зоны "кроваво-красно, аж глаза вытекают". Проблемы из жёлтых и зелёных зон будут придумываться на ходу и не будут иметь никакого отношения к реальной ситуации.
Если вы действительно хотите управлять рисками, просто регулярно устраивайте опрос: назовите ДВЕ причины, по которым, по вашему мнению, всё в скором времени полетит в жпп.
Есть ещё момент с эффективностью использования. Что лучше купить за те же деньги: один трактор JSB или два трактора Беларусь?
С одной стороны, JSB надёжней, удобней и производительней. С другой, двум "Белярусям" можно одновременно дать разные задачи, если один встанет на ТО, другой продолжит работать, детали Беларуси хреновенькие, но дешёвые.
Конечно, эффективность и полную стоимость владения надо считать в каждом случае отдельно, но чисто интуитивно мне больше импонирует вариант с двумя дешёвыми пепяками, вместо одной дорогой, но брендовой.
Может, кто подскажет, куда исчезла опция 'replace with import'? (Примерно как-то так называлась). Сейчас во всех случаях предлагается только 'replace with alias', что в большинстве случаев бессмысленно.
Где легче найти ошибку: в одном проекте или в десятке не пойми как связанных?
Отвечу на последний абзац.
Задача сущности, а точнее, агрегата, оперирующего своими сущностями - соблюсти целостность и непротиворечивость данных. Плюс, конечно, обеспечить удобный интерфейс. На этом его функции заканчиваются.
Если вам нужны какие-то побочные действия по результату создания заказа - киньте событие. Если другому домену оно интересно, он его поймает и сделает свою часть работы.
Ой, простите. Не utf, конечно.
I18N
Спасибо. Видимо, это это была ложная память.
Нормальное представление, в сорцах ориентируюсь довольно свободно. Кроме поддержки utf. Лол. Три-четыре уровня макросов, пока доберёшься до кода, уже забудешь, зачем пришёл.
mysqliразве не deprecated? Новость.Я по-дефолту плюсую статьи про пхп, просто потому что сейчас процентов 80 времени пишу на нём. Но поверхностное описание сишной либы, даже если примеры даны на пхп, не делают это статьёй про пхп.
Давайте лучше про ексепшены поговорим?
Автору:
расматриваются базовые (очень базовые) возможности курла. При чём здесь пхп?
если пхп "при чём", то где curl_multi_init? Это же чуть ли не единственный способ распарралелить однопоточный пхп без использования event loop'ов.
если пхп "при чём", то где Guzzle? Лично мне он не очень-то нравится интерфейсной частью, но архитектурно он вполне хорош. И он работает.
Вышеотписавшимся комментаторам:
каждому слою - свой эксепшен. Если на "верх" прилетает эксепшен от инфраструктуры -- у вас проблемы с архитектурой.
за сигнатуру
Response | flaseнадо изгонять из общества. Даже похапешное ядро отказывается от этого.До сих пор не могу простить создателям dns'а перевёрнутый "арабский" способ написания адресов. Знаю историю, понимаю, почему они так сделали, но простить не могу. Жутко бесит.
Сказал прямо в душу. Смело могу нотариально подписаться под каждым абзацем и отвечать за это в суде.
Интересное наблюдение:
Люди, которые приходят в "большое ИТ" с производств наиболее адекватны и наиболее нацелены на результат. С ними приятно работать, они никогда не подведут. Если что-то начинает идти не так, они не будут рефлексировать, плакать в подушку и дожидаться ретро. Они просто громко заявят о проблеме.
Люди, которые попали в "большое ИТ" сразу, принимают весь этот скрам-бред как должное, они просто не видели другого. И вот с ними работать очень сложно: хнык-хнык, плак-плак, к моему мега-реквесту написали аж пять замечаний, значит, меня здесь не любят, вот дождусь ретро и заявлю об этом...
Второй пункт, конечно, не про всех. Как и первый. Но моя личная статистика такова.
Типичное мнение скрам-мастера. "Без меня ничего не заработает".
Был у меня в универе случай. Попросили перетащить большой кондовый стол с этажа на этаж. Все тащили, а один чел, наверняка будущий скрам-мастер, бегал вокруг и типа рулил: "так, так, левее, ещё левее, теперь прямо, ага". Когда мы потные таки дотащили эту дуру до места назначения, он на полном серьёзе сказал: "ну вот видите, при грамотном руководстве всё возможно". Был послан и "в" и "на".
PPS: когда я был молодым и зелёным, мне очень помогла книжка Йордана "Смертельный марш. Полное руководство для разработчика программного обеспечения по выживанию
в безнадежных проектах". Скорее всего, сейчас она покажется мне наивной и где-то даже смешной, но мне зелёному она подсветила тёмные углы всей этой ИТ-кухни и действительно помогла избежать нескольких заманчивых, но мертворождённых проектов.
Без менеджеров тоже никто не сознается, если что-то прокатило, никто не заметил и это не стало причиной чего-то нехорошего. Когда у человека будет следующая задача на подобную тему, он зафиксит косяк в ней и получит дополнительную звёздочку за прозорливость и неравнодушие.
Опять же, если человек увидел баальшой косяк, но было поздно, то "добровольное признание смягчает вину" и приводит к получению дополнительной звёздочки за прозорливость и неравнодушие.
Классический стиль в моём понимании - это стиль победившего менеджмента.
Надо, не надо - ретро устраивается, потому что это обязательная церемония. Потому что если мы не устроим ретро, это будет не скрам, а если это будет не скрам, то мы работаем неправильно. А если мы работаем неправильно, то это не скрам виноват (он идеален), это вы долбо^W несовершенные и вас надо подгонять под прокрустово ложе идеального скрама, где первичны церемонии, а не результат.
Обязательно будет вводное слово, потом поочерёдно четыре части: "чего мы добились", "какие проблемы поимели", "что я/мы могли бы сделать лучше", "а кто у нас скушал всю кашку и заслуживает звёздочки?". В обязательном порядке по каждому пункту будут опрошены все поимённо, по итогу в жыру упадёт документ с четырьмя колонками и прикольными картинками. Ну и финальное слово, конечно. "Советский Союз и Коммунистическая Партия сталкиваются с всё новыми и новыми вызовами, но мы, как комсомольцы и патриоты Компании, остаёмся верны делу Ленина и Партии..."
Лично моё мнение - это его проблемы. Если человек боится задать вопрос, у него в любой сфере будут проблемы. Другое дело, когда он боится задать вопрос из-за постоянного рыка "ты что, тупой?" Но это уже крайняя стадия, и любому человеку должно быть понятно, что оттуда надо валить.
Сам я, слава яйцам, с таким не сталкивался, но моему бывшему коллеге (на тот момент уже бородатый сеньор) пришлось пройти через подобное. Команда патриархов в "возрасте дожития" устроила себе болотце а-ля Шрек и делало всё, чтобы никто в него не заходил. Непредоставление информации и игнорирование были частью стратегии по выдавливанию нежелательных элементов.
Есть специально выделенный человек: начальник отдела (ака тимлид). Одна из его функций - построить в команде процессы и общий климат. Если тимлид этим не занимается, любая группа хороших людей никогда не станет хорошей командой. Исключение - наличие в команде "серого кардинала", который имеет авторитет и рулит всем по-тихому, не привлекая внимания санитаров.
Зачем для этого отдельная церемония? Это делается в ревью, на дейликах и просто в прямой связи: "чувак, клёвое решение!", "Вау, третий релиз без одного бага! Продолжай в том же духе, подтягивай {технологияХ} и будем думать про перевод тебя в миддлы", ...
Правильная формула: одобрение - прилюдное, порицание - тет-а-тет.
+++++
PS: в целом не имею ничего против вашего комментария, хороший противовес моему.
Ретро... Одна из наиболее бесполезных штук в рабочем процессе. Бесполезнее только сами скрам-мастеры.
"Серёженька сегодня первый скушал кашку, давайте похвалим Серёженьку, вот тебе звёздочка. А Виталик недоел салатик. Кушай лучше, Виталик, тебе тогда тоже дадут звёздочку". Буээ.
В любой команде все и так знают, кто как кушает.
Обсуждение проблем - очень полезная штука, но зачем ждать ретро? В хорошей команде это постоянный непрекращающийся процесс. Формат ретро "давайте обозначим проблемы, а потом запланируем отдельное совещание" - бредовый полностью, лишний ненужный этап.
Обсуждение достижений - зачем? Почесать СЧВ?
Зато для менеджера ретро это просто песня. Минус час рабочего времени, по итогу можно написать красивый отчёт "заслушали, постановили", обязательно приложить к нему прикольные картинки, которые будут выбираться ещё два часа (запись в отчёте: подготовка к ретро).
Я в разработке 20+ лет и повидал всякое. Но вот ретро в классическом "скрамном" стиле лучше бы не видел.
DTO - это набор данных, которые можно однозначно сериализовать (ок, маршализировать) на одном конце и десериализовать на другом. Никаких требований к "примитивности" нет.
Дата, время, деньги - сериализуются однозначно. Использоаать в DTO можно.
давайте разберём первоначальный пример: вы предлагаете делать отдельные базы под каждый способ регистрации? Если да, то как со всем этим работать? Если нет - зачем тогда это всё?
Что меняется с более простым примером? Проблема просто переносится с уровня БД на уровень АПИ. И отследить её становится гораздо сложнее. Версионность АПИ может помочь, но далеко не всегда.
Я не против самодостаточных микросервисов (какими они и должны быть), но примеры в статье, мягко говоря, странные.
Я не понял многие доводы, но этот, имхо, где-то за гранью. Два отдельных сервиса для регистрации пользователя? Ну ок, это может быть и правильно в некоторых случаях, но тогда это должны быть эдакие "прокси-сервисы", которые тупо мапят специфику в "настоящий" сервис пользователей. Надеюсь, вы не предлагаете создавать отдельную базу под каждый способ регистрации?
Скорее всего, я просто не допёр или выпустил из текста что-то важеое..
Тема хорошая, но не рабочая, как и всё остальное, построенное на экспертных оценках. Все эксперты будут существенно завышать риски реальных проблем, вплоть до зоны "кроваво-красно, аж глаза вытекают". Проблемы из жёлтых и зелёных зон будут придумываться на ходу и не будут иметь никакого отношения к реальной ситуации.
Если вы действительно хотите управлять рисками, просто регулярно устраивайте опрос: назовите ДВЕ причины, по которым, по вашему мнению, всё в скором времени полетит в жпп.
Есть ещё момент с эффективностью использования. Что лучше купить за те же деньги: один трактор JSB или два трактора Беларусь?
С одной стороны, JSB надёжней, удобней и производительней. С другой, двум "Белярусям" можно одновременно дать разные задачи, если один встанет на ТО, другой продолжит работать, детали Беларуси хреновенькие, но дешёвые.
Конечно, эффективность и полную стоимость владения надо считать в каждом случае отдельно, но чисто интуитивно мне больше импонирует вариант с двумя дешёвыми пепяками, вместо одной дорогой, но брендовой.
Может, кто подскажет, куда исчезла опция 'replace with import'? (Примерно как-то так называлась). Сейчас во всех случаях предлагается только 'replace with alias', что в большинстве случаев бессмысленно.
Да потому их жаворонки своими звонками в 10 утра выбешивают.