​​Как правильно ездить в отпуск

Я боюсь отпусков. Просто потому что не люблю терять контроль над ситуацией. Но не отдыхать я тоже не могу. Вот что я делаю, чтобы не волноваться.

1. Чаще всего коллеги достаточно компетентны (если нет, надо с этим что-то делать) и они не сломают все за эти две-три-четыре недели. Нужно принять это и довериться им.
2. Перед отпуском важно довести все свои задачи до логического завершения или подробно рассказать кому-нибудь как их довести. Нельзя оставлять зависшие проблемы.
3. Не планировать по возвращении из отпуска сразу что-то выпустить — скорее всего не получиться, а стресс будет. Стоит признать, что первые два дня после отпуска будут потрачены на возвращение в рабочий ритм и разгребание накопившегося долга.

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

#softskills

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

Весь декабрь Тим Маринин рассказывал о том как делать инди-сайты. Вчера вышел последний пост и теперь можно прочитать все скопом: 24 дня индивеба — адвент-календарь постов про Индивеб.

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

Решения для себя

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

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

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

​​Астрологи объявили неделю асинхронной коммуникации

- Работай асинхронно — простые правила эффективной (не)блокирующей работы

- Асинхронное общение — руководство по асинхронной коммуникации внутри команды, преимущества и недостатки (по версии автора, их нет)

- Взгляд со стороны EcmaScript на общую теорию ООП — отличный разбор объектно-ориентированного программирования в JavaScript, его отличий от других языков

- Сообщение об ошибке, от которого не горит — очередное размышление на тему хороших сообщений об ошибках

- Как организовать работу над библиотекой общих компонентов — опыт разработки UI-кита от Тинькофф

#дайджест

Как делается заказная разработка

Лёня из @breadhead рассказал о заказной разработке в первой половине подкаста «Почему продукт важнее маркетинга?». Это совсем не про технологии, но очень интересно.

#softskills

Сейчас читаю и конспектирую «Создание микросервисов». Вот вам конспект первой главы.

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

Преимущества подхода:
- возможна технологическая разнородность;
- легко достигается изящная деградация;
- отдельные части системы независимо масштабируются;
- независимое развертывание сервисов;
- простое разделение отвественности между командами.

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

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

#микросервисы

Кстати, напоминаю, что микросервисы — это не только бекенд. Посмотрите хороший доклад про микро-фронтенды.

Микро-фронтенд

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

Сейчас вокруг многие обсуждают микросервисы на фронтенде. Значит немного странно, но, вероятно, нам это нужно.

Тематический доклад — Разрываем монолит.

#фронтенд #архитектура

​​С Новым годом, друзья 🎉

Спасибо, что читаете этот канал.

​​Немножко статей для чтения на праздниках. Две софт-скиловые, одна совсем простая и одна очень серьезная.

+ Работа программистом, свой бар и квест-рум: последние полгода я совмещаю это всё — автор боится не выдержать конкуренции с молодыми специалистами через 10-20 лет и готовит запасные варианты, звучит как отличная идея

+ Good times create weak men — программисты теряют экспертизу, размышления о причинах и последствиях

+ Качество кода — довольно попсовая статья о способах сделать код лучше, очень базовая, но качественная

+ Функциональное программирование: дурацкая игрушка, которая убивает производительность труда (часть 1, часть 2) — ну тут все понятно, просто прочтите

#дайджест

​​Осознанная меркантильность

Можно сколько угодно говорить о внутренней мотивации, любви к продукту, сложным задачам или крутой команде, но в любом случае, за работу программисты получают деньги. И это одна из основных причин работать. Ответьте себе честно, если бы вам разрешили работать вдвое меньше за те же деньги, согласились бы вы?

Тематическая статья — Осознанная меркантильность.

#softskills

Архитектор развития

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

Работа архитектора в меньшей степени касается конкретных сервисов и в больше степени — их связей, пространства между микросервисами, способов их взаимодействия.

Основные отвественности архитектора:
• определение концептуального технического устройства системы;
• умение сотрудничать в лидерами отдельных команд для выработки архитектурных решений;
• коррекция уровня автономности команд.

#микросервисы

