каким должен быть правильный эджайл — нигде толком конкретно, по полочкам, системно не написано. до уровня методики или методологии, сравнимой по степени проработанности с RUP, эти процессы так никем и не проработаны. (ошибаюсь? ткните меня, пожалуйста, в «самое эталонное описание»… ).
у меня такое впечатление, что сегодня «эджайл» — это уже бренд, марка, лейбл, которым клеймят всё что-ни-попадя, что по мнению авторов должно быть «модно молодежным итеративным». Каждый дудит в свою дуду, у каждого есть своя правда и свой набор успешных проектов…
Каждый _Мастер_ говорит, что «его кунг-фу лучше других кунг-фу»)))
«Мода вокруг эджайл» дошла до того, что в проектном менеджменте уже тоже «используют эджайл»…
вот лет 30 как не эджайл, оказывается; Тернер планирование по вехам не описывал, и итеративную поэтапную работу никто не использовал, о планировании «набегающей волной» тоже никто не слышал («действительно… ведь в PMBoK же нет»… или есть? поправьте если упустил что… вот у Тернера и в НТК от Совнет / IPMA это точно есть ),
И тут бац —
откровение: ЭДЖАЙЛ в проектном менеджменте… ээх.
Конечно, понятно, там совсем-совсем не тот «эджайл» что в статье у автора, и некоторые идеи предлагаемые под этим лейблом там тоже есть — и новые, и жизнеспособные… Но степень «истерии вокруг» и «оторванности вообще» сегодняшнего термина «эджайл» от внятного понимания «что же это такое» — это, имхо, иллюстрирует как нельзя лучше.
PS: и это мы еще про «прогрессивный» «девопс» не говорили )))
Как мы это решаем?.. гм. А никак не решаем.
Буквально — не прменяем agile в том виде и формах, как это предлагается «идеологами легковесных технологий».
Как работаем? «Вспоминаем классиков» Пытаемся применять принципы масштабирования процесса разработки, заложенные в RUP, причем как это было описано в версиях от Rational (пока методологию еще не испортил IBM своими нововведениями и «принципами бизнес-ориентированной разработки» ).
т.е. вместо того, что бы пытаться адаптировать agile к процессам, которые выходят за границы его применимости, мы сразу берем немного другие принципы/артефакты и «утяжеляем» процесс разработки в зависимости от масштаба / сложности / особенностей проекта. И того, как он развивается.
В начале набор фич, названий usecase, архитектурный прототип (который исполняемая архитектура).
По мере развития проекта и его усложнения или измения границ — утяжеляем / расширяем те или иные стадии или процессы, детализируем артефакты, усложняем процесс работы с ними.
Тут главное не слепо копировать техники «описанные в трудах классиков», а понимать какой артефакт, какой процесс в какой из своих форм тебе сейчас нужен и _достаточен_. Те же usecase могут оставаться в форме кратких описаний до конца проекта, если проект не большой и с заказчиком доверенные отношения. Где то хорошо заходят сквозные сценарии, а где то надо хорошо проработать модель данных и вывернуть процесс разработки от моделирования. 6де то надо у заказчика сидеть, а где то надо строго отрабатывать по этапам.
А за ваш опыт — спасибо. Почитаем про описанные вами техники подробнее, глядишь, где и приложится.
OFFTOP:
«Фигак-фигак… » — это еще ничего.
Вот «стартап в п**дакшен» — вот это действительно страшно.
(:
/OFFTOP
Заметил тут краем глаза: скрипты калькуляторов — они у вас на паскале, что ли?
А бизнес логику / поведение можно скриптовать? Изменить поведение экранной формы?
Скриптануть создание печатной формы? Расчет отчета?
Повторяю, .Net framework — часть винды. В энтерпрайзе винду используют. Но вас именно .Net framework, почему-то смущает. Пока вы не объясните почему — рассуждать про смену мантейнера можно только за рамками Support Lifecycle и premier support. То есть лет через 20.
речь шла не об «использовании виндоус в интерпрайзе». Речь шла о конкуренции с java. Винду используют. никто не отрицает. в своей области. на рабочих станциях. word+excell запускать, доступ к веб-интерйесу обеспечивать, да принтером управлять )
Это все написано в том числе и на .net. И это замечательно. Переход от C++ и WinApi к технологиях шарп+дотнет — в их случае улучшил ситуацию. winapi — та еще кака. Но к конкуренции с джавой это не имеет никакого отношения.
С джавой — C# и .NET Core не конкурируют — слишком разные весовые категории и спектр задач. И выйти на конкуренцию с джава они не способны, как минимум пока — в силу неоднократно выше описанных причин — проблемы с обратной совместимостью, зависимостью от единственного поставщика и его изменчивого взгляда на то «как надо», необходимостью переаботки кода «при смене моды».
Если секьюриити патч изменяет поведение (очевидно, в стандартах не описанное), то верить в неизменное поведение опенсорсных копий с другой кодовой базой, простите, идиотизм.
снова искажаете смысл того что вам говорят и додумываете.
я говорил о том, что «патч меняет поведение системы» — равно как и любое другое вмешательство в систему. Так же говорил, что не имея эталонного описания поведения и процесса проверки — вы не способны выяснить — изменил ли этот патч ещё что либо? — изменилось или нет эталонное поведение (которое вы не должны бы менять ради совместимости).
а вы начинаете рассуждать про что то вам «очевидное». не надо так.
Кроме того, повторюсь, не так важно опенсорс у вас или нет. Важно есть у вас достаточно детальное эталонное описание или нет, доступно оно для потребителя иил нет. У джава машины такое описание есть, оно доступно, и процесс сертификации на совместимость поддерживает соблюдение этих требований. И в итоге совершенно не важно на чем написана у вас ваша джава машина — на какой кодовой базе, опенсорсная она или нет — если она «одинаково вращает байткод» — то это совместимая джава машина. И «на неё можно переезжать».
>> когда есть стандарт, но его никто не соблюдает? Это лучше одного мантейнера и открытых исходников Core?
во первых, ECMA262 соблюдают. не настолько, наверное, насколько хотелось бы — но соблюдают. стараются. и официальный процесс сертификации улучшил бы ситуацию. но уже сейчас те-же Noshorn, V9, Rhino и др джавасрипт-машины вполне совместимы, что бы переносить js-код между ними, и беспокоиться не о том, будет он работать или нет, а беспокоиться о том насколько быстро, и будет ли у вас API для отладки вашего js-кода и насколько это api удобно. Другое дело, что разработка больших систем на языке с динамической типизацией — дело крайне не благодарное, и, имхо, даже глупое, но при медленном процессе, статичности требований, и некой мере безумности авторов — это может сработать.
Ну и, как это может вам ни показаться странным, но с точки зрения сохранности долгосрочных вложений в разработку кода — да, даже такая ситуация во многом лучше, чем текущая ситуация с «шарпы и дотнет».
Что предлагает майкрософт? изменивую моду и следование за ними. Вчера был просто .net, сегодня они вводят модную .net core (под которую надо снова переписывать код), завтра ещё что… каждый чих _единственного_ производителя вливается в хорошую копеечку производителям больших систем — и производители вынуждены петь под эту дудку за свой счет. А это все — в долгой перспективе и с большой кодовой базой — крайне не интересно и крайне затратно.
Потому и удел технологий майкрософт — в их текущем состоянии — небольшие и/или короткоживущие системы — у которых стоимость переработки не слишком велика — утилитакные пакеты, офис, игровые проекты, да тулзы на рабочих станциях. И в этом они, да, хороши) Но это всё — никак не конкуренция с джавой.
Наверное, то же, что вы будете делать, когда Oracle выпустит Java2 без стандартов и сертификаций? Форкну (подожду, пока IBM/JetBrains) Roslyn и пойду выпью за светлую память.
вы перемешиваете 2 момента.
во первых я говорил о проблеме смены майнтейнера.
если вы надетесь, что форкнутая, взятая на поддержку новым разработчиком система, без тестов/стандартов/сертификации будет продолжать работать точно так же как старая версия до форка — то вы, извините, наверное, очень наивны или никогда не работали ни с чем сложнее небольших изделий которые сдал и забыл.
видение ситуации и модель поведения в случае проблем типа форкну и подожду нового майнтейнера — это решения из области хомячковых популярных проблем. увы. интерпрайз думает не так. для них прекращение поддержки, смена майнтейнера, невыпуск секьюрити патчей и тп — сильная головная боль попробуйте цб рассказать что вы именно форком и ожиданием нового майнтейнера собираетесь решать риски закрытия платформы — на проекте, где простой системы в 6 часов обернется дефолтом в стране — вас пошлют и еще подопнут в дорожку. в лучшем случае просто «попросят на выход и не мешать дядям решать проблемы».
любой секьюрный патч изменит поведение системы. а у вас в шарпах даже описания эталонной модели нет, что бы понять «а как надо».
соответственно, новая версия ройзена от нового майнтейнера будет накапливать ворох скрытых проблем, которые очень сильно вдарят по разработчикам больших систем.
с джавой же у вас в принципе не будет проблемы смены майнтейнера. у вас уже есть несколько полнодействующих сборок джава машины, гарантированно реализующих одинаковое повещение как минимум в области стандарта. и я не буду ждать пока кто то сделает форк. я просто поставлю альтернативную, уже существующую джава машину, и буду далее обновляться уже с ней.
2. кроме того, вы кажется не понимаете, что в этой ситуации джава отличается от c# как минимум тем, что не оракл выпускает новый стандарт джавы. не только они.
попытка выпустить закрытую не покрытую стандартом и описаниями джаву провалится еще на этапе обсуждения, и в худшем случае приведет к тому же что и с опенОфисом — оракл останется только с торговой маркой вне процесса, а партнеры выпустял либре-Java, от ibm и сообщества, которые будут продолжать поддерживать стандарт как стандарт.
и их новые версии можно будет проверить на соответствие поведению старым по уже существующему процессу сертификации, что обеспечит избавление от проблем с переездом на новую версию платформы, пропатченную, избавленную от секьюрных проблем.
с шарпами все не так, согласитесь.
— — — — — — — — — —
кстати, когда я говорил про то, что «критериям стандартизации и сертификации соответвует только джава» — я совсем забыл про js — у них тоже есть стандарт и описание поведения — ECMA262. (имхо, он путанный до нельзя, но он есть) и ситуация с js как с технологией сейчас во многом похожа с java — замена одного майнтейнера не повлияет на сохранность ваших наработок. несколько джаваскрипт машин конкурируют за популярность и качество соблюдения единого стандарта) хотя, как я знаю, нет единого процесса сертификации и проверки на соответствие стандарту.
вот когда ситуация с c# станет аналогичной хотя бы js — тогда и можно будет говорить, что шарпы начали конкурировать с java. но майкрософту не интересно выпускать контроль за разработкой шарпов из своих рук — потому забудьте про эти мечты.
>> энтерпрайзу альтернативные компиляторы, например, зачем?
Альтернативные компиляторы (и даже не сами они, а именно только полностью совместимые друг с другом компиляторы/среды исполнения, которые генерируют одинаково работающий код) — это не самоцель.
Это следствие и признак хорошей среды, хорошей платформы, у которой малые риски потери вложенных в разработку средств.
Это признак хорошей технологиии, которая стандартизирована, тестируется, в которой последствия и проблемы от того, что один из майнтейнеров отвалится — минимальны.
Это признак технологии, в которой действительно есть тесты и стандарты, в которой совместимость — и «обратная между версиями» и «совместимость между платформами» и «переносимость софта между платформами» — не рекламные заявления, а проверяемый результат.
И на сегодня, увы, нет платформ которые соответствовали бы этим качествам — окромя джавы. Увы. Поправьте меня, если я не прав.
Вот скажем — вы же помните, что оракл начал «монетизацию JDK»? Это кого-то волнует? да собственно не особо. потому, что налажены стабильные выпуски OpenJDK, и все просто будут использовать OpenJDK. Потмоу что есть ещё пяток другой джава-машин (ну или был точно) — которые можно взять и начать использвоать. Потмоу что совместимость обеспечивается процессом сертифкации. В итоге — никто особо не парится из-за действий оракла, хотят они свои сборки продавать — ну пожалуйста — может кто и купит. Но окромя оракловой есть ещё несколько других джава машин, и сборок, и майнтенеров джавы среди которых, скажем IBM, и уже его одного хватит не пустить это дело на самотек, вне зависимости от недалекости менеджеров оракла, уже, показавших свою «мудрость» попытавшись спихнуть ОпенОфис на обочину истории.
А вот что вы будете делать _когда_ майкрософт прекратит поддержку Roslyn и, скажем, выпустит .Core2 уже совсем не опенсорсный? да хотя бы поменяет лицензию — мол «теперь все коммерсы дожны платить деньги, за обновления и секьюрити патчи»… И вот если в этот момент у вас нет альтернативного майнтернера, открытого стандарта и процесса сертификации этот стандарт подтверждающего и, собственно реализующего, нет альтернативного компилятора и среды, лишенной этих секьюрити проблем — … в этом случае, перспективы вашего софта — если ваш софт большой, долгоживущий и написан на .core — «печальны», а все деньги вложенные в разработку на шарпах — уже начали накрываться медным тазом. В лучшем случае — вы попадаете на проблемы смены майнтейнера проекта Roslyn — а это дело очень шаткое… или попадаете на непонятные перспективы миграции, или поклонения майкрософту деньгами в новой жизни с .Core2, не опенсорстной и может даже не бесплатной (см условия задачи)…
Вы вот с таким планом проработки рисков и такими песпективами планируется потеснить джаву в корпоративном сегменте? нуну…
>> Компилятор Roslyn — уже давно open source — GitHub
ну я вам про козлов, а вы мне про баранов. я не говорил про опенсорсность компилятора ну вот совершенно ничего.
Я смотрю на описание проекта… на майнтейнера… и вспоминаю вышенаписанное мною про то, что
пока эталонный компилятор создает только майкрософт,…
…
Вы знаете — вот у руби тоже компилятор опенсортный. Только «10 его портов и 5 реализаций»… они, конечно, совместимы друг с другом, но код работает на них «немного по разному»; версии майнстрима нарушают обратную совместимость, хотя — (по заявлениям) «всё вроде как собирается».
Опенсорс — не гарантия и не залог успеха.
Для сравнения: вспоминаем историю Java: она не была опенсорс насколько я помню. Но у неё была четкая, хорошо документирвоанная модель поведения, набор требований и тестов, процесс сертификации сторонних джава машин. Только на вскидку я могу вспомнть как минимум три джава машины — от Sun, от IBM и от сообщества — OpenJdk.
В шарпах есть что либо подобное? насколько я знаю нет.
>> Обратная совместимость кода присутствует, проекты 5 летней давности вполне себе собираются
и вот опять же… как это доказать? у вас есть стандарты, требования, модель поведения, тесты? как убедиться что у вас — не «хеппи стори выжившего» которому «просто повезло»?
Как взять результат сборки новым компилятором, прогнать его по официальным тестам требований к старой версии языка — и убедиться что поведение старого кода на новом компиляторе _действительно_ не изменяется на всем поле требований к поведению?
Не выйдет же, такую проверку устроить с шарпами, ага?
Что в текущей ситуации остается? верить вам на слово или вашему опыту? ОК, мы верим что вы уверены в своей правоте. А объективно что мы имеем? имееем субъективную точку зрения, предположительно фанатично(?) настроенного разработчика. простите.
Ну и снова про переносимость и отсутствие четкого стандарта. Понимаете… ну вот сделаю я, для примера, порт Roslyn компилятора и .net машины на эльбрус-процессор… И вот как доказать, что моя дотнет-машина работает точно так-же как на большой официальной десктопной платформе?
Где стандарты на поведение .net-байткода и процесс сертифкации компиляторов, разработанных не майкрософтом? вы с подобным подходом прогнозируете успех в интерпрайзе, где уже завоевала признание джава? ну ну.
Говорите у дотнет произволительность выше? да фигня это, извините. железо дешевеет и дешевеет. А вот труд людей, перерабатывающих код — дорожает. Стоимость любого чиха связанного с переработкой кода после выхода очередного компилятора — растет не линейно от объема кода. Потому и вопросы о которых я говрю — крайне серьезны для больших и долгоживущих проектов.
А майкрософт, простите, не сильно то и чешется в этом направлении особо. Они делают популярный продукт. _популярный_. Понимаете? Как руби, как питон, как js — они с ними фактически конкуриют, не с джавой. Джава «в поп-массовой культуре» не популярна))
А интерпрайзу популярность не сильно нужна. Нужна надежность, контролируемость, стабильность, экономия вложений. Один раз написал — и будь уверен что в оно будет не только собираться но и работать точно так же. ну как минимум, пока ты в пределах задокументирвоанного повдеения.
Именно этим джава получила признание.
не станет, увы. уже не стал, и не состоялся. полностью игнорируя все факты о темпах развития, и все прогнозы, пророчившие аналогичную победу еще несколько лет назад. увы.
вы, как минимум, забываете про проблемы обратной совместимости. (вы смешиваете «развитие» и «изменчивость»?). код, написанный 3-5-7 лет назад должен собираться и работать на новых компиляторах точно так же, как и 3-5-7 лет назад на старых компиляторах.
а этого в шарпах, увы, не происходит. по крайней мере как я вижу. только недальновидный будет вкладываться в большие долгоживущие системы на шарпах в таких условиях.
ну и стандартизация с описанием эталонной модели работы языка там тоже не очень то дотягивает до уровня, что бы обеспечить процесс аналогичный сертификации сторонних реализаций джава-машины.
пока эталонный компилятор создает только майкрософт, шарпы будут жить только там, где его двигает майкрософт, а на всех и вся их банально не хватит.
но для не очень больших короткоживущих приложух, с малоизменяющимися требованиями, простыми процессами внутри, отсутствием «бизнес-процессов» и проблем с этим связанных, отсутствием проблем долгой поддержки и постоянного развития — шарпы самое то. и геймдев на юнити — тому прямое доказательство.
который надо не зыбыть сменить на что-то «не учебное» в конце обучения.
ибо боевой истребитель — он не для тех кто только учится.
для учебы — учебные самолетики, простые в управлении.
по поводу популярности, у меня был, однажды, разговор.
человек «топил» за руби, но сути вопроса это не меняет:
— 80% проектов на гитхабе сейчас начинают на _этом_языке_!
— а ты посмотри, пожалуйста, сколько этих «проектов» не будут заброшены уже через 2-3 месяца?
(молчит)
вот я вся «суть популярности», имхо. шумиха, мода, раздувание собственной значимости — направленные на, по сути, обман тех, кто «не особо в теме».
если же хотите знать мое мнение, то оценивать надо кластерами, в пространстве с измерениями вида: область задач, объем кода и человекочасы-затрат вложено, время жизни проекта, интенсивность изменений (вкладываемые в работу человекочасы), оценочная стоимость разработки продукта по средней ставке специалиста на рынке и средняя цена этого специалиста, интенсивность изменений требований к по.
про последнее все забывают и ставят на одну планку сравнения «популярности» скажем руби и джаву, забывая, что рефакторинг большого кода в языках с динамической типизацией — совершенно другая лебединая песня, чем автоматическое отслеживание зависимостей и использования типов в языках со статической типизацией.
все языки — хороши в одном и сложны для другого. сравнивать надо сопоставляя схожие по областям и задачам. учебные языки нельзя тащить в «кровавый интерпрайз». в хаосе постоянно изменения ситуации, оно там просто не выживет «нигде и никак», окромя мелких утилит да сервисного скриптования процедур сборки и обслуживания боевого софта. но и учить новичков безднам джавы, если они банально не сталкивались с проблемами, из-за которых тут «устроено именно так как устроено» — рано. не поймут.
но, увы, задаваться этими вопросами… как правило не задаются. мода направлена на поиск очередной серебрянной пули. и, кажется, что «популярные статистики» направлены не на выяснение правды, ибо она сложна и не понятна, а на расчесывание ЧСВ у хомячков и целевой аудитории. имхо. что и есть ответ на поставленный в заголовке вопрос. тоже имхо )
>> JEP 335: Deprecate the Nashorn JavaScript Engine
а дальше что, какой движок следующий?
«карусель», конечно, получается — не успели отказаться от Rhino, уже и Nashorn выкидывают.
(имхо, последнего не жалко: я так и не нашел у Nashorn штатного api для программного контроля и отладки скриптов. а вот с Rhino получилось нарисовать собственный отладчик скриптов в нашем окружении. )
но, все-таки — кто в курсе вопроса? ждем возвращения Rhino или будут скрещивать ужа с ежом в формате java+v8?
спасибо.
исходя из описания по пункту 2:
1) верно ли я понимаю, что во freemarker нет переменных, которые вы можете создавать в самом шаблоне?
2) есть ли вызов паблик-функций класса? (вызов bean-свойств есть, но это несколько другое)
буду краток и ни разу не политкорректен, заранее прошу прощения.
работать в айти, имхо, сегодня не классно только по 2 причинам:
1. половина заказчиков грезит «мемасиками и хеппи стори», в том числе и с хабра. увы, но да, ребята, я говорю это на хабре) а то что их проект в реальности сложнее на 2 порядка чем хеппи-стори для статьи на 1 страницу — это понимает не так уж и много людей.
2. демпингующая школота, которая реально не понимает на что подписывается. извините еще раз, пожалуйста. ситуация: к заказчику категории пункта 1 приходит бравый молодец пункта 2 и обещает что вот все быстро просто и легко сделаем. и приправливает сверху списком «хеппи стори», да давит на «браво-модно-молодежно». в итоге через год он наконец «прозревает»… что типа «да, не надо было писать это на руби» (не в руби огород камень, а в сторону людей не понимающих границы применимости технологий)… но бюджет уже съеден и остатков не хватит что бы нанять нас и исправить ситуацию. молодец, понимая что тут больше не кормят, валит в туман, проект накрывается медным тазом, а на его место приходит другой молодец, так же браво заявляющий что вот уж он то сейчас все это быстро перепишет. скажем «на питоне, за месяц, чо уж там. сейчас на гитхабе 90% проектов начинают именно на *этом супер языке и мега фреймворке*. „
а ты сидишь рядом с этой воркующей парочкой и тихо материшься, понимая, что будет через год будет точно такой же песец.
видишь что заказчик не понимает что ему впариваю. и что тебя, с опытом и пониманием, видевшего эту ситуацию не раз, не отличают от выпускника “заочной школы программистов на мейллу».
понимаешь, что такой швах творится практически везде, куда ни глянь.
— вот это и мешает. наличие с обоих сторон людей которые не понимают как это работает.
и которые не хотят понимать )) синдром начинающего программиста, сдобренный слащавой рекламой.
слишком много людей сейчас набилось в it, которые к it не имеют практически никакого отношения. увы. Это примерно как в художники, музыканты, психологи будут приходить технари. не выйдет ничего хорошего.
а в остальном работать в it, имхо, не лучше и не хуже чем в любой другой области.
про «вкусовщину»… имхо вставки велосиси не смешиваются с html кодом, а во фримаркеке есть элементы похожие на теги, это мешает, имхо ) но да, может и вкусовщина.
тайпхинты? рад что вам нравится, но для нас это не не аргумент — идеей не пользуемся и в здравом уме и твердой памяти ее закупать в масштабах предприятия никто не будет; есть еще к ней личные претензии по поводу невозможности отобразить структуру анонимных классов в навигаторе по структуре кода, но… отложим. это вообще не по теме сейчас)
работа с мапами удобнее? давайте чуть позже обсудим.
сначала конкретику: как в freemarker сделать вот такие вещи?
пример 1
А почему тут нет Mala Gupta? её подготовка к сертификационному экзамену OCA — лучшее руководство по яыку Java какое я только видел.
написана на анлийском, но язык простой, читается без проблем.
собственно мы сейчас им (velocity) и пользуемся, и для проснения функциональности — пара вопросов, если можно:
* можно ли в free maker отправлять на рендеринг шаблоны, созданные динамически в рантайме? например в jsf такой фичи нет — все шаблоны компиляются во время сборки. а с velocity я так могу.
* если в значение строки подставить html — оно отрендерится как html или будет экранированно?
* есть возможность условного рендеринга? т.е. если значение переменной такое — то рендерим этот кусок, если нет то другой? мы часто этим пользуемся, перекладывая часть логики построения на плечи шаблонизатора.
* есть возможность реализовать внутри шаблона цикл? или list — это единственная «расширенная фича»?
* есть ли возможность обращаться к bean-свойствам объекта который погружен в контекст? т.е. я в хешмапе определяю одну переменную, а потом пользуюсь всеми его методами и свойствами, без необходимости в хешмапе определять 20+ значений.
Кажестя, возникло недопонимание в отношении того, что я от вас хотел.
Мне нужен пример работающего проекта, платформенно независимый, на вашем фреймворке и вашем языке (питон у вас? ну пусть питон и будет), который умеет работать с BLE.
Описание процесса сборки этого проекта под андроидом и под яблоком. Причем в последнем варианте так же сильно интересует процесс сборки и подписания вашего изделия в xcode временными ключами разработчика. И последнее не менее важно, потому что я собирал на огрызке проекты на LibGDX и C++\Qt — и в обоих случах сценарий стыковки проекта с механизмами подписания был не самым тривиальным и разным — потому очень интересует как это делать у вас.
Ждем от вас публикации.
Спасибо.
ЗЫ: и да, демки работы с BLE на C++\Qt я вчера таки собрал и запустил на огрызке. огрызок правда 5-й или 4-й, но на халяву другого не досталось). Теперь ход за вами — ждем аналогичной демки на Kivy.
и спорить с ними будет
бесполезнотрудно.каким должен быть правильный эджайл — нигде толком конкретно, по полочкам, системно не написано. до уровня методики или методологии, сравнимой по степени проработанности с RUP, эти процессы так никем и не проработаны. (ошибаюсь? ткните меня, пожалуйста, в «самое эталонное описание»… ).
у меня такое впечатление, что сегодня «эджайл» — это уже бренд, марка, лейбл, которым клеймят всё
что-ни-попадя, что по мнению авторов должно быть «модно молодежным итеративным». Каждый дудит в свою дуду, у каждого есть своя правда и свой набор успешных проектов…Каждый _Мастер_ говорит, что «его кунг-фу лучше других кунг-фу»)))
«Мода вокруг эджайл» дошла до того, что в проектном менеджменте уже тоже «используют эджайл»…
вот лет 30 как не эджайл, оказывается; Тернер планирование по вехам не описывал, и итеративную поэтапную работу никто не использовал, о планировании «набегающей волной» тоже никто не слышал («действительно… ведь в PMBoK же нет»… или есть? поправьте если упустил что… вот у Тернера и в НТК от Совнет / IPMA это точно есть ),
И тут бац —
откровение: ЭДЖАЙЛ в проектном менеджменте… ээх.
Конечно, понятно, там совсем-совсем не тот «эджайл» что в статье у автора, и некоторые идеи предлагаемые под этим лейблом там тоже есть — и новые, и жизнеспособные… Но степень «истерии вокруг» и «оторванности вообще» сегодняшнего термина «эджайл» от внятного понимания «что же это такое» — это, имхо, иллюстрирует как нельзя лучше.
PS: и это мы еще про «прогрессивный» «девопс» не говорили )))
Буквально — не прменяем agile в том виде и формах, как это предлагается «идеологами легковесных технологий».
Как работаем?
«Вспоминаем классиков»Пытаемся применять принципы масштабирования процесса разработки, заложенные в RUP, причем как это было описано в версиях от Rational (пока методологию еще не испортил IBM своими нововведениями и «принципами бизнес-ориентированной разработки» ).т.е. вместо того, что бы пытаться адаптировать agile к процессам, которые выходят за границы его применимости, мы сразу берем немного другие принципы/артефакты и «утяжеляем» процесс разработки в зависимости от масштаба / сложности / особенностей проекта. И того, как он развивается.
В начале набор фич, названий usecase, архитектурный прототип (который исполняемая архитектура).
По мере развития проекта и его усложнения или измения границ — утяжеляем / расширяем те или иные стадии или процессы, детализируем артефакты, усложняем процесс работы с ними.
Тут главное не слепо копировать техники «описанные в трудах классиков», а понимать какой артефакт, какой процесс в какой из своих форм тебе сейчас нужен и _достаточен_. Те же usecase могут оставаться в форме кратких описаний до конца проекта, если проект не большой и с заказчиком доверенные отношения. Где то хорошо заходят сквозные сценарии, а где то надо хорошо проработать модель данных и вывернуть процесс разработки от моделирования. 6де то надо у заказчика сидеть, а где то надо строго отрабатывать по этапам.
А за ваш опыт — спасибо. Почитаем про описанные вами техники подробнее, глядишь, где и приложится.
«Фигак-фигак… » — это еще ничего.
Вот «стартап в п**дакшен» — вот это действительно страшно.
(:
/OFFTOP
Заметил тут краем глаза: скрипты калькуляторов — они у вас на паскале, что ли?
А бизнес логику / поведение можно скриптовать? Изменить поведение экранной формы?
Скриптануть создание печатной формы? Расчет отчета?
или это я не прошел до конца?
речь шла не об «использовании виндоус в интерпрайзе». Речь шла о конкуренции с java. Винду используют. никто не отрицает. в своей области. на рабочих станциях. word+excell запускать, доступ к веб-интерйесу обеспечивать, да принтером управлять )
Это все написано в том числе и на .net. И это замечательно. Переход от C++ и WinApi к технологиях шарп+дотнет — в их случае улучшил ситуацию. winapi — та еще кака. Но к конкуренции с джавой это не имеет никакого отношения.
С джавой — C# и .NET Core не конкурируют — слишком разные весовые категории и спектр задач. И выйти на конкуренцию с джава они не способны, как минимум пока — в силу неоднократно выше описанных причин — проблемы с обратной совместимостью, зависимостью от единственного поставщика и его изменчивого взгляда на то «как надо», необходимостью переаботки кода «при смене моды».
снова искажаете смысл того что вам говорят и додумываете.
я говорил о том, что «патч меняет поведение системы» — равно как и любое другое вмешательство в систему. Так же говорил, что не имея эталонного описания поведения и процесса проверки — вы не способны выяснить — изменил ли этот патч ещё что либо? — изменилось или нет эталонное поведение (которое вы не должны бы менять ради совместимости).
а вы начинаете рассуждать про что то вам «очевидное». не надо так.
Кроме того, повторюсь, не так важно опенсорс у вас или нет. Важно есть у вас достаточно детальное эталонное описание или нет, доступно оно для потребителя иил нет. У джава машины такое описание есть, оно доступно, и процесс сертификации на совместимость поддерживает соблюдение этих требований. И в итоге совершенно не важно на чем написана у вас ваша джава машина — на какой кодовой базе, опенсорсная она или нет — если она «одинаково вращает байткод» — то это совместимая джава машина. И «на неё можно переезжать».
во первых, ECMA262 соблюдают. не настолько, наверное, насколько хотелось бы — но соблюдают. стараются. и официальный процесс сертификации улучшил бы ситуацию. но уже сейчас те-же Noshorn, V9, Rhino и др джавасрипт-машины вполне совместимы, что бы переносить js-код между ними, и беспокоиться не о том, будет он работать или нет, а беспокоиться о том насколько быстро, и будет ли у вас API для отладки вашего js-кода и насколько это api удобно. Другое дело, что разработка больших систем на языке с динамической типизацией — дело крайне не благодарное, и, имхо, даже глупое, но при медленном процессе, статичности требований, и некой мере безумности авторов — это может сработать.
Ну и, как это может вам ни показаться странным, но с точки зрения сохранности долгосрочных вложений в разработку кода — да, даже такая ситуация во многом лучше, чем текущая ситуация с «шарпы и дотнет».
Что предлагает майкрософт? изменивую моду и следование за ними. Вчера был просто .net, сегодня они вводят модную .net core (под которую надо снова переписывать код), завтра ещё что… каждый чих _единственного_ производителя вливается в хорошую копеечку производителям больших систем — и производители вынуждены петь под эту дудку за свой счет. А это все — в долгой перспективе и с большой кодовой базой — крайне не интересно и крайне затратно.
Потому и удел технологий майкрософт — в их текущем состоянии — небольшие и/или короткоживущие системы — у которых стоимость переработки не слишком велика — утилитакные пакеты, офис, игровые проекты, да тулзы на рабочих станциях. И в этом они, да, хороши) Но это всё — никак не конкуренция с джавой.
вы перемешиваете 2 момента.
во первых я говорил о проблеме смены майнтейнера.
если вы надетесь, что форкнутая, взятая на поддержку новым разработчиком система, без тестов/стандартов/сертификации будет продолжать работать точно так же как старая версия до форка — то вы, извините, наверное, очень наивны или никогда не работали ни с чем сложнее небольших изделий которые сдал и забыл.
видение ситуации и модель поведения в случае проблем типа форкну и подожду нового майнтейнера — это решения из области хомячковых популярных проблем. увы. интерпрайз думает не так. для них прекращение поддержки, смена майнтейнера, невыпуск секьюрити патчей и тп — сильная головная боль попробуйте цб рассказать что вы именно форком и ожиданием нового майнтейнера собираетесь решать риски закрытия платформы — на проекте, где простой системы в 6 часов обернется дефолтом в стране — вас пошлют и еще подопнут в дорожку. в лучшем случае просто «попросят на выход и не мешать дядям решать проблемы».
любой секьюрный патч изменит поведение системы. а у вас в шарпах даже описания эталонной модели нет, что бы понять «а как надо».
соответственно, новая версия ройзена от нового майнтейнера будет накапливать ворох скрытых проблем, которые очень сильно вдарят по разработчикам больших систем.
с джавой же у вас в принципе не будет проблемы смены майнтейнера. у вас уже есть несколько полнодействующих сборок джава машины, гарантированно реализующих одинаковое повещение как минимум в области стандарта. и я не буду ждать пока кто то сделает форк. я просто поставлю альтернативную, уже существующую джава машину, и буду далее обновляться уже с ней.
2. кроме того, вы кажется не понимаете, что в этой ситуации джава отличается от c# как минимум тем, что не оракл выпускает новый стандарт джавы. не только они.
попытка выпустить закрытую не покрытую стандартом и описаниями джаву провалится еще на этапе обсуждения, и в худшем случае приведет к тому же что и с опенОфисом — оракл останется только с торговой маркой вне процесса, а партнеры выпустял либре-Java, от ibm и сообщества, которые будут продолжать поддерживать стандарт как стандарт.
и их новые версии можно будет проверить на соответствие поведению старым по уже существующему процессу сертификации, что обеспечит избавление от проблем с переездом на новую версию платформы, пропатченную, избавленную от секьюрных проблем.
с шарпами все не так, согласитесь.
— — — — — — — — — —
кстати, когда я говорил про то, что «критериям стандартизации и сертификации соответвует только джава» — я совсем забыл про js — у них тоже есть стандарт и описание поведения — ECMA262. (имхо, он путанный до нельзя, но он есть) и ситуация с js как с технологией сейчас во многом похожа с java — замена одного майнтейнера не повлияет на сохранность ваших наработок. несколько джаваскрипт машин конкурируют за популярность и качество соблюдения единого стандарта) хотя, как я знаю, нет единого процесса сертификации и проверки на соответствие стандарту.
вот когда ситуация с c# станет аналогичной хотя бы js — тогда и можно будет говорить, что шарпы начали конкурировать с java. но майкрософту не интересно выпускать контроль за разработкой шарпов из своих рук — потому забудьте про эти мечты.
Альтернативные компиляторы (и даже не сами они, а именно только полностью совместимые друг с другом компиляторы/среды исполнения, которые генерируют одинаково работающий код) — это не самоцель.
Это следствие и признак хорошей среды, хорошей платформы, у которой малые риски потери вложенных в разработку средств.
Это признак хорошей технологиии, которая стандартизирована, тестируется, в которой последствия и проблемы от того, что один из майнтейнеров отвалится — минимальны.
Это признак технологии, в которой действительно есть тесты и стандарты, в которой совместимость — и «обратная между версиями» и «совместимость между платформами» и «переносимость софта между платформами» — не рекламные заявления, а проверяемый результат.
И на сегодня, увы, нет платформ которые соответствовали бы этим качествам — окромя джавы. Увы. Поправьте меня, если я не прав.
Вот скажем — вы же помните, что оракл начал «монетизацию JDK»? Это кого-то волнует? да собственно не особо. потому, что налажены стабильные выпуски OpenJDK, и все просто будут использовать OpenJDK. Потмоу что есть ещё пяток другой джава-машин (ну или был точно) — которые можно взять и начать использвоать. Потмоу что совместимость обеспечивается процессом сертифкации. В итоге — никто особо не парится из-за действий оракла, хотят они свои сборки продавать — ну пожалуйста — может кто и купит. Но окромя оракловой есть ещё несколько других джава машин, и сборок, и майнтенеров джавы среди которых, скажем IBM, и уже его одного хватит не пустить это дело на самотек, вне зависимости от недалекости менеджеров оракла, уже, показавших свою «мудрость» попытавшись спихнуть ОпенОфис на обочину истории.
А вот что вы будете делать _когда_ майкрософт прекратит поддержку Roslyn и, скажем, выпустит .Core2 уже совсем не опенсорсный? да хотя бы поменяет лицензию — мол «теперь все коммерсы дожны платить деньги, за обновления и секьюрити патчи»… И вот если в этот момент у вас нет альтернативного майнтернера, открытого стандарта и процесса сертификации этот стандарт подтверждающего и, собственно реализующего, нет альтернативного компилятора и среды, лишенной этих секьюрити проблем — … в этом случае, перспективы вашего софта — если ваш софт большой, долгоживущий и написан на .core — «печальны», а все деньги вложенные в разработку на шарпах — уже начали накрываться медным тазом. В лучшем случае — вы попадаете на проблемы смены майнтейнера проекта Roslyn — а это дело очень шаткое… или попадаете на непонятные перспективы миграции, или поклонения майкрософту деньгами в новой жизни с .Core2, не опенсорстной и может даже не бесплатной (см условия задачи)…
Вы вот с таким планом проработки рисков и такими песпективами планируется потеснить джаву в корпоративном сегменте? нуну…
ну я вам про козлов, а вы мне про баранов. я не говорил про опенсорсность компилятора ну вот совершенно ничего.
Я смотрю на описание проекта… на майнтейнера… и вспоминаю вышенаписанное мною про то, что …
Вы знаете — вот у руби тоже компилятор опенсортный. Только «10 его портов и 5 реализаций»… они, конечно, совместимы друг с другом, но код работает на них «немного по разному»; версии майнстрима нарушают обратную совместимость, хотя — (по заявлениям) «всё вроде как собирается».
Опенсорс — не гарантия и не залог успеха.
Для сравнения: вспоминаем историю Java: она не была опенсорс насколько я помню. Но у неё была четкая, хорошо документирвоанная модель поведения, набор требований и тестов, процесс сертификации сторонних джава машин. Только на вскидку я могу вспомнть как минимум три джава машины — от Sun, от IBM и от сообщества — OpenJdk.
В шарпах есть что либо подобное? насколько я знаю нет.
>> Обратная совместимость кода присутствует, проекты 5 летней давности вполне себе собираются
и вот опять же… как это доказать? у вас есть стандарты, требования, модель поведения, тесты? как убедиться что у вас — не «хеппи стори выжившего» которому «просто повезло»?
Как взять результат сборки новым компилятором, прогнать его по официальным тестам требований к старой версии языка — и убедиться что поведение старого кода на новом компиляторе _действительно_ не изменяется на всем поле требований к поведению?
Не выйдет же, такую проверку устроить с шарпами, ага?
Что в текущей ситуации остается? верить вам на слово или вашему опыту? ОК, мы верим что вы уверены в своей правоте. А объективно что мы имеем? имееем субъективную точку зрения, предположительно фанатично(?) настроенного разработчика. простите.
Ну и снова про переносимость и отсутствие четкого стандарта. Понимаете… ну вот сделаю я, для примера, порт Roslyn компилятора и .net машины на эльбрус-процессор… И вот как доказать, что моя дотнет-машина работает точно так-же как на большой официальной десктопной платформе?
Где стандарты на поведение .net-байткода и процесс сертифкации компиляторов, разработанных не майкрософтом? вы с подобным подходом прогнозируете успех в интерпрайзе, где уже завоевала признание джава? ну ну.
Говорите у дотнет произволительность выше? да фигня это, извините. железо дешевеет и дешевеет. А вот труд людей, перерабатывающих код — дорожает. Стоимость любого чиха связанного с переработкой кода после выхода очередного компилятора — растет не линейно от объема кода. Потому и вопросы о которых я говрю — крайне серьезны для больших и долгоживущих проектов.
А майкрософт, простите, не сильно то и чешется в этом направлении особо. Они делают популярный продукт. _популярный_. Понимаете? Как руби, как питон, как js — они с ними фактически конкуриют, не с джавой. Джава «в поп-массовой культуре» не популярна))
А интерпрайзу популярность не сильно нужна. Нужна надежность, контролируемость, стабильность, экономия вложений. Один раз написал — и будь уверен что в оно будет не только собираться но и работать точно так же. ну как минимум, пока ты в пределах задокументирвоанного повдеения.
Именно этим джава получила признание.
вы, как минимум, забываете про проблемы обратной совместимости. (вы смешиваете «развитие» и «изменчивость»?). код, написанный 3-5-7 лет назад должен собираться и работать на новых компиляторах точно так же, как и 3-5-7 лет назад на старых компиляторах.
а этого в шарпах, увы, не происходит. по крайней мере как я вижу. только недальновидный будет вкладываться в большие долгоживущие системы на шарпах в таких условиях.
ну и стандартизация с описанием эталонной модели работы языка там тоже не очень то дотягивает до уровня, что бы обеспечить процесс аналогичный сертификации сторонних реализаций джава-машины.
пока эталонный компилятор создает только майкрософт, шарпы будут жить только там, где его двигает майкрософт, а на всех и вся их банально не хватит.
но для не очень больших короткоживущих приложух, с малоизменяющимися требованиями, простыми процессами внутри, отсутствием «бизнес-процессов» и проблем с этим связанных, отсутствием проблем долгой поддержки и постоянного развития — шарпы самое то. и геймдев на юнити — тому прямое доказательство.
ибо боевой истребитель — он не для тех кто только учится.
для учебы — учебные самолетики, простые в управлении.
человек «топил» за руби, но сути вопроса это не меняет:
— 80% проектов на гитхабе сейчас начинают на _этом_языке_!
— а ты посмотри, пожалуйста, сколько этих «проектов» не будут заброшены уже через 2-3 месяца?
(молчит)
вот я вся «суть популярности», имхо. шумиха, мода, раздувание собственной значимости — направленные на, по сути, обман тех, кто «не особо в теме».
если же хотите знать мое мнение, то оценивать надо кластерами, в пространстве с измерениями вида: область задач, объем кода и человекочасы-затрат вложено, время жизни проекта, интенсивность изменений (вкладываемые в работу человекочасы), оценочная стоимость разработки продукта по средней ставке специалиста на рынке и средняя цена этого специалиста, интенсивность изменений требований к по.
про последнее все забывают и ставят на одну планку сравнения «популярности» скажем руби и джаву, забывая, что рефакторинг большого кода в языках с динамической типизацией — совершенно другая лебединая песня, чем автоматическое отслеживание зависимостей и использования типов в языках со статической типизацией.
все языки — хороши в одном и сложны для другого. сравнивать надо сопоставляя схожие по областям и задачам. учебные языки нельзя тащить в «кровавый интерпрайз». в хаосе постоянно изменения ситуации, оно там просто не выживет «нигде и никак», окромя мелких утилит да сервисного скриптования процедур сборки и обслуживания боевого софта. но и учить новичков безднам джавы, если они банально не сталкивались с проблемами, из-за которых тут «устроено именно так как устроено» — рано. не поймут.
но, увы, задаваться этими вопросами… как правило не задаются. мода направлена на поиск очередной серебрянной пули. и, кажется, что «популярные статистики» направлены не на выяснение правды, ибо она сложна и не понятна, а на расчесывание ЧСВ у хомячков и целевой аудитории. имхо. что и есть ответ на поставленный в заголовке вопрос. тоже имхо )
а дальше что, какой движок следующий?
«карусель», конечно, получается — не успели отказаться от Rhino, уже и Nashorn выкидывают.
(имхо, последнего не жалко: я так и не нашел у Nashorn штатного api для программного контроля и отладки скриптов. а вот с Rhino получилось нарисовать собственный отладчик скриптов в нашем окружении. )
но, все-таки — кто в курсе вопроса? ждем возвращения Rhino или будут скрещивать ужа с ежом в формате java+v8?
думали над hdmi _входом_?
признаться, мне постоянно хочется подключить планшет как дополнительный монитор к основному компьютеру когда сижу на работе.
исходя из описания по пункту 2:
1) верно ли я понимаю, что во freemarker нет переменных, которые вы можете создавать в самом шаблоне?
2) есть ли вызов паблик-функций класса? (вызов bean-свойств есть, но это несколько другое)
работать в айти, имхо, сегодня не классно только по 2 причинам:
1. половина заказчиков грезит «мемасиками и хеппи стори», в том числе и с хабра. увы, но да, ребята, я говорю это на хабре) а то что их проект в реальности сложнее на 2 порядка чем хеппи-стори для статьи на 1 страницу — это понимает не так уж и много людей.
2. демпингующая школота, которая реально не понимает на что подписывается. извините еще раз, пожалуйста. ситуация: к заказчику категории пункта 1 приходит бравый молодец пункта 2 и обещает что вот все быстро просто и легко сделаем. и приправливает сверху списком «хеппи стори», да давит на «браво-модно-молодежно». в итоге через год он наконец «прозревает»… что типа «да, не надо было писать это на руби» (не в руби огород камень, а в сторону людей не понимающих границы применимости технологий)… но бюджет уже съеден и остатков не хватит что бы нанять нас и исправить ситуацию. молодец, понимая что тут больше не кормят, валит в туман, проект накрывается медным тазом, а на его место приходит другой молодец, так же браво заявляющий что вот уж он то сейчас все это быстро перепишет. скажем «на питоне, за месяц, чо уж там. сейчас на гитхабе 90% проектов начинают именно на *этом супер языке и мега фреймворке*. „
а ты сидишь рядом с этой воркующей парочкой и тихо материшься, понимая, что будет через год будет точно такой же песец.
видишь что заказчик не понимает что ему впариваю. и что тебя, с опытом и пониманием, видевшего эту ситуацию не раз, не отличают от выпускника “заочной школы программистов на мейллу».
понимаешь, что такой швах творится практически везде, куда ни глянь.
— вот это и мешает. наличие с обоих сторон людей которые не понимают как это работает.
и которые не хотят понимать )) синдром начинающего программиста, сдобренный слащавой рекламой.
слишком много людей сейчас набилось в it, которые к it не имеют практически никакого отношения. увы. Это примерно как в художники, музыканты, психологи будут приходить технари. не выйдет ничего хорошего.
а в остальном работать в it, имхо, не лучше и не хуже чем в любой другой области.
тайпхинты? рад что вам нравится, но для нас это не не аргумент — идеей не пользуемся и в здравом уме и твердой памяти ее закупать в масштабах предприятия никто не будет; есть еще к ней личные претензии по поводу невозможности отобразить структуру анонимных классов в навигаторе по структуре кода, но… отложим. это вообще не по теме сейчас)
работа с мапами удобнее? давайте чуть позже обсудим.
сначала конкретику: как в freemarker сделать вот такие вещи?
пример 1
пример 2
написана на анлийском, но язык простой, читается без проблем.
кстати, никто не хочет взяться за перевод?
собственно мы сейчас им (velocity) и пользуемся, и для проснения функциональности — пара вопросов, если можно:
* можно ли в free maker отправлять на рендеринг шаблоны, созданные динамически в рантайме? например в jsf такой фичи нет — все шаблоны компиляются во время сборки. а с velocity я так могу.
* если в значение строки подставить html — оно отрендерится как html или будет экранированно?
* есть возможность условного рендеринга? т.е. если значение переменной такое — то рендерим этот кусок, если нет то другой? мы часто этим пользуемся, перекладывая часть логики построения на плечи шаблонизатора.
* есть возможность реализовать внутри шаблона цикл? или list — это единственная «расширенная фича»?
* есть ли возможность обращаться к bean-свойствам объекта который погружен в контекст? т.е. я в хешмапе определяю одну переменную, а потом пользуюсь всеми его методами и свойствами, без необходимости в хешмапе определять 20+ значений.
Спасибо.
Мне нужен пример работающего проекта, платформенно независимый, на вашем фреймворке и вашем языке (питон у вас? ну пусть питон и будет), который умеет работать с BLE.
Описание процесса сборки этого проекта под андроидом и под яблоком. Причем в последнем варианте так же сильно интересует процесс сборки и подписания вашего изделия в xcode временными ключами разработчика. И последнее не менее важно, потому что я собирал на огрызке проекты на LibGDX и C++\Qt — и в обоих случах сценарий стыковки проекта с механизмами подписания был не самым тривиальным и разным — потому очень интересует как это делать у вас.
Ждем от вас публикации.
Спасибо.
ЗЫ: и да, демки работы с BLE на C++\Qt я вчера таки собрал и запустил на огрызке. огрызок правда 5-й или 4-й, но на халяву другого не досталось). Теперь ход за вами — ждем аналогичной демки на Kivy.