Do you have IDEA?

Prelude

This post is intended as an introduction to why I love working with IntelliJ IDEA. If you haven't heard of it yet, it is an IDE, just like Eclipse or NetBeans, the only material difference being that it has an edition that costs money (but you can get a free open source license).

During this "review" I will be using the following notation to present my pros and cons:

This is something I like a lot.

This is something I don't like.

Pricing

After I have been using it for a few months I can say that it seems that being an essentially non-free product is a good thing: it feels that they are actively seeking to deliver better and more comfortable usage. It feels that their team doesn't just put in features, they try to do it in a way that is natural and easy-to-use and cool.

Disclaimer

These are just some of the experiences I noticed while coding. IDEA offers a lot more little "wow that was easy" or "wow that was clever" feelings, whenever it does something that feels just right in that situation. Those can only be experienced while watching someone working in IDEA, or better yet, trying it out for a few months.

I will probably post updates with new things in the future -- I will try to document all these moments when they occur.

Mail must be sent a day before commit

A friend of mine has just received a mail, that contains instructions on the project his team is working on (excerpt):

• Every change to XML/XSD/XSL must be reviewed by the (censored) review board group.
• [...] A change in XML needs to be announced to the (censored) mail distribution list. This distribution list does not exist in the exchange server yet so you can send me the email and I can forward it for the moment.
• Ideally a mail should be sent at the start of the work with the expected commit date.
• A mail must be sent a day before commit.

I'm sorry. I understand the need of control, but this is a seriously fucked up way to do it. What I think is:

• This is a distributed project with a lot of teams depending on a central XML/XSD.
• There are no branches, it is a single track development (in fact I know that it is hosted in SVN despite being such a huge thing).
• There are no tests, therefore no continuous integration.
• Instead of fixing things, more bureaucratic weight is placed on the developers to create an illusion of control.
• There isn't a mechanism to easily and effectively distribute change notices through teams.
• The authors are basically stating that developers do not have the necessary knowledge to propose changes in the XMLs.
• This leads to the conclusion of no documentation, from which the developers would learn.

So what

Developers are best at hacking away at code and providing solutions to the requirements. It's their job! They love their job! (Some even grow facial hair because they would rather hack at code than play with sharp blades.)

This kind of control will only throw them off balance, making it impractical to even suggest changes that may make the whole project easier.

Practically the mail makes the XML/XSD/XSL in the system a fixed fact ("Don't touch it, you!"). No one but the bravest will try to fiddle with it, therefore solutions will pop up that go around the problem. They may not be big things -- only there's a possibility that out of two solutions, the better will be dropped.

There still won't be tests -- so we now have hacks in the code, but the management is confident because nothing changed in the critical area.

Commit control?

Tasks that involve adding a single optional attribute that would take anyone 25 minutes will suddenly be days. First the approval, then the announcement, then the "will commit" ping, then 24 hours later, the commit. Changes will be batched, it will be unclear if they're logically grouped or it just happened that way.

Sending a mail that the change will be committed 24 hours later creates a tension that practically will manifest as: done → send mail → commit tomorrow. Bam, we have a 24h delay. Not good for anyone.

Conclusion

I may overreact to this; I can easily imagine a situation that such rigorous verification is necessary. Only that it should be supported via the build and continuous integration, not via pre-commit emails, not via restrictions on design feedback from developers. This is too much of a cost, and ultimately the product has a good chance to be the loser of this.

But soft! what build on yonder server trots?

I am seriously loving Gradle after the initial 15 minutes of confused searching. No, really, if you are coming from the Java side, consider reading this page first: Gradle Java plugin, or be lost for quite some time like me. And you will probably want to run

gradle test

first.

What I wanted

I wanted something that used Maven's repository for fetching dependent open source libraries, while not forcing Maven's heavyweight things on me.

What I got from Gradle

Consider the following snippet: What did the author want?

• Oh hey, this bloke wants Java. Let's "apply" it, whatever that means.
  (Look, this stuff is plugin based!)
• He wanted to use Maven central as a repository.
  (You can stop with Maven right there, thank you!)
• He described his dependencies, 1 for compilation, 3 for test compilation and 1 for running his tests.
  (How do I configure how targets are related?...)
• Define the source set paths, for main java, test java and test resources.
  (Sounds Mavenish, am I not going to be free after all?)

What it really is

That snippet is i7m-common's complete build description.

As far as I can see now, Gradle has certain perks:

