Владимир Казанов VlK

Классик писал, что счастливые часов не наблюдают. В те дикие времена ещё не было ни программистов, ни Unix, но в наши дни программисты знают твёрдо: вместо них за временем проследит cron.

Утилиты командной строки для меня одновременно слабость и рутина. sed, awk, wc, cut и другие старые программы запускаются скриптами на наших серверах ежедневно. Многие из них оформлены в виде задач для cron, планировщика родом из 70-х.

Я долго пользовался cron поверхностно, не вникая в детали, но однажды, столкнувшись с ошибкой при запуске скрипта, решил разобраться основательно. Так появилась эта статья, при написании которой я ознакомился с POSIX crontab, основными вариантами cron в популярных дистрибутивах Linux и устройством некоторых из них.

Используете Linux и запускаете задачи в cron? Вам интересна архитектура системных приложений в Unix? Тогда нам по пути!

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

Критика C — классический для нашей индустрии эпистолярный жанр. Она звучит то громче, то тише, но в последнее время буквально оглушает. Пример — перевод статьи Дэвида Чизнэлла «C — не низкоуровневый язык», опубликованный в нашем блоге некоторое время назад. Про C можно говорить разное, в дизайне языка действительно много неприятных ошибок, но отказывать C в «низкоуровневости» — это уже слишком!

Чтобы не терпеть такую несправедливость, я собрался с духом и постарался определиться с тем, что есть язык программирования низкого уровня и чего хотят от него практики, после чего перебрал аргументы критиков C. Так получилась эта статья.

Сбор, хранение, преобразование и презентация данных — основные задачи, стоящие перед инженерами данных (англ. data engineer). Отдел Business Intelligence Badoo в сутки принимает и обрабатывает больше 20 млрд событий, отправляемых с пользовательских устройств, или 2 Тб входящих данных.

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

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

17 млрд событий, 60 млн пользовательских сессий и огромное количество виртуальных свиданий происходят в Badoo ежедневно. Каждое событие аккуратно сохраняется в реляционные базы данных для последующего анализа на SQL и не только.

Современные распределённые транзакционные базы данных с десятками терабайт данных — настоящее чудо инженерной мысли. Но SQL как воплощение реляционной алгебры в большинстве стандартных реализаций пока не позволяет формулировать запросы в терминах упорядоченных кортежей.

В последней статье из серии, посвящённой виртуальным машинам, я расскажу про альтернативный подход к поиску интересных сессий — движок регулярных выражений («Поросячий Матчер»), определённых для последовательностей событий.

Виртуальная машина, байт-код и компилятор прилагаются бесплатно!

"No matter how hard you try, you can't make a racehorse out of a pig. You can, however, make a faster pig" (комментарий в исходном коде Емакса)

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

Во второй части серии статей об интерпретаторах байт-кодов я на примере небольшой стековой виртуальной машины ПВМ («Поросячья Виртуальная Машина») постараюсь показать, что не всё потеряно для трудолюбивых поросят с амбициями и что в рамках (в основном) стандартного C вполне возможно ускорить работу таких интерпретаторов по меньшей мере в полтора раза.

Виртуальные машины языков программирования в последние десятилетия получили весьма широкое распространение. С презентации Java Virtual Machine во второй половине 90-х прошло уже достаточно много времени, и можно с уверенностью сказать, что интерпретаторы байт-кодов — не будущее, а настоящее.

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

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

Разработчикам часто приходится иметь дело с файлами, представляющими из себя древовидную структуру: XML, JSON, YAML, всякого рода языки разметки вроде Markdown или Org-mode. Облегчая в общем и целом нашу жизнь, такие файлы имеют склонность к бесконтрольному росту, в какой-то момент из решения превращаясь в проблему.

Стандартное решение этой проблемы — разбиение на меньшие файлы. Это, конечно, работает, но не всегда удобно.

Но существует и альтернатива, о которой — ниже.

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

