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