Фуллстек. Фронтенд для бекендеров 3.

И немного про стартапы.

В 10-11 году мы с женой вложили 10k в зоомагазин (физический) и стали партнёрами в мелком бизнесе (спойлер — партнёрство не зарегистрировали должным образом, бизнес не взлетел, точки закрылись, деньги сгорели). Параллельно с этим планировалось запустить еще и интернет-магазин, и я, как человек, что-то понимающий в разработке, взялся за это дело.

Естественно, вместо того, чтобы взять опенкарт/shopify/мадженту/что там еще есть, я решил что б-гомерзким PHP связываться не стоит и нужно потрайхардить. В то время был моден Rails, за год до этого я уже делал попытку выучить Rails, но она не увенчалась успехом и я решил попробовать еще раз. Взяв тогда самый популярный фреймворк для екоммерса Spree я засучил рукава и начал его прикручивать. С горем пополам убрал такие вещи как "billing address", сделал нормальную локализацию, и еще какие-то мелкие изменения, а вот дальше оказалось что "продукт овнер" хочет видеть красивый дизайн, потому что без дизайна магазин продавать не будет, а дефолтный минимализм нам не подходит. Конечно же дизайнера у нас не было, поэтому решили содрать дизайн у магазина-конкурента. Еще какое-то время я пострадал над css-ом, но, увы, и в этот раз у меня ничего не вышло — магазин мы так и не открыли. Полный провал.

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

Если бы меня щас вернуть назад, я бы вместо ковыряний с рельсами заплатил бы тыщу баксов агенству "сайт за 777 гривен" чтобы они сделали нам магазин на опенкарте, с импортом товаров из 1С и быстрой покупкой. Тогда это почему-то никому в голову не пришло.

Посыл "продукт овнера" был таким — магазин должен быть красивым и точка. А на самом деле в екоммерсе важен не дизайн, а цены, ассортимент, реклама и цвет кнопки "КУПИТЬ" чтобы конверсия была повыше. У лидера рынка с 2005 года вообще сайт не менялся, и ничего, это им совсем не мешает.

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

Про "планы карьерного развития", 365 degree review и прочие способы платить меньше.

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

Все такие схемы — мучение и для менеджера и для сотрудника. Менеджеру сверху дают указку не повышать зп просто так. Менеджер извергает из себя планы развития для сотрудников, но при этом он вынужден действовать в быстро изменяющейся среде. Сегодня ты поставил как КРІ девелоперу "выучить aws" а начиная с завтра весь месяц приходится заниматься багофиксом и на обучающие активности совершенно нет времени. Сорян братишка, рынок такой, давай поменяем планы. Ну вот ты баги фиксил, за что тебе больше платить? А почему так думаешь? А если найду? А ну попрыгай?

Как мерять производительность если она напрямую не привязана к бизнес-показателям? Никак. Кто во что горазд.

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

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

Вместо игр в перформенс планы и оценки лучше сходить на собес. Там или согласятся с твоей оценкой, или честно скажут твою стоимость. Почему мне должны платить больше? Да потому что рынок такой, вот тут мне могут платить больше. Какие peer review, какие обзоры, алё ребята! Собрал вещи и ушел, джаст бузинесс носинг персонал.

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

Фуллстек. Фронтенд для бекендеров 4.

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

В Киеве почти каждый год проводится благотворительный оффлайн ивент под названием "Кубок Барбоса" — выставка беспородных собак, а моя жена состоит в оргкомитете этого самого кубка. Long story short, в предыдущие года люди (и собаки) регались через гуглоформу, это было неудобно и куча времени тратилась в оффлайне на то чтобы заматчить конкретного человека со строкой в гуглотаблице. Никому это не нравилось, и было решено силами нашей конторы сделать сайт с контентом, регой, оплатой, и каким-то образом еще и привязать это к оффлайну (людям после реги выдавался QR код, с которым они приходили на мероприятие, наши волонтеры сканили код на телефонах и им отображалась вся инфа об участнике, в общем там куча всего было). Архитектурно все решение состояло из сайта для людей, админки для оргов, мобильных приложений для android/ios и API для них. "Вот он, шанс выучить rails!", подумал я и решил сделать всю не-мобильную часть в виде монолита на Rails.

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

