I came, I coded, I debugged.

Even the trivial things are not A common activity the vast majority of software engineers share is working with code. There are many programming languages out there, some are statically typed, while others dynamically. Some are object oriented, and some are functional. Others are still trying to make up their mind (just kidding, we love you Scala!!). Regardless of the programming language at hand, in the end, working with code means manipulating code. These manipulations can be read-only, e.g., code navigation, or mutating, where existing code is being changed, and/or new code is being written, or both. Not only is manipulating code a very common activity for software engineers, some would argue that this activity is what takes up most of one's time as a software engineer, or at the very least, one of the top activities software engineers spend time on. Other activities includes consuming coffee, debugging, context gathering, etc.  Manipulating code is not trivial. For example, in...

When I tell people how strongly I feel about my IDE preferences they are often surprised and go all "haters gonna hate" on me. Being all into empirical software engineering, here's a post on the little things that make all the difference between Eclipse and an IDE that actually puts effort into trying to understand people who write code (Java in our case).

A short one. I've already posted about IntelliJ in the past , and judging by my enthusiastic PR for IntelliJ IDEA someone might mistake me for a share holder. Well, I'm not, though come to think of it, it might actually be a good IDEA (pardon the pun). I just love working with IDEs that understand developers and make things easier on them, and IntelliJ does just that. I've recently been brushing up my (automatic) refactoring skills, and IntelliJ has some really awesome stuff to offer in that department. Truth be told, there are some issues here and there, but hey, I have my bad days too. All in all, for me it's done the unbelievable job of making programming in Java ... kinda fun, not a simple task by any means. I even managed to enjoy editing a bash script the other day, I mean, that's unprecedented! All that before I even had a chance to try out the Ultimate edition, as I'm working with their (free!) Community version. Speaking of community, check out th...

Same JAR, different version.   If you have multiple projects in your workspace depend on different versions of the same JAR, Eclipse will hand out all of them the same version, which is the one it happened to load first. Uncool . IntelliJ handles this case properly. Spring support. IntelliJ is capable of certain  tractability  between your Java and your spring XML context. For instance, if you refactor a class name, its bean will be renamed accordingly. You can also navigate from your Java class name to its corresponding spring bean . How cool is that? Static imports. Because I simply hated looking for the proper import for every Hamcrest static  mather  I needed. IntelliJ suggests to add them for you. Out of the box SVN integration. IntelliJ supports SVN right out of the box, no need to download any SVN plugins or tweak any configuration files . Not a biggy, but it's nice  nonetheless .

Every now and again you might require for some additional resources to be present in order for your unit test to properly execute. This seems as a reasonable requirement, and MSTEST has indeed addressed it with what goes by the name "Deployment". To configure deployment for your unit tests double click the "Local.testsettings" in your "Solution Items" folder, you should be able to see a "Deployment" option on the left side, allowing you to add files and folders to be copied alongside your unit tests. So far so good.