О том что Huawei обнародует собственный язык программирования новости ходили уже давно. Ещё в прошлом году при поиске работы мне уже предлагали работать с этим языком - правда "не сейчас а вот-вот вскоре" :) На тот момент компилятор и прочие инструменты ещё не были в открытом доступе. Сейчас же страница скачивания - вот она - под Linux, Windows и Darwin (да ещё и плагин к VSCode)!

В этой статье - беглый обзор. Я попробовал скачать-запустить и, пройдясь по разделам документации, описал основные фичи - так что вы можете сэкономить себе время и за 5-10 минут составить представление о Cangjie. Сразу скажу - чего-то оригинального, инновационного - я не заметил. Нет такого, чтобы как с Haskell, Erlang или Rust на первых порах пришлось ломать голову. Для программистов на Java, Go, C++ много будет довольно привычных вещей (можно сказать - "обокрали" эти языки тут и там понемногу).

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

Есть нюанс с примерами - Habr естественно не поддерживает подсветку синтаксиса для Cangjie (пока) - а для наглядности это желательно. Пожалуй буду вставлят картинками, за что заранее прошу извинения.

В комментариях обратили внимание на статью от 2022 года, где специалисты компании Meanotek взялись специально натренировать GPT-2 «весьма прилично играть в шахматы». К счастью они оставили демо‑страничку где можно поиграть против их модели — то есть, потестировать результат вместо чтения длинной статьи (о чем пару слов тоже скажем).

Ну я и потестировал, получил интересные результаты, но в отличие от профессора Выбегалло с удовольствием сейчас их вам расскажу — будут представлены 3 тестовых игры, буквально в несколько ходов каждая — по крайней мере в первой модель держится неплохо... до поры :)

Поскольку LLM (все эти ChatGPT, DeepSeek и т.п.) это языковые модели, которые по идее просто складывают ответ из кусочков фраз, как в калейдоскопе - мы не ожидаем от них чудес логики. Тем больше они нас удивляют пытаясь генерировать ответы на достаточно мудрёные задачи - от генерации и исправления программного кода до, например, игры в шахматы.

Идея с игрой в шахматы хороша тем что на ней легко продемонстрировать и неспециалисту как возможности так и ограничения LLM. Эксперименты на эту тему появились уже давно, например в статье на Хабре же от 2023 года. Там автор на 6м ходу сделал неправильный ход но LLM этого не заметила. Мы кратенько посмотрим есть ли прогресс в этом направлении, попробуем немного изменить подход и потестируем ещё пару игр.

(сразу скажу - несмотря на прошедшие два года и явно принятые разработчиками усилия добиться адекватности мне почти не удалось)

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

Собственно программатор — голый Arduino с прошивкой, разбирающей HEX‑файл построчно и реализующий программирование целевого чипа по SPI. Прошивка и инструкции сложены в репозитории на гитхабе: At89s‑prog.

Конкретные чипы (At89s...) здесь скорее для примера. Мы не будем воспевать достоинства 8051-й архитектуры (конечно, они архаичны но у них есть плюсы, благодаря которым они до сих пор сохраняют популярность). У меня в какой‑то момент оказалась их горстка а программатора под рукой не нашлось. Они (те что с индексом S) программируются через SPI, а не стандартным «многоногим» интерфейсом что делает удобным их применение в любительских поделках.

Что такое "отрицательное сопротивление"? Под этот термин подходят различные явления и устройства - но нам годятся далеко не все. Данная статья содержит пояснения по теории к статье про Гармонический Осциллятор с Отрицательным Сопротивлением. Её можно читать отдельно или только заглядывать сюда по ходу чтения основной статьи, для справки.

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

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

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

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

Поэтому мы обсудим альтернативу - с использованием "отрицательного сопротивления" - подключая к нему LC-контур прямо в том виде в каком он нарисован в учебнике, мы сразу получаем рабочий осциллятор и с широчайшим диапазоном по частоте!

