Полно, голубь, не греши!
Убери свои гроши.
Я ведь это не для денег.
Я ведь это для души.

Леонид Филатов "Сказка про Федота-стрельца, удалого молодца"

Just for Fun.

Linus Torvalds

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

Чтобы быть интересным, программирование должно представлять собой, своего рода «зарядку для ума». Хорошим примером такого (полезного) развлечения является, известный многим ресурс, посвященный совершенствованию навыков составления SQL-запросов. Но не SQL-ем единым жив программист! Недавно, я нашел отличный способ усовершенствовать свои навыки владения Фортом. Axiom позволяет напрограммироваться на Форте вволю!

Мой рецепт получения Fun-а, при помощи Axiom, прост:

1. Выбираем любую игру, с правилами позаковыристее, из числа ещё не реализованных ZoG-сообществом
2. Пытаемся её воплотить в жизнь, используя Axiom
3. Получаем удовольствие, в процессе решения возникающих при этом задач
4. В случае, если в полученное приложение интересно играть, выработанный Fun автоматически удваивается!

          Старый серый ослик Иа-Иа стоял один-одинешенек в заросшем чертополохом уголке Леса, широко расставив передние ноги и свесив голову набок, и думал о Серьезных Вещах.

                  А. Милн «Винни-Пух и все-все-все»

— Видите ослика? — спрашиваю я милиционера. — Вон там маленький серый ослик… Артикул 2908. Цена тридцать две копейки. У него великое будущее.
— У осликов это бывает, — соглашается милиционер. — У них иногда бывает очень большое будущее.

                  Генрих Альтов «Ослик и аксиома»


Что самое сложное в разработке настольных игр? Очевидно, не анимация перемещения фигур по доске. Сложно придумать разумные и интересные игровые правила. Бывает очень сложно обеспечить игровой баланс. Если мы занимаемся компьютерной разработкой, зачастую, безумно сложно реализовать качественный AI (для таких игр как Го или Сёги эта проблема не решена до сих пор). И даже если нам удалось реализовать работающий AI, приходится проделать очень большой объем работ, чтобы оценить качество его работы и выбрать из нескольких возможных вариантов наилучший.

Я хочу рассказать об инструменте, способном существенно упростить решение всех этих вопросов. Axiom Development Kit задумывалась разработчиками как способ улучшения Zillions of Games. В частности, она ориентирована на реализацию игр, связанных с захватом территории (таких как Го), с которыми AI ZoG справляется очень плохо. Кроме того, Аксиома существенно расширяет возможности ZoG-разработчиков, предоставляя массу возможностей, практически не реализуемых в рамках традиционного ZRF (языка описания правил). При всём этом, Аксиома может работать совершенно самостоятельно, даже если ZoG на компьютер никогда не устанавливался и не покупался. Но, обо всём по порядку…

This game has no name.

       Виктор Пелевин «Generation П»

Дорога в тысячу ли начинается с первого шага.

       Лао Цзы


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

В одном мгновенье видеть Вечность,
Огромный мир — в зерне песка,
В единой горсти — бесконечность,
И небо — в чашечке цветка.

              сэр Уильям Блейк

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

              сэр Артур Конан Дойл "Этюд в багровых тонах"

Сегодня, я хочу поддержать почин уважаемого Unlimion и рассказать о попытке реставрации правил игры, считающейся, на сегодняшний день, древнейшей из известных игр, связанных с перемещением фишек по доске. Доски для этой игры были найдены в 1926-1927 г.г., знаменитым археологом сэром Леонардом Вулли, на раскопках развалин города-государства Ур в Месопотамии. Сама игра датируется 2600-2500 до н.э. Поскольку название игры до сих пор остаётся неизвестным, она именуется в честь города, в котором была найдена.

