С приходом нейросетей теперь можно решать задачи гораздо проще, правда и задачи бы такой не стояло не будь нейросетей и llama.cpp, и huggingface. В общем смысл статьи в том чтобы попытаться математически вычислить теоретическую скорость генерации токенов в программе llama.cpp для моделей на hugginface, просто открыв карточку модели и нажав на закладку (букмарклет).

В интеренете таких калькуляторв довольно много, и в этом калькуляторе нет никаких новых идей, он работает как и все остальные - вычисляет скорость исходя из пропускной способности видеопамяти пользователя. Но как выяснилось просто поделить одно число на другое (вес модели на пропускную способность видеокарты) не совсем правильно, когда я сказал что в реале у меня другая скорость, нейронки стали вводить поправочные коэффициент в виде эффективности видеокарты (60-80%).

Я тут решил решил чуток заморочиться и протестировать локальные MOE модели на кодинг. Кодинг громко сказано - мои задачи исключительно игры причем на html, css, js. Но зато с таким набором можно сразу в продакшен, легко проверить без компиляций, кроссплатформенность ну и другие известные плюсы и минусы. На тесте побывало 10 моделей: Qwen 3.6 (MTP), KAT Coder V2.5, Gemma 4, Aurora-Code-1, Frontis, GLM 4.7 Flash, Ornith 1.0, Salience 1.5 Pro, Agents A1, GPT-oss 20b. Ссылки на модели есть в таблице результатов на которую ниже будет тоже ссылка. Многие из этих моделей сделаны на базе Qwen и тем интереснее было тестировать, потому что по бенчмаркам в карточках моделей на HF они часто превосходят своего учителя. Правда я сразу был настроен скептически и понимал что вряд ли они смогут составить реальную конкуренцию - хоть и дообучаются на кодинг, но такого рода тесты не очень как будто бы проходят, что собственно и подтверждает итоговая таблица с результатами (подсчитывал результаты Qwen3.8-Max):

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

Чаще всего в SCADA системах используются платные лицензии, в которых прописано ограниченное количество тегов, с которыми можно работать - если хочешь больше тегов (чтобы получать больше сигналов из PLC), то нужно больше платить. Естественно может появиться желание немного сэкономить и выйти из положения ограничившись меньшим количеством тегов, для этого придется немного схитрить, о чем я и хотел бы написать.

Самый простой вариант, который я тоже применял в наших проектах, это использовать вместо дискретных тегов аналоговые - 16 дискретных сигналов можно заменить на одно слово. А вот из слова достать нужный бит средствами самой СКАДА - это уже довольно простая задача. На Intouch, например, при программировании реакция на нажатие кнопки, скрипт который обнуляет 4 бит может выглядеть вот так:

Несколько дней назад, чтобы доказать что в интернете кто‑то не прав, мне пришлось «считать пиксели», чтобы оценить соотношение размеров двух предметов на фото. Тогда еще я не сообразил сразу, что можно было просто загуглить что‑нибудь вроде «Pixel ruler» и получить размер предметов в пикселях, из которого легко можно получить соотношение. Я же взял подручный MS Paint, вырезал один предмет и уместил его несколько раз внутри другого предмета, сразу узнав во сколько раз один больше другого. Но мне вдруг стало интересно немного автоматизировать этот процесс и решил написать пиксельную рулетку сам, такую что вводишь заранее уже известный тебе размер некоторого предмета, указываешь его на фото в виде линии, и потом уже другие линии автоматом пересчитываются по отношению к этому размеру. Получилось что‑то в этом роде:

У нас на производстве уже несколько лет работает "самодельная" система контроля за простоями на производстве, реализованная на базе MS SQL, SQL Server Reporting Services и IIS. Поскольку эта система довольно старая и не очень хорошо приспособлена для современных браузеров, мне захотелось попробовать ради эксперимента сделать что-то похожее на базе SQlite, c# и javascript.

Недавно на работе столкнулись с интересной ситуацией, о которой захотелось написать тут, потому что случай довольно интересный, хотя как и оказалось простой. На одном из агрегатов, управляемым контроллером от Allen Bradley Compact Logix L33ER, в контроллере постоянно сыпались предупреждения, а точнее даже минорный ошибки (Minor Faults) - которые на функциональность никак не влияют, но раздражают своим присутствием. В секунду по нескольку десятков таких ошибок без перерыва: Type 04 Program fault (Code 04) Arithmetic overflow. Result of an arithmetic instruction out of range, что переводится примерно как "Арифметическое переполнение. Результат арифметической инструкции вышел за предел."

Речь идет о обычной "Змейке", написанной на C# и запускаемая в консоли. Во время игры рядом с "едой" после того как нажмешь кнопку управления змейкой, появлялся символ "а", которого в исходном коде просто не могло быть, поэтому мне и захотелось разобраться почему так происходит и как это можно починить:

Статья больше не о том как это сделать, а о предложении к усовершенствованию UI/UX, потому как делается обнуление довольно просто: в своем профиле жмешь на кнопку Whois (это оказывается кнопка) и в выпадающем списке выбираешь "Обнуление кармы". Обнуление происходит не сразу, а только через сутки (не совсем понимаю для чего) и воспользоваться им можно только один раз.

Я работаю инженером АСУТП в одном из цехов металлургического производства. В цеху есть 3 довольно объемных агрегата и несколько небольших локальных систем, и естественно все они состоят из кучи механизмов, ПЛК, датчиков, клапанов, моторов и т.п. В нашей службе мы частично внедрили некоторые методы системы ТОИР (Техническое обслуживание и ремонт), а именно промаркировали все свое оборудование, внесли его в единообразный каталог и после планового ремонта стараемся делать обходы, согласно заранее подготовленных чек-листов. Раньше все было довольно печально: чек-листы страниц на 20-30 распечатывались, подшивались, и приходилось ходить по агрегату с ручкой в одной руке и кипой бумаги в другой, которая так и норовит где-нибудь рассыпаться. А еще иногда приходится лазить среди грязи и пыли, или взбираться на неудобные площадки. Мало того, после обхода желательно как-то обработать результат, и сохранить его на будущее: потому кучи заляпанных бумаг после каждого обхода постоянно валялось где попало и не было от нее никакой пользы. С этим непотребством хотелось что-то сделать и потому пришла идея сделать электронный чек-лист на планшете.

Backend