Заметки с тегом «Программирование»

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

Я использую MacBook Pro 14" 2022 года. Когда я работаю дома, ноутбук подключён к монитору LG UltraFine 4K прошлого поколения — кажется это единственный монитор с честной ретиной и нативным для мака DPI. Поколение монитора важно — подробнее см. обзор на «Вёрдже».

Я не использую два дисплея, поэтому ноутбук работает Clamshell mode. Единственное исключение — стримы: для них я открываю на ноутбуке Open Broadcaster Software.

В качестве органов управления я использую Happy Hacking Keyboard и Magic Trackpad. Мои пальцы не могут изогнуться, чтобы воспользоваться странной клавишей, которую засовывают в русских раскладках между левым шифтом и z, поэтому я всегда покупаю американские клавиатуры, вот — клавиатура ноутбука:

Полный список железок:

• MacBook Pro 14" 2022, Apple M1 Max, 64Gb RAM
• Монитор LG UltraFine 4k  на кронштейне Ergotron LX Desk Monitor Arm
• Клавиатура Happy Hacking Keyboard Pro Hybrid Type-S
• Внешний тачпад Magic Trackpad 2
• Веб-камера Razer Kiyo Pro
• Микрофон Shure SM7B со штангой Blue Compass
• Микрофонный предусилитель SE Electronics DM1
• Звуковая карта Focusrite Scarlett 2i2
• Наушники Sony MDR-7506

Поскольку я работаю стоя, напишу пару слов про стол. Сначала я работал за обычным икеевским столом, собранным из самой дешёвой столешницы и регулируемых ножек, но в какой-то момент эта конструкция меня достала —из-за высоты стол сильно шатался. Задумав поменять стол, я посмотрел на рынок и сильно удивился — меньше, чем за 20 000 ₽ высокий стол не купить, причём даже самые дорогие экземпляры, судя по обзорам на ютубе, не отличаются надёжностью.

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

Софт

Я не люблю IDE, и в роли редактора кода использую neovim. Долгое время я сидел в Visual Studio Code, но конце 2021 года я устал бороться с увеличивающимся количеством скрепышей фич, плюнул и перешёл на neovim в терминале iTerm2:

Основные плагины:

• coc для автодополнения, которое понимает язык (LSP)
• fzf для быстрого открытия файлов
• nerdcommenter, чтобы быстро комментировать куски кода
• vim-vinegar, когда нужно походить по файловой системе

В качестве оболочки я использую прекрасный fish. Если хотите так же — посмотрите на мои файлы конфигурации на гитхабе.

Знаний всегда больше, чем можно выучить. А то, что выучивают айтишники, становится неактуальным в 10 раз быстрее, чем в других областях.

Посмотрите на историю серверной инфраструктуры: 20 лет назад были большие железные серверы. Сисадмины с важным видом настраивали RAID, патчили FreeBSD и выдавали программистам права доступа. Потом появились виртуальные машины — теперь, чтобы выкатить софт, стало не нужно думать про RAID-массивы и FreeBSD: нажал кнопочку и получил работающую машину.

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

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

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

В любой здоровой компании есть атмосфера критики. Кто бы ни пришёл с идеей: акционер, CEO или линейный сотрудник, его идею обязательно обсуждают и валидируют. Автору задают важные вопросы: «мы это делаем, чтобы что?», «если это не заработает, то из-за чего?» и тд. Такая резка фич, ещё до продакт-менеджера.

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

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

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

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

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

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

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

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

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

Чаще всего набор фиче-флагов формирует фронтенд, и отсылает на бекенд в момент каждого запроса. Так можно легко ставить a\b тесты — просто выбираем две когорты, одной добавляем фичу, а другой — нет, и смотрим на поведение.

Пример реализации — GitHub, который передает фиче-флаги в HTTP-заголовках. Прямо сейчас в API гитхаба таким образом включается-выключается одновременно 30 фич.

Есть ещё одно очень полезное применение фиче-флагов — полное отключение функций приложения в зависимости от среды. К примеру, у нас ЦРМ есть фича — уведомлять пользователя по СМС о статусе заказа. Но я не хочу, чтобы СМС уходили с тестовых стендов или из CI, даже если кому-то хватит ума прописать боевые ключи на них. Поэтому я делаю фиче-флаг ENABLE_NOTIFICATIONS и включаю его только в переменных окружения на проде. По умолчанию флаг выключен, поэтому где мы ни развернули мой бекенд — он никогда не пошлет сообдщений живым людям, если его явно об этом не попросить.

См. также:

• Подробное объяснение пользы фиче-флагов от самого Мартина Фаулера
• Launch Darkly — централизованное управление включенностью фич
• Unleash — то же самое, но бесплатно и self-hosted