У тех, кто читал цикл моих статей, посвященных Zillions of Games, могло сложиться впечатление, что я полностью удовлетворен этим продуктом. Разумеется, это не так. ZoG уникален тем, что позволяет быстро и практически «на коленке» разработать прототип почти любой логической игры, но это вовсе не означает, что он идеален. Сегодня, я хочу рассказать о том, что мне не нравится в этом проекте.
Конечно, эта критика нужна не сама по себе. Я вполне отдаю себе отчет в том, что при полностью остановившейся разработке продукта (кстати, это один из тех моментов, которые мне не нравятся), подобная критика, как средство обратной связи с разработчиком, совершенно бесполезна. Поэтому, я не собираюсь писать каких либо писем создателям продукта — паровоз уже давно ушёл.

ZoG показал возможное направление действий, саму возможность создания подобного универсального игрового движка, но, если хочешь, чтобы что-то было сделано, делать это придется самому. Работа эта не простая и я совсем не уверен, что мне удастся с ней справиться (по крайней мере в одиночку). В любом случае, в качестве самого первого шага, будет полезно разобраться, чем плохо то, что уже имеется. Для чего затевать разработку нового продукта? Я постараюсь рассказать об этом…

         — Эволюция? — оживился Главный. — Что-то новенькое?

         — Французская выдумка. Я в этом пробовал разобраться. Если, к примеру, взять дождевого червя и вместо него сразу подсунуть африканского носорога, то все увидят, что их надули. Но если тот же фокус растянуть надолго, то никто и не заметит.

        В этом вся штука: кто видел червяка — все давно повымерли, а кому встретился носорог — тому некогда рассуждать о всяких пустяках.

        Евгений Чемеревский "Вариации на тему черепахи"

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

Я хочу рассказать о том, с чем знакомы почти все. О том, чем мало кто интересуется. О том, о чем никто практически ничего не знает. Я хочу рассказать о Шашках. Не спешите ухмыляться. Если вы думаете, что знаете о Шашках все, ответьте (для себя) на несколько простых вопросов:

• Какие разновидности Шашек существуют?
• Чем отличаются Шашки от Шахмат?
• Что общего у Шашек и «Крестиков-ноликов»?

Эти вопросы кажутся вам глупыми? Это нормально, мне тоже казались… пока я не заинтересовался историей Шашек

Сегодня я завершаю цикл статей, рассказывающих о возможностях языка ZRF, используемого для разработки игр в Zillions of Games. Поскольку я намеренно двигался от простого к сложному, логично предположить, что сегодняшняя игра (в плане реализации) будет сложнее всех предыдущих. Это действительно так. Дело в том, что ZRF ни в коем случае нельзя отнести к универсальным языкам программирования. Он предназначен для описания игр похожих на Шахматы. Чем более «шахматоподобна» игра, тем более очевидно её описание (если, конечно, не обращать внимание на описание правил таких хитрых ходов как рокировка или взятие на проходе). Описание такой игры может быть довольно большим по объему (в этом случае может помочь PreZRF, о котором я писал ранее), но довольно тривиальным по содержанию.

Все меняется когда приходится делать что-то на Шахматы совсем не (или не совсем) похожее. Создание таких приложений как Game of Life или Mine Finder является серьезным вызовом, в случае использования чистого ZRF, без каких либо расширений. Сегодня я постараюсь показать с какими сложностями может быть связана подобная разработка.

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

Как можно бороться с подобной избыточностью?

Разумеется, с помощью макросов! Проблема в том, что макросы ZRF недостаточно выразительны для этого. Адриан Кинг, в процессе разработки игр Scirocco и Typhoon, пришел к аналогичному выводу и разработал свой собственный, расширенный язык макросов, работающий как внешний препроцессор. Сегодня, я расскажу о возможностях этого языка и постараюсь, на примере Thud!, показать его использование в процессе разработки ZRF-приложений.

Я уже писал о том как легко разработать собственную игру, используя Zillions of Games, но я не упомянул об одном важном следствии этого факта. Набор приложений для ZoG не ограничивается 375 играми и головоломками, входящими в комплект дистрибутива. Игр, разработанных под Zillions of Games действительно много. Десятки энтузиастов со всего мира пополняют этот список, используя как ZRF, так и native-расширения. На сегодняшний день, его размер уже перевалил за 2000.

Конечно, я не смогу рассказать обо всем, что было реализовано в рамках проекта ZoG. Сегодня, я постараюсь рассказать о приложениях, показавшихся мне особенно интересными.

