At my job we recently started researching logging tools to make our RESTful API, written in Clojure, writing logs in JSON format. We were using Log4j already, but decided to use another tool for this task, making it less painful. So we felt into timbre. Is seemed so easy to use, but it is really undocumented.

According to timbre’s API, we needed to define our own appender for writing to a custom JSON file. And we found the output-fn option to configure this behaviour. But it is not documented at all, so we started looking for repositories, using timbre, examples and all the stuff. And finally, we ended up with our own solution.

Underneath you will find description of our way to use timbre from scratch.


How do we usually create a web application? We run a bootstrapping script, which provides us with a skeleton of our application and then we just extend it with the features we need.

That’s exactly what we did at the last hackathon we were attending - we started with rails new twf and spent half of the day integrating our blank app with Angular, Paperclip, creating API methods and so on. But the effort we needed to accomplish our goal (quite a simple web app) was really huge.

So I decided to find the best combination of backend and frontend technologies that would cause less pain.

At the project I was recently introduced to, the line between frontend and backend is distinguished very clearly: we have an API, written in Clojure and thin frontend application, made with Angular that works on a generated set of static assets - HTMLs, CSS and JS files (but under the hood we are using HAML and SCSS).

The application I will be implementing throughout the whole article has the same architecture: it has RESTful API and MVVM on the frontend, made with Angular. I welcome you to the journey of research and new technologies!

At my work we’ve lately been having a discussions on email validation. I recalled a post on habrahabr, showing different options, including effective and psycho solutions.

At this point we have an application with

  • 1x Ninja, walking around
  • 1x sphere, hanging in the center of the screen
  • 1x cube, flying around the sphere

That’s our “game”? Doubtely… So let’s make things move like in real world! Or just like that…

Aug 28, 2015

First script

As we discussed, we will describe the whole game in scripts, and the core functionality we will define in the core. In this chapter we will be adding Lua to our application. You do not need to download Lua itself - you’d better install it with your system’s package manager (yum or apt or whatever your Linux uses, brew for OSX…).

Aug 27, 2015

First application

Install Irrlicht

First of all, you will definetely need the Irrlicht engine, so go get it.

Now, you need to compile it. Compilation process depends on the operating system you use, but it’s really similar everywhere.

Positive thinking is a good-to-have when starting something =)

Basic rules

Let’s talk a bit about our application before we create it - let’s make some planning! We will think of our application at least as of well-designed one. So what is the application architecture? Not just a game, but any application? It’s the way developer split its parts, divided classes, modules, variables, entities and other pieces of application, packing them into separate units and defining how they will interact. So that any new improvement or change to the application does not make one feel sick at the task definition stage.

But how about a game? What the good architecture of a game looks like? Do we need to separate one 3D models from others? Or does that means writing each quest in a separate *.cpp file? No-no-no. That means we should create such an application, so that any new quest, model or even a text change will not require us to re-compile the damn bunch of code for hours or look for a places, where that particular model or text is used and changing it everywhere in the source code.

I assume our game to have a stable, rarely changed core, a set of assets (models, textures, sounds - any content, made by artists and used to be presented to the player) and a bunch of scripts, defining all the logic of a game - how character looks like, how the menus are shown and how they react to player’s actions, how objects in the game world behave and how that world looks like and all the stuff. The main criteria here are:

  1. scripts and assets may be changed at any time
  2. scripts and assets define the whole game
  3. none of the changes to scripts or assets force us to re-compile game core

Basically, we can make the core so flexible, we may use it in any game. Or we may want to create a GUI editor to create scripts in more handy way. But that requires much more work. And there is never a limit to make something better. So currently we will not advance that much.

Aug 25, 2015


What will you learn?

This tutorial covers the development of a game from the very beginning. This includes:

  • creating game architecture
  • writing game engine
  • making game logic with scripts
  • creating assets
  • and deployment

And of course, the whole tutorial is built around two libraries - Irrlicht and Newton Game Dynamics.

As for now (19 Mar 2018), the tutorial covers an introduction to NewtonGD, Irrlicht, Lua, CMake and combining all of them into one sample application.

Why writing everything from scratch? Why not just use XXX?

The main reason why this tutorial was written, especially due to the fact there are couple of well-known and actively discussed/developed/used game engines like Unreal Engine 4, Unity 3D and others, is: there is still a need for developers, knowing not only how to make a game using given tools, but how the game or even those tools are made underneath.

What should I know to proceed?

You are required to have at least some experience with C++, basic knowledge of graphics and game development (just to make sure, you will not call assets “textures” or miss the “script” word’ meaning =) ).

If you are interested - then welcome!


Last time I wrote an article on how one can encapsulate both HTML and CSS in one entity, called WebComponent. This time I want to tell a bit about how to encapsulate JavaScript and HTML.

When I see an article on Habrahabr titled React something, I think Omg, React again?... But React, just as Ember was always a mystery for me.

Until today.

Мій друг запитав мене сьогодні “а от ці всі асемблери, їм взагалі є застосування?”. Самому мені було важко вигадати застосування асемблера сьогодні. Тому для нього (і для себе також) я вирішив перекласти частину вступу з матеріалів мого ВУЗу з предмету “низькорівневе програмування”.
Навіть не зважаючи на те, що я вже писав про можливе застосування ассемблера.