Пишите от руки чаще

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

Мозг в процессе письма от руки работает принципиально иначе и результат не сравним с клавиатурным вводом ПК и тем более смартфоном. Да, от руки медленнее. Но в процессе письма от руки задействуются другие зоны мозга. Рукописный формат влияет на форму изложения мысли и на её содержание. Рукопись требует внимания, а значит и чистоты и лаконичности мысли.

Календари, ежедневники, напоминалки, доски to-do и прочие kanban тоже стали преимущественно электронными. И это также влияет, как минимум на расстановку приоритетов. Бумажный ежедневник имеет свои незаменимые преимущества.

Другое преимущество рукописи: материализация мысли. Листок бумаги или ежедневник психологически меняют отношение к записанному. Особенно это относится к стратегическим целям.

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

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

Выбор технологий под проект

Фредерик Брукс в своём Мифическом человеко-месяце разбирает вопросы размера команды, выполняющей сложный проект. Один из важных выводов: добавление новых членов в команду может ухудшать общую производительность и отодвигать сроки проекта. Эффект проявляется сильнее если в проекте уже есть накопленный дефицит времени и ресурсов, а также на поздних стадиях проекта.

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

  1. Для небольшой инфраструктуры лучше избегать ресурсоёмких технологий, какими бы хорошими, модными и полезными они ни были
  2. Когда использовать технологию становится целесообразно обычно лучше её внедрять на новой отдельной инфраструктуре, а не вносить изменения в рабочую старую.

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

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

Нобелевка по химии 2024

Нобелевка прошедшего года гениальна! Это настоящая disruptive science.

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

Хассабис и Джампер пошли от обратного. Они верно допустили, что существующие в живых организмах белки не случайны и их геометрия определяет их биологическое значение, которое фактически получается как некоторая функция первичной структуры белка. А она закодирована в ДНК. Т.е. множество закодированных последовательностей в ДНК некоторым образом "классифицированы". И если рассматривать ДНК как язык натравить на него ИИ, можно "понять" его структуру, точнее найти куски белков со схожей геометрией. Геометрия некоторых белков (малой части) уже известно и из неё можно восстановить геометрию остальных.

Главная "разрывная" идея в использовании другого набора данных: ДНК. Очень неожиданный и неожиданно результативный подход.

Инфраструктура и образование

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

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

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

Показателен также пример Индии, Китая. Китай ещё 40 лет был на задворках мировой фабрикой и продавал дешевый труд. Но они вкладывались в образование, строили инфраструктуру. Сейчас по факту это первая экономика мира с высокомаржинальными продуктами, захватившими мир.

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

Зумеры и деньги

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

Попробуем решить задачу с конца. Представим молодого человека или девушку 20-30 лет из небогатой семьи и без наследства. Этот возраст самое время создавать семью. Для семьи нужно жилье. Возьмём по минималке: 43 квадратных метра, общая площадь типичной хрущевки-двушки. Цена такого жилья даже на окраинах в Москве порядка 300кр/м2, или порядка 13-15м рублей. Не нового, вторички, те же хрущёвки или 9-этажные старые панельки.

Теперь берем ипотечный калькулятор, вбиваем эту сумму и делаем срок 15 лет. Домкликовский калькулятор для 15 лет и суммы 13.5мр даёт первоначальный взнос 5.8мр, сумму кредита 7.7мр и ежемесячный платеж 164кр. Это без "льготной ипотеки", но для льготки и цены другие (первичка) и не для всех она. Рыночная стоимость честнее.

Допустим рассматриваемый молодой человек, потенциальный глава семейства, живет с родителями и не шикует, добавляем сюда еще затраты на еду, одежду и прочие неснижаемые расходы. Получаем сумму порядка 200кр. Это минимальный доход, при котором бизнес-проект "Молодая семья" выходит в 0. И это на 15 лет! Даже для двоих это минимум 100кр на человека на минималках. А если покупать не самую дешёвую еду, одежду? Добавить ещё медицину, образование и даже минимальные сбережения? Если добавить детей — сумма станет ещё выше. И да, молодым хочется жить отдельно от родителей, это ещё и недешевая аренда.

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

Можно на вопрос посмотреть и по другому, монетарно. В 2010 году цена грамма золота в рублях была примерно 1к, а сейчас порядка 8-9к рублей за грамм, т.е. рубль обесценился в 8-9 раз. Доллар, тоже обесценился, но меньше — примерно в 2.5 раза. Пересчитайте тогдашние доходы в современных рубли, а заодно и цену недвиги. Многих старпёров результат неприятно удивит. В нулевые и даже в 90-е годы недвига была доступнее, чем сейчас, даже при номинально меньших доходах.

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

