💁‍♂️ и я завел подкаст — в нем я буду разговаривать в умными людьми об умных вещах. И первый выпуск про DevOps c Сашей Фаткулиным.

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

В этот раз мы обсудили вот что:
+ что такое Docker, зачем он нужен и почему все им пользуются;
+ как в современном мире принято запускать приложения и следить за их работой;
+ про повседневную работу DevOps, программирование и велосипеды;
+ как Самокат пережил нагрузку из-за короновируса;
+ почему облачные провайдеры — не всегда лучший выбор;
+ про страшный факап и его починку.

Если вы не знаете что такое подкасты и как этим пользоваться, вот инструкция.

Пожалуйста, напишите свои впечатления мне @igorkamyshev, мне правда важно узнать, как оно вам.

Пыщ пыщ, добавил подкаст в Яндекс.Музыку

https://music.yandex.ru/album/11893440

Продолжаю осваивать новые платформы — выложил подкаст на YouTube.

Подписывайтесь, ставьте лайки, нажимайте колокольчик 👇

https://youtu.be/tccehPUEUXk

Прочитал небольшую книгу Naming Things (за пару часов можно управиться). Она не даёт какой-то ультимативно новой информации, но рассматривает именование всего немножко с другой стороны.

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

#общие_знания

Сходил в в гости к подкасту «Сделайте мне красиво». Рассказал как устроены фронтенды внутри Авиасейлс, про наши боли и радости.

Получилось удивительно бодро, послушайте.

https://soundcloud.com/begebot/ep43

Svelte — это новый и очень модный фронтенед фреймворк. О нем начали говорить года полтора назад, я тогда взглянул на него и решил, что ничего интересного внутри нет.

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

#фронтенд

Кайф:
1. Реактивность из коробки — шок и трепет, почти работает (столкнулся с одним багом и пришлось сделать все немножко иначе);
2. Slots, Event Forwarding — мелочи, которых очень нехватает в Реакте;
3. Очень много вещей для которых в Реакте нужны сторонние библиотеки тут есть из коробки (скоупинг стилей, управление состоянием, транзишны).

Не кайф:
1. Это уже не JS, семантика многих конструкций совсем другая — магические значки доллара, экспорты как объявление пропсов;
2. Сомнительная интеграция с TS, я попробовал, сходу не завелось и забил;
3. Очень много магии, Реакт-приложение можно запустить прямо в браузере (только JSX придется выкинуть), тут же результирующий код совсем далек от того, что я написал.

Svelte — это интересная технология. Я, пожалуй, попробую его на более крупном проекте.

#фронтенд

Знаете, меня очень печалит, что для создания мобильного приложения нужно две отдельные команды разработки — iOS и Android. Чувствую в этом какую-то внутреннюю неправильность. И поэтому я с интересом наблюдаю за всеми инициативами по созданию фреймворков кросс-платформенной разработки.

Я радовался, когда выходил Xamarin, писал на React Native и хочу попробовать сделать серьезное приложение на Flutter. И поэтому я позвал большого специалиста по Flutter, Евгения Кота, чтобы расспросить его о Dart, Flutter и вот этом всем.

Евгений Кот — директор по разработке в пражском отделении Wrike. А Wrike — самая дартовая компания России, они писали на нем, когда это было полным безумием (как мне тогда казалось).

Мы поговорили про историю создания и первой «смерти» Dart, про неожиданную популярность Flutter, его сильные и слабые стороны. Обсудили текущее положение дел на рынке, погрустили про Flutter for Web и Fuchsia OS.

А в небольшом послешоу выяснили, что общего у XCode и монорепозиториев.

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

Доклад в основном про C# (и немного F#), но сами подходы ценны в любой экосистеме.

#фп #архитектура

В IT есть темы, в которых я ничего не понимаю. И самая темная из них — сети. Я очень примерно представляю как работает интернет, но в подробностях всегда теряюсь.

На самом деле, такие базовые вещи важно знать не только админам, которые с этими сетями работают каждый день, а любому специалисту, сталкивающемуся с Интернетом.

Встретил на днях хорошую статью, которая понятно и подробно объясняет все что нужно знать.

Сети для начинающего IT-специалиста. Обязательная база

#общие_знания

Контракты — это ещё один способ увеличить надежность программы. Это и валидация, и парсинг, и проверка типов. Класс! Но мне всегда казалось, что в JS-мире это неудобно и костыльно.

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

#фронтенд

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

https://www.notion.so/kamyshev/4ab00ab272e144a69a10242e826dad72?v=6f679602f9ad41f0913dc638bcfc1aab

Стоит ли тут рассказывать о новых заметках в этом документе?
anonymous poll

Да 🤓 – 149
👍👍👍👍👍👍👍 96%

Нет 🤫 – 7
▫️ 4%

👥 156 people voted so far.

Сегодня утром посмотрел крутой доклад про архитектуру — Быстрорастворимое проектирование.

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

В докладе весь код приводится на C#, но подходы применимы к любому языку (с небольшими правками, конечно)

#проектирование #архитектура

На прошлой неделе писал про мои заметки с быстрыми решениями, добавил туда новую напоминалку — про JS-функцию, которая типографирует русские тексты.

https://www.notion.so/kamyshev/036b55da6eb44540b941d66c07e0857b

#js

Массово выкидываем старый код

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

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

Вообще, наша глобальная цель — сделать так, чтобы в репозитории не было кода, которые не «видят» пользователи. Думаю, это достойная цель для любого проекта.

#кейс #рефакторинг

Одержимость тестированием

Ниже речь пойдет только о веб-приложениях, которые легко и безболезненно деплоить.

В Самокате у нас был примерно такой флоу релиза:
+ планируем версию, накидываем таски, которые в неё попадут;
+ каждая таска проходит через QA;
+ когда все таски сделаны, собираем контейнер версии, которую собираемся релизить;
+ QA делают регрессионное тестирование;
+ катим в продакшн;
+ QA делают смоук-тест.

Короче, мы много заморачивались на тестировании, старались избежать даже самых мелких багов на продакшене.

В Aviasales все устроено совсем иначе. Разработчик делает таску, другой разработчик ее тестирует и заодно смотрит код, после — катим таску на продакшн, потом ещё 10 минут смотрим за фоном ошибок и метриками.

В такой парадигме код доставляется клиентам сильно быстрее. А самое удивительное, что и багов больше не стало. Мне подход «смелых релизов» нравится больше.

#кейс #тестирование

Мы там в чатике обсуждали последний пост и я понял, что он получился не полным. Продолжение 👇

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

Просто 95% задач не такие и с ними можно обращаться проще.