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

Преимущества

Слои раскладки. Все сплиты глубоко кастомизируемы, а потому вам больше не потребуется ломать пальцы на шорткатах в четыре кнопки. Настраиваете слои раскладки и получаете, например, такое:
— Hold T — открыть новую вкладку в браузере
— Hold W — закрыть текущую вкладку
— Отдельная клавиша на скобки (), чтобы не зажимать Shift
— Отдельная клавиша $, чтобы ещё быстрее набирать $foo = $bar
— Свой слой макросов для Idea, чтобы не упражняться в йоге для пальцев, пытаясь быстро выжать ⌥+⌘+L одной левой

Можно настраивать раскладки всё свободное время. Что может быть лучше, чем сидеть по вечерам и раскидывать по слоям скобки и макросы, ощущая интеллектуальное превосходство над ~98,51% населения планеты?

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


Как клавиатура делает больно

Производитель честно предупреждает, что первый месяц будет мучительно больно
— Скорость печати показала отрицательный рост. Было 60 слов в минуту, стало 15
— Новый ZSA Moonlander стоит под 400 $, но я купил БУ за полцены
— Придётся покупать вторую домой. Говорят, если привыкнуть, на обычной уже работать не хочется

Как я докатился до этого

Раньше я жил как нормальный человек, но потом нашёл на сингапурской свалке кресло Herman Miller Embody, которое в магазине стоит полторы тысячи американских долларов. Находка положила начало моему пути эргономиста. Я стал сидеть прямо, с локтями на подлокотниках и ладонями на клавиатуре. Но с обычной это оказалось неудобно, поэтому я обзавёлся сплитом. Через месяц напишу об ощущениях и результатах.

Мы с @slobodator заключили джентльменское пари на 50 евро: смогу ли я довести до конца обучение слепой 10-пальцевой печати или брошу это занятие и вернусь к старой доброй традиции печатать 4,5 пальцами.
Андрей ставит на то, что я брошу!

Срок: 2 месяца
Минимальна скорость печати: 150 зн\мин

Пока я полон оптимизма и новая клавиатура подпитывает меня.
Вернусь к вам через 2 месяца 😎

Буквально мы с Серёжей

Теперь немного подушним. За свою карьеру я-таки заметил одну вещь, от которой у меня пригорает. Многие разрабы не умеют в инкапсуляцию, от чего кишки классов и модулей часто вываливаются наружу.

Рассмотрим на примере. Представим что у нас есть вот такой класс:

class Disease {
 var confirmed: Confirmed
}

enum class Confirmed {
 YES, NO, NOT_SPECIFIED
}

Мы можем подтвердить диагноз или отклонить его. Как бы вы реализовали?
Нам обычно попадается такое:

fun setConfirmed(confirmed: Confirmed){
 // какие-то проверки
 this.confirmed = c
}

У такой реализации есть недостатки. Клиент теперь чуть больше знает о реализации вашего модуля: оказывается, есть какой-то енумчик, который нужно передать внутрь. Ещё это сложно рефакторить: как найти все места, в которых передается Confirmed.YES, учитывая что значение не везде передается константо? А если мы захотим поменять YES на CONFIRMED, сколько классов придется поправить? А можно ли передавать в метод NOT_SPECIFIED или же мы получим ошибку?

Пример примитивный, но объём кучи навоза уже можно прикинуть. И многие разработчики не думают, как грамотнее инкапсулироваться, вываливают всё наружу, а потом жалуются, что у них всё слиплось.

Правильнее сделать примерно так:

fun confirm(){
 // какие-то проверки
 this.confirmed = Confirmed.YES
}

fun decline(){
 // какие-то проверки
 this.confirmed = Confirmed.NO
}

fun confirmed() = this.confirmed == Confirmed.YES

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

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

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

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

Можно подумать, что так делают только джуны, но нет. Так пишут и солидные дядьки с бородой.

И речь не об энтитях, что мы сохраняем в базу данных, а о модулях в принципе. Если это библиотека, значит, ей будет невозможно пользоваться без предварительного изучения внутренностей. Если что-то спрятанное за интерфейсом, придётся найти реализации и смотреть, в каком порядке что вызывать. В микросервисах — выяснять, на каком стеке он сделан и какая СУБД пользуется.

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

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

