-
Облачная учетка
В повести 1984 герой читает книгу братства. В числе прочего ему попадаются строки: “нужно, чтобы колеса индустрии вращались, но мир оставался бедным”. В мире Оруэлла решением стала война, которая сжигала лишние ресурсы.
Эти строки напомнили о том, что происходит с разработкой софта. Недостаточно выпустить программу и продать ее. Нужно навязать услугу, за которую пользователь платит постоянно. Решением стала облачная учетная запись.
В самом деле, как раньше писали софт? Выпустили условный The Bat! или WinAMP версии 1. Продали. Через год выпустили версию 2. Тоже продали. Третья версия либо вышла унылым г..вном, потому что идея выдохлась, либо пользователи не хотят обновляться, либо продавать уже некому. Поток денег иссяк, а штат за эти годы только распух, и чем платить зарплату, тоже не ясно.
Идеальное решение — посадить клиента на ежемесячную подписку, но как? Для этого нужно обоснование, ведь если ты выпускаешь программу раз в год, то резонно услышать вопрос — за что подписка?
Облачная учетка снимает эти проблемы. Она требует хостинг (конечно, в Амазоне) со всеми вытекающими: виртуальные машины, база данных, файловое хранилище, очередь задач и другие облачные штучки. Плюс нужны пара бекендеров, пара фронтов, специалист по безопасности. Все это требует денег просто за факт своего существования. Еще емейл рассылки, копирайтер и верстальщик писем.
И вот фирма выпускает анонс, что для нашего же блага (!) для работы программы нужна учетная запись. Все, кто ее покупали, получат полгода грейс-периода, а потом — плати или до свидания.
Примеров на моей памяти было достаточно. Шесть лет назад я покупал 1Password версии 5. Сегодня он не работает без облачной учетки: первый экран требует авторизации — на мастер-пароля, как раньше, именно облачной учетки.
Программа Dash для офлайн-документации пошла тем же путем. Я купил версию 6, а уже следующая версия перешла на подписку.
Я понимаю подписку с точки зрения бизнеса: она дает прогноз финансов. Умножаешь цену на число пользователей и готово: точно знаешь, сколько денег упадет на счет. Ясно, что можно планировать, а что нельзя.
Я понимаю подписку как программист: добавил в базу флаг “есть доступ”, и когда подписка оформлена, ставишь true, а если остановилась, то false. На практике не все так просто, но по крайней мере понятно.
У меня у самого был коммерческий пет-проект. Идея о том, что нужно считать потребленные ресурсы и добавлять их в квитанцию, бросала в ужас. Я повесил подписку через Paypal и был таков.
Но я отказываюсь принимать подписку как пользователь. Что 1Password, что Dash, что WinAMP были уже хорошими тех версий, что я их скачивал. Мне не нужен 1Password версии 7 и 8, если шестая отлично работает. Мне не нужна облачная учетка. Мне не нужны емейл рассылки, опросы и остальное. Достаточно, чтобы над программой работал один человек, подчищая баги. Но тогда не будет бизнеса.
Так и получается колесо Сансары: бизнес делает софт, собирает базу пользователей и вводит подписку. Пройдя этот круг раз десять, я понял, что пора выбираться: брать софт, который поддерживается на некоммерческой основе. На первый взгляд он не такой крутой, как коммерческий, но ведет себя лучше на долгой дистанции.
А насмешки я как-нибудь переживу, не в первый раз.
-
Автоответчики
Пока мы не ушли от темы, замечание об автоответчиках.
Операторы бессовестно включают автоответчик на всех тарифах. Это работает так: если абонент не берет трубку в течение N секунд, включается бот, который предлагает записать сообщение и передать его.
Все бы ничего, если бы не прогресс в распознавании речи. Все, что надиктует вам собеседник, будет распаршено и прогнанно через алгоритмы. Если звонила тетушка с просьбой собрать шкаф, то у вас вылезет реклама шкафов и сборки мебели на дому.
Как и в прошлой заметке, автоответчики устроены так, чтобы вытянуть из собеседника максимум информации. Недавно звонил сестре, и после четвертого гудка включился бот. На фоне шум, словно едет маршрутка, и женский голос отвечает — алло? Но голос совершенно другой женщины! Упор на то, что я начну разговор, а в конце бот скажет — спасибо, передам.
То же самое у Тинькова: автоответчик Олег включен по умолчанию. Он начинает разговор с приветствия, не уточняя, что он бот. Расчет тот же самый — собрать как можно больше приватной информации.
Убедитесь, что у ваших родственников, особенно пожилых, выключены автоответчики. Во-первых, будет меньше слива приватных данных. Во-вторых, у родственника будет больше времени принять вызов, потому что оператор заинтересован включить бота как можно быстрее.
-
Борьба с PDF (2)
Недавняя заметка про замену PDF на HTML, была, конечно, бредом. Не получится по ряду следующих причин.
Бизнес-требования. Если руководство или тем более регулятор ожидают PDF, ты им ничего не докажешь. Ни про какой HTML там не слышали.
Подписи. Вокруг PDF построены сервисы и тулинг для подписей. Электронно подписанный PDF имеет такую же силу, как и бумажный договор. В техническом плане подписать HTML легко — достаточно поместить в заголовок тег
<signature>с RSA-ключом, — но опять же, под это нет тулинга.Отображение. Ваша правда, PDF везде отображается одинаково — проблемы бывают в самых редких местах. В случае с HTML неопределенность гораздо шире: может поплыть и на телефоне, и на Линуксе, а в Винде браузер заблокирует base64-изображения.
Но все-таки: порой PDF бывает таким душным! Напрягает его ориентация на бумагу, хотя большинство документов сейчас не печатают, а смотрят с экрана. В таких ситуациях HTML дает больше плюшек: он нормально покажет длинные таблицы без разрывов. В HTML работает минимальная интерактивность. В сложном отчете можно сделать табы на чистом CSS. HTML на ура копируется в офисные документы: скажем, тег
<table>идеально сядет в таблицу Excel, в то время как копирование из PDF — сущий ад.Можно сказать, что PDF и HTML лежат на разных концах одной шкалы. Приближаясь к одному, уходишь от удобств другого.
-
Борьба с PDF (1)
По всему миру люди борются с PDF. Скажем, нужно сгенерить отчет, и начинается: рендерим файл LaTeX и скармливаем pdflatex. Глючно, не очевидно, требует установки Латеха и пакетов. Рассыпается при смене минорной версии. Кросплатформенно только в теории.
Можно собрать при помощи Java-библиотеки. Импортировать двадцать классов
com.pdf.MySuperCellFactoryи как-то их соединить. Тоже не очевидно, трудно дебажить.Неплохой вариант: сгенерить HTML и напечатать PDF при помощи headless-Хрома. Уже лучше, но требует установки Хрома и chromedriver. Запускать Хром на каждый чих расточительно, нужна отдельная машина.
Короче, с какой стороны ни зайди, везде плохо.
Так вот: почему бы не генерить документы в HTML? Стили и картинки зашиты в один файл через
src=data:base64. Получаем один .html-файл без зависимостей. Браузер есть везде, не нужно ничего ставить. При желании можно адаптировать стили под мобильный экран, чтобы смотрелось везде хорошо.Почему так не делают? Зачем PDF, если вот он, HTML: любой шрифт, картинки, таблицы и все прочее?
-
Перезагрузка айфона
Если хочется перезагрузить айфон, знайте, что такой кнопки там нет. На экране выключения только три пункта: выключение, экстренный вызов и отмена. Никакой перезагрузки. Тут у меня начинается двоемыслие.
С одной стороны, перезагрузка телефона — бестолковое действие. Что-то вроде дефрагментации диска и очистки реестра, чем мы страдали в нулевых на винде. Перезагружать телефон, чтобы устранить какой-то баг, глупо — нужно починить баг, и не придется ничего перезагружать.
Примерно так и рассуждали в Эпле: телефон либо работает, либо нет, а перезагружаются пусть рутованные китайские андроиды.
С другой стороны, напрягает это лицемерие. Эпл ведет себя так, словно их телефоны действительно не нуждаются в перезагрузке, а это не так. Мой айфончик иногда теряет сотовую связь, и это никак не исправить без перезагрузки. А поскольку ее нет, нужно выключить телефон, подождать секунд десять и зажать кнопку включения, пока не появится яблоко. Довольно глупо.
Типичное поведение Эпла: сделать вид, что проблемы нет и улыбаться. А проблема-то есть.
-
Бумеры и зумеры
Я никогда не использую слова “бумер” и “зумер” по двум причинам.
Во-первых, они грубоваты. Так уж случилось, что их используют в пренебрежительном тоне, когда одна группа говорит о другой. Даже в нейтральном контексте от слов “бумер” и “зумер” идет запашок.
Во-вторых, это лишняя нагрузка от вычислений. Как правило, неважно, когда человек родился, важно, сколько ему лет. Поэтому когда говорят “бумер”, я подвисаю на секунду, пытаясь вычислить, сколько ему лет. Почему бы не сказать прямо: люди от 50 до 60 лет? Если “зумер” — от 20 до 30 лет?
Авторам и редакторам взять на заметку.
Сюда же относятся “миллениал”, “поколение Y” и прочая ахинея, про которую я забыл.
-
Зачем фронтенд? (2)
Ситуация: сломался фронтенд. Непонятная ошибка с null, код обфусцирован, сорс-мап нет, хотя это тестовое окружение.
Открываю исходник и вижу: поиск в коллекциях, парсинг чисел и дат, форматирование с учетом локали, поход в сеть и прочие штучки. И мне правда интересно — что этот код делает на фронтенде? Почему он не на бекенде? Чего ты добился, заставив этот код крутиться на клиентской машине?
Ты потерял всякую предсказуемость, потому что код выполняется уже не на сервере с линуксом и джавой фиксированных версий. У тебя зоопарк клиентов, где хромы-фаерфоксы с блокироващиками всего и вся. Ты потерял нормальные стек-трейсы. Ты потерял удобный прогон тестов. Ты потерял логирование и отправку ошибок в Sentry. Ты банально сделал хуже по всем статьям.
Звоню фронтендеру. Первое, что от него слышу — сегодня пятница, и он уходит через две минуты. Падает фронтенд? Это с бэка приходят неверные данные, почисти базу и заработает. Сорс-мапы? Тебе надо, ты и добавь. Созвониться в понедельник? У меня будет выходной. Но ты держись!
Я понимаю, что фронтендеру надо зарабатывать, да. Однако лучшее, что можно сделать с проектом — это сократить фронт до одного верстальщика и переехать на северный рендер. Вся логика будет в одном месте; будут тесты, будут прогоны на CI, будут предсказуемые билды. А верстальщик пусть рисует макеты.
Да, будет что-то, что не ложиться на серверный рендер. В таком случае мы это просто не делаем. Если из десяти хотелок мы сделали девять, а последняя ложится поперек, то ее перерабатывают. Например, бьют фичу на два экрана, убирают лишнюю интерактивность и так далее.
Кому-то это не понравится, но что поделать? Чтобы проект шел легко, нужно сбросить балласт. А роль балласта часто играет фронтенд.
-
Зачем фронтенд? (1)
Признаться, я давно потерял мысль, зачем нам фронтенд. Я имею в виду реакты-вуи, папки
node_modulesвесом в тонну, тормозной гуй и спиннеры в каждом углу.В самом деле, какую проблему мы решаем? Неужели так важно писать километры кода на js, чтобы элемент обновился динамически? Почему никто не помнит закон сохранения энергии: если на беке кода стало меньше, его станет больше на фронте? Плюс и минус схлопываются, и в лучшем случае получится то же самое. Но прибавляется энтропия, вызванная фрагментацией технологий и стеков, тулинга, языков.
Есть и другое замечание. Когда-то браузеры были медленными, и рендеринг страницы был узким местом. Даже если разметка приходила быстро, ее было трудно вывести на экран. Сайты верстали таблицами, на которых IE знатно подвисал. Поэтому Ajax казался спасением: выдернем данные в полете, не придется перезагружать страничку.
Сегодня браузеры ушли в космос: это уже почти операционные системы. Видео, дизайн, игры, офисный редактор. Если взять обычный сайт и доработать под стандарты — Etag-и, кэширование, правильная разметка, оптимизация стилей — то он будет работать мгновенно. Страницы будут открываться так быстро, что никакие аяксы не понадобятся.
Вместо того, чтобы ускорить сайт целиком, фронтендеры пишут приложения. Они как Джава — загружаются долго, но, вроде бы как, работают быстро. С оговоркой, потому что новых вкладок порой не избежать, и загружается вторая копия приложения. Со всеми этими спиннерами, загрузками и клиентским рендером.
Казалось бы, хочешь обновить кусок страницы динамически — пришли с сервера кусок разметки и вставь в нужное место. Это самый простой способ, проще невозможно. Но у фронтендера свой путь: он запрашивает данные, складывает во внутреннюю базу, подписывается на обновление базы, по событию ее изменения вызывает другое событие, которое читает базу, рендерит HTML и вставляет в документ.
Этот как налить чай не в кружку, а сначала в тазик, потом в блюдце, потом по трубочке в кувшин, а оттуда в кружку. Что ты хотел этим доказать?
Разработчики разучились мыслить критически. У всех перед глазами шоры: реакт-вуй-протобуф-кубернетис. Никто не думает, как решить задачу просто, дешево и в срок. Всем подавай бест-практис и блидинг-эдж.
-
Новый вид людей
Меня волнует, что когда-то было два вида людей: неандертальский и кроманьонский. Это именно два разных вида, а не отличие в цвете кожи или разрезе глаз. Сегодня ничего такого нет: люди всех рас отличаются незначительно (но и не абсолютно одинаковы, как любит западная повестка).
Мне бы хотелось, чтобы появился новый вид людей. Я часто их представляю: возможно, они будут жить чуть дольше; беременность будет длиться год, а не девять месяцев; их слух и зрение будут работать слегка в другом диапазоне. Возможности интеллекта не будут отличаться от нашего; будет другая система оволосения и потоотделения.
Появление конкурентов будет столь жарким событием, что ковиды и войны покажутся детским садом. Мир погрузится в истерику. Верующие найдут в Библии факты, что это потомки зверя. Военные окажутся на коне: кто как не они защитят человечество. Социальные сети лопнут от твитов и аналитики. Будет всемирная жесть.
Это будет проверка, чего мы добились за сорок тысяч лет. Я не сомневаюсь, что люди убьют конкурентов подобно тому, как кроманьонский человек убил неандертальцев.
То есть — ничего.
-
Джон и чат
Предположим, Джон не может сегодня работать. Заболела дочь, и он везет ее по врачам. Джон заходит в рабочий чат и пишет: гайз, заболел ребенок, сегодня работать не смогу.
Через двадцать минут просыпается Майкл, заходит в чат, видит сообщение Джона и отвечает: Джон, желаю твоей дочери поправиться! Еще через полчаса заходит Карл и пишет: скорее поправляйся! Через сорок минут… короче, вы поняли. В час дня выползает как-то тип со сдвинутым графиком и мотает чат. Пролистав десяток пожеланий, что он делает? Правильно — желает выздоровления дочери, а поскольку речь о ребенке, ставит тупую гифку с плюшевым медведем.
Обеим сторонам нужно помнить следующее.
Если вы — Майкл и Карл, то желать выздоровления больше одного раза не нужно. Если прям неймется, поставьте к первому сообщению лайк — в знак того, что вы присоединяетесь к пожеланию. Иначе вы затрахете коллегу и всех, кто в чате.
Если вы — Джон, и коллег не перевоспитать, не пишите о личных проблемах в общий чат. Достаточно написать руководителю и паре людей, с которыми вы плотно работаете. Остальным хватит и статуса в мессаджере.
Формально все эти пожелания вежливы. Но иногда еще вежливей будет помолчать.
Ivan Grishaev's blog
Writing on programming, education, books and negotiations.