• Supported by travis-ci!
• No boilerplate Ant build.xml, no init, compile, copy, test tasks, etc.
• If you're building a simple Java project with the same structure convention as Maven, you only need the first line to get a full, working build that can also run the tests and create JAR packages.
• If you want to use a lot of open source thingy, you can easily manage dependencies without having to commit them to your source control. (Of course, being in an IDE is an entirely different question, you will still want the libraries, or get a Gradle plugin.)
• If you want to use a different structure, just set sourceSets like above, and carry on.
• You don't have to worry about target relationships, because Gradle has a built-in "default" which is OK for most of the Java projects. And if someone needs more, the configuration is as easy as the sourceSets above.

Closing thoughts

I am sure that it has its downsides but right now I'm pretty happy that I did not have to litter build.xmls into my projects.

PS. I stole the title from Why did the chicken cross the road? (Shakespeare), which of course was based on Romeo and Juliet.

Mind the gap

This is probably the most blogged topic ever, but let me try to reiterate it.

I find it interesting that some of the companies or recruiters I had to work with actually place more emphasis on the claimed skills of the individual, rather than the individual's mindset.

Why is the mindset important?

Going back a few years, I was actively interviewing candidates for Java Developer positions. After the initial round we dropped only the ones who couldn't talk at all. I realize that everyone can have a bad day, but those people were actually unable to communicate.

In the second round, they had to solve a problem in front of the computer, without any time limit or restrictions. They were free to ask questions, search on the web. The task was not a hard one: it involved writing a servlet and a JSP. Basically the candidate passed, if he was able to Google "servlet jsp tutorial". The results were astounding:

• majority of the candidates have given up after 5 minutes;
• most of the rest were unable to find the solution on the web;
• some of the rest were able to solve it.

The demography of the results were also very surprising to me:

• fresh graduates who worked on thesis related to the field were unable to solve it;
• people with years of experience were unable to solve it;
• usually random people without proven experience or degree could solve it.

Going back to the mindset

The fizzbuzz example is a similar problem; people with degrees or experience can't solve a problem that involves simple concepts.

And I think it is not the degree or experience that corrupts people, it is the mindset of the people involved (being affected by the other people at the company or university/college).

I have seen people get high and proud doing their thing at a company, and it is fine to a degree. The danger rears its head when these people want to move on and realize that there is a whole different world out there, with acronyms they never heard before. And even for a J2EE developer, it is very unlikely to find a job that requires to do the same thing as before.

Therefore it is necessary have a mindset that embraces new things, is open, receptive and pragmatic. This is sometimes visible in job posts like this Atlassian one.

Going back

I come back to my first statement: I feel that some companies I interview with in Hungary are not actually interested in my mindset, they are interested at static evidence that may or may not mean what they think. I feel that it won't make that much difference to a team if I am the best EJB guru ever born (I am not). I feel that it is more helpful to have someone who can see the concepts and intents of a system. If that is given, I don't feel that it matters what technology we are talking about, since technology can be learned (fast).

I am not saying that companies should not require proven experience from candidates in areas they will work with; I am saying that the focus should not be exclusively in that area.

I feel that these companies would be much more productive if they would hire people who are open to new things. Rands called them volatiles.

I feel like I have to emphasize that I don't think people with proven static experiences can't be volatile or pragmatic. I just think that the recruitment process should assess those qualities as well.

jruby-18mode and 1.9 hash syntax

I have this pet sandbox project named kandic where I try myself at Ruby BDD while creating something worthwhile. I hooked up with travis and codeclimate for good measure too. Travis is set up to test against 4 different RVMs: 1.8.7, 1.9.3, jruby-18mode, jruby-19mode.

And here's the funny thing: as it turns out, the 1.9 hash syntax that was in the code that time properly creates parse errors on 1.8.7, but jruby-18mode can parse it.

I had the same problem with minitest dependency later, the jruby-18mode was happily crunching away.

Just a few things to watch out for if the target is 1.8, I guess.

Lost project found

This was before the day I used any version control, and I have to admit I have totally forgotten about this.

It's my "let's make a hungarian-japanese online kanji reference based on the book I bought" project: Kanji referencia.

First time HTTP servers

There are two things you will need to watch out for if you are to write your own small HTTP server for the first time:

• The request ends with a line containing exactly

  \r\n

  If you go on and read again, the read will block because nothing new will come. This can be conveniently checked using a BufferedReader.
• The minimal response you will need to send is

  output.print("HTTP/1.1 200 OK\r\n");
  output.print("\r\n");
  output.print(response);
  output.flush();
  output.close();
  

  A PrintWriter is a good friend here. The "OK" after the response code is not required, but should be written out, since HTTP 1.1 RFC tells us so:

  Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF