Тут знаете ли, всякие штуки про разработку пишу. И смежные темы. Больше двадцати лет жизни отдал этому балагану, надо опытом делиться. Вводный текст.
Вытаскиваю из живого ревью проекта. Какие три вопроса следует адресовать, и что конкретно получить, прям с самого начала анализа и погружения в разруливание бардака.
Британский регулятор хочет денег. Если вы там есть, платить скорее всего придется. Вопрос за что, и сколько; давайте смотреть.
История о том, как пара десятков людей в 2006-2009 собрались и зажгли. Сделали интернет и образование таким, которое вы знаете сейчас.
Мой комментарий в одном из федеральных СМИ. Раскрою тему. Почему лучше регулировать хреново, чем остаться без инструмента совсем.
Можно привлекать новых, можно удерживать старых. Но не получится одними инструментами и механиками делать это одновременно.
JWT, подписанный веб-токен, штука неплохая. Но на практике вылезают вопросы, которые с ним как-то надо решать. Не все решаются красиво. Инструментик не универсальный.
Как делать правильно. Неправильно — когда медиа-контент мессенджера (социалки) доступен по прямой ссылке, и типа ее никто не знает. Позволю себе оттоптаться по популярной теме, с решением.
Регулятор, намучившись с горе-кодописателями, вместе с гайдами выпускал ряд документов «по дизайну». То есть не чего будут хотеть, а как конкретно лучше сразу проектировать (design) те или иные системы, чтобы потом не было вопросиков задорого. И чтобы юзерданные в блокчейне не лежали.
HADI, CJM, JTBD, RICE/ICE, RAT. Разработка и методы, чтобы не впадать в ступор, когда/если вас о них спросят. Привязываем сокращения к смыслу.
Есть ряд решений, для которых добавление любых «фичей» несет сильно больше минусов, чем плюсов. «А еще вот это добавим» там не работает, особенно если вас об этом никто не просил.