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

Именно такую картину рисует мое воспаленное воображение при слове “асинхронность”. Конечно, все это слишком эмоционально и не всегда правда. Ведь так?.. Возможны варианты. Некоторые скажут, что “при правильном подходе все будет работать хорошо”. Однако это можно сказать всегда и везде при всяком удобном и не удобном случае. Но лучше от этого не становится, баги не исправляются, а бессонница не проходит.

Так что же такое асинхронность? Почему она так привлекательна? А главное: что с ней не так?

Оптический поток (Optical flow) – технология, использующаяся в различных областях computer vision для определения сдвигов, сегментации, выделения объектов, компрессии видео. Однако если мы захотим его по-быстрому реализовать в своем проекте, прочитав про него на википедии или где-нибудь еще, то, скорее всего, очень быстро наткнемся на то, что он работает очень плохо и сбоит при определении сдвигов уже порядка 1-2 пикселей (по крайней мере так было у меня). Тогда обратимся к готовым реализациям, например, в OpenCV. Там он реализован различными методами и совершенно непонятно, чем аббревиатура PyrLK лучше или хуже обозначения Farneback или чего-нибудь в этом роде, да и придется поразбираться со смыслом параметров, которых в некоторых реализациях очень много. Причем, что интересно, эти алгоритмы как-то работают, в отличие от того, что мы написали сами. В чем же секрет?

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

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

В статье будет много картинок. Объяснение как решать задачу рекурсивно и как она решается бинарным поиском.
В общем статья посвящается тем смелым, кто пока еще боится Ханойской башни, но хочет перестать её бояться.

Думаю у любого человека, интересующегося космосом — возникала идея купить телескоп, чтобы лично все посмотреть.

Однако суровая реальность вечно портит всю малину: в пределах города – все небо засвечено уличным освещением и турбулентность воздуха высокая. Это означает, что либо придется ограничится самыми крупными и яркими объектами (вроде Луны и Юпитера), либо возить телескоп далеко за город.

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

Пример того, что получилось: галактика Андромеда, M31 на телескопе Т20

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

И вот, однажды я решил портировать библиотеку на PHP, и теперь хочу поделиться ею с народом и очень надеюсь на помощь в ее улучшении: буду рад советам, баг-репортам и особенно pull-реквестам. Библиотека находится на GitHub'е: github.com/Andre-487/php_rutils

UPD от 26.10.2013: теперь библиотека так же доступна через Composer: packagist.org/packages/andre_487/php_rutils
Так же хочу сказать спасибо всем, кто помог улучшить библиотеку и довести ее до стабильного релиза.

Возможности библиотеки

PHP RUtils — порт Pytils на PHP. Это утилиты для работы с русским текстом. Утилиты разделены на следующие модули (классы):

• Numeral — работа с числами: склонение существительных в зависимости от количества, числа прописью, суммы денег в рублях и копейках прописью.
• Dt — работа с датами: расширение формата дат PHP русскими именами месяцев, дней недели; временные периоды (например, 24 976 дней назад).
• Translit — транслитерация, подготовка строк для использования в URL'ях, именах файлов.
• Typo — небольшой набор правил типографики простого текста.

В данном посте я расскажу о наиболее интересных командах, которые могут быть очень полезны при работе в консоли. Однозначных критериев определения какая команда лучше другой — нет, каждый сам для своих условий выбирает лучшее. Я решил построить список команд на основе наиболее рейтинговых приемов работы с консолью от commandlinefu.com, кладовой консольных команд. Результат выполнения одной из таких команд под Linux приведен на картинке. Если заинтересовало, прошу под кат.

Предыдущая статья цикла Язык программирования J. Взгляд любителя. Часть 1. Введение

Вопрос: Если функции изменяют данные, а операторы изменяют функции, тогда кто изменяет операторы?
Ответ: Кен Айверсон
Chirag Pathak

В J используется идея тацитного (от слова «tacit», неявный) программирования, не требующего явного упоминания аргументов определяемой функции (программы). Работа в тацитном подходе происходит, как правило, с массивами данных, а не с отдельными их элементами.
Интересно заметить, что тацитное программирование было открыто Бэкусом еще до APL и реализовано им в языке FP. Среди современных языков, поддерживающих такой подход, (кроме, естественно, J) можно назвать Форт и другие конкатенативные языки, а также Haskell (за счет point-free подхода).

1. Глаголы

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

	neg =: -

Дейкстра: А как вы запишите более сложное выражение? Например, сумму всех элементов матрицы, которые равны сумме индексов соответствующих строк и столбцов.
Айверсон: + + / (M = ?1 ^(o)+ ?1)M//
(Кеннет Айверсон — создатель языков APL и J)

1. Быстрый старт

Перед тем как APL получил свое название, он назывался «нотация Айверсона». Однако Кен считал, что название должно звучать просто как «Нотация». И в самом деле, мы же не говорим «трава Бога», мы говорим просто «трава».
Paul Berry

Отличительными особенностями языка программирования J можно назвать:

• векторная арифметика
• предельная лаконичность
• обширная стандартная библиотека, предназначенная в частности для статистической обработки данных
• наличие в стандартной библиотеке функций для рисования 2d графиков и 3d поверхностей, а также примитивов для создания графического интерфейса
• подробнейшая и разнообразнейшая документация и примеры

Можно сказать, что J находится в той же нише, что и Matlab и R. Но есть одно «но» — синтаксис языка.
Приведем один из самых распространенных учебных примеров всех введений и туториалов J:

	mean =: +/%#

В данном примере определяется новая функция (на языке J это называется «глаголом») «mean», которая рассчитывает среднее значение в массиве чисел.

Небольшая преамбула

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

Я намеренно не хочу затрагивать такие комплексные аспекты, как редактирование изображений и подготовка трехмерных визуализаций в Blender. Так же я не ставлю задачу обучить читателя пользоваться профессиональным инструментарием. Для этого есть документация и масса пользовательских ресурсов. Цели настоящей серии я бы очертил так:

• Устранить предвзятое мнение относительно невозможности использования *nix систем для профессиональной деятельности отличной от работы программиста или администратора сети;
• Показать, что за счет модульности архитектуры *nix систем и использования программного обеспечения с открытым исходным кодом, следующего стандартам POSIX, многие операции, на которые в привычном рабочем окружении я ранее тратил часы а то и дни, могут весьма просто автоматизироваться, либо решатся за считанные минуты;
• Поделиться опытом и показать, какой инструментарий выбирают специалисты (в частности, какой выбрал я в процессе поисков) и какие решения могут быть наиболее приемлемы для тех или иных задач.

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



_{Это тиражный результат. Прошу прощения за качество снимка, была только настольная лампа под рукой, если кто хочет посмотреть оригинал, вот буклет про GPS аудиогид в PDF формате с редуцированным разрешением растровой графики.}

Ниже я расскажу о ключевых этапах и проблемах, которые пришлось решать в процессе.