Мы проверим эту идею на практике! Подключим LC-контур к двум типам схем с отрицательным сопротивлением - сперва к "лямбда-диоду" (на транзисторах), а потом к "транзитрону" (на электронной трехсеточной лампе - пентоде).

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

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

Многих останавливает кажущаяся сложность таких экспериментов - хотя сами лампы можно купить рублей по 50 за штуку, трансформатор для питания достанется уже несколько сложнее и дороже. Да и анодное питание под 300 Вольт - а ну как дёрнет?

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

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

Возьмём очень простую задачу - скомпилировать код. Для наиболее однозначного соответствия я беру код на ассемблере - и хочу получить HEX-файл. Это задача которую можно выполнить на бумажке (имея под рукой список команд и помня формат файла) - да в древние времена кому-то и приходилось такую "ручную компиляцию" выполнять. А что нам ответит, например DeepSeek?

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

Дан массив с числами, в десятичном представлении - из них можно удалить какие-то, а то что осталось конкатенировать. Для N чисел это даёт 2^N-1 возможных результатов (нельзя удалить все числа) - и нам интересно сколько из этих результатов делятся нацело на 13.

Для маленьких массивов можно написать простой перебор, но автор предлагает N=400000 - у одного из пользователей это сразу вызвало реакцию "2 в степени 400000 - это невозможно перебрать". Действительно, перебором тут не справиться :)

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

Игра Rogue знаменита не только тем что породила и вдохновила огромное количество "потомков" - от визуально схожих Moria и NetHack до графически продвинутых вроде DIablo. Знаменита она ещё и тем что является одной из самых сложных игр для прохождения (в этом классе она гораздо интеллектуальнее чем Flappy Bird). Не уверен что вы найдете даже по форумам человека который скажет что проходил её (не читеря с файлами сохранения). А может такие есть среди вас?

Я заметил что современная опенсорсная версия (например доступная в пакетах для разных Linux и BSD) отличается от той, например, что была портирована коммерчески под ДОС где-то в 80е. Заметно отличаются монстры - чуть ли не со 2 уровня уже можно напороться на Ледяного Монстра который не только лишает подвижности но ещё и активно дамажит. Как будто и без того сложная игра стала ещё сложнее!

Дело в том что ранний код Rogue изначально не был доступен публично - кроме того авторы опенсорсной версии хотели избежать возможных нарушений прав (т.к. существовали уже коммерческие порты).

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

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

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

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

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

А как же наш любимый программизьм? :) Мне известно не так много примеров. Зачем вообще программисту задачи? Для начинающего актуально, конечно, на них "нарабатывать практику" (или когда уже не новичок но осваивает новый для себя язык программирования) - но не только это. Задачки кроме того дают идеи. Программисты же народ творческий и хотя бы подсознательно постоянно в поиске идей.

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

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

Эти занятия на правах предмета по выбору я веду в одной из местных школ с 2006 года. Их цель — дать представление юным знатокам — любителям ардуин — некоторое представление о том зачем светодиоду резистор, не говоря уже о пользе транзисторов‑конденсаторов и прочих чудес:‑) Занимаемся в основном на макетных платах, впрочем об организационной стороне дела лучше написать потом отдельно.

Такой список занятий с картинками (!) может быть полезен как тем кто захочет провернуть что‑то подобное в собственной школе (но затрудняется с чего начать) — так и тем кто сам захочет немного освежить понимание всех этих «аналоговых фокусов». Прилагаю и ссылочки на накопившиеся «электронные конспекты» по соответствующим темам. В принципе они годятся и для самообразования:‑)

Программируемая Логика - увлекательный и своеобразный мир - к сожалению среди большинства из нас, знатоков Python, JS, Go, Java, C++ да и среди любителей Arduino и прочих микроконтроллеров она не так широко "распростирает свои руки".

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

Мотивация (или везение?) пришло с очередной новой работой - хотя она не связана с PLD/FPGA, но в моей текущей компании эти направления значительно развиты, есть и знатоки - которые подсказали кое-что по инструментам, по выбору языка - а заодно показали и репозиторий с "домашками" от их собственного курса... Я засучил рукава, добавил компилятор в "песочницу" и вот уже первые несколько заданий ждут энтузиастов :) Также ждём знатоков которые захотят помочь с идеями новых задач и верификацией существующих. Итак, переходим к подробностям...

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

