Про protobuf как язык описания структур данных — я волне разделяю вот это мнение, мой опыт от использования очень похожий. А так же все эти приколы в духе "так, а это у нас пустой массив или отсутствующее значение? " https://reasonablypolymorphic.com/blog/protos-are-wrong/
Я всего лишь сказал, что добавление этой технологии в стек должно быть обосновано реальными потребностями, она добавляет изрядное количество заморочек. Сам факт, что какую-то технологию используют, без контекста ни о чем особо не говорит.
Я не очень понял что вы хотели сказать про генерацию. Что фронт-сервер не нужен, можно открывать наружу gRPC а пользователям отдавать сгенеренные клиенты?
Поддержку предыдущего оратора. Очевидно, что gRPC будет передавать сильно меньший лбъем данных, и сериализация там эффективная, throughput вырастет. НО плата за это велика — все начнут зависеть от протофайлов, клиенты надо будет пересобирать и дистрибьютить для юинарной совместимости, для сервисов на gRPC все равно потребуется JSON front server, который будет отдавать апишку во внешний мир. protobuf очень слабый язык данных, структурно он не соответствует тому же JSON и вам надо будет костылить много конвертация.
Это не сравнить с JSON сервисом, который можно просто прокинуть наружу, и помтучаться к нему можно накидав JSON'ку в консоли.
Кстати, JSON можно зиповать на лету, это быстро, дешево и он хорошо сжимается
Действительно, я не понял о чем вы. Лично в жизни встречался с запретами на отдельные библиотеки и конструкции языки, в принципе и на любой другой случай могу придумать разумные внешние ограничения. Но просто пример не про это — я говорил о волюнтаристских решениях менеджера, основанные на красивых графиках. Примеры взял такие, что бы они были понятны в среднем по индустрии.
Пока я был совсем юн и не имел опыта, то спрашивал "а может юниты напишем" и мне говорили "нет, времени нет, очень спешим!" Потом повезло, выпал проект, где я научился их правильно готовить, и после этого уже никого не спрашивал никогда — оказывается, с ними гораздо быстрее, чем без них.
Выскажусь про пример с юнитами. Юнит-тесты — инструмент разработчика. Не в компетенции менеджера запретить писать юнит-тесты. С тем же успехом может запрещать использовать библиотеки или анонимные функции.
Хорошая новость, т.к. Купертох node-v8-clone забросил. Но бенчмарки и тесты вы оттуда притащили бы все-таки, они очень наглядные, плюс там очень хорошее разбираение того, что можно так скоприровать, и что нельзя.
У нас тут с коллегой возник разговор, кто оптимист, а кто реалист. С одной стороны он надеялся, что использующих TDD будет побольше, я же сказал «Вау, ЦЕЛЫХ 3 человека всегда используеют TDD!». С другой — утверждает, что большая часть людей, проголосовавших за «Тестирую не по TDD», используют ручное тестирование — под отладчиком прогнали, ручками потыкали, и вперед. Я же искренне верю, что это пункт про автотестирование, просто тесты пишутся после кода, а не до.
Было бы классно разделять такие пункты на «пишу тесты, но не по TDD» и «Тестирую без автоматизации».
После ruby очень не хватало методов метапрограммирования для создания действительно гибких api. Теперь вот есть надежда, что станет веселее. Конечно, то, что сам инстанс proxy является отдельным объектом, сильно усложняет использование…
REST != CRUD. CRUD — это только паттерн управления ресурсами, а REST — это очень широкий архитектурный подход к проектирования API, который позволяет целиком перенести состояние системы в запрос.
Упоминается docker-machine — пока beta, но для дев-окружения подойдет отлично. Теперь это официальный способ запускать docker на маках, вместо boot2docker. Плюс они планируют интегрировать эту утилиту с другими компонентами.
docker-compose любопытный, подъем согласованного кластера Vagrant'ом на маке был не самым тривиальным способом, надо освоить.
Есть одна сложность с кучей модулей — найти в них можно только если знаешь, что искать. У нас в компании-то приватный npm уже разрастается достаточно, что некоторые решения «теряются», и их находят много позже, да и то — только потому, что кто-то знал про него и увидел, что в коде вместо него используется велосипед.
Я гуглю много мелочей прежде, чем костылить самому, но идея, что можно, например, использовать модуль homedir, мне просто в голову не приходила.
Вопрос навскидку. В каком отношении находятся классы «Квадрат» и «Прямоугольник»?
Не уверен, что классы «Утка» и подкласс «Утка, умеющая стрелять из ПЗРК», будут соответствовать substitution-принципу. Подкласс сможет поражать цели, что не мог бы делать родительский класс.
Тут обычно говорят «Use composition instead of inheritace».
Окей, действительно — статью прочитал не то что бы совсем по диагонали, но с купюрами — и фраза про «дизайнеры должы писать код» проскочила мимо :) И правда странное предложение. Как UX соотносится с кодом — мне не очень понятно. Задача все-таки гораздо более общая, код — очень низкоуровнево уже. Хотя техническая грамотность дизайнера, конечно, очень желательна, т.к. позволяет экономить на коммуникации.
Да ладно, при чем тут код? Достаточно взять ручку и листочек и четко сформулировать задачу, обозначить контекст, в котором это задача решается (предметная область), выдвинуть идею как решить эту задачу — в случае дизайнера — на уровне UX / UI, словами и набросками.
«Люди довольны» — с одной стороны не сильно аргумент, т.к. до сих пор живут люди, довольные Delphi и Borland C Builder :)
Все языки/платформы/фреймворки — это инструменты, имеющие свою область применения, а не самоцель. There's no silver bullet. А разработчики все же люди, у них изменяются решаемые задачи, изменяются самые технологии, и в какой-то момент они упираются в те самые рамки области применения для своего инструмента, и многие — кто с огорчением, кто с радостью — берут в руки другой инструмент. Это нормально, так работает прогресс :)
REST — это не только структура самих URL'ов, но и логика обработки запросов. По REST сервер является stateless, т.е. не хранит состояние между запросами, а все действия — атомарны и самодостаточны. Для обеспечения транзакционности сервер должен быть statefull.
Мне не очень ясно, как менеджмент API связан с протоколом сериализации? Строгую схему и контракт можно поддерживать в любом формате.
Про protobuf как язык описания структур данных — я волне разделяю вот это мнение, мой опыт от использования очень похожий. А так же все эти приколы в духе "так, а это у нас пустой массив или отсутствующее значение? " https://reasonablypolymorphic.com/blog/protos-are-wrong/
Я всего лишь сказал, что добавление этой технологии в стек должно быть обосновано реальными потребностями, она добавляет изрядное количество заморочек. Сам факт, что какую-то технологию используют, без контекста ни о чем особо не говорит.
Я не очень понял что вы хотели сказать про генерацию. Что фронт-сервер не нужен, можно открывать наружу gRPC а пользователям отдавать сгенеренные клиенты?
Поддержку предыдущего оратора. Очевидно, что gRPC будет передавать сильно меньший лбъем данных, и сериализация там эффективная, throughput вырастет. НО плата за это велика — все начнут зависеть от протофайлов, клиенты надо будет пересобирать и дистрибьютить для юинарной совместимости, для сервисов на gRPC все равно потребуется JSON front server, который будет отдавать апишку во внешний мир. protobuf очень слабый язык данных, структурно он не соответствует тому же JSON и вам надо будет костылить много конвертация.
Это не сравнить с JSON сервисом, который можно просто прокинуть наружу, и помтучаться к нему можно накидав JSON'ку в консоли.
Кстати, JSON можно зиповать на лету, это быстро, дешево и он хорошо сжимается
Про "не будут добавляться" — это хорошо известная сказка :)
Действительно, я не понял о чем вы. Лично в жизни встречался с запретами на отдельные библиотеки и конструкции языки, в принципе и на любой другой случай могу придумать разумные внешние ограничения. Но просто пример не про это — я говорил о волюнтаристских решениях менеджера, основанные на красивых графиках. Примеры взял такие, что бы они были понятны в среднем по индустрии.
Пока я был совсем юн и не имел опыта, то спрашивал "а может юниты напишем" и мне говорили "нет, времени нет, очень спешим!" Потом повезло, выпал проект, где я научился их правильно готовить, и после этого уже никого не спрашивал никогда — оказывается, с ними гораздо быстрее, чем без них.
Выскажусь про пример с юнитами. Юнит-тесты — инструмент разработчика. Не в компетенции менеджера запретить писать юнит-тесты. С тем же успехом может запрещать использовать библиотеки или анонимные функции.
Хорошая новость, т.к. Купертох
node-v8-cloneзабросил. Но бенчмарки и тесты вы оттуда притащили бы все-таки, они очень наглядные, плюс там очень хорошее разбираение того, что можно так скоприровать, и что нельзя.Было бы классно разделять такие пункты на «пишу тесты, но не по TDD» и «Тестирую без автоматизации».
docker-compose любопытный, подъем согласованного кластера Vagrant'ом на маке был не самым тривиальным способом, надо освоить.
Я гуглю много мелочей прежде, чем костылить самому, но идея, что можно, например, использовать модуль homedir, мне просто в голову не приходила.
Не уверен, что классы «Утка» и подкласс «Утка, умеющая стрелять из ПЗРК», будут соответствовать substitution-принципу. Подкласс сможет поражать цели, что не мог бы делать родительский класс.
Тут обычно говорят «Use composition instead of inheritace».
Все языки/платформы/фреймворки — это инструменты, имеющие свою область применения, а не самоцель. There's no silver bullet. А разработчики все же люди, у них изменяются решаемые задачи, изменяются самые технологии, и в какой-то момент они упираются в те самые рамки области применения для своего инструмента, и многие — кто с огорчением, кто с радостью — берут в руки другой инструмент. Это нормально, так работает прогресс :)