Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— How Pinterest Scaled Its Architecture to Support 500 Million Users Очередная статья о том, как в бигтехе решали проблемы. Сегодня это pinterest, который справлялся с трудностями роста количества посетителей. Когда компания только появилась — никто не ждал нагрузки и приоритет в разработке отдавался скорости выкатки фичей. А как только пошла нагрузка — компания переехала в aws. Текст выше рассказывает об эволюции технической системы в компании. Сначала рассказывается как изначально выглядела структура системы (веб + несколько сервисов + mySQL). После чего начался рост: трафик увеличивался вдвое каждые 6 недель. Добавили cassandra, редис начали использовать для кэширования. Понравилась мысль, что вместо постоянного добавления технологий, компания решила сфокусироваться на качестве и надежности. Так, выкинули cassandra, mongodb и mbase, а фокус инженеров направили на mysql и редис. В случае мускуля возникла проблема с горизонтальным масштабированием, что решилось шардами. А редис выбрали для реалтайма. Далее описывается как компания переезжала на распределенную систему, с собственной обработкой задач и service discovery поверх zookeeper. Без кафки для приложения и мониторинга тоже не обошлось. #how_it_works ————————————— Patterns of Legacy Displacement Лонгрид с сайта фаулера написанный инженерами thoughtworks. Текст начинается с рассуждений о том, почему бизнес хочет изменить техническую систему (капабилити бизнеса не закрываются текущей системой). Попутно описываются три причины, по которым подобная модернизация проваливается: расхождение между ожиданием и реальностью, отсутствие изменения в организации, большие релизы. Далее описывается, как можно разорвать «порочный круг» подобных изменений. Для этого стоит разобраться с четырьмя категориями: понять что хотите, разбить проблему на задачи, зарелизить задачи, изменить организацию под новую тех систему. А в тексте найдете подробное описание каждой из категорий. При этом, для каждой из категорий дается список инструментов, который поможет. Так найдете упоминание EventStorming, каннари релизов, создание новой компании и так далее. Во второй части текста приводится пример, где удалялся избыточный интеграционный слой в системе. #modernization ————————————— I am sorry, but everyone is getting syntax highlighting wrong Сегодня в подборке пятничная и холиварная статья связанная с цветовой подсветкой кода от Тонского. Я сам отказался от подсветки кода в 18 году, по причине того, что в моей голове «подсветка» работает иначе, чем в редакторе. Связанно это с тем, что то, что важные «объекты» не подсвечивается, а то, что не так важно — подсвечивается слишком ярко. Из-за чего появляется дополнительная сложность с «перекодировкой» цветов. Плюс пестрые темы отвлекают больше, чем помогают. Главную мысль текста можно охарактеризовать цитатой «если выделено всё, то ничего не выделено». Чтобы к ней прийти, вначале описывается зачем цвета нужны (поиск по цветам и проверка корректности объектов). Далее описывается как и что можно выделять: числа, top-level definitions, пунктуацию (кроме ключевых слов самого языка), комментарии. После поднимается холиварная тема со светлой/темной темой. Ну а в конце дается пример «хорошей» схемы. Русский перевод #code