Посмотрел видео с WWDC 1997 года, где Стив Джобс отвечает на вопросы зала. И вот что интересно (с точки зрения мотивации): кажется, все, о чем он переживал, это делать хорошие вещи.

Не программистов развлекать. Не деньги зарабатывать. Не «быть different». Не изобретать все самим. Не захватить как можно больше областей. Не планировать устаревание на годы вперед.

Знал как сделать хорошо — делал. Не знал — не делал. Если хорошо делал кто-то другой — отлично, можно не делать тоже.

Даже рекламу давать не хотел — говорит, если сделаем хорошо, нафига реклама? Реклама — это когда прокисшее говно продаешь.

В искренность мотивов я поверил, короче. Вот эта вот сквозная мотивация, когда глава на самом верху всей софтверной компании переживает ровно о тех же вещах, что и рядовой пехотинец^W пользователь в самом конце цепочки. Не на словах, причем, а по-настоящему. А все остальное приложится.

Стоп, так а разве не все продуктовые компании хотят хорошо делать?

Не все.

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

Ну, знаете, раз есть формат, ему нужна и ИДЕ, да? Так у маркдауна появились специализированные редакторы, хотя сама идея формата ровно в том, что никакой специальный редактор ему не нужен, что писать можно где угодно.

А раз появились редакторы, то им нужные какие-то фичи, да? С этим еще тяжелее. Ну можно слова жирным/курсивом покрасить. Можно шорткат Cmd+B сделать, который ставит звездочку до/после выделенного сегмента. Не очень убедительно, да?

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

Но с такой идеологией редактор не продашь. Так появились двухпанельные редакторы маркдауна, в которых слева — исходный код, а справа — превью.

Выглядит оно, как вы уже догадались, практически неотличимо. Необходимости в нем примерно ноль. Экрана занимает примерно половину. Ломает скролл либо слева, либо справа. Потому что у отрендеренного и сырого текста высота разная лишь _слегка_. Недостаточно разная, чтобы это хоть на что-то существенно влияло, но достаточно, чтобы раздражать рассинхроном.

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

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

Но нет, это другое. Ну то есть как, в каком-то смысле точно такое же, только хорошее.

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

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

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

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

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

НА ЛУНЕ

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

ты как будто одна
ты вся такая в скафандре
обречена
тиха

одно выражение твоих глаз
достойно рассказа или стиха

в рации раздаются чьи-то команды
и уже истерическое ха-ха

тебе страшно как в детстве
когда удаляли гланды

а тогда на Луне
ты помнишь

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

я был тоже очень испуган
и этот страх был нашим единственным другом
подтверждающим
что мы ещё живы

(вот, кстати, куда заводит жажда наживы)

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

и по открытым каналам свободно неслась
всякая ругань

и внезапно ты повернулась
прижалась ко мне
и тут
какой-то голос в наушниках
громко сказал:
Серёжа, этот горящий порт напоминает мне
железнодорожный вокзал
в Бердянске
в 2075-м году

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

на Луне
Серёжа
как на войне
кстати, у тебя обгорела рожа

а мы такие
сидели спиной к спине

Давным-давно была у меня команда, и я ей, получается, руководил. Ну то есть как руководил — как умел, так и руководил.

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

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

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

Страдая в своем положении, я наткнулся в Твиттере на Rasmus Andersson, который постоял у истоков Спотифая, придумал Графкуэль, начал портить Дропбокс, порисовал Фигму, сделал шрифт Интер, а потом пошел нахер^W^W стал чилить в свое удовольствие, называя это модным словом Individual Contributor (IC). То есть нигде не работать, делать то что интересно и делиться с миром. Просто потому что ему так комфортнее.

И тогда я понял, что вот она, моя проблема — я тоже в душе Individual Contributor! То есть люблю делать все по-своему, никого не слушать, не люблю убеждать, зато умею в опенсорс и деливери. Правда, в отличие от Расмуса, я не заработал свои сто мильенов будучи двадцатилетним и поэтому не могу расслабиться и уйти на пенсию.

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

Кстати, сегодня в Джетбрейнс началась летняя стажировка, и у меня под руководством два студента. Надеюсь, руки все помнят. С богом!

Обожаю смотреть, как большие компании не могут повторить даже минимальные продукты от индивидуальных контрибьюторов/небольших стартапов.

