I did not see that coming.

It is very nice of them. I hope it will help them to spread the IDEA more. I am often considered to be weirdo by my colleagues (present and past), because I pay for editor while I can have "worse one" for free.

I understand Jetbrains needs to keep some income so they have split it to Community and Ultimate Editions. Unfortunately I am addicted to some features from Ultimate Edition so I might stick with paying one in the future. I hope it will not get more expensive to compensate for "lost sales". I will see, maybe I will be able to downgrade, or I will just buy cheaper RubyMine as my "web development" is done in Ruby.

Huray!

My favourite plugin for IntelliJ IDEA TestDox finally works in EAP of version 8. So I can see nicely formatted test outline again. If I needed to wait longer I would be afraid that I could stop using pattern testShould... that I like so much :-)

For those who are not familiar with this approach it as as follows. Tests should describe what tested class should do. So it helps if test methods are named accordingly - describing expected behaviour. The best naming convention is testShouldDoSomething which should read as a sentence in English (of course name of tested class, or tested class in some context, makes begining of the sentence).

So for example let's have FullStackTest (specification) with method testShouldThrowExceptionAfterPush. This is time when TestDox cames into picture - it is able to convert it to Full stack should throw exception after push. Which feels really like specification of behaviour. And that's whole point. It seems subtle, but it works miracles. This plugin helps me to create good test names. It is even more important when I have lazy mood, because it motivates me to do so.

Its biggest disadvantage is that my Eclipse-based colleagues do not have anything like this (I tried to find it several times without any success, so if you know about something similar, tell me please).

Note: I have tried to update it to new IntelliJ IDEA API myself, but it was changed a lot and without any previous knowledge of IntelliJ plugin development and without complete list of changes I failed.

I was struggling with running our unit tests in Idea for some time. Problem was that we have many modules and some of our tests using files try to find them through working directory instead of classpath. So every time I needed to execute test/suite from different module I needed to change working directory of test to point to its own module.

Finally I was able to find great solution (I really do not understand why I did not try it sooner :-) ). Just open Run/Debug dialog, click to Edit Defaults and write $MODULE_DIR$ into Working directory: field.

Project I am currently working on has rather sophisticated build system. I believe that huge project as this one is deserves it. It has many advantages and a few disadvantages. Problem is that it is optimized for Eclipse as all developers are using it.

Unfortunatelly, some features like:

• dependencies between modules done through jar files
• regeneration of Eclipse's project files by Ant (needed every time you update jar files)
• dependenent jars copied to target/
• fact that Eclipse does not distinguish between production and test sources

made my life with Idea miserable in the beginning. It used lot of memory, was slow and needed refresh of internal data often (very slow in Idea) and remote debugger was not able to switch to different module. I gave a chance to Eclipse (3 weeks) before returning to Idea with goal to overcome all these problems (plus those happening in Eclipse too like impossibility to refactor between projects) by custom scripts.

I started slowly, then I added more features. Because my goal was to fix problems in Eclipse/Idea integration, fix disadvantages in dependencies as well as to fix management of project I rejected an idea to create plugin as it would need learning huge Plugin SDK and it could not help me to solve all problems. I decided to go through command line scripts (not to mention I never liked to do project management related tasks through IDE). My scripts are done in Ruby.

I am able to clean all projects in directory by subsequent calling of 'ant clean' in all subdirectories:

def clean
    in_dirs_with 'build.xml' do
        system 'ant clean'
    end
end

I was really nicely surprised seeing how nice and readable those simple tasks could be. I added a few more:

def update
    in_dirs_with '.svn' do
        system 'svn up'
    end
end

def eclipse
    in_dirs_with '.classpath' do
        system 'ant eclipse'
    end
end

All magic is hidden in following method:

	def in_dirs_with(guard)
		Dir['*'].each do |dir|
			if File.exist?("#{dir}/#{guard}")
				puts "Processing #{dir}..."		
				Dir.chdir(dir) do
					raise Exception.new($?) unless yield
				end
			end
		end
	end

OK, less annoying things are handled, now I can get to fixing problems with Idea. I am not going to show any code for that, it is bigger, but I will describe what I have done:

• script finds all generated .classpath and replaces jar dependencies with known sources (fixed refactoring and debugging problems)
• script finds all .eml files (Idea keeps here information what .classpath belongs to module and what is missing in .classpath but Idea needs it). Script modifies it by stating which directories are tests and which directories to exclude from project.

With these two scripts my life is wonderful again (as it was before I joined this huge project with build system optimized for Eclipse). Idea responds immediately and I can refactor as no of my colleagues can :-) (well, they could use the one wiring modules together, because it modifies only .classpath, but they would need to install Ruby first).

Apart from that I have created small DSL that helps me to perform merges (merging multiple modules in Idea is rather annoying), but I needed it only twice. Example how merging file might look like follows:

Merger.new.
	from_revision(12305).
	from_branch('http://server/svn/branches/mybranch').
	to_branch('http://server/svn/branches/head').

	add_new('new_module').
	add_new('other_new_module').

	merge('changed_module1').
	merge('changed_module2')
end

If I tried to do it in Idea (similarly in Eclipse) I would need to state revisions and branches for every module that needs to be merged. Small script helped enormously with 10 modules I was merging last time. (Note: add_new is for adding module that was created in mybranch so it cannot be merged directly to head, at least I am not aware of directly working solution).

Doing these things is called yak shaving and considered problematic, but I have to say, my yak is shaved very well now and I guess time invested has been paid off for some time already.

I am big fan of two programs. Big means that I bought also upgrade. It also means I used to advocate both of them. This is not the case with one anymore. These products and their companies have many common things and many differences. Let's look at them both.

Similarities:

• Both products are excelent in what they offer, they have many unique features
• Both are commercial products surrounded by commercial and free competitors
• Both companies need to release new version every year to keep income
• Both companies need about half a year for finalizing public version to finished state (see later!)
• Both companies have a lot of bugs reported by customers which is normal (see later!)
• Both companies need to balance enhancing existing features vs. adding new
• I resist upgrading to new version of both products until some killer feature is added I must have
• Both products satisfy my needs in their respective area
• I have bought at least one upgrade of both of them in past
• Both companies distribute their products mainly through web (see later)
• Both companies have associated discussion forum for their products (see later)
• Features of both products are copied by competitors
• Both products need a lot of computing resources and are a bit slow (that means if they were twice as fast, I would be glad)

Before I get to their differences I am going to disclose them. I am comparing JetBrains with their IntelliJ Idea and DXO with their DXO Optics Pro. One is for SW development, other for processing photos from DSLRs (how surprising from me :-) ).

Differences:

• JetBrains starts with Early Access Program that can be used by owners of previous version for free, getting valuable feedback about problems and features driving final great product. DXO releases final (paid) version that is completely useless till version x.2
• JetBrains' developers are active in discussion forums trying to help, DXO ignores bug reports and tries to blame customers (indirectly for buying their terrible product!)
• When JetBrains releases new version it contains change list (detailed for EAP, somehow more generalized for update). DXO is able to release several updates without saying what was changed.
• If you buy new computer, update version of Java or switch to another language/library, there is fair chance you still can use your version of Idea. If you buy new camera you will probably need to buy new version of Optics Pro. Or if your new camera is supported by existing version of Optics Pro it is possible your existing lenses are not. And upgrading might not help you.
• I have seen JetBrains' server down, but DXO is master in this area. Many people are not able to download product/update, downloaded file is corrupted or even users are not able to activate their license after they paid for it. It can take days to be running again.
• Some people (former users of Optics Pro) are coming to forum for fun - to see how other more tolerant people struggle to use Optics Pro and are abused by DXO
• JetBrains care about their customers, DXO does not
• JetBrains care about their image, DXO does not (I am sure their management is not stupid, thus this conclusion is only one that I could make)

Am I going to buy upgrade of these products when they are finished?

• JetBrains: I am already using their 8.0 Milestone 1, hence the answer is probably yes.
• DXO: I am afraid to install their latest update 5.2.1 because nobody knows what was changed and there are long discussions about broken reading on RAW files. Nobody knows what will be offered by 6.0 and I hope I will not buy a new camera supported only by 6.0 if I still want to use my version of Optics Pro.

Why I preffer attitude of JetBrains?

• By releasing EAP soon and often people can try it to see if it works for them. As software developers they are usually striving for new features and they get them. Basically they get addicted to new version long before it is done!
• Released EAP has usually lot of bugs, but people do not feel robbed compared to what happens after paying for Optics Pro that is full of bugs (and refuses to start). Nobody will bash JetBrains, because the newest build (Release Candidate or even less) has 1234 bugs, but there are not many phlegmatics that would be satisfied with wonderful marketing materials promising something it cannot deliver 10 months after paying for product, because it is unstable and full of bugs. (To be fair, I waited patiently 8 months since 5.0 was shipped and bought 5.1 and I have never experienced the worst things described in forums. I consider myself lucky).

Why I wrote this

Now I am getting to reason why I am writing this. My intention is not to mock or ruin business for DXO. They are self sufficient it this area. Contrary, I try to help them in only way I can. Please, DXO, start to behave as a comercial company that plans to stay in business and start to do what your customers deserve from you. I have given you one example worth of following.

Oh, there is one positive twist about all this - I am really happy I did not encourage anybody to buy Optics Pro 5.x. I would not be able to apologise enough for that!