Category Archives: Programming

Old Games and Old Memories

I had been digging in my email account for some reasons and voila I found the binaries of two games I developed around year 2000. These games were written in FoxPro as I found FoxPro very interesting those days. I used to develop financial apps in FoxPro and I still believe that it was a good development platform albeit not suitable for game development but anyways these two were simple text based games. I just downloaded the binaries and they still work but via ‘DOSBox’ which is a Dos emulator shell for newer windows version.

I developed these games to basically promote the services of the company for which I did freelancing. I figured that with some free games floating around people would find out about this company. Actually the plan failed miserably as I don’t think we made any new contact that way. But the games still work and it feels nice to see them operating after all these years. I would have loved to tweak around the source code if I still had it 🙁 but those were the days when I had still not learnt anything about Version Control and Backups.

I still remember the pride with which I included my name ‘Abhinav Anand’ in these game titles. I loved putting my name in everything I did and I still feel that branding is important for your work.

Splash Screen for Tetris

Splash Screen for Tetris

Game Screen of Tetris

Game Screen of Tetris

Congratulations Screen of Tetris

Congratulations Screen of Tetris

Puzzle Game Screen

Puzzle Game Screen

 

Gradle the build and dependency management tool

I recently had a chance to evaluate and Gradle and I am impressed by the Groovy based scripting feature it provides. It is really possible to make sophisticated build scripts using scripting constructs like looping and if checks. The functionality to selectively disable parts of the build on the fly and make build decisions based on some condition really makes it a winner and a clear choice for Java based development. It has support for using Apache Maven and Apache Ant build scripts as well inside the Gradle build script which means current investment in Apache Ant and Apache Maven remains intact. I think I am going to give Gradle a serious try in my next project and if it performs as I hope for I am going to switch to Gradle for good.

I am die hard Apache Maven fan for all my Java based development and configuration need. In spite of all the criticism it has received over the years I have remained a staunch supporter of Maven. I delved in Apache Ant whenever I needed some extra punch in my Maven build scripts. The XML based configuration although at times felt very verbose but it did work and it was possible to write portable build scripts that worked everywhere. However if Gradle allows me to write Groovy based scripts inside my build script then I think its time to switch to Gradle.

JavaFX on the Horizon

When JavaFX was launched in 2007 I had thought that Sun had already lost the race of RIA and RCP platform to Silverlight and Adobe Flex. Plus the fact that JavaFX required the developer to learn a new scripting language was a big turn off. Although it’s not a big deal to learn something new but re-training an entire team on something new when a better replacement is available was simply a tough thing then. I could have designed some of my projects using JavaFX but I consistently used Swing as I felt it was the better framework.

Fast forward to 2011 JavaFX was re-launched and the need to learn a new scripting language is no longer there. It is possible to reuse developer’s Java knowledge and become productive in JavaFX. If I had to start a new Java Desktop based project I would definitely try JavaFX before delving in Swing. Agreed Swing is a proven and mature UI framework but there are limits to what Swing can do. Maybe JavaFX has a future now that Oracle is pushing JavaFX 8 later part of this year. JavaFX 2 to JavaFX 8 seems like a quantum leap in terms of version and maybe it might counter balance Swing in terms of performance and maturity, but again who knows the future 🙂

I personally think now that Silverlight is a stalled technology and it’s unbelievable that Microsoft was not able to push it to dominance. It is grimly evident with the news that Netflix ditched Silverlight in favor of HTML5. Adobe Flex looked like a clear winner 6-7 years ago but given the fact that now it is open source I think it is clear that Adobe is politely walking with away from Flex with some contributions from it’s end now and then from their ‘dedicated team’.

This brings us back to JavaFX and I must honestly say that I still find it unbelievable that it is still around and might become the UI framework of choice of Java based desktop application software. I don’t think JavaFX has a future inside browser but it might become a framework of choice for Java’s desktop requirements.

For browser based development nothing beats HTML5 I think. Love it or hate it I think it is bound to be around for considerable time to come. It however remains to be seen how well it is supported by different browser both on mobiles, tabs and desktop OS.

Founding Principles for a Development Shop

A development shop can be broadly associated with service delivery (consultation and service at cost) or product delivery (product sold at cost).  I think the following principles could be applied to both:
  • Always try to Innovate
  • There are different ways of solving a problem. Try finding the best approach.
  • Have faith in your teams capability to deliver anything.
  • Have faith in yourself and believe that you have potential to change the world.
  • You need to have flexibility and the capability to move fast.
  • Always try to work in the team but also hold your identity.
  • Believe in sharing knowledge and tips.
  • Trust your colleagues.
  • Avoid bureaucracy and politics like plague.
  • Customer is the king. If a customer doesn’t know something be ready with a training session.
  • An absurd idea is not always a stupid idea. Be open and receptive.
The core belief is the willingness to innovate and allow customer to be the final judge.

Traits of a bad programmer

A bad programmer is somebody who I personally consider a liability to any team. This category of programmers have the potential to bring down a project and even a full team. It is always better to either notify them of their deficiencies so that they improve or to ultimately save the team by removing them. I tend to identify a bad programmer from their following traits:

Lack of curiosity
If a programmer is not curious about the API and considers superficial knowledge as sufficient then it is the first warning bell that this particular person will have a mediocre knowledge and as a result mediocre performance.

Difficult to Understand Code
If the code a programmer writes is bug laden and the code itself is messy and unnecessarily large then you are dealing with a bad programmer.

Lack of Depth in Knowledge
Superficial knowledge about a topic is a dangerous attribute of a bad programmer. This can bring less than optimized behavior in the software. This superficial knowledge can range from programming API, tools of trade and even the problem domain itself.

Unwillingness to do defensive coding
A programmer has to consider lots of scenarios which can be documented as test cases or even unit tests. If a programmer only considers a general scenario and fails to accommodate the not so general scenario then the result is often a bug laden software.

Unwillingness to comment or improve code
A commented source code is an asset and an un-commented source code is a liability.  A programmer rarely works alone and if the source code written by them is not documented then it doubles up the amount of time required to fix their code. If a programmer never has time to comment the code or even simplify the code by writing smaller pieces of a large piece of code then this is a dead give away of a bad programmer.

Aversion to feedback
Any programmer worth his salt should be open to feedback from his peers. If a programmer is unfazed by negative feedback and doesn’t consider his responsibility to fix his code as a result of feedback then he is a bad programmer. A programmer should learn to make decisions based on experience and also the feedback received from peers and customers.

Eclipse RCP – Application … could not be found in the registry.

While trying to integrate Eclipse Forms into an existing Eclipse RCP application I encountered a launch issue where the launch failed with this error:

java.lang.RuntimeException: Application  could not be found in the registry. The applications available are: org.eclipse.equinox.app.error.

Well the strange thing was I could do the relevant import of Eclipse Forms package in the Java editor while doing development but I got the above error while launching it. I thought it might be launch configuration issue so I went to Project Properties > Run/Debug Settgins > [Select Launch Configuration] > Edit. This opened up the Edit Configuration dialog where we have a Plugins tab. In the plugins tab sure enough the Eclipse Forms plugin was unchecked. I checked this check box for this plugin, saved the configuration and launched the application. This time no error happened.

By default Eclipse RCP didn’t tell me what the problem was. I spent some trying to guess the problem before finding the solution. The lesson from this experience is that we should always use “-debug” argument in the launch configuration as it clearly outputs on log any error which might not be properly reported via error dialog.

Interesting Articles 13 July, 2011

Here are some interesting articles I found from various sources.

Java Meets Objective-C

Secure Login in AJAX Applications

Sizing Android Visual Elements Correctly

Adobe Woos Mobile Developers With Flash Builder 4.5 and Flex 4.5

Secure Login in AJAX Applications

11 Insider Tips You Must Follow If You Want Your App To Succeed

How To Create A Game Like Tiny Wings Part 1 Using Cocos2D

iOS 5 beta 3 released for Apple iPhone, iPad, iPod touch, Apple TV