Типа, какой-нибудь Git плохо скейлился на монорепы Гугла-Фейсбука-Амазаона, и они страдали, какие-то подпорки делали, вместо того чтобы сесть и написать такой же Git, но для монореп.

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

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

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

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

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

Проклятие Джавы распространяется не только на десктопные UI, но и на билд-системы.

Ant, кажется, был ничего? Эдакий make, только писать надо на XML (времена были тяжелые, XML казался хорошей идеей). Ну я не пользовался особо, но видел.

Где-то начиная с Maven что-то пошло не так. В Maven впервые в полную силу была реализована идея «ты что-то пишешь, а потом оно где-то в совсем другой момент используется». Типа, твои действия привязываются к stages, но stages ты явно не вызываешь, они вызываются неявно, когда ты вызываешь команды, причем пачками. То есть тебе нужно не просто куда-то свой плагин вставить, но и убедиться, что он не вставился туда, куда не нужно. Короче, сложно, я за 15 лет так и не разобрался.

Лучше всего абсурдность Maven подчеркивает Lein, система сборки для Clojure. Lein сел на ту же инфраструктуру, что и Maven, буквально: в те же репозитории ходит, те же jar-ки использует. Но при этом Lein это самая простая, логичная, лаконичная, удобная система сборки из вообще всего, что я когда-либо видел (как и многое в Clojure, впрочем). То есть понимаете, да? Делает то же самое, использует те же вводные, но делает это НОРМАЛЬНО. А джависты — ну, джависты это джависты.

Так вот. На Maven мысль, к сожалению, не остановилась. XML начал потихоньку умирать (спека на 125 ТЫСЯЧ букв, кто ж такое вытерпит?), чем заменили бы его здравомыслящие люди? Ну, JSON-ом, наверное? YAML в худшем случае. Ну это здравомыслящие. А джависты взяли Groovy, язык, нигде вообще не использовавшийся в принципе. Потому что могут.

Так появился Gradle. Groovy, конечно, шаг вперед по сравнению с XML все равно. Но вот чего не учли создатели: на Groovy стало очень удобно программировать билд. На Maven программировать тоже можно было, но гораздо неудобнее: надо плагин создавать, компилять его как-то, выкладывать куда-то публично, и только потом использовать.

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

Я уж не говорю про всякие мелочи, типа того, что Gradle сам себя скачивает, отдельно в каждый проект. То есть у начинающего Джава программиста в среднем в системе стоит пять-десять копий Gradle одновременно.

Или, например, у Gradle три конфига вместо одного. Почему три? Да фиг его знает. Но запомнить где что я тоже так и не смог. Просто щелкаю их все по очереди, пока не найду то что надо.

Котлинисты, кстати, знаете как решили эту проблему для себя? Никак, лол. Заменили Groovy на Kotlin, оставив все остальные проблемы ровно на том же месте, где они изначально лежали.

А теперь я расскажу вам о той самой идеальной билд системе, которая порешала все недостатки Maven и Gradle и сделала жизнь джавистов и котлинистов счастливой. Вот она:

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

Что все может быть и правда, но вопрос-то не об этом. Код почему хреновый?

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

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

Писать код.

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

И вот она завершилась. Объявила ответ. Только что в мире была лишь запутанная паутина исходных данных, с которыми бесполезно было пытаться что-то делать руками. И вот ты сам, единолично, прямо здесь и сейчас создал себе инструмент, подспорье, которое работает лучше тебя, и оно распутало ту самую паутину и привнесло в мир какую-то ясность, какой-то ответ.

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

Так что да. Дайте мне терминал и компилятор, и я может не переверну мир, но на сутки пропаду точно. А остальное неважно.

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

Во-первых, ребята, очнитесь. Время дизайнера не «дешевое», это самое дорогое время, которое в разработке продукта вообще может быть. Всем глубоко пофиг и насрать, что там у их ежедневных программ под капотом: лапша, не лапша, монолит или микросервисы, электрон или позитрон, json или xml, хаскель или джаваскрипт, стратегия или фабрика. Вот серьезно, мем с Райаном Гослингом, объясняющим девушке на вечеринке.

