Тестирование считается завершенным, когда пройдет 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. Я же не утверждаю, что на ассемблере вообще невозможно выводить строки произвольной длины и в разных кодировках. Речь только о том, что данная реализация такого не предусматривает.
Вы удивитесь, но в ассемблере именно так: программисты сами, руками считают байты. Нельзя написать
mov edx, strlen(text)
Такой инструкции просто нет.
Тут предлагали вычислять по смещению памяти – уже лучше, но тоже не будет работать. Во-первых, совершенно разные сегменты памяти. Во-вторых, компилятор будет выравнивать адреса данных по границе 16/32/64 бит, и если длина в байтах не кратна 2/4/8, в конце строки будет мусор.
Единственный вариант универсального решения тут: добавить в конец строки символ-терминатор (традиционно 0), вычислить в ассемблерном коде её длину (своя реализация strlen) и уже это значение передать в регистр перед вызовом прерывания.
Погодите, транслятор ещё не запускался. Пока мы видим код, написанный программистом. И чтобы передать корректное число байт, ему нужно помнить, сколько занимает каждый символ.
Источник можно?
А она была, та инфраструктура? Помимо канавы вдоль улицы, в которую из окон выливали ночные горшки?
Честно говоря, не знаю. У меня нет нужды длительно использовать комп в автономке, просто не было случая проверить.
🤦♂️ Кофе, подогреть? Это что же за бурда получится?
🤔 Это что-то специфичное для индивидуалов? У меня сейчас под корпоративным эккаунтом 23 приложения, и ни к одному подобные требования не предъявлялись. Когда релизил последние 3, аппрув занял буквально пару часов. Более того, я ошибся и залил предварительную версию одного из приложений сразу в продакшн трэк, с выключенным managed publishing – и она моментально ушла в Google Play, пришлось срочно снимать с публикации, а потом перепубликовывать окончательную.
Недавно писал здесь: упрятывание ключей API в коде, их размещение в секретных репо и т.п. не имеет ни малейшего смысла. Всё равно они элементарно сниффятся с использованием легальных, общедоступных инструментов. Упомянутая в статье привязка к конкретному сертификату сервера могла бы помочь, но имеет очень ограниченную область применения: сертификаты имеют ограниченный срок действия, а заставить всех клиентов обновить приложения после истечения этого срока мы не можем, с высокой вероятностью они просто решат, что приложение сломалось и перестанут им пользоваться. А с внешними сервисами типа того же firebase это в принципе невозможно, мы ротацию их сертификатов не контролируем.
Применение ключей API – всего лишь первый, самый базовый уровень защиты. Аутентикация и разграничение доступа должны обеспечиваться совсем другими средствами.
Да не нужно ничего анализировать и выносить. Трафик пропускается через любой прокси (Charles, Wireshark, whatever) и все ключи как на ладони. А если это веб, то DevTools в браузере открыть достаточно.
Ничуть, не надо вообще в коде копаться, смотришь данные любого запроса и получаешь искомое. Ключ API не должен использоваться, как единственное средство аутентикации/разграничения доступа. По крайней мере за пределами внутреннего периметра.
Запутались.
Тут никакого выравнивания не было. Когда добавили, мусор исчез. Я писал о том, что конкретные, проведённые в тексте и комментариях примеры кода правильно работать не будут. Но не о том, что работающий код в принципе невозможен.
Согласитесь, ни в одном из предыдущих примеров этого не было 🙂
Спасибо, не знал. Повидимому, всё, как обычно: мало произвести хороший продукт, надо его ещё и хорошо продать. В этом смысле именно Манифест явился поворотным пунктом, сумев привлечь внимание широких кругов. До него единичные попытки были, но таки повсеместно использовался именно waterfall.
Вы путаете вывеску с содержанием. В наше время эджайл – общепринятое обозначение методологий, основанных на коротких итеративных циклах. Даже если сама методология была разработана до появления этого понятия. Термин прижился именно в разработке ПО, в других сферах не встречал – хотя похожие подходы используются не только в программировании.
С удовольствием почитал бы Вашу статью, касающуюся Вашей сферы компетенции. Про эджайл не нужно – я только на один момент указал, но на самом деле в статье спорных (как минимум) утверждений полно.
Да, Agile Manifesto – не методология. Как и устав компании – не правила внутреннего распорядка. Это идеологическое обоснование итеративной модели разработки – как альтернативы повсеместно использовавшемуся на тот момент waterfall. SCRUM, кстати, появился сильно позже, и не нужно всё время ссылаться именно на него, как синоним Agile.
🤦♂️ Серьёзно? И Вы пытаетесь учить других, что такое эджайл?
Я свой первый эджайл проект делал для SwissRe: второй по величине в мире перестраховочной компании. Регулирования у них там никак не меньше, чем у банков. Очень даже возможно, ничто не мешает к моменту сертификации у регулятора подходить мелкими итерациями с непрерывной обратной связью от заказчика.
Вообще я уже писал, и ссылку давал. Это сработает только на восьмибитных процессорах – что нынче экзотика. Ибо компилятор будет выравнивать адреса данных по границе слова, и во многих случаях получим мусор в конце строки.
По-моему, у автора путаница в тех самых понятиях, с определения (в целом правильного) которых начинается статья. Это не SCRUM в частности, а эджайл вообще так работает. Разбиение на короткие циклы есть неотъемлемая часть любой эджайл методологии. Пока что ничего, специфичного именно для SCRUM в статье нет.
Так это то же самое, что кастомный
strlen. Я же не утверждаю, что на ассемблере вообще невозможно выводить строки произвольной длины и в разных кодировках. Речь только о том, что данная реализация такого не предусматривает.Не, не взлетит 😁 См.
Вы удивитесь, но в ассемблере именно так: программисты сами, руками считают байты. Нельзя написать
Такой инструкции просто нет.
Тут предлагали вычислять по смещению памяти – уже лучше, но тоже не будет работать. Во-первых, совершенно разные сегменты памяти. Во-вторых, компилятор будет выравнивать адреса данных по границе 16/32/64 бит, и если длина в байтах не кратна 2/4/8, в конце строки будет мусор.
Единственный вариант универсального решения тут: добавить в конец строки символ-терминатор (традиционно 0), вычислить в ассемблерном коде её длину (своя реализация
strlen) и уже это значение передать в регистр перед вызовом прерывания.Погодите, транслятор ещё не запускался. Пока мы видим код, написанный программистом. И чтобы передать корректное число байт, ему нужно помнить, сколько занимает каждый символ.
А при чём тут транслятор? Там в syscall (aka int 0x80) явно передаётся размер строки 5 байт.