Easily Install Docker on OS X

I tried recently to install docker on my mac. The problem with the mac port is that it needs a VM that runs linux to properly execute it locally. I found this guide.

In short, it uses a Virtual box image to run the app. The whole process can be simplified by using homebrew. Just execute the following commands on a console:

brew update
brew tap phinze/homebrew-cask
brew install brew-cask
brew cask install virtualbox
brew install docker
brew install boot2docker
boot2docker init
boot2docker up

… then export the three environment variables and you are ready.

Note: The default image size created by boot2docker has only 4GB hard disk space. Make sure that you have all the required parameters in place when you launch your docker instance, since later on it’s a fuss to resize the HD. ūüôā
Note 2: I think that docker is a dependency of boot2docker, so you really need to install boot2docker only.


Revenge of the SQL

The mainstream is always under attack. So is SQL and in general the various RDBMSs that implement its various incarnations. After the golden age of MySQL and the LAMP (Linux-Apache-MySQL-PHP) stack, various NoSQL databases appeared, preaching that the data storage as we knew it was coming to an end.

The Crusade

Everyone thought back then, that the web applications could not benefit from data with strongly enforced relations and the query language for these systems; SQL was complex and introduced overhead in terms of performance and security with the infamous SQL-injection attacks.

In addition, every programmer I know (even me) was tempted to join the crusade against the RDBMS and the SQL. At first, the problem was solved with ORMs, which mapped the database entities to specific programming language abstraction elements, such as classes. After that, millions of lines of code were written for support tools, and IDEs, all of course in the name of the crusade.

The Elusive Holy Grail

Even with all this effort and resources, the problem was in fact recursive. SQL is a Domain-Specific Language (DSL), which in plain English means that it focused on a specific problem domain. General-Purpose Languages (GPL) like Java, C++ and Python, could never offer the richness of any DSL, focused to expressed queries on data entities. Since ORMs offered abstractions on the GPLs, other query languages were designed to offer querying capabilities on the mapped objects. Programmers got rid of the SQL and the interaction with the RDBMS, but instead they had to learn new exotic variations of query languages, which in the end suffered from the same set of problems.

The NoSQL approaches were successful, but their usage is misjudged. NoSQL databases are perfect to solve specific types of problems, but they are not here to replace RDBMS systems.

The Empire Strikes Back

It seemed that the big players that provide infrastructure (IaaS/PaaS) noticed that RDBMSs are an irreplaceable piece of technology; thus they start offering turn-key solutions on their platforms, like Heroku postgres service and Google Cloud SQL.

On the language front, it seems that the problem was not the SQL, but the way the programmers interacted with it. Next generation languages like Scala and Java 8, offer libraries like Anorm, Slick and JOOQ that offer enhancements on the interaction between these languages and SQL, providing compile-time error detection in queries and out-of-the-box optimisations.


History shows that SQL and RDBMSs are here to stay. Of course new, related technologies were invented and will be in the future, but they will never be replaced.

Revisiting Java Layout Managers

As a developer I always revisit the following three problems:

  1. Find a proper IDE for each language (ok, sublime text rocks, but sometimes you need something more sophisticated)
  2. Find a cross-platform language to develop desktop application
  3. Find the best version control system for source files
  4. Find the best tool to automate software building and testing process

So far, I have a clear choice only for the #3, which is Git :). So that leaves me with #1, #2, #4. In this post we will discuss #2, since #1, #4 are really complex topics and cannot be easily covered.

For the last 18 years (time flies, oh yeah), I try to find a proper tool to create cross-platform desktop applications. Why I need that? Many of my clients need an administration tool (and yes I hate the web, so HTML-stuff is out of the picture) and they usually have a combination of Macs and PCs. It seems that the windows-dominance era passed for good.

For UI editing I used the following platforms, namely; Delphi -> Windows C API -> Java (AWT) -> Java (swing) -> C# -> XUL -> C# -> HTML/CSS/JS -> C#.

Do you notice a pattern? Yes, I revisited many times C#, which is by far the most sophisticated IDE to write UI applications. But it has one problem, it works only for the Microsoft universe, thus we are back in square one.

After lots of thought and experimentation, I tried several Java tool for RAD UI construction. Ok, officially the tools are bad. Yes real bad. Their developers should download visual studio 2003 -> 2013 and learn real IDEs are made, at least from that perspective.

I decided that I would be more productive if I wrote stuff by hand, than using any of those tools. So, layout managers is the answer to that. Of source, Java has plenty, and there are a few third party around, if you make the usual google-based-keyword round.

In addition to JGoodies, and MIG layout, I also found HTMLLayout and a set of various layout managers , which are open source and seem abandoned also.

So this is my decision (for the time being), Java but with manual UI construction using anything I can found as open source library on the web.

To that end I created a github repository name java-layout that will host all these resources. Recently, I added the htmllayout project, which I refactored, since it seems abandoned. In the future I plan to add some more stuff, regarding Java UI construction.

ps. Yes I know all about JavaFX. The concept is simple, I do not add ant library etc, if it does not have significant added value to the development process.

First Rule of bkarak (me) of Computer Programming

My one (and only) so far rule of Computer Programming:

If a typical programmer can write a program in 100 lines of code, a bad programmer will need 120 lines, a good programmer 80 lines. But this is it, no programmer can write a shorter program.