ostinelli|net • Roberto Ostinelli's blog.

Simple Procedural Walk for UE4

By Roberto Ostinelli / April 26, 2021 / No Comments

In my spare time I love dedicating some energy to Unreal Engine 4. Today, I’m releasing my first UE4 plugin, Simple Procedural Walk.

I’ve had an idea for a game for quite a while (on Steam, Subtype Grounds), which basically takes you in a cooperative journey to destroy the A.I. responsible for robots taking over the world. That’s another story, but while I was animating the killer robots for this game, I found out about how procedural animations can really help in making their movement realistic and interesting, so I decided to give that a try. But… What is procedural animation?

A journey to Syn v2, a better Erlang & Elixir Process Registry and Group manager

By Roberto Ostinelli / November 18, 2019 / 3 Comments

For those who don’t know it, Syn (short for synonym) is a global Process Registry and Process Group manager for Erlang and Elixir that I’ve written a few years back. It has been around for some time now, and it has served me well on many occasions. Through the years, I’ve built up a series of considerations and ideas for improvement, and now the time has come to put all of these back into Syn.

Syn v2 has been rewritten from the grounds up, and I’d like to share the reasoning and the architectural choices behind this work. Since Syn is written in Erlang, the few portions of the code here below will show Erlang syntax. Don’t let that discourage you if you are an Elixir developer though, as the same principles apply.

Modern Erlang for Beginners: my course

By Roberto Ostinelli / March 13, 2019 / 2 Comments

I remember when I first started learning Erlang, many years ago. There was the fundamental Programming Erlang book by the late Joe Armstrong, the official Erlang documentation, some various books but what really helped me was a screencast from Kevin Smith sold on the Pragmatic Bookshelf’s website.

I am a visual learner, which means that it is much easier for me to learn with videos or by pairing with other people. So, after those years I decided that I wanted to add my little contribution to the Erlang courses that available out there.

I’m pleased to say that as per today my course is live on The Pragmatic Bookshelf. I hope it will help out those who are seeking to enter this fantastic world, or those Elixir programmers who want to understand Erlang better.

EDIT (Apr. 17, 2023): my course was retired from PragProg on Apr. 21, 2020 and moved to Udemy, but is now retired from Udemy as well.

Setting up multiple databases in Rails: the definitive guide

By Roberto Ostinelli / December 2, 2015 / 54 Comments

There are different reasons why you might consider having multiple databases in your Ruby on Rails application. In my specific case scenario, I needed to store large quantities of data representing user behavior: clicks, pages visited, historical changes, and so on.

This kind of databases generally are not mission critical, and grow much faster (and larger) than most databases. Their requirements are often different: for instance, they need more storage space, are more tolerant in the face of hardware or software failures, and are write-intensive. For these reasons, sometimes it is interesting to separate them from your application’s primary database. Often, non-RDBMS databases are chosen for these kind of tasks, something which is however beyond the scope of this article.

I googled and read many different solutions, however I couldn’t find one that was able to fully cover how to:

Have different and isolated migrations and schemas for every database.
Use rails generators to create new migrations for every database, independently.
Offer database-specific rake tasks for the most common database operations (i.e. like the ones available for the primary database).
Integrate with RSpec’s default spec task.
Work with Database Cleaner.
Work on Heroku.

This is my take on how to solve all of these – and have a fully working multiple database solution for your Rails application.

An evaluation of Erlang global process registries: meet Syn

By Roberto Ostinelli / July 6, 2015 / 9 Comments

Due to my personal interests and history, I often find myself building applications in field of the Internet Of Things. Most of the times I end up using Erlang: it is based on the Actor’s Model and is an ideological (and practical) perfect match to manage IoT interactions.

I recently built an application where devices can connect to, and interact with each other. Every device is identified via a unique ID (its serial number) and based on this ID the devices can send and receive messages. Nothing new here: it’s a standard messaging platform, which supports a custom protocol.

Due to the large amount of devices that I needed to support, this application runs on a cluster of Erlang nodes. Once a device connects to one of those nodes, the related TCP socket events are handled by a process running on that node. To send a message to a specific device, you send a message to the process that handles the devices’s TCP socket.

While building this application, I was early in the process faced with a very common problem: I needed a global process registry that would allow me to globally register a process based on its serial number, so that messages can be sent from anywhere in the cluster. This registry would need to have the following main characteristics:

Distributed.
Fast write speeds (>10,000 / sec).
Handle naming conflict resolution.
Allow for adding/removal of nodes.

Therefore I started to search for possible solutions (which included posting to the Erlang Questions mailing list), and these came out as my options:

Erlang’s global module.
Erlang’s pg2 module.
Gproc.
CloudI Process Groups.
Roll out a custom solution.

How to build a Rails API server: Optimizing the framework

By Roberto Ostinelli / June 23, 2015 / 12 Comments

I have been developing Rails JSON API applications for quite some time now, and I’d like to share a few of my setups and discuss why I do things this way. I’m starting today a series of articles that will cover up pretty much the steps I take every time I bootstrap a new Rails JSON API application.

One of the first things I do is to ensure I’m optimizing Rails for speed. I basically optimize the framework itself, prior coding any specific application logic.

You may have heard before that “Premature optimization is the root of all evil“. However, “Premature optimization is a phrase used to describe a situation where a programmer lets performance considerations affect the design of a piece of code”, which “can result in a design that is not as clean as it could have been or code that is incorrect, because the code is complicated by the optimization and the programmer is distracted by optimizing” (source: WikiPedia). This is not what we’re doing here: we’re just going to apply a few changes to Rails, and then basically forget about those and start coding in a framework that is optimized to serve our API.

Many of Rails functionalities are simply not needed when building an API server, and by stripping down Rails to a bare minimum we can actually achieve pretty significant performance increases.

GIN: a JSON-API framework in Lua

By Roberto Ostinelli / June 18, 2015 / 3 Comments

GIN is a fast, low-latency, low-memory footprint, web JSON-API framework with Test Driven Development helpers and patterns. It is a framework that I open sourced some time ago, as an experiment.

It all started when I heard so many good things about Lua that I wanted to see it in action and find a project where I could unleash its power. Being an API fan, it came natural for me to build a JSON-API server framework. And GIN was born.

GIN is currently in its early stage, but it already enables fast development, TDD and ease of maintenance. It is helpful when you need an extra-boost in performance and scalability, since it is entirely written in Lua and it runs embedded in a packaged version of nginx called OpenResty. For those not familiar with Lua, don’t let that scare you away: Lua is really easy to use, very fast and simple to get started with.

Controllers

The syntax of a controller is extremely simple. For instance, a simple controller that returns an application’s version information looks like:

local InfoController = {}

function InfoController:root()
    return 200, { id = 'my_api', description = 'An API server powered by GIN.' }
end

return InfoController

local InfoController = {}

function InfoController:root()

return 200, { id = 'my_api', description = 'An API server powered by GIN.' }

end

return InfoController

The return statement specifies:

The HTTP code 200
The body of the response, which gets encoded by GIN into JSON as:

{
  "id": "my_api",
  "description": "An API server powered by GIN."
}

{

"id": "my_api",

"description": "An API server powered by GIN."

}

Most of standard JSON-API paradigms are already embedded in GIN.

A comparison between Misultin, Mochiweb, Cowboy, NodeJS and Tornadoweb

By Roberto Ostinelli / May 9, 2011 / 61 Comments

As some of you already know, I’m the author of Misultin, an Erlang HTTP lightweight server library. I’m interested in HTTP servers, I spend quite some time trying them out and am always interested in comparing them from different perspectives.

Today I wanted to try the same benchmark against various HTTP server libraries:

Misultin (Erlang)
Mochiweb (Erlang)
Cowboy (Erlang)
NodeJS (V8)
Tornadoweb (Python)