А на то, как продукт выглядит и как работает – нет, не пофиг. Неправильно поставленная кнопка может буквально разорить компанию. Сложная навигация — похоронить продукт. Неприятный визуал — сдержать рост. Я уж не говорю про просранные пользовательские сценарии или, прости господи, про левую идею продукта.

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

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

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

Что не отменяет того, что программировать я по-прежнему очень люблю и, хочется думать, умею. Просто не надо думать, что это имеет какую-то глобальную ценность для кого-то ещё кроме меня.

Во-вторых, по фактам. У любой программы, которой вы пользуетесь, есть интерфейс. Да, даже у CLI утилит.

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

Ну а дальше сама польза продукта может быть настолько высокой, что люди закроют глаза на проблемы интерфейса и будут им пользоваться скрипя зубами. Мы все знаем такие примеры: Git, Kubernetes, JavaScript. Такие продукты можно пересчитать по пальцам одной руки.

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

Или все-таки заморочитесь и сделаете нормально, чтобы люди могли пользоваться вашей программой не превозмогая себя, не вопреки?

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

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

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

Имел я в виду примерно следующее. Конечно, я никого не считаю бесполезными, ни дизайнеров, ни программистов. Не знаю, почему это так прочитали дизайнеры. Нет, все профессии нужны, и пост в первую очередь это реакция на высказывание, что время дизайнеров априори дешевле времени программиста. Я был раздражен и немного перегнул в другую сторону. Маркетинг все равно в 10 раз уделывает любые наши потуги, и дизайнеров, и программистов 🙂

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

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

А предмет рефлексии — что, собственно, делать программисту с 15-летним опытом? Первые два года ты, понятно, джун, учишься, смотришь, что бывает, совершаешь ошибки. Еще года два-три ты мощная рабочая единица, делаешь что просят, можешь решать задачи от и до, клепаешь проекты один за другим, приносишь максимум пользы. Может повезет даже поруководить кем-то. Пик взаимной эффективности, короче.

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

И вот что ему делать? Изучать новые языки. Фреймворки. Экспериментировать. Разрабатывать что-то новое. Дизайнить уникальные системы. Это все классно, интересно, драйвово, но эффективность падает, а бизнесу так это и вообще не нужно. Под это нельзя найти работу. Таких вакансий в принципе не бывает. Как мне сказали на собеседовании в Pitch, когда я вывалил им ворох своих идей по поводу приложения: идеи не нужны, а вот писать код, куда скажут, можешь?

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

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

И вот что, спрашивается, делать опытному программисту? Куда податься?

Когда-то давно, лет, скажем, 15 назад, я программировал на Джаве. Джава тогда была, ну, не то чтобы новорожденная, но в юношестве точно. И все эти корпоративные «серьезные» программисты только начинали ее окучивать. Spring, Hibernate, Java EE — все это только начиналось.

Ну и вот, на этой волне придумал какой-то лидер мнений Dependency Injection, он же Inversion of Control. Почему названия два? Наверное, лидера было два, хз. У обычных людей это называется просто «передача параметра в функцию», но у Java это обязательно должен быть какой-то паттерн, движение, идеология.

Конкретно это движение возникло из патологической боязни «new» и ответственности. По не до конца ясным мне причинам, код в Java, который что-то на самом деле делает, считается зашкваром. Самый лучший код — тот, который ничего не делает и не решает, а просто перекладывает задачу на следующего. Да, прямо как бюрократический аппарат. Особенно мило на это смотреть, когда все классы пишет один и тот же человек, и перекладывает он работу от самого себя самому себе.

Ну вот, короче, решил я узнать, что за шум. Все-таки я ж архитектор и тимлид тогда был (не то что сейчас), надо держать руку на пульсе. Открыл доку, как сейчас помню, по Guice. Это такая гугловая вариация Спринга, типа, щадащая (да, в Джава мире даже такая большая компания как Гугл не может вырвать пальму первенства по говенности кода у настоящих Java-архитекторов).

Открыл, в общем, читаю, а там пишут: DI это то-то и то-то, new зашквар, фабрики зашквар, присоединяйтесь к революции, удаляйте все свои new Papaya() и делайте IPapaya, PapayaImpl, обмазывайте их аннотациями, заводите Module, реализуйте configure, биндите ваш класс с вашим классом, заводите Injector, инициализируйте модулем (да, даже тут без `new`), и наконец просите у него ваш класс создать. Чтобы точно никто никогда не догадался, кто у вас там кого создает и откуда что берется.

