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

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

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

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

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

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

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

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

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

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

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

Тренды 2024-2025

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отключение обновлений Windows 10

Беда современных ОС от MS в том, что они считают себя умнее пользователя и обновляются когда это совсем не вовремя. И дело не только в том, что обновления не всегда полезны, а прежде всего это прерывает рабочий процесс. Оставил ПК на ночь с запущенными задачами, а он за ночь взял и сам перезагрузился. И на утро НИЧЕГО не осталось.

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

Идём более длинным путём. Качаем PsExec, распаковываем и запускаем через cmd с правами администратора. Далее запускаем Планировщик:

psexec -i -s "C:\Windows\system32\mmc.exe" "C:\Windows\system32\taskschd.msc" /s

Далее отключаем неугодные задания из Microsoft\Windows\UpdateOrchestrator.

Всё. С внезапными обновлениями и перезагрузками покончено.

Запуск nodejs через systemd

Приложения nodejs собираются обычно на коленке и для них нет стандартного способа запуска как демон. Наиболее короткий и корректный способ сделать это сейчас — через systemd. Для этого создаем свежий конфиг в /etc/systemd/system/, называем по имени приложения, например /etc/systemd/system/myapp.service с содержимым:

[Service]
WorkingDirectory=/opt/myapp/
ExecStart=/usr/bin/node /opt/myapp/app.js
Restart=always
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=myapp
User=igogoo
Group=igogoo
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Обычно в /etc кладутся не сами конфиги, а симлинки на действительные конфиги в /lib/systemd/system/, но поскольку наш демон кастомный, а директория /etc бэкапится полностью, создадим его прямо здесь.
Далее релодим конфигурацию и включаем демона на автостарт

systemctl daemon-reload
systemctl enable node-app.service

Теперь возможны стандартные операции вроде

systemctl start myapp
systemctl stop myapp
systemctl restart myapp
systemctl status node-app.service

Перезапускаем виртуалку, проверяем, что всё работает. Готово.

Исправление графиков munin

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

Графики munin хранит в rrd-формате в /var/lib/munin. Чтобы исправить заходим туда и конвертируем rrd в xml:

cd /var/lib/munin/localdomain
cp x.xml x.xml.bak
rrdtool dump x.rrd > x.xml

Открываем получившийся xml, удаляем оттуда ненужное и конвертируем обратно:

rrdtool restore x.xml > x.rrd

Обновление с небезопасного репозитария

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

Отмычка такая. Добавляем кастомный конфиг /etc/apt/apt.conf.d/99custom такого содержания:

Acquire::Check-Valid-Until "false";
Acquire::AllowInsecureRepositories "true";
Acquire::AllowDowngradeToInsecureRepositories "true";

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

Дебиановские установочные образы non-free firmware

Иногда возникает необходимость скачать несвежий устанвщик дебиана с версией несвободных пакетов. Свежий постоянно располагается по ссылке:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/amd64/iso-cd/

А "несвежий" можно загрузить по ссылке из из архива:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/archive/

Изменение PATH в Debian buster

В дистрибутиве Buster зачем-то подчистили переменную PATH от важных и полезных путей, в частности /usr/sbin. В итоге полезные и весьма нередко используемые команды вроде dpkg-reconfigure, fdisk, blkid и многие другие стали недоступны без указания точного пути. Интерпретатор пишет command not found и усё на этом.

Возвращаем к обратному добавлением в .bashrc:

export PATH=$PATH:/usr/sbin

После следующего логина всё работает

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

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

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

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

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

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

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

Выводы:

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

SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol

В новом дебиане при попытке законнектиться к очень старым сайтам из питона (и не только) периодически вылезает ошибка "SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol". Вылезает она из-за отсутствия поддержки более-менее современных протоколов серверами с теми сайтами. Работать с этими сайтами надо, а повлиять никак, поэтому единственный доступный выход — это обойти ограничение. На глобальном уровне это делается правкой секции в /etc/ssl/openssl.cnf:

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=1

