But still, I was left wanting more. I mean, I don’t want to have to hit something to tell eclipse to go run my tests. Eclipse already knows when I save, as it can automatically shoot off a build. Why couldn’t I just have another step afterwards which then runs my test, so I don’t have to do anything? It was along this line of thought that I stumbled upon Misko‘s setup of using build steps to run all unit tests at each save. Hallelujah! But the more I used this, the more I started realizing its pain points. You actually had to setup each project to do this? Uh, no. Not happening. Too much effort. I like being lazy.

So then I happened upon this Infinitest thing. The description sounds promising, “A continuous test runner for your JUnit tests.” And what, it “integrates with Eclipse and IntelliJ“. And its “Intelligent and runs only tests that are needed.” I’m sold, where do I sign up? So I went ahead and installed it, and tried it out. And it actually seems to live up to its claim, so far. Its main configuration has a single checkbox, which basically says run Infinitest or don’t run it. Nice. And it integrates seamlessly with the problems view. Like so :

Infinitest results in the problem view

As can be seen above, I made a change which broke two tests. Half a second after I saved those changes, I have problem markers popping up all over my project telling me that the last thing I just did blew up some tests. I can double click on the markers, go to the exact line where the failure is, and see if it was an issue of the test being wrong or me being stupid. And in some cases, that isn’t even needed, because you know the tests shouldn’t have broken.

Infinitest seems to be smart enough to recognize all JUnit tests without you having to point it out, and runs only the tests that matter, and not all of it. But if you have other kinds of tests, then you might run into trouble. I am still playing around with it, and will probably update this post or add a new post later with more detailed info if I deem it necessary. But in the meantime, for those of you who want to run tests at every save, check out Infinitest. It is awesome!

While the focus of the workshop was testing and refactoring, what they did do, which I applaud them for, was they showed us some awesome shortcuts. And suddenly, I was doing these insane refactorings at the blink of the eye. It was then that I started searching for and learning every eclipse shortcut that would help me be more productive. And before I knew it, I was typing 6 words a minute and coding up 100 words a minute . And I loved it.

And so, today, I just wanted to share the best shortcuts that make life easier. And without further ado :

Ctrl + Space : One of the two most important keyboard shortcuts that eclipse offers. This one is probably commonly known for autocomplete in eclipse, but not many people know that it is also context sensitive. For example, hitting Ctrl + Space when you are in the middle of typing will show you all members and methods that begin with your text. But hitting Ctrl + Space when you have nothing typed shows you all members and properties available. But the real eclipse masters know that, hitting Ctrl + Space when you type in for or foreach will show you autocomplete options for generating a for loop or for each loop. And if you do it right after you assign something to a collection or a list, it will fill in the loop variables for the for each loop. Autocomplete after typing in test, will allow you to generate the skeleton of a JUnit test case method. Autocomplete after typing in new, generates you a skeleton for a new call, which you can tab through and fill in. So many more uses and use cases for Ctrl + Space that can be found. You can generate / override method signatures in child classes. Just use and abuse it, and you will learn so much.

Ctrl + 1 : If there is just one more shortcut you remember from this post, let it be this one. The other super awesome, context sensitive shortcut in Eclipse, which is basically Quick Fix. If you have an error in a line, Ctrl + 1 will show you potential options to fix it, like importing a class, or adding an argument to a method or fixing the method signature. If you just do a method call which returns something, then you can hit Ctrl + 1 and ask it to assign it to a new local or field variable. You can hit Ctrl + 1 on a parameter to a method and assign it to a field. Ctrl + 1 on a variable can allow you to inline it, and on an assignment, can allow you to split up the declaration and assignment, or convert it to a field, parameter, etc. It is, by far, The Most Awesome  Keyboard shortcut that you can know and use. Especially on errors!

Ctrl + F11 : Reruns the last run configuration that was executed. If you do TDD, then Alt + Shift + X, T followed by Ctrl + F11 is the most standard approach.

Ctrl + Shift + R : Shows the Open Resource dialog. Type to filter, and jump directly between classes. I love this shortcut, and use and abuse it!

