Господин Архитектор

2021-03-18 11:42:35 Об git и не только

Я уже как-то писал, что недолюбливаю git. Разумеется, я не уникален в этом. Некто Ричард Хипп - вы его могли знать, он там одну небольшую малоизвестную любительскую БД написал - sqlite - однажды решил, что так жить нельзя, и написал свою scm - FOSSIL. Что в ней интересного:

1. Это scm для людей. Там всего один бинарник, и вся метаинформация транзакционно хранится - вы не поверите - в sqlite на дисочке.

2. Ничего не надо устанавливать в систему, достаточно drop-copy бинаря.

3. В систему встроен веб-сервер для GUI, а fossil достаточно умен, чтобы понять, что директория содержит markup-файлы, таким образом, к коду в этом же репозитории можно вести и просматривать документацию, и все это локально.

4. GIT все равно все используют как централизованную SCM с главным репозиторием, так что fossil по умолчанию так и работает: делаешь коммит, и оно тут же отправляется в главный remote. Это не очень подойдет для больших команд, но нормально для trunk-based development, а к тому же не плодит бессмысленные мерж-коммиты.

В общем, если хочется взять и начать работать локально, и бесит git, альтернативы есть. Открыть/Комментировать

2021-03-13 02:22:58 Об язык С

Существует некоторая легенда, что язык Си предназначен для системного программирования.

На самом деле, нет. Для системного программирования он оказался предназначен, потому что любое программирование в те годы было системным, кроме рассчетов баллистики на Фортране.

На самом деле, Си лучше всего подходит для подкрепления разработки Unix-way, просто об этом забыли. Так что на нем писать? Высокоэффективные портабельные одно-страничные и одно-файловые утилиты, которые соединяются друг с другом клеем в виде пайпов и скриптов. Для этого в Си есть:

1. Независимая (а не раздельная) компиляция, модуль = файл. Поэтому многофайловые проекты компилируются небыстро, т.к. по умолчанию надо оттранслировать все .h-файлы заново.

2. Отсутствие работы со строками. В системных утилитах строки нужны для работы с файлами, а на это уже есть posix api, больше ничего не нужно.

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

4. В юниксе все - это файл, в Си все - есть указатель. Хочешь мутабельную или иммутабельну ссылку? Держи указатель. Хочешь привязаться к адресу в памяти для ввода-вывода? be Держи указатель. Хочешь посчитать размеры? Держи адресную арифметику на указателях. А для коротких мелких утилит больше ничего и не надо.

5. Даже компиляция родным инструментом (gcc) идеально делается для однофайлового проекта, без всяких мейков: "gcc main.c", и все. Полученный a.out можно запускать.

В этом смысле Rust его никогда не вытеснит, потому что решает совсем другую проблему и не является конкурентом. Открыть/Комментировать

2021-03-05 11:59:27 Интересный казус с GPL v3 в российском правовом поле: в России признают только переведенные на русский документы, а GPL явно выражается, что изменения в нее, в том числе переводы на другой язык, ее нарушают.

Поэтому тем, кто выбрал этот путь, придется выпускать хитрый dual-licensed, который все равно будет нарушать GPL на территории России, но будет валиден в отношении нее на других территориях Открыть/Комментировать

2021-03-04 00:44:30 Потратил пару вечеров на то, чтобы разобраться со стянутыми из разных мест интернета библиотеками sensor fusion по алгоритму Махони, а он все не работает. Оказалось, что его реализации на гитхабах содержат мелкие ошибки, заботливо опенсорснутые авторами. Сегодня почитал оригинальные пейперы и методические рекомендации, сократил код в полтора раза, и все заработало. Опенсорс - сила! (нет) Открыть/Комментировать

2021-02-25 15:50:14 Картинка: сияние простоты МСА в Monzo, британском необанке Открыть/Комментировать

2021-02-25 15:50:01 Об микросервисы в который раз

Ну, хорошо, всем продали микросервисы: дескать, и устройство системы понятнее из-за них, и two pizza team вообще стандарт в Гугл ИТ, значит, и нам надо тоже. И код можно писать на самом подходящем языке: хочешь, пишешь на php, не хочешь, пишешь на nodejs, что очень удобно (особенно потом сопровождать комплекс, написанный на 10 языках). А еще можно переписать за две недели маленький микросервис, любой. Ну круто же, правда?! А еще архитектура очень отказоустойчивая, и если один сервис упал, то остальные выживут (на практике - не работает никогда). И самое главное - можно МАСШТАБИРОВАТЬ приложения! О том, что монолит тоже можно масштабировать, тем более сейчас, когда железо ничего не стоит, молчат.

