Вопрос про управление состоянием. Как вы относитесь к идее состояния в саге?
Т.е. несколько серверов хранят состояние саги, доступное сервисам по ключу идемпонентности. Элементы саги могут читать все состояние как документ, но писать могут только "свой" кусок. При этом состояние помнит все свои изменения, что можно использовать для компенсации.
Привлекательность тут в следующем:
Во-первых операционно можно понять состояние транзакции просто поглядев в документ состояния в одном месте, что очень удобно.
Сервисы для хранения состояния могут масштабироваться линейно и должны обеспечивать ACID состояния саги только на время ее жизни, которое относительно короткое (максимум в большинстве случаев — дни). Ключ идемпонентности это просто полный URL для документа состояния. На запуске саги мы выбираем один из инстансов, даже балансеров не нужно.
Писать транзитивные данные в состояние предпочтительнее сохранению их в локальной базе сервиса и передаче их сообщениями, т.к. не надо заботиться о их компенсации и совместимости сервисов на уровне протокола. Грубо говоря если шаг 3 зависит от данных шага 1, а шаг 4 зависит от данных шага 2, цепочка 1-2-3-4 подразумевает либо публичное API чтобы 1-3 и 2-4 могли поговорить между собой, либо шаги 2 и 3 должны знать о данных которые нужны следующему по цепочке.
Как уже отмечалось — компенсации делать проще, если иметь лог изменений. И хранить его в документе состояния — самое оно.
Затруднения же в том, что это выглядит больше как шаг назад от "трушной" распределенности в сторону DTC. Прям подмывает последним шагом в саге сделать "а теперь запишем изменения". Наличие сервера состояния ни как не отменяет наличия шины или оркестратора. Ну и соответственно "а что будет если состояние таки потерялось".
Светофоры видимо пока останутся. Но начнут слушать траффик от автомобилей и принимать решение о переключении и назначении лидера. Грубо говоря светофор будет играть роль арбитра. Вот вам и реальная выгода от трансивера — подъехал с трансивером к светофору, он тебе включил зеленый, подъехал без трансивера — стой как лох, жди пока по таймеру переключится.
У нас скрам, но через месяц дедлайн??? Это как? Завернули итеративную разработку в фикскост и продали клиенту? Ну и м… молодцы. Я бы пожалуй ответил Бобу следующее:
Старик, я понимаю что ты на стрессе и все такое, но давай по честному, ок? Ты как опытный менеджер почуял грядущую жопу и ищешь виноватого. Слава Богу у тебя достаточно адеквата чтобы виноватым оказался ангуляр, докер, скрам, кофемашина или на худой конец не особо ценный сотрудник из линейного менеджмента. Если тебе так легче — пусть виноватыми будут скрам и я. Но даже Дон уже понимает что проблема не там. Да, мы долбоклюи. Мы начали делать итеративную разработку внутри фикскост проекта. Мы объяснили все Дону, а он сказал "да мне пофигу, как, просто пишите код". Вот тогда нам следовало объяснить Дону что у любой методологии плюсы и минусы. Что поезд хорошо держит рельсы, а мотоцикл быстро едет и хорошо поворачивает. Возить мебель на мотоцикле или устраивать гонки на поездах это хреновые идеи. И либо ему надо отразить итеративность в отношениях с заказчиком, либо нам надо не выпендриваться а расчехлить мспроджект и поставить ПМ ов на бюджет из расчёта 1 на 5 подчинённых. Но мы ничего из этого не сделали. Мы (вообще говоря вы) продали фиксированные обязательства, выкинули весь менеджмент оверхед из оценок (у нас скрам, какие менеджеры!), тем самым занизили стоимость, забили болт на трекинг (на деме поговорим, ага) и теперь ты на меня орёшь про близящийся дедлайн. Дедлайн, Боб! Это вообще слово из другой книжки! Ты врубаешься какой это долбаный цирк! А теперь позволь предложить как клоун клоуну: давай наденем взрослые штаны и начнём решать проблему конструктивно. А почему черт подери мы не можем двинуть этот хренов дедлайн?
Шумит редутор, причем довольно мерзко. С отключенным пылесосом и сопутствующими шестернями слышно на весь этаж (чертов опенспейс).
Автономная зарядка (еще один довод был в пользу румбовой платформы) — это док станция с маяком. Достаточно подрулить к доку и дать команду заряжаться. Робот сам разворачивается к маяку, попадает на контакты (три раза пытается). С учетом того, что попасть туда у него получается не всегда даже с трех попыток, видимо это не так просто как кажется. Для коммуникационного бота это актуально, т.к. там планшет который часто со включенным экраном и звуком. Подзаряжать прийдется часто.
Источником вдохновения был хак Джонни Чанга (http://procrastineering.blogspot.com/2011/02/low-cost-video-chat-robot.html). Он использовал док станцию с двумя здоровыми контактными пластинами, на которые выведено 110 вольт. Очевидно не совсем годная для офиса конструкция. Можно, разумеется, вместо сети выводить туда сразу постоянные 5В 2А и напрямую заряжать планшет, но контакт будет плохой и зарядка нестабильной. В общем я забросил это дело до лучших времен, пока ваш пост не навеял...
У меня была задумка собрать telepresence робота, чтобы не мотаться в офис лишний раз. Все, к сожалению, уперлось в неудачный выбор платформы. У меня под рукой в тот момент была только румба (которая, кстати, довольно неплохо справляется с тем, чтобы нести "вешалку" с планшетом), плюс там есть возможность запитаться от выводов на пылесос. Но потом выяснилось, что она больно шумная и раздражает людей, так что пришлось отказаться от затеи. Как с шумностью у вашей платформы? Не попадалось ли вам вариантов автономной зарядки?
Хмм… А почему много первых разов это обязательно плохо? Эта потребность в чем-то чего-то добиться, на самом деле (по крайней мере у меня) просто тщеславие. Она от лукавого.
Я вот serial hobbyist, например. Я пробую разные штуки не для того, чтобы стать самым крутым гончаром в округе, собрать самый большой 3Д принтер в городе и выиграть тур-де-франс, а чтобы получить опыт и ощущения.
Смысл? В большинстве случаев "начать" просто и дешево — удовольствие, а вот каждый день улучшаться в чем-то — вложения и труд, частенько, кстати, напрасный.
20% затрат как правило 80% результата. Забей на оставшиеся 20%. Вместо них ты можешь получить еще 4 раза по 80% чего-нибудь другого. Это ж офигенно!
Я стесняюсь указать на слоника притаившегося в комнате, но…
Во-первых ORM в большинстве своем это таки DSL (domain specific language, где предметной областью является C(Q)RUD). То, что семантика распихана по нескольким файликам, часть из которых на привычном ОО-языке, не более чем попытка не слишком пугать программиста. Тот же Hibernate нормально преобразует все эти удобства в весьма формальную модель и генерит кучу байткода на лету, существенно не отличаясь от DSL компилятора.
Во-вторых SQL как бы не работает с любой произвольной структурой данных. Как минимум требуется (даже логически) первая степень нормализации, чтобы можно было вообще произносить слово "таблица", а для слова "ключ", в его нормальном понимании, хорошо бы иметь как минимум вторую. Упомянутые вами Splunk и Lucene как раз специфические языки и придумывают от того, что "поток частично структурированных сообщений" и "некоторое количество коллекций гетерогенных слабо-структурированных документов" несколько не ложатся на любимые всеми таблички.
В общем не надо бояться языков, тем более что большинство из DSL-ей простые как дрова. Если вы справились с SQL, маппингом в ОО, транзакциями через аспекты и реляционной алгеброй, все вариации на тему "100500 способов описать логический фильтр" для вас проблем не составят.
Автоматизация — это отлично. В остальном мы пошли по другому пути. Можно сказать в обратном направлении. Выглядит это так.
Код ревью занимает столько, сколько занимает и "ускорить" его нельзя. Тестировщиков у нас как таковых нет. Доказательность того, что все работает — это один из аспектов ревью. Хотите — читайте код, хотите — предъявляйте тесты, хотите — шагайте через код дебагером. Ваша задача убедить ревьювера, а он будет упираться. Почему? Потому что, за вынос в прод отвечает не автор, а ревьювер. Если вы напороли, разбираться будете вдвоем, но ответственность именно на ревьювере. Это чтобы народ серьезнее к этому процессу относился а не глянул по диагонали, тесты проходят — и +2. Как результат ревью по три десятка итераций вполне норма.
А как сделать так, чтобы ревью не уходило в бесконечность? На то есть менеджеры. У них есть право и обязанность любыми доступными методами, кроме запрещенных в code of conduct, тянуть разработчиков в сторону закрытия историй. У нас это специальные барышни, которые отвечают за набор историй. Сейчас конкретно их две на наш отдел в 30 человек. Могут три раза на дню прийти поспрашивать как дела и что держит. Могут попросить назначить другого ревьювера и т.д. Если ревьювер и автор уперлись, могут пригласить третьего в качестве арбитра. Если застряли на координации, будут носиться между командами и сводить концы. Если что-то поменялось будут обновлять истории и доносить это до инженеров. Это их работа, главным образом персонально-коммуникационная, и справляются они с ней на ура. Опять же не из альтруистических соображений — если ревью зависло на месяц, есть шанс что всю фичу зарубят как невыполнимую и снесут в бэклог. Им тогда объясняться с кучей народа, в том числе директорами и спонсорами. И OKR могут посыпаться.
Кстати, подчиненных инженеров у барышень нет и начальством они формально тоже не являются (разве только между собой). Это для того, чтобы они обслуживали процесс а не рулили им. В противном случае будет "сделай как я говорю или премия минус".
В целом работать намного комфортнее чем в конторе с кучей мотивационных метрик (я и там был в свое время), а впечатление очень положительное. Когда у вас "ревью в 24 часа" и "история в день", фокус неизбежно сползает с работы на удовлетворение системы или ее надувательство. Конкретно пример из "метрической" конторы (каюсь): иногда если ревью сложное, а мне надо еще кучу всего сделать, я его просто рубил его "за несоответствие требованиям", благо всегда можно прицепиться. Автор понимал что я в зашиве и возвращал историю продакту. Они всегда перегружены, так что пару дней есть пока они доберутся. Потому 10 минутный митинг с чтением истории вслух, уточнение одного предложения, подъем ревью, а у меня уже было время код почитать. Так погоняешь ревью кругами — у всех метрики на ура, коллаборация претъ, все счастливы. Только сплошная Кафка какая-то, причем я не про технологию.
Тоже думаем уходить от ORM-a из-за трудностей с динамической схемой. Фактически планируем создавать записи хранящие JSON + некоторое количество полей по которым ведется связывание и выборки (вычисляются на основе самого объекта который храним). NoSQL использовать не можем из-за регуляций. Пока прототип выглядит очень достойно в плане использования (код контроллеров сильно похудел, много boilerplate code вроде PUT, PATCH, валидации и прочего ушло из контроллеров) и производительности (для сильно связанных данных, которые были разнесены по десятку таблиц из-за нормализации, разница в десятки раз, главным образом из-за отсутствия дорогих джойнов).
Кто так пробовал делать, какие подводные камни?
Относительно JSON, очень хотелось бы хранить данные в BSON (с упаковкой). Много не-текста в схеме.
Камни может и стереотипные, но, по моему опыту, весьма заслуженные. Я говорю о том, что процесс разработки интерфейса стал из двунаправленного односторонним, и реализация (а иногда и функция) сейчас часто вторична по отношению к дизайну. Торг за требования — это часть работы архитектора, передача дизайна в разработку — это передача (и прием) ответственности. Теперь же мне приходится очень часто беседовать на повышенных тонах с дизайнерами и менеджерами по поводу целесообразности очередного решения. И, как правило, убедить кого-то можно только угрожая увеличением бюджета, потому что технические детали не интересны, а "на вебе можно все". Может просто я стал старый и сварливый?
Разделяю ваши фрустрации! Но, боюсь, срыва покровов не произошло:
В мире веб-программирования считается хорошим тоном блуждать в трех соснах, которые называются M, V и C
Вот в них-то и проблема, и изящно избавиться от "M" и "C" вашим методом не выйдет. Во-первых "M" на бэк-енде и "M" на клиенте малость разные от слова совсем. "M" клиента обычно обрастает состояниями, про которые бэк-енд понятия не имеет. "C" не тождественно браузеру уже лет пятнадцать, с тех пор как появился AJAX и асинхронность. А вот с "V" который всем так интересен как раз все теперь относительно хорошо, по крайней мере не так плохо как на десктопе.
С моей точки зрения проблемы совсем не в экосистеме, а в архитектуре, которая ее породила:
Где состояние, Зин? Изначально браузер (да и весь интернет) был документ-ориентированным, состояние жило на сервере, клиент был предельно тупым. Потом мир малость поменялся, и сейчас у нас stateless backend (потому что масштабирование) и stateful client (потому что пользователь так хочет). А обработка и данные по прежнему удаленные. Из-за этого нам приходится решать кучку нетривиальных задач по управлению всем этим хозяйством (распределенное состояние, асинхрон, безопасность и т.д).
Где у этого мозги? Раньше мы обычно "говорили" с одним сервером и могли, хоть и с натяжкой, думать об этом как об RPC, можно было (с оговорками) считать сервер источником правды, рассуждать про границы транзакций, какие-то операционные контракты и т.д. Теперь работать с кучей гетерогенных сервисов, половина которых вообще не наши и в лучшем случае eventually consistent — скорее норма чем исключение. В такой ситуации источник правды переехал на клиента, равно как и добрая половина бизнес-логики, хотите вы в этом себе признаваться или нет. Так что мозги теперь повсюду.
Один как Леонид Ильич МакЛауд. У веб приложений практически нет реальных альтернатив, т.к. только они позволяют начать взаимодействовать с пользователем без установки, консента и работают более-менее везде предсказуемо. Был шанс что мобильные устройства развернут ситуацию, но победила жадность, которая родила аппстор и устроила сегрегацию. Заменой веба им теперь не быть. Это сместило фокус в сторону веб-разработки с прицелом делать десктопный UX, что как раз породило весь зоопарк уродов. И толпы программистов которые умеют только веб программирование. Так что теперь у нас будут веб программы на десктопе. И вот я скрепя зубами следующий десктопный проект уже делаю с Electron, потому что Xamarin-а комманда не знает.
Декларативное против императивного. Веб раньше был декларативным (потому как был заточен под документы, см выше). И хочет им остаться как можно дольше в силу традиции. Может быть если бы когда-то давно люди забили на HTML+CSS и начали бы манипулировать SVG из JS, мы бы сейчас жили в другой реальности (с компонентной моделью близкой к десктопной). Но, по состоянию на сегодня, layout в коде не одобрен институтом кашрута, а ведический HTML+CSS — очень даже одобрен. Но, увы, у декларативного синтаксиса есть свои пределы, в то время как у фантазии UX дизайнеров похоже нет. В итоге без фреймворка и тулчейнов вроде вебпака запилить что-то с профессиональным качеством весьма трудоемкая задача.
А если честно, то есть еще Power-point driven development. Вот это пожалуй и есть объективный корень всего зла. Мой первый опыт веб-программирования был в 2000-м. Мы обсуждали штуки вроде "визуальный язык", "метафоры управления", "поведение элементов", "доступность данных", "стандартные представления", "control flow/data flow" и т.д. Было много торга с дизайнерами за выразительность против универсальности, и это был спор в духе Сократа. Что было необходимо, т.к. компоненты приходилось писать и поддерживать самостоятельно. Сейчас я этого практически не вижу. Если что-то вышло из UX специалиста (чаще в формате PPT или PSD, с описанием в духе "новый дизайн!!!"), обратно это можно запихнуть только со слезами и насилием над личностью последнего (он же ж нарисовал и уже согласовал, и вообще чем нам не угодил pivot table с аггрегацией по 10MM записей, эксель же тянет). А потом еще начнется A/B тестирование, с двумя версиями интерфейса в параллель, потому что эта хитрая жопа не хочет брать на себя ответственность за свои решения. Не, я не против. Если у меня бюджет будет как в Амазоне и Нетфликсе — за ваши деньги любой каприз, а так…
Я к чему… Это больше не поле деятельности инженеров, тут правят дизайнеры и частенько маркетинг, а им чаще всего плевать как все работает, откуда берутся данные, как они вяжутся к интерфейсу, что повторно используется и т.д. Что, в свою очередь пораждает любовь к абстракциям и фремворкам, потому что собственно свой код все равно выраждается в адову копипасту со временем, а душа не терпит посредственности.
Прошу прощения за простыню, сегодня грустный вечер ;-)
потому что так у них повелось. См про качество этого процесса в том же параграфе.
перед каким финалом
pull request / git workflow. Ревью делаются на PR.
полукилометровые из-за одной буквы m
нет, из-за naming conventions у компонентов и методов. Типа PublicCampaignAnalyticsEventTransitiveViewFactory::analyticsEventCreationTimestamp. Это в общем из той же оперы.
Автор оригинальной статьи, вероятно, как и положено сеньору в Гугеле, проводит больше времени в Gerrit, чем в IDE. А там как раз будет дифф без подсветки и прочего. А тащить ветку локально чтобы посмотреть на нее через IDE это слишком много телодвижений для уважаемого человека.
Слуга ваш покорный пострадал на прошлой работе в попытках аргументированно объяснить, что код пишет 50 человек и каждый день, а ревью делают 4 и только перед финалом. И исходя из этого раскладывать компонент по 6 местам и фигачить полукилометровые имена с префиксами несколько иррационально. Тем более что за 12 месяцев ни каких замечаний от оных уважаемых людей, кроме соответствия гайдлайнам, я не видел. На что получил вполне ожидаемый ответ — мы есмь четыре всадника апокалипсиса, покайсо холоп и убойся гнева нашего. На том и разошлись. ;-)
Гибкая она, только если знать где гнуть. Скрам это контракт (как программный интерфейс) между тремя сторонами — ПМ, Заказчиком и Инженерами. Реализация этого контракта зависит от много чего. Как и в программировании — хорошее API может быть плохо реализовано. На тренингах этому, к сожалению, этому не учат, а занимаются разбором этого самого интерфейса. Пообщайтесь с кем-то у кого скрам работает — взглянете на это по-другому. Если хотите — спрашивайте в личку.
…
И тогда угрюмые сибирские мужики сунули под бензопилу стальной лом.
"Хрррр" — сказала бензопила и поломалась.
"А-а-г-аааа! То-то!" — возопили угрюмые сибирские мужики и пошли валить лес двуручными пилами.
Есть на планете много несчастных, которые вынуждены корячиться с mingw, cygwin, VcServ/XMing, Hyper-V+Boot-to-Docker и т.д. Вот майки наконец вняли стенаниям горемык и вместо кучи костылей сделали… свой собственный костыль. Хорошо ли оно будет работать и долго ли будет поддерживаться — это отдельный вопрос, но за смелую попытку — честь и хвала, я считаю.
"Кто эти несчастные?" — спросите вы. Добро пожаловать в чудаковатый мир корпораций. У нас весь прод на открытых технологиях, но при поступлении на работу всем выдают lenovo thinkpad с предустановленной десяткой. IT отвечает только за вин, и только за 10, и все, потому что их десять человек а нас несколько сотен, и обслуживать зоопарк никсов и маков им совсем не хочется. Поэтому у меня крутится пяток контейнеров под hyper-v, один из которых дев среда с X11.Отдельные горячие головы поставили себе убунту и подписали waver что берут на себя всю ответственность, но таких единицы.
JSON лично меня устраивает — кавычки, комментарии и типы данных — это нужно не на уровне формата кодирования данных, а на уровне схемы. А вот то, что JSON schema, похоже, не взлетела очень печалит. Если бы она была так же популярна как JSON, заниматься придумыванием 100500 улучшений формата было бы не нужно.
Ну если уж совсем по торе, то с докером желательно менять жизненный цикл софта. И в этом-то на самом деле вся прелесть. Вы релизите не jar/war/dll и кучку конфигов, а как раз целиком образ. Т.е. не важно что вы там поменяли — пропатчили что-то в системе, добавили фичу, починили баг в коде или поменяли конфигурацию. Все равно это новый билд, новая версия образа, тестирование этого образа в стейдже и вывод этого образа в прод (как правило параллельным деплойментом с переключением на уровне балансера, например). Почему так? Потому что для конечного потребителя не важна суть изменений, которые вы внесли на конкретной итерации. Важно чтобы все работало не хуже чем до обновления. И контейнеризация как раз помогает это обеспечить. И откатываться надо уметь не только после кривого кода, но и после кривых обновлений сторонных зависимостей (т.е. и ОС). А после последних, пожалуй, даже чаще.
Более конкретно, в mvn, например, есть плагин для сборки и публикации образов в докере, Т.е. ваша история будет выглядеть так: вы пропатчили базовый имидж (или в Dockerfile прописали, или ручками закоммитили изменения, или тем же паппетом накатили), запустили обычный билд, билд нагенерил вам образов для контейнеров (он это делает довольно шустро за счет кеширования, так что собрать сотню образов может быть сравнимо с копированием файлов по сетке). Дальше ваш QA позапускал контейнеры (фактически 1 к 1 конфигурация вашего продакшена, может быть с меньшей избыточностью), прогнал автотесты, подтвердил что все работает. После этого те, кто у вас занимается релизами, взяли те же образы, подменили в продакшене одни контейнеры другими и все побежало дальше.
Менеджмент конфигурации тоже становится малость другим. У четких пацанов уже давно конфиг = код. А значит очень хочется чтобы конфиги на продакшене = конфиги в стейджинге = конфиги у девелопера (здесь = бинарное). Все вариации в топологии за счет DNS, вся авторизация между сервисами — по сертификатам. Если уж совсем никак — то через параметры у контейнера или разделяемые тома. Чтобы различий между средами не было вообще.
У нас тоже долго путались с концепциями, надо сказать у докера не очень удачная терминология, и от того много недопониманий. Не думайте про контейнеры как про виртуалки. Контейнеры ни кто никогда не патчит, не перезапускает, и даже ssh-ем в них не лазает. Это как "суперпроцесс", который крутится со своим изолированным окружением. Остановился — умер. Можно унести труп в лабу и там поковыряться, если уж очень нужно поискать причины сбоя, но оживлять его и возвращать в строй его уже ни кто не будет.
А вот про безопасность самого докера — это справедливо. Технология молодая, и грабли будут. Но те же разговоры были и про виртуализацию, если память мне не врет.
Да, вы правы… Все держится на энтузиастах. Сейчас носятся с идеей outcome-based медицины, при которой врача компенсируют за здоровых пациентов. Т.е. за процедуры он получает сравнительно мало, а за успешное лечение — большой бонус. Такое в Англии, например, делают с терапевтами. Бонус в год может быть порядка $93K для терапевта с 1,800 приписанными пациентами. Может там заживет?.. А в штатах пока, к сожалению, от outcome-based бегут как от огня…
Пару месяцев назад делал оценку стартапа, который занимается как раз телемониторингом пожилых пациентов через носимое оборудование. По итогам оценки стартап убили, несмотря на то, что у него были клиенты (дома престарелых), 10 летняя история и в общей сложности около 1000 девайсов в пользовании. Проблема как раз не в том, чтобы собрать данные — это относительно просто. И альянс уже есть по ZigBee и Bluetooth для медицинских устройств, и сервис-агрегатор, и аналитическая платформа, да еще и не одна.
Проблема как всегда в людях. Данные собираются, аналитика считается. Но. Никому. Это. Не. Надо. Как выясняется. Пациенты, конечно, счастливы — бабушки боятся встать с кровати без этих часов, сильно к ним привыкают. Но медсестрам пофигу. Им важен только fall detection, и мониторинг по зонам (не застрял ли пациент в туалете). Вся телеметрия им по барабану. Геронтологу это вообще все в пику, зачем ему смотреть на данные, если можно заставить его приезжать два раза в неделю, по $300 за визит и тесты? Терапевту это все пофигу в квадрате. Какая разница, активен пациент или нет. Жалобы спросил, давление померял, ответственность с себя снял. Досвидос. Родственникам тоже пофигу, в большинстве случаев. Тем кому старики нужны, не сдают их в дома престарелых. Госпиталям в IT тоже пофигу, потому что у них EMR система и 100500 индусов которые вокруг нее бегают и крутят HL7 так, чтобы она была вообще не совместима ни с чем кроме самой себя. Дополнительная интеграционная точка — это десятки тысяч баксов их драгоценного времени ежегодно. Страховым тоже пофигу, кода на услугу нет, возврата нет, пропихнуть его туда можно только в новой редакции кодов услуг, а мед. учреждения еще предыдущий стандарт ввести не смогли. Это еще лет 5-10, не меньше.
Поэтому носимые штуки это здорово, но медицина с точки зрения технологий, по крайней мере в USA — это адское болото. На каждого 1 человека, которому что-то надо есть 1000 человек которым ничего не надо, кроме job security ;-(
Второй проект которым мы занимаемся — система записи для эндоскопов — много лучше, т.к. драйвится докторами (в основателях очень уважаемый в индустрии человек). А с телеметрией пока таких энтузиастов не видно. ;-\
Вопрос про управление состоянием. Как вы относитесь к идее состояния в саге?
Т.е. несколько серверов хранят состояние саги, доступное сервисам по ключу идемпонентности. Элементы саги могут читать все состояние как документ, но писать могут только "свой" кусок. При этом состояние помнит все свои изменения, что можно использовать для компенсации.
Привлекательность тут в следующем:
Затруднения же в том, что это выглядит больше как шаг назад от "трушной" распределенности в сторону DTC. Прям подмывает последним шагом в саге сделать "а теперь запишем изменения". Наличие сервера состояния ни как не отменяет наличия шины или оркестратора. Ну и соответственно "а что будет если состояние таки потерялось".
Светофоры видимо пока останутся. Но начнут слушать траффик от автомобилей и принимать решение о переключении и назначении лидера. Грубо говоря светофор будет играть роль арбитра. Вот вам и реальная выгода от трансивера — подъехал с трансивером к светофору, он тебе включил зеленый, подъехал без трансивера — стой как лох, жди пока по таймеру переключится.
У нас скрам, но через месяц дедлайн??? Это как? Завернули итеративную разработку в фикскост и продали клиенту? Ну и м… молодцы. Я бы пожалуй ответил Бобу следующее:
Шумит редутор, причем довольно мерзко. С отключенным пылесосом и сопутствующими шестернями слышно на весь этаж (чертов опенспейс).
Автономная зарядка (еще один довод был в пользу румбовой платформы) — это док станция с маяком. Достаточно подрулить к доку и дать команду заряжаться. Робот сам разворачивается к маяку, попадает на контакты (три раза пытается). С учетом того, что попасть туда у него получается не всегда даже с трех попыток, видимо это не так просто как кажется. Для коммуникационного бота это актуально, т.к. там планшет который часто со включенным экраном и звуком. Подзаряжать прийдется часто.
Источником вдохновения был хак Джонни Чанга (http://procrastineering.blogspot.com/2011/02/low-cost-video-chat-robot.html). Он использовал док станцию с двумя здоровыми контактными пластинами, на которые выведено 110 вольт. Очевидно не совсем годная для офиса конструкция. Можно, разумеется, вместо сети выводить туда сразу постоянные 5В 2А и напрямую заряжать планшет, но контакт будет плохой и зарядка нестабильной. В общем я забросил это дело до лучших времен, пока ваш пост не навеял...
Спасибо за пост и исходники.
У меня была задумка собрать telepresence робота, чтобы не мотаться в офис лишний раз. Все, к сожалению, уперлось в неудачный выбор платформы. У меня под рукой в тот момент была только румба (которая, кстати, довольно неплохо справляется с тем, чтобы нести "вешалку" с планшетом), плюс там есть возможность запитаться от выводов на пылесос. Но потом выяснилось, что она больно шумная и раздражает людей, так что пришлось отказаться от затеи. Как с шумностью у вашей платформы? Не попадалось ли вам вариантов автономной зарядки?
Хмм… А почему много первых разов это обязательно плохо? Эта потребность в чем-то чего-то добиться, на самом деле (по крайней мере у меня) просто тщеславие. Она от лукавого.
Я вот serial hobbyist, например. Я пробую разные штуки не для того, чтобы стать самым крутым гончаром в округе, собрать самый большой 3Д принтер в городе и выиграть тур-де-франс, а чтобы получить опыт и ощущения.
Смысл? В большинстве случаев "начать" просто и дешево — удовольствие, а вот каждый день улучшаться в чем-то — вложения и труд, частенько, кстати, напрасный.
20% затрат как правило 80% результата. Забей на оставшиеся 20%. Вместо них ты можешь получить еще 4 раза по 80% чего-нибудь другого. Это ж офигенно!
Я стесняюсь указать на слоника притаившегося в комнате, но…
Во-первых ORM в большинстве своем это таки DSL (domain specific language, где предметной областью является C(Q)RUD). То, что семантика распихана по нескольким файликам, часть из которых на привычном ОО-языке, не более чем попытка не слишком пугать программиста. Тот же Hibernate нормально преобразует все эти удобства в весьма формальную модель и генерит кучу байткода на лету, существенно не отличаясь от DSL компилятора.
Во-вторых SQL как бы не работает с любой произвольной структурой данных. Как минимум требуется (даже логически) первая степень нормализации, чтобы можно было вообще произносить слово "таблица", а для слова "ключ", в его нормальном понимании, хорошо бы иметь как минимум вторую. Упомянутые вами Splunk и Lucene как раз специфические языки и придумывают от того, что "поток частично структурированных сообщений" и "некоторое количество коллекций гетерогенных слабо-структурированных документов" несколько не ложатся на любимые всеми таблички.
В общем не надо бояться языков, тем более что большинство из DSL-ей простые как дрова. Если вы справились с SQL, маппингом в ОО, транзакциями через аспекты и реляционной алгеброй, все вариации на тему "100500 способов описать логический фильтр" для вас проблем не составят.
Автоматизация — это отлично. В остальном мы пошли по другому пути. Можно сказать в обратном направлении. Выглядит это так.
Код ревью занимает столько, сколько занимает и "ускорить" его нельзя. Тестировщиков у нас как таковых нет. Доказательность того, что все работает — это один из аспектов ревью. Хотите — читайте код, хотите — предъявляйте тесты, хотите — шагайте через код дебагером. Ваша задача убедить ревьювера, а он будет упираться. Почему? Потому что, за вынос в прод отвечает не автор, а ревьювер. Если вы напороли, разбираться будете вдвоем, но ответственность именно на ревьювере. Это чтобы народ серьезнее к этому процессу относился а не глянул по диагонали, тесты проходят — и +2. Как результат ревью по три десятка итераций вполне норма.
А как сделать так, чтобы ревью не уходило в бесконечность? На то есть менеджеры. У них есть право и обязанность любыми доступными методами, кроме запрещенных в code of conduct, тянуть разработчиков в сторону закрытия историй. У нас это специальные барышни, которые отвечают за набор историй. Сейчас конкретно их две на наш отдел в 30 человек. Могут три раза на дню прийти поспрашивать как дела и что держит. Могут попросить назначить другого ревьювера и т.д. Если ревьювер и автор уперлись, могут пригласить третьего в качестве арбитра. Если застряли на координации, будут носиться между командами и сводить концы. Если что-то поменялось будут обновлять истории и доносить это до инженеров. Это их работа, главным образом персонально-коммуникационная, и справляются они с ней на ура. Опять же не из альтруистических соображений — если ревью зависло на месяц, есть шанс что всю фичу зарубят как невыполнимую и снесут в бэклог. Им тогда объясняться с кучей народа, в том числе директорами и спонсорами. И OKR могут посыпаться.
Кстати, подчиненных инженеров у барышень нет и начальством они формально тоже не являются (разве только между собой). Это для того, чтобы они обслуживали процесс а не рулили им. В противном случае будет "сделай как я говорю или премия минус".
В целом работать намного комфортнее чем в конторе с кучей мотивационных метрик (я и там был в свое время), а впечатление очень положительное. Когда у вас "ревью в 24 часа" и "история в день", фокус неизбежно сползает с работы на удовлетворение системы или ее надувательство. Конкретно пример из "метрической" конторы (каюсь): иногда если ревью сложное, а мне надо еще кучу всего сделать, я его просто рубил его "за несоответствие требованиям", благо всегда можно прицепиться. Автор понимал что я в зашиве и возвращал историю продакту. Они всегда перегружены, так что пару дней есть пока они доберутся. Потому 10 минутный митинг с чтением истории вслух, уточнение одного предложения, подъем ревью, а у меня уже было время код почитать. Так погоняешь ревью кругами — у всех метрики на ура, коллаборация претъ, все счастливы. Только сплошная Кафка какая-то, причем я не про технологию.
Тоже думаем уходить от ORM-a из-за трудностей с динамической схемой. Фактически планируем создавать записи хранящие JSON + некоторое количество полей по которым ведется связывание и выборки (вычисляются на основе самого объекта который храним). NoSQL использовать не можем из-за регуляций. Пока прототип выглядит очень достойно в плане использования (код контроллеров сильно похудел, много boilerplate code вроде PUT, PATCH, валидации и прочего ушло из контроллеров) и производительности (для сильно связанных данных, которые были разнесены по десятку таблиц из-за нормализации, разница в десятки раз, главным образом из-за отсутствия дорогих джойнов).
Кто так пробовал делать, какие подводные камни?
Относительно JSON, очень хотелось бы хранить данные в BSON (с упаковкой). Много не-текста в схеме.
Камни может и стереотипные, но, по моему опыту, весьма заслуженные. Я говорю о том, что процесс разработки интерфейса стал из двунаправленного односторонним, и реализация (а иногда и функция) сейчас часто вторична по отношению к дизайну. Торг за требования — это часть работы архитектора, передача дизайна в разработку — это передача (и прием) ответственности. Теперь же мне приходится очень часто беседовать на повышенных тонах с дизайнерами и менеджерами по поводу целесообразности очередного решения. И, как правило, убедить кого-то можно только угрожая увеличением бюджета, потому что технические детали не интересны, а "на вебе можно все". Может просто я стал старый и сварливый?
Разделяю ваши фрустрации! Но, боюсь, срыва покровов не произошло:
Вот в них-то и проблема, и изящно избавиться от "M" и "C" вашим методом не выйдет. Во-первых "M" на бэк-енде и "M" на клиенте малость разные от слова совсем. "M" клиента обычно обрастает состояниями, про которые бэк-енд понятия не имеет. "C" не тождественно браузеру уже лет пятнадцать, с тех пор как появился AJAX и асинхронность. А вот с "V" который всем так интересен как раз все теперь относительно хорошо, по крайней мере не так плохо как на десктопе.
С моей точки зрения проблемы совсем не в экосистеме, а в архитектуре, которая ее породила:
А если честно, то есть еще Power-point driven development. Вот это пожалуй и есть объективный корень всего зла. Мой первый опыт веб-программирования был в 2000-м. Мы обсуждали штуки вроде "визуальный язык", "метафоры управления", "поведение элементов", "доступность данных", "стандартные представления", "control flow/data flow" и т.д. Было много торга с дизайнерами за выразительность против универсальности, и это был спор в духе Сократа. Что было необходимо, т.к. компоненты приходилось писать и поддерживать самостоятельно. Сейчас я этого практически не вижу. Если что-то вышло из UX специалиста (чаще в формате PPT или PSD, с описанием в духе "новый дизайн!!!"), обратно это можно запихнуть только со слезами и насилием над личностью последнего (он же ж нарисовал и уже согласовал, и вообще чем нам не угодил pivot table с аггрегацией по 10MM записей, эксель же тянет). А потом еще начнется A/B тестирование, с двумя версиями интерфейса в параллель, потому что эта хитрая жопа не хочет брать на себя ответственность за свои решения. Не, я не против. Если у меня бюджет будет как в Амазоне и Нетфликсе — за ваши деньги любой каприз, а так…
Я к чему… Это больше не поле деятельности инженеров, тут правят дизайнеры и частенько маркетинг, а им чаще всего плевать как все работает, откуда берутся данные, как они вяжутся к интерфейсу, что повторно используется и т.д. Что, в свою очередь пораждает любовь к абстракциям и фремворкам, потому что собственно свой код все равно выраждается в адову копипасту со временем, а душа не терпит посредственности.
Прошу прощения за простыню, сегодня грустный вечер ;-)
Одно с другим слабо связано, как отмечено выше. Если на ревью проверяется главным образом стиль кодирования и NPE, на качество кода оно слабо влияет.
потому что так у них повелось. См про качество этого процесса в том же параграфе.
pull request / git workflow. Ревью делаются на PR.
нет, из-за naming conventions у компонентов и методов. Типа PublicCampaignAnalyticsEventTransitiveViewFactory::analyticsEventCreationTimestamp. Это в общем из той же оперы.
Автор оригинальной статьи, вероятно, как и положено сеньору в Гугеле, проводит больше времени в Gerrit, чем в IDE. А там как раз будет дифф без подсветки и прочего. А тащить ветку локально чтобы посмотреть на нее через IDE это слишком много телодвижений для уважаемого человека.
Слуга ваш покорный пострадал на прошлой работе в попытках аргументированно объяснить, что код пишет 50 человек и каждый день, а ревью делают 4 и только перед финалом. И исходя из этого раскладывать компонент по 6 местам и фигачить полукилометровые имена с префиксами несколько иррационально. Тем более что за 12 месяцев ни каких замечаний от оных уважаемых людей, кроме соответствия гайдлайнам, я не видел. На что получил вполне ожидаемый ответ — мы есмь четыре всадника апокалипсиса, покайсо холоп и убойся гнева нашего. На том и разошлись. ;-)
Гибкая она, только если знать где гнуть. Скрам это контракт (как программный интерфейс) между тремя сторонами — ПМ, Заказчиком и Инженерами. Реализация этого контракта зависит от много чего. Как и в программировании — хорошее API может быть плохо реализовано. На тренингах этому, к сожалению, этому не учат, а занимаются разбором этого самого интерфейса. Пообщайтесь с кем-то у кого скрам работает — взглянете на это по-другому. Если хотите — спрашивайте в личку.
И тогда угрюмые сибирские мужики сунули под бензопилу стальной лом.
"Хрррр" — сказала бензопила и поломалась.
"А-а-г-аааа! То-то!" — возопили угрюмые сибирские мужики и пошли валить лес двуручными пилами.
Есть на планете много несчастных, которые вынуждены корячиться с mingw, cygwin, VcServ/XMing, Hyper-V+Boot-to-Docker и т.д. Вот майки наконец вняли стенаниям горемык и вместо кучи костылей сделали… свой собственный костыль. Хорошо ли оно будет работать и долго ли будет поддерживаться — это отдельный вопрос, но за смелую попытку — честь и хвала, я считаю.
"Кто эти несчастные?" — спросите вы. Добро пожаловать в чудаковатый мир корпораций. У нас весь прод на открытых технологиях, но при поступлении на работу всем выдают lenovo thinkpad с предустановленной десяткой. IT отвечает только за вин, и только за 10, и все, потому что их десять человек а нас несколько сотен, и обслуживать зоопарк никсов и маков им совсем не хочется. Поэтому у меня крутится пяток контейнеров под hyper-v, один из которых дев среда с X11.Отдельные горячие головы поставили себе убунту и подписали waver что берут на себя всю ответственность, но таких единицы.
Более конкретно, в mvn, например, есть плагин для сборки и публикации образов в докере, Т.е. ваша история будет выглядеть так: вы пропатчили базовый имидж (или в Dockerfile прописали, или ручками закоммитили изменения, или тем же паппетом накатили), запустили обычный билд, билд нагенерил вам образов для контейнеров (он это делает довольно шустро за счет кеширования, так что собрать сотню образов может быть сравнимо с копированием файлов по сетке). Дальше ваш QA позапускал контейнеры (фактически 1 к 1 конфигурация вашего продакшена, может быть с меньшей избыточностью), прогнал автотесты, подтвердил что все работает. После этого те, кто у вас занимается релизами, взяли те же образы, подменили в продакшене одни контейнеры другими и все побежало дальше.
Менеджмент конфигурации тоже становится малость другим. У четких пацанов уже давно конфиг = код. А значит очень хочется чтобы конфиги на продакшене = конфиги в стейджинге = конфиги у девелопера (здесь = бинарное). Все вариации в топологии за счет DNS, вся авторизация между сервисами — по сертификатам. Если уж совсем никак — то через параметры у контейнера или разделяемые тома. Чтобы различий между средами не было вообще.
У нас тоже долго путались с концепциями, надо сказать у докера не очень удачная терминология, и от того много недопониманий. Не думайте про контейнеры как про виртуалки. Контейнеры ни кто никогда не патчит, не перезапускает, и даже ssh-ем в них не лазает. Это как "суперпроцесс", который крутится со своим изолированным окружением. Остановился — умер. Можно унести труп в лабу и там поковыряться, если уж очень нужно поискать причины сбоя, но оживлять его и возвращать в строй его уже ни кто не будет.
А вот про безопасность самого докера — это справедливо. Технология молодая, и грабли будут. Но те же разговоры были и про виртуализацию, если память мне не врет.
Проблема как всегда в людях. Данные собираются, аналитика считается. Но. Никому. Это. Не. Надо. Как выясняется. Пациенты, конечно, счастливы — бабушки боятся встать с кровати без этих часов, сильно к ним привыкают. Но медсестрам пофигу. Им важен только fall detection, и мониторинг по зонам (не застрял ли пациент в туалете). Вся телеметрия им по барабану. Геронтологу это вообще все в пику, зачем ему смотреть на данные, если можно заставить его приезжать два раза в неделю, по $300 за визит и тесты? Терапевту это все пофигу в квадрате. Какая разница, активен пациент или нет. Жалобы спросил, давление померял, ответственность с себя снял. Досвидос. Родственникам тоже пофигу, в большинстве случаев. Тем кому старики нужны, не сдают их в дома престарелых. Госпиталям в IT тоже пофигу, потому что у них EMR система и 100500 индусов которые вокруг нее бегают и крутят HL7 так, чтобы она была вообще не совместима ни с чем кроме самой себя. Дополнительная интеграционная точка — это десятки тысяч баксов их драгоценного времени ежегодно. Страховым тоже пофигу, кода на услугу нет, возврата нет, пропихнуть его туда можно только в новой редакции кодов услуг, а мед. учреждения еще предыдущий стандарт ввести не смогли. Это еще лет 5-10, не меньше.
Поэтому носимые штуки это здорово, но медицина с точки зрения технологий, по крайней мере в USA — это адское болото. На каждого 1 человека, которому что-то надо есть 1000 человек которым ничего не надо, кроме job security ;-(
Второй проект которым мы занимаемся — система записи для эндоскопов — много лучше, т.к. драйвится докторами (в основателях очень уважаемый в индустрии человек). А с телеметрией пока таких энтузиастов не видно. ;-\