Я делаю то, что мне интересно. Пишу программы, которые нужны только мне, потому что мне не нравится зависеть от чужих решений, модных фреймворков и очередной индусской магии, которая ломается в самый неподходящий момент. Мне важно, чтобы всё работало ровно так, как я задумал, а не так, как "принято".
Кроме софта я веду оперативный журнал - записываю мысли, наблюдения и разборы, которые никому не нужны, но помогают мне самому не забывать, что я делал и зачем. Это не блог, не попытка кому‑то понравиться и не попытка собрать аудиторию. Это просто мой уголок, где я делаю всё так, как мне удобно, и если кому‑то это не нравится - он идёт нахуй.
Или нет.
Мне можно написать в Gadu-Gadu 16276712
Выложена реализация под Java 6, гарантирующая широкую совместимость от Mac OS X Snow Leopard через Solaris 11.3 вверх до практически любой ОС. У меня есть другая реализация этих же решений на Си, которой я пользуюсь. Но она строго секретна.
Рядом обычно лежит скрипт-помошник (sh), который нужен только для старых ОС и для людей, которые без сознания. Нормальные люди возьмут jar с которым и сами знают что и как нужно делать.
builder - это маленькая утилита, которая следит за файлами и автоматически запускает команды построения и выполнения, когда что‑то меняется. Нужна для организации простого и быстрого цикла разработки. Задача разработчика - сохранить изменения, остальное сделает builder - заметит, перестроит, перезапустит. Перестройка может включать в себя тестирование, а перезапуск - деплой на пром.
Работает так: ты указываешь команду сборки, команду запуска и список файлов. Если любой из этих файлов изменился - builder сначала выполняет сборку, а если она прошла нормально, запускает программу. Если программа уже работает, builder её гасит и запускает заново. Весь вывод, включая дочерний, аккуратно складывается в терминал.
Все примеры ниже используют помощник builder.sh, который просто вызывает JAR с нужными параметрами. Это избавляет от длинных команд и гарантирует правильную кодировку.
Минимальный пример:
./builder.sh "make" "./run.sh" src/Main.java src/Utils.java
Если список файлов не указан, builder читает их из стандартного ввода:
find . | grep .java | ./builder.sh "make" "./run.sh"
Если команда сборки пустая, builder просто перезапускает программу при изменениях:
./builder.sh "" "./run.sh" src/*
Если команда запуска пустая, builder только собирает:
./builder.sh "make" "" src/*
Работает на Windows и Unix‑системах. Вывод процессов builder не жрёт - он аккуратно пересылает stdout и stderr дочерних процессов в твой терминал, без плясок и без потерь.
kicker - это утилита для запуска дочерних команд и объединения предсказуемым образом (построчно) их вывода. Может быть использована как самостоятельно (например для организации "устойчивой" работы глючного приложения), так и как модуль в других программах (для распределения нагрузки в дочерних процессах). Есть несколько режимов работы.
Далее в разделе загрузок есть Kicker.pm, который суть модуль использования kicker в Perl. С помощью этого модуля можно распилить большую задачу на подзадачи, обработать подзадачи отдельно используя все ядра ОС, объединить и обработать результаты. И при необходимости для обработки подзадач использовать средства, написанные на других языках программирования, не обязательно на Perl.
Далее примеры работы как утилиты. Все примеры используют помощник kicker.sh, который вызывает JAR с правильной кодировкой.
Выполнить команды по очереди:
./kicker.sh process "ls -l" "uname -a" "date"
Выполнить команды параллельно на 4 ядрах:
./kicker.sh jam_4 "ls -l" "uname -a" "date"
Бесконечно перезапускать команду, если она завершается слишком быстро:
./kicker.sh launch "ping 127.0.0.1"
То же самое, но на всех ядрах:
./kicker.sh work "ping 127.0.0.1"
Вывод вегда аккуратно собран, строки не перемешиваются, stderr и stdout идут туда, куда должны.
updater - это утилита доставки обновлений. Может быть запущена как клиент и как сервер. Сервер - источник истины, файлы на нём эталон. Обновление - один вызов сервера.
Работает через RMI, сравнивает контрольные суммы и передаёт только те файлы, которые реально изменились. Просто нормальный механизм обновления, который делает ровно то, что ему сказано.
Логика простая: клиент сканирует каталог, считает MD5 всех файлов и отправляет их серверу. Сервер считает свои MD5 и возвращает только те файлы, которые отличаются. Клиент сохраняет изменения. Всё. Никаких "патчей", никаких "дельт", никаких "умных алгоритмов" - только честная передача байтов.
Легко используется для обновления из единого файлового склада нескольких систем (пока нет пересечений по названиям файлов) - сервер не отдаст клиенту файлов, которых изначально на клиенте нет.
Сервер работает вечно, пока его не убьют. Клиент работает один раз: сравнил, получил, сохранил, ушёл.
Все примеры используют помощник updater.sh, который вызывает JAR с правильной кодировкой.
Запустить сервер:
./updater.sh server://localhost:1099
Запустить клиент и получить обновления:
./updater.sh client://localhost:1099
Сканирование идёт рекурсивно, глубина до 16 уровней. Передаются только изменённые файлы. Если сервер и клиент одинаковы - обновлений нет. Если что‑то поменялось - клиент получает байты и сохраняет их как есть.
nex - это утилита для прямой передачи файлов и каталогов между двумя машинами через сеть "со страшной силой". Никаких архивов, никаких протоколов уровня "умной синхронизации". Просто честная передача байтов: отправил - получил. Всё.
Ну то есть понятно, что можно "через флешку". Можно и через американское облако. Те, кто решает задачу на таком уровне, добро пожаловать нахуй отсюда подальше деливерить и дискаверить эндтуэнд. Тем, кто пока остался. Можно через шару, но это надо делать шару, и это 2 операции. Можно через tar cvf - . | nc 192.168.0.1 9999, но tar и nc есть не везде. Также и с scp. А вот nex быстро принести и быстро попользоваться на любой ОС, имея прямое Ethernet подключение на хотя бы гигабит перекатать любую файлопомойку с одной машины на другую ничего не настраивая и со страшной силой.
Работает в двух режимах: send и receive. В режиме send nex проходит по файлам и каталогам, отправляет структуру, размеры, блоки данных и контрольную сумму. В режиме receive он принимает пакеты, создаёт каталоги, пишет файлы и проверяет CRC. Если что‑то не совпало - ошибка. Если всё совпало - готово.
Передача идёт блоками по 64 КБ. Каталоги создаются по мере входящих пакетов. Символические ссылки игнорируются. Запрещённые имена (типа .DS_Store, Spotlight, Trashes и прочая системная хуета) фильтруются.
Все примеры используют помощник nex.sh, который вызывает JAR с правильной кодировкой.
Отправить файлы на удалённую машину:
./nex.sh 192.168.1.10:9000 send file1.txt dir2 image.png
Принять файлы на локальной машине:
./nex.sh 9000 receive
Если хост не указан - nex работает как сервер и ждёт вхоящее подключение. Если указан - подключается как клиент. Режим соединения и режим получения/отправки не связаны. Соединение может быть установлено в одну сторону, а файлы при этом передаваться в другую.
Контрольная сумма - простая байтовая сумма. Если файл повреждён - nex орёт и не принимает. Если всё нормально - файл записан. Каталоги создаются автоматически. Блоки пишутся строго в том порядке, в котором пришли.
В 90-е Microsoft изобрело OLE. Благодаря чему можно было вставить "объект" в "документ". Можно было вставить таблицу Excel в Word. Туда же поместить звук, программу, видео и пр. Находились уникумы, которые держали вообще всё в одном большом документе Word, им так было удобно. Наверное тогда же стоило придумать понятие "as a Word". Теперь все конечно вспоминают такое со стыдом. Сейчас у нас всё по-другому. Сейчас всё "as a Code".
Ресурсы любых видов (кадры, доступ к материалам, технологии, в том числе организации процессов) для любой компании залог успеха в конкуренции. У всех компаний свои сильные стороны - у кого-то карьер с силиконом ближе, у кого-то инженеры туже знают, как делать дела. Никто в здравом уме не будет делиться тем, что у него обеспечивает превосходство, ибо конкурент, поимев чужие преимущества и добавив их к своим, получит перевес и выдавит этого делящегося из существования. Почему мы собираемся на "конференции" с прямыми конкурентами и рассказываем им как делать дела? Почему мы ходим к ним на подкасты, где раскрываем наши секреты? Мы отдаём (наверное безвозмездно) наш ресурс. Или то, о чём мы там рассказываем - это дезинформация, чтобы их утопить, и всё хитрый обман? Может быть и Google, со своей книжкой "делай как во мне", написал её с аналогичными целями, чтобы утопить нас? Может быть не стоит применять слепо всё что там не подумав собственной головой на собственном языке?
Было дело, я хотел написать книгу. Называть "Религия Бабилюдизма: Бабушкизм-Старыизм".
Супруга предложила основать церковь. И сразу одновременно противостоящее течение реформации, чтобы как у нормальных людей. Чтобы каждый мог присоединиться либо к ортодоксам, либо к протестантам.
Сейчас пока пишу начал думать на эту тему. Приходят на ум важные темы, такие как Трон Старости, необходимая и достаточная Ветвистость Шапки, Достойность, Такое Неуважение и Такая Нелюбовь, вещах которые должен мущиный (такое произношение слова "мужчина"), пропаганда алкоголя и агитация за брак через запреты, Женский Профсоюз, Дао (и воспитание) мальчиков с последующим отъёмом имущества, доброго имени и жизни в пользу женщиный (такое произношение слова "женщина" с нахрапом), практика будничего ежедневного Царствования и снисходительного помыкания родственниками, практика передачи важной информации в танце, Колхозная Магия, собака - Саша Васильев, Ор, Ор о том что она не орёт, отсутствие хоть какого-то занятия и нахождение на пенсии десятилетиями и одновременное нытьё по поводу вот-вот наступящей смерти. Это то, что только сразу на ум пришло.
Я инженер и этим горжусь. Люблю программировать. Применяю вместе C, Perl, Java. Создаю собственные инструменты, повышающие эффективность моего труда. Консервативен. Рассматриваю модное с точки зрения эффективности, не реагируя на хайп. Не терплю идиотов. Ненавижу "грумление комунды" и "челенджинг вординга эпиков". Обладаю широким кругозором. Имею также музыкальное и лингвистическое образование. Готов учить новое. Готов работать не только умственно, но и физически. Главное для меня - быть полезным. Предочитаю простые решения сложным, так как они более надёжны. Считаю, что надо работать головой, а не 8 часов. Хочу видеть вокруг профессионалов, у которых буду учиться, которые будут лучше меня.
"Микросервис проверки числа на чётность" - это же чистая тупь с точки зрения всего. Грумящие комунду синеволосые на полном серьезе до такого докатились или это все-таки прикол?
Вот недавно я видел статью BlueSky (это такой новый твиттер), где рассказывалось, что каждый новый твит знаменитости - это миллионы инсертов в БД (по таблице на фолловера), и как у них для этого кластер серверов, Кавки, и бог знает что еще. Всё описано с гордостью. Это тоже прикол?
Я не хочу понимать "вентиляторные" записи и чтения. Как по мне твиттер - это три таблицы. Юзеры, Твиты и Фолловеры. Один твит - один инсерт в твиты. Чтение ленты - один селект. Селекты не тяжелые. Если даже нафантазировать, что твиты для персоны - отдельная таблица, то что тогда. Вот я отписался от кого-то - тысяча делейтов? А вот подписался - тысяча инсертов? Чистая, дистилированная тупь. Которая потом героически решает проблему, которую сама же создала. И настолько тупая, что хвастается.
Задача тривиальная. Если селект работает медленно, можно индекс накатить. Можно базу на рамдиск положить. На крайняк можно сделать распределенный кластер на чтение. Скорее сетка ляжет. Но нет ни одной причины усложнять структуру БД и делать миллион инсертов.
Почему сейчас и дальше больше распространяется и внедряется Python.
Это отчётливо плохо спроектированный язык, подверженный сложно вылавливаемым багам ввиду опечаток, которые ввиду этого должны быть нивелированы сторонними инструментами - умными IDE, линтерами, нейросетями - и без которых (а также без сопутствующих периодических инвестиций в разные смешные заграничные организации) он сложноиспользуем.
В современной информационной среде много передач про экономику. Что заметил. У экономистов когда чего-то стало меньше, они используют такие слова как "замедлилось", "охладилось", "сжалось", "ослабло", "упало", "сократилось". А когда больше - "ускорилось", "нагрелось", "расширилось", "ужесточилось", "выросло". Как они выбирают, какое именно слово из списка использовать? И зачем им такой богатый список синонимов там, где можно было бы просто сказать "меньше" и "больше"?
Ставка кредита стала меньше - понятно. Ставка кредита намокла - звучит странно. Даже если ставка кредита это что-то что не цифра, и чтобы подчеркнуть ее нецифирность прибегают к метафоре намокания жидкостью, которая олицетворяет в свою очередь среду, из которой что-то вышло на сушу. Передают информацию в танце.
В технике так. Если у тебя есть трёхфазный фидер на подстанции, то его состояние описывается однозначно набором измерений - ток, напряжение, активная/реактивная мощность и сигналов - состояние выключателя, заземляющих ножей, разъединителей по фазам. Каждое ТИ это цифра с плавающей точкой и каждый ТС это 1 бит информации. При этом, фидер никогда не ужесточается, не замедляется и не тормозит. Есть цифры (как текущее состояние), есть скорость этих цифр (как первая производная), есть ускорение (как вторая производная) - и эти величины тоже не намокают, не делаются более скользкими и не засахариваются. Почему в экономике по-другому?
Использование такого разнообразного вокабуляра наводит меня на мысль, что пытаются завести рака за камень. Денежный агрегат М6.3 высох и облупился.