This blog is moving

After several years using the Blogger platform I've decided to freeze this blog and move my writing efforts elsewhere. In the last few days I've tested several options, mainly looking at Wordpress running on Openshift. But I have found Wordpress a bit overkill for a simple personal blog, so I discovered Octopress.

Octopress is a framework designed by Brandon Mathis for Jekyll, the blog aware static site generator powering Github Pages. To start blogging with Jekyll, you have to write your own HTML templates, CSS, Javascripts and set up your configuration. But with Octopress All of that is already taken care of. Simply clone or fork Octopress, install dependencies and the theme, and you're set.

The main reasons for this move are:

1. Blogger has become slow and heavy: the preview takes forever and sometimes it doesn't show up at all
2. Octopress serves static files and can be quickly tested locally
3. I can use Git for pushing all my changes and I can rollback easily
4. I want to be in total control of the typography and html
5. My main domain and blog pages are all hosted on Github

Here it is: www.maurizioturatti.com

So, goodbye Blogger.com and thank you for all the blogging fish. Welcome Jekyll and Octopress!

The Brodzinski's estimation scale for a task

Pawel Brodzinski, lean and agile coach, suggests a good estimation scale for a task:

• 1: 1
• TFB: Too Fucking Big
• NFC: No Fucking Clue

Despite the fact this could initially looks like a joke, it's actually a serious way to handle too large user stories and, from my point of view, it's very close to what has been suggested by other agile coaches like Neil Killick (My Slicing Heuristic Concept Explained), especially popular within #NoEstimates practioners.

The idea, at least at high level, is very simple: slice down your tasks until they are all more or less of the same size (1 story point), then your final estimation is just a matter of summing the total number of stories. Of course, it's easier said than done: too many misunderstand the NoEstimate practice, dismissing it as just a way to avoid the "hard work", but in reality the slicing activity forces a very accurate analysis of requirements, to be able to slim them down to a common size. The easy part is the final sum, but that's not the point.

In my opinion this method suggests that, when somebody says a user story is 5, 8 or 13 points in size, this implies a good amount of delusion, because in reality going beyond a 1, 2 or 3 size is so close to pure guessing that it is usually a waste of time. Using only a single size (one) it's even more effective, because forces a serious decomposition of tasks: if you can't achieve this level of decomposition then you should acknowledge that your requirements are not clear enough yet: drastic, but effective.

A practical approach to this kind of user stories slicing could be Gojko Adzic's hamburger method, when adding the constraint that each task composing the hamburger must be of size 1.

Many years ago I did something vaguely similar in a project: I decided that every user story had to fit into a week and every Friday was release / demo day. Not exactly continuous delivery, but I think it was even before the term "agile" was invented...

Extremely Bad Advice for Remote Workers

As I have a long-term experience as a remote worker, also dealing with and managing remote teams in different timezones, I am always interested in experiences on this subject. Today I stumbled upon an article on TheNextWeb: 3 radical habits of highly successful remote teams. Despite the article seems to be nice with remote workers, it actually contains what I think are some of the worst possibile anti-patterns for remote work. In summary:

1. Total transparency about yourself with your remote team
2. Leave your webcam on all day
3. Replace physical space with software — lots of it

Let's rephrase the meaning:

1. I don't care about your privacy at all, so I want to know even when you are sleeping or pooping ("For example, every Buffer employee receives a Jawbone UP wristband that tracks how you’re sleeping and shares that with the team.")
2. I don't trust you at all, so I want to check that you are always staring at a computer screen, all day long ("This provides a persistent, passive view of your colleagues that makes you feel like you’re in the same room, working together at the same table."). So you are even required to broadcast you scratching your nose or your privates: I can only imagine the level of anxiety!
3. Additionally, I also want to mess up with your work by asking you to install, learn an manage a lot of different software doing, more or less, the same thing ("lots of it"). So that I can annoy you from even more different angles!

I, instead, suggest the following:

1. Hire people you trust and let them organize their daily routine and priorities
2. Adopt few, useful, simple software like Skype, Google Hangout and Slack for communication, Google Docs and/or Confluence for shared documentation.
3. If you want a social life go to the gym or to the pub, switching off your mobile email notifications. Get a life outside your work.

Managing a remote team like being into a modern edition of Orwell 1984? No, thanks. A remote, distributed team is not an assembly line: I suggest to move toward measuring people by the actual value they generate instead of the time they sit in front a PC.

