Up until now I’ve been using a fairly standard capistrano deploy.rb. The problem is that as we speak I’m trying to deploy a patch from my Windows work machine and it’s not working. The ethics of fixing one of my project from home aside, this is a problem. When I try and deploy the following error  comes up

can’t convert Net::SSH::Authentication::Pageant::Socket into IO (TypeError)

The change I was trying to deploy stops in its tracks. After quite a bit of searching I found a thread about the error that dates back to Capistrano 2.5.3… from 2008. What a shining example of open source.

To be fair the error isn’t necessarily in Capistrano, it may in fact be in Net::SSH. The sad thing is that we’re over a year later, and nothing has been done to fix the problem. Is the number of people that use Ruby from Windows machines so low that no-one has managed to fix it in a year?

I’m not expecting Jamis to fix it. I get that he has too much to do, and doesn’t have time to give out a bunch of freebie support, but I’m now faced with the choice of either trying to fix the problem, a task I don’t currently have time for, or ditching capistrano.

I’ve considered switching to heroku in the past and just never made the leap. For a start the app in question has to many moving parts for heroku. One thing I did like though was the notion that to deploy all I had to do was ‘git push target master’  and the app would be updated and deployed.

After toying around with rolling my own solution, I stumbled upon mislav’s gem. It lacks some of the features that I’m looking for, but its a good deal closer to the level that I need. It lacks the bloat of capistrano, which is important, because the biggest barrier to me getting in and fixing capistrano would be the size of the library and knowing where to start.

I very quickly migrated my existing application to use git-deploy. It’s not perfect for every problem, particularly if you’re doing multi stage deployments, etc, but at least I’ll be able to do a deployment everywhere I can get access to git now.

I’ve spent the majority of the last 2 days trying to get DA 6SP1 Patch Release to install properly on IBM Websphere 6.1.0.23. It had been a while since I’d last done the install, and I fell into the same traps as last time, forgetting where to set the class loader and so forth. After getting past these I was left with the application unhelpfully still showing a white screen and error messages that revealed (looking back) very little about the true nature of the problem. Having finally conquered the problem, I thought I would provide the steps necessary so that anyone else trying to get a WDK application working on Websphere as at least one more thing to try.

Grab a copy of da.war from the EMC Powerlink Download site.

• Unpack da.war and add the following files to a directory
• Put dfc.properties into WEB-INF/classes (As described in the deployment guide)
• ibm-web-ext.xmi & ibm-web-ext.xmi goes into WEB-INF – https://solutions.emc.com/emcsolutionview.asp?id=esg91105
• Find a copy of xml.jar on the Websphere App Server in ‘Websphere\AppServer\java\jre’ and put in ‘WEB-INF\lib’ - https://solutions.emc.com/emcsolutionview.asp?id=esg93106
• Install the application using the IBM Administration Console.
• Change the order the classes are loaded in by expanding the Applications node and click the Enterprise Applications node. Select the application called da_war (or equivalent wdk app). Click the Manage Modules link. Click the da.war link. In the Class loader order drop-down list, select the option ‘Classes loaded with application class loader first’ – https://solutions.emc.com/emcsolutionview.asp?id=esg93177
• You can then save and start the application.

The xml.jar file is appropriate for D6SP1 only, previous D6 versions have a slightly different set of instructions (see linked support note). Any feedback, corrections, suggestions greatly appreciated.

It’s been almost a month since my last post, disgraceful. While I have the will to maintain a blog, I certainly don’t have the time. We’re currently in the thick of a large Documentum deployment, which means that there are bucket loads of new users that each have their own issues with the system.

I have learned SO much over the last few months, hopefully I’ll have a chance to sit down over the next week or so and distill some of that wisdom. Until then, keep safe.

Recently I’ve been doing quite a bit of development in Java. Of the many languages that I’ve played with and used I find Java to be one of the most functional programming languages out there. There are plenty of factors that have helped me choose Java as my primary programming language, and while I’m not under the illusion that java is the ‘monkey wrench’ of the programming world, its still an invaluable tool.