Но это все selling points для недоверчивых технарей, а я расскажу, почему на самом деле бизнес выбирает микросервисы. Причин всего две:
1. Быстрая проверка гипотез, которые в 9 из 10 случаев проваливаются - да, продакт-менеджеры тоже не боги. В случае монолита вы стоите перед непростым выбором: или вкладываться по полной в эксперимент (дизайн, код, тесты), который, скорее всего, будет выброшен, или на коленке слепить то, что рискует выстрелить, и тогда с этим поделием придется жить вечно в монолите. Какой вариант хуже? Оба хуже. В случае с микросервисами эксперименты не сильно трогают ядро системы, которая кормит всю компанию и их семьи.
2. Найм. В ситуации, когда средней компании найти хорошего разработчика за праздник, в случае микросервисной архитектуры можно нанимать вообще любых программистов, которые подвернулись, а не те, которые подходят по стеку или согласны работать с легаси и т.п.

Эти две причины пересиливают все сложности, связанные с МСА. А сложностей немало, от оркестрации до смены парадигмы владения системами.

Все, больше на самом деле ни зачем не надо. А, еще маленькое замечание: проще нанимать людей, потому что "у нас такие же крутые технологии, как в Гугле, так что мы будем платить поменьше". Открыть/Комментировать

2021-02-03 14:58:39 Джентльмены, обращаюсь за советом.

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

С моей стороны есть требование только к полетному контроллеру - он должен быть конкретным по выбору, остальное уже по лучшим практикам рынка. Хотел бы получить его в сборе. Что можете посоветовать? Есть готовый kit?

Если кто-то сможет за деньги купить, собрать, и передать, готов пообсуждать условия в личке. Открыть/Комментировать

2021-02-01 17:16:01 Об дистанционную работу

Мы не нанимаем дистанционных сотрудников. Ну, таких, которые сидят дома или в коворкинге, и индивидуально работают на нас. У подхода есть и плюсы, и минусы, мы решили, что минусы перевешивают, пока мы можем нанять локальных. Хочу объяснить, почему.

1. Всеобщее стремление к удаленной работе похоже на карго-культ. Напомню, что в середине 90х, в 200х в условном Сиэттле программисты даже в крупных компаниях сидели в "кубиклах", исправно приезжали на работу, и вопросов к этому было немного. При этом компании вполне себе строили и нанимали удаленные ресурсные центры из условного Бангалора. Потом все поменялось. Почему? Очень просто. Стартапы в Долине обнаружили, что местные разработчики кончились, ездить по два часа никто не хочет, платить за дорогую аренду нужно и за офис, и за жилье сотрудникам опосредованно. И тут зажглась звезда "удаленки". Но мы не стартап в Долине, мы не хотим бежать вслепую с чужой повесткой.

2. Кажется, что удаленка сильно расширяет возможность нанять хорошего сотрудника, и это плюс. Но этот плюс надо помножить также на минусы. Минус номер 1: если при офисной работе вы конкурировали за сотрудника в плюс-минус окрестности офиса, то теперь вам надо конкурировать с гораздо большим числом компаний, которые тоже нанимаю удаленно. Это круто разным Амазонам и Одноклассникам, но совсем не круто для небольших компаний. Минус номер 2: людей стало больше, но от этого они не стали автоматически уметь работать удаленно. Да, представьте себе, работать на удаленке тоже надо уметь, от одного желания такое умение у работника не появляется.

(83% удалённых сотрудников обманывают коллег и руководителей по поводу работы)
https://incrussia.ru/news/obmanyvayut-kolleg/

(Треть сотрудников IT-компаний признались, что работают 3–4 часа в день)
https://incrussia.ru/news/working-only-3-4-hours-a-day/

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

Мы поразмыслили над всем этим, и пришли к такому варианту:
- нанимаем в офис в городе
- обеспечиваем режим 3/2 или 2/3 "офис"/"дом".
Можно ли лучше? Можно. Но вряд ли за счет перевода на удаленку. Открыть/Комментировать

2021-01-27 20:06:35 Без темы

Видели в интернете одно время было популярно забавное увлечение: додумывать пословицы, как они были "на самом деле"? При этом смысл менялся.

Например: "кто старое помянет, тому глаз вон -- а кто забудет, тому оба".
Или: "рыбак рыбака видит издалека -- и стороной обойдет".

Как минимум, это было интересное, нестандартное упражнение. Часто такое упражнение проделываете?

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

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

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

Или вот еще: чувак, я слышал, ты в школе арифметику учил? А ну, посчитай пример с канала "Хулиномики": "Илон Маск внёс на брокерский счёт 5000 долларов. Он купил 300 акций Теслы по $30 за штуку. Минимальная маржа у брокера - 30%. Не учитывая комиссий и процентов по займу, при какой цене акций он получит маржин-колл?". На ответ дается три-четыре минуты.

Не могу в уме посчитать, сколько банку должен буду, если занял Х, а возвращать буду так-то и так-то? Так я, выходит, не арифметику учил, я опять неправильными визуализациями страдал, дурачок. Зачем мне интегралы, если меня примеры из жизни в тупик ставят?

И так во многом. Открыть/Комментировать

2021-01-25 13:28:13 Об документацию

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

Комплект из "Инструкции по сборке" и "Руководства пользователя" закрывал вообще 80%+ процентов вопросов по всем темам, от функциональности до внутреннего устройства.

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

А вы думали, большим компаниям сильно надо, чтобы у вас получалось? Открыть/Комментировать