No more Hibernate? Really?

September 22nd, 2013 11 comments

I recently stumbled upon this punchy one-liner: “No More Hibernate!“.

At first, I couldn’t believe what I read. Then, scrolling down, I noticed that the site was linked to jOOQ, a framework that advocates for SQL to have a first-class status in Java:

SQL was never meant to be abstracted. To be confined in the narrow boundaries of heavy mappers, hiding the beauty and simplicity of relational data. SQL was never meant to be object-oriented. SQL was never meant to be anything other than… SQL!

So the jOOQ people do not like Hibernate, EclipseLink and JPA, and prefer writing SQL albeit in Java syntax. I couldn’t swallow this statement and thought about this article. Anyway, its final form is somewhat different from the flaming I originally intended.

I don’t remember fondly the time when I had to write SQL by hand. Perhaps I lost my ability to understand SQL when I understood Object-Oriented Programming? Sure, I wrote once or twice monster PL/SQL scripts, but beyond that, I struggle to write queries with more than 2 joins. And it really bothers me to concatenate strings to create queries with optional parameters.

When I discovered Hibernate – 7 years ago, I could only think: “Wow, these guys understand exactly what is wrong with plain JDBC!”. Since that time, there has been myBatis (formerly iBatis), more Hibernate versions, JPA v1, JPA v2, and so on. It isn’t as if SQL was really welcomed in the Java world… So, who is foolish enough to challenge this?

After letting some background thread digest this “No more Hibernate” stuff, some facts came back to the surface. In particular, do you have ever been in a interview with a candidate proudly displaying Hibernate skills on his CV? For me, it usually goes like this:

  • First question: “Could you describe the reason behind LazyInitializationException?”
  • Second question: “Ok, what’s the difference between eager and lazy loading?” <…>
  • When candidates answer both questions correctly – and that’s not so common, my third question is something along: “What’s your way of avoiding those exceptions?”

At this point, given the fraction of matching candidates, I’m to the point of accepting nearly every answer, even some I’m strongly against, such as the OpenSessionInViewFilter.

Dare I also mention the time I had to review an application code and discovered that each and every attribute was eagerly loaded? Or when I was asked to investigate an OutOfMemoryError in staging but only when logging was activated? Thanks to Dynatrace, I discovered that Hibernate entities all inherited from an abstract class that overrode toString() to use introspection to log every attribute value. To be honest, I had showed this trick to the developer earlier to use when debugging, I wouldn’t have thought he would log entities.

And those are things I know and understand; I’m also aware of more Hibernate’s pitfalls: please check this awesome presentation, by Patrycja Wegrzynowicz to realize its overall scope.

On one hand, Hibernate really rocked the JDBC world, on the other hand, it really set the developer skills bar higher. Even if “No more Hibernate” is really too strong for my own taste, I guess having a look at your team skills and knowledge before choosing your DAO technology stack can go a long way toward meeting your project deadlines and avoiding bad surprises in the later stages.

Categories: Java Tags: , ,

On the merits of verbosity and the flaws of expressiveness

September 8th, 2013 2 comments

Java is too verbose! Who didn’t stumble on such a rant on the Internet previously? And the guy bragging about [Insert expressive language there], that which soon replace Java because it is much more concise: it can replace those 10 lines of Java code with a one-liner. Ah, the power!

Unfortunately, in order to correlate conciseness with power (and verbosity with lack of power), those people take many shortcuts that once put into perspective make no sense at all. This article aims to surgically deconstruct such shortcuts to expose their weaknesses. And because I like a factual debate – and because there are not only trolls on the Internet, this post will be linked to Andy Petrella’s different point of view.

Verbose is not bad

Having more data than necessary prevents messages corruption by indirect communication. Here are two simple but accurate examples:

  • In network engineering, there’s a concept of DBIt or Delivery Confirmation Bit. It is just a summary of all 0 or 1 of the current sequence and guarantees the delivered packet has been transmitted correctly, despite not-so-adequate network quality.
  • In real-life, bank accounts have a 2-digits control key (at least in most European countries I know of). Likewise, it is to avoid wiring funds to a erroneous account.