на

[system_default_sect]
MinProtocol = None
CipherString = DEFAULT

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

Обновление с репозитария без подписи

Начиная примерно с дистрибутива buster стандартный установщик дебиана apt-get требует подписи всех используемых репозитариев. Обычный способ использования репозитария — добавление его подписи в систему. Это, однако, не всегда удобно и целесообразно. Иногда нужно что-то взять из сторонних репозитариев не добавляя подписи в систему. Это можно сделать разово при обновлении с помощью опции

apt-get update --allow-unauthenticated

Намного удобнее сделать это навсегда в отдельном списке репозитариев по типу:

deb [arch=amd64 allow-insecure=yes] http://www.deb-something-exampe.org buster main

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

UPD: Обновленный и более хороший способ

rsync на нестандартном порту с докачкой

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

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

Вторая часть — заставить rsync подключаться на другой порт. Прямой опции, кторая позволяет так делать нет, но можно указать опцию для ssh, через ключ "-e".

В итоге получается команда вроде

rsync -av --append-verify -e "ssh -p 55667" backup-srv:/data/backup/ /data/backup-srv

Обновления security для Debian

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

На практике это работает следующим образом. Обычно security-ветки уже есть в /etc/apt/sources.list. Мы на основе его создадим отдельный файл, в который поместим только ветки безопасности:

cd /etc/apt
cp sources.list sources.list.d/security.list

Далее из первого файла удалим security-источники, а во втором только их и оставим. Если в исходном файле нет security-источников совсем, тогда просто добавляем их в новый файл /etc/apt/sources.list.d/security.list. Нужны будут security-ветки для нужных репозитариев, обычно это stable.

Далее можно обновлять пакеты или все или из только из списка безопасности. В последнем случае это делается так:

apt-get update
apt-get upgrade -o Dir::Etc::SourceList=/etc/apt/conf.d/security.list

Таким образом можно своевременно фиксить критичные уязвимости, но при этом не рисковать обновлением всего ПО.

md127

После изменения конфигурации софтового рейда, mdadm-устройств некоторые из них именуются странным образом вроде md127. Это уже с изменённым /etc/mdadm/mdadm.conf.

Решается генерацией initramfs заново:

sudo update-initramfs -u

При следующей загрузке устройства именуются как надо.

Вход в BIOS на ноутбуках HP серий 250/260 G*

Последние ноубуки с UEFI BIOS имеют нетривиальный вход в собственно настройки биоса. Каждый производитель придумывает свой хитрый способ. В такие моменты с теплотой вспоминаешь старые компьютеры, на которых вход был унифицированный с помощью Del.

На днях разбирался с Hewlett Packard HP 260 G2. Он имеет UEFI BIOS, зайти в который ещё надо знать как. Нашёл этот способ и чтобы не забыть сохраню.

Как попасть в BIOS. Сразу после включения Power нажимаем (и отпускаем) ESC, а после быстро F10, которую лучше держать.
Ка попасть в меню загрузки (Boot Order). Аналогично нажимаем ESC, а затем F9.

Управление supervisorctl без рутовых прав

Для разных самописных процессов, которые нужно запускать как демон, есть прекрасный инструмент supervisor. Управление запуском процесса в нём происходит с помощью конфигов предельно простого синтаксиса (и в тоже время покрывающих почти все необходимости) в /etc/supervisor.d/ и команд наподобие:

supervisorctl start myapp
supervisorctl stop myapp
supervisorctl restart myapp

т.е. интерфейс полностью аналогичный управлению демонами в ОС.

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

sudo supervisorctl restart myapp

Но если это виртуальная машина, в которой supervisor нужен именно для приложений от этого пользователя, то можно сделать и в обход root совсем. Для этого необходимо поправить в /etc/supervisor/supervisord.conf:

[unix_http_server]
file=/var/run/supervisor.sock
chmod=0770
chown=someuser:someuser

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