Большую часть литературы по теме можно отнести либо к первым, либо ко вторым: академические исследования традиционно проходят в башнях из слоновой кости, не демонстрируя, как правило, никаких примеров живых изданных игр; прикладные же тексты опускаются до формата рецептов и интуитивных советов, не давая никакой осязаемой модели работы тех или иных приемов.

Книга, что попалась не так давно на глаза, объединяет в себе оба мира: в ней, с одной стороны, описаны интересные в совокупности алгоритмические приемы; результат же работы — настольная игра «Yavalath» на приложенной картинке — был издан и пользовался достаточно широкой для абстрактной игры популярностью.

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

Одни питонисты любят код читаемый, другие предпочитают лаконичный. К сожалению, баланс между первым и вторым — решения по-настоящему изящные — редко случается встретить на практике. Чаще стречаются строки вроде

my_function(sum(filter(lambda x: x % 3 == 1, [x for x in range(100)])))

Или четверостишья а ля

xs = [x for x in range(100)]
xs_filtered = filter(lambda x: x % 3 == 1, xs)
xs_sum = sum(xs_filtered)
result = my_function(xs_sum)

Идеалистам же хотелось бы писать как-то так

result = [x for x in range(100)] \
    | where(lambda x: x % 3 == 1)) \
    | sum \
    | my_function

Не в Питоне?

Ну вот и случилось долгожданное событие: вышла новая версия одной из лучших свободных пошаговых игр — Battle for Wesnoth.

Из нового:

• Новая кампания
• Изменения и исправления в старых кампаниях
• Новые саундтреки
• Исправления в графике, улучшения в интерфейсе
• Усовершенствованный AI
• Новые переводы
• Огромное число багфиксов
• Новые инструменты для разработчиков контента

Ну и многое другое, разумеется, из того, над чем работали разработчики последний год. За подробностями сюда.

Какое-то время назад Хабре проскакивала заметка про клиент-парсер сайтиков на Питоне. Автор на этом примере разбирал проблемы многопоточных сетевых приложений.

Но мне показалось, что ту же задачу (вернее, ее главную часть — параллельные соединения c http-cервером) вполне можно эффективно решить и без потоков.

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

Почти все знают о гигантах конвеерного веб-программирования, основанных на php — Drupal, Joomla!, Wordpress и прочих, но не все знают, что в мире Python существуют не менее мощные и даже гораздо более зрелые инструменты.

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

Питон — очень гибкий язык. Одна из граней этой гибкости — возможности, предоставляемые метапрограммированием. И хотя в ядре языка абстрактные классы и интерфейсы не представлены, первые были реализованы в стандартном модуле abc, вторые — в проекте Zope (модуль zope.interfaces).

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

Некоторое время назад случилось несколько событий, изменивших привычный вид ландшафта веб-разработки на Питоне: Facebook приобрела сервис Friendfeed и сразу же открыла исходный код технологии проекта — http-сервер и микрофреймворк Tornado. Одновременно разработчик Friendfeed опубликовал в своем блоге заметку, в которой привел причины, по которым было решено с нуля разрабатывать собственный асинхронный веб-сервер.

Статья — экскурсия в самое сердце этого и конкурирующего (Twisted.web) проектов, их циклы асинхронной обработки поступающих данных.

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

1 Введение

В своей прошлой заметке я постарался осветить в общих чертах стиль работы с
распределенной системой контроля версий git и указать на отличия по сравнению с
классическими централизованными СКВ. Целью было прежде всего обобщение опыта
работы с системой без упоминания тонкостей синтаксиса отдельных команд.

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

1 Вступление

В топике освещаются не столько подробности работы с git, сколько его отличия от схемы разработки других систем контроля версий, и общий подход (выработанный по большей части личным опытом и Git Community Book) к работе.

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

Отчет в двадцать страниц, из которых пятнадцать — расчетов. Никакой разумной деятельности, только тупой и кропотливый набор формул пальчиками.

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