Сдается мне, что автор начал за здравие, а закончил за упокой. Зачем это сопоставление REST с CRUD? Причем здесь проблема N+1? Сервисы — это фасад, и должны им оставаться. Обслуживающий персонал. Ну надо клиенту получить много связанных данных — ну выстави ты ему агрегирующий ресурс, зачем повторять структуру домена или структуру таблиц в БД? С таким успехом сервисы на основе чего угодно можно сделать эдакой вещью в себе.
Не суть важно, на самом деле. Важно, что опыт и знания остаются релевантными при смене инструмента, и идет просто как бы натягивание инструмента на имеющийся каркас и, как следствие, довольно быстрое возвращение на прежний уровень.
Да в принципе релевантный опыт — это пересадка готового специалиста с одной платформы на смежную. Скажем, с дотнета на руби. По началу он, как собака — все понимает, но сказать не может :) А там месяц-другой, и, глядишь, уже продуктивность почти на прежнем уровне.
Важен баланс. Я бы даже иногда предпочел теоретика, который, зная как надо, быстро наработает навык, чем умельца, который со скоростью света бездумно копипастит сниппеты со StackOverflow.
Потому что таков директивный менеджмент, и в этом его ключевое отличие от servant leadership. Я бы еще обратил внимание на факт, который описывает в своей книге Чед Фаулер: если ты не рассказываешь начальству о своих успехах, начальство, как правило, не делает ничего, чтобы о них узнать. Речь здесь не идет о каком-то бахвальстве, а просто об информировании о положении дел. В эту ловушку и попал Рик — с его точки зрения он был героем, который тащил все на себе, а в глазах менеджмента оказался непонятным чудиком, замкнувшимся в кабинете и огрызающимся по каждому поводу. Наверняка в ход шли такие слова как «non-proactive», «unresponsive» и «pushback». Я предполагаю, что каждый либо уже оказывался, либо еще окажется когда-нибудь в подобной ситуации.
На самом деле отличный вопрос. На мой взгляд основных фактора тут два:
— пачка денег лежит не на столе, а в кармане, где ее никто не видит;
— как я люблю повторять, «деньги мой любимый мотиватор — он действует ровно пять минут».
Вывода напрашивается два. Если давать материальные премии по принципу сравнения сотрудников, то ущерб в целом будет, я считаю, не бОльшим — люди через некоторое время вполне могут про это забыть. Если же давать всем поровну (например, всей команде за сданный проект), то эйфория от полученных денег очень быстро улетучится, а на ее месте не останется ничего материального на память — вряд ли кто-то будет ассоциированный купленный на эту премию электрочайник с командным успехом.
Тимбилдинг тимбилдингу рознь. Я лично считаю одним из самых состоятельных представителей жанра совместное поглощение пищи. А еще лучшим — ее совместное приготовление.
Честно признаться, не помню, где я это встречал. Просто число прочно засело в голове. Мне почему-то казалось, что это было у Сазерленда, но я проверил, и у него там какие-то совсем дикие цифры: различия в командной производительности в несколько тысяч раз. Впрочем, чтобы не оставлять вам вообще без ничего, вот ссылка на блогпост Макконнелла. Соотношения там более скромные, но надо понимать, что сравнивались в основном команды примерно одного уровня квалификации.
Правдива история или нет, но вполне реалистична. На рынке спрос превышает предложение, контор как грязи, уровень разработки в них хаотический. Грубо говоря, сидит дюжина «23-летних синьоров» и выбирает, кто из них тимлид, кто СТО, а кто главный инженер проекта. Из одной такой к нам техдир на джуниора переходил. Более того, если подобная контора прикладывает усилие хоть как-то упорядочить процессы, то первое, что она делает (если, конечно, не скатывается в псевдоСкрам) — это как раз выделяет тимлидов, которые хотя бы кодинг стайл начинают блюсти.
Вообще говоря, послать можно только JSON. Соответственно, бинарные данные нужно эскейпить, например энкодить в Base64, однако нужно учитывать, что максимальный размер сообщения составляет 32Кб. Если нужно переслать действительно что-то большое, то распространенной практикой является пересылка через PubNub URL на файл где-нибудь в Amazon S3, скажем, откуда клиент уже может его выкачать. В примере в статье, кстати, от IBM Watson приходит не сам аудио-файл, а ссылка на него.
В плане вариантов использования применений масса: от банальных чатов до организации обмена сообщениями между датчиками на картофельных полях. Суть в наличии готовой инфраструктуры, которую не нужно городить самостоятельно. Естественно, если речь идет о передаче конфиденциальных данных, например, то третьестороннее решение — не самый подходящий выбор.
Пардон, сам уже с цветами запутался и вас запутал.
>>> Интерактор (розовый слой) берет эти сущности и с помощью содержащихся в них данных инициирует объекты предметной области (желтый слой), которые, в отличии от сущностей, содержат методы обработки этих данных (т.е. правила предметной области).
Конечно же зеленый контроллер берет зеленые же сущности и инициирует розовый интерактор, который уже выполняет какие-то действия (рабочий процесс) с этими данными. В случае сложной предметной области и наличия желтого слоя, интерактор создает желтые объекты бизнес-логики и отдает данные им на обработку. Таким образом зеленый слой вообще ничего не знает о наличии желтого, соответственно никак не может создавать его объекты напрямую.
В примере из книги Фаулера в итоге ничего не нарушается, если принять во внимание, что «client» — это контроллер, а получает он от репозитория те самые зеленые сущности.
— пачка денег лежит не на столе, а в кармане, где ее никто не видит;
— как я люблю повторять, «деньги мой любимый мотиватор — он действует ровно пять минут».
Вывода напрашивается два. Если давать материальные премии по принципу сравнения сотрудников, то ущерб в целом будет, я считаю, не бОльшим — люди через некоторое время вполне могут про это забыть. Если же давать всем поровну (например, всей команде за сданный проект), то эйфория от полученных денег очень быстро улетучится, а на ее месте не останется ничего материального на память — вряд ли кто-то будет ассоциированный купленный на эту премию электрочайник с командным успехом.
P.S. А забастовка — итальянская :)
В плане вариантов использования применений масса: от банальных чатов до организации обмена сообщениями между датчиками на картофельных полях. Суть в наличии готовой инфраструктуры, которую не нужно городить самостоятельно. Естественно, если речь идет о передаче конфиденциальных данных, например, то третьестороннее решение — не самый подходящий выбор.
>>> Интерактор (розовый слой) берет эти сущности и с помощью содержащихся в них данных инициирует объекты предметной области (желтый слой), которые, в отличии от сущностей, содержат методы обработки этих данных (т.е. правила предметной области).
Конечно же зеленый контроллер берет зеленые же сущности и инициирует розовый интерактор, который уже выполняет какие-то действия (рабочий процесс) с этими данными. В случае сложной предметной области и наличия желтого слоя, интерактор создает желтые объекты бизнес-логики и отдает данные им на обработку. Таким образом зеленый слой вообще ничего не знает о наличии желтого, соответственно никак не может создавать его объекты напрямую.
В примере из книги Фаулера в итоге ничего не нарушается, если принять во внимание, что «client» — это контроллер, а получает он от репозитория те самые зеленые сущности.