Ctrl + Shift + O : Organizes Imports, and gets rid of unused imports.

Ctrl + O : Shows the methods and properties of a class. You can start typing to filter and hit enter to jump to a particular signature / type. Hitting Ctrl + O again toggles showing inherited members. Very useful for jumping between sections in a class, or finding that one method you want to get to.

Ctrl + T : Opens the Type Heirarchy. Shows all super classes as well as sub classes / implementing types in your class path. Very useful for jumping to an implementation class. Can be called from the class type, or even a method signature. Can toggle between Supertype and Subtype heirarchy if you hit Ctrl + T again. Again, you can type and filter once you are in this menu.

Ctrl + / : Comment / Uncomment code. Single or multiple lines, depending on what you have selected. Enuff said.

Alt + Shift + R : One of my most used shortcuts, Rename. It renames anything from variables to methods to even classes, renaming the class files if necessary. Also fixes all references to refer to it by the new name. Can sometimes break if there are compile errors, so watch out when you use it. You can also ask it to fix all textual references as well.

Alt + Shift + M : Extract Method. Super useful method to break up a larger method into smaller chunks. If the code block you have selected does not need to return too many types, and looks reasonable as a separate method, then pulls up  a prompt where you can basically edit the method signature, including return type, method name and order and type of parameters. Very useful

Alt + Shift + C : Only useful when the cursor is on a method signature, but this one allows you to refactor and change the method signature. This includes changing the return type, method name, and the parameters to the method, including order, and default values if you are introducing a new one. Automagically fixes all references to said method.

Alt + Shift + L : Once you have a expression selected (a method call, or whatever), then Alt + Shift + L extracts that to a local variable. It prompts you for the name of the variable, and automatically infers the type as best as it can. Extremely useful shortcut!

Alt + Shift + Up / Down : This one is a useful one. If you hit up, it selects the next biggest code block, down selects the next smallest. Useful in conjunction with refactoring shortcuts like extract local variable, extract method, etc. Useful to know.

Alt + Shift + T : Brings up the Refactor menu. Depending on the context, this will show options like Rename, Move, Extract Interfaces and classes, Change Method Signature, etc. Nice to know, but not one I use very often. The ones I do use have already been listed above.

Alt + Shift + S : Shows the Source menu. This includes menu options like Comment related, and the ever useful Override / Implement Methods, Generate Getters and Setters, and much more. Some of the menu options have direct shortcuts, but a lot of the generate commands don’t, so useful to know.

Alt + Shift + X : Pulls up the Run menu, and shows what key you have to press to run a particular type. Now I generally use this as Alt + Shift + X, followed by T, which basically executes a JUnit Test. Fastest way to run unit tests without leaving the comfort of your keyboard.

Alt + Up / Down : Moves a block of lines up or down. Rather than say, selecting, hitting Ctrl + X and then going to the place and pasting, why not just select all the lines, and use Alt + Up or Down to move them. Automatically handles indentation depending on the block. Very convenient

Ctrl + D :  Nice and Simple, deletes the current line the cursor is on. If you have selected multiple lines, then they are all blown away. Much faster than selecting a line and hitting delete.

UPDATE: Adding in some of the shortcuts that I forgot or were mentioned in the comments for easy finding

Ctrl + L : Jump to a Line number

Ctrl + Shift + T : Display available types. A better version of Ctrl + Shift + R if you are only looking for Java classes

Alt + Shift + Up / Down : Duplicate selected lines above or below. Easier than hitting Ctrl + C followed by Ctrl + V

Ctrl + Alt + H : This one, I didn’t know about. but pulls up the Call heirarchy, showing you all callers and users of the method under the cursor. Super useful, especially if you are refactoring.

Ctrl + Shift + L : Show the list of shortcuts. You can hit it again to go in and edit your shortcuts.

Pair programming is an agile concept and is frequently used in XP (eXtreme Programming). At its core, it is nothing but having two people sit and code instead of one. And while that may seem like an obvious timesink and a doomed concept, considering two people cannot type and code at the same time, it is surprisingly effective for many reasons, some of which I will try to outline with examples from my brief experience.

When you work as part of a team, there is usually a process (sometimes a series of flaming hoops even) which you have to jump through before you can submit your new, super amazing, code which breaks all previous latency records. Or something just as amazing. And for a lot of groups, that involves a code review process, where someone familiar with the architecture of the system or understands the programming language and the problem goes through your code, points out issues (as if there are any in my code !!!) and so on. And while this is a good way to ensure that the quality of code that is submitted to your code base remains above a certain threshold, it becomes a huge timesink. Especially the more you know about the codebase, as everyone and their aunts start sending code reviews your way.

How is this solved with pair programming, you ask ? Well, consider this. While pair programming, assuming one guys starts coding away. What does the other guy do ? He (aha, you shout, as you understand even before I say it) reviews the code as you type, suggesting corrections and optimal solutions in case you start going down the wrong route. But then, you ask, isn’t that a huge waste of time, considering you are basically getting one person to just sit and permanently review ?

Here is where the beauty of pair programming really shines. Its called pair programming for a reason. For one, both programmers take turns in writing up new code, while the other looks on and makes sure the code is up to the amazingly high standards. Another, how many times have you written this super awesome function which took you half an hour to think of, only to find someone tell you in a code review to use this existing library function that does the entire same thing ? Now imagine that guy is, instead, sitting right next to you and telling you this before you even start coding this up.

Furthermore, what if I am a new guy joining a team with a very stable, settled code base. How do I hit the deck running, other than sitting for hours reading up on documentation ? Well, I go find a senior guy who loves pair programming (which is easier than it sounds if a team loves Agile practices) and go pair with him. Instant knowledge dump, and easier transition. This was the case with Arthur, a guy who joined our group for a short period of time. Instead of spending, say two weeks reading design and architecture documents, we started pairing with him from day one. By the end of day three, he had already fixed two bugs (both of which were on the first day itself!!!) and had made quite some headway into designing his first full feature. Now this intensive pairing (some might even call it hand holding) might have caused us to loose some productivity in the first few days, but by the 4th day, we had a new engineer who was capable of working independently if need be while pairing on the initial designs and features.

Also, Pair programming helps increase discipline and productivity. How you ask ? Well, I tend to loose focus quite easily, and love to be caught up on my emails (the thousands that spam me everyday, sigh!). And replying to my IMs takes precedence, often interrupting my thought process. Now I was pairing on the other hand, out of respect to my pair, I usually end up closing all such external annoyances, and often get two to three hours of uninterrupted work. Does wonders for my productivity, which is why I often roam around look for people to pair with.

Of course, if you need to convince management why you need to do pair programming, you need but point them at the multitude of studies that have been done which show an increased quality in software developed while pairing as compared to individuals. Also, if a person ever does end up leaving the team, there is someone on the team left who has paired with him and thus there are no systems which are alien to everyone on the team ever. And hey, its fun to pair, think out loud and bounce ideas off of each other. Seemingly impossible problems may seem easier as well when you pair. Often times, I seek out a teammate to bounce ideas off of, and more often than not, he will say “Alrite, let me get my keyboard. Lets pair on this.” Then it would take two hours to churn it out, and we would have a working, tested prototype by the end of it.

Of course, on the other hand, there is the intimidation factor of pairing with someone who seems much more knowledgeable and would eat you for lunch. Not to mention possible ego clashes and the fact that some people might find it akin to tutoring if they are paired with someone new. But these are pitfalls that can be overcome quite easily with a dedicated team.

And pair programming works really great when you do Test Driven Development. TDD is the art of writing a failing test before going and writing just the amount of code to pass the test. When you practice something known as ping pong pair programming with TDD, it becomes quite interesting and fun. In this, one person writes a failing test, and then the other person goes and writes the bare minimum code to get the test to pass (That is the key, the bare minimum. Don’t do speculative programming). And then, they switch. So the guy who wrote the code the first time now writes the next test, and the other person implements the functionality. This ensures that both people get turns at writing code and tests, and can make sure they cover all the cases. You end up with well tested code, but just enough code for your need. No speculation, no unneeded generalization, nothing extra.

And of course, no agile practice post is complete without an obligatory dilbert comic, so here goes :