Дан массив с числами, в десятичном представлении - из них можно удалить какие-то, а то что осталось конкатенировать. Для 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 но сдать задачу «вручную» не получится, поскольку присутствует ограничение по времени — так что без программы не обойтись.

Среди игр на тетрадном листочке из школьной поры была такая Гонки — вы тоже помните? На удивление, похожую игру предлагает в своей старинной книжке Жак Арсак — машина «в пошаговом режиме» мчится по извилистой трассе на целочисленной плоскости — и нужно варьируя вектор скорости умудриться не вылететь — но и доехать не черепашьим шагом.

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

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

Честно говоря планировалось что в задаче будет спрашиваться наиболее быстрый маршрут — но составляя её я немного усомнился в собственном решении — поэтому она стала чуточку проще.

Конечно, из‑за того что вся трасса видна сразу, отсутствует интрига — но на днях планируется добавить версию игры в которой нужно играть против HTTP‑сервера — и там «видимость» трассы будет ограниченной, так что если не хватает интриги — просто чуть‑чуть подождите :-)

Известна зловещая история о том, как Мария Стюарт лишилась головы из‑за одноподстановочного шифра — задолго до вымышленных баек про «Золотого Жука» или «Пляшущих Человечков». Нынче подобные шифры вызывают снисходительную улыбку даже у школьников — чтобы расшифровать их, обычно и компьютер‑то не требуется.

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

Оказывается Хабр доброжелательно предоставляет возможность завести бесплатный «корпоративный» блог для опенсорсного проекта. Какое‑то время назад я подал заявку — и недавно обнаружил что она была удовлетворена. Начинать программисты любят с «тестового» поста, но т.к. речь идёт о публичном пространстве, пусть он будет хоть немного содержательным:)

На сайт CodeAbbey сегодня добавилась задачка про поиск Белого Прямоугольника. Речь идёт о матрице в которой есть чёрные и белые клетки — расставленные достаточно хаотично — и хочется найти прямоугольник без чёрных клеток максимальной площади (со сторонами параллельными сторонам матрицы, конечно).

Про сам сайт мы ещё расскажем в отдельно (иначе зачем блог было заводить) — а сейчас всё же про саму задачку.

Это ещё один "эзотерический" язык, не относитесь к нему слишком серьёзно :)

Некоторые языки хвастаются отсутствием циклов - например в Erlang или Scheme циклы реализованы через хвостовую рекурсию. Иногда "отсутствием циклов" называют конструкцию в духе (1..10).forEach(something) - а отсутствием условного оператора, какую-нибудь разновидность match. Честно говоря, выглядит просто как альтернативный синтаксис.

А как можно "совсем без"? Вот в машине Тьюринга и подобных автоматах мы переключаем "состояние" и дальнейшее исполнение программы зависит от того в какое состояние мы попали. Это похоже на GOTO у которого параметр не обязан быть константой.

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

Конечно, это "прототипичная" версия - в ней не хватает многих фишек - и она абсолютно открытая к вашим предложениям и идеям!

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

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

Искренне извиняюсь за такую нетехническую заметку, но прям "наболело" :)

Давным‑давно, чуть больше 50 лет назад вышла книга «101 BASIC Computer Games» — она стала первой книгой на компьютерную тематику, тираж которой перевалил за миллион экземпляров. Нужно понимать — это был 1973 год, до появления домашних компьютеров типа Apple II или ZX80 ещё оставалось лет пять — так что книжка предназначалась студентам и сотрудникам учреждений где были установлены «миникомпьютеры» — девайсы размером с несколько домашних холодильников — но нередко уже многопользовательские, с подключенными телепринтерами в качестве рабочих мест. Сам BASIC ещё не разменял первый десяток лет. Программы предлагалось перепечатать вручную — тем не менее это издание сразу стало популярным.

В этой статье мы взглянем поближе — а что же за «игры» там были, интересные ли? Я попытался разложить их по категориям, т.к. в книге они идут просто по алфавиту и выискивать что‑то интересное среди них затруднительно.

Если отказаться от Бейсика — то игры из этого сборника могут быть интересны, например, на уроках программирования. Алгоритмы встречающиеся в играх могут быть не менее полезны чем задания на пузырьковую сортировку — и притом, конечно, программирование игр более увлекательно (даже если играть в получающиеся игры, прямо скажем, не очень интересно).

Совсем коротенький рассказ — о довольно бесполезной но забавной штуковине, извините :)

Как-тораз я написал интерпретатор BASIC, который можно использовать на контроллере хоть с 1кб памяти (в частности AVR / Arduino). В основном мы им пользовались через Bluetooth‑модуль с телефона (я уж рассказывал). Но у меня руки чесались сделать своеобразный «терминальчик» — ну я и сделал.

Как видите — в качестве экрана тут дисплей 4 строки по 20 символов. А клавиатура полноценная — обычная c PS/2 разъёмом. Между ними и UART‑ом воткнут контроллер (младший STM32). Вообще‑то можно было без него, реализовать общение с клавиатурой и дисплеем в том же контроллере где интерпретатор крутится — но тогда это не был бы терминал, его нельзя было бы использовать с любым другим UART‑интерфейсом.

Покажу картинки, код — и немножко расскажу про устройство. А если сами строили что‑то похожее — расскажите и вы :)

Ещё статья про ассемблер для тех кто с ним не знаком. В предыдущей про 5 ассемблеров последний примерчик вызвал критику за "упрощенизм". А давайте посмотрим вместе как его улучшить и немножко нарастить - в качестве "продолжения знакомства".

Заодно полюбуемся на несовместимость Linux и BSD, а также на различие 32 и 64-битной версии обеих ОС - и подумаем как с этим бороться.

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