Сломанный "рынок" труда

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

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

То же происходит и в "первом" мире, там процесс начался намного раньше и происходит медленно. За последние 30 лет реальная стоимость действительно ценных вещей и услуг (дом, образование, качественная медицина, хороший автомобиль) растёт, за это время оплата растёт только номинально и сильно не поспевает за ценными вещами.

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

Меняется и подход компаний. Становится нормой удалёнки и гибрида и с их стороны. Действительно многим компаниям не нужен работник на полный рабочий день и им приходится не "закрывать вакансии", а искать способы менее затратно решать возникающие проблемы. Есть надежда на ИИ, но он скорее изменит формат занятости, но не сам дефицит ресурсов.

Как исправить дефицит: снижать расходы государственного бюджета, снижать регулирование и распускать бюрократию. Как когда-то 45 лет назад делал старик Рейган. И существенно снижать уровень жизни бумеров. Пойдут ли на это демократии? Определённо нет, потребуются очень непопулярные среди стариков-избирателей реформы.

Тренды 2024-2025

Если коротко: Всё будет дорожать.

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

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

Зумеры с порога просят большие зарплаты, но им фактически и не оставили выбора. Если нет наследства и поддержки родственников — смысла соглашаться на работу за еду у них нет. Неявно здесь вылазит и ещё одна давняя проблема — демография. Нет жилья — рожать не будут. Достаточно большое поколение 80-х уже выходит из фертильного возраста, а поколение 90-х существенно меньше. Да и жить им негде, 80-кам в этом смысле повезло чуть больше.

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

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

Захватыать новые рынки и производить продукт с высокой добавленной стоимостью? Нужны инвестиции, их правовая защита и люди. Нет инвестиций — нет развития.

Нас ждут непростые времена.

Разработка ПО полвека назад

Так Фредерик Брукс описывает разработку и тестирование софта примерно полвека назад:

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

(…)

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

Люди работали круглосуточно, чтобы машины не простаивали. Еще 20-30 лет назад крупное ПО полностью компилировалось раз в сутки и код выкладывался на тестирование. Там же:

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

Смертный грех состоял в том, чтобы смело нажимать кнопку START, не разбив программу на тестовые секции с запланированными остановами.

(…)

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

Сейчас по ночам обычно спят, а инструменты всего цикла разработки ПО поменялись. У почти каждого разработчика в арсенале виртуальные машины, контейнеры и прочие докеры для экспериментов и не только. Тестировать и выкладывать даже большой код можно настолько часто, насколько это позволяет местный DevOps.

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

Преимущество электромобиля

В чём главное преимущество электромобиля? Экология? Нет. Его система управления.

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

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

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

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

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

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

Самым живучий транспорт сейчас это вероятно гибридный мобиль: с маломощным и лёгким ДВС и небольшой батареей (наверное не литиевой) для компенсации низкой мощности ДВС. Без массивных литиевых батарей и без сказок про "экологию".

Н. В. Гоголь

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

Николай Васильевич Гоголь, "Мёртвые души". 1842 год, почти 2 века прошло.

Послушать, век наш — век свободы

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

У них два веса, два мерила,
Двоякий взгляд, двоякий суд:
Себе даётся власть и сила,
Своих наверх, других под спуд.

У них на всё есть лозунг строгой
Под либеральным их клеймом:
Не смей идти своей дорогой,
Не смей ты жить своим умом.

Когда кого они прославят,
Пред тем — колена преклони.
Кого они опалой давят,
Того и ты за них лягни.

Свобода, правда, сахар сладкий,
Но от плантаторов беда;
Куда как тяжки их порядки
Рабам свободного труда!

Свобода — превращеньем роли —
На их условном языке
Есть отреченье личной воли,
Чтоб быть винтом в паровике;

Быть попугаем однозвучным,
Который, весь оторопев,
Твердит с усердием докучным
Ему насвистанный напев.

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

16 мая 1860
Пётр Вяземский


Александр II читал это стихотворение и оставил пометку "По-моему, много есть правды и весьма полезных намек".

Взлет и падение проекта FreeBSD

В далёких нулевых годах, когда я только начинал работать с серверными системами, мейнстримом было использование FreeBSD. Более половины серверов под *nix в то время было FreeBSD и другмими BSD. Линукс в качестве серверной системы тогда встречался редко и на него смотрели с опаской. Даже на десктопах линукс считался выбором гиков. Адепты BSD считали только её варианты настощим unix и достойной серверной системой и на "пингвинятников" часто смотрели с большим презрением.

