Какой алгоритм принимает решение поменять сириус на альтаир? Что отражает это изменение, если, судя по номеру, это вообще одна и та же сборка?
SemVer в своей полной версии перекрывает все потребности версионирования. А решение о присвоении номера версии должно приниматься на этапе сборки. У меня, например, сборка запускается по добавлению определённого тега к ветке: release-x.x.x. Или release-x.x.x-RCx. Какой функционал включён, ломает ли этот релиз совместимость – на момент сборки известно, и проставить корректный номер никакого труда не составляет. А программисты при коммитах используют номера тикетов, о том, в какую версию их коммит войдёт, им задумываться не нужно – зато в тикетах автоматически появляются ссылки на все связанные с ними коммиты.
Кроме того, есть ситуации, в которых ваш подход в принципе не работает. Например, при деплое в App Store можно передать только версию в формате х.х.х и номер билда, всё.
Создание нового репо при смене версии выглядит не менее странно. Опять же, я могу пометить текущее состояние любым тегом и потом хоть какие изменения делать – это не помешает мне при необходимости вернуться в данной версии. Такое ощущение, что у вас не очень умеют готовить гит, простите уж.
В 2019 году успех измеряли velocity и выполненными спринтами, а в 2024 году уже перешли на time-to-market,
Возможно, в Раффайзен так и было. Но обобщать не стоит: я начинал работать по эджайлу в 2002, если мне память не изменяет, и уже тогда единственным смыслом его внедрения было именно сокращение времени вывода продукта на рынок. Откуда вся эта глобальная статистика в статье, я не знаю.
Третий сценарий предполагает наиболее радикальное изменение. В нём Agile-коучинг перестаёт существовать как отдельная профессия и растворяется внутри управленческих и продуктовых ролей.
А он с самого начала был не нужен. Скорее, даже вреден – ибо в этом качестве зачастую выступали люди, прочитавшие пару книжек, но не имевшие вообще никакого опыта практической реализации проектов, ни в эджайле, ни без оного – но тем не менее, вообразившие себя носителями некого сакрального знания. "Низкий порог входа", ага.
Agile-коуч в 2029 году. Кто это вообще будет
С общим посылом раздела согласен практически полностью (распределение и содержание ролей же всегда будет специфичным для конкретной организации), а вот с датой нет. Там, где эджайл (а не его имитация) есть – оно давно уже примерно так. Организацией процессов занимаются конкретные менеджеры в рамках общей политики компании, и никакие коучи им нафиг не нужны.
Тестирование считается завершенным, когда пройдет 14 дней. В каждый из этих дней приложение должно быть запущено как минимум 12 людьми.
🤔 Это что-то специфичное для индивидуалов? У меня сейчас под корпоративным эккаунтом 23 приложения, и ни к одному подобные требования не предъявлялись. Когда релизил последние 3, аппрув занял буквально пару часов. Более того, я ошибся и залил предварительную версию одного из приложений сразу в продакшн трэк, с выключенным managed publishing – и она моментально ушла в Google Play, пришлось срочно снимать с публикации, а потом перепубликовывать окончательную.
Недавно писал здесь: упрятывание ключей API в коде, их размещение в секретных репо и т.п. не имеет ни малейшего смысла. Всё равно они элементарно сниффятся с использованием легальных, общедоступных инструментов. Упомянутая в статье привязка к конкретному сертификату сервера могла бы помочь, но имеет очень ограниченную область применения: сертификаты имеют ограниченный срок действия, а заставить всех клиентов обновить приложения после истечения этого срока мы не можем, с высокой вероятностью они просто решат, что приложение сломалось и перестанут им пользоваться. А с внешними сервисами типа того же firebase это в принципе невозможно, мы ротацию их сертификатов не контролируем.
Применение ключей API – всего лишь первый, самый базовый уровень защиты. Аутентикация и разграничение доступа должны обеспечиваться совсем другими средствами.
Конечно это не серебряная пуля и при желании, проанализировав декомпилированный код, можно прочитать скрытые секреты в рантайме, вынеся их в другую среду исполнения
Да не нужно ничего анализировать и выносить. Трафик пропускается через любой прокси (Charles, Wireshark, whatever) и все ключи как на ладони. А если это веб, то DevTools в браузере открыть достаточно.
но это куда сложнее, если бы они лежали в открытом виде
Ничуть, не надо вообще в коде копаться, смотришь данные любого запроса и получаешь искомое. Ключ API не должен использоваться, как единственное средство аутентикации/разграничения доступа. По крайней мере за пределами внутреннего периметра.
Выравнивание добавили, попросили показать, где же мусор
Тут никакого выравнивания не было. Когда добавили, мусор исчез. Я писал о том, что конкретные, проведённые в тексте и комментариях примеры кода правильно работать не будут. Но не о том, что работающий код в принципе невозможен.
термин Scrum для итеративной модели разработки был предложен ещё в 1991 году
Спасибо, не знал. Повидимому, всё, как обычно: мало произвести хороший продукт, надо его ещё и хорошо продать. В этом смысле именно Манифест явился поворотным пунктом, сумев привлечь внимание широких кругов. До него единичные попытки были, но таки повсеместно использовался именно waterfall.
Ну так итеративные системы вполне есть и без аджайла, я же про это.
Вы путаете вывеску с содержанием. В наше время эджайл – общепринятое обозначение методологий, основанных на коротких итеративных циклах. Даже если сама методология была разработана до появления этого понятия. Термин прижился именно в разработке ПО, в других сферах не встречал – хотя похожие подходы используются не только в программировании.
я не учу других Agile, я консультант в другой сфере.
С удовольствием почитал бы Вашу статью, касающуюся Вашей сферы компетенции. Про эджайл не нужно – я только на один момент указал, но на самом деле в статье спорных (как минимум) утверждений полно.
Да, Agile Manifesto – не методология. Как и устав компании – не правила внутреннего распорядка. Это идеологическое обоснование итеративной модели разработки – как альтернативы повсеместно использовавшемуся на тот момент waterfall. SCRUM, кстати, появился сильно позже, и не нужно всё время ссылаться именно на него, как синоним Agile.
В банковской сфере или здравоохранении документирование и согласования неотъемлемы, что делает чистый Agile невозможным.
Я свой первый эджайл проект делал для SwissRe: второй по величине в мире перестраховочной компании. Регулирования у них там никак не меньше, чем у банков. Очень даже возможно, ничто не мешает к моменту сертификации у регулятора подходить мелкими итерациями с непрерывной обратной связью от заказчика.
Вообще я уже писал, и ссылку давал. Это сработает только на восьмибитных процессорах – что нынче экзотика. Ибо компилятор будет выравнивать адреса данных по границе слова, и во многих случаях получим мусор в конце строки.
Вместо одного большого водопада мы создаем множество маленьких, автономных циклов.
По-моему, у автора путаница в тех самых понятиях, с определения (в целом правильного) которых начинается статья. Это не SCRUM в частности, а эджайл вообще так работает. Разбиение на короткие циклы есть неотъемлемая часть любой эджайл методологии. Пока что ничего, специфичного именно для SCRUM в статье нет.
Так это то же самое, что кастомный strlen. Я же не утверждаю, что на ассемблере вообще невозможно выводить строки произвольной длины и в разных кодировках. Речь только о том, что данная реализация такого не предусматривает.
Это невозможно. В том числе, и в вашем варианте:
Какой алгоритм принимает решение поменять сириус на альтаир? Что отражает это изменение, если, судя по номеру, это вообще одна и та же сборка?
SemVer в своей полной версии перекрывает все потребности версионирования. А решение о присвоении номера версии должно приниматься на этапе сборки. У меня, например, сборка запускается по добавлению определённого тега к ветке: release-x.x.x. Или release-x.x.x-RCx. Какой функционал включён, ломает ли этот релиз совместимость – на момент сборки известно, и проставить корректный номер никакого труда не составляет. А программисты при коммитах используют номера тикетов, о том, в какую версию их коммит войдёт, им задумываться не нужно – зато в тикетах автоматически появляются ссылки на все связанные с ними коммиты.
Кроме того, есть ситуации, в которых ваш подход в принципе не работает. Например, при деплое в App Store можно передать только версию в формате х.х.х и номер билда, всё.
Создание нового репо при смене версии выглядит не менее странно. Опять же, я могу пометить текущее состояние любым тегом и потом хоть какие изменения делать – это не помешает мне при необходимости вернуться в данной версии. Такое ощущение, что у вас не очень умеют готовить гит, простите уж.
Очень научно. У меня всё куда проще: прикидываем трудоёмкость и умножаем на π/2. Подозреваю, что точность прогноза примерно одинакова.
Возможно, в Раффайзен так и было. Но обобщать не стоит: я начинал работать по эджайлу в 2002, если мне память не изменяет, и уже тогда единственным смыслом его внедрения было именно сокращение времени вывода продукта на рынок. Откуда вся эта глобальная статистика в статье, я не знаю.
А он с самого начала был не нужен. Скорее, даже вреден – ибо в этом качестве зачастую выступали люди, прочитавшие пару книжек, но не имевшие вообще никакого опыта практической реализации проектов, ни в эджайле, ни без оного – но тем не менее, вообразившие себя носителями некого сакрального знания. "Низкий порог входа", ага.
С общим посылом раздела согласен практически полностью (распределение и содержание ролей же всегда будет специфичным для конкретной организации), а вот с датой нет. Там, где эджайл (а не его имитация) есть – оно давно уже примерно так. Организацией процессов занимаются конкретные менеджеры в рамках общей политики компании, и никакие коучи им нафиг не нужны.
Источник можно?
А она была, та инфраструктура? Помимо канавы вдоль улицы, в которую из окон выливали ночные горшки?
Честно говоря, не знаю. У меня нет нужды длительно использовать комп в автономке, просто не было случая проверить.
🤦♂️ Кофе, подогреть? Это что же за бурда получится?
🤔 Это что-то специфичное для индивидуалов? У меня сейчас под корпоративным эккаунтом 23 приложения, и ни к одному подобные требования не предъявлялись. Когда релизил последние 3, аппрув занял буквально пару часов. Более того, я ошибся и залил предварительную версию одного из приложений сразу в продакшн трэк, с выключенным managed publishing – и она моментально ушла в Google Play, пришлось срочно снимать с публикации, а потом перепубликовывать окончательную.
Недавно писал здесь: упрятывание ключей API в коде, их размещение в секретных репо и т.п. не имеет ни малейшего смысла. Всё равно они элементарно сниффятся с использованием легальных, общедоступных инструментов. Упомянутая в статье привязка к конкретному сертификату сервера могла бы помочь, но имеет очень ограниченную область применения: сертификаты имеют ограниченный срок действия, а заставить всех клиентов обновить приложения после истечения этого срока мы не можем, с высокой вероятностью они просто решат, что приложение сломалось и перестанут им пользоваться. А с внешними сервисами типа того же firebase это в принципе невозможно, мы ротацию их сертификатов не контролируем.
Применение ключей API – всего лишь первый, самый базовый уровень защиты. Аутентикация и разграничение доступа должны обеспечиваться совсем другими средствами.
Да не нужно ничего анализировать и выносить. Трафик пропускается через любой прокси (Charles, Wireshark, whatever) и все ключи как на ладони. А если это веб, то DevTools в браузере открыть достаточно.
Ничуть, не надо вообще в коде копаться, смотришь данные любого запроса и получаешь искомое. Ключ API не должен использоваться, как единственное средство аутентикации/разграничения доступа. По крайней мере за пределами внутреннего периметра.
Запутались.
Тут никакого выравнивания не было. Когда добавили, мусор исчез. Я писал о том, что конкретные, проведённые в тексте и комментариях примеры кода правильно работать не будут. Но не о том, что работающий код в принципе невозможен.
Согласитесь, ни в одном из предыдущих примеров этого не было 🙂
Спасибо, не знал. Повидимому, всё, как обычно: мало произвести хороший продукт, надо его ещё и хорошо продать. В этом смысле именно Манифест явился поворотным пунктом, сумев привлечь внимание широких кругов. До него единичные попытки были, но таки повсеместно использовался именно waterfall.
Вы путаете вывеску с содержанием. В наше время эджайл – общепринятое обозначение методологий, основанных на коротких итеративных циклах. Даже если сама методология была разработана до появления этого понятия. Термин прижился именно в разработке ПО, в других сферах не встречал – хотя похожие подходы используются не только в программировании.
С удовольствием почитал бы Вашу статью, касающуюся Вашей сферы компетенции. Про эджайл не нужно – я только на один момент указал, но на самом деле в статье спорных (как минимум) утверждений полно.
Да, Agile Manifesto – не методология. Как и устав компании – не правила внутреннего распорядка. Это идеологическое обоснование итеративной модели разработки – как альтернативы повсеместно использовавшемуся на тот момент waterfall. SCRUM, кстати, появился сильно позже, и не нужно всё время ссылаться именно на него, как синоним Agile.
🤦♂️ Серьёзно? И Вы пытаетесь учить других, что такое эджайл?
Я свой первый эджайл проект делал для SwissRe: второй по величине в мире перестраховочной компании. Регулирования у них там никак не меньше, чем у банков. Очень даже возможно, ничто не мешает к моменту сертификации у регулятора подходить мелкими итерациями с непрерывной обратной связью от заказчика.
Вообще я уже писал, и ссылку давал. Это сработает только на восьмибитных процессорах – что нынче экзотика. Ибо компилятор будет выравнивать адреса данных по границе слова, и во многих случаях получим мусор в конце строки.
По-моему, у автора путаница в тех самых понятиях, с определения (в целом правильного) которых начинается статья. Это не SCRUM в частности, а эджайл вообще так работает. Разбиение на короткие циклы есть неотъемлемая часть любой эджайл методологии. Пока что ничего, специфичного именно для SCRUM в статье нет.
Так это то же самое, что кастомный
strlen. Я же не утверждаю, что на ассемблере вообще невозможно выводить строки произвольной длины и в разных кодировках. Речь только о том, что данная реализация такого не предусматривает.Не, не взлетит 😁 См.