Тестирование считается завершенным, когда пройдет 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) и уже это значение передать в регистр перед вызовом прерывания.
Погодите, транслятор ещё не запускался. Пока мы видим код, написанный программистом. И чтобы передать корректное число байт, ему нужно помнить, сколько занимает каждый символ.
Сценарий "свайп, свидание, разочарование, повторить" для них идеальный.
Неправда! Идеальный – это когда юзер зашёл 10 лет назад, оформил подписку, а отменить забыл 😁
Шутка только отчасти – такие тоже есть. А вообще, как и в любом бизнесе, многое зависит от репутации. Если бы онлайн дэйтинг был столь безнадёжным занятием, аудитория очень быстро сошла бы на нет. Поэтому мы, разумеется, заинтересованы в том, чтобы предоставить эффективные инструменты поиска пары. Иначе это сделают конкуренты, и юзеры уйдут к ним.
Интересно ваше мнение: мы, где то, допустили важную ошибку или что то недопроверили?
Мне кажется провальной изначальная идея о возможности организации свиданий. Это, возможно, могло бы сработать в масштабах одного [небольшого] города – но не страны, и тем более, в мировом. А при столь ограниченном охвате денег не заработать.
Что до матчинга идей – это не что-то необычное, у нас тоже есть пункт анкеты с описанием идеального первого свидания. Так что назвать это конкурентным преимуществом сложно. В любом случае это вторично, в первую очередь всё равно смотрят на фото, а анкеты читают уже потом.
Ещё одна явная ошибка: вы разрешали создавать пустые профайлы. Это не имеет смысла, они не работают. Нужно требовать заполнить хотя бы основные данные при регистрации. Те, кто пришёл именно с целью найти пару, это не отпугнёт – они понимают, что иначе никого заинтересовать не смогут. А те, у кого цели другие, нам не нужны.
Рынок весьма насыщенный и сложный, а последние пару лет ещё и в явном даунтренде. Чтобы преуспеть, нужен комплекс услуг (а не единичная фишка), и немаленькие затраты на покупку трафика.
🤔 Это что-то специфичное для индивидуалов? У меня сейчас под корпоративным эккаунтом 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 байт.
А если не "hello", а "привет"? И не в 1251, а в UTF-8.
Неправда! Идеальный – это когда юзер зашёл 10 лет назад, оформил подписку, а отменить забыл 😁
Шутка только отчасти – такие тоже есть. А вообще, как и в любом бизнесе, многое зависит от репутации. Если бы онлайн дэйтинг был столь безнадёжным занятием, аудитория очень быстро сошла бы на нет. Поэтому мы, разумеется, заинтересованы в том, чтобы предоставить эффективные инструменты поиска пары. Иначе это сделают конкуренты, и юзеры уйдут к ним.
Мне кажется провальной изначальная идея о возможности организации свиданий. Это, возможно, могло бы сработать в масштабах одного [небольшого] города – но не страны, и тем более, в мировом. А при столь ограниченном охвате денег не заработать.
Что до матчинга идей – это не что-то необычное, у нас тоже есть пункт анкеты с описанием идеального первого свидания. Так что назвать это конкурентным преимуществом сложно. В любом случае это вторично, в первую очередь всё равно смотрят на фото, а анкеты читают уже потом.
Ещё одна явная ошибка: вы разрешали создавать пустые профайлы. Это не имеет смысла, они не работают. Нужно требовать заполнить хотя бы основные данные при регистрации. Те, кто пришёл именно с целью найти пару, это не отпугнёт – они понимают, что иначе никого заинтересовать не смогут. А те, у кого цели другие, нам не нужны.
Рынок весьма насыщенный и сложный, а последние пару лет ещё и в явном даунтренде. Чтобы преуспеть, нужен комплекс услуг (а не единичная фишка), и немаленькие затраты на покупку трафика.