-
Зачем фронтенд? (1)
Признаться, я давно потерял мысль, зачем нам фронтенд. Я имею в виду реакты-вуи, папки
node_modulesвесом в тонну, тормозной гуй и спиннеры в каждом углу.В самом деле, какую проблему мы решаем? Неужели так важно писать километры кода на js, чтобы элемент обновился динамически? Почему никто не помнит закон сохранения энергии: если на беке кода стало меньше, его станет больше на фронте? Плюс и минус схлопываются, и в лучшем случае получится то же самое. Но прибавляется энтропия, вызванная фрагментацией технологий и стеков, тулинга, языков.
Есть и другое замечание. Когда-то браузеры были медленными, и рендеринг страницы был узким местом. Даже если разметка приходила быстро, ее было трудно вывести на экран. Сайты верстали таблицами, на которых IE знатно подвисал. Поэтому Ajax казался спасением: выдернем данные в полете, не придется перезагружать страничку.
Сегодня браузеры ушли в космос: это уже почти операционные системы. Видео, дизайн, игры, офисный редактор. Если взять обычный сайт и доработать под стандарты — Etag-и, кэширование, правильная разметка, оптимизация стилей — то он будет работать мгновенно. Страницы будут открываться так быстро, что никакие аяксы не понадобятся.
Вместо того, чтобы ускорить сайт целиком, фронтендеры пишут приложения. Они как Джава — загружаются долго, но, вроде бы как, работают быстро. С оговоркой, потому что новых вкладок порой не избежать, и загружается вторая копия приложения. Со всеми этими спиннерами, загрузками и клиентским рендером.
Казалось бы, хочешь обновить кусок страницы динамически — пришли с сервера кусок разметки и вставь в нужное место. Это самый простой способ, проще невозможно. Но у фронтендера свой путь: он запрашивает данные, складывает во внутреннюю базу, подписывается на обновление базы, по событию ее изменения вызывает другое событие, которое читает базу, рендерит HTML и вставляет в документ.
Этот как налить чай не в кружку, а сначала в тазик, потом в блюдце, потом по трубочке в кувшин, а оттуда в кружку. Что ты хотел этим доказать?
Разработчики разучились мыслить критически. У всех перед глазами шоры: реакт-вуй-протобуф-кубернетис. Никто не думает, как решить задачу просто, дешево и в срок. Всем подавай бест-практис и блидинг-эдж.
-
Новый вид людей
Меня волнует, что когда-то было два вида людей: неандертальский и кроманьонский. Это именно два разных вида, а не отличие в цвете кожи или разрезе глаз. Сегодня ничего такого нет: люди всех рас отличаются незначительно (но и не абсолютно одинаковы, как любит западная повестка).
Мне бы хотелось, чтобы появился новый вид людей. Я часто их представляю: возможно, они будут жить чуть дольше; беременность будет длиться год, а не девять месяцев; их слух и зрение будут работать слегка в другом диапазоне. Возможности интеллекта не будут отличаться от нашего; будет другая система оволосения и потоотделения.
Появление конкурентов будет столь жарким событием, что ковиды и войны покажутся детским садом. Мир погрузится в истерику. Верующие найдут в Библии факты, что это потомки зверя. Военные окажутся на коне: кто как не они защитят человечество. Социальные сети лопнут от твитов и аналитики. Будет всемирная жесть.
Это будет проверка, чего мы добились за сорок тысяч лет. Я не сомневаюсь, что люди убьют конкурентов подобно тому, как кроманьонский человек убил неандертальцев.
То есть — ничего.
-
Джон и чат
Предположим, Джон не может сегодня работать. Заболела дочь, и он везет ее по врачам. Джон заходит в рабочий чат и пишет: гайз, заболел ребенок, сегодня работать не смогу.
Через двадцать минут просыпается Майкл, заходит в чат, видит сообщение Джона и отвечает: Джон, желаю твоей дочери поправиться! Еще через полчаса заходит Карл и пишет: скорее поправляйся! Через сорок минут… короче, вы поняли. В час дня выползает как-то тип со сдвинутым графиком и мотает чат. Пролистав десяток пожеланий, что он делает? Правильно — желает выздоровления дочери, а поскольку речь о ребенке, ставит тупую гифку с плюшевым медведем.
Обеим сторонам нужно помнить следующее.
Если вы — Майкл и Карл, то желать выздоровления больше одного раза не нужно. Если прям неймется, поставьте к первому сообщению лайк — в знак того, что вы присоединяетесь к пожеланию. Иначе вы затрахете коллегу и всех, кто в чате.
Если вы — Джон, и коллег не перевоспитать, не пишите о личных проблемах в общий чат. Достаточно написать руководителю и паре людей, с которыми вы плотно работаете. Остальным хватит и статуса в мессаджере.
Формально все эти пожелания вежливы. Но иногда еще вежливей будет помолчать.
-
Репозиторий функций
Где-то я прочел тезис: мол, хорошо бы иметь платформу, где в репозитории лежат не пакеты, а функции. То есть гранулярность библиотек столь мала, насколько это возможно. И вот тогда бы мы зажили.
Не понимаю, зачем об этом мечтать, ведь такая платформа есть — это Node.js и npm. В ней тысячи пакетов, которые состоят из одной-двух функций. Прямо сейчас прошелся по папке
node_modulesодного проекта. Обнаружил там забавные вещи:-
ansi-red— пакет для вывода текста красным, одна функция, пять строк на весь файл; -
expand-range— что-то для диапазона значений, одна функция; -
for-in— синтаксический сахар для цикла, одна функция, 6 строк; -
is-buffer,is-number,isarray,isobject— пакеты-проверки на нужный тип, везде одна функция на 5-6 строк; -
list-item— генерилка списка с буллитами, одна функция; -
markdown-link— рендер ссылки markdown, одна функция; -
randomatic— генератор случайной строки, две функции; -
repeat-element— генератор массива с повтором элемента, одна функция.
Есть и другие однострочники, не хочу утомлять. Просто факт: вот тебе платформа, куда можно заливать функции и делать ссылку на них, и это даже работает.
Имея все это на руках, хочется спросить: помогли тебе твои ляхи? Мы уже переехали в рай Node.js верхом на радуге? И что сегодня сказал бы автор тезиса? Опять чего-то не хватает?
Я очень скептичен к Node.js как платформе и не вижу смысла опять об этом писать. Речь о другом: высказывая тезис, даже самый фантастический, нужно помнить о том, что его легко проверить. Для этого не нужно ждать пять лет. Почти все, о чем мы мечтаем — это лишь слабые навороты к тому, что уже есть.
А истинно новые вещи проверить наперед невозможно.
-
-
Концепция
Итак, вы придумали изящную концепцию, простую и понятную. Но в процессе выяснилось, что ей мешают костыли: надо воткнуть условие здесь, условие там, словом, концепция поползла. Никакая она больше не изящная.
Возможны три варианта. Первый — идти до конца, то есть воткнуть столько костылей, сколько нужно для запуска в проде. Далее отчитаться перед начальством, съездить на конференцию с зажигательным толком, собрать все ништяки и уйти в закат. Позже фирма наймет кого-то другого, чтобы все переделать.
Второй путь — изменить внешние условия так, чтобы концепция не разваливалась. Например, переместить данные в другое место, отказаться от устаревших протоколов, поменять рабочий процесс. Это может быть справедливо, если сохранит изящность концепции.
Третий путь — если концепция, пусть даже изящная, не может жить в текущих условиях, она признается негодной. Вместо нее ищут другую концепцию. На первый взгляд она может быть уродливой, но ее достоинство в том, что она хорошо себя чувствует в тяжелых условиях.
Что именно выбрать — каждый решает сам. Лично мне нравится второй вариант. Если концепция простая, то есть может быть описана двумя предложениями, она прослужит долго. Ради этого стоит напрячься и передвинуть мебель так, чтобы в будущем ничего не двигать.
-
SOLID (2)
В продолжение прошлой заметки: особого упоминания заслуживает ООП. С ним можно играть в бинго. Если разговор зашел про ООП, кто-то обязательно скажет, что НА САМОМ ДЕЛЕ под ним имеется в виду что-то другое. То ООП, что в джавах и питонах, неправильное! Был божественный замысел, который неверно истолковали.
Дальше пойдет кряхтение о том, что Алан Кей был биологом. По аналогии с клетками он придумал обмен сообщениями, и что верное ООП только в Эрланге из-за модели акторов… все это я слышал много раз. Но скажите, что делать с зоопарком ООП в разных языках? Если это другое ООП, то может и назвать его по-другому? Если оно то же самое, то попуститься и все-таки признать?
И вообще, ничего, что прошло полвека со времен Кея и модели клеток? Ситуация как бы изменилась. Слегка.
Современное ООП — примерно как живопись. Найдено столько стилей и направлений, что их нельзя описать пятью буквами SOLID. Да, когда-то в них помещался весь опыт индустрии, и их возвели в догму. Но сегодня попытки объяснить ООП в Питоне терминами SOLID напоминают попытку заправить шубу в трусы. Не вмещается!
От ООП, кстати, уходят к классическому подходу структура-функция. Тысячи гоферов колбасят код в Гугле и других фирмах. Структура-функция-интерфейс, структура-функция-интерфейс… теперь это тоже ООП называется? Или все-таки можно писать в прод без ООП?
Просто маятник качнулся в обратную сторону. Теперь он удаляется от тех, к кому двигался раньше.
Если сравнивать языки, то в плане ООП мне больше всего нравится Lua. Там концепция ООП умещается в абзац. Объект — это таблица с данными, которой назначена мета-таблица с функциями. Когда вы обращаетесь к таблице, она ищет поле или метод в себе, потом в мета-таблице, потом в мете той таблицы и так далее. Вот и все ООП: инкапсуляция и наследование одим махом. Никаких виртуальных деструкторов, никаких Function.Prototype. И никто не парится.
Конечно, с такими тезисами вы не пройдете собес, если встретится ООП-маньяк. Но и вести себя с ним надо подобающе: не поднимать больные темы, принимать его сторону, если становится буйным. И все получится.
-
SOLID (1)
Когда говорят о REST, SOLID и прочих абстракциях, допускают следующий оборот. Мол, вы не так поняли оригинальный замысел: НА САМОМ ДЕЛЕ имелось в виду другое, просто техническая реализация отличается от задуманного.
Я никогда не мог понять, зачем так говорят. Если реализация REST на базе HTTP + JSON отличается от абстрактного REST, то либо не называйте ее так, либо смиритесь, что она отличается от замысла. Всяко лучше, чем с пеной у рта доказывать, что на самом деле имелось в виду что-то там.
Если идею автора пришлось доработать, чтобы претворить в жизнь, то это проблема автора, а не того, кто пользуется реализацией.
Конечно, есть те, кому нравится унижать людей на собесах. Тут REST и SOLID заходят на ура. Маньяки, ничего не поделаешь. Но мы-то с вами тут при чем?
-
Замеры
Если вы долго поддерживаете код, полезно делать замеры: стал ли он быстрее, медленнее или ничего не изменилось.
Не обязательно замерять каждый коммит. Достаточно делать это каждые N версий. Даже скромных данных будет достаточно, чтобы понять, где вы свернули не туда или наоборот — в проекте все круто.
Ниже — замеры драйвера Postgresql в разрезе версий. Разрыв между версиями 0.1.2 и 0.1.11 вызван тем, что в этот период я исправлял то, что не окажет влияния на производительность. А в 0.1.12 было то, что оказывает, поэтому замер необходим.
Картинка ниже показывает, сколько времени нужно, чтобы забрать данные с сервера без парсинга. С каждой версией эта метрика уменьшается. Вызвано это ленивым парсингом. Данные не разбираются сразу, а оборачиваются в класс, который притворяется словарем. При обращении к ключу происходит разбор поля и сохранение во внутреннем кэше.
То же самое, но для сложного запроса с полями разных типов:
Последняя версия выигрывает у конкурента на порядок: 59 против 590 милисекунд. Разве не круто, когда оцениваешь разницу визуально?
Другая метрика: число запросов в секунду HTTP сервера, который вынимает из базы случайные данные и отдает в JSON. Здесь видно, что хотя прирост есть, но на некоторых платформах число RPS слабо, но проседает. Это потому, что при сбросе данных в JSON срабатывает тот самый ленивый парсинг, а он отнимает время.
Есть еще одна метрика: очень сложный запрос с принудительным парсингом. Здесь видно, что он дает о себе знать: с каждой версией цифра повышается.
Из этих картинок можно извлечь пользу, например оценить, где мы выиграли и потеряли и насколько. В моем случае я считаю, что главное — как можно скорее забрать данные с сервера и освободить соединение. За это мы платим чуть менее быстрым парсингом, но ничего — это осознанный выбор.
Другое дело, когда замеров нет в принципе и остается гадать — может, станет быстрее, а может быть, медленнее. Компьютеры у всех мощные, телефоны меняют каждый год, поэтому выкатывай, там разберемся. Кажется, большинство программ обновляют именно так.
-
Никнейм в JetBrains
Смешно: регистрация в JetBrains запрашивает никнейм.
Вот у меня есть имя и фамилия. У меня есть электронная почта. У меня есть телефон. А никнейма нет. Где взять никнейм? Где его выдают?
Считается, что я должен его придумать. Но зачем? Какую пользу дает никнейм? Вы там что, не можете сгенерить UUID, а в сообщении писать имя и фамилию?
Согласен, что на форуме майнеров или имиджборде без ника никуда. Не будешь же ты подписываться полным ФИО. Но у JetBrains не форум анонимных программистов. У них продукт, и какую роль в нем играет никнейм — неясно.
Никнейм — это либо рудимент нулевых, машинное имя пользователя, удобное на бекенде. Либо это способ анонимности, чтобы постить сомнительный контент без разоблачения.
Оба случая проходят мимо JetBrains, что и желаю им понять.
Ну и классика: еще ничего не написал, а форма кричит ошибками.
-
Ковид
Вопрос между делом: как дела с ковидом? Он уже прошел? Все выздоровели? Повальная вакцинация сделала свое дело? Все приобрели иммунитет?
Где мы находимся: уже перешагнули катастрофу? Ковида больше не будет?
Может быть теперь, когда ковидная истерия сходит на нет, не мешало бы провести ретро, а именно:
- надо ли было запирать людей в четырех стенах на год?
- надо было ставить прививки всем поголовно, в том числе беременным и детям?
- нормально ли было пускать в магазин за едой по QR-коду?
- хорошо ли было отказывать в помощи тем, у кого не ковид, а сердце, например?
В целом, отношение к ковиду у меня ровно то же, что и к Титанику и Чернобылю. Во всех случаях было что-то из ряда вон, но в основном людей угробили из-за паники и суетливых мер.
Искренне надеюсь, что лет через сто, когда виновники будут в могиле, кто-то выпустит нормальный обзор ковидной истерии. И там будет ровно то, что в Титанике и Чернобыле: эти бедняги могли все сделать правильно, но увы.
Writing on programming, education, books and negotiations.