I’ve been around programming languages for the last 6 – 7 years, in that time a lot has changed. The software industry has matured in its approach to programming, and the fundamental building blocks that make up the software industry have matured as well. Gone is the time when you needed a PhD to understand the complexities of computer programming. This is not an article about the many different languages; this is not even an article about how Java is better than ‘x’ language. This is simply an article about the features of Java that slipped it into my toolkit.

Native Graphics Support

The first thing that usually pops into mind when you want to convince someone about the superiority of java, is the fact that it’s a compile once run anywhere language. Honestly though I find this less useful than you might think. What I do find useful is the fact that with very little research you can write a graphical user interface for an application. I find the graphics support for Java to be logical, where so many other graphics libraries are not. While I’m not overly fond of the layout managers that Java provides, I can appreciate the fact that they’re there if I do ever find a use for them.

Excellent Database Support

This was one of my primary reasons for moving to java in the first place. If you’ve ever tried to get MySQL working with (Visual) C# then you’ll know what I’m talking about. The JDBC makes connecting to whatever database a dream, if your program is well written you can even switch database backend without to much trouble.

Eclipse IDE

If you haven’t tried Eclipse then you don’t know what your missing out on. While its certainly not solely dedicated to Java it’s a very flexible and well designed tool that will help you get your work done. In addition to being a useful portal to the Java language, it is also a driving force in making Java into more than just the pet project of Sun Microsystems. Take a look at SWT, which was originally developed by IBM and is distributed as a part of eclipse and you will begin to understand.

Lack of Deployment Options

This is one of the fundamental failings of a lot of programming languages. Running a java program relies on the operating system already having a copy of the Java Runtime Environment (JRE) installed. If its not then you won’t be able to do squat, additionally there is no way of knowing whether the version of Java that you’re programming in, and that has the features you want is installed on the client.

You fall back into the same rut that the old VB programs had with missing DLL files. There is no simple way of installing both Java and the given Application in one easy step. Additionally you are held hostage by the fact that you require certain environment variables to be set correctly for the java program to run (JAVA_HOME, CLASSPATH). This is all well and good but it’s just more overhead for the programmer to worry about when they need to do a large scale deployment of an application that they’ve developed.

GCJ bridging the gap

One of the baseline flaws with Java is the fact that it is interpreted (from bytecode) at runtime, and as such relies on the JVM. More importantly it means that it runs slower on CPU intensive processes like md5 hashing for example. GCJ is the GNU Toolkit’s answer to the fact that Java is not open source. It is in effect a complete replacement for Sun Java. More importantly it provides support for compiling Java directly as an Executable freeing it from the reliance on the JVM.

The speeds generated when running is GREATLY improved, to close GCC/G++ levels, and more importantly the deployment is less of an issue. You do lose the fundamental portability that is gained with Java classes, but there is no reason you can’t provide the class files and just install GCJ (rather than Java) to allow the class files to be converted into executables.

THE only place where GCJ is still lacking is the area of AWT/Swing; the developers are still working on adding the support necessary to support the windowing toolkits. Incidentally they are looking for help in this area if any of you programming gurus want to give up your spare time.

Conclusion

The bottom line with Java is that it is a functional and practical language. The fact that Sun is still holding the reins is regrettable because it’s inhibiting a language with otherwise HUGE potential from maturing. The compile once, run anywhere is less useful than ‘write once / compile (& run) anywhere’ this subtle difference is where Sun missed the boat. The matter of compiling different copies for different operating systems is trivial when you consider the fact that doing it the way they are cripples the speed of the language.

Other than that Java is a great choice because it’s a language that’s flexible enough to be used on plenty of different operating systems. You do lose a certain amount of control over the low level functions; however this particular beef has been adequately dealt with in the form of JNI.