Сегодня я хочу продолжить рассказ о возможностях языка описания игр ZRF, используемого Zillions of Games. В предыдущих статьях цикла я показал как описываются ходы фигур, но есть еще одна важная разновидность хода, оставшаяся не рассмотренной. Помимо перемещения фигур по доске (возможно со взятием фигур противника), игрок (если ему это разрешено), может добавлять новые фигуры на поле. Эта разновидность хода называется сбросом (drops).
Кроме того, в сегодняшней статье, я расскажу о том, как в ZoG осуществляется генерация случайных ходов. Этот функционал необходим, например, при реализации игр, использующих броски игровых костей, для выполнения ходов, таких как Ludo или Chaturanga.

В качестве примера, я предлагаю, взяв за основу классические Шахматы, реализовать игру по мотивам одной из миссий сюжетной кампании Battle vs Chess. Большинство миссий в кампании играются по измененным правилам. Миссии различаются по сложности, в некоторых, для победы, достаточно провести одну из пешек в ферзи, в других — поставить мат за ограниченное число ходов. Я предлагаю рассмотреть четвертую миссию кампании Хаоса под названием «Точка невозврата».

         Но мы говорим: здесь в этой пещере на краю света, дварфы и тролли заключили мир, чтобы рука об руку пройти под дланью Смерти.

         И мы говорим: враг наш не Тролль и не Дварф, а злоба, клевета, трусость, сосуды омерзения, те, кто творят зло под личиной добра. Вот с кем мы сражались сегодня, но упрямство глупцов вечно и скажут… что это ложь

                                                                        сэр Терри Праттчетт

В предыдущей статье, я рассказывал об оригинальной настольной игре, разработанной Тревором Трураном, по мотивам произведений знаменитого английского писателя Терри Пратчетта. В 2005 году, Труран разработал новую игру, использующую тот же набор фигур, на той же доске. Название этой игры — "Koom Valley Thud" и, сегодня, я постараюсь ее реализовать, попутно рассказав о тех возможностях языка ZRF, о которых не успел рассказать ранее.

Напомню, что ZRF — это язык описания игровых правил (напоминающий Lisp), используемый Zillions of Games. Несмотря на то, что в нём имеются определенные сложные моменты, в целом, он довольно прост и может быть освоен любым человеком, даже очень далеким от программирования. Главным достоинством игрового ядра ZoG является его универсальность. Описав правила мы, фактически сразу, получаем новую игру. Хотя AI ZoG уступает специализированным игровым движкам, играет он, на удивление, сильно. К сожалению, бесплатная демонстрационная версия приложения позволяет запускать лишь ограниченный набор игр и не позволяет загружать ZRF-описания собственной разработки.

Бац…

…с этим звуком тяжелая дубинка соприкоснулась с чьей то головой. Тело дернулось и завалилось назад. Дело было сделано, никем неуслышанное, неувиденное: идеальный конец, идеальное решение, идеальная история.

Но, как говорят гномы, за любой бедой стоит тролль.

                                                                   сэр Терри Праттчетт

Thud! Разумеется, я не мог пройти мимо этой игры. Не только потому, что мне очень нравятся произведения Терри Пратчета, но, главным образом, по той причине, что игра эта ни на что не похожа. Начнем с того, что играется она на восьмиугольной доске. Гномы сражаются с троллями (и последних существенно меньше). Как тролли могут победить, пребывая в меньшинстве? Очень просто — за один ход тролль может снять с доски несколько гномов. А гномам, даже действуя сообща, чтобы снять с доски одного тролля приходится попотеть.

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

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

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

Поскольку на стандартной шахматной доске 8x8 черные побеждают элементарно, используем для игры доску 9x9 клеток. Эта игра очень простая (и нравится детям). При правильной игре, белые всегда побеждают.

