Популярное за всё время

Провели сегодня мега-совещание про работу разработки с дизайнерами. Покажу вам, какое письмо я разослал по окончании встречи.

Размер и сложность продукта растет, старые процессы уже не выдерживают. Копится недовольство с обоих сторон и вообще, нужно было поговорить.

Резюме совещания:

про макеты:
- постепенно создаем один мастер-макет, в котором отрисованы все форматы медузы и в который добавляются новые, перестаем использовать отдельные маленькие макеты как источник правды;
- с помощью этого мастер-макета постепенно уменьшаем количество разных элементов, выносим все общие элементы в стайлбук;
- если в новых форматах есть неочевидные моменты (заголовок изменился на 1 пункт, так просто не заметишь) — указываем эти комментарии прямо рядом элементом, на полях артборда;
- этот мастер-макет храним в версионированном хранилище с возможностью просмотра диффов и автоматическими уведомлениями о правках (скорее всего github + скетч-плагин, но если найдем хороший SaaS — то вполне может и на него сядем);

про совместную работу:
- задача разработчиков — в процессе разработки (чем раньше тем лучше, идеально во время приемки) найти недорисованные/недодуманные моменты и сказать о них дизайнеру. Например, если не учтена ситуация, когда одно из полей пустое — не очевидно, какие отступы делать в этом случае. Дизайнер дорисует эти кейсы и/или добавит в макет комментарий, объясняющий логику;
- если что-то очень сложно сделать на платформе (белая тень, хитрый блюр, etc.) — обсуждаем это с дизайнером. Что нужно в разговоре? 1) объясняем что именно сложно сделать и почему 2) предлагаем решение, как вы думаете можно упростить/сделать по другому 3) приходим вместе к компромиссу. Никто не требует делать безумные хаки, которые дорого поддерживать и которые ломаются с апдейтом чего-нибудь. Все мы хотим классный продукт и дизайнер мог просто не знать/забыть о платформо-специфичной вещи;
- вывод: Не стоит допридумывать то, что не описано/не нарисовано. Нужно договариваться. Молча делать отлично от макета запрещено;

В заключение: разработчики — полноценные члены продуктовой команды. Думайте о продуктовых фичах, задавайте вопросы, предлагайте идеи. Не все они будут реализованы, часть задвинем в дальний ящик и никогда до них не доберемся. Это нормальный рабочий процесс — то же происходит с идеями редакции, дизайнеров и даже Ильи. Мы (разработчики) обладаем уникальным знанием того, как это всё будет реализовано в конечном счете. Без нашего участия сделать классный продукт невозможно.

Теперь о том, где, как и с кем это всё обсуждать.

1. О каких-то мелких непониманиях по дизайну стоит писать в личку Насте, Вите и Насте; можно созвониться-пошарить экран и тд, если текст не решает;
2. О крупным вещах, которые хочется обсудить с командой и с дизайнерами — пишите прямо в #dev или в проектный канал типа #dev-prodano
3. Если это тема в проектной работе, которая требует осмысления и обсуждения — круто завести для неё карточку в трелло-доске проекта и заменшенить в комментарии всех причастных. В трелло обсуждения не теряются и можно посмотреть толком историю переписки по конкретному вопросу.

Воспользуюсь случаем и напомню, что текущие проекты, предстоящие задачи и icebox (то, что хочется сделать, но хз когда) можно посмотреть в доске «проекты разработки» — он открыт для всех, изучайте и дополняйте, пожалуйста.

-----

А как вы строите работу дизайнеров с программистами? Делитесь в @ctodailychat, интересно послушать ваши истории.

Этот блог называется запуск завтра, а у нас на самом деле завтра запуск самого крупного проекта Медузы so far.

Приложения в сторах раскатываются по читателям, письмо рассылки сверстано. Осталось сделать импорт записей из одной внешней системы в наш собственный бэкенд и влючить ручку API.

Каждый запуск — как экзамен в универе, перед ним страшно, даже если всё приготовил и знаешь предмет 🙈

Один из крупнейших интернет-маркетплейсов страны Wildberries не работает вторые сутки и не называет ни причину падения, ни сроки, когда проблемы будут исправлены.