Всё изменилось в последующие годы — доля BSD на серверах уже в 2010-е неуклонно падала и сейчас её почти и не осталось, а если встретишь, то под разные специфичные/legacy задачи. Молодое поколение не всегда и знает об это операционке, для них это архаика сродни MS DOS или OS/2.

Почему так получилось, что хорошая ОС уступила лидерство?

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

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

Отдельной историей был buildworld и buildkernel, т.е. обновление самого самого "мира" и ядра. "Пересборка мира" занимала огромное количество времени и в результате можно было получить нерабочую систему. Или рабочую систему, в которой что-то не работает из прикладного софта и требует "доработки напильником", причём это не всегда можно было определить сразу после пересборки, иногда проблема всплывала потом. Поскольку результат такого обновления в общем случаем не предсказуем, было разумно из RAID-зеркала (если такая возможность была) вынуть один из дисков в качестве бэкапа, обновиться и вернуть в случае успеха.

И так на каждом сервере! Если в небольших проектах такое можно было делать относительно безболезненно, то на больших проектах или high-availability процесс обновления представлял собой уже нетривиальную задачу. А если серверов не несколько штук, а хотя бы десятки — поддержка превращалалась в проблему.

Линуксы с их пакетными менеджерами и уже скомпилированными и протестированными(!) ядром, библиотеками и софтом имели огромное преимущество, их обновление происходило предсказуемо, а саму систему со всем софтом и окружением можно было несложно воспроизвести из пакетов.

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

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

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

Восхождение на Пик Ленина

Акклиматизация на семитысячник для человека, который не живёт в горах, занимает минимум 2 недели. Хорошая аккалиматизация из города — 3 недели. Большинство участников "из города" закладывает на всю экспедицию 3 недели, что достаточно мало. Один из вариантов лучше акклиматизироваться — начать это заранее: ходить на невысокие горы на 2-3 дня и ночевать тоже на высоте. И в целом проводить больше времени в горах.

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

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

Вид с Юхина

Это лагерь 3, высота примерно 6100м, вершина Раздельная

Лагерь на 6100 м
Вершина, 7134м
Спуск вниз

О старых конфигурациях 1С

У одного заказчика используется 1С:Торговля достаточно старой версии на такой же старой платформе 8.2. И то, и другое уже не поддерживается 1C, никакие обновления не ставятся. Хранение данных выполнено в MS SQL старой древней, который установлен на ещё более древнем Windows Server. Конфигурация Торговли была достаточно сильно дописана на заказ именно под бизнес-процессы заказчика. И вот эта вся связка работает уже более 5 лет. Надо сказать, прекрасно работает.

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

С момента внедрения конфигурации прошло уже более 10 лет. СУБД, ОС и серверы, на которых это всё работает, устарели и их отдельно даже смысла обновлять нет.

Что делать? Конструктивно ничего с этим не сделать. Только делать всё наново. И в конкретно этом случае в новом решении из качественно-быстро-дешёво даже 2 пунктов не набирается.

Что сделали: оставили как есть.

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

Сомневайся во всем, создавай правильное окружение

Биолог Джеймс Уотсон, один из первооткрывателей структуры ДНК в своей автобиографической книге описывает как это происходило.

Над структурой ДНК работали несколько групп, в том числе Лайнус Полинг с коллегами. Он предложил модель тройной спирали и поспешил об этом сообщить миру. Уотсон, когда узнал о модели Полинга, засомневался в её реалистичности, тройная спираль по химическим соображениям была неустойчива. Уотсон обратился к своим коллегам и те подтвердили его сомнения. Через очень непродолжительное время Уотсон, Крик и Морис предложили модель двойной спирали и опубликовали статью, за которое потом получили нобелевку.

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

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

Неподдерживаемый код

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

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

Код скомпилироан на старом продакшене, под старые версии библиотек. Операционная система тоже не обновляется и старые репозитарии уже не доступны, а ставить по частям новые библиотеки опасно — там ещё много другого кода с зависимостями на старое и можно их поломать. Получается, что старые библиотеки нормально не обновить.

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

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

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

Выводы:

  1. Избегать использования библиотек, поддержка которых вероятно скоро прекратится. Заранее это не всегда можно определить, но есть косвенные признаки.
  2. Писать код с продуманной архитектурой и интерфейсами, которые позволяют легко поменять хранилище (и не только его).
  3. Разделять задачу на разные уровни. Конкретно здесь хранение можно почти полностью реализовать на более низком уровне без существенного потери функционала.
  4. Использовать как можно более прозрачные и унифицированные инструменты.