После возни с трехмерной игрой «Жизнь» я вспомнил о том, что для обычной, конвеевской версии этой игры существует алгоритм под названием «Hashlife». Он несколькими фразами описан в Википедии, и приведенной там картинки с комментарием («конфигурация через 6 октиллионов поколений») для меня было достаточно, чтобы держаться от этой идеи подальше: сколько же ресурсов нужно этому алгоритму? Стоит ли за него браться вообще?

Общая идея алгоритма такая.

Допустим, что у нас есть квадрат поля размером N*N (N>=4 – степень двойки). Тогда мы можем однозначно определить состояние его центральной области размером (N/2)*(N/2) через T=N/4 шага. Если мы запомним состояние исходного квадрата и результат его эволюции в словаре, то сможем в следующий раз, встретив такой квадрат, сразу определить, что с ним станет.

Предположим, что для квадратов N*N эволюцию на N/4 шага мы считать умеем. Пусть у нас есть квадрат 2N*2N. Чтобы просчитать его развитие на N/2 шагов, можно сделать следующее.

Разобьем квадрат на 16 квадратиков со стороной N/2. Составим из них 9 квадратов со стороной N, для каждого из них найдем результат эволюции на N/4 шага. Получится 9 квадратов со стороной N/2. В свою очередь, из них составим уже 4 квадрата со стороной N, и для каждого из них найдем результат эволюции на N/4 шага. Полученные 4 квадрата со стороной N/2 объединим в квадрат со стороной N – он и будет ответом.

Часть 1: Архитектура
Часть 2: Протокол
Часть 3: Клиент-серверное взаимодействие

В последнее время работаю с 11 flash на примере движка AWAY3D 4. Информации на русском по этому движку очень мало. На хабре о нем практически ничего нет. Вот решил написать пару статей об этом очень интересном продукте. Писать про простые кружки и кубики не совсем интересно. Не люблю обсуждать сферических коней в вакууме.
В общем решил сделать описание движка на боле менее реальном примере. Переведем нашу игру в топдаун 3D шутер. И продолжим разработку, но уже с применением 3D технологий.
Конечно я в курсе, что есть движок Alternativa3D. Но мне их продукт не нравится по многим причинам. Обсуждать их в статье не будем, если есть вопросы, добро пожаловать в каменты.

В общем будем делать альтернативу альтернативе…

PHP очень популярный язык программирования, но тестирование в нем, это скорее прерогатива экспертов, а не жизненная необходимость. Неужели это от того, что PHP-разработчики поголовно быдло-кодеры? Я считаю, что нет. Скорее всё от того, что системы тестирования порой излишне усложнены. А тесты, наоборот, должны были предельно просты: легко читаться, писаться, отлаживаться, и конечно же, быстро выполняться. Мое виденье того как это можно воплотить в PHP вылилось в проект под названием Codeception.

С ним тесты для ваших веб-приложений могут выглядеть так:

<?php
$I = new TestGuy($scenario);
$I->wantTo('create new blog post');
$I->amOnPage('/blog/posts');
$I->click('Create new post');
$I->fillField('Title','Codeception, a new way of testing!');
$I->fillField('Text','Codeception is new PHP full-stack testing framework.');
$I->click('Send');
$I->see('Congratulations, your post is successfully created!');

Согласитесь, такой тест понятен без дополнительных комментариев.
А теперь самое интересное: этот код без всяких изменений может быть выполнен как функциональный тест в фреймворках symfony, Symfony2,Zend Framework, а также в браузерном эмуляторе Goutte и даже через Selenium. Таким образом, вам предлагается единый интерфейс для написания функциональных тестов практически для любого сайта.

Цель этой статьи — заставить всех, особенно программистов на Си, сказать «я не знаю Си».
Хочется показать, что тёмные углы в Си значительно ближе, чем кажется и даже тривиальные строки кода несут в себе undefined behavior.

Introduction

Цель данной статьи — помочь начинающему iOS разработчику, понять, как правильно работать с SQLite базой данных используя Core Data на примере iPhone Core Data Recipes. В первой части из серии статей, будет рассмотрено взаимодействие приложения и базы данных, а также работа со связанными записями (Relationships).

Prerequisites

Для самостоятельного изучения исходных текстов данного приложения, вам необходим стандартный набор инструментов:

• Mac OS X
• Xcode

Данный набор позволит вам просмотреть, изменить и запустить приложение на симуляторе. В случае же, если вы захотите попробовать запустить его на настоящем iPhone, требуется участие в iOS Developer Program.

А также, что немало важно, нужно базовое понимание структуры языка Objective-C и приложения.

Ссылки на используемые материалы и инструменты предоставлены в разделе References.

Что такое iPhone Core Data Recipes?

Xcode проект от разработчиков из Apple, который дает общее представление о том, как использовать view controllers, table views и Core Data в iPhone приложениях. Конечно, данный проект также актуален для iPad, но в него необходимо внести интерфейсные изменения, для корректного отображения на iPad.