На Хекслете вышла статья «Преждевременная оптимизация: абсолютное зло или иногда полезная практика?», в которой кажется все специалисты выразили завидное единодушие. Почитайте.

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

Всех нас занимают вопросы: «Как стать лучшим инженером?», «Как расти профессионально?». На них в целом, похоже нет ответов. Зато можно попробовать изменить отдельные аспекты своей работы.

Хороший тематический доклад — Мерцание технологий, или Инжиниринг.

#softskills #рост

​​Зачитываюсь книгой про микросервисы, поэтому статей на этой неделе совсем мало 😢

+ Архитектура программного обеспечения переоценена, простой и понятный дизайн — недооценен — архитектура ПО не то, чем кажется, отличный обзор от Гергелия Ороса (чувак из Uber)

+ Понимание брокеров сообщений — вообще-то это книга, но на Хабре сейчас выходит ее перевод по главам, первая глава — хорошее введение в тему

+ Метапрограммирование в JavaScript и TypeScript — немногие разработчики пользуются приемами метапрограммирования, а это мощная концепция, которая может сильно упросить код

#дайджест

Я читаю много статей на английском, но почему-то не хотел их добавлять в дайджесты. Добавить?
anonymous poll

Да – 254
👍👍👍👍👍👍👍 92%

Нет – 21
👍 8%

👥 275 people voted so far. Poll closed.

Типизация

Я большой адепт ограничений. Люблю, когда инструмент заставляет меня писать лучший код. Строгая статическая типизация — это как раз такие ограничения. Да, нужно больше думать, тратить больше времени. Зато результат получается лучше.

Но, к сожалению, в JavaScript-мире я не могу получить желаемого. Самый популярный инструмент типизации TypeScript дает мне статическую слабую типизацию. Плюс в нем довольно плохо работает вывод типов, очень мягкие правила проверки типов по умолчанию. Этого мало. Поэтому, я с интересом смотрю на альтернативные решения. Elm, Scala.js, PureScript — это все очень весело, но абсолютно бессмысленно. Слишком непопулярные решения, которые требуют менять кодовую базу.

Недавно наткнулся на Hegel.js — это статический типизатор, которые переваривает аннотации типов от TypeScript, но лишен его проблем. Если этот проект дойдет до продакшн-реди состояния, я обязательно возьму его в пару проектов. Доклад автора на HolyJS — Как и зачем я пишу свой статический типизатор.

Что такое сильная/слабая и статическая/динамическая типизация рассказывал тут.

#языки

Шрифты

Во фронтенд разработке есть две проблемы: подключение шрифтов и настройка CORS.

Вадим Макеева рассказал в докладе все о шрифтах в вебе: как их правильно подготовить (сжать, обрезать) и подключить. Смотрите его доклад со странным названием _ __ _____?.

С CORS все сложнее, пару месяцев назад осерчал и запилил мини-тред в твиттере.

#фронтенд

Как моделировать сервисы

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

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

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

Делить сервисы по ограниченным контекстам (понятие Эрика Эванса из книжки DDD) — хорошая идея.

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

Сервисы не должны делиться по принципу «владения данными», лучше смотреть на бизнес-возможности.

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

#микросервисы

​​Суббота начинается с дайджеста статей. Насладжайтесь.

+ О 30-кратном увеличении параллелизма в Node.js — отличная история рефакторинга, который сэкономил компании 300 тысяч долларов за год;

+ Делаем HTTP-запросы, изящно деградируем (и ни единого разрыва) — хорошая статья про аккуратную работу с сетью;

+ Чем программирование сегодня отличается от программирования 20 лет назад? — очередное размышление на тему плачевного состояния нашей индустрии, но в этот раз справедливое.

И еще три англоязычные статьи:

+ Goodbye, Clean Code — Дэн Абрамов рассказывает когда нужно и когда не нужно делать код «чистым»;

+ How to move your project to TypeScript - at your own pace — статья о постепенном переводе приложения на TypeScript без большой единовременной траты времени;

+ who are you trying to impress with your deadlines? (перевод) — критика необоснованных дедлайнов, замораживания состава спринта, очень актуальная тема.

#дайджест