Главная страница открывается, но пропали все данные о прошлых заказах, нельзя оформить новый заказ, в личном кабинете не отображается даже имя пользователя.

Учитывая, что сами они ничего не говорят, предположу, что компания потеряла большую часть базы данных из-за аварии или хакерской атаки и пытается восстановить данные из бэкапов.

Проверяйте бэкапы, это дешево, могу помочь! И зовите меня с Федей, если вдруг авария, в которой не можете разобраться, у нас есть опыт тушения пожаров (дорого).

Отдельно обращу внимание на отвратительную внешнюю коммуникацию. Берите пример с Cloudflare, они хорошо объясняются, когда что-то идет не так.

Гугл опубликовал пост-мортем по позавчерашнему падению. Обычные ошибки, только на инфраструктуре планетарного масштаба.

У них есть внутренний сервис, который проверяет доступы (бабки, квоты и т. д.) перед тем, как API запрос доходит до любого продукта.

Эта программа берет из специальной глобальной базы данных правила, по которым проверяет каждый запрос и отвечает, пропускать его или нет.

В эту программу добавили поддержку нового типа квот. Программист допустил небрежность в новом коде и не проверял, насколько корректно записано это правило в базе, перед тем, как пытаться положить его в память. Обращение к несуществующей памяти — смертный грех, за такое программа мгновенно завершается (если программист не предусмотрел, что такое может случиться, а это не наш случай). При этом я бы не назвал это ошибкой, все мы люди, мы не идеальны и поэтому придумываем механизмы защиты от своей природы. В этом суть инженерного подхода.

Экземпляр этой программы работает в каждом регионе Гугла. Так как это серьезный, ключевой сервис, его выкатывают не во все регионы сразу, а по одному, внимательно отслеживая, не внесли ли программисты новые ошибки.

Более того, весь новый функционал специально помечают и сначала запускают только для внутреннего пользования, чтобы, даже при наличии ошибки, она не задела внешних клиентов. Этот механизм называется фича-флагами.

К сожалению, программист забыл настроить фича-флаги для этого кода. Кусочек программы с ошибкой запустился на всех пользователей сразу. Удивительно, что это не заметили на этапе code review!

Итак, проходит время, и вот программа с ошибкой запущена во всех регионах для всех пользователей. Кто-то добавляет в базу данных новое правило с новым типом квот, с пустым полем. Эта запись в течение десятков миллисекунд копируется во все регионы, и в каждом регионе программа проверки считывает новое правило, пытается обратиться к несуществующей памяти, падает, перезапускается и снова падает.

Тут в дело вступает, на мой взгляд, первая ошибка (а не просто человеческая небрежность) инженеров — система контроля доступа настроена так, что при отсутствии ответа от программы проверок она отклоняет запрос. Так называемый fail closed. Хорошо для замков на банковских сейфах, плохо для пожарных выходов.
В нашем случае система не пропускает ни один запрос.

Дежурные инженеры замечают проблему в течение 2 минут, за 10 минут находят причину (дежурная система и дежурные инженеры у Гугла достойны восхищения) и нажимают большую красную кнопку, которая должна выключить эту часть программы (ее программисты сделали). Ее включение занимает еще 30 минут. (Не понятно, почему этот механизм занимает 30 минут, а не 20 миллисекунд, но движемся дальше).

Система заработала, но из-за того, что она лежала 40 минут, накопилось много желающих отправить запрос еще раз, и они создали эффект толпы, которая набежала и перегрузила остальные соседние сервисы через наш сервис проверок. Оказалось, что он не ждет какое-то время, если нужный сервис отказывается ответить на запрос (для этого есть красивая схема exponential back off), а долбит до упаду, тем самым не давая системе возможности восстановиться. Пришлось руками ограничивать число запросов. На постепенную, ручную разгрузку очередей ушло еще 2 часа.

Ко всему прочему, Гугл час не мог опубликовать уведомление о проблеме, потому что сервис публикации статус-страниц зависит от системы, которая упала.

Как вывод, Гугл обещает пройтись по всем сервисам и убедиться, что они, во-первых, fail open, то есть пропускают запросы, когда падают, во-вторых, реализуют exponential back off, если на их запрос не отвечают, а не добивают лежачего, и, наконец, в-третьих, что даже глобальные добавления правил должны прилетать во все регионы не сразу, а с некоторыми задержками. Ещё обещают добавить эти проверки в свои статические анализаторы кода, завидую!