И дальше, внимание, следующая фраза: «Мы понимаем, что вам придется переделать почти все свое приложение. Мы знаем, что это займет много времени. Скорее всего, в середине пути вы начнете спрашивать себя: а зачем я это делаю, не дурак ли я? Так вот, помните: вы делаете это потому что так будет лучше».

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

С тех пор я Java-архитекторам не верю. Я вообще никому на слово теперь не верю. Если есть предложение, как улучшить код — просто расскажи, в чем предложение. Если оно нормальное, как-то специально рекламировать или убеждать кого-то в его необходимости не нужно — само предложение все скажет само за себя. А если написано «поверьте, нет времени объяснять» — это очевидная наебка и вам пытаются впарить прокисшее говно.

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

Я уже упоминал неоднократно, как выгорел от Джава экосистемы 10 лет назад. Так вот, неделю назад я имел неосторожность ввязаться в живую дискуссию по поводу Ant/Maven/Groovy как раз с ребятами из мира Java. ПТСР стрелял с регулярностью три минуты.

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

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

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

Видите проблему? Видите? Да, это именно из-за нее в жопе не только русское кино, но и русское Айти. Да любое Айти, в принципе.

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

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

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

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

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

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

С вами все в порядке. Вы молодец и все делаете правильно. Проблема в консерватории, ее уже не починить.

Также помните, что рядом тоже полно нормальных, адекватных людей, которые создают куда более приятные экосистемы. Такие, в которых люди не соревнуются в том, кто кого переусложнит и у кого Hello World займет больше строчек, сервисов и ресурсов. В которых проекты измеряются не миллионами строк кода, а десятками тысяч, и ни в чем не уступают по функционалу. Проекты, которые зарабатывают миллионы долларов и меняют мир, ничуть не менее «серьезные», вопреки мнению тех самых энтерпрайзных джавистов.

И туда всегда можно перейти, найти свое счастье и душевное спокойствие. Я в свое время сбежал на Питон, потом на Erlang, и в конце концов на Clojure.

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

На этом неделя Java в канале официально объявляется закрытой, и мой гештальт тоже. Надеюсь, в следующий раз услышу о ней не раньше чем через еще 10 лет.

P.S. Если вам нормально — ну и классно, просто проигнорируйте этот пост
P.P.S. JVM все еще нежно люблю, пост исключительно о java как экосистеме
P.P.P.S. Убрал языки, про которые я знаю только понаслышке. Там тоже может быть хорошо, но обещать не могу

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

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

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

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

Кстати, в Java логирование _есть_ в стандартной библиотеке, но проблема осталась. Почему так? Почему никто не переехал на java.util.logging? У меня две версии, и подозреваю, они сыграли обе.

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

Вторая версия — что java.util.logging вышел куцым по функциональности в сравнении с «настоящими» логгерами. Мне-то как раз это нравится, а вот Java-программистам, подозреваю, не зашло.

И тут я выскажу радикальное мнение: по мне, так логгинг должен быть максимально куцым. Тот же log4j может: срать в несколько файлов, обкусывать файлы, менять файлы в зависимости от дня недели, фильтровать записи, форматировать записи, грузить конфиги, перезагружать конфиги, варить кофе^W^W. Это полноценный фреймворк, на настройку которого можно потратить не один день.

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

А это не задача вашего приложения — решать, где я хочу видеть логи, сколько и как часто. Генерить логи — да, пожалуйста, но фильтрация, хранение, организация — это явно другой уровень и решаться должно снаружи. Когда это делается изнутри, это негибко, это лишний функционал и плохая интеграция. Будете в следующий раз пить аспирин после настройки log4j — задумайтесь об этом. 12 factor apps всем, пацаны!

Так что же, как в итоге должен выглядеть идеальный логгер? Идеальный логгер — это println.

Джон Блоу (да-да, тот самый, который Preventing the Collapse of the Civilization) высказывает (ну как высказывает, высказывал, в январе еще) интересную мысль в подкасте On The Metal.

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

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

