August 30th, 2012
After almost a year of hard working we’ve finally started the closed beta testing of the Facebook version of the Western Story Game!

Western Story is the game where Old West is as real as it gets. You’ll deal with courageous cowboys, noble Indians, brave settlers and ravenous cattlemen, virtuous lawmen and ruthless outlaws.
Keeping our fingers crossed and getting prepared for fighting with tons of bugs and glitches
By the way, if you are interested you can join the beta testing group and play the game!
P.S. The game will also be available for mobile phones and tablets shortly after the stable release on Facebook.
Posted in facebook, westernstory | No Comments »
August 30th, 2012
Writing cross-platform scripts is really painful and sometimes one has to find workarounds for shell commands which simply don’t work as expected on some platforms. One of such cases is usage of tar xzf command on Windows.
There is an excellent port of some *nix utils for Windows - UnixUtils. It has the tar utility, however, it doesn’t support the compression (via x or j flags).
One of our PHP batch scripts contained the following snipped which wouldn’t work as is on Windows:
$cmd =
"tar xzf " . escapeshellarg(realpath($arch_file)) .
" -C " . escapeshellarg(realpath($out_dir));
system($cmd, $ret);
The good news is UnixUtils has the gzip utility so we can rewrite the code above as follows:
$tar_file =
str_replace(".tar.gz", ".tar", realpath($arch_file));
$cmd =
"cd " . escapeshellarg(dirname(realpath($arch_file))) . " && " .
"gzip -d " . basename($arch_file) . " && " .
"cd " . escapeshellarg(realpath($out_dir)) . " && " .
"tar xf " . escapeshellarg($tar_file);
system($cmd, $ret);
The main idea is : a) decompress the archive into a regular tar file using the gzip utility b) “untar” the resulted tar file
Apart from that on Windows tar doesn’t understand absolute paths (I believe, it has something to do with the drive letter in the beginning of the path). For this reason absolute paths are better to be avoided in UnixUtils commands. The trick is to cd to the required directory and issue commands using relative paths from there.
Posted in automation, windows, *nix, administration | No Comments »
October 22nd, 2011
We are using APC cache very heavily in our projects and during project deployment the cache must be flushed and warmed up. A common solution to warmup the APC cache is to fetch some special page via HTTP which does the job.
The problem with this approach is that it’s not reliable enough when PHP is served via several fastcgi back-ends. You may actually never know which back-end is going to serve your HTTP request. And I needed a solution which would warmup caches on every PHP back-end for sure.
For this reason I extracted some fastcgi related bits from the Nanoweb PHP web server and created a phpfpm module which allows to directly talk to the fastcgi via socket and execute arbitrary PHP scripts. Here’s the usage example:
<?php
include("phpfpm.inc.php");
$filename = "/path/to/project/bin/apc_warmup.php";
$response = phpfpm_request("localhost", 9000, $filename);
var_dump($response);
Note, it was tested only with php-fpm so I’m not sure if it’s going to work with anything else. The code of phpfpm.inc.php is quite “hackish” but, hey, it does its job
Posted in php-fpm, fastcgi, *nix, php | 5 Comments »
October 13th, 2010
I created a small PHP library taskman for writing project related tasks in a similar with Ant and rake fashion.
There is a lib-taskman project on the google code hosting where you can find the full documentation, sources and latest releases.
It’s probably not that elegant as rake but if you want to stick to PHP and have Ant-alike functionality without any XML programming then taskman may turn out to be handy. taskman is very simple to use, it requires only one include, all its code resides in one PHP file, and it has no external dependencies.
Here is the simplest usage example.
- Download and unpack the archive.
- Put taskman.inc.php to some place where you can include it from(I personally tend to bundle this script with every project).
- Create a task.php script with the following contents:
<?php
require('taskman.inc.php');
taskman_run($argv);
function task_hello()
{
echo "Hello\n";
}
function task_comma()
{
echo ",\n";
}
/**
* @deps comma
*/
function task_world()
{
echo "World\n";
}
/**
* @deps hello,world
*/
function task_say($args = array())
{
if(isset($args[0]))
echo $args[0] . "\n";
}
You can run this script now in the command line as follows:
>php task.php say Whatever
************************ Running task 'hello' ************************
Hello
************************* 'hello' done (0 sec.)*************************
************************ Running task 'comma' ************************
,
************************* 'comma' done (0 sec.)*************************
************************ Running task 'world' ************************
World
************************* 'world' done (0 sec.)*************************
************************ Running task 'say' ************************
Whatever
************************* 'say' done (0 sec.)*************************
************************ All done (0 sec.)************************
You might be wondering what these “project related tasks” are. There can be lot of them: build the sources, bootstrap database, auto-generate code, migrate database schema, deploy project onto remote servers, etc. Maintenance of such tasks can become pretty tedious at some moment. Furthermore, some tasks may depend on other task, e.g. you can not build the sources without running code auto-generation task first.
P.S. Looks like there is a similar PHP solution called pake. The biggest difference between taskman and pake is the way tasks are specified. In case of taskman one has to prefix task functions with task_ keyword while in pake one has to register tasks explicitly using pake_task(..) function. Furthermore, in taskman one attaches task meta information using a PHPDoc block while in pake one should use separate functions, e.g. pake_desc(..).
P.P.S As David noted in comments there is also a Phake project which has, I believe, the strongest resemblance with rake thanks to new PHP-5.3 only features(e.g closures). Some of its ideas I’m going to borrow for taskman2 which will be PHP-5.3 only as well.
Posted in automation, php | 8 Comments »
October 4th, 2010
Continuing my flash automation saga this time I’m going to blog about a fla2swf utility, as I promised in the previous post about fcshd. You can grab it in the downloads section of the flash-automation project.
fla2swf is a command line utility written in PHP which can be used in a batch mode for publishing .fla files to .swf. It consists of the client and server parts. The cool thing behind this utility is the fact the client can be run on the box without Flash IDE installed(even on the *nix box). Of course, you will need the server to be run on the workstation with the Flash authoring environment installed.
Read the rest of this entry »
Posted in flash, automation, php | 1 Comment »
September 28th, 2010
For the impatient
fcshd is a convenient command line PHP based wrapper around fcsh shell. It works both in *nix and Windows. You can grab it from the downloads section of the flash-automation project. Just unzip it, enter the directory and run “php fcshc.php” in the shell to get the basic usage help.
Read the rest of this entry »
Posted in flex, fcsh, flash, automation, php | 3 Comments »
September 24th, 2010
I really like the FuzzyFinder vim plugin. In short, it allows to search quickly for files, tags, buffers, etc using fuzzy logic.
I especially like it for its ability to find files recursively using simple patterns. However, by default FuzzyFinder is not really convenient because it searches for files relative to the current working directory in vim. And what I want is to be able to search for files recursively relative to some project’s root directory at any moment from any buffer.
Of course, it’s possible in FuzzyFinder to use “../../**”-alike patterns in order to make it search recursively starting from upper directories. But it’s quite boring. It’s especially painful for those folks(me included) who have vim settings which change the vim cwd to the one where the opened file resides.
Some folks may suggest using the Project plugin which allows to setup the global cwd for each project. But that’s too much of a hassle to my humble opinion. There should be a simpler way 
Read the rest of this entry »
Posted in vim | 1 Comment »
September 6th, 2010
The game I’m currently working on is now officially available on the Russian social service odnoklassniki.ru (quite popular in Russia and somewhat similar to linkedin). Hope our servers can handle the load 
Posted in zveriki, gamedev | No Comments »
March 28th, 2010
Short story
Use -fpch-preprocess option alongside with -c option in order to make precompiled headers work properly.
Update: I asked the same question on the gcc help mailing list and Ian Lance Taylor explained this strange behavior by my usage of distcc/ccache. These tools first preprocess the source that’s why this options is required.
Long story
I’m using gcc-4.4.1 on Linux and before trying precompiled headers in a really large project I decided to test them on a simple program. They “kinda work” but I was not happy with results and I was sure there was something wrong about my setup.
Read the rest of this entry »
Posted in pch, gcc, c++ | No Comments »
January 8th, 2010
For the impatient
Ok, here is what you have to do on your Ubuntu box:
$ sudo apt-get install rcs
$ vim ~/.hgrc
… and put the following lines somewhere into your ~/.hgrc
[merge-tools]
merge.priority = 100
Read the rest of this entry »
Posted in mercurial, subversion | No Comments »