(не рассматривайте эту статью в качестве поучения "как надо писать" - код несколько архаичен и коряв, и реализация на KV таблице может выглядеть спорно)

В почте очередное рекрутёрское:

Родион, добрый день!
Меня зовут Юля, я HR компании Атом
Подробнее про нас и про то, чем мы занимаемся (ссылка).
Если коротко, то мы делаем собственный электромобиль с нуля. В 2025 году хотим встать на конвейер и для того, чтобы этот план стал реальностью, комплексно и очень активно укрепляем команды. Сейчас мы в поиске Ведущего Golang Developer`а. С описанием вакансии можно ознакомиться (ссылка)

Перехожу к описанию вакансии - текст можно найти под катом - но центральная фраза вот:

Мы ищем ведущего разработчика на Golang для работы над проектом «MQTT Cloud broker». Наша задача — разработка MQTT брокер‑сервера, который обеспечит надежную передачу информации между нашими электромобилями и облачными сервисами.

В конце письма «confidentiality notice» на английском языке из которого следует что о нём не следует никому рассказывать. Что и сподвигло меня на эту краткую заметку.

Я написал ответ с ключевой мыслью что хотя идея создания отечественного электромобиля (очередного) встречает среди меня бурное одобрение, я катастрофически не согласен с мыслью что для «вставания на конвеер» электромобилю нужен магазин приложений, облако и MQTT‑брокер для «надёжной передачи информации» в него.

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

Разработчики языка Go подбросили программистам занятную дилемму - в виде фиксированного размера буфера у каналов (тех что используются для передачи сообщений между потоками - точнее "go-рутинами" приложения). На днях на ревью увидел у коллеги код в духе:

- хотим оповещать "подписчиков" об изменениях в БД, асинхронно
- используем для этого канал с буфером какой-то вместимости (например, 50)
- когда вызывается коллбэк от БД, мы создаём информационное сообщение и пытаемся затолкать его в канал
- если канал оказался заполнен, просто пишем ошибку в лог и спокойно выходим из коллбэка ничего не делая (запись в базу проходит, но оповещения не будет)

Стоит ли так делать? А какие ещё варианты? Был бы канал безразмерным (как в erlang или некоторые из очередей в java) - программист и не задумался бы (может семантически лучше чтобы отправка в канал удавалась всегда - как запись в массив или мэпу) - но в Go нам предоставили "более полный" контроль над ситуацией, только не сказали что с ним делать :-)

Мне неизвестен ответ в духе "серебрянной пули" - ниже я лишь подытожил варианты которые обычно приходят в голову - и буду рад если вы поделитесь соображениями и опытом (а может и какими-то полезными библиотечками).

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

А кто-то быть может идей по улучшениям накидает - милости прошу!

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

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

В то же время в обычной SQL-ной базе проекта порой "не хватает" такого общего K-V хранилища для разнородных (семантически) записей. В своих проектах я такую обычно завожу. Среди коллег этот подход порой вызывает негатив :)

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

«Виселицу» — популярную игру на угадывание слов — кто‑то упомянул в комментариях к предыдущему посту, о задаче про игру в «Гонки». Не очень в тему, конечно — но я подумал «а чего это у нас задачи про виселицу нет?»

Теперь есть!

Обычно под программированием этой игры подразумевается написать код который загадывает слово — а пользователь предлагает буквы (и это пользователь будет повешен в случае неудачи). Здесь же наоборот — нужно написать программу которая угадывает слово по правилам данной игры. И теперь уже программист старается избежать «повешенья».

Задача интерактивная — сервер загадывает слово — а наша программа должна HTTP‑запросами предлагать ему буквы и смотреть что получается. Я покажу как можно «поиграть» вручную прямо из командной строки, используя curl но сдать задачу «вручную» не получится, поскольку присутствует ограничение по времени — так что без программы не обойтись.