A team made of knowledge workers must generate tangible value: if you can do that while playing tennis or having a shower, I don't really care.

The Programmer

"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be."

Frederick Brooks, The Mythical Man Month.

The Java EE ecosystem keeps shrinking

Less than a year ago Oracle announced the Java EE and GlassFish Server Roadmap Update, which defined the end of commercial support for the Oracle Glassfish Server, which is (was) the fully supported release of the GlassFish Server Open Source Edition. In the last few months there has been plenty of comments about this move, some of the most remarkable are:

• GlassFish reduced to “toy product” as commercial offering axed
• GlassFish Commercial is Dead, WildFly and JBoss EAP to the Rescue
• Oracle removed GlassFish plugin for Eclipse

The motivation around this move are probably about Oracle not being keen on supporting two full app server implementations, Glassfish and Weblogic, which apparently makes sense from a commercial point of view. The problem here is that the two products are very different, and if you liked Glassfish usually hated Weblogic (but has somebody ever genuinely liked Weblogic anyway?). Glassfish is a lightweight, easy to install, fast to start, open source product, with a community around, while Weblogic is IMO one of the most bloated piece of software ever: the two products were addressing two very different Java EE markets, being Weblogic's the most lucrative one.

A reply to community's concerns, apparently from an Oracle representative:

"... GlassFish and WebLogic share quite a bit of code, and that helps with application and configuration portability between the two. So, organizations can continue to develop on GlassFish and leverage that development by deploying on WebLogic."

This is one of the most laughable sentences I have read in years: can anyone seriously think a company could develop and test in one application server but then deploy in production with another? Can anyone really assert that Glassfish and Weblogic are that similar? Just try to install both and judge yourself: you could start developing your first Glassfish application while Weblogic installer is still downloading...

Glassfish has always been a minor commercial player, but reducing the available options has never been a successful strategy for any ecosystem, and Oracle is supposed to lead this one. Below are the results of this leadership:

glassfish, jboss, weblogic, websphere Job Trends

Glassfish jobs - Jboss jobs - Weblogic jobs - Websphere jobs

If you care about open source but want / need to deploy into a commercially supported Java EE app server, you now have basically only a couple of options left: RedHat's JBoss EAP and Tomtribe's TomEE. Despite both are fine options, pulling out a minor but strategic member doesn't help arresting the progressive shrinking of the Java EE ecosystem, as differentiation and competition are king.

This is a pity, because Java EE is becoming more and more lean and easy.

Sales are Good for You

I have just published the below presentation on Slideshare: half it's serious content, half it's just for fun.

Some of my best friends are present or former colleagues, most are developers but many of them are sales or marketing people. I was thinking about describing the often difficult relationship between software developers and sales people since many years now. Maybe I should give a talk about this, one of these days.

I am lucky I had the opportunity to work with very smart people, both on sales or IT, with the exception of some occasional moron, of course.

Hopefully you can recognize some common, funny patterns here.

Sales are good for you from Maurizio Turatti

Book Review: "Real-time Web Application Development using Vert.x 2.0"

About Vert.x

I am following the evolution of the Vert.x project since its inception and I was expecting to see some books coming about the subject sooner or later. First of all, some explanation on what's Vert.x:

"Vert.x is a lightweight, high performance application platform for the JVM that's designed for modern mobile, web, and enterprise applications."

The product is 100% open source, licensed under the business friendly Apache Software License 2.0 and well documented. The project's founder and main maintainer is Tim Fox, of HornetQ fame.
Vert.x characteristics are nicely summarized in the related Wikipedia entry:

Vert.x is a polyglot event-driven application framework that runs on the Java Virtual Machine.

Similar environments written in other programming languages include Node.js for JavaScript, Twisted for Python, Perl Object Environment for Perl, libevent for C and EventMachine for Ruby.

Vert.x exposes the API currently in Java, JavaScript, Groovy, Ruby and Python.

Scala and Clojure support is on the roadmap.

The application framework includes these features:

• Polyglot. Application components can be written in Java, JavaScript, Groovy, Ruby or Python.
• Simple concurrency model. All code is single threaded, freeing from the hassle of multi-threaded programming.
• Simple, asynchronous programming model for writing truly scalable non-blocking applications.
• Distributed event bus that spans the client and server side. The event bus even penetrates into in-browser JavaScript allowing to create so-called real-time web applications.
• Module system and public module repository, to re-use and share components.

Few days ago I decided to purchase a recent book from Packt Publishing about the subject.

The Book

Title: Real-time Web Application Development using Vert.x 2.0

Language : English

Paperback : 122 pages

Release Date : September 2013

ISBN : 1782167951

ISBN 13 : 9781782167952

Author(s) : Tero Parviainen

I bought the eBook format only and I read it in both my iPad and computer screen, especially because the narration is mainly about building a fairly complete Web application, so I wanted to read and experiment at the same time, by entering the code by hand and running it step by step.

Below I provide a short summary of the book' sections and I will write some final comments about it.

Preface

The preface introduces clearly the content and objectives of the book

"Real-Time Web Application Development using Vert.x 2.0 will show you how to build a real-time web application with Vert.x. During the course of the book, you will go from the very first "Hello, World" to publishing a fully featured application on the Internet."

The scope is to build an editor with which people can create mind maps collaboratively. So, it is neither a too trivial application, nor something too complex. A good, balanced choice, with the additional bonus of learning a few of jQuery, D3 JavaScript library and MongoDB on the road.

What the book covers 

Chapter 1, Getting Started with Vert.x, guides you through the installation of the Vert.x 2.0 platform and its prerequisites. In this chapter, you'll also write your very first Vert.x application: the web equivalent of "Hello, World".

Chapter 2, Developing a Vert.x Web Application, covers the development of a full-fledged Vert.x web application, including both the server and browser components. You will become familiar with the architecture of a typical Vert.x application.

Chapter 3, Integrating with a Database, extends the web application from the previous chapter by adding support for persisting data in a MongoDB database, using one of the available open source Vert.x modules: the MongoDB Persistor.

Chapter 4, Real-time Communication, builds on everything you've learned so far
to deliver the secret sauce: real-time communication. You will develop a real-time, collaborative, browser-based mind map editor.

Chapter 5, Polyglot Development and Modules, presents some of the polyglot features of Vert.x, as well as the development of reusable and distributable modules,
by creating a Java module that is used to save mind maps as PNG images.

Chapter 6, Deploying and Scaling Vert.x, shows how to deploy your Vert.x application on Internet, by setting up a Linux server with continuous deployment. Finally, we discuss the basics of scaling Vert.x for growing amounts of users and data. 

My comments

One might argue that the official Vert.x documentation is already quite comprehensive and this book doesn't add much, but conversely I feel this book allows for a smoother approach to learning, without the need to browse and search too much around the Web site. Maybe somebody with already a working experience with Vert.x wouldn't gain a lot of new knowledge here, at the end I feel the book is more focused on Vert.x beginners, but anyway it contains a good amount of advanced tips to make it valuable for a wide audience.

Vert.x is a polyglot framework, so one can choose among a set of popular programming languages, with even more on the move, but the code in the book is mainly Javascript, also server side. On one hand this seems to restrict a bit the potential audience, as to fully understand the source code and the logic behind the mind map application a decent knowledge of Javascript is advisable, but on the other hand this could be very appealing to node.js developers, as they could immediately compare it with Vert.x. Then, also a client-side Javascript developer can easily follow the content and learn some server-side programming. I'm not sure on my side if I would pick Javascript for developing complex server-side logic, but adopting the same language for both client and server development undoubtedly has its own advantages, as the growing popularity of node.js testifies.

What I especially like in this book is the capacity to explain "full stack" concepts in small, easy steps. You learn about Vert.x and asynchronous message exchanges via the event bus, but also some client side programming techniques in Javascript. The bridge between client and server is built using the SockJS library, which provides real-time, full duplex, client-server communication through HTML5 WebSockets and other fallback mechanisms for older browsers.

Another plus of this book resides in its two last chapters, about modules and deployment. Chapter 5 provides a clear description of distributing and managing Vert.x applications through modules, while Chapter 6 goes into the fundamental topic of real deployment and scaling of Vert.x applications. As Vert.x applications are not distributed as standard Java EE packages, these final chapters are really a bonus and I wish to see more books that include at least some basic information about development, scaling and lifecycle management.

Conclusions

The book is very well written and readable. It is balanced, as it can support both the novice and the expert developer in exploring this excellent Web framework. I can definitely recommend buying it if you want to start studying in deep Vert.x.

Note: I actually bought this book by myself and not asked to review it by Packt or anybody else, so this article reflects my own independent opinion only.

References

• http://vertx.io/
• http://en.wikipedia.org/wiki/Vert.x
• http://www.packtpub.com/real-time-web-application-development-using-vert-x-2-0/book