Ну и в третьих он считает, что в принципе программы в компьютере плохо дружат. Есть, типа, shell, в котором программы обмениваются строками через пайп, и это стыд, конечно. И есть, причем очень давно, нормальный способ переиспользовать чужой код — C calling conventions и, соответственно, динамические/статические библиотеки.

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

Такая вот перспектива, издалека. Даже какой-то смысл в WASM появляется, даже не для браузеров, а для обычных десктопных утилит и программ

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

Например, в Grumpy Website есть авторизация, которая сбрасывается раз в две недели. Почему? Да потому что это гарантия, что она будет работать. Если бы она жила вечно, то прошло бы полгода-год, кому-то понадобилось бы зайти с нового компа и мы все бы узнали, что авторизация, оказывается, давно сломана. А так она тестируется регулярно и всегда в форме.

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

Да, анекдот про вылить воду из чайника и перейти к шагу 1 (налить воду) совсем не анекдот, а очень хороший совет. А вы что думали, шутки про программистов — это шутки?

Давайте расскажу вам про главное правило пет-проектов. Главное правило пет-проектов: придумать, как ничего не делать.

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

«Скрипты. Планировщик в CI запускает тесты, оформленные в pytest/junit/whatever, рисует красивые картинки, срёт уведомлениями, если что-то пошло не так. Надо только определиться, кто отвечает за реакцию на уведомления.»

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

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

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

Трюк с пет-проектами в том, чтобы обмануть себя и успеть сделать что-то, что можно показать людям до того, как ты устанешь и тебе надоест. А тебе устанет и надоест, trust me. Поэтому количество нерелевантной работы надо резать жестко и беспощадно. И поэтому я так доволен решением с авторизацией: работы нет, а тестирование выполняется.

Классическая иллюстрация этого принципа это «не пишите движок блога». Потому что устанете быстрее, чем напишете первый пост. Люди, которые хостятся на Github Pages с готовым шаблоном или на Wordpress — те, которым интересно решить проблему; люди, которые пишут движок — те, которым интересно попрокрастинировать. Поэтому вы читаете этот текст в Телеграмме, а не на каком-то самописном сайте с собственным компилятором — я бы этот компилятор до сих пор писал.

Другой пример из недавнего — Roam Research. Чуваки лет то ли пять, то ли семь сидят без сервера вообще, тупо складывают все в Firebase и ничего, работают, денег подняли. Во всей инфраструктуре нет ни одного сервера. Потом пришел создатель Athens Research, решил склонировать Roam, но еще больше не заморачиваться, и не стал делать даже Firebase. Просто сделал локального клиента, так еще и без авторизации обошелся. И все равно 2 ляма поднял. Легенда.

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

Иногда я говорю, что не понимаю чего-то, но на самом деле конечно понимаю, просто несогласен. Но есть вещи, которые я сколько умом ни пытался понять, так и не смог.

Одна из таких — поведение NaN в IEEE 754 и NULL в SQL. Как вы знаете, NaN != NaN, а NULL <> NULL.

И вот тут вопрос: ПОЧЕМУ БЛЯДЬ???

Это классический foot gun же: ты думал, что a == a, и оно почти всегда да, кроме случаев, когда нет. Хочешь проверить, что функции вернули одно и то же? == будет недостаточно. Хочешь тест написать? == не хватит. В мапу положил, а потом найти не можешь? Смотря как ищещь. Передал по сети и сравниваешь JSON с эталонным? Не сравнится, потому что в глубине где-то есть NaN. Про SQL я вообще молчу.

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

Вашему внимаю представляется список сложнейших, практически неразрешимых задач в IT:

- Инвалидация кэша
- Придумывание названий
- Off-by-one ошибки
- Кнопка «Назад»
- Плавный скролл
- Запомнить позицию скролла
- Плавные веб-анимации
- Звук на видеоконференциях
- Верстка имейлов
- Выравнивание текста и иконки
- Файловые пути с пробелами
- Запоминание «Запомнить меня»
- Не писать еще один пакетный менеджер (ой, написал)
- Логгирование в Джаве
- Юнит тесты в Джаве
- Сборка проекта в Джаве
- Выделение текста в PDF
- Оценка оставшегося времени в прогресс-барах
- Кража фокуса
- Запись в файл (надежная)
- Парсинг XML (надежный)
- Переключение режимов монитора в Windows
- Поиск пути, куда установлена Visual Studio
- Запоминание, на каком мониторе открывать окно
- Плавное изменение размера окна
- Подключение Bluetooth-наушников
- Цветовые пространства
- Ввод текста
- Вывод текста
- Часовые пояса