I’ve chosen these libraries because they are the ones which currently interest me the most. Misultin, obviously since I wrote it; Mochiweb, since it’s a very solid library widely used in production (afaik it has been used or is still used to empower the Facebook Chat, amongst other things); Cowboy, a newly born lib whose programmer is very active in the Erlang community; NodeJS, since bringing javascript to the backend has opened up a new whole world of possibilities (code reusable in frontend, ease of access to various programmers,…); and finally, Tornadoweb, since Python still remains one of my favourites languages out there, and Tornadoweb has been excelling in loads of benchmarks and in production, empowering FriendFeed.

Misultin: erlang and websockets

By Roberto Ostinelli / January 20, 2010 / 9 Comments

Inspired by Joe Armstrong’s post, I’ve recently added websocket support to misultin v0.4, my Erlang library for building fast lightweight HTTP servers.

Basically, websockets allow a two-way asynchronous communication between browser and servers, filling the gap that some technologies such as ajax and comet have tried to fulfill in these recent years. If you want to try this out yourself, you will first need to grab a browser which implements websockets, such as Google Chrome.

Misultin library

By Roberto Ostinelli / July 27, 2009 / No Comments

Today I’ve released Misultin (pronounced mee-sul-teen), an Erlang library for building fast lightweight HTTP servers. The first benchmarks are quite satisfying, even though there still is work to do.

Here is the simple code for Misultin’s Hello World.

-module(misultin_hello_world).
-vsn('0.1').
-export([start/1, stop/0, handle_http/1]).

% start misultin http server
start(Port) ->
    misultin:start_link([{port, Port}, {loop, fun(Req) -> handle_http(Req) end}]).

% stop misultin
stop() ->
    misultin:stop().

% callback on request received
handle_http(Req) ->
    Req:ok("Hello World.").

-module(misultin_hello_world).

-vsn('0.1').

-export([start/1, stop/0, handle_http/1]).

% start misultin http server

start(Port) ->

misultin:start_link([{port, Port}, {loop, fun(Req) -> handle_http(Req) end}]).

% stop misultin

stop() ->

misultin:stop().

% callback on request received

handle_http(Req) ->

Req:ok("Hello World.").

Boost message passing between Erlang nodes

By Roberto Ostinelli / April 7, 2009 / 44 Comments

Message passing between Erlang nodes is considerably slower than within the same node. This is normal, and is due to the fact that messages sent between nodes are actually copied from the area of the sender to that of the receiver, then sent over from one node to the other via TCP/IP.

I was getting interested when a server could achieve amazing performance over a single node, performance which got much lower once the server got distributed over two Erlang nodes. I therefore tried a small benchmark test to somehow measure the difference in message passing speed within/across Erlang nodes.

OpenSpime

By Roberto Ostinelli / June 10, 2008 / 1 Comment

OpenSpime is a protocol, an open XMPP custom extension enabling physical devices to communicate. It has been written with the Internet of Things in mind.

A Technical Introduction to OpenSpime

The Composite Intelligence of Virtual Assistants

By Roberto Ostinelli / October 10, 2007 / 1 Comment

As early as 1968, influenced by visionary movies such as Stanley Kubrick’s 2001: A Space Odyssey, with its fictional computer character HAL 9000, we envisioned omniscient, intelligent machines that could easily contain the whole range of human knowledge. Then, in 1987, the Knowledge Navigator video from Apple Computer struck our imaginations and greatly boosted our expectations of what computers would be able to do for us in a few years’ time.

It is now 20 years later, but technology is still very far from fulfilling such hopes regarding virtual assistants:

Voice recognition isn’t immediate.
People adapt to machines’ lexicons rather than the other way around.
Computers cannot easily transcend the scope for which they have been programmed.
Self-learning machines are still experimental.
The generation of high-quality graphics representing emotionally rich, 3-D avatars is far from being real time, cheap, or extensively available.

The technology for fulfilling such high expectations simply does not yet exist. However, while we wait for technology to catch up with our dreams, the gap between our expectations and the reality of what we can now achieve has inspired two important trends in the development of virtual assistants:

simulation of generic conversations
application-specific virtual assistants

Roberto Ostinelli's Blog

Controllers

A Technical Introduction to OpenSpime