MongoDB and Java

In the past few weeks I've participated at the M101J: MongoDB for Java Developers Course from 10gen Education. For those who are not familiar, MongoDB is an NoSQL database that's been very prominent amongst the "new" databases that have showed up after the NoSQL movement started.

I say "new" in quotes because most of them have been around for a long time, but only recently began to be considered real alternatives for production systems. I'd say that the industry has finally realized that polyglot persistence is a really obvious best practice and I'm amazed by how long it took for it to realize it.

Learning MongoDB is really fast so that in less than a day you can install it and begin inserting and querying data on your development machine. Of course, as any industry level database it will take longer for you to feel comfortable and productive with it, but it's mainly a convention over configuration tool and with impressively few steps you will have it up and running.

A few of the most important concepts used by MongoDB:

• A document based database: it stores data in the form of whole documents instead of the traditional relational rows in a table. The documents are stored in the BSON format, which is a binary representation of JSON documents
  
  
• It's schemaless: it does not enforce a determined pre-defined format that data has to have in order to be inserted. It means that you can basically put anything inside a collection (analogous to a table in a RDBMS) and it will be stored successfully by MongoDB. As cool as it might seem at first, this does require an application able to deal with that condition. Look at the following example:
  
  

• Its supports indexes: as relational databases, MongoDB relies on indexes to return query results quickly. Indexes work pretty much the same here, they take up space, might slow your inserts and updates, but greatly decrease read times. The main difference is that on MongoDB you can create a Multi-Key Index, that is an index created on an array field. By the way, have you noticed on the example above that Mongo is able to store arrays? How great is that?
  
• It's distributed: MongoDB can natively be distributed in two ways with Sharding or Replica Sets. Sharding is basically splitting up your collections on different physical servers to scale up horizontally. Replica Sets grant reliability and availability by using other server as backups to a database.

Using Java and MongoDB is pretty easy, use the MongoDB Java Language Center. The Language Center has a Java Driver provided by 10gen, which is just great and pretty easy to use. Here's a simple read code example:

This is just a simple read on a collection, to get a better grasp of what's really going on it's important to study the MongoDB client syntax, as the Driver relies on that and you can even send direct commands to the database. If you want less boilerplate code try the SpringData MongoDB integration
 
Learning MongoDB is a very rewarding experience for a Java developer. It's quick and very little messy, so that you can at least test it for all kinds of applications. It's reliable and scalable, so even if you got a project that's going to turn big, it's still a good idea. For those willing to dig deeper I really do recommend the courses available on 10gen Education. They've been developed with a lot of care by the company that made and maintains MongoDB. Also, they're free, so if you don't like it you can always drop it without regrets.

Pair programming, is it truly productive?

Having worked with different agile methodologies I have frequently met people completely skeptical to the fact that two people sharing a computer can be as productive (or more) than if they were separated. That led me to write this article about pair programming and I hope that you enjoy it.
As an agile evangelist and pair programming admirer, I'm going to go through a few major topics on this subject and share my own personal experience. This post does not intend to teach you how to do pair programming, instead it will show you some benefits that would lead you to try this approach. Please leave your comments if you want to share your point of view on these matters.

Knowledge transfer is in my opinion the most important benefit of pair programming. Teams that practice pair programming have a consistent knowledge base distributed among its members, so that code produced by any member of the team tends to have the same pattern everywhere. You won't have to spend resources on team training because the daily developing activities become the training themselves. I cannot overemphasize how important it is that the senior members of the team be reminded of that. Some people just weren't made to be good teachers or even don't like to share knowledge. These people just won't fit to pair programming and are likely to be a lot more productive by using the single programmer approach. Furthermore new technologies are always popping out of nowhere and external training should not be neglected.

The second most important benefit would be quality. A pair will always have a person that controls the keyboard at a time. This person should focus on the coding, analyzing, syntax, tools and the action of developing. The name given to that person is "pilot" as he will be the one getting his hands dirty. The other person will be watching the development, but he's got no less responsibility. The "co-pilot" as we call it, must provide support in many ways in order to allow the "pilot" to focus on the coding activity itself. The "co-pilot" tasks involve checking the code for bugs, proposing different architectural approaches, executing parallel tasks and foreseeing possible impacts of the development being made. That said, the quality of the code is greatly improved by the pairing, reducing the likeness of code being re-worked to fix bugs, thus accelerating development. It's important to mention that a pair must always switch positions between "pilot" and "co-pilot".

Skill 

Considering the skills of your resources when pairing developers is not only important, it's essential. Different combinations lead to different results and some of them can prove to be a total disaster. I've suggested a few combinations here, but it's unreal to divide developers as novices, average and experts. The combinations are in truth a lot more complex than that as developers tend to have specialties and expertise that differ a lot one from another. Even so I'm providing a few suggestions for you to grab the concept of comparing combinations:

Novice + Novice: Weak combination not promising in terms of results. Two unseasoned developers together tend to produce results slowly and with bad quality. Worst, it's not likely they will be teaching much to each other. The only profit I usually saw from doing this was that it is a great way to analise the developers profile. While some will try to learn and struggle to complete a task, some will just bug people around and try to copy things, or fake some workaround. It's also a good way to determine which of the pair is fitter for decision making and leading.

Novice + Expert: Also not very promising, expert programmers are usually very fast and have little patience and little time to be teaching the basics. The results will be produced very quickly and with quality, as the novice won't have anything to add or debate about what's being coded. In many ways, it's pretty much the same as having the expert to code by himself. Only use this combination if you have a spare novice that you don't have anywhere else to put nor any task to provide.

Novice + Average or Average + Expert: Usually a great combination, we will have a productive pair with good debating and questioning. The most experienced member will spend some time explaining questions on technologies, but in the end you will probably have the tasks done timely, while training the resources of your team.

Average + Average: Good pair. Whenever two programmers with a similar average level of skill are put together they will strive to get the task done quickly. They might stumble on a couple of technical complexities, but being a pair they will have an easier time by putting their efforts together to achieve a common goal. The danger here is to have on programmer coding and the other just watching. As mentioned above, to have a good co-pilot is essential if you want to have a lower re-work rate and fewer bugs in your end software.

Expert + Expert: Rarely a good idea. Except on architectural decisions, experts don't really need to rely on a co-pilot. Don't get me wrong, I always think that the more, the merrier, but usually having two experts coding together does not justify the investment as these tend to be scarce resources. Coding is easy for them and the best idea would be having experts to make big decisions in a meeting.

Duration 

It's also important to take in consideration the duration of each pairing. It could be a single day session or several iterations, but usually having a pair to work together for 2-4 weeks works well. Less time than that and the members won't have time enough to synchronize their work rhythm. More time than that and differences might begin to bother the pairs.  Also, having your team to switch partners regularly will improve the community feeling. Developers learn their strengths and weaknesses and that is really crucial for keeping the team calm and steady for some tight scheduled or complicated projects.

Communication

Communication is the key for good results with pair programming. It must be constant between the pair and also with the team. It must be productive and have constructive criticism. Not anyone can stand being criticized and questioned during development and that's fair. Pair programming is not intended to anyone. There are personal traits that a developer must have in order to be a good pair programmer, and that includes patience and people skill. 

Discipline
People developing in pairs are constantly being supervised and watched. By their own partners it is. They tend to focus on the work and lose a lot less time with personal stuff. They won't be likely to stop a good programming rally just to check their email or chat with someone. Much less to be watching the newest review of some crazy gadget. That greatly increases productivity, at the cost of stressing the developer. Different people will react differently, but in the end, some intervals should be allowed after long programming sessions to allow the developers to have some privacy. Having to share a computer does not mean that they don't need a private workstation, or have to be together at all times. What worked fine in my previous experiences was to extend the lunch time, allowing the developers to have an extra free time after lunch to take care of personal stuff. 
Another complicated situation happens when the team must study a new technology or learn to use an entirely new API. When there's nobody to share the knowledge on a topic, pair programming should NOT be used at all. Having pairs to study the same subject together is very much like de Novice + Novice approach mentioned above, with all of its drawbacks.

Conclusion
Yes, pair programming can be as productive or more than single person programming. I've seen it myself on different teams and on different projects. The speed of having separated developers is counterbalanced by better quality code that doesn't have to be re-written and developers that focus on their work instead of YouTube, Facebook and other crap. The reader must understand that it does not mean that it always will be better. There any many cases where pair programming will suck and will just waste one of your resources. My final thoughts? Use a hybrid approach. Using both pair programming and single person programming will work just fine if the team leader and the developers know on which stories should be tackled in pairs or not. 

Jet Brains - IntelliJ IDEA

Since I began programming I've heard colleagues talking about how IntelliJ IDEA was great. Higher productivity, smart suggestions and a world of assistances were the most common praises.

For the ones who never heard about it, IntelliJ IDEA is an IDE focused for Java development. It has a free (Community Edition) and a paid version (Ultimate Edition).

I've always been an Eclipse fan since I began programming so I never bothered much to spend time learning yet another tool to do the same things of my everyday programming life, until the day that was supposed to be the "End of the world". Yes, on that day (12/21/2012) Jet Brains decided to do a "End of the world sale" and sold IntelliJ and some other products of their catalogue with a great discount (50 bucks for IntelliJ).

I then decided to master that new tool. Besides having the opportunity to increase my skills, they say that doing the same things in a different way is a great brain-training exercise. It helps to avoid and recognize bad habits one might have from using the same tools, everyday.

This question on stack overflow was one of the things that inspired me the most when I was wondering whether to buy ir or not:
http://programmers.stackexchange.com/questions/21987/how-is-intellij-better-than-eclipse

Also, something that's been extremely useful for myself is a printed list of the hotkeys for IntelliJ. I used a text marker on the commands I use the most and reduced my learning time considerably. You can get an oficial KeyMap in this link: http://www.jetbrains.com/idea/documentation/index.jsp

Another hint, by using: command + shift + A you can type any command available in the IDE, much like the ctrl-3 hotkey on Eclipse.

Well I'll keep posting my experiences with IntelliJ and hope to bring interesting facts and comparisons between those two amazing tools.