My Digital Life
Apologies for the repeat posting, but the earlier link to the syntax file was not working. The webserver was not liking sending back .ini files (which is the extension of the syntax file).
I’ve uploaded the syntax file again with the original entry. This time it is a zipped file. You’d need to unzip this into the {PSPad install path}/syntax directory.
Thanks to Ken Auenson for pointing this out.
Indy
Loose typing of ColdFusion variables is arguably one of the key factors that contribute to rapid application development.
However, the lack of any standard in which variables are named causes considerable grief, especially when working on large-ish ColdFusion application, in a medium to moderate sized team, over a period of time. Different developers start using different “conventions” for variable names and those “conventions” become more like fashions that come and go with each season.
And of course this is bad because it adds to the total time spent on maintaining legacy code.
Over a period of time, after trying various ways of naming variables (or using Hungarian Notation), I settled on using following.
| Prefix | Data Type | Example |
|---|---|---|
| a | array | aItems |
| b | boolean | bValue |
| c | single char | cVar |
| i | int | iNumber |
| f | float | fNumber |
| l | list | lItems |
| o | object | oComponent |
| q | query | qGetRecords |
| s | string | sName |
| st | struct | stItems |
| u | UUID | uObject |
| w | wddx | wPacket |
| x | xml | xPacket |
Here is a simple “Hello World” type of application using Cairngorm Extensions from Universal Mind.
This application demonstrates the following two features of the Cairngorm Extensions:
A detailed list of features in Cairngorm Extensions is available on the Google Code site for Cairngorm Extensions.
This Flex application simply displays a text area box for where a user can input her/his name, and then click on one of the two buttons. Depending on the button clicked, the application displays greeting with the name of the user.
This is sort of a follow-up on an earlier post that I had made: Life after Subversion.
I’ve been toying with the idea of moving from Subversion (a centralized version control system) to a Distributed Version Control System (DCVS) like Git, Mercurial or Bazaar for about 6 months. I played with Mercurial and Bazaar earlier this year and found that moving our development from Subversion to Mercurial or Bazaar was was a fairly significant change.
Over the last few weeks I’ve been looking again at Git. Obviously there are lots of advantages of using distributed version control system. However, what I found was that there are quite a few issues that I had to consider before making the jump from Subversion.
Before I talk about these considerations, here what what Wikipedia defines a DCVS is:
distributed revision control takes a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository with which clients synchronize, each peer’s working copy of the codebase is a bona fide repository. Synchronization is conducted by exchanging changesets, which define unique versions of every file, from peer to peer.
So here are the factors that I had to consider when thinking of moving to a distributed version control system.
I (and the team I work with) primarily use Eclipse for ColdFusion and Java development. There is excellent support for Subversion in Eclipse through two plugins, Subclipse and Subversive. My team mates who use Windows also use the TortoiseSVN extension.
Git lists an Eclipse-based plugin on its website. However, it is still in early stages of development. Mercurial has recently launched version 1 of its Eclipse-based plugin so that is a big brownie point for Mercurial.
But the point here being… IDE support for decentralized systems is still in it early stages.
The primary interface to work with a DCVS is command line. Now I know that developers should be comfortable with using command line. However, there are different types of developers. Also, at times development teams comprise of non-developer individuals like designers, coders, project managers, etc. To expect everyone to start using command line does not work out too well in a team situation.
Obviously the team has to get used to a new way of working with version control. And there is a considerable learning curve there. The larger and more diffused the team, the more of an issue this becomes.
Most distributed version control systems are *nix friendly. Although they have some form of Windows-based port, but those tend to be much slower than their *nix siblings. So if you are a development team that primarily uses Windows, you need to either live with the relatively slower performance of the version control system, or start looking at using Linux (which is a big jump for many in terms of skill sets etc.)
In my current Subversion-based setup, there are other systems that are tied into version control. These include systems to create automated builds, repository viewers and code review systems. Moving to a DCVS would involve investing resources in upgrading these ancilliary systems as well. I’m not sure if there is an easy way hook these systems into a DCVS.
At this point, the time and resources required in moving to DCVS is a major issue. And that proves to be a too large an issue compared to the advantages that a DCVS offers — at least for the the team I work with and type of work we do.
On the whole, the longer you’ve been using Subversion (or any other centralized system) — and consequently the more team members are used to it and the more you have other systems hooked into it — the harder it will be to make the jump.
A couple of weeks ago, I spoke at the RIA conference Web on the Piste 2008 on the topic of “Testing for Success”.
Over the past few years, I’ve worked with many ColdFusion and Flex development teams. It has been interesting to see that there is more interest in test-driven development. However, a lot of times team leaders/company executives overlook the bigger picture and focus on just the details. And the lack of this larger context can lead to less effective/failed testing practices. My presentation this year was focused on presenting this bigger picture with focus on ColdFusion and Flex.
You can download the presentation here or view it at Slideshare.
By the way, for those of you who have not heard about Web on the Piste, it is a conference on Rich Internet Technologies that takes place every year in the beautiful Queenstown in New Zealand.