|
What tools do you use to push your code base around? |
||||||||
I've been developing in more and more random locations recently, and finally got fed up enough with manually moving and synchronising my own (local) development code that I've switched to an online SVN repository.
I used to use Beyond Compare for file syncing different code bases, instead of revisioning. It is good, but it isn't particularly quick, and you have to be thorough as it is still very easy to miss a file.
I had an online repository provider recommended to me, http://beanstalkapp.com/.
I've been using them a few weeks now, and they seem really good. They are always 'up', and the connection holds a good speed. There is even a free account if you just fancy trying it out.
The problem I had then is that my code was nicely versioned, and synchronised, but it was not on my live server. Pushing files up to live still required me to know what files had been changed, which is not ideal.
As I use Eclipse I thought I'd search for an Eclipse based FTP client, I've had no luck though, I just can't find an Eclipse based FTP synchronisation tool!
Luckily I had previously used Beyond Compare, searching around in their documentation it turns out that it can also handle local-to-ftp file/folder comparisons.
So for now I've settled on these applications, they both seem to allow me to release stable complete code versions. It would be interesting to see what toolset other developers have arrived at. I've had some exposure to GIT and ANT, but this seems a more comfortable process.
|
Testing methodologies - Regression testing |
||||||||
One of the more overlooked forms of testing (you do test don't you?) is regression testing. I'm a big fan of scripted testing using both scripted tests to actually run against your code base (think cfUnit or Junit) and scripted testing as in a basic word doc of testing instructions.
This word doc can be as simple as 'click button N' - what displayed on screen? You can literally just list the actions, expected consequences and actual conqequences.
Regression testing is the practice of going back after a release and testing the functionality that was already present. IE did you break anything by releasing your new functionality. Often the business and IT focus is on the shiny new development, not the integrity of the existing application.
Developers in particular are guilty of zoning in on the specifc area that they are directly involved with. This can sometimes lead to other areas suffering, especially if you have an OO application layer. In just how many places is each individual object referenced? A change to it may work in one area, but have devastating consequences in another.
I've seen cases of this where its been months later before an error has reared its head, and without an accurate change log it can be difficult to track the root cause down. Needless error tracking and bug fixes take developers away from actually developing, and essentially cost the business money due to bad practice.
I mentioned scripted testing above as it has had unforseen beneficial consequences. If you have done anything like this in the past, your regression testing will be very easy. You will have a handy library of repeatable scripted tests, so it is very easy for you to measure the previous results against any new tests you might perform. Thus making it instantly obvious wether your functionality is still behaving as it was before the release.
|
ColdFusion scoping issues and the Var scope |
||||||||
One of the more common problems with a ColdFusion application, especially when it starts to grow or involves more than one developer is variable scoping, and scope bleed through issues. More recently I have had to re examine the framework of an application, in an effort to track and eliminate any instances of this.
Not properly scoping a variable, IE:
Forces ColdFusion to add the variable to the 'variables' scope. This scope is available to the entire template. This is even more important when you consider CFC's and the potential damage that a leaked variable could cause. One of the major benefits of OO in ColdFusion is the encapsulation that it provides. As soon as you start declaring un scoped variables, then you lose that.
Mike Schierberl has quite an in-depth blog about this subject, http://www.schierberl.com, he goes into a great deal of depth about this subject, and he has built and maintains the varScoper project. The varScoper allows you to scan your code base for un scoped variables, and after a quick inspection of its output it seems very reliable. I'm not sure its 100% foolproof, but would be a valuable addition to a QA process.
Changes to the Var scope in Coldfusion 9
I am currently not using ColdFusion 9 in any environment; in fact my hosting company is still on 7! That said it appears that there are some significant changes to the Var scope in ColdFusion 9.
Ben Forta sums it up nicely here:
http://forta.com/blog/index.cfm/2009/6/21/The-New-ColdFusion-LOCAL-Scope
He does touch on an interesting point in the article above. I quite like the structured layout of a CFC, and part of that regime for me is declaring all the Vars at the top of a function. It sort of matches the layout of an Action Script class as well, declaring all your constants etc at the top of the script. It is also a very easy coding standard to adopt and enforce if you are part of a larger team.
|
Introducing third party applications into your frameworks, good practice? |
||||||||
A recent development involved some changes to a large script that was using a product called ImageMagick (link). It is an image manipulation tool that allows you to perform transformations and other actions on image files. The product seems stable enough, and can be executed from a web interface using cfexecute, in a kind of command line prompt method.
It got me thinking as to why the application wasn't using cfimage, and then lead me to examine the wider topic of whether to use ColdFusion's in built functionality, or opt for other third party products.
I can think of a few obvious deciding factors for both pro and con, the first that springs to mind is performance.
Is there a marked performance difference between a ColdFusion function, and the third party application? Is it better to pass the load of to the operating system, rather than have ColdFusion perform whatever processing function it is supposed to do? In this case it would be a race between cfexecute, and cfimage, so there may be very little difference in it.
The second major point that springs to mind is the knowledge base of the developer, and the structure of whatever framework you are using. What I really mean by this is 'if your chosen technology can perform a function, why not utilise it to its full potential?' . It seems a bizarre choice indeed to deliberately not harness a function that your platform can already provide, and instead introduce another code base or application into the framework.
It also introduces another hurdle for the development staff, they may well be familiar with how an existing Tag works, but be totally unaware of the third party application, as was my case here.
A long winded intro, but here is the code I used:
2<cfset variables.destination = "C:\dev\images\testimage.jpg">
3<cfset variables.source = "C:\dev\images\testimage.jpg">
4<cfset variables.width = "100">
5<cfset variables.height = "100">
6<cfset variables.exec = "C:\dev\apps\imageMagick\convert.exe">
7
8<!--- executing an external application version --->
9<cfexecute name="#variables.exec#" arguments="-size #variables.width# #variables.source# -geometry #variables.height# -strip #variables.destination#" variable="imageinfo" timeout="3" />
10
11<!--- CFimage version --->
12<cfimage source="#variables.source#" action="resize" width="#variables.width#" height="#variables.height#" destination="#variables.destination#">