It’s exactly the same for “verbose” languages; it decreases probability of understanding mistakes.

More concise is not (necessarily) better

Telling that one-liner are better than 10 lines implies that shorter is better: this is sadly not the case.

Let us take a code structure commonly found in Java:

public List<Product> getValidProducts(List<Product> products) {

    List<Product> validProducts = new ArrayList<Product>();

    for (Product product : products) {

        if (product.isValid()) {


    return validProducts;

In this case, we have a list of Product and want to filter out invalid ones.

An easy way to reduce verbosity is to set everything on the same line:

public List<Product> getValidProducts(List<Product> products) { List<Product> validProducts = new ArrayList<Product>(); for (Product product : products) { if (product.isValid()) { validProducts.add(product); } } return validProducts;}

Not concise enough? Let’s rename our variables and method obfuscated-style:

public List<Product> g(List<Product> s) { List<Product> v = new ArrayList<Product>(); for (Product p : s) { if (p.isValid()) { v.add(p); } } return v;}

We drastically reduced our code verbosity – and we coded everything in a single line! Who said Java was too verbose?

Expressiveness implies implicitness

I already wrote previously on the dangers of implicitness: those same arguments could be used for programming.

Let us rewrite our previous snippet à la Java 8:

public List<Product> getValidProducts(List<Product> products) {

    return -> p.isValid()).collect(Collectors.toList());


Much more concise and expressive. But it requires, you, me and everybody (sorry, I couldn’t resist) to have a good knowledge of the API. The same goes for Scala operators and so on. And here comes my old friend, the context:

  • The + operator is known to practically everyone on the planet
  • The ++ operator is known to practically every software developer
  • The Elvis operator is probably known to Groovy developers, but can be inferred and remembered quite easily by most programmers
  • While the :/ operator (aka foldLeft()) requires Scala and FP knowledge

So from top to bottom, the operator requires more and more knowledge thus reducing more and more the number of people being able to read your code. As you write code to be read, readibility becomes the prime factor in code quality.

Thus, the larger the audience you want to address, the more verbose your code should be. And yes, since you will not use advanced features nor perfect expressiveness, seasoned developers will probably think this is just average code, and you will not be praised for your skills… But ego is not the reason why you code, do you?


In this article, I tried to prove that “Less is more” does not apply to programming with these points:

  • Verbosity prevents communication mistakes
  • Spaces and tabs, though not needed by the compiler/interpreter, do improve readibility
  • Expressiveness requires you and your readers share some common and implicit understanding

I will be satisfied if this post made you consider perhaps verbosity is not so bad after all.

Now is the time to read Andy’s post if you didn’t already and make your own mind.

Categories: Development Tags: , ,

Happy summer holidays

August 4th, 2013 No comments

The time of the year has come for me to go on holidays. For two weeks, no technology watching, no tech post reading, no blogging, no coding and most important of all, no computer at all.

If you belong to the group of people who already spent their holidays – or even worse, to those who do not have vacations, rejoice (or not)! Not only will I think about you, but when I go back, I’ll bring with me more Vaadin sweetness:

  • On September 11th, I’ll be leading a Vaadin 7 workshop under the Duchess Swiss banner. Bring your laptop and discover not only Vaadin but easy server-push. If you cannot attend, there’s a Github project just for that.
  • October 26th will see the 3rd edition of Soft Shake, “cocktail of computer backgrounds”. There, I will be presenting Vaadin 7 Extension Points.

Come meet me at these two events, let’s talk about Vaadin and make the world a better place!

And if it’s not enough, somewhen in September, the new version of Learning Vaadin updated for Vaadin 7 will be released. Get it now before it’s live, and benefit from huge savings! Afterwards, it will be too late…

Happy holidays!

Categories: Event Tags: ,

The Leprechauns of Software Engineering

July 28th, 2013 No comments

This review is about The Leprechauns of Software Engineering by Laurent Bossavit, self-published Leanpub.


  • 13 chapters, $5 minimum, $10 suggested
  • The book is about many things we all take for granted in software engineering, and that have no reliable underlying scientific basis

Pros and cons

This is not your average tech book, nor your average methodology book. As such, it cannot be reviewed through the pros/cons prism.


Software is thought of as an engineering science: as software engineers, we are asked to provide factual data so that management can take rational decisions. This book wreaks havoc with this idyllic vision, and proves with much data that some of the “facts” we based our decisions upon are just huge memes that have  taken the status of absolute truth.

I hugely recommend reading this refreshing book, as it questions many facts taken for granted in our daily job.

Categories: Book review Tags:

Stop the f… about Gradle

July 21st, 2013 24 comments

Stop the f… about #Spring & #Hibernate migrating to #Gradle. Repeat after me: “my project do NOT have the same requirements” #Maven

This was my week’s hate tweet, and I take full responsibility for every character in it. While that may seem like a troll, Twitter is not really the place to have a good-natured debate with factual arguments, so here is the follow up.

Before going into full-blown rhetoric mode, let me first say that despite popular belief, I’m open to shiny new things. For example, despite being a Vaadin believer – which is a stateful server-side technology, I’m also interested in AngularJS – which is its exact opposite. I’m also in favor of TestNG over JUnit, and so on. I even went as far as going to a Gradle session at Devoxx France! So please, hear my arguments out, only then think them over.

So far, I’ve heard only two arguments in favor of Gradle:

  1. It’s flexible (implying Maven is not)
  2. Spring and Hibernate use it

Both are facts, let’s go in detail over each of them to check why those are not arguments.

Gradle is flexible

There’s no denying that Gradle is flexible: I mean, it’s Groovy with a build DSL. Let us go further: how is flexibility achieved? My take is that it comes from the following.

  • Providing very fine-grained – almost atomic operations: compilation, copying, moving, packaging, etc.
  • Allowing to define lists of those operation – tasks: packaging a JAR would mean copying classes and resources files into a dedicated folder and zipping it
  • Enabling dependencies between those: packaging is dependent on compilation

If you look at it closely, what I said can be applied to Gradle, of course, but also to Ant! Yes, both operate at the same level of granularity.

Now the problem lies in that Gradle proponents tell Gradle is flexible as if flexibility was a desirable quality. Let me say: flexibility is not a quality for a build tool. I would even say it is a big disadvantage. That’s the same as having your broken arm put in a cast. That’s a definite lack of flexibility (to says the least) but it’s for your own good. The cast prevents you from moving in a painful way, just as unflexible build tools (such as Maven) make strange things definitely expensive.

If you need to do something odd over and over because of your specific context, it’s because of a recurring requirement. In Maven, you’d create a plugin to address it and be done with that. If it’s a one-shot requirement, that’s probably no requirement but a quirk. Rethink the way you do it, it’s a smell something is definitely fishy.

Spring and Hibernate both use Gradle

That one really makes me laugh: because some framework choose a build, we should just use theirs, no questions asked? Did you really check why they migrated in the first place?

I won’t even look at the Hibernate case, because it annoys me to no end to read arguments such as “I personally hate…” or “…define the build and directories the way that seemed to make sense to me”. That’s no good reason to change a build tool (but a real display of inflated ego in the latter case).

For Spring, well… Groovy is just in their strategic path and has been for years. SpringSource Tools Suite fully support Groovy, so I guess using Gradle is a way to spread Groovy love all over the world. A more technical reason I’ve heard is that Spring must be compatible with different Java versions, and Maven cannot address that. I’m too lazy to check for myself but even if that’s true, it has only a slight chance of applying to your current project.

Gradlew is one cool feature

The only feature I know of that I currently lack – and would definitely love to have, is to set the build engine version once and for all, to be able to run my build 10 years from now if I need it. It’s amazing the number of software products that go to their first maintenance cycle in years and are at loss building from sources. Believe me, it happened to me (in a VB environment) but I had the fortune to have a genius at hand, something I unfortunately cannot count on.

In the Gradle parlance, such feature is achieved through something known the Gradle Wrapper. Using that downloads the build engine itself, so you can put it into your version control. Too bad nobody ever raised this as an argument :-) though this is not enough to make me want to migrate.

Note: during this writing, I just searched for a port of this feature to Maven and I found maven-wrapper. Any feedback?



  • Gradle is just Ant with Groovy instead of XML
  • Your context is (probably) different from those of frameworks which are using Gradle

Both points have only one logical conclusion: there’s no real reason to use Gradle, stop the f… about it and go back to develop the next Google Search, there’s much more value in that!

Categories: Java Tags: , , ,

You should check AngularJS…

July 14th, 2013 4 comments

… even if you’re a server-side guy!

It is not because I’m a big Vaadin fan that I’m completely rejecting other technologies even before trying them. In this regard, I must stay I’ve been strongly impressed by the AngularJS talk at Devoxx France 2013. Since that time, time has definitively been too short to even think about investigating further, but now that Learning Vaadin 7 is nearing completion and that I successfully completed the MongoDB courses, I can finally do something about that.

At first, I wanted to use Google Maps as an illustration – as was demoed at Devoxx, but that meant I needed to be online to play with my it, so I quickly discarded it. Instead, I went down memory lane: I had always been playing with computers, but I really became hooked into them with POV-Ray, a raytracing engine coupled to a textual scene description language. I found 3D so cool I learnt VRML on my own and modeled a whole section of my hometown for my Master of Arts in Architecture final project. Those technologies have either become obsolete or no more relevant to what my job, but 3D has crept back into the browser through WebGL, a plugin-less technology embedded in most recent browsers. Recently, I’ve come upon Three.js, a JavaScript wrapper framework around WebGL, whose example scenes are really impressive.

Basically, my prototype’s goal is to interactively manage a basic Three.ds scene with AngularJS.

Laying out the work

Today’s target is not to highlight three.js, so I’ve just taken this sample. I just updated its structure for even if I seldom use JavaScript, when I use it, I want to enforce good practices I apply in statically-compiled server-side languages (read Java and Scala) context. Thus, I adapted the sample to only expose variables I want to be able to manipulate through AngularJS: axis rotation and color. Other variables should be kept strictly private and must be encapsulated. I’ve already provided a way to achieve that in JavaScript in a previous post. In short, we create a dedicated object, that serves as a namespace.

AngularJS first steps

Angular is a rising JavaScript framework that aims to enhance HTML with custom attributes.

The first and foremost feature I want to use is to bind JavaScript variables, and more precisely those that govern rotation and color, in order for users to change them. In AngularJS, this is achieved through objects called controllers. A controller is a way to restrict variables scope to a subtree in the DOM.

First, we just need to provide a global entry point: we have to add a ng-app attribute to the body tag.

Then, we create such a Controller:

function HelloWorldCtrl($scope) {

    $scope.who = 'world!';
    $scope.sayhello = function () {

        alert("Hello " + this.who);

Controllers should be passed a variable, that represents scope. Variables and functions defined in this scope are not only restricted to it, but can be used in the relevant HTML section. Be sure to always use the smallest scope possible!

Note: controllers can be nested, so that the whole tag can be set a controller while a sub-tag can be set another one.

With both snippets above, elements can be set event handlers such as ng-mouseover or ng-click can be set controller code, such as the following:

Clicking on the button, it will open a “Hello world!” popup, as expected.

Integrating three.js

The integration step is just about changing the controller to call relevant three.js methods:

function ColorRedCtrl($scope) {

    $scope.updateColor = function () {


The three.js integration is not the main point of this article and thus not very interesting in itself.

As for axis change, AngularJS offers a templating engine, a way to reuse HTML fragments and change only relevant parts. This is achieved through the ng-include tag. It is then up to the controller to set variables.

{{label}}-axis rotation
function AxisXCtrl($scope) {

    $scope.label = 'X';
    $scope.axis = $scope.x;

    $scope.updateRotation = function () {

        this.x = this.axis;


You can check the demo yourself, just be sure to have a look at the source code.

Note: I’m just missing how to keep rotating the cube when the mouse stays hover an element, help welcome [UPDATED]: Christophe, you rock! See the demo as I designed it in my head below in Christophe’s last comment

Categories: Development Tags: , , ,

Maven between different environments

July 7th, 2013 3 comments

As a consultant, I find myself in different environments in need of different configurations. One such configuration is about the Maven settings file. This file is very important, for it governs such things as servers, mirrors and proxies. When you have a laptop, switching from customer configuration to home configuration and vice versa when you change place quickly becomes a bore. When you have to handle more than one customer, it escalates a nightmarish and tangled configuration mess.

In a former environment, colleagues handled Eclipse ini file switch, a very similar concern, by having a dedicated .bat to overwrite the reference file. I heard a colleague of mine do exactly the same for Maven settings file. It does the job, but it is not portable, is more than slightly intrusive and has something I cannot put quite my finger on that does not “fit”.

As IT people are, I’m lazy but idealist, so I scratched my head to handle this problem in a way I would deem more elegant. I think I may have found one, through Maven command native CLI. If you run mvn --help, you’ll get plenty of CLI options: go to the -s section.

 -s,--settings      Alternate path for the user
                               settings file

This means Maven let you use settings files other than ~/.m2/settings.xml. So you can create settings-cust.xml, set all needed configuration for this customer and run mvn -s ~/.m2/settings-cust.xml.

And since I’m really lazy, I just added the following snippet in my ~/.bash_profile to make my life even easier:

alias mvncust='mvn -s ~/.m2/settings-cust.xml'

Now, I just need to run mvncust to run Maven with all relevant configuration for this environment. And it is compatible with other options!

The only drawback I found so far is I’ve to explicitly set the settings file in Eclipse’s m2e but that doesn’t bother me much since I’ve a dedicated Eclipse instance (for configuration and plugins) for each of my environment.

Categories: Java Tags:

Spring 3.2 sweetness

June 23rd, 2013 No comments

Even the most extreme Spring opponents have to admit it is all about making developers life easier. Version 3.2 of Spring MVC brings even more sweetness to the table.

Sweetness #1: No web.xml

The ability to run a webapp without any web deployment descriptor comes from Servlet 3.0.

One option would be to annotate your servlet with the @WebServlet annotation to set mapping and complementary data. When you get your servlet for free, like Spring’s DispatcherServlet, you’d need to subclass you servlet for no other purpose than adding annotation(s).

Alternatively, Servlet 3.0 offers a way to both programmatically register servlets in the container and to offer hooks at startup through the ServletContainerInitializer interface. The container will call the onStartup() method of all concrete implementation at webapp startup. The Spring framework leverages this feature to do so for WebApplicationInitializer instances.

Spring MVC 3.2 provides such an implementation – AbstractContextLoaderInitializer, to programmatically register the DispatcherServlet. This means that as soon as the spring-webmvc jar is in the WEB-INF/lib folder of the webapp, you’ve got the Dispatcher servlet up and ready.

This replaces both the servlet and servlet mapping and the context listener declarations in the web.xml.

Sweetness #2: Easy Java configuration integration

Java configuration is the way to configure Spring injection explicitly in a typesafe way. I won’t go into the full demonstration of it, as I already wrote about that some time ago.

Earlier Spring versions provided a way to use Java configuration classes instead of XML files in the web deployment descriptor. Spring 3.2 offers AbstractAnnotationConfigDispatcherServletInitializer, a AbstractContextLoaderInitializer subclass with hooks for Java configuration classes.

Your own concrete subclass has to implement methods to define servlet mappings, as well as root and web Java configuration classes:

public class SugarSpringWebInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {

    protected Class[] getRootConfigClasses() {

        return new Class[] { JavaConfig.class };

    protected Class[] getServletConfigClasses() {

        return new Class[] { WebConfig.class };

    protected String[] getServletMappings() {

        return new String[] { "/" };

At this point, you just need to create those configuration classes.

Sweetness #3: integration testing at the mapping level

Your code should be unit-tested, that is tested in isolation to ensure that each method is bug-free, and integration-tested to ensure that collaboration between classes yield expected results.

Before v. 3.2, the Spring test framework let you assemble your configuration classes / files easily enough. The problem lay in the way you would call entry-points – the controllers. You could call methods of those controllers, but not the mappings, leaving those untested.

With v. 3.2, Spring Test brings a whole MVC testing framework which entry-points are mappings. This way, instead of testing method x() of controller C, you would test a request to /z, letting Spring MVC handle it so we can check for expected results.

The framework also provide expectations for view returning, forwarding, redirecting, and model attribute setting, all with the help of a specific DSL:

public class SayHelloControllerIT extends AbstractTestNGSpringContextTests {

    private MockMvc mockMvc;

    public void setUp() {

        mockMvc = webAppContextSetup((WebApplicationContext) applicationContext).build();

    @Test(dataProvider = "pathParameterAndExpectedModelValue")
    public void accessingSayhelloWithSubpathShouldForwardToSayHelloJspWithModelFilled(String path, String value) throws Exception {

        mockMvc.perform(get("/sayHello/Jo")).andExpect(view().name("sayHello")).andExpect(model().attribute("name", "Jo"));

The project for this article can be downloaded in Eclipse/Maven format.

To go further:

  • The entire set of new features is available here

Writing a tech book: why and how?

June 20th, 2013 2 comments

There are a couple of reasons that could motivate you to write a tech book. Money shouldn’t be one of them.

You don’t get rich, period

First things first, you don’t write a technical book to become rich as you need the lower time to revenue ratio possible. In this regard, technical book writing is one on the worst possible example:

  • It is a very time consuming activity. Even if you know everything there’s to know about the subject – doubtful, you will need the time to write and to add relevant refernces. Then, you’ll be dependent on others to review your work. After that, you’ll have to let check the commented drafts, carefully evaluate if each is sound or not and act accordingly. Once done, it will be layout work, and so on, ad nauseam…
  • It doesn’t pay much. Really.
    • For once, the lifespan of a book is (very) limited compared to that of a regular book. People are still buying H. P. Lovecraft nowadays, they don’t buy books about EJB 2. That means that the more adherent to a specific tech you are, the lesser revenues you’ll get.
    • But it doesn’t stop at this. Audience is also very limited and the same adherence rule applies. About 40 millions of Fifty Shades of Grey have been sold. Whether you like it or not, it’s a fact. It’s unlikely there are so many developpers, without even mentioning technology barriers: if you write about Java (in general), audience is less; if you do about Vaadin, ouch, that hurts to even think about it.
    • And now for the final blow. You’ll probably go to an editor to publish your book, thinking that would probably expand your reach. Perhaps (more on that later), but that will with no doubt decrease your cut, as your best pal will take between 85 and 90% of the revenue. Welcome to real life…

    As seen from above, a waitress or a janitor are probably paid more bucks, if you check per hour of work.

Good reasons to write

There are other very good reasons to write a book though. One of them is probably pride: pride in yourself or the desire to make your momma or your significant other proud. Having your own book in your hands gives a really nice feeling of accomplishment. It’s your baby, dammit, the product of your sweat and toil!

Another reason is fame, or more realistically, peer recognition. This one may be double-edged since you will need to provide a good deliverable or you will achieve the opposite. But if you do a good job, chances are people in the tech business will probably know about you and your book and look upon you in a favorable light, even when they didn’t meet you before.

It may also look good on your resume… or not. Personally, I do not advertise it on mine as I feel a recruiter may become afraid to deal with someone who he thinks will act like a diva. But I think it may be very dependent on the culture. Just be aware of that.

Last but not least, a very good reason to write is to strengthten your knowledge of the subject. Yes ladies and gents, authors are not (at first) experts on the subject they write about. That doesn’t mean you should write a book when you know nothing about the subject (though I wouldn’t advertise against it if you’ve enough time and motivaton), that just means that some areas are more or less obscure and writing about them is a chance to deepen your knowledge. When I began writing Learning Vaadin, I played with some applications and knew about the general architecture, but the finer points about client-server communication were lost to me. That didn’t prevent me to understand them in the process of writing. And I hope that I have achieved a decent degree of expertise on Vaadin now.

There may be other reasons, but since they don’t come to me naturallt, I guess they were not mine. Feel free to add your own here.

What do I need?

As said previously, skills is not mandatory per se. You could write a book on a subject you don’t know about. It will take you much more time, but it’s possible. Likewise, mastery of the language is not a requirement: you could ask people to review your book. And in the technical book, sentences should be concise and to the point.

IMHO, there are only three basic requirements: time, will and faith.

For time, well, I talked a little about that formerly but you should definitely understand this: either you got plenty of time right now and that’s fine, or you’re stuck with 24 hours days like us mere mortals and that means you’ll need to prioritize. In essence, instead of browsing around the Internet, you will write. Instead of playing casual games, you’ll write. Instead of talking to virtual friends on Facebook, you’ll write. Up to this point, I guess it should be pretty ok for everybody. But instead of going out with your friends, guess what, you’ll write. If at the end of a work day, you want to spend some time with your family… you have to write. And so on. As a sidenote, a friend of mine warned me before I undertook my journey that the last person he knew who did write a book ended up divorced.

Writing is time consuming. I wish I could give an estimate of how much time it took me, but I didn’t monitor. Just understand that writing is time-consuming, and having a salaried job takes you at least 8 hours a day, so plan. Guess how much time you’ll be able to work on your book each day/each week, then add 30% to produce a realistic planning.

Very close to the time thing is will. Because we are only human beings, and writing takes so much time over our other activities, sometimes you’ll have enough. Though it’s OK (and even recommended) to go out in the sun, you should always strive to write each day or even each week or at least to research something related to your book. It keeps you in the line. It’s self-discipline and for me, it’s one of the hardest thing to achieve when you want to be an author. Having an editor definitely helps you there (more later).

The last thing you need is faith in the subject you write on: you have to be convinced that the technology is going to change the world, end wars, make people happy or whatever. Definitely and without a doubt. Or don’t write. Remember, you’re going to make your book a priority in your life, so it better be worth it. If you don’t think highly of your subject, you’d better go back to what you were doing previously because all those sacrifices are not worth it.

Editor or not editor?

The most structuring step is to go with an editor or not. There are good reasons to choose the former, and bad ones.

If you’re writing a tech book, that means you’re a tech guy (or girl)++. This means that you like tech, and perhaps also sharing your love of tech. But in general tech people don’t like what goes around book writing: reviews, layout, marketing, advertising, public relations, sales, etc. If that is the case, go for an editor which will take care of that (more below).

Having an editor means you’ll have a contract, and in it an associated planning. If you think you do not have enough self-discipline to write regularly, such a planning could be the looming threat you need to go for it despite all distractions around. This is definitely something to ponder about.

Some editors are small and competing for visibility, some are definitely a standard and have the best reputation. If you have the chance to write for O’Reilly (or perhaps Artima also, for their Pragmatic serie), jump at it. The downside is that they have power, they know it, so your cut will be at the smallest. But you didn’t write for money, did you?

If you’re a new writer, and have no access to user groups, conferences, or audience in any way and have no prior reputation, I would definitely recommend going for an editor. It will help you in the writing process and open you channels. On the other end of the spectrum, if you’re Adam Bien or Antonio Goncalves, both Java Champions, you can self-publish without much trouble.

As for some bad reasons, well, remember marketing and advertising? Don’t have high expectations on this side, they are completely oversold by editors. This is an excerpt from a mail conversation with my own:

I was wondering if you’d like to give me any suggestions regarding the promotions of this book, it could be anything, reviewers you’d like me to get in touch with, specific websites you’d like the book to be featured on, any speaking arrangements/events where you’d like the book to be promoted, etc. Any such suggestions from you would be highly appreciated and I’d be happy to implement them.

So in essence, you give them pointers and they contact them for you… What a big deal! To sweeten this, note that at the end of the writing process, you basically want to enjoy life again, get reunited with your family, see your friends and have no desire to go the extra mile; you’ll probably end up wanting to delegate everything to someone, even if they don’t do much, so think about that before telling it’s bullshit (which it is).


I think at this point, you have a good overview of what to expect (and what not to expect) from a tech book writing experience. IMHO, it may be related to a race. You train for weeks, it requires time and will. And during the race, it’s hard. But the nice warm feeling inside when you finish it is really something special. Go do it :-)

Categories: Technical Tags:

MongoDB course, thoughts and feedback

June 16th, 2013 4 comments

I’m afraid I traded my ability to understand SQL for the ability to understand Object-Oriented Programming a long time ago. That’s why I never have been at ease with databases in general and SQL in particular. Given the not-so-recent trend about NoSQL, I thought it was time to give it a try. When I became aware that 10gen – the company behind MongoDB, was making free online courses available at regular intervals, I jumped at the chance and last month, I registered for M101J: MongoDB for Java Developers.

Yesterday, I finished week 5 assignments. Even though it’s not finished yet, it’s time for some feedback, on the both the course and MongoDB.

On the bright side:

  • First, I’d like to thank 10 gen to make those courses available freely. Of course, it’s not without second thoughts, but it would be a better world if other software editors would do the same.
  • Also, the course is very practical and IMHO well adapted to a software engineer’s day-to-day work. I’ve prevoously followed Coursera’s Scala course, and I disliked it because I felt it was too theoritical: homework examples were about algorithms and had no roots in the real world. Compared to Scala’s course, this one is much more pragmatic and relevant to me.

There are some downsides, though:

  • The course is said to be “for Java Developers”. Unfortunately, some – if not most – of the courses and their associated homeworks are about the MongoDB shell, which is plain JavaScript. I would have prefered to have two different courses, one for the shell and one for the Java API.
  • Speaking about the Java API, to tell it’s a thin wrapper is an understatement, for it’s only the literal transcription of JavaScript shell commands into the Java language.
    I know API design is hard, but come on guys: no enumerations, no constants, only Strings! I was expecting more in 2013 than JDBC reinvented, complete with String concatenation… Now, here’s what one who has been around a few years can expect if MongoDB becomes widespread:

    1. Productivity will be low, there will be tons of bugs, developers will complain
    2. Some smart people/company will provide a usable wrapper API around the native one (in fact, Spring Data already does)
    3. MongoDB will learn its lessons and provide their own improved API, based on their competitor, but not quite like it
    4. And it will be the whole JDBC to Hibernate vs JPA war all over again!
  • SQL is not what I would call readable, but it’s expected for a technology that began some 40 years ago. I have more expectations for a technology a few years old, but sadly, they are to be unmet. Whereas standard MongoDB queries are not a model of usability from a developer point-of-view, but the palm goes to the so-called aggregation framework. As an illustration, this Gist is the answer to one of this week’s homework (obfuscated of course).

This is my feedback based on my own experiences and those are completely personal. I would recommend anyone even remotely interested in NoSQL to take those courses themselves and make their own mind. The next batch is planned for July 29th.

Categories: Java Tags: , ,