Вот я не понимаю почему не сделают подстановку переменных на этапе конструкции DOM? Все костыли какие-то с тонной JS и новые конструкции в HTML, прицеленные на узкий кейз. ОК, а если я не картинку хочу а фон с разными DPI и кропом? Чего стоит на этапе парсинга сразу разворачивать какие-нибудь ${DPI-X} и ${DPI-Y}, ${SCREEN-WIDTH} и прочее и подставлять в URL или в HTTP хедеры. И эту, и еще миллион проблем с тем же видео решили бы сразу.
Автор — мой коллега, статья по-видимому родилась из шестимесячного упражнения по рефакторингу workflow в крупной SaaS системе (2-й по размеру игрок legal рынка в штатах). Так что знакомство у комманды с предметом было весьма близкое…
С парой вещей я соглашусь:
— workflow (в теории) скалится хорошо, если (даже не так: ЕСЛИ) все activities очень легкие (=короткие) и сами по себе скалятся тоже. Если нагородить тяжелых активити, которые грузят базу тяжелыми транзакциями, делают ощутимые вычисления, используют триггера и тяжелые UDF-ы, блокируют друг друга или вообще любят что-то погонять в синхронном режиме — все будет плохо. Workflow тут вообще-то не при чем, просто из-за длительности транзакций играет конструктивное ограничение, про которое не все в курсе. Наверное, общая рекомендация тут такая: если есть тяжелые активности, делайте их асинхронными. Да, магии не будет.
— в нормальной ситуации аналитики, конечно, сами workflow не пилят, это вотчина devops / solutions. Другое дело что devops часто сами выступают в роли аналитиков (т.е. сами говорят с заказчиками и реализуют изменения) и крутят эти самые workflow не особенно думая о том, что творится внутри. Специфика конкретного клиента в том, что там был сделан встроенный workflow designer и это еще усугубило проблему, ибо рисованием workflow вообще занялись не особо технические люди…
Опять же в защиту статьи, начальная архитектура была сформирована при участии архитекторов из Редмонда. Отсюда, видимо, и негодование по поводу расхождения между обещанным и полученным. Я ни в коем разе не буду катить бочку на архитекторов из MSFT, видимо реальная жизнь сильно вышла за пределы проторенной дорожки…
Disclaimer: это не мой проект, я в менеджменте компании, всех деталей могу не знать. Если где соврал — то по чистосердечному заблуждению… Игорю спасибо за статью!
Именно так. Head units остаются во владении Tier 2 и под контролем Tier 3, всем остальным — пожалуйста в MirrorLink. Вы можете положить на наш тортик свою вишенку, да и то просто так у вас это не получится. Не зря же CCC хлеб ест.
Давеча общался с QNX на тему встройку в их платформу аппов для российского рынка. Кухня у них такая. Есть Tier 1 — это производители авто. Есть Tier 3 — это производители head units. Есть Tier 3 — это производители ОС, компонент и девайсов. Никаких апп маркетов, никаких облаков, везде адский контроль всего, с любимыми отговорками что «водитель может отвлечься и попасть в аварию, а это иск к Tier 1».
Чтобы засунуть свой апп в авто, надо прийти к отдельному производителю из Tier 1 и договориться с ним. Тогда они наймут Tier2 чтобы внести изменения, а те в свою очередь подгонят консультантов-партнеров из Tier3. Т.е. если вы хотите приложение для BMW, Mercedes и Audi вам надо договориться с ними по отдельности, вложиться в «партнерство» и съесть все накрутки «партнеров» ниже по пищевой цепочке. К сведению, на Tier3 час консалтинга стоит сам по себе довольно дорого, чувствительно дороже $50.
Короче, полнейшая жопа. Три уровная бессовестно жирующих жадин. А рынок организован так, что пойти против шерсти практически не реально. Даже чтобы войти на tier 3 надо инвестиции в пол-ляма евро без малейшей надежды на отдачу за три года. И это еще без разъездов по шоу и маркетинга. Если AGL задавит этот гадючник — честь и хвала им, хотя все указывает на то, что это будет очередная грызня в Tier 3.
Хорошо написано, но вот нумерованный список — это в ряде случаев адский антипаттерн.
Хорошо когда вы «рулите» достаточно простым процессом (напр. продажей) в одиночку. Тогда у вас все веревочки в руках и проблем нет: вы-мозг, все остальные — мускулы.
Если ситуация хотя бы чуть более сложная, я предпочитаю иметь централизованный артефакт (напр. коммерческое предложение, спека, бэклог, план проекта, и т.д.) который мы совместно приводим к общему знаменателю. И только он имеет значение, а не письмо от надцатого числа который Иван Семенович отправил Прокофию Никитичу вместе с приглашением отужинать. Всякий раз когда я вижу «нумерованный список» во всякими штуками в переписке — это сигнал: коммуникация перешла в ad-hoc, надвигается задница.
Хах! У меня тетя мучается спиной, мы с женой привезли массажную накладку на кресло. Такую, с грелкой и вибромассажем, на пульте. На досмотре погранцы очень напряглись и занервничали. Знаете как сабж выглядит в рентгене в свернутом виде? 20 непрозрачных брусков, в каждый с двух сторон воткнуто по паре цилиндров размером с авторучку, к каждому идет по паре проводов, все провода перекручены в косичку и идут на пульт с одной кнопкой. Просто пояс шахида! Надо отдать должное погранцам, ситуация была контроллируемой, пока моя супруга не брякнула «это не наше» и не рванула в сторону…
А вообще TSA расшифровывается не как Transportation Security Administration, а как Thousands Standing Around.
Интересно… Мы в свое время покурили open source и решили перейти на темную сторону использовать Artifactory Pro. Как раз в пару к Jenkins. После оценки трудозатрат на поднимание инфраструктуры коммерческое решение оказалось куда выгоднее. А вы молодец, справились…
Overengineering это метод борьбы с рутиной. Я вот сейчас рисую генератор мокапов по XML спеке вместо того, чтобы рисовать CRUD формочки в Visio. Меня трудно понять. Но, при этом, когда у меня получается, я делаю «80 часов работы до обеда» ;-)
1) Posh-у вообще фиолетово кто на другом конце пайпа, лишь бы плевался объектами и вообще поддерживал метафору. Хотите — заверните вашу историческую действительность в cmdlet и радуйтесь.
2) Да, Posh прицелен на DevOps. Это старая музыка под новую драм-машину, «пишущие админы». Майки очень на них ставят и, кстати, не зря. Большинство SaaS держится именно на них. Фанаты переименовывающие музыку в шеле их мало интересуют.
Я как раз и написал комментарий про то, что мои попытки что-то похожее сделать привели к довольно сложным (на мой взгляд) костылям. Но тем плюрализм мнений и конкурренция идей и хороши — может у вас получится то, что не получилось у меня.
Много лет назад, когда мы еще дружили с перлом, я делал нечто похожее (даже с поддержкой CSV, JSON и XML). Собственно «расширение шелла» выглядело как кучка перл-прог, к которым со временем родился общий модуль для парсинга параметров из arg-ов и конфиг-файлов, сериализации объектов с сохранением типов и методов и т.д. Соответственно если у меня закисал мозг на каком-то однострочнике, я шел и писал прогу на перле. Да, сочленять перл-проги между собой через трубы было немного неэффективно (типа чтобы передать объект надо его заенкодить с одной стороны и задекодить с другой + динамически подгрузить его методы из общего модуля). И таки да, это занимало лишние 30 минут. Но, со временем, из зоопарка прог знание начало сегрегироваться в разумный набор утилит.
Гонять хэши было довольно увлекательно, но потом из «личных нужд» это переросло в «очень перспективное решение», и пришлось выкинуть перлы и трубы, и взяться за java, ant (для кастомизации сценариев) и message bus. Увы.
PS, кстати, отличная штука. И, наверное, .NET это плюс, а не минус, ибо зная API можно с ним поговорить, нарисовать свой cmdlet, даже если прога в явном виде это не позволяет. Что сильно более опенсоурсно и прогрессивно чем концепция «кучки черных ящичков» в никсах. Майки в этом смысле подняли планку.
Кто-то политкорретно спалился, если не ошибка перевода. Напомним, что расизм суть дискриминация по рассовой принадлежности. Master и slave — это из области рабовладения. Кстати, этимология слова slave: от слова slavic, т.е. славяне, растет корнями еще в римскую империю. Автор патча (и многие другие борцы за свободу и против истории) немножко путает расизм и рабовладение, непроизвольно ассоциируя черных с рабами, что само по себе является вопиющим проявлением расизма. Я бы на их месте реально обиделся.
Относительно терминологии, leader / follower крайне неудачный выбор терминов, имхо.
ИМХО, за исключением редких случаев, сравнение разработки софта с полетом на луну вообще говоря не правомочно. Большинство приложений, даже те, где много математики и бизнес-логики, не уж такие сложные. А те, которые большие и сложные пишутся не одной итерацией и не с одного плана. Да и в процессе есть много места для маневров.
Мы тут друг друга кормим байками про то, что мы делаем мега сложные продукты, что «оценить точно невозможно», «много рисков» и прочее так долго, что сами в них поверили. А это ни больше ни меньше отсутствие банальной дисциплины и боевого опыта. Это не проблема утилит, это проблема людей и их руководителей (вроде меня).
Кстати, если вы спросите водителя рейсового автобуса в Германии или Штатах сколько до следующей остановки — получите ответ с точностью до ± 10 мин. Так что есть, к чему стремиться. ;-)
Проблема MVVM которая меня больше всего заботит: есть например датамодель на EF. Фактически для скучных enterprise приложений ViewModel на 70% ее брат-близнец, только там свойства немножко другие штуки возвращают и реализуют NotifyPropertyChanged. По мне это адский оверхед, как для написания (кто-то будет сидеть, писать туповатые viewmodel-и, отрабатывать change requests, раздувать кодобазу без надобности и ненавидеть свою жизнь), так и для исполнения (чтобы показать список объектов надо создать их близнецов в памяти). Есть ли какие-то рекомендации в этом направлении? LightSwitch не предлагать :-)
Я возможно вызову на себя праведный гнев сообщества, но: DelegateCommand это скорее зло чем добро.
Идея использования комманд растет из responsibility segregation, т.е. когда мне надо делать расчет платежей я оформляю это в отдельный класс, который реализует помимо алгоритма еще и определение того, когда это действие применимо, уведомления когда действие стало применимо и т.д. И затем использую его либо глобально в приложении, либо создавая инстансы в конкретных ViewModel. Зачем? Затем что, как правило, команды повторно используются и требуют бОльшего покрытия чем ViewModel и имеют четкие зависимости.
Может мы и клоуны… Но tier0 вопросы задаем всем и всегда. К сожалению уже выросло два поколения EA которые начитались книжек, любят рассуждать про best practices, наслушались семинаров, покатались по всяким тусам и т.д. Эта братия умеет феерично скручивать фреймворки но (внезапно!) плывет в OO дизайне и алгоритмах. Потому как серьезный код не писала никогда. Но понты имеет с избытком. Соответственно дев. команда быстро теряет всякое уважение к такому EA и перестает воспринимать его серьезно. И его приходится увольнять после 2 месяцев работы, несмотря на то, что он говорит в общем правильные вещи. А это $10-15K в трубу. Поэтому наем такого EA не желателен, хотя бы чисто экономически. Отсюда и вопросы tier0 на интервью.
Техническая история будет выглядеть приблизительно так: «сделать справочник правил для расчета компенсаций по целям продаж для сотрудников». К этой истории будет идти описание на пол-страницы какие поля должны быть в справочнике, и как по нему считается зарплата. Понятно, она связана за всем остальным и не вполне отражает взаимодействие с пользователем. Это неприятность. Однако она описана в терминах предметного домена, понятна аналитику и т.д. Да и получается довольно компактно, дев может в нее въехать за короткое время.
Если я пытаюсь написать то же с точки зрения BDD, я «попадаю» на описание всего этого с точки зрения актеров, т.е. «как администратор я хочу завести правило так что...» и дальше детализирую его. Но проблема в том, что этот справочник цепляет несколько «поведений» у трех разных ролей — и завести правило, и посмотреть, и выплатить и т.д. Т.е. скорее описывает процесс использования софта, нежели алгоритм его работы.
Спасибо за статью. Раз уж в заголовке есть слово «введение» позволю себе нубский вопрос к аудитории. Мы довольно давно подсели на agile, но вот дзен все никак не наступит. Вцелом получается, что как только мы начинаем писать не технические истории, а именно behavior (As X I want Y so that Z) и пытаемся протянуть все до уровня тестов, получаются два неприятных эффекта:
1) Очень много головняка вываливается на сторону PO, вплоть до полной стагнации работы (даже в маленькой команде 3-5 чел). На достаточно простой технический сценарий получается куча As… I want… so that… историй настолько гранулярных, что за деревьями перестает быть виден лес. Фактически PO вынужден прорабатывать логику поведения в очень мелких деталях. Команда-то рада до соплей, потому что «перевести в тесты и дальше TDD», а вот PO и архитектор глубоко несчастны. Писать behavioral истории чтобы потом декомпозировать их в технические таски как-то уж слишком утомительно. Груминг требует дофига времени и вообще value от этой деятельности как-то не видно.
2) Так как за behavioral историями не видно ни дизайна, ни концепций, команда начинает буферить по-страшному. Велосити в стори-поинтах прет в гору, а реальный прогресс по фичам ни к черту ни годится. На бурндауне же видится такая типовая картина: behavioral истории висят в активном состоянии несколько дней и потом закрываются «пучками», т.е. пишут по факту одну фичу на несколько историй. Что мега раздражает всех, потому как усилия на прописывание историй получается тратятся зря…
При составлении беклога в виде технических историй такой фигни (параллельный проект) происходит меньше…
Тема очень интересная. С выводом не соглашусь, к тому же типов атак больше. И главный вопрос: ок, круто, а что делать?
Я двигаю идею, что надо смотреть на проблему шире, не фокусируясь на одном акте волеизъявления, но на делегации полномочий принятия политических решений. Т.е. исключить процедуру разового выбора на N лет вообще. Я описал вкратце идею у себя.
В прошлом году пытался пообсуждать с разными людьми, но ничего не получилось — с желающими участвовать оказалось туго. Да и вообще мало-мальски сложившиеся люди, что в России, что в Штатах, бегут от этой темы как от проказы. Хотя казалось бы — математика…
Еще одну довольно популярную причину забыли: заводской брак HDD редко бывает в одном винте, обычно затрагивает целую партию. Поэтому граждане закупившие OEM винты и собравшие на них конфигурацию raid из расчета замены одного винта «если че», жестоко обламываются, когда диски начинают вылетать пару раз в день.
Еще страшилка — это плохая политика бэкапов. Когда данных много (десятки-сотни ТБ, сканы доков например), а хранилище архивное (write once read many), люди часто думают терминами дифференциальных бэкапов: меняется редко, если че — восстановимся. И тут — опа, надо подниматься собираясь из диффов за последние XX месяцев (=оффлайн на несколько дней), а то и ввобще выясняется что парочка диффов не читается.
И еще одна в кучу — основной и резервный датацентры в одной погодной зоне, напр. на восточном побережье в штатах (а то и вообще в 15 минутах друг от друга, в рамках одной подстанции). В последний ураган было весело: оба ДЦ работают на дизелях два дня, шлют мольбы сокращать энергопотребление. Та-да!
С парой вещей я соглашусь:
— workflow (в теории) скалится хорошо, если (даже не так: ЕСЛИ) все activities очень легкие (=короткие) и сами по себе скалятся тоже. Если нагородить тяжелых активити, которые грузят базу тяжелыми транзакциями, делают ощутимые вычисления, используют триггера и тяжелые UDF-ы, блокируют друг друга или вообще любят что-то погонять в синхронном режиме — все будет плохо. Workflow тут вообще-то не при чем, просто из-за длительности транзакций играет конструктивное ограничение, про которое не все в курсе. Наверное, общая рекомендация тут такая: если есть тяжелые активности, делайте их асинхронными. Да, магии не будет.
— в нормальной ситуации аналитики, конечно, сами workflow не пилят, это вотчина devops / solutions. Другое дело что devops часто сами выступают в роли аналитиков (т.е. сами говорят с заказчиками и реализуют изменения) и крутят эти самые workflow не особенно думая о том, что творится внутри. Специфика конкретного клиента в том, что там был сделан встроенный workflow designer и это еще усугубило проблему, ибо рисованием workflow вообще занялись не особо технические люди…
Опять же в защиту статьи, начальная архитектура была сформирована при участии архитекторов из Редмонда. Отсюда, видимо, и негодование по поводу расхождения между обещанным и полученным. Я ни в коем разе не буду катить бочку на архитекторов из MSFT, видимо реальная жизнь сильно вышла за пределы проторенной дорожки…
Disclaimer: это не мой проект, я в менеджменте компании, всех деталей могу не знать. Если где соврал — то по чистосердечному заблуждению… Игорю спасибо за статью!
Чтобы засунуть свой апп в авто, надо прийти к отдельному производителю из Tier 1 и договориться с ним. Тогда они наймут Tier2 чтобы внести изменения, а те в свою очередь подгонят консультантов-партнеров из Tier3. Т.е. если вы хотите приложение для BMW, Mercedes и Audi вам надо договориться с ними по отдельности, вложиться в «партнерство» и съесть все накрутки «партнеров» ниже по пищевой цепочке. К сведению, на Tier3 час консалтинга стоит сам по себе довольно дорого, чувствительно дороже $50.
Короче, полнейшая жопа. Три уровная бессовестно жирующих жадин. А рынок организован так, что пойти против шерсти практически не реально. Даже чтобы войти на tier 3 надо инвестиции в пол-ляма евро без малейшей надежды на отдачу за три года. И это еще без разъездов по шоу и маркетинга. Если AGL задавит этот гадючник — честь и хвала им, хотя все указывает на то, что это будет очередная грызня в Tier 3.
Хорошо когда вы «рулите» достаточно простым процессом (напр. продажей) в одиночку. Тогда у вас все веревочки в руках и проблем нет: вы-мозг, все остальные — мускулы.
Если ситуация хотя бы чуть более сложная, я предпочитаю иметь централизованный артефакт (напр. коммерческое предложение, спека, бэклог, план проекта, и т.д.) который мы совместно приводим к общему знаменателю. И только он имеет значение, а не письмо от надцатого числа который Иван Семенович отправил Прокофию Никитичу вместе с приглашением отужинать. Всякий раз когда я вижу «нумерованный список» во всякими штуками в переписке — это сигнал: коммуникация перешла в ad-hoc, надвигается задница.
А вообще TSA расшифровывается не как Transportation Security Administration, а как Thousands Standing Around.
перейти на темную сторонуиспользовать Artifactory Pro. Как раз в пару к Jenkins. После оценки трудозатрат на поднимание инфраструктуры коммерческое решение оказалось куда выгоднее. А вы молодец, справились…1) Posh-у вообще фиолетово кто на другом конце пайпа, лишь бы плевался объектами и вообще поддерживал метафору. Хотите — заверните вашу историческую действительность в cmdlet и радуйтесь.
2) Да, Posh прицелен на DevOps. Это старая музыка под новую драм-машину, «пишущие админы». Майки очень на них ставят и, кстати, не зря. Большинство SaaS держится именно на них. Фанаты переименовывающие музыку в шеле их мало интересуют.
Я как раз и написал комментарий про то, что мои попытки что-то похожее сделать привели к довольно сложным (на мой взгляд) костылям. Но тем плюрализм мнений и конкурренция идей и хороши — может у вас получится то, что не получилось у меня.
Гонять хэши было довольно увлекательно, но потом из «личных нужд» это переросло в «очень перспективное решение», и пришлось выкинуть перлы и трубы, и взяться за java, ant (для кастомизации сценариев) и message bus. Увы.
PS, кстати, отличная штука. И, наверное, .NET это плюс, а не минус, ибо зная API можно с ним поговорить, нарисовать свой cmdlet, даже если прога в явном виде это не позволяет. Что сильно более опенсоурсно и прогрессивно чем концепция «кучки черных ящичков» в никсах. Майки в этом смысле подняли планку.
Относительно терминологии, leader / follower крайне неудачный выбор терминов, имхо.
Мы тут друг друга кормим байками про то, что мы делаем мега сложные продукты, что «оценить точно невозможно», «много рисков» и прочее так долго, что сами в них поверили. А это ни больше ни меньше отсутствие банальной дисциплины и боевого опыта. Это не проблема утилит, это проблема людей и их руководителей (вроде меня).
Кстати, если вы спросите водителя рейсового автобуса в Германии или Штатах сколько до следующей остановки — получите ответ с точностью до ± 10 мин. Так что есть, к чему стремиться. ;-)
Идея использования комманд растет из responsibility segregation, т.е. когда мне надо делать расчет платежей я оформляю это в отдельный класс, который реализует помимо алгоритма еще и определение того, когда это действие применимо, уведомления когда действие стало применимо и т.д. И затем использую его либо глобально в приложении, либо создавая инстансы в конкретных ViewModel. Зачем? Затем что, как правило, команды повторно используются и требуют бОльшего покрытия чем ViewModel и имеют четкие зависимости.
Техническая история будет выглядеть приблизительно так: «сделать справочник правил для расчета компенсаций по целям продаж для сотрудников». К этой истории будет идти описание на пол-страницы какие поля должны быть в справочнике, и как по нему считается зарплата. Понятно, она связана за всем остальным и не вполне отражает взаимодействие с пользователем. Это неприятность. Однако она описана в терминах предметного домена, понятна аналитику и т.д. Да и получается довольно компактно, дев может в нее въехать за короткое время.
Если я пытаюсь написать то же с точки зрения BDD, я «попадаю» на описание всего этого с точки зрения актеров, т.е. «как администратор я хочу завести правило так что...» и дальше детализирую его. Но проблема в том, что этот справочник цепляет несколько «поведений» у трех разных ролей — и завести правило, и посмотреть, и выплатить и т.д. Т.е. скорее описывает процесс использования софта, нежели алгоритм его работы.
Или есть какие-то трюки для таких ситуаций?
1) Очень много головняка вываливается на сторону PO, вплоть до полной стагнации работы (даже в маленькой команде 3-5 чел). На достаточно простой технический сценарий получается куча As… I want… so that… историй настолько гранулярных, что за деревьями перестает быть виден лес. Фактически PO вынужден прорабатывать логику поведения в очень мелких деталях. Команда-то рада до соплей, потому что «перевести в тесты и дальше TDD», а вот PO и архитектор глубоко несчастны. Писать behavioral истории чтобы потом декомпозировать их в технические таски как-то уж слишком утомительно. Груминг требует дофига времени и вообще value от этой деятельности как-то не видно.
2) Так как за behavioral историями не видно ни дизайна, ни концепций, команда начинает буферить по-страшному. Велосити в стори-поинтах прет в гору, а реальный прогресс по фичам ни к черту ни годится. На бурндауне же видится такая типовая картина: behavioral истории висят в активном состоянии несколько дней и потом закрываются «пучками», т.е. пишут по факту одну фичу на несколько историй. Что мега раздражает всех, потому как усилия на прописывание историй получается тратятся зря…
При составлении беклога в виде технических историй такой фигни (параллельный проект) происходит меньше…
Что я делаю не так?
Я двигаю идею, что надо смотреть на проблему шире, не фокусируясь на одном акте волеизъявления, но на делегации полномочий принятия политических решений. Т.е. исключить процедуру разового выбора на N лет вообще. Я описал вкратце идею у себя.
В прошлом году пытался пообсуждать с разными людьми, но ничего не получилось — с желающими участвовать оказалось туго. Да и вообще мало-мальски сложившиеся люди, что в России, что в Штатах, бегут от этой темы как от проказы. Хотя казалось бы — математика…
Еще страшилка — это плохая политика бэкапов. Когда данных много (десятки-сотни ТБ, сканы доков например), а хранилище архивное (write once read many), люди часто думают терминами дифференциальных бэкапов: меняется редко, если че — восстановимся. И тут — опа, надо подниматься собираясь из диффов за последние XX месяцев (=оффлайн на несколько дней), а то и ввобще выясняется что парочка диффов не читается.
И еще одна в кучу — основной и резервный датацентры в одной погодной зоне, напр. на восточном побережье в штатах (а то и вообще в 15 минутах друг от друга, в рамках одной подстанции). В последний ураган было весело: оба ДЦ работают на дизелях два дня, шлют мольбы сокращать энергопотребление. Та-да!