После некоторого периода тупинга (примерно пары недель) кривая обучения резко пошла вверх и в итоге мы почти в срок выдали вполне рабочее решение, которым даже пользовались настоящие люди. От "кастомера" пришел положительный фидбек, все счастливы, все довольны. CSS я так и не выучил, но уже сделал серьезный шаг к тому, чтобы самостоятельно фигачить полноценные сайты, а не только рест апишечки. Особенно хорошо получилось с админкой/дашбордами — для этих дел есть множество гемов (ruby пакетов) которые автоматом генерят сносный UI на основании ваших таблиц/деклараций. То есть у меня получился относительно красивый интерфейс без применения фронтенд-скиллов вообще. До работы дата саенс парней, которой я вдохновлялся в прошлой части, было еще далеко, но уже намного понятнее, как туда попасть.

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

Релизы в пятницу.

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

Я и сам множество раз делал релизы в пятницу. И всегда, всегда это сопровождалось какими-то проблемами. Вылез важный баг. Продакшн окружение чуть чуть отличается от тестового и что-то ведет себя не так, как нужно. Люди склонны делать хотфиксы побыстрее потому что пятница же, охота побыстрее свалить, в итоге проблемы нарастают снежным комом, хотфикс не проверяет должным образом и становится только хуже. И самое ужасное что нельзя просто сказать — ок, на сегодня все, завтра утром придём и починим. Нет! Завтра — суббота и никто работать не будет, давай чини. Особенно плохо, если нельзя просто так откатиться назад, например прогнали миграцию на проде и восстанавливаться из бэкапа дольше чем исправить ошибки. Кто-то взял себе тайм-офф на вторую половину дня, у кого-то поезд вечером, у всех могут быть свои дела, каждое из которых уж точно важнее нежели релиз очередного куска функциональности.

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

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

Фуллстек на минималках. Фронтенд для бекендеров 5.

Одним из партнёров в нашей аутсорс шлюпке был крутой фуллстек парень. Кодил он на js, был большим любителем ноды и к тому же отлично знал PHP. К нам тогда по наследству приехал среднего размера проект как раз написанный на PHP, к счастью, на Laravel (это такой аналог Rails в мире PHP, в целом довольно годный), и он ним занимался. Сам проект (который кстати живет и здравствует до сих пор, только поддерживаю его уже я) состоит из бекенда для мобил и SPA и админки для управления контентом и прочим.