iPhone Core Data Recipes Screenshots

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

В рамках JSR-299 “Contexts and Dependency Injection for the Java EE platform” (ранее WebBeans) была разработана спецификация описывающая реализацию паттерна внедрения зависимости, включенная в состав Java EE 6. Эталонной реализацией является фреймворк Weld, о котором и пойдет речь в данной статье.

К сожалению в сети не так много русскоязычной информации о нем. Скорее всего это связано с тем, что Spring IOC является синонимом dependency injection в Java Enterprise приложениях. Есть конечно еще Google Guice, но он тоже не так популярен.

В статье хотелось бы рассказать об основных преимуществах и недостатках Weld.

Всем привет!
Процесс обработки ошибок в Yii был для меня не совсем прозрачным с первых дней использования этого фреймворка. Даже несмотря на наличие в документации специального раздела Error Handling. В каких случаях какие view используются, как влияет ajax или debug-режим, зачем нужен errorAction, в чем отличия при обработке исключений?
В итоге после копания в документации и исходном коде фреймворка я нарисовал наглядную схему обработки ошибок, которая лично для меня оказалась весьма полезной и наверняка пригодится кому-то еще.
Под катом собственно схема и некоторые комментарии к ней.

InCube Chess: первая удачная реализация шахмат в трёхмерном поле

Привет!

Хотя в Хабре обычно не обсуждают игрушки, полагая их занятием несерьёзным – я сознательно сделал сегодня исключение. Очень уж редко в «игровой индустрии» происходит что-то действительно оригинальное. К тому же надобно, чтобы при яркой оригинальности оно осталось ещё и играбельным – а это уж совсем редкость. Но в данном случае, кажется, оба требования сошлись. В общем, я нашёл кое-что для настоящих «головастиков»…

Суть в том, что небольшая украинская фирма «InCube Games» выпустила одноимённые компьютерные шахматы: InCube Chess. И это не заслуживало бы ровно никакого внимания (мало ли шахматных программ?) – если бы не одна существенная деталь: поле для шахмат представляет собой не плоскую «доску» 8х8, а куб, 8х8х8. То есть борьба между фигурами игроков разворачивается не в двумерном, а в трёхмерном пространстве!

Недавно на одном из форумов, посвященных многомерным пространствам, был задан вопрос: «А какие игры реализованы в нетривиальных пространствах, в частности, нет ли где реализации игры Каркассон на плоскости Лобачевского?» Вопрос мне показался интересным, тем более, что про эту игру я ни разу не слышал.

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

Понятно, что простор для обобщений в сторону нетривиальной геометрии огромен. Можно вместо квадратных карточек разработать треугольные или шестиугольные. Можно укладывать квадратные карточки на поверхность куба (появится 8 особых точек, в которых сходятся 3 а не 4 карточки, но это не очень принципиально). Можно нарисовать на плоскости Лобачевского квадратную сетку, в каждой вершине которой сходится 5 (или 6, или бесконечно много) квадратов. А можно заменить квадратные клетки на кубические и строить карту в пространстве.

Я выбрал последний вариант. Очень уж интересно было посмотреть на то, как будет выглядеть карта местности на четырехмерной планете.

Памятка начинающему экзорцисту.

Прежде, чем начать: я знаю, что такое phpDaemon и System_Daemon. Я читал статьи по этой тематике, и на хабре тоже.

Итак, предположим, что вы уже определились, что вам нужен именно демон. Что он должен уметь?

• Запускаться из консоли и отвязываться от неё
• Всю информацию писать в логи, ничего не выводить в консоль
• Уметь плодить дочерние процессы и контролировать их
• Выполнять поставленную задачу
• Корректно завершать работу

Отвязываемся от консоли

// Создаем дочерний процесс
// весь код после pcntl_fork() будет выполняться двумя процессами: родительским и дочерним
$child_pid = pcntl_fork();
if ($child_pid) {
    // Выходим из родительского, привязанного к консоли, процесса
    exit();
}
// Делаем основным процессом дочерний.
posix_setsid();

// Дальнейший код выполнится только дочерним процессом, который уже отвязан от консоли

В сети гуляет довольно много решений для эмуляции многопоточности в php. Чаще всего они основываются на форках, но есть и вариации на тему с использованием curl, proc_open и т.п.

Все встреченные варианты по тем или иным причинам меня не устроили и пришлось написать свое решение.
Набор требований у меня был следующий:

• Использование форков;
• Синхронный режим с сохранением интерфейса при отсутствии необходимых расширений;
• Многократное использование дочерних процессов;
• Полноценный обмен данными между процессами. Т.е. запуск с аргументами и получение результата по завершении;
• Возможность обмена событиями между дочерним процессом-«потоком» и основным процессом во время работы;
• Работа с пулом потоков с сохранением многократного использования, передачи аргументов и получения результатов;
• Обработка ошибок выполнения;
• Таймауты на выполнение работы, ожидание работы потоком, инициализацию;
• Максимум производительности;