В каждой шутке есть доля шутки

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

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

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

Хороших выходных!

Когда ты играющий тренер программирующий тимлид

Сегодня я разговаривал с одним CTO, и он сказал, что парное программирование они внедрить никак не могут, потому что тогда разработка фич замедлится в два раза. Ведь сейчас две фичи делаются параллельно, а после внедрения два разработчика будут над одной задачей работать.

Да, говорит, парное программирование повышает качество кода. Но мы этого добиваемся, введя двойное код-ревью.
Я спрашиваю: и сколько времени вы закладываете на ревью кода и правки после ревью?
Столько же, говорит, сколько и на первоначальный кодинг фичи!

И пока я не нашёл листочек, не порвал его на две части и не показал ему наглядно, что даже по его критериям парное программирование не станет дороже, он не мог этот факт принять.

А в реальности я уверен, что процесс ещё и ускорится, так как разработчикам не придётся переключать контекст со своей задачи на "чужую" и обратно.

Кстати говоря, кому нужно получать два аппрува, чтобы залить изменения в мастер?

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

Результаты пари смогу ли я научиться слепой печати

Итог 35-40 слов в минуту слепой печати с нуля за 50 часов практики

Практическая польза
- Удовлетворение от обладания навыком — есть
- Опечаток стало меньше
- Скорость печати — около 35 слов в минуту
- Перестал печатать целое преложение на не правильной раскладке, ругаться, стирать и опять печатать в той же раскладке

Стоит ли оно того?
Понятное дело, вам не обязательно учиться слепой печати на вычурной клавиатуре. Эти 50 часов можно потратить на разное. Например, пройти курс по алгоритмам или прочитать 3 книги по разработке:
- Building Microservices by Sam Newman
- Unit Testing:Principles, Practices and Patterns Владимира Хорикова
- Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy Влада Хононова
Но тренировки не требуют особой вдумчивости, поэтому вам не обязательно заниматься печатью в продуктивные часы. Можно тренироваться на скучных встречах и создавать образ мультизадачного сверхчеловека.

Как начать, если вы решились
1. Создать мотивацию. Например, купить вычурную клавиатуру и всем об этом рассказать
2. Начать тренироваться на keybr.com. Он составляет фразы из малого числа букв и постепенно добавляет новые. Каждая новая буква — маленькая победа
3. Выбрать язык, если вы в России. Кодим мы на английском, но общаемся в чатах на русском

Какую клавиатуру выбрать
Тема для отдельного поста, но вот краткая рекомендация.
Лучше клавиатура с матричным расположением кнопок | | | | | | |, а не со смещённым (staggered) \\\\\. С матричным меньше путаницы, что каким пальцем нажимать.

Ещё лучше split-клавиатура //// \\\\. Печатать как обычно вы не сможете, придётся сразу учиться слепой печати. А ещё будете себя чувствовать капитаном звездолёта или киношным хакером.

Наш сайт и основные ресурсы находятся теперь на домене ru

- https://howto.stringconcat.ru/ — основной сайт
- https://course.stringconcat.ru/ — доступ к курсам

Спасибо!

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

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

И, как вы понимаете, это серьёзное дерьмо. Железка живёт где-то далеко в физическом мире. Новую версию на сервер не выложишь, оно уже китайцами собрано и у потребителя на руках. В лучшем случае можно выложить новую прошивку и надеяться, что владелец заморочается с микро-USB. А в худшем случае ничего не поделаешь, прибор будет работать через назад, если вообще не сдохнет. И к нему просто так не подключишься для диагностики, логи в облако он не пишет, вот это всё. А баги есть в любых устройствах. Вот, посмотрите, раздел ERRATA для STM32.

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

Однако я порекомендовал бы поковырять железо каждому разрабу. Потому что это вам даст следующее:

- Понимание древних вед основ вычислительной техники. У простых микроконтроллеров элементарная архитектура, можно наблюдать их жизнь в реальном времени
- Глаза отдохнут от монитора
- Получите массу сенсорного опыта: понюхаете канифоль, обожжётесь об паяльник, пошевелите пальцами в ловле мелких деталей
- Сможете понять, как работают операционки. Можно взять FreeRTOS для Arduino и посмотреть, как работает многозадачность, переключаются контексты и т.д.
- Можно потренироваться в упражнении «Пойми, что отвалилось». Суть: вас есть больное устройство, и нужно понять, что с ним не так, и как исправить. При этом терминалом служит условный Олег, который говорит вам в телефон, что «зеленый огонёк мигает и ничего не работает». Гарантирую, что вы свои рабочие поделки в разрезе мониторинга увидите в новом свете
- Получить удовольствие от осознания, что ваш код шевелит чем-то в реальном мире. Мне это нравилось больше всего

На собеседованиях гоняют по теории, потому что не знают, что ещё спрашивать!

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

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

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

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

Я разработал архитектуру приложения, которое зарабатывало бизнесу 400к $ в месяц. Приложение интегрировалось с 7 разными глючными системами. Входная нагрузка была 100 rps, а мы генерировали в районе 500 rps к сторонним системам. Чтобы повысить надёжность, мы применяли асинхронную коммуникацию на кафке. А чтобы особенности интерфейсов этих систем не влияли на наш домен, мы использовали hexagonal architecture, вынеся всё взаимодействие в плагины.

Основные триггеры:
- 400к $ в месяц — вы сразу показали что не в игрушки игрались, а делали серьёзную систему, за простой которой начальство сильно спросит.
- 100/500 rps — показали цифрами, что для вас высокая нагрузка, а не пресловутые «высоконагруженные системы».
- Вдобавок тут огромное количество технических ништяков, которые нормальный интервьюер увидит, и вы проговорите про них оставшийся час:
- Hexagonal
- Асинхронная коммуникация
- Кафка та же самая
- Взаимодействие с нестабильными API

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

Обещаная история, правда от Жени.

Однажды прихожу на обычный технический собес, меня встречают обычный разраб + менеджер типа тимлида. Задают обычные технические вопросы. Тимлид для вежливости спросил, чем я занимался до этого, я также из вежливости перечислил несколько проектов. Его заинтересовал один, и я начал рассказывать, как мы его запускали: выявляли потребности клиентов, проектировали, пилили, внедряли, решали трудности и как радовались первому контракту на миллион баксов! И это при том, что я был старшим бекенд-разрабом (да, кстати, если вы считаете, что разработка — это синоним к слову программирование, то у меня для вас плохие новости). Тимлид слушал, открыв рот, а к вечеру я получил оффер. Ни на один технический вопрос я так и не ответил, мне их просто не успели задать.

Почему так получилось
- Я рассказывал про свой опыт через призму достижений, а не «ну, месил там всякое и ел, что дают».
- На предварительных созвонах я задавал наводящие вопросы, а потому понимал, в каком состоянии находится команда нанимателя, какие у них есть проблемы. На очном собеседовании я рассказал о своём опыте решения таких проблем.
- Добавил немного циферок: сколько чего заработали, какой экономический эффект был нанесён.
- Рассказал, как брал инициативу и решал поступающие проблемы, а не просто ждал, пока мне нарежут таски. Это добавило мне очков.

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

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

- В коде появились куски, сгенеренные жпт или чем-то подобным. При этом они такие упоротые, что диву даёшься. Их словно вставили неглядя, без оценки адекватности
- В требованиях тоже появились куски, сгенеренные чатом жпт, сходного качества
- То же самое наблюдаем в важных документах и презах. Понятно, что эти доки никто не читает обычно, но всё же…

Даже и не знаю, что и сказать. Вот вы вставляете код прямо из жпт? И если да, то что вами движет?

Собеседование — это продажа

Вот недавняя история про сабж.
Мы выбирали learning management system (LMS) для клиента. А такие продукты продают, как в кино, на очной презентации: вы оставляете почту на сайте, вам назначают встречу, и профессиональный продажник с вами общается. Все встречи проходят по одному сценарию. Сначала они узнают, что именно вам нужно, а потом рассказывают, как их уникальный продукт закрывает ваши индивидуальные потребности.

Но вот на той встрече всё было иначе. Пришёл японский дед и давай грузить фишками системы: как её можно устанавливать, какая она универсальная и гибкая, для всего вообще. Он даже не спросил, зачем она нам, а мы так и не поняли, делает ли система то, что нужно конкретно нам.

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

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

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