Короче, там была админка, которой постоянно пользовались люди. И она выглядела круто! Там был сайдбар, хидер, всякие кнопочки-формочки и так далее, и чтобы писать все это, нужно было совсем немного кода. Я решил разузнать поподробнее как это так получается, так как всегда думал, что кто-то разрабатывал все это с нуля, а реальность оказалась намного прозаичнее — существует полно HTML-шаблонов для админок и прочих штук, и нужно всего лишь добавить себе в ассеты css-ину, js-ину ну и дальше верстать формочки так, чтобы там были нужные стили. В нашем случае таким шаблоном был AdminLTE (https://adminlte.io/themes/AdminLTE/index2.html) — это один из самых популярных, но их есть много разных. Для Laravel даже есть библиотека, которая позволяет интегрировать эти шаблоны в приложение без необходимости верстать всякие сайдбары самому.

Тут до меня потихоньку начало доходить — для того, чтобы делать сносные приложения, совсем необязательно хорошо шарить верстку — достаточно где-то найти подходящий шаблон, а дальше через копипаст переносить себе компоненты и собирать из этого, как из конструктора, рабочее решение. Конечно, для уникальных сайтов это не подойдет, но всякий околоадминский инструментарий, дашборды, аналитика и тд пишутся на ура. Нет, я конечно знал про всякие бутстрапы и прочие "фреймворки", но мне они казались чем-то типа молотка и отвертки которые еще нужно применить, а не экскаватора, которым ты после непродолжительного обучения сможешь рыть ямы со скоростью 300кк/cек. А сайты типа TemplateMonster (кстати один из людей, который стоял у истоков этой компании когда-то был моим боссом в NC) я почему-то всегда воспринимал как наблон шаблонов для екоммерса и джумлы с вротпрессом.

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

Как раз в то время у нас стояла задача сделать админку для нового проекта. Сам проект вначале был запилен на PHP силами одного джуна, потом под моим присмотром перепилен силами другого джуна на Java но в процессе перепиливания мы потеряли админку. Я некоторое время колебался, но, после успешного небольшого проекта решил сделать ставку на Rails, кроме того, у java-джуна был кореш который как раз искал работу на rails. Я решил нанять парня и не прогадал.

Еда.

Люто бесит необходимость есть чтобы поддерживать бренное тело в этом мире.

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

Единственный продукт, который хоть как-то можно считать инновационным — это сойлент и прочие порошки. Но и это не полноценная замена еде, потому что кишкам нужно что-то более твердое и волокнистое. Непонятно, как длительный постоянный прием сойлента скажется на здоровье пациентов и люди вынуждены ставить эксперименты на себе. Как только решат все проблемы с сойлентом — перейду на него. Надеюсь, это случится еще на моем веку. Но даже и его нужно будет потреблять внутрь, вместо того, например, чтобы ставиться каждый день смесью из необходимых организму элементов и вообще забайпассить ЖКТ. Но так не работает, увы — потому что человек — невероятно сложная система которая, если копнуть поглубже, вообще чудом как ходит на двух ногах, все наши потроха выполняют свои функции в удивительной синергии, и попытка подхачить один орган незамедлительно скажется на других. Самый дефолтный пример — плохой прикус/кривые зубы —> хуже пережевывается пища —> хуже переваривается —> хуже работает жкт, меньше производится серотонина —> человек ходит грустный и бонусом получает еще кучу мелких проблем.

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

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

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

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

Я хотел молекулярный конструктор, который будет собирать любую еду из куска угля, щепотки соли и воды, а получил Uber Eats и сотню стартапов по доставке еды, приложения для трекинга калорий, куда нужно вбивать их вручную и смузи по подписке с qr-кодом и выжималкой пакетиков за 300 баксов. Вот и все инновации, куда вливают бабло венчурные капиталисты.

Грустно это все, 2019 год а я до сих пор варю себе гречку. Еда же касается всех и каждого, и бедняка, и богача, так почему же прогресса нет?

О неработающем скраме.

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

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

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

Короче стендапы есть, но толку от них нет.

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

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

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

Но самое ужасное что преследовало меня всегда — это невыполненные до конца спринты. Так или иначе, фичи продалбывались и burndown chart не сходился. Не знаю как у других, а у меня от этого горело постоянно. Как так — работаем полгода и каждые две недели мы не выполняем план? Ретро не помогают, стендапы не помогают, оценка не помогает, ничего не помогает, все равно в конце спринта поинтов сделано вполовину. А продукт овнер не хочет ставить цели ниже, вот и получается перманентная фрустрация. Лучше уж работать как-нибудь и выдавать что-нибудь, нежели постоянно быть под давлением дедлайна, грустно смотреть друг на друга на закрытии спринта и на график в виде буквы Г наоброт, а не на красивую линию "\".

Кстати я на собесах всегда спрашиваю "как часто вы продалбываете спринты" и в своем прошлом вояже минимум половина ответила "всегда". Зачем так жить, котаны?

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

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

О сломанных авто/интеграционных тестах.

Люблю тесты. Особенно интеграционные или авто (те которые в браузере кликают). Запустил — и сидишь смотришь как у тебя все красиво и все работает.

Одна проблема.

Такие тесты всегда сломаны. Всегда, просто всегда. Конечно, поначалу, пока сценариев мало, то все красивое и зелененькое. Но как только продукт становится чуть более сложным чем сайт-визитка с формой контакта, то моментально наступает коллапс. Длительность прохождения сценариев увеличивается экспоненциально, количество мест отказа в распределенной системе и комбинаций сбоев разных подсистем так же растет, в итоге мы имеем по факту тесты которые могут сказать только "не работает вообще ничего" (логин отвалился) или требуют квалифицированного QA для анализа того, что же действительно упало. В 99% случаев падает из-за таймаута/редеплоя/устаревшего сценария/умершего селениума/съеденной памяти на CI-сервере.

Со временем команда привыкает к перманентно сломанным тестам, это становится обычным делом, и никто уже не реагирует на возгласы умирающего дженкинса в слак-канале #tests.

И снова, мне как-то не везло работать в командах, где тесты работали бы надежно и где успешно пройденный e2e тест был бы ежечасной реальностью а не еженедельным исключением. При этом не писать тесты себе дороже — даже в сломанном виде они позволяют хоть как-то гарантировать, что на выпуск идет хоть работающий продукт а не пятисотая на главной. За качество тестов всеми силами борются автоматизаторы и QA но и они проигрывают это сражение и с опущеными знамёнами идут тестировать вручную. А учитывая количество времени, требуемое на поддержку инфраструктуры тестов, менеджмент имеет все меньше желания отдавать половину команды на эти активности и пускает все на самотёк.

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

VR для нищих

Ходили сегодня в VR-"салон" (не знаю как это правильно назвать). Короче такое место в трц, там сделаны такие "клетки" из дерева 2х2 метра, висят окулусы/htc на подвеске сверху, чтобы провода не путались (на вайфай не хватило денег или не рентабельно), дают в руки контроллеры и вперед.

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

Сегодня же был стоячий вариант (можно ходить!), но с контроллерами вместо рук. Играли в какой-то тавер дефенс, где надо было отстреливать орков из лука, зомби апокалипсис, где нужно отстреливать уже зомби, хождение по доске над небоскрёбом и super hot — адовый шутан с интересной механикой и кровь-кишки-осколки.

VR меня люто вштырил. Мозги обманываются на ура и это очень впечатляет. Если выбирать игорь с физической активностью (например в тавер дефенсе нужно натягивать тетитву, в super hot уклоняться) то можно нехило так вспотеть. Очень круто, даже несмотря на полное отсутствие физической обратной связи. 15 лет назад когда я фанател от Лабиринтов Отражений и Фальшивых Зеркал такая штука наверное вообще бы мозг вынесла, хе-хе.

Самое главное ограничение всех VR-штук — нельзя ходить, лишь в пределах условной безопасной зоны 2х2. Разные игры обходят это ограничение по разному, делают костыли кто во то горазд, но в целом это несколько портит впечатление. В остальном — очень даже покатит. Более детальный твитор тред с разборами недостатков текущей технологии и объяснениями почему уже 10 год прошло а мы до сих пор ходим на работу в офис, вместо того чтобы валяться в креслах подключенными в VR — https://twitter.com/oulasvirta/status/1103298711382380545.

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

О работе с мудаками 1

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

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

Как и в любом деле здесь важен баланс. Я довольно долго проработал в среде, которую нельзя назвать прям ваще токсичной, но которая явно препятствовала развитию в интересном мне направлении. Любая большая корпорация — это такая среда. Если ты не добрался достаточно высоко, или не работаешь в каком-нибудь около-RnD отделе, где ты можешь быть себе хозяином, то везде будешь натыкаться на стены бюрократического взаимодействия. Хочешь внедрить новую технологию? Докажи главному инженеру компании что эта штука нужна. И позови на защиту своего решения еще десяток людей со смежных отделов, им ведь тоже интересно! Хочешь разработать новый продукт? Изволь составить подробный план и презентацию (и пофиг что план станет бесполезным уже через месяц после работы), выбей откуда-то людей, подожди пол-года чтобы решить все бюрократические проволочки, а потом начнется пожар на другом проекте, и до твоего уже никому не будет дела. Корпорации защищают себя от изменений, и это происходит естественным путём. То ли дело мелкий стартап, где ты и жнец и швец и кузнец, и волен делать всё, что хочешь.

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

Однако чем дальше в лес, тем больше я понимаю, что силами одного человека можно сделать многое (привет, фуллстек на минималках!), а закалка своей шкуры в неравных боях с корпоративной машиной однозначно того не стоит. Видишь, что вокруг тебя работают люди, которым интересно оставаться там, где они есть и делать то, что они сейчас делают, а любые инновации и изменения вызывают в них моментальное отторжение? Ну что ж, можно попробовать переубедить их, но не стоит тратить на это много усилий. Лучше свалить туда, где можно будет оттачивать реальные навыки работы с рынком, с пользователями, быстро тестировать решения и выводить их в продакшн, быть в окружении людей которые думают схожим образом, открыты к инновациям и не страдают синдромом вахтёра.

Сам свалил и ни дня не пожалел об этом.

Фуллстек на минималках. Фронтенд для бекендеров 6

Предыдущие серии: 1 (t.me/full_of_hatred/85), 2 (t.me/full_of_hatred/86), 3 (t.me/full_of_hatred/88), 4 (t.me/full_of_hatred/90), 5 (t.me/full_of_hatred/92)

Итак, нам нужно было сделать админку. Для этого мною был прособеседован и нанят Rails джун, и мы приступили. Для Rails есть много разных админок, но все они проигрывают по красоте AdminLTE (adminlte.io), поэтому, после пары дней исследований было решено велосипедить свое решение, без хитрых генераторов, а для стилей взять вышеупомянутый AdminLTE.

Буквально через неделю у нас уже была вполне работающее приложение с базовыми функциями. К таблицам были прикручены сортировки и стили, пагинация, формочки и так далее. Если нужно было добавить еще какую-то сущность ("заказы" например) то все таблицы и формы просто копипастились, менялись названия контроллеров, полей и прочего и все это выкатывалось. Копипаст конечно не очень хорошо, но в нашем случае пришлось бы изобретать свой генератор, который так или иначе упирался в граничные кейсы (таблицы и формы иногда были разными). Все это выглядело довольно красиво и было несложным в доработке и поддержке. Заказчик доволен, пользователям все удобно, все счастливы. Приложение до сих пор живет в продакшене и активно используется.

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

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

Поэтому, для следующего проекта я решил немного заморочиться и сделать фронтенд на реакте. Для реакта есть не так много вменяемых шаблонов админок (а те, которые есть, часто идут с jQuery впридачу), поэтому после трех дней изысканий я купил за 20 баксов чисто CSS-ный шаблон основанный на Bulma (bulma.io) и пошел учить реакт, благо основы постигаются буквально за полчаса, а дальше только успевай строгать компоненты.

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

Ну а со временем и практикой уже появится понимание, что к чему в стилях, и обучение html/css будет происходить естественным путём.

Переключение раскладки клавиатуры 1

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

Дефолтный вариант с ctrl+shift который нам предлагает Шиндовс, неустойчив к ошибкам. За многие года я так и не научился запоминать, сколько раз мне нужно нажать комбинацию, чтобы переключить раскладку — нужно постоянно смотреть на иконку в трее, это сбивает фокус и снижает скорость печати, особенно если в речь нужно вставлять всякие технические термины на английском. Сложность алгоритма — O(n).

В какой-то момент мне это все надоело, и я назначил каждой раскладке свою комбинацию клавиш — alt+shit+1/2/3 для английской, русской и украинской. Таким образом я всегда точно знал какую одну комбинацию мне нужно нажать, для того, чтобы выбрать нужную раскладку. Сложность понизилась до O(1), но появились ошибки, вызванные не одновременным нажатием на клавиши — в некоторых программах на alt+1/2/3 повешены какие-то действия и иногда это приводило к неожиданным эффектам. Тем не менее, я довольно долго жил на такой конфигурации, и был вполне доволен, пока не переехал на мак.

Особые отношения у меня были с кнопкой Caps Lock. За все года, проведенные за компьютером, эта кнопка мне не пригодилась ни разу. Многим другим скорее всего, тоже, но производители уперто продолжают засовывать её во все без исключения клавиатуры. Вот она — сила инерции! Так как мне не нравилось ошибаться и нажимать на эту кнопку, то я просто доставал или выламывал её из всех своих клавиатур. Нет кнопки — нет проблем 🙂

На маке, к сожалению, из коробки нет возможности назначать отдельную комбинацию на каждый язык, и еще хуже, что дефолтная комбинация cmd+space используется в IDE, в которой я работаю, для автокомплита. Поэтому я перебил смену раскладки на комбинацию cmd+shift+2. В перспективе это решение оказалось большой ошибкой, потому что я постоянно нажимал эту комбинацию не одновременно и часто ошибался, вызывая забавные эффекты (например выход из программы или вызов каких-то настроек). Я промучился примерно два года, прежде чем попал на статью Никиты Прокопова про раскладки и не прочитал в камментах о том, что можно забить переключение раскладки на Caps Lock. Был быстро проведен гуглеж, установлен карабинер и еще какие-то штуки и теперь у меня переключение раскладки происходит одной кнопкой, прямо как РУС-ЛАТ на древних клавиатурах. Думаю что на винде тоже можно сделать такой трюк. Достоинства очевидны — вместо комбинации надо нажимать одну кнопку, Caps Lock наконец-то получает значимую роль, снижается количество ошибок при наборе, в общем одни профиты. Ура! Осталось решить проблему трех раскладок.

Переключение раскладки клавиатуры 2

На маках есть еще одна проблема — дефолтные кириллические раскладки отличаются от тех, что на винде. В процессе гугления стандартной раскладки я попал на знаменитую типографскую раскладку Ильи Бирмана. Там помимо возврата знака вопроса на его законное место, добавлено еще куча всяких полезных штук, самой часто используемой из которых у меня есть длинное тире —. Искушённый читатель наверняка это заметил: разница между - – — очевидна, а я всегда использую длинное тире 🙂

Всякие типографские символы там забиты на комбинации alt+символ и тут мне пришла в голову другая мысль — наверняка ведь можно забить в одну раскладку дополнительные символы — і, ї, ґ, є, чтобы не держать две кириллических раскладки. Оказалось что эту задачу до меня же решили, и я каким-то образом нагуглил раскладку Бирмана с добавленными нужными символами на хабре (https://habr.com/ru/post/130471/) установил и был таков! Наверняка есть похожие решения для винды, так что если вы вдруг страдаете от трёхъязычности срочно избавляйтесь.

Никита же пошёл еще дальше, и модифицировал раскладку полностью — убрав необходимость использовать нажатие shift для печати запятой и точки (https://tonsky.livejournal.com/318571.html). Это следующий этап, я до него пока не добрался, потому что привычка очень сильна, но обязательно буду пробовать.

Тупо, что многие вещи были сделаны как попало, никто не хочет/не может их заменить и огромное количество людей страдает, совершая каждый день неэффективные действия, а забота об эргономике своего места — это почему-то удел задротов (тех самых, которые покупают себе девайсы вроде Truly Ergonomic (https://trulyergonomic.com/store/index.php), или Kinesis (https://kinesis-ergo.com/products/#keyboards).

Ультимативным решением проблемы раскладок был бы переход на латинницу, но, при всех достоинствах этого решения, mne ono sovsem ne po dushe. Надо было переходить еще при союзе, тогда бы бы ок 🙂

Вакансии в поверпоинте

Время вот времени получаю от рекрутёров предложения в виде ссылки на документ с вакансией.

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

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

Особенно меня радуют такие порождения корпоративного мира как презентации. Духота переговорки, человек с лазерной указкой монотонно вещающий что-то, люди втыкающие в телефоны, постоянно обрывающаяся телеконференция, "коллеги мы все on the same page?", бессмысленные графики и обязательный фирменный стиль на презентации мутным потоком выплескиваются на меня прямо из монитора и погружают сознание в кошмар где 4 таких митинга в день с интервалом в час, на всех нужно обязательно быть, а на некоторые нужно готовить презентацию самому.

Итак, что же нас ждет в этой славной отрыжке корпоративного червя ловко владеющего основным инструментом убеждения окружающих в собственной ценности?

- прикольная картинка и название компании. Работать в нашей компании — большая честь!
- фотки руководителей/основателей этой славной конторы с краткими биографиями каждого. Очень важная информация.
- традиционный безликий булщит про миссию компании, революционный продукт, дизраптив технолоджи. Иногда фоточки офиса.
- три слова о проекте и пять буллитов про компетитив салари и медстраховку с залом
- требования к вакансии! Ура!
- слайд Thank You и контакты. Спасибо, что доехал до этого слайда и живой! Стресс-тест кандидата прямо во время чтения вакансии.

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

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

Зарплата джуна

Сколько денег платить джуну? Сколько денег просить джуну?

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

Сколько же платить таким ребятам?

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

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

Я убежден, что когда беру на работу людей без опыта, то оказываю им значительно большую услугу, нежели они — мне, но, даже несмотря на это, всякий труд должен оплачиваться. Ни в коем случае не работайте бесплатно и не нанимайте людей на проекты бесплатно. Всем надо платить, пусть даже немного.
И именно поэтому я считаю что денег джун должен получать ровно столько, чтобы не помереть с голоду. В киевских реалиях это примерно 300-400$. Взамен я не требую лояльности и чётко понимаю, что ушлый парень/девушка уже через полгода озаботится вопросом повышения зарплаты и есть риск, что он от меня уйдет, если я не соглашусь с его аппетитами, или не буду достаточно убедительным, чтобы он продолжал работать за мелкий прайс.

Через год джун должен как-то выходить на планку в 1000$. Если для меня он будет ценным — ок, я буду платить такие деньги. Если нет — ну что ж, бизнес есть бизнес, рынок есть рынок, вперед, я только порадуюсь за человека.

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

Не стыдно работать за мелкий прайс. Стыдно продолжать получать мелкий прайс через год.

Идеальный джун

За свою карьеру я нанял большое количество нулячих джунов (без предыдущего опыта). Человек 20 точно будет, не меньше, а то и все 30. Соответственно просмотрел я далеко за сотню разных людей. Довольно давно я сформировал как говорят на западе highly opinionated профиль кандидата согласно которому я автоматически дискриминирую и отсекаю целую толпу народа. Кто же это?

— Обязательно студент/ка 3-5 очного курса профильного технического факультета. Разнообразные АСУ, ВТ, АУТС, кибернетики, автоматики, безопасность и прочие компьютерные науки. В принципе дальше можно не продолжать 🙂 но разберем по полочкам:

- Раз студент, значит парттаймщик. Это очень важно. Кто-то может думать что парттаймщик будет меньше работать, но на самом деле это не так. Человек который работает пол-дня будет эти пол-дня проводить сфокусированно над нужными задачами, а не смотреть мемасы. Чем меньше времени — тем более эффективно оно расходуется, тем проще отслеживать и контролировать прогресс. Непредсказуемость посещений делает ваш процесс более устойчивым, такой себе chaos engineering. Важно чтобы человек мог работать не меньше 20 часов в неделю — это необходимый минимум, из моей практики.

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

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

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

- Идеальный джун уже с горем пополам знает парочку фреймворков/библиотек — spring/rails/react/angular/express/etc.

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

Почему нужно нанимать джунов

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

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

- Улучшение и формализация процессов. Когда у вас на борту не самые опытные бойцы, такие вещи как CI/CD, статические анализаторы кода, тесты, код ревью и автодеплой становятся просто обязательными. Чем больше препятствий на пути к продакшн серверу — тем лучше.

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

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

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

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

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

Вранье на собесах

Несколько лет назад одна моя знакомая решила пойти на вайти курсы QA.

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

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

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

Уже потом я узнал что это распространённая практика на курсах, особенно тестировщиков. Стоит ли говорить, что любой нормальный специалист довольно быстро распознает вранье, ведь не может человек вообще без опыта просто так сэмулировать два года работы на реальном проекте. Ну а кандидат подвергает себя риску занесения в локальные чёрные списки (хотя я и не особо верю в их существование). И как-то с коллегами надо потом разговаривать, где раньше работал, что делал? А вдруг найдется кто-то из той фирмы, кто работал в тот же период?

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

О стеклянном потолке 3. Оффлайновый бизнес

Предыдущие части: первая (https://t.me/full_of_hatred/42), вторая (https://t.me/full_of_hatred/43).

Многие люди ненадолго погрузившись в сладкие обещания, которые нам вещают со страниц книг, буллитов презентаций, сцен залов всевозможные бизнес-тренеры, рано или поздно задумываются о своем деле. В качестве такого "своего" дела часто выбирается какое-то оффлайновое предприятие — магазинчик китайского барахла, фургончик с фастфудом, СТО или похожие активности. Будущие бизнесмены мечтают о том, как они вложат десяток тысяч баксов, поставят все процессы на поток, а сами укатят на #сказочноебали лежать на пляже и любоваться закатами.

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

В 2010 году нам предложили вложиться в такое предприятие — оффлайн магазин зоотоваров. Пораскинув мозгами и найдя в закромах $10k мы решили вписаться. Long story short: спустя 5 лет все точки, которые у нас были, закрылись.

Самый большой недостаток оффлайновых штук как раз и заключается в том, что они, собственно оффлайновые. Товар может испортиться, его нужно где-то хранить. Его могут забрать или украсть. Его могут не купить и тогда придется что-то делать с остатками. Нужно арендовать место для точки продаж и склад. Заниматься логистикой доставки товара туда-сюда и поставщиками. Иметь дело с многочисленными контролирующими органами. Контролировать сотрудников. Заниматься складским учётом и осваивать 1С.

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

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

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

Производительность веб-сервисов

До сих пор люди иногда спорят о скорости программ, написанных на том или ином языке или платформе. Хотя тренд значительно пошел на убыль и редко где услышишь "Java тормозит" или "1 000 000 конкуррентных подключений на node.js" но время от времени все равно этот вопрос подымается.

Так вот.

У меня в продакшене уже несколько лет крутится куча сервисов, часть на JVM, часть на Rails, часть на Python, часть на PHP, парочка на node.

80% (а то и все 99%) проблем с производительностью ваших и моих приложений связаны с I/O, и никак не связаны с тормознутностью интерпретатора отдельно взятого языка. Если вы не гугл конечно. А вы — не гугл.

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

Ruby on Rails известен своей медленностью во всяких модных бенчмарках. И действительно — интерпретатор медленный по сравнению с JVM или node, а фреймворк наворачивает поверх этого кучу барахла которое еще больше замедляет время ответа. Да вот только вся скорость JVM-приложений так или иначе упирается в (No)SQL-запросы и сетевое взаимодействие.

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

Ruby тормозит? Да плевать, зато я за 5 минут подыму работающее АРІ, пока вы будете импортировать build.gradle в IntelliJ.

Туда же NoSQL барахло. Современные базы работают очень бодро, поэтому постгреса хватит всем. Ту да же микросервисы, но это отдельный разговор 🙂

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

О работе над продуктом

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

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

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

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

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

Вот сегодня приехала мне задача увеличить максимальный размер принимаемых определённым API файлов. Раньше ограничения не было, но какие-то ребята додумались слать видео по 50 мегабайт. Сделали ограничение в 10 мегабайт, хардкодом, потому что не было времени (или уже не помню почему). Сегодня оказалось что один из клиентов этого API присылает файлы по 11 мегабайт и здорово было бы лимит увеличить. Можно перехаркодить значение. Можно внести настройку в базу. Но тогда на каждый запрос надо ходить в базу, а это плохо. Значит нужно сверху навернуть кеширование. Хорошо. Но клиентов у API много и разных. Некоторые могут попросить оставить 10 MiB. Делать настройку per-application или per-customer? Если добавлять настройку то нужно добавлять поле в базу для этого клиента. Или записать в json-конфиг его подключения. Но если добавлять в json-конфиг, то нужно добавлять поля в классы(прости Господи) дто, нужно добавлять настройку в админку (которая написана отдельным приложением), добавлять валидацию, устаналивать дефолтное значение, мигрировать существующие конфиги на новые, с добавленным полем, добавлять код чтения настройки уже не из общесистемных настроек, а из конфига подключения...В общем работы на день есть точно.

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