Ограничения Apple не позволяют нам портировать текущую версию Firefox на устройства под управлением iOS (iPhone, iPad, iPod Touch). Мы изыскиваем новые способы по созданию Firefox для iOS, но не имеем определённых планов по его выпуску.
Мне всего одна станция по кольцу. Я успеваю только авторизоваться и скачать апдейт для reeder.app. Но про эти баннеры наслышан. Ещё один поинт в копилку внедрения https://
После анализа, они сразу упадут в один из спринтов или же будут запланированы в большой roadmap — Эту функцию уместнее всего будет запустить одновременно на всех платформах, поэтому запускам в Апреле.
Зависит от задачи очень сильно. Бывают, что предложенные (внутри, снаружи) идеи попадают в спринт, а затем и в релиз. Обычно нужно больше времени на исследовать, сделать прототип.
Да, вешаем со статусом «Need Info». Мы стараемся брать в работу только исследованные и понятные задачи, в которых есть все необходимые данные, информация о внешних зависимостях.
А, если не секрет, как решаются проблемы, когда одна задача ломает другую, уже оттестированную, и когда вообще гонятся регрессы?
Полные регрессы происходят при подготовке релизов. Отдельные задачи проходят code review и тестирование перед вливанием в стабильную ветку. Стараемся делать атомарные изменения, чтобы ничего не взрывалось.
Что бывает с тасками, которые не прошли тестирование и не укладываются в спринт, в какой момент принимается решение, что они в спринт не войдут?
У нас все задачи проходят тестирование, кроме совсем тривиальных syntax fix'ов. У нас, как правило, нет жестких deadline'ов, поэтому когда мы понимаем, что не успеваем сделать задачу, то просто переносим её в следующий спринт.
И, не очень понятно, верстку отделили от бэкенда — теперь они у вас просто в отдельных спринтах параллельно или чередуются, как решаются проблемы взаимодействия, когда один компонент нельзя катить без другого?
Задачи бэкэнда вёрстки живут в нашем спринте. Есть другой уровень «бэкенда», который живёт отдельно. Но мы не начинаем делать интерфейсы, пока этот уровень не готов хотя бы частично.
habrastorage.org/files/492/b07/9e4/492b079e4cbb49998992823b49d6dfd3.png
habrastorage.org/files/6da/0e3/8b8/6da0e38b8ace42ac8c03b1fd3f407868.png
https://support.mozilla.org/ru/kb/dostupen-li-firefox-dlya-iphone-ili-ipad
Какой % людей пользуется firefox на android? Сколько из них установило adblock?
Проблему тулбаров надо решать разговорами с оператором :)
navigator.userAgent. Пытаются определить устройство.или можно создать пустой , например.
Но я надеюсь, что Билайн прочитает этот пост и отключит панельку всем :)
Так вначале и было, но потом я решил немного странное сделать — github.com/sbmaxx/datauri/commit/0c9d36b83ff850029d5fd97650a88faaa55f5d4e
Речь же не про GZip, а целесообразность подключёния библиотеки ради стрельбы по воробьям.
$('#id'), если подключёна jQuery.reeder.app. Но про эти баннеры наслышан. Ещё один поинт в копилку внедренияhttps://Зависит от задачи очень сильно. Бывают, что предложенные (внутри, снаружи) идеи попадают в спринт, а затем и в релиз. Обычно нужно больше времени на исследовать, сделать прототип.
Да, вешаем со статусом «Need Info». Мы стараемся брать в работу только исследованные и понятные задачи, в которых есть все необходимые данные, информация о внешних зависимостях.
Полные регрессы происходят при подготовке релизов. Отдельные задачи проходят code review и тестирование перед вливанием в стабильную ветку. Стараемся делать атомарные изменения, чтобы ничего не взрывалось.
У нас все задачи проходят тестирование, кроме совсем тривиальных syntax fix'ов. У нас, как правило, нет жестких deadline'ов, поэтому когда мы понимаем, что не успеваем сделать задачу, то просто переносим её в следующий спринт.
Задачи бэкэнда вёрстки живут в нашем спринте. Есть другой уровень «бэкенда», который живёт отдельно. Но мы не начинаем делать интерфейсы, пока этот уровень не готов хотя бы частично.