На простых тестах и единичных запросах все хорошо работает. Под бенчмарками с минимальной параллельностью съезжает до неприличных значений. К сожалению, в php очень дорогой вызов функции. Иногда прямо ломает лишний метод выносить, хотя было бы красиво. Я как раз приводил примеры реальной логики из реального проекта, специализированного поисковика, где нет текстовой шаблонизации и основная задача — выборка из быстрого хранилища и манипуляции хеш-массивами. По сути молотилка по формулам, которую уже некуда дальше оптимизировать. Просто описал свой опыт портирования практически один к одному. Это был первый реальный проект, который люди в теме еще и раскритиковали справедливо за расточительность в аллокациях памяти. Можно было взять железо помощнее, вынести что-то в модули, как сделал Фалкон. Или вот так вот тупо переписать. Дальше уже потихоньку втянулся, параллельно разрабатывая на php.
По поводу MVC вопрос дискуссионный. Фреймворки есть, но это немного не в стиле Go. Самый известный ORM — это, имхо https://gorm.io Лично мне такой подход к базе не нравится, но ORM таки есть. Для маршрутизации запросов хорошо зашел аскетичный https://github.com/gin-gonic/gin
Суперсила языка не во фреймворках, а возможности совместить пакеты, которые ничего друг о друге не знают, но описали требуемые интерфейсы. Если объект содержит нужный набор методов — можно подсунуть как удовлетворяющий интерфейсу. Это дает просто немыслимую свободу в проектировании отдельных кирпичей с низкой связностью. Смысла нет создавать комбайн для всего в одном флаконе — для этого есть целый гитхаб пакетов на любой вкус, зачастую взаимозаменяемых. https://github.com/avelino/awesome-go
У меня на PHP не получилось преодолеть порог 50-70 мс отклика при минимальной нагрузке или на тестах показать больше 500-600 rps. Если речь идет не о пустом скрипте. Причем обычно счастье, если удалось утрамбовать отклик в 100 миллисекунд. От безысходности начал уже модули писать на С. На моей практике с php, если идет склейка каких-то выборок из sql/redis и очередей, плюс какая-то объектная логика, в среднем по больнице получается около 150-200 мс на среднем восьмиядерном сервере. Сверху еще передача по сети и, как правило, очень заметный по времени коннект к базе, если отдельно с этим не заморачиваться.
На Go пишу всерьез уже примерно два года и сравниваю одну и ту же бизнес-логику, переписанную без оптимизаций. Реально уровень производительности веб-сервера. Приложение на go и представляет собой веб-сервер в виде самодостаточного экзешника, который сам плодит легковесные треды и загружает все ядра. Можно сделать сборку сайта, с навигацией, пользовательской сессией, выборкой контента из базы, развесистой маршрутизацией, до кучи закатать туда веб-сокеты и время генерации html будет около 5мс. Естественно, что это при умеренной нагрузке и примерно 95 перцентиль, причем будут изредка выбросы до 15-20мс и большая нагрузка может дать удвоение-утроение. Но даже 50мс при 2-3тыс. rps выглядят очень привлекательно (это тупо VDS за цену в пределах тысячи, на которой php не сможет участвовать в сравнении, потому что умрет раньше при меньшей нагрузке). Nginx можно не ставить, но обычно остается из за удобства подключения сертификатов и привычного конфигурирования, чтобы не нервировать админа.
За советскую власть не буду агитировать, т.к. с PHP еще жить долго, людей нанимать не перестанут и можно в принципе не заморачиваться, но присмотреться осторожно к другим технологиям не помешает, вдруг понравится ;) Смысла сравнивать или/или совершенно нет, т.к. современный веб можно собирать из нескольких технологий, особенно с микросервисами. Больше свободы в выборе инструментов для разных задач. Сейчас писать на компилируемом языке для веба гораздо проще и доступнее, чем во времена четвертого и пятого PHP.
Очень люблю PHP, даже несмотря на все проблемы и косяки, но после 12 лет плотной работы перешел на Go, перевел основные проекты и сейчас понимаю, насколько все было сложно и тяжеловесно. После перехода на микросервисы как-то пропал драйв писать новое на PHP. Реально не для холивара коммент, но просто вдумайтесь, без всяких оптимизаций и кешей, приложение с бизнес-логикой и селектами из базы дает отклик 3-5 мс. Можно так раскочегарить PHP? А если еще на Laravel или Zend? На Go это происходит без малейшего напряга, сохраняя объектную декомпозицию и слабую связность.
На чем вообще поднялся PHP? В 2001, задолго до эпохи VDS, были ровно две альтернативы: perl и с/с++. Причем доступен только shared-хостинг для средней компании. Допустим, если хостинг с perl еще можно было найти, то со своими экзешничками мало где можно было захоститься, если у вас нет своего сервера. И тут возникает нечто, похожее по синтаксису на C, да еще и классы/объекты какие-никакие и можно недорого "скриптик в интернете" сделать. Причем я сразу начинал на ООП писать, а народ крутил пальцем у виска, типа выпендривайся в своем С++ с объектами. Со временем как-то дозрела отрасль и до объектов :)
Сейчас ситуация принципиально иная. Есть недорого хостинг с шелом и возможностью компиляции. Казалось бы, можно и на С/С++, но есть специальный вариант компилируемого С для веба, с интерфейсами/инкапсуляцией и огромным набором библиотек (Golang). Причем понятие фреймворка в принципе чужеродно и не приветствуется. Пакеты(библиотеки) с юниксовым подходом "одну функцию делать хорошо" и возможностью совмещать несовместимое, лишь бы набор методов/аргументов совпал. В PHP, к сожалению, нужно чтобы об интерфейсах имели представление все клиенты библиотек.
Делаешь в проекте россыпь пакетов, в одном из которых сервер, отдельно cli-утилиты, отдельно общие части для повторного использования. И все это со скоростью нативного кода, как будто модуль для nginx написал.
Куча кода PHP на поддержке осталась и если ничего не делать, через пару лет это перестанет работать после обновлений (приходится следить за языком, за нюансами конфига, за поддерживаемыми модулями), в то время как экзешнику без зависимостей пофиг. У меня есть микросервис-долгожитель, написанный на Go за два дня, кропает картинки, работает полтора года без перезапуска, сколько аптайм сервера. И память пока не сожрал.
Изучать ли PHP, инвестировать ли время, писать ли новый проект — гораздо сложнее ответить на этот вопрос сейчас, чем в нулевых. Вроде и ништяков много в языке, но и альтернативы интересные появились.
Напоминает статьи про каршеринг vs своя машина. У меня прижился комбинированный вариант. Конечно, много зависит от специфики работы. Оказалось полезно для продуктивности немного менять обстановку. Иногда дома, иногда в офисе, иногда в кафешке, иногда в парке. Удачный вариант — снять небольшой офис рядом с домом в бизнес-центре, чтобы была вся инфраструктура, включая столовую. Получается также или чуть дешевле съемной квартиры для работы(раньше был такой вариант). Кругом деловая атмосфера, какое-то формальное разделение дом/работа, но остается гибкость в способах работы. В своем офисе можно принимать программистов для встреч, спокойно работать сколько надо, говорить по телефону или для разнообразия ездить на встречи, чтобы денек поработать в другом месте.
Очень спорный вопрос, надо ли менять ширину колонок. Вообще в примере достаточно уродливая, непродуманная таблица. То, что она еще ездит по ширине, добавляет уродства.
Мне кажется в принципе сложно автоматически создавать "штабелирование", чтобы это выглядело приемлемо. В классической почте письма идут строчками, но в почте айфона превращаются в красивые двустрочные блоки. Сделать это автоматом, ничего не зная о данных, очень сложно. Автор копал вообще не в том направлении.
Нормальный вариант: горизонтальная прокрутка плотной, подогнанной на основе данных таблицы. Сколько есть окна — столько есть, а сама таблица остается большой и прокручивается в узком вертикальном пространстве. Если в окне только таблица, то вообще не заморачиваться и оставить горизонтальный скролл на странице, а если надо вписать в дизайн, то
Сейчас работаю над диалоговым интерфейсом для машины, который в будущем будет расширяться до голосового. С машинкой можно просто поговорить (пока початиться).
Хочу постирать штаны
Из какого материала?
Хз
Сфоткай?
и т.д.
Полагаю для слабовидящих голосовой интерфейс решит вопрос принципиально.
Вы мыслите категориями рынка, а в плановой системе само понятие себестоимости достаточно условно. Есть понятие материалоемкость, расход драгметаллов, редкоземельных элементов, количество энергии. В деньгах не всегда возможно выразить. Продажная стоимость для населения слабо кореллировала с ценностью материалов. Даже сейчас, в якобы рыночной экономике, возможны сценарии, когда себестоимость достаточно условна, потому что важен фактический результат и выполнение планов.
Государственные деньги предприятий и деньги граждан — это были две изолированные системы. Плотину прорвало, когда легализовали нттм в восьмидесятых, фактически обналичку госденег. На чем собственно ходор сделал капитал.
Себестоимость на дефицит не влияет. Если спрос превышает предложение — вот он и дефицит. Просто мало производят, потому что приоритет в распределении исходных материалов и планы по выпуску не соотносятся с желанием купить.
Спасибо за описание реального опыта! Другими нишами не пробовали параллельно заниматься? Были идеи как-то клонировать в другие направления, автоматизировать процесс?
В офлайне примерно похожая ситуация, спрос видоизменяется, конкуренты закрываются — надо постоянно генерировать идеи, иначе загнется. Нащупал канал привлечения, выкручиваешь на максимум, параллельно ищешь новые. Одно время было очень легко сделать (онлайн)магазин запчастей на хорошем спросе, а сейчас это достаточно стремно. Все такие магазины либо закрылись, либо мутировали в новые сложные формы.
Вот эта тема со статьями — хорошая точка входа, чтобы переосмыслить саму идею подачи материалов, понять лучше людей, что их цепляет может быть перейти к созданию собственной редакции или нишевого издательства, работать с авторами и т.д. Недавно Ильяхов хорошо описал опыт создания редакции ТЖ.
Если нужно "гарантий" — прятать транзакционный движок внутри конкретного сервиса. В остальных случаях достаточно носить каску и не стоять под стрелой. Надеяться, подстраховавшись в разумных пределах. Основная проблема — удачно поделить. Если получилось, то транзакции не понадобятся, а если все же вылезли наверх составные операции, есть варианты как выйти из положения. Но все же, надо сначала поделить на кирпичи без лишних связей.
В плюсах изоляция сложности, осязаемые простые ТЗ, легкость тестирования, меньше холиваров какой движок выбрать. Можно вообще заказывать часть микросервисов на стороне.
В простонародье есть "золотое правило микросервиса" — любой микросервис можно выкинуть и переписать с нуля за 2 недели не ухудшив.
Как вытащить всех пользователей с age=23 из городов с country='RU'?
Никак. Это пример архитектуры курильщика. Еще и на мобиле часто это все пытаются через REST дергать, чтобы собрать интерфейс, по 20 запросов на экран. Сквозные данные (единый набор id, общие структуры) не должны летать между сервисами.
Микросервис — это одна конкретная функция. Нарезать картинку, упаковать файл, отправить нотификацию, вычислить маршрут, геофенсинг, посчитать рейтинг, выписать токен доступа. Легко тестировать, почти нет зависимостей, конкретные изолированные кирпичи. Функция для которой делается джойн должна быть одним сервисом — каталогом юзеров с локациями. Сложно абстрактно рассуждать. В контексте поиска — разные вертикали обсчитываются разными сервисами. Учет денег тоже должен быть внутри одного сервиса.
… где-то видел схему с «делай обратную операцию» работающую реально?
Гарантий 100% никто дать не может и бывают необратимые действия. Это надо индивидуально рассматривать. В редакторах undo реально работает и сложность там не запредельная.
Если сделать микросервисы из одной функции примитивными, вся транзакционность сильно упрощается, практически до уровня промисов js в точке склейки логики. Ключ идемпотентности больше применяется, чтобы дважды одно и то же не сделать, но и откатить при случае можно. Типа сложный трансфер прав на объект, который сопровождается дополнительным пересчетом, но это прям экзотика.
Нотификация может быть финальным шагом в логике, а может быть сразу в пачке действий, часть из которых обламывается. Не отправлять сразу, ставить в очередь с задержкой отправки, по сигналу отмены удалять. Работает вполне. По ключу потом и логи удобно вытаскивать.
Лучше кривой и косой, монолитный прототип, чем никакого. Микросервисы — это архитектурный черный пояс. Легко перейти, если получается предметную область делить на объекты. Микросервисы дают такой же эффект изоляции сложности, инкапсулируя ненужные особенности.
Если чел банально не умеет в объекты, то естественно возникает ступор. Потому что разработка и мышление на уровне "взять данные из одной библиотеки и кинуть в другую". И вот это все как раньше летало внутри "функции main", так и продолжает летать, только между отдельными сервисами, что дает тот самый ужасный распределенный монолит.
Сначала изучать ООП, научиться заворачивать и не выпускать сложность сквозь интерфейсы, научиться понижать связность внутри одного модуля, а потом уже переходить на микросервисы.
Транзакционное поведение в микросервисах делается через общую шину и ключи идемпотентности. Если облом на одном из сервисов, другие участники получают сигнал "сделай обратную операцию". Более того, действия могут быть очень разветвленными, на много экранов, если бы это было внутри хранимой процедуры. Ну а джойны с like%, это само по себе узкое место производительности и маркер костыля. А ведь можно вместо джойна кинуть запрос на десяток сервисов(например поисковый) и асинхронно склеить. Яндекс вон склеивает целую пирамиду из результатов метапоисков.
Отличная идея для проекта. Даже если бы его не было, чужие api так и просятся быть завернутыми в объекты, чтобы с помощью композиции оформлять разные виды обработок.
Как обычно мучает вопрос об открывшихся прикладных применениях. Можете, пожалуйста, в следующих сериях больше рассказать об идеях, что можно в принципе интересного делать со звуком? В применении для веба. Кроме банального перекодирования и наложения музыки фоном, в голову ничего не приходит.
Теги вложены на много уровней, а элементы блока идут "в один уровень". Это фишка БЭМа, которая все упрощает. В то же время блок является элементом другого блока за счет применения нескольких классов (миксования).
Ну ок, например есть интерфейс отрисовки "фигур", некий упрощенный кусок проекта с планировками зданий:
interface DrawShapesInterface {
public function drawCircle(int $x, int $y);
// ... прочие фигуры аналогично
}
Потом некий умник делает следующее, ведь PHP позволяет:
class SimpleDrawer implements DrawShapesInterface {
public function drawCircle(int $x, int $y, ...$args)
{
// отрисовка, которая зависит от дополнительных аргументов:
// кисти, параметры цвета и т.п.
// ведь так просто подсунуть в интерфейс еще и прицеп
}
}
Потом получается целая система умолчаний и подразумеваемых параметров, которые передаются нелегально, в обход декларации.
Возможность пропихнуть «прицеп» из необязательных параметров в любой интерфейс вообще обнуляет ценность интерфейса. Смотришь на красивую декларацию, а там на самом деле скрытые зависимости. Это недочет в дизайне движка, чтобы сохранить совместимость с пятой версией. Можно сгладить недочеты языка, если ограничивать себя и следовать строгим принципам кодописания.
В контексте собеседования — это вообще запредельное буквоедство. Если чел педант и любит строгое соответствие декларациям, но не знает, что есть совместимость методов? Экзамен в универе может и не пройдет, но для работы очень даже привлекательный персонаж.
На простых тестах и единичных запросах все хорошо работает. Под бенчмарками с минимальной параллельностью съезжает до неприличных значений. К сожалению, в php очень дорогой вызов функции. Иногда прямо ломает лишний метод выносить, хотя было бы красиво. Я как раз приводил примеры реальной логики из реального проекта, специализированного поисковика, где нет текстовой шаблонизации и основная задача — выборка из быстрого хранилища и манипуляции хеш-массивами. По сути молотилка по формулам, которую уже некуда дальше оптимизировать. Просто описал свой опыт портирования практически один к одному. Это был первый реальный проект, который люди в теме еще и раскритиковали справедливо за расточительность в аллокациях памяти. Можно было взять железо помощнее, вынести что-то в модули, как сделал Фалкон. Или вот так вот тупо переписать. Дальше уже потихоньку втянулся, параллельно разрабатывая на php.
По поводу MVC вопрос дискуссионный. Фреймворки есть, но это немного не в стиле Go. Самый известный ORM — это, имхо https://gorm.io Лично мне такой подход к базе не нравится, но ORM таки есть. Для маршрутизации запросов хорошо зашел аскетичный https://github.com/gin-gonic/gin
Суперсила языка не во фреймворках, а возможности совместить пакеты, которые ничего друг о друге не знают, но описали требуемые интерфейсы. Если объект содержит нужный набор методов — можно подсунуть как удовлетворяющий интерфейсу. Это дает просто немыслимую свободу в проектировании отдельных кирпичей с низкой связностью. Смысла нет создавать комбайн для всего в одном флаконе — для этого есть целый гитхаб пакетов на любой вкус, зачастую взаимозаменяемых. https://github.com/avelino/awesome-go
У меня на PHP не получилось преодолеть порог 50-70 мс отклика при минимальной нагрузке или на тестах показать больше 500-600 rps. Если речь идет не о пустом скрипте. Причем обычно счастье, если удалось утрамбовать отклик в 100 миллисекунд. От безысходности начал уже модули писать на С. На моей практике с php, если идет склейка каких-то выборок из sql/redis и очередей, плюс какая-то объектная логика, в среднем по больнице получается около 150-200 мс на среднем восьмиядерном сервере. Сверху еще передача по сети и, как правило, очень заметный по времени коннект к базе, если отдельно с этим не заморачиваться.
На Go пишу всерьез уже примерно два года и сравниваю одну и ту же бизнес-логику, переписанную без оптимизаций. Реально уровень производительности веб-сервера. Приложение на go и представляет собой веб-сервер в виде самодостаточного экзешника, который сам плодит легковесные треды и загружает все ядра. Можно сделать сборку сайта, с навигацией, пользовательской сессией, выборкой контента из базы, развесистой маршрутизацией, до кучи закатать туда веб-сокеты и время генерации html будет около 5мс. Естественно, что это при умеренной нагрузке и примерно 95 перцентиль, причем будут изредка выбросы до 15-20мс и большая нагрузка может дать удвоение-утроение. Но даже 50мс при 2-3тыс. rps выглядят очень привлекательно (это тупо VDS за цену в пределах тысячи, на которой php не сможет участвовать в сравнении, потому что умрет раньше при меньшей нагрузке). Nginx можно не ставить, но обычно остается из за удобства подключения сертификатов и привычного конфигурирования, чтобы не нервировать админа.
За советскую власть не буду агитировать, т.к. с PHP еще жить долго, людей нанимать не перестанут и можно в принципе не заморачиваться, но присмотреться осторожно к другим технологиям не помешает, вдруг понравится ;) Смысла сравнивать или/или совершенно нет, т.к. современный веб можно собирать из нескольких технологий, особенно с микросервисами. Больше свободы в выборе инструментов для разных задач. Сейчас писать на компилируемом языке для веба гораздо проще и доступнее, чем во времена четвертого и пятого PHP.
Очень люблю PHP, даже несмотря на все проблемы и косяки, но после 12 лет плотной работы перешел на Go, перевел основные проекты и сейчас понимаю, насколько все было сложно и тяжеловесно. После перехода на микросервисы как-то пропал драйв писать новое на PHP. Реально не для холивара коммент, но просто вдумайтесь, без всяких оптимизаций и кешей, приложение с бизнес-логикой и селектами из базы дает отклик 3-5 мс. Можно так раскочегарить PHP? А если еще на Laravel или Zend? На Go это происходит без малейшего напряга, сохраняя объектную декомпозицию и слабую связность.
На чем вообще поднялся PHP? В 2001, задолго до эпохи VDS, были ровно две альтернативы: perl и с/с++. Причем доступен только shared-хостинг для средней компании. Допустим, если хостинг с perl еще можно было найти, то со своими экзешничками мало где можно было захоститься, если у вас нет своего сервера. И тут возникает нечто, похожее по синтаксису на C, да еще и классы/объекты какие-никакие и можно недорого "скриптик в интернете" сделать. Причем я сразу начинал на ООП писать, а народ крутил пальцем у виска, типа выпендривайся в своем С++ с объектами. Со временем как-то дозрела отрасль и до объектов :)
Сейчас ситуация принципиально иная. Есть недорого хостинг с шелом и возможностью компиляции. Казалось бы, можно и на С/С++, но есть специальный вариант компилируемого С для веба, с интерфейсами/инкапсуляцией и огромным набором библиотек (Golang). Причем понятие фреймворка в принципе чужеродно и не приветствуется. Пакеты(библиотеки) с юниксовым подходом "одну функцию делать хорошо" и возможностью совмещать несовместимое, лишь бы набор методов/аргументов совпал. В PHP, к сожалению, нужно чтобы об интерфейсах имели представление все клиенты библиотек.
Делаешь в проекте россыпь пакетов, в одном из которых сервер, отдельно cli-утилиты, отдельно общие части для повторного использования. И все это со скоростью нативного кода, как будто модуль для nginx написал.
Куча кода PHP на поддержке осталась и если ничего не делать, через пару лет это перестанет работать после обновлений (приходится следить за языком, за нюансами конфига, за поддерживаемыми модулями), в то время как экзешнику без зависимостей пофиг. У меня есть микросервис-долгожитель, написанный на Go за два дня, кропает картинки, работает полтора года без перезапуска, сколько аптайм сервера. И память пока не сожрал.
Изучать ли PHP, инвестировать ли время, писать ли новый проект — гораздо сложнее ответить на этот вопрос сейчас, чем в нулевых. Вроде и ништяков много в языке, но и альтернативы интересные появились.
Напоминает статьи про каршеринг vs своя машина. У меня прижился комбинированный вариант. Конечно, много зависит от специфики работы. Оказалось полезно для продуктивности немного менять обстановку. Иногда дома, иногда в офисе, иногда в кафешке, иногда в парке. Удачный вариант — снять небольшой офис рядом с домом в бизнес-центре, чтобы была вся инфраструктура, включая столовую. Получается также или чуть дешевле съемной квартиры для работы(раньше был такой вариант). Кругом деловая атмосфера, какое-то формальное разделение дом/работа, но остается гибкость в способах работы. В своем офисе можно принимать программистов для встреч, спокойно работать сколько надо, говорить по телефону или для разнообразия ездить на встречи, чтобы денек поработать в другом месте.
Очень спорный вопрос, надо ли менять ширину колонок. Вообще в примере достаточно уродливая, непродуманная таблица. То, что она еще ездит по ширине, добавляет уродства.
Мне кажется в принципе сложно автоматически создавать "штабелирование", чтобы это выглядело приемлемо. В классической почте письма идут строчками, но в почте айфона превращаются в красивые двустрочные блоки. Сделать это автоматом, ничего не зная о данных, очень сложно. Автор копал вообще не в том направлении.
Нормальный вариант: горизонтальная прокрутка плотной, подогнанной на основе данных таблицы. Сколько есть окна — столько есть, а сама таблица остается большой и прокручивается в узком вертикальном пространстве. Если в окне только таблица, то вообще не заморачиваться и оставить горизонтальный скролл на странице, а если надо вписать в дизайн, то
Сейчас работаю над диалоговым интерфейсом для машины, который в будущем будет расширяться до голосового. С машинкой можно просто поговорить (пока початиться).
и т.д.
Полагаю для слабовидящих голосовой интерфейс решит вопрос принципиально.
Обычно стирка ночью. Закончила стирать — пусть тоже спит. В свое время целый квест прошел, чтобы отключить пиликанье после окончания.
Вы мыслите категориями рынка, а в плановой системе само понятие себестоимости достаточно условно. Есть понятие материалоемкость, расход драгметаллов, редкоземельных элементов, количество энергии. В деньгах не всегда возможно выразить. Продажная стоимость для населения слабо кореллировала с ценностью материалов. Даже сейчас, в якобы рыночной экономике, возможны сценарии, когда себестоимость достаточно условна, потому что важен фактический результат и выполнение планов.
Государственные деньги предприятий и деньги граждан — это были две изолированные системы. Плотину прорвало, когда легализовали нттм в восьмидесятых, фактически обналичку госденег. На чем собственно ходор сделал капитал.
Себестоимость на дефицит не влияет. Если спрос превышает предложение — вот он и дефицит. Просто мало производят, потому что приоритет в распределении исходных материалов и планы по выпуску не соотносятся с желанием купить.
Спасибо за описание реального опыта! Другими нишами не пробовали параллельно заниматься? Были идеи как-то клонировать в другие направления, автоматизировать процесс?
В офлайне примерно похожая ситуация, спрос видоизменяется, конкуренты закрываются — надо постоянно генерировать идеи, иначе загнется. Нащупал канал привлечения, выкручиваешь на максимум, параллельно ищешь новые. Одно время было очень легко сделать (онлайн)магазин запчастей на хорошем спросе, а сейчас это достаточно стремно. Все такие магазины либо закрылись, либо мутировали в новые сложные формы.
Вот эта тема со статьями — хорошая точка входа, чтобы переосмыслить саму идею подачи материалов, понять лучше людей, что их цепляет может быть перейти к созданию собственной редакции или нишевого издательства, работать с авторами и т.д. Недавно Ильяхов хорошо описал опыт создания редакции ТЖ.
Если нужно "гарантий" — прятать транзакционный движок внутри конкретного сервиса. В остальных случаях достаточно носить каску и не стоять под стрелой. Надеяться, подстраховавшись в разумных пределах. Основная проблема — удачно поделить. Если получилось, то транзакции не понадобятся, а если все же вылезли наверх составные операции, есть варианты как выйти из положения. Но все же, надо сначала поделить на кирпичи без лишних связей.
В плюсах изоляция сложности, осязаемые простые ТЗ, легкость тестирования, меньше холиваров какой движок выбрать. Можно вообще заказывать часть микросервисов на стороне.
В простонародье есть "золотое правило микросервиса" — любой микросервис можно выкинуть и переписать с нуля за 2 недели не ухудшив.
Никак. Это пример архитектуры курильщика. Еще и на мобиле часто это все пытаются через REST дергать, чтобы собрать интерфейс, по 20 запросов на экран. Сквозные данные (единый набор id, общие структуры) не должны летать между сервисами.
Микросервис — это одна конкретная функция. Нарезать картинку, упаковать файл, отправить нотификацию, вычислить маршрут, геофенсинг, посчитать рейтинг, выписать токен доступа. Легко тестировать, почти нет зависимостей, конкретные изолированные кирпичи. Функция для которой делается джойн должна быть одним сервисом — каталогом юзеров с локациями. Сложно абстрактно рассуждать. В контексте поиска — разные вертикали обсчитываются разными сервисами. Учет денег тоже должен быть внутри одного сервиса.
Гарантий 100% никто дать не может и бывают необратимые действия. Это надо индивидуально рассматривать. В редакторах undo реально работает и сложность там не запредельная.
Если сделать микросервисы из одной функции примитивными, вся транзакционность сильно упрощается, практически до уровня промисов js в точке склейки логики. Ключ идемпотентности больше применяется, чтобы дважды одно и то же не сделать, но и откатить при случае можно. Типа сложный трансфер прав на объект, который сопровождается дополнительным пересчетом, но это прям экзотика.
Нотификация может быть финальным шагом в логике, а может быть сразу в пачке действий, часть из которых обламывается. Не отправлять сразу, ставить в очередь с задержкой отправки, по сигналу отмены удалять. Работает вполне. По ключу потом и логи удобно вытаскивать.
Лучше кривой и косой, монолитный прототип, чем никакого. Микросервисы — это архитектурный черный пояс. Легко перейти, если получается предметную область делить на объекты. Микросервисы дают такой же эффект изоляции сложности, инкапсулируя ненужные особенности.
Если чел банально не умеет в объекты, то естественно возникает ступор. Потому что разработка и мышление на уровне "взять данные из одной библиотеки и кинуть в другую". И вот это все как раньше летало внутри "функции main", так и продолжает летать, только между отдельными сервисами, что дает тот самый ужасный распределенный монолит.
Сначала изучать ООП, научиться заворачивать и не выпускать сложность сквозь интерфейсы, научиться понижать связность внутри одного модуля, а потом уже переходить на микросервисы.
Транзакционное поведение в микросервисах делается через общую шину и ключи идемпотентности. Если облом на одном из сервисов, другие участники получают сигнал "сделай обратную операцию". Более того, действия могут быть очень разветвленными, на много экранов, если бы это было внутри хранимой процедуры. Ну а джойны с like%, это само по себе узкое место производительности и маркер костыля. А ведь можно вместо джойна кинуть запрос на десяток сервисов(например поисковый) и асинхронно склеить. Яндекс вон склеивает целую пирамиду из результатов метапоисков.
Отличная идея для проекта. Даже если бы его не было, чужие api так и просятся быть завернутыми в объекты, чтобы с помощью композиции оформлять разные виды обработок.
Как обычно мучает вопрос об открывшихся прикладных применениях. Можете, пожалуйста, в следующих сериях больше рассказать об идеях, что можно в принципе интересного делать со звуком? В применении для веба. Кроме банального перекодирования и наложения музыки фоном, в голову ничего не приходит.
Формально у вас вроде БЭМ, но по существу издевательство. Я бы предложил:
Теги вложены на много уровней, а элементы блока идут "в один уровень". Это фишка БЭМа, которая все упрощает. В то же время блок является элементом другого блока за счет применения нескольких классов (миксования).
В РФ юридически не имеют, но имеют значение для следующего особо осторожного работодателя.
атомарные?
Кто-то не подумав ляпнул про "Нигерию в снегу" и понеслась. Такого ахтунга как в статье даже в девяностые близко не было.
Ну ок, например есть интерфейс отрисовки "фигур", некий упрощенный кусок проекта с планировками зданий:
Потом некий умник делает следующее, ведь PHP позволяет:
Потом получается целая система умолчаний и подразумеваемых параметров, которые передаются нелегально, в обход декларации.
В контексте собеседования — это вообще запредельное буквоедство. Если чел педант и любит строгое соответствие декларациям, но не знает, что есть совместимость методов? Экзамен в универе может и не пройдет, но для работы очень даже привлекательный персонаж.