Phoenix Framework: the assets pipeline


From the time I wrote part 1
of this short series, Atom has gained a new Elixir plugin based on Samuel Tonini’s Alchemist Server.
From the Emacs plugin, it inherits all the most notable features such as
autocomplete, jump to definition/documentation for the function/module under
the cursor, quote/unquote code and interactive macro expansion.
A feature reference along with some screenshots can be found at the atom-elixir page.
It also looks pretty good.

The assets pipeline

Assets pipelines are one of the most important features in modern web frameworks.
When working on this task, Phoenix developers have proven that they value
pragmatism over purity and have chosen to base their implementation on Brunch, a Node.js build tool that takes care of everything
related to assets management.
This choice has probably saved man-years of work, that would have inevitably delayed the release of a fully working pipeline system.
A very common counter argument is that this adds node as a dependency, but I
think it’s a negligible inconvenient, node is most probably already present on
the majority of developers machines.

Continue reading “Phoenix Framework: the assets pipeline”

Phoenix, to the basics and beyond.


Phoenix is the exciting new kid on the block in the vast world of web frameworks.
Its roots are in Rails, with the bonus of the performances of a compiled language.
This isn’t exactly a getting started guide, but a (albeit short) list of things you’ll have to know very soon in the process of writing a Phoenix application, that are just a bit beyond the writing a blog engine in 15 minutes by using only the default generators.
I assume previous knowledge of the Elixir language, the Phoenix framework and the command line tools

Continue reading “Phoenix, to the basics and beyond.”

Writing Ruby extensions in Go – an in depth review

For a very long time the only way to extend Ruby with native estensions has been using C.
I don’t have the numbers with me, but I guess C is not the first choice for Ruby programmers when they have to pick up a secondary/complentary language.
So I started investigating the possibility of writing them in other languages, taking advantage of the favorable moment: in the past 3-4 years we had an explosion of new languages that compile down to native code and can be easily used to produce a C equivalent shared library that Ruby can pick up and load.

My main goal was to find languages that a Ruby programmer would understand effortlessly or with a minimum investment.
This first episode will focus on Go.

Continue reading “Writing Ruby extensions in Go – an in depth review”

A month with Atom: my first package

Exactly one month ago, Github relaesed version 1.0 of their open source editor Atom.
Giovanni already blogged about it, from the perspective of a long time Emacs lover: Atom still has a long way to go, but he also admitted that

There are several things going for Atom though. Coffeescript is a more popular language than Lisp, also, I know it better, so writing my own Atom extensions won’t be as hard as writing my Emacs extensions.

I’ve never been proficient enough with Lisp to write a package for Emacs, and Vimscript is really too hackish for the undisciplined developer I am.
I know Javascript better, but I don’t love it.
Atom packages can be written in Coffeescript, a language that I really enjoy.
Language alone is surely not enough to declare that writing a package is going to be easy, but it gave me the confidence to try.

Our package will be very simple: it will put a live clock on the right side of the status bar that can be toggled on and off.

Continue reading “A month with Atom: my first package”

Regexes: the Bad, the Better, and the Best

Regexes: the Bad, the Better, and the Best

Integrate Meteor with Kendo UI

At the end of last year I’ve been involved in a testdrive project aimed to explore the possibility of replacing good old desktop applications with modern web applications, a demanding task, but nonetheless a fun one.

The client gave me complete freedom to chose whatever technology I wanted, except for some key elements, one of them was Kendo UI, a widget library they had been testing for a while with an impressive list of features and components.

On my side I’ve decided to put Meteor on test, I confess, I’m not the biggest Javascript fan around, but I’ve rarely felt so confident with a new platform like I’ve been with Meteor, so I went for it.
The biggest advantage Meteor gave us was speed, we’ve been able to put together an incredible (IMHO) amount of work in a very short period of time.

Long story short: the project was a success, everything was good, we also had the opportunity to experiment on the infrastructure side, and I’ve learned a lot in those few months, about things I could never have accessed otherwise.

There was only one small glitch that constantly bugged me: the integration between Meteor and Kendo, especially in regards to reactivity.

Meteor might not be the new kid on the block anymore, but it’s not the well established framework either: there was no official Telerik package for Meteor, and I had to roll my own, learning by doing.

Continue reading “Integrate Meteor with Kendo UI”

GitBook · Write & Publish Books

GitBook · Write & Publish Books