UPD (из комментов):

- Синхронизация файлов в iCloud
- Принтеры
- Выход из vi
- Счетчик непрочитанных
- Настройка фронтенд-проекта

Ох как я ненавижу логины и аккаунты.

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

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

Ладно, захожу. Оно говорит — нет устройств! Как нет-то, ты же, падла, нотификации мне шлешь.

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

А раз настраивал — должен был аккаунт создать? Но почему тогда он слетел? Телефон я не менял, приложение не переустанавливал. Жму логин — 1Password — нет аккаунта.

Ну ладно, нет так нет, может раньше не требовался? Жму создать, заполняю блядскую форму на восемьнадцать полей, придумываю, конечно, пароль, ввожу два раза, и емейл, конечно, тоже два раза. И конечно, посудомоечной машине нужно знать где я живу и какой у меня телефон, чтобы полоскать мои чашки. ВСЮ ФОРМУ ДО КОНЦА ЗАПОЛНЯЮ! Все с телефона, то есть максимально неудобно, в квадратике 2 на 2 сантиметра. Жму: создавай.

Создала, говорит. Иди в емейл. Иду в емейл. А там — есть такой аккаунт уже. Попробуй залогиниться, лузер. И все, даже ссылки обратно, сука, нет. А СРАЗУ НЕЛЬЗЯ СКАЗАТЬ БЫЛО???

Иду логиниться. Пароля, конечно, взять неоткуда. Жму восстановить. Иди опять в почту. Иду в почту. Вот ваш временный пароль. О, думаю, зашибись. Его-то и оставлю. Ввожу емейл и копирую пароль. Зашибись, говорит! Но пароль-то временный. Давай новый придумывай. Ну ё-маё, ну что опять началось...

Ладно, придумываю. Соглашается. Пускает. Добавляю, наконец, машину в апп. Безболезненно достаточно, кстати — потому что Я ОДИН РАЗ ЭТО УЖЕ ДЕЛАЛ КУДА ОНА ПОДЕВАЛАСЬ? А? А?

Зашибись, думаю. Теперь-то запущу чистку. Нахожу режим в приложении. Подношу палец к кнопке. ЗАПУСК ИЗ ПРИЛОЖЕНИЯ ЗАПРЕЩЕН. ИДИ ПАСИСЬ.

(Ну или если хочешь можешь еще час в ютубе гуглить, как remote start разрешить, но у меня уже сил не было, честно).

Короче, я просто спалил, какая иконка у режима чистки в приложении.

А потом подошел к машинке ногами И НАЖАЛ ТОЧНО ТАКУЮ ЖЕ КНОПКУ. Просто подошел и просто нажал. Все. Одно действие. НИКАКИХ, БЛЯДЬ, ЛОГИНОВ. ПОЧЕМУ В ТЕЛЕФОНЕ НЕЛЬЗЯ ТАКЖЕ???

Вы удивляетесь, почему «умный дом» никто так не любит? Ну вот поэтому.

Ну и про проблему логинов и того, что их пихают везде, где нужно и где не нужно.

Во-первых, идите со своими логинами нахуй.

Во-вторых, идите-идите, я не шутил.

Во-третьих, если уж вас укушенный маркетологом менеджер заставил их делать, как насчет того, чтобы эти логины не терять? В идеале я хочу вводить логин один раз в жизни. Ну может один раз за время жизни компьютера. КАК ЛОГИН МОЖЕТ ПОТЕРЯТЬСЯ???

В-четвертых, одного поля «email» достаточно ДЛЯ ВСЕГО. Просто email — письмо со ссылкой — нажал — ты внутри. Логин, регистрация, восстановление — все одинаково. В вашей форме БУКВАЛЬНО не должно быть НИ ОДНО поля, кроме email. БУКВАЛЬНО.

В-пятых, на тему логинов обязательно посмотрите «Jonathan Blow tries Razer BlackWidow TE Chroma v2 keyboard» на Ютубе. Руководство к действию.

В-шестых, идите нахуй.