Первые два пункта можно и нужно использовать в каждом проекте, даже если ты не Гугл.

Помните, «кремлевские хакеры» ломали оппозиционеров через краденые смски?

«Коммерческие хакеры» начали использовать дыру под названием SMS в промышленных масштабах для опустошения банковских счетов законопослушных бюргеров. А значит, не далек день, когда мы перестанем пользоваться смсками для любых штук связанных с безопасностью. Наконец-то.

Чтобы вы не удивлялись, протокол GSM (2G) — 1987 года выпуска, контрольный протокол SS7 — 1975 (это не опечатка).

Учитывая, что нас уже больше 3 тысяч, я чувствую некоторую ответственность, так что вот социальная реклама: используйте Google Authenticator для получения одноразовых кодов, не смс. И включите 2-факторную аутентификацию, пароль слишком легко потерять.

Подъехали подробности про блокировку fable 5.

Крестная мать баг-баунти програм (она запустила bug bounty в Microsoft и в Минобороны США, не баран чихнул), Кейти Муссурис, прочитала технический документ, который послужил основой для блокировки.

Говорит, что когда fable 5 дали на вход программу и попросили найти уязвимости, она отказалась. И тогда исследователь попросил модель исправить ошибки в этой программе. И подготовить тесты, чтобы проверить, исправлены ли они на самом деле.

Всё, это весь «взлом».

Можно конечно такое починить, но тогда модель станет абсолютно бесполезной для разработки софта.

🍿🍿

Аааа МТС. Висит уже больше часа https://agileday.mts.ru/

Космическая история: фронтендеры Ютуба убили Internet Explorer 6, без согласования с руководством разместив баннер «мы скоро перестанем поддерживать этот браузер, поставьте что-нибудь посвежее» в июле 2009.

Чтобы вы понимали контекст, в июле 2009 года это был браузер четверти пользователей интернета. IE6 было уже 8 лет, он глючил, тормозил и решительно не подходил для современного интернета 2009го, но ни один крупный сайт не был готов сказать четверти пользователей интернета «сорян, ваш браузер — говно».

Фронтендеры ютуба совершили настоящий заговор, протащили релиз мимо QA, переводчиков, вообще всех и задеплоили его на на один из самых популярных сайтов в интернете.

В 2009, IE6 ненавидили уже все фронтендеры без исключения. Практически сразу после запуска баннера на Youtube, фронтендеры Google Docs использовали пример Ютуб как обоснование для того, чтобы выкатить такой же баннер на Google Docs (все думали, «вряд ли Ютуб провернул такое без соответствующих согласований»). Иронично, но когда о баннере узнали в руководстве ютуба, они решили, что это просто копия баннера с Google Drive («и кто-то наверняка согласовал это ранее»).

Когда правда вскрылась — было уже поздно, баннер был практически на всех сайтах в интернете, а IE6 —обречен. Цель оправдывает средства.

Рассказывает один из участников заговора (там есть, как отреагировали юристы и PR-щики). 💎

число открытых вкладок, когда пытаешься разобраться с необычным запросом в API фейсбука
слава Аллаху, что у меня мощный ноутбук и большой внешний монитор

Удивительно, на какие ухищрения идут Яндекс и Фейсбук, чтобы отследить, на какие веб-сайты мы ходим.

Если на вашем Андроид-телефоне установлен Инстаграм или Яндекс.Карты, то при открытии веб-страниц с трекером Фейсбука или Яндекса соответствующая компания знает, что это именно вы открыли веб-страницу. Не спасут даже режим инкогнито и отдельный браузер.

Для этого они, ни много ни мало, запускают локальный веб-сервер прямо на мобильном устройстве.

После публикации статьи Фейсбук перестал это делать, Яндекс — продолжает. Производители браузеров спешно исправляют уязвимость.

Под iOS это не работает только потому, что там нельзя запустить долгоживущие фоновые процессы, это сделано для экономии батареи.

Интересно, наложит ли кто-то из европейских регуляторов оборотные штрафы?