kamyshev.code
2.12K subscribers
40 photos
565 links
Архитектура, код, софт-скиллы и всё остальное. Вопросы, пожелания, комментарии — @igorkamyshev

https://kamyshev.me
Download Telegram
Изучение разных языков программирования очень полезно. Это позволяет перенимать интересные концепции и лучшие практики разных экосистем и писать лучший код.

Отличный подкаст «Мысли и методы» про разные подходы к исполнению программ — интерпретацию и компиляцию, про системы типов.

#языки
Близится стабильный релиз Deno.

Тематическая статья — Deno: время Node.JS уходит?

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

Deno пытается стать лучшей версией Node, но не может. Он не решает текущие проблемы Node.js, но приносит кучу новых. Он похож на редакс — идея может и красивая, но в жизни все будет совсем не так.

Если кто-нибудь верит в Deno, напишите, пожалуйста, почему — @igorkamyshev

#языки #спор
На скорость работы программиста сильно влияет переключение контекста. То есть примерно так. Если выполнить две задачи последовательно — это займёт 2 дня. А если попытаться делать их параллельно — 3.

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

#процесс #softskills
​​Очень давно не публиковал дайджестов 🤓

- Вопросы будущему работодателю — о важных вещах, которые лучше уточнить на собеседовании

- Будущее программирование — Никита Тонский рассуждает о будущем и ворчит на настоящее

- Разработчик, который не думает, а просто делает — не нужен? — о ценности разработчика для бизнеса и его задачах

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

- Десять вещей, которые можно делать с GraalVM — разбор областей применения и причин использования GraalVM (возможно, на этой штуке скоро будут работать все модные бекенды)

#дайджест
Under JS

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

Недавно начал слушать UnderJS Podcast. И он совсем другой. В нем разбирают более глубокие темы, обсуждают разное и интересное. Недавно были выпуски про Haskell, про Dart, рассуждение на тему стейт-менеджеров. Если вам близок JS-мир, послушайте этот подкаст.

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

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

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

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

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

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

#общие_знания
Решения для себя

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#фронтенд #архитектура
​​С Новым годом, друзья 🎉

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#дайджест