В результате получилась библиотека AzaThread (старое название — CThread).

В статье описан функционал, который доступен в PHP (актуально для 5.3.х) для обработки ошибок всех типов, включая ошибки интерпретации кода (E_ERROR, E_PARSE, E_WARNING, etc). Эта обработка поможет вам для управляемого отображения страницы в случае возникновения таких проблем. В статье присутствует множество описаний и рабочих примеров(архитектуры) для того, что бы сразу воспользоваться в своем программном продукте. В конце концов, ну немного сломали сайт, ну надо же, об этом сообщить поисковику с заголовком 4хх или 5хх и повеселить пользователя, вместо возврата белого экрана (или что хуже экрана со священной информацией, для хакеров) с ответом 200 Ok.



Идея написать этот топик возникла, когда я на храбре задал 2 вопроса:

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

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

Если заинтересовались, то подробности под катом…

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

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

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

В проекте есть несколько разных источников данных, результаты работы которых хорошо было бы кэшировать, основной — конечно БД. Хотелось решения прозрачного, с минимальной кровью. В один прекрасный момент надоедает писать конструкции вида

$query = "Select something";
$result = $cache->get($query, $tag);
if (!$result) {
    $result = $db->queryAll($query);
    $cache->set($query, $tag);
}

И хочется чего-то другого. Конечно, код можно вынести в отдельную функцию или метод, но это как-то скучно и к тому же, для каждого разного вызова (а там есть не только $db->queryAll, а несколько разных вариантов) нужен будет свой код и своя функция/метод.

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

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

Недавно инкапсулировал свой проект в namespace и столкнулся с проблемой отсутствия нормальной документации. Все, что удалось найти датируется примерно 2009 годом, а на дворе почти 2012… В найденном материале куча нерабочих мест, использующих то, что в нынешней версии php нет. В связи с этим хочу немного осветить этот вопрос.

Про Unsafe в Java не слышал только ленивый, однако это не единственный магический класс в Sun/Oracle JDK, стирающий границы Java платформы и открывающий тропинки, не нанесенные на карту публичного API. Я расскажу про некоторые из них, принесшие пользу в реальных проектах. Но помните: недокументированные возможности лишают ваше приложение переносимости на другие Java платформы и, кроме того, являются потенциальным источником нетривиальных ошибок. Я даже зря написал слово «приложение». Лучше сказать, что описанные ниже классы вовсе не годятся для приложений! Скорее, они представляют интерес лишь для системного ПО и для любознательных программистов, т.е. для вас :)

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

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

Задача однако осложняется тем, что визуальные компоненты во флекс имеют многофазную асинхронную процедуру инициализации и обновления свойств, и для них требуется особые средства для написания тестов. FlexUnit 4 позволяет легко справляться с этой задачей, и ниже я покажу как это делать, а заодно и раскрою пару нюансов.

1. Вместо вступления.

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

Собственно, главное отличие алгоритма от, например, «наивного сравнения», заключается в том, что в его основе лежит логические операции, а именно логическое умножение (оно же AND, оно же конъюнкция).

Введение

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

Эта статья — не набор “волшебных команд” и рецептов (cookbook, как называют такие наборы по-английски), хотя они тут тоже присутствуют, а, скорее, попытка описать, как общие принципы построения эргономичных интерфейсов можно применить в практике использования Vim, чтобы сделать из него удобную и эффективную среду работы с текстами.

Эта статья также не является tutorial’ом для начинающих пользователей Vim, хотя и им (а также пользователям Emacs) может быть интересна, поскольку некоторые упоминаемые принципы являются достаточно общими и действуют не только в системах редактирования текстов, а вообще везде, где идет речь об использовании компьютера для редактирования чего-либо. Тем не менее, я предполагаю, что читатель знаком с основными концепциями, применяемыми в Vim (режимы, регистры, буфера, команды) и не останавливаюсь на их подробном описании.

По умолчанию Vim настроен очень старомодно, и эта настройка подразумевает, что пользователь при работе с текстом будет мыслить метафорами пятидесятилетней давности, как будто бы сейчас заря эпохи UNIX. Однако дизайн Vim позволяет сделать несколько настроек, после которых система станет выглядеть вполне прилично и станет работать весьма эффективно, сочетая в себе полезные черты и древних юниксовых инструментов работы с текстом, и современных WYSIWIG-процессоров, при этом обходя, насколько это возможно, присущие им недостатки. Вот об этих настройках и приемах их использования и пойдет речь.

Помню, когда я в первый раз взял в руки iPad, более всего меня поразило приложение iBooks c его натуралистичным перелистыванием страниц. Все остальные «фишки» как-то не особо впечатляли, но это… это показалось воплощением полной интерактивности. По сравнению с обычными графическими интерфейсами, использующими стандартные элементы GUI, интерфейсы с использованием анимации OpenGL это новый шаг в развитии пользовательских интерфейсов.