К шахматам я неравнодушен с детства. Хотя я так и не научился играть действительно хорошо, сам процесс игры доставляет мне огромное удовольствие. Довольно давно я узнал, что помимо известных всем традиционных шахмат, существуют и другие их разновидности. Не помню на каком компьютере, на Спектруме или Векторе 06 Ц я впервые увидел Сянцы. Игра была полностью на китайском языке и постигать её правила приходилось «методом тыка». Позже, я узнал о существовании Сёги, Чатуранга и прочих ближайших родственников Шахмат. Публикации в Кванте подстегнули интерес к Сказочным шахматам. Меня заинтересовал вопрос, сколько вообще известно разновидностей шахмат? Выяснилось, что их невероятно много. Настолько много, что список, посвященный этому вопросу на Вике очень и очень далек от того, чтобы его можно было считать полным.

Уже гораздо позже, когда я стал профессиональным программистом, у меня появилась идея, разработать универсальное приложение, для контроля правил ходов в разнообразных шахматноподобных играх на квадратных и прямоугольных досках. Разумеется, у меня и в мыслях не было, что я смогу создать универсальный AI. Даже сама задача реализации универсальной шахматной доски, с настраиваемым контролем всевозможных правил и возможностью игры по сети выглядела неподъемной. Я коллекционировал правила шахматных игр, пытался обобщить их, но, с учетом того, что я занимался этим краткими урывками, между основной работой, процесс пробуксовывал и шел очень медленно. Так продолжалось до тех пор, пока в прошлую пятницу, я не обнаружил проект под названием Zillions of Games.

Сегодня я хочу рассказать об XSLT. Этот, весьма своеобразный, язык может оказаться очень полезным в тех случаях, когда требуется обработать XML-данные, сколь нибудь не тривиальным образом. Я расскажу о двух наиболее популярных (в среде Java-разработчиков) реализациях XSLT-процессора, подробно остановлюсь на вопросах их использования из Java-кода и попытаюсь сравнить их производительность. В качестве теста для сравнения производительности, я буду использовать широко известную задачу о расстановке 8-ми ферзей на шахматной доске.

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

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

Важность наличия возможности такой рассылки сложно переоценить. Действительно, отослав уведомление об аварии на EMail контактного лица, мы не можем рассчитывать на немедленное реагирование. Неизвестно, когда адресат прочитает свою почту. SMS доставляется намного оперативнее.

В нашей компании давно и успешно используется собственная реализация SMPP-сервиса и мысль об использовании готового SMPP-клиента на Java показалась мне логичной. Отважно вбив в строку поиска google слова «java smpp client», я немедленно нашел нужную мне библиотеку. О том, что происходило дальше, рассказывает мой сегодняшний пост.

Некоторое время назад, я написал статью посвященную вопросам оптимизации загрузки данных в БД Oracle. Судя по обилию последовавших комментариев, статья вызвала живой интерес, но, судя по тем-же комментариям (а также последовавшей статье о загрузке данных в PostgreSQL) многими она была понята не так, как я на то рассчитывал. По большей части, виноват в этом я сам, поскольку, в процессе упрощения изложения материала, оторвался от жизни настолько, что задача перестала быть понятна окружающим (это, в свою очередь, негативно сказалось на понимании причин выбора методов, использованных для ее решения).

Сегодня, я хочу исправить допущенные ошибки. Я расскажу о реальной задаче обработки данных SNMP-мониторинга, уделяя максимальное внимание техническим подробностям. Я постараюсь обосновать выбор подходов для ее решения и сравнить их производительность. Также, я уделю внимание тем техническим моментам, которые могут вызвать сложности у новичков. Прежде чем двигаться дальше, я хочу выразить свою признательность DenKrep, xlix123, zhekappp и всем прочим товарищам, давшим невероятное количество полезных советов, в процессе обсуждения предыдущей статьи.

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

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

Обычной практикой является обработка данных мониторинга посредством RDBMS (таких как Oracle Database). Но способны ли традиционные реляционные базы данных справиться с такой нагрузкой? Попробуем в этом разобраться.

Давным давно, на Хабре была опубликована статья, рассказывающая о том, как использовать популярную библиотеку, для работы с SNMP из Java-приложения. Поддерживая, в целом, начинание автора, я хочу остановиться на тех сложностях, которые могут возникнуть в реальном проекте, использующем SNMP.