Цифровые Мысли

Практически в каждом софтверном проекте, где участвуют более одного участника, или даже один разработчик но с памятью как у меня, рано или поздно встаёт вопрос документирования процессов: как компилировать, как запускать, как тестировать, как настраивать, и т.д. Так рождается файлик HOWTO.md.

И я нашёл замечательный инструмент под названием just. Ставится одной командой curl --proto '=https' --tlsv1.2 -sSf https://just.systems/install.sh | bash -s -- --to ~/bin (если конечно не бояться curl-pipe-bash). С виду он похож на старый добрый make: есть текстовый Justfile, в котором хранится именованный список рецептов. Однако в отличие от make, тут нет никаких подкапотных проверок - все зависимости между рецептами явные. И сами рецепты не обязательно последовательности шелл-команд, они могут быть написаны на любом языке (хоть на TinyC с указанием #!/usr/local/bin/tcc -run). И есть ещё куча мелких особенностей, делающих just особенно удобным: рецепты умеют принимать аргументы, есть автоматическая загрузка переменных окружения из .env, внутри есть несложная поддержка переменных и функций, всё очень прагматично.

Теперь в своих проектиках я могу просто написать just build или just start.

Несколько лет назад один латвийский программист Pēteris Caune написал гениальную в своей простоте систему мониторинга интернет-сервисов HealthChecks.io: каждый сервис раз в определённое время должен прислать уведомление "я ещё жив", а когда уведомления перестают приходить - владельцу приходит предупреждение. Работает отлично, успешно мониторит мой домашний сервер. Рекомендую.

Но жизнь - штука чудесатая...

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

Modern problems require modern solutions.

Как известно, программист - это такой работник умственного труда, который на работе старается спрограммировать всё побыстрее, чтобы наконец пойти домой и попрограммировать для удовольствия. А как же тут попрограммировать для души, когда домашний игровой комп сыграл в ящик, не гудит и не мигает лампочками? Пришлось выделить из семейного бюджета солидную сумму на покупку нового компа в серьёзной конфигурации: Ryzen 7, RTX видеокарта, 32G памяти, все дела.

Прошло несколько недель (COVID всё же на дворе), и настал светлый день. Уставший FedEx'овец в маске дотащил здоровую коробку, и не спрашивая росписи о доставке, умчал вдаль шурша опавшими листьями. Коробку распаковали, комп собрали, подвели питание, включили - он загудел, засверкал светодиодными лентами через боковое стекло. Красота!

Тут меня начал мучать соблазн - ну что я, не настоящий программист что ли? Не пропадать же такой вычислительной мощности только для вечерних загонялок в Doom! Надо поднять нормальную Linuxовую виртуальную машину для разработки, а может даже и несколько, чтобы сделать себе devel, staging, и production.

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

Теперь буду записывать себе на память инструкции по поднятию домашней системы:

После этого можно удовлетворённо попить чайку и переходить к следующей стадии.

Гениальный Фейнман в своей книге описывал занимательную историю о строительстве первых ядерных очистных установок. Ему, молодому специалисту, приносят на обзор свежий проект обогатительного завода - пачку синек со схемами накопителей, клапанов, труб и насосов. Офигевший от безумной сложности увиденного, Фейнман тыкает пальцем в один из таинственных крестиков и спрашивает "а что если этот клапан заклинит?". Инженеры смотрят на синьки, водят пальцами по линиям труб, и изумлённо произносят "всё ж накроется нафик! вы просто гений, мистер Фейнман!"

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

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

Есть правда и небольшая тонкость - надо всё-таки чувствовать "куда надо бить молотком", за это нам и платят нашу зарплату...

А подскажите мне, коллеги-программисты, какой нонеча самый кошерный способ правильно описывать HTTP APIs? Ну вот так, чтобы свой обычный REST JSON API, описать его один раз и чтобы дальше всё само получилось: документация, клиенты для скриптовых (и не только) языков, какой-нибудь online playground, и всё такое?

Мы в нашей конторе пять лет назад, когда внедряли REST, ничего зрелого и толкового не нашли, и поэтому запилили свой велосипед: Sleepwalker. Это потом бурным цветом расцвели RAML, Swagger, WADL и прочие, а у нас уже наросли кучи полезного code base.

Вот я и думаю - если бы новый проект начинать сейчас, то что бы следовало взять за основу? Там же только на первый взгляд всё несложно, а чуть углубился в детали - и из-под каждой по дьяволу мерещится. А вдруг хочется поддержать не только JSON, а например ещё и XML? А если захочется какой-нибудь CSV или вообще blob наружу выдать? А как ошибки документировать? А как HTTP errors пересекать с ошибками приложения? А как bulk-операции реализовывать? И прочее, и прочее, и прочее...

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

Сижу, изучаю очередной JavaScript-фреймворк. На этот раз YUI3. Раньше приходилось покопаться в Dojo, была задача за пару месяцев изучить ExtJS (aka Sencha) и пописать на нём. И всё это время одолевает меня один вопрос-непонимание...

И нет, этот вопрос отнюдь не "Ну почему же универсальным языком интернетов оказался этот ужасный монстр?" У нас, программистов, ответ "так исторически сложилось" подходит почти к любому вопросу. Ладно... Я другого не понимаю.

Каждый серьёзный фреймворк начинается с того, что вводится своя система классов, свойств, модулей и пр. Почему? Потому что на голом JS писать большие системы так же удобно как на ассемблере и вообще "см. рис.1." Потом поверх этой системы наворачиваются всякие паттерны, на которых строятся MVC, виджеты и всё остальное. Причём шаг влево, шаг вправо от этих паттернов - и всё начинает становиться раком в самый неподходящий момент (поскольку язык динамический и никаких compile time checks нет и вообще "см. рис.1.").

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

Делов-то: взять, скажем CoffeeScript, форкнуть его и допилить немножко. Радикально было бы адаптировать какой-нибудь Haxe или Elm. Но практически хватило бы даже минимальной кодогенерации в JavaScript. А никто не делает!

Впрочем - выяснилось, что я немножко вру. Таки-есть один скриптовый язык, заточеный под Ember.js (Иуда рулит!) - EmberScript. Тем более непонятно, почему другие серьёзные игроки в эту сторону не смотрят. Занимался бы я UI так, как занимался десять лет назад - точно бы учудил такую надстройку к ExtJS. А сейчас - нет, лучше пойду свою REST-систему на C++ допиливать...

Коллеги интересуются, что в конце концов случилось с идеей написания веб-сервиса на плюсах. Спрашивали - отвечаем!

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

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

Довольно быстро с дистанции сошли SproutCore (который теперь Ember), Qooxdoo, dHTMLx, SmartClient, Rico. Туда же пошли монстры вроде AppCraft.

В финал вышли: jQuery UI, ExtJS, Dojo и YUI3. Отбросил YUI3, потому что где будет Yahoo даже через полгода - совсем непонятно, плюс даже третья версия показывает признаки старости. jQuery UI выглядел неплохо, но разработка его как целого тулкита у меня вызывает лёгкое недоумение (они там похоже простое дерево третий год пишут). ExtJS, особенно четвёртая его инкарнация, очень хорош, однако его лицензионные заморочки настораживают даже меня (а что скажут юристы?!). И остался Dojo Toolkit.

Резюмируя, в общем Dojo мне понравился и, если не наткнусь на что-то совершенно фатальное, буду строить UI именно на нём. Если у кого будут вопросы по Dojo - приходите обсуждать на ХэшКод или на StackOverflow.

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

Дано: линуксовая система с жадным до памяти софтом с C++ API.

Надо: прикрутить сверху Web UI поверх Apache, чтобы всё красиво конфигурить, смотреть всякие результаты: таблично и графически, плюс сваять своё подобие портальной системки чтоб уметь строить страницы с наборами своих виджетов.

Вот и думаю - как бы всё это задизайнить правильно и с перспективой? Собственно вопрос архитектуры распадается на два связанных вопроса: 1) на чём писать клиентскую сторону? и 2) на чём писать серверную сторону?

Клиент. Есть большой соблазн взять какой-нибудь ExtJS или Dojo (или SproutCore, или dhtmlx, или SmartClient, или на базе jQueryUI что-то своё) и построить в браузере монолитное веб-приложение со всеми рюшечками. Заманчиво конечно замахнуться на такое ультра-современное решение ибо и HTML5 на пороге, веб-приложения проникают везде и повсюду, да и демки все выглядят захватывающе. Отдельный плюс - серверная компонента сокращается до тоненькой прослойки над C++ API, которую можно написать на чём угодно, хоть на C++ сделать модуль к Апачу. Однако мне кажется что риск слишком велик. Написание приложений на JS - дело относительно молодое, подходы не устоялись, API всё ещё гуляют, плюс зоопарк браузеров просто вразнос пошёл. Опять же - непонятно, где искать JS-программистов соответствующего уровня? (Да даже оценивать JS-программистов - уже задача нетривиальная!) И сколько займёт процесс изучения конкретного выбранного JS-фреймворка, даже если у него такая неплохая документация как у Sencha? В общем, технологически - амбициозно, а вот организационно - всё же рисковано.

Сервер. Здоровая альтернатива - делать всё более-менее традиционно: MVC-фреймворк на сервере, те же jQueryUI или Dojo для оживляжа страниц, и JSON/XML для транспорта. Подводных камней видится гораздо меньше, но проще всё равно не становится. Всё равно надо думать - для начала о серверной платформе. Попробуем решить задачу перебором...

Мне так кажется, что на один бокс сажать Java с другими прожорливыми компонентами - нерационально. Прожорливость + непредсказуемость GC = проблемы. Так что отпадают многочисленные Java-фреймворки (Spring, Stripes, Play, и др.), химерный GWT и JVM-based Scala (Lift) и Groovy (Grails). При всей моей трогательной любви к Perl реальных перспектив у него не вижу ни с Perl5 ни с Perl6 несмотря на Ренессанс, да и TIMTOWTDI в командной разработке не будет помогать. Так что отпадают Catalyst, Mojo, Dancer. PHP сразу нет, потому что дикая эклектика и вообще плохо пахнет. ASP - нет, потому что среда линуксовая и Microsoft сюда тянуть себе дороже.

Насчёт написания веб-компонента на C++ пока не могу даже определиться - сумасшествие это или реальный вариант. Гугление вроде бы выдаёт некоторую информацию, но стоит ли бросаться в этот омут? Наверное всё же - нет.

Итого что у нас остаётся: модный Ruby и кошерный Python. То есть Rails и что-то из Django, Pyramid, TurboGears. Rails я на зуб пробовал - мне понравилось. И общая архитектура, и инструментарий для тестирования, и динамичность сообщества разработчиков. Однако несколько смущает сам Ruby: во-первых, непонятно где искать рубистов, а во-вторых опять же может выйти TIMTOWTDI. Питоновые фреймворки руками не щупал, но верю что там тоже всё должно быть примерно аналогично (и даже более однозначно из-за the python way). Есть правда озабоченность моментом Python 2.x против Python3K... А точнее пока непонятно как сравнивать.

Так что судя по всему, придётся выбирать между Rails, Pyramid и TurboGears. Методом тыка и прототипирования.

Коллеги, веб-девелоперы - скажите своё слово, поделитесь советом, а?

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

Очень любопытные технологии. Надо будет попробовать на практике.