December 18, 2012

IntelliJ and General Development on a Windows 7 Corporate Laptop...

The more development I do with IntelliJ, the more attached I become to it. It works well with my development style and I don't mind the licence costs as a result.

I recently started working on a new project with a company and discovered that they were in the middle of a project to move all its developers over to using a new laptop build based on Windows 7.

They have a great team working on this but they were relatively inexperienced at dealing with developers requirements so they needed some guinea pigs and our team fitted the bill nicely.

When the proposed laptop was first trialled a misconfiguration of the anti-virus meant that they were very slow, as a result our boss was able to demand SSDs... Which was nice. I've been running SSDs on my home development machines to provide the best possible build performance though I always make sure my machines and repositories are backed up to spinning rust.

The laptops with SSDs finally arrived and it turned out that I was the first of the development focused guys to get our hands on it.

Some clever tooling meant that while none of us developers had admin privileges, there was a clear and sensible route for installation of any software that we required. The technique involved meant that temporary admin privileges were given to the install process which meant that our normal users were unable to alter the installed files in any way. This had several implications for the installation of software, IntelliJ in particular.

I encountered a number of teething problems - the first one was that our user profiles were configured to be read from a network share. Fine as long as we were plugged into our head office networks, less so when we were on the road. The most visible problem was the corporate software provisioning tools having a snit fit and not wing able to launch various items of software if we were connecting using a VPN. The VPN could only be launched after login for various good reasons.

Fixing this problem was easy as it only required using the Offline Sync capabilities in Windows 7 on the necessary parts of our profile.

This however pointed to a more significant problem for developers. By default IntelliJ, Maven and other tools keep a lot of their configuration and caches in the profile. This means a large volume of data needs to be sync-ed initially and as the IntelliJ caches are updated and new Maven dependencies are added even more sync-ing needs to happen. Not great across a VPN over ADSL.

The solution is to reconfigure your tools to store these high entropy folders in the local drive away for your profile. This also makes the support team happy as it stops the developer profiles getting too large and clogging up the networks.

I created a 'development' folder specifically for these folders and my projects.

Configuring Maven is easy: create a settings.xml file in your profile fold if you haven't already and override the default local repository location. At the same time you may as well be sorting out your proxies or any corporate Nexus repositories. Set the Maven environment properties on the user environment variables and you're done.

IntelliJ is not too hard as well. I copied the idea.properties file from the IntelliJ bin directory (I couldn't edit it directly as it had been written with admin privileges) and edited it to move my .IntellijIDEA folder to my development folder. I replaced the ${user.home} entry in all the relevant properties with a hardcoded value as replacing it with a self declared property like ${configuration.home} caused the logging to end up in a directory under IntelliJ called ${configuration.home}.

I then needed to tell IntelliJ to use the new idea.properties file so I had to set up the IDEA_PROPERTIES environment variable. This could not be done as a system environment variable but fortunately user level environment variables do the job. It is worth noting that you should be able override the Path environment variable that is set in the system environment variables by setting one up in the user ones. Anecdotally this can be a bit temperamental if you don't match the case of the system one and you may have problems if the admins have locked it down too.

The same process of configuration needs to be repeated for any other tools that like to put things in the profile.

The next issue encountered was when starting IntelliJ. IntelliJ 11 would start but not be able to index the project whereas IntelliJ 12 would fail completely, complaining about being unable to start webserver processes. It turned out that the McAfee firewall had been configured too aggressively and local loop back calls (localhost and 127.0.0.1) were blocked. A quick chat with the support team sorted this one out.

The last major issue was with performance due to McAfee Data Loss Prevention (DLP). I'd encountered this before on other corporate sites. You need to ensure that your development folder is excluded. This is due to the number of files typically deleted due to a Maven clean install cycle; DLP just eats CPU and slows disk access to a crawl when this happens. Once more the support team came to the rescue.

Once these issues were sorted I was delighted to have a corporate laptop that was entirely pleasant to develop on. As a bonus we were given widescreen 27" monitors, I was able to rotate mine to landscape mode and view entire classes at a time!

- Posted using BlogPress from my iPad

No comments: