в этой главе Филдинг методично перечисляет ограничения, с которыми приходится сталкиваться разработчику
По сути ограничения в архитектуре это соглашения и гарантии. Это не следствия, это основы. В том смысле, что если вы до чего-то договорились, то это уже нельзя нарушать и это будет вас ограничивать в возможности творить любую дичь, и заставляя соблюдать определенную дисциплину. Профит в том, что опираясь на эти соглашения вы можете строить коммуникацию с другими системами, заявившими о следовании той же архитектуре. В общем ограничения это не что-то плохое. Ограничения это фундамент, который предоставляет архитектура, и на базе которого разработчик строит свое приложение. Они же служат критериями соответствия архитектуре при анализе готового решения.
REST как архитектурный стиль штука довольно абстрактная. Он не связан с HTTP напрямую, вы можете использовать те же принципы и на базе других протоколов (даже для работы с памятью напрямую, проектируя IPC, без дополнительных слоев).
Похоже, что п. 2 оставляет большой простор для бюрократических маневров - стоит добавить пункт в какой-нибудь внутренний регламент и задача сразу перестает быть потерей. Японцы, кстати обожают придумывать правила на каждый чих, вплоть до инструкций по использованию турникета на входе.
Вообще, понять какие задачи и в какой степени добавляют ценность заказчику, проблематично как только речь заходит о любом нетривиальном процессе (т.е. таком, где результат не является простой суммой, а определяется системными эффетами). Это легко проверить, например попытавшись оценить вклад и привязать зряплату каждого работника к такой вот метрике.
А вот задачи «зарегистрировать договор», «завизировать договор», «согласовать договор с юристами» — это НЕфункциональные задачи. Мы можем продвинуться к заключению договора с клиентом и без них
А потом героически решать новые функциональные задачи, отбиваясь от контрагентов в суде, подписав непроверенный специалистами договор.
В том же сервисе вообще важнее не столько то, что ты делаете, а то как вы это делаете. Клиент платит за получаемые в процессе взаимодействия с вами эмоции или опыт.
Принцип это аксиома. Некое утверждение или правило, которое вы в своей области интересов принимаете без доказательств как само собой разумеющееся (вероятно вы его сформулировали на основе каких-то своих наблюдений, практики и т.п., обрели просветление или взяли с потолка).
Можно-ли обойтись без принципов? Скорее всего нет, если мы хотим дружить с логикой. Ведь логика формально это аксиоматическая система. Т.е. все свои утверждения можно разделить на два класса: аксиомы и теоремы. Теоремы выводятся из аксиом или других теорем. Аксиомы не выводятся ни от куда - это начала. Выделение аксиом даёт понимание структуры логики вашей деятельности, а минимизация их количества - к абстракции и упрощению.
Поэтому задача поиска принципов весьма захватывающая для исследователей в любой научной обрасти, и computer science тут не исключение. Но я согласен с автором в том, что полезность такой деятельности не особо очевидна когда речь идёт о разработке конкретной игры. Здесь нужны в основном конкретные рецепты, такие как паттерны.
Подвергать сомнениям дедовские принципы это нормально, иначе они превращаются в догмы.
Изначально SOLID возник в ходе переписки, когда ещё не было комментов на Хабре, и народ трындел в какой-то своей DLке на тему - какие у нас вообще есть принципы хорошего кода?
Сперва насобирали пару десятков. Но потом пришел Дядя Боб и набросил, что этот склад мудрости овер дофига для простого разработчика - надо быть проще и оставил пять с хвостиком.
Ну а потом, падкие на все простое и готовое, это растиражировали как будто тут истина в последней инстанции и думать здесь больше не о чем. Хвостик правда потеряли, но кого это волнует, если он ни сколько не мешает при случае с умным видом блеснуть академическими знаниями.
Со временем SOLID мутировал под влиянием разных тенденций и трактовок. Та же Барбара Лисков спустя много лет на конференции как-то отметила в духе, что ее принцип подстановки в оригинале был вообще не о том (да и не она его придумала, а в последствии коллеги наши нестыковки применительно к своей задаче и его переделали), но довольна что кого-то это смогло вдохновить.
В общем, когда у людей появляются свои мысли на тему принципов хорошего кода это норм. Как может быть иначе?
SOLID это набор принципов. ECS это паттерн. Принцип это высокоуровневая абстракция, задающая общий ход рассуждениям в процессе дизайна. Паттерн описывает конкретный способ реализации конкретной задачи в конкретном контексте. По смыслу это разные вещи.
Суммы ущерба по стране, измеряемые в ярдах, говорят о том, что телефонное мошенничество поставлено на поток и это похоже всех устраивает - и банки, и власти. Иначе бы проблему уже давно решали по существу.
Обучать, причем задорого - у IBM различные тренинги и программы сертификации это внушительная часть бизнеса, вместе с консалтом и саппортом. Решать вопросы через платную поддержку получается все равно дешевле, чем пытаться разобраться в бесконечных типа публичных мануалах, где значимые моменты могут просто отсутствовать.
Достоинства вещей являются продолжением их недостатков. PL/I это язык с объёмом знаний, который тянет на второе высшее образование. Это не может быть массовым. Для массового использования нужны простые вещи, как джаваскрипт. PL/I классно вписывается во вполне конкретную модель продаж, и непригоден для всего остального. Это не значит, что они упускают рынок. Просто для каждого рынка свой товар.
А если нет разницы, зачем платить больше?
Ну а как иначе распилить огромный бюджет, чтобы на следующий год его не порезали? Здесь нужен правильный партнёр.
IBM это корпорация - в том смысле, что у них куча подразделений, занимающих разные ниши. Есть те кто опенсорсят в условные линуксы на сишечке. И в то же время есть те, кто продолжает пилить решения для энтерпрайзов на коболах, которые они ни когда не стремились и не стремятся продвигать как масмаркет - нельзя упустить то чего нет.
Фирма IBM была не заинтересована в безвозмездном распространении языка на рабочих станциях
Бизнес модель у IBM изначально рассчитана на распил огромных бюджетов уровня оборонки, госов, банков и т.п. Переусложненность и не стандартность решений это вообще-то их конкурентное преимущество. Они не стремятся в масмаркет, программы обучения инженеров даже начального уровня по стоимости там как у космонавтов. Безвозмездное распространение языка звучит как анекдот: прикольно, но зачем? - если правильнее добавить ещё строчку в бюджет. Мне кажется СССР пропустили именно этот момент, пытаясь скопировать и массово тиражировать технологию, которая для этого вообще не была предназначена.
Здесь интересны были бы аналоги из реальной жизни. Например, с кулинарными рецептами. И почему мамины пирожки не такие как у бабушки, хотя делают вроде все одинаково: одна цель, одна задача, один рецепт с одним и тем же набором действий.
Если деплой ограничивается docker, можно на целевой машинке выставить порт dockerd наружу и указать джобе для деплоя DOCKER_HOST (технически docker это ведь тоже клиент и сервер). Плюс в том, что на минималках все это настраивается за 5 секунд. Вопросы безопасности для такого решения хорошо описаны в сети и можно городить любой огород в зависимости от ваших потребностей.
Либо, раз у вас gitlab, то можно запустить gitlab-runner на машинках куда собираетесь деплоить - он подтянет артефакты. Остальное решается скриптом для джобы в десяток строчек на bash (и gomplate если нравятся гошные шаблоны).
Ну или по классике: Ansible, Terraform и т.п.
Писать свое может быть полезно, если надо например потренировать команду, чтобы ребята лучше разобрались в нюансах предметной области или языке. Но делать законченное продакшн решение это проект и это дорого, если подходить к вопросу серьезно. Вы это ни когда не окупите. Пользуйтесь готовым.
Реакт завоевал популярность не в последнюю очередь благодаря грамотному техномаркетингу. Пока вы в каждой теме продолжаете позиционировать себя путем противопоставления всем остальным, все остальные вас закономерно будут продолжать ненавидеть).
PHP не содержал HTML как часть языка. По сути это была надстройка для интерполяции строк, где не было ни какой возможности проверить корректность результата. JSX это всё-таки немного другое, при желании он даже тайпчекается статически.
Роман с профессией: как он случается? ... образ жизни привлекает, возникает фантазия о будущей профессии.
По-моему путь к айти больше похож на дорогу в алкоголики, чем в психологи или артисты. Я имею ввиду ту часть, кто пришел в айти по любви к занятию. Ух ты, он с утра до ночи сидит за монитором с красными глазами, не знает во что одет, и не может связать пары слов когда разговор не о компьютерах - хочу быть таким же. Ну да.
Почему любимая работа не даст вам того, чего вы на самом деле от нее ждете
В теории, все будет хорошо, если не впадать в крайности. Проблемы начинаются тогда, когда она даёт этого даже больше, чем вы способны переварить без вреда для собственного здоровья и окружающих.
Проблема в том, что ReST это архитектура, а не протокол. Поэтому протокол можно сделать каким угодно, если он не противоречит её принципам и шести ограничениям. Из-за этого вероятность найти готовый инструмент под конкретные требования стремится к нулю - всегда приходится адаптировать.
Есть зоопарк из различных RFC, которые в разное время составляли под разные задачи. Попытки систематизировать и формализовать, скажем так, "web-ориентированный ReST" уже были - с четким алгоритмом в какой ситуации какой HTTP status code должен возвращаться. Например, такую работу проделали в Webmachine для Erlang, описав флоу в виде flow-диаграммы, машины состояний и тестов (мне также встречались порты для других языков). Но в массы это не пошло, а жаль - возможно мир стал бы гораздо проще.
Какого-то единообразия среди фреймворков и технологий нет. Каждый реализует протокол вмеру собственных предпочтений. Наименьший общим знаменателем становится OpenAPI (бывший Swagger). Но он определяет только формат, оставляя протокольную часть за рамками. Остальное решается на уровне соглашений, принятых в конкретной организации.
По сути ограничения в архитектуре это соглашения и гарантии. Это не следствия, это основы. В том смысле, что если вы до чего-то договорились, то это уже нельзя нарушать и это будет вас ограничивать в возможности творить любую дичь, и заставляя соблюдать определенную дисциплину. Профит в том, что опираясь на эти соглашения вы можете строить коммуникацию с другими системами, заявившими о следовании той же архитектуре. В общем ограничения это не что-то плохое. Ограничения это фундамент, который предоставляет архитектура, и на базе которого разработчик строит свое приложение. Они же служат критериями соответствия архитектуре при анализе готового решения.
REST как архитектурный стиль штука довольно абстрактная. Он не связан с HTTP напрямую, вы можете использовать те же принципы и на базе других протоколов (даже для работы с памятью напрямую, проектируя IPC, без дополнительных слоев).
В статье слишком много воды.
Цифровые дают 0.1 + 0.2 == 0.3 -> false и это не считается такой уж проблемой.
Похоже, что п. 2 оставляет большой простор для бюрократических маневров - стоит добавить пункт в какой-нибудь внутренний регламент и задача сразу перестает быть потерей. Японцы, кстати обожают придумывать правила на каждый чих, вплоть до инструкций по использованию турникета на входе.
Вообще, понять какие задачи и в какой степени добавляют ценность заказчику, проблематично как только речь заходит о любом нетривиальном процессе (т.е. таком, где результат не является простой суммой, а определяется системными эффетами). Это легко проверить, например попытавшись оценить вклад и привязать зряплату каждого работника к такой вот метрике.
А потом героически решать новые функциональные задачи, отбиваясь от контрагентов в суде, подписав непроверенный специалистами договор.
В том же сервисе вообще важнее не столько то, что ты делаете, а то как вы это делаете. Клиент платит за получаемые в процессе взаимодействия с вами эмоции или опыт.
Принцип это аксиома. Некое утверждение или правило, которое вы в своей области интересов принимаете без доказательств как само собой разумеющееся (вероятно вы его сформулировали на основе каких-то своих наблюдений, практики и т.п., обрели просветление или взяли с потолка).
Можно-ли обойтись без принципов? Скорее всего нет, если мы хотим дружить с логикой. Ведь логика формально это аксиоматическая система. Т.е. все свои утверждения можно разделить на два класса: аксиомы и теоремы. Теоремы выводятся из аксиом или других теорем. Аксиомы не выводятся ни от куда - это начала. Выделение аксиом даёт понимание структуры логики вашей деятельности, а минимизация их количества - к абстракции и упрощению.
Поэтому задача поиска принципов весьма захватывающая для исследователей в любой научной обрасти, и computer science тут не исключение. Но я согласен с автором в том, что полезность такой деятельности не особо очевидна когда речь идёт о разработке конкретной игры. Здесь нужны в основном конкретные рецепты, такие как паттерны.
Подвергать сомнениям дедовские принципы это нормально, иначе они превращаются в догмы.
Изначально SOLID возник в ходе переписки, когда ещё не было комментов на Хабре, и народ трындел в какой-то своей DLке на тему - какие у нас вообще есть принципы хорошего кода?
Сперва насобирали пару десятков. Но потом пришел Дядя Боб и набросил, что этот склад мудрости овер дофига для простого разработчика - надо быть проще и оставил пять с хвостиком.
Ну а потом, падкие на все простое и готовое, это растиражировали как будто тут истина в последней инстанции и думать здесь больше не о чем. Хвостик правда потеряли, но кого это волнует, если он ни сколько не мешает при случае с умным видом блеснуть академическими знаниями.
Со временем SOLID мутировал под влиянием разных тенденций и трактовок. Та же Барбара Лисков спустя много лет на конференции как-то отметила в духе, что ее принцип подстановки в оригинале был вообще не о том (да и не она его придумала, а в последствии коллеги наши нестыковки применительно к своей задаче и его переделали), но довольна что кого-то это смогло вдохновить.
В общем, когда у людей появляются свои мысли на тему принципов хорошего кода это норм. Как может быть иначе?
SOLID это набор принципов. ECS это паттерн. Принцип это высокоуровневая абстракция, задающая общий ход рассуждениям в процессе дизайна. Паттерн описывает конкретный способ реализации конкретной задачи в конкретном контексте. По смыслу это разные вещи.
Суммы ущерба по стране, измеряемые в ярдах, говорят о том, что телефонное мошенничество поставлено на поток и это похоже всех устраивает - и банки, и власти. Иначе бы проблему уже давно решали по существу.
Обучать, причем задорого - у IBM различные тренинги и программы сертификации это внушительная часть бизнеса, вместе с консалтом и саппортом. Решать вопросы через платную поддержку получается все равно дешевле, чем пытаться разобраться в бесконечных типа публичных мануалах, где значимые моменты могут просто отсутствовать.
Достоинства вещей являются продолжением их недостатков. PL/I это язык с объёмом знаний, который тянет на второе высшее образование. Это не может быть массовым. Для массового использования нужны простые вещи, как джаваскрипт. PL/I классно вписывается во вполне конкретную модель продаж, и непригоден для всего остального. Это не значит, что они упускают рынок. Просто для каждого рынка свой товар.
Ну а как иначе распилить огромный бюджет, чтобы на следующий год его не порезали? Здесь нужен правильный партнёр.
IBM это корпорация - в том смысле, что у них куча подразделений, занимающих разные ниши. Есть те кто опенсорсят в условные линуксы на сишечке. И в то же время есть те, кто продолжает пилить решения для энтерпрайзов на коболах, которые они ни когда не стремились и не стремятся продвигать как масмаркет - нельзя упустить то чего нет.
Бизнес модель у IBM изначально рассчитана на распил огромных бюджетов уровня оборонки, госов, банков и т.п. Переусложненность и не стандартность решений это вообще-то их конкурентное преимущество. Они не стремятся в масмаркет, программы обучения инженеров даже начального уровня по стоимости там как у космонавтов. Безвозмездное распространение языка звучит как анекдот: прикольно, но зачем? - если правильнее добавить ещё строчку в бюджет. Мне кажется СССР пропустили именно этот момент, пытаясь скопировать и массово тиражировать технологию, которая для этого вообще не была предназначена.
70% пассажиров бизнес-класса международных направлений Аэрофлота покупают билеты на черном рынке - это само по себе сильное заявление.
Здесь интересны были бы аналоги из реальной жизни. Например, с кулинарными рецептами. И почему мамины пирожки не такие как у бабушки, хотя делают вроде все одинаково: одна цель, одна задача, один рецепт с одним и тем же![]()
набором действий.
Если деплой ограничивается docker, можно на целевой машинке выставить порт dockerd наружу и указать джобе для деплоя DOCKER_HOST (технически docker это ведь тоже клиент и сервер). Плюс в том, что на минималках все это настраивается за 5 секунд. Вопросы безопасности для такого решения хорошо описаны в сети и можно городить любой огород в зависимости от ваших потребностей.
Либо, раз у вас gitlab, то можно запустить gitlab-runner на машинках куда собираетесь деплоить - он подтянет артефакты. Остальное решается скриптом для джобы в десяток строчек на bash (и gomplate если нравятся гошные шаблоны).
Ну или по классике: Ansible, Terraform и т.п.
Писать свое может быть полезно, если надо например потренировать команду, чтобы ребята лучше разобрались в нюансах предметной области или языке. Но делать законченное продакшн решение это проект и это дорого, если подходить к вопросу серьезно. Вы это ни когда не окупите. Пользуйтесь готовым.
Реакт завоевал популярность не в последнюю очередь благодаря грамотному техномаркетингу. Пока вы в каждой теме продолжаете позиционировать себя путем противопоставления всем остальным, все остальные вас закономерно будут продолжать ненавидеть).
PHP не содержал HTML как часть языка. По сути это была надстройка для интерполяции строк, где не было ни какой возможности проверить корректность результата. JSX это всё-таки немного другое, при желании он даже тайпчекается статически.
По-моему путь к айти больше похож на дорогу в алкоголики, чем в психологи или артисты. Я имею ввиду ту часть, кто пришел в айти по любви к занятию. Ух ты, он с утра до ночи сидит за монитором с красными глазами, не знает во что одет, и не может связать пары слов когда разговор не о компьютерах - хочу быть таким же. Ну да.
В теории, все будет хорошо, если не впадать в крайности. Проблемы начинаются тогда, когда она даёт этого даже больше, чем вы способны переварить без вреда для собственного здоровья и окружающих.
При обрыве соединения клиент сможет докачивать только недостающие данные или будет грузить все по новой?
Проблема в том, что ReST это архитектура, а не протокол. Поэтому протокол можно сделать каким угодно, если он не противоречит её принципам и шести ограничениям. Из-за этого вероятность найти готовый инструмент под конкретные требования стремится к нулю - всегда приходится адаптировать.
Есть зоопарк из различных RFC, которые в разное время составляли под разные задачи. Попытки систематизировать и формализовать, скажем так, "web-ориентированный ReST" уже были - с четким алгоритмом в какой ситуации какой HTTP status code должен возвращаться. Например, такую работу проделали в Webmachine для Erlang, описав флоу в виде flow-диаграммы, машины состояний и тестов (мне также встречались порты для других языков). Но в массы это не пошло, а жаль - возможно мир стал бы гораздо проще.
Какого-то единообразия среди фреймворков и технологий нет. Каждый реализует протокол вмеру собственных предпочтений. Наименьший общим знаменателем становится OpenAPI (бывший Swagger). Но он определяет только формат, оставляя протокольную часть за рамками. Остальное решается на уровне соглашений, принятых в конкретной организации.