If you have a need to move your coldfusion CFIDE directory then you will also need to change the CFIDE mapping in ColdFusion administrator. The problem here is that the CFIDE mapping is not editable in the administrator, so it is necessary to edit the XML file that stores the CFIDE path. This file is found in your ColdFusion install location, in my case it is located in /Applications/coldfusion9/lib/. The file we need to edit is named neo-runtime.xml. It is minified, so it is helpful to do a simple find on ‘/CFIDE’. We want to edit the string property of the var element /Applications/ColdFusion9/wwwroot/CFIDE. Change that path to your new CFIDE location and restart ColdFusion. Checking in your ColdFusion administrator Mappings should now reflect your new path.

Hey Googler… restart ColdFusion before you look any further.

I just spent an hour looking for syntax errors in an entity CFC and double checking for case issues throughout an application. As it turns out, even with reinitialization, CF must have been caching and not recognizing the existence of my entity object. Upon restart of ColdFusion server the entity was found and everything worked as expected.
The error was directly related to the use of EntityNew(“EntityName”) and the error would no longer be present when removed. I found solutions which ranged from the case sensitivity, mentioned above, to problems with dependency injection or mapping errors. In the end, CF was caching and the new entity did not exist in the cache. Also, I should note that in my configuration I had coldbox.handlerCaching = false; and coldbox.eventCaching = false;
So, give CF a restart just in case, it might save you some time.

CF Web Server Connector appears to successfully configure during installation but silently fails to connect to Apache Web server.

During a ColdFusion 9.0.2 installation I was configuring CF to connect to Apache Web server and experienced the behavior of index.cfm being downloaded instead of rendering in Chrome. This behavior is indicative of Apache either not running or not having index.cfm configured as a directory index in httpd.conf. The first place I looked was to make sure that I had restarted Apache and it was indeed running. Once verified I went to have a look at my httpd.conf file. The only changes I had made to default conf were changing my DocumentRoot, Directory, DirectoryIndex, and enabling Virtual hosts. Everything looked fine in Apache, except that the JRun Settings configuration had not been added by the Web connector durning installation. Okay, so I figured I blew the install, uninstalled, reinstalled, same thing. On to the ColdFusionLauncher.

Here is where things became more interesting. I started up the CF Launcher so that I could use the WebServerConnector Utility to configure CF/Apache connection manually. Here are some screenshots of my configuration:

This all looks fine, no problems thus far…Then I receive this warning:

At this point I really wasn’t sure what was going on. A colleague, Mike McKellip, suggested that I have a look at the wsconfig directory. I pulled it up and wsconfig has no content. After some more research, it appears there is an issue with the ColdFusion installer on 64bit Mountain Lion. So, what to do… Mike provided me with a wsconfig and a mod_jrun22.so to use for manual installation. Along with the JRUN entry for httpd.conf to complete configuration:

# JRun Settings
LoadModule jrun_module /Applications/ColdFusion9/runtime/lib/wsconfig/1/mod_jrun22.so
<IfModule mod_jrun22.c>
    JRunConfig Verbose false
    JRunConfig Apialloc false
    JRunConfig Ignoresuffixmap false
    JRunConfig Serverstore /Applications/ColdFusion9/runtime/lib/wsconfig/1/jrunserver.store
    JRunConfig Bootstrap 127.0.0.1:51800
    #JRunConfig Errorurl url <optionally redirect to this URL on errors>
    #JRunConfig ProxyRetryInterval 600 <number of seconds to wait before trying to reconnect to unreachable clustered server>
    #JRunConfig ConnectTimeout 15 <number of seconds to wait on a socket connect to a jrun server>
    #JRunConfig RecvTimeout 300 <number of seconds to wait on a socket receive to a jrun server>
    #JRunConfig SendTimeout 15 <number of seconds to wait on a socket send to a jrun server>
    AddHandler jrun-handler .jsp .jws .cfm .cfml .cfc .cfr .cfswf
</IfModule>

You can find the solution details related to creating the wsconfig directory and compiling mod_jrun22.so over on 12Robots.com or Just Another Tech Blog.

I need to show hidden files quite often and rather than leaving the hidden files visible all the time, e.g. .localized and .DS_Store files showing on desktop, I rather toggle hidden file visibility on and off. The terminal command for this is:

$ defaults write com.apple.Finder AppleShowAllFiles TRUE
$ killall Finder

The first line here sets hidden files visible and the second line refreshes Finder. Change the boolean to ‘FALSE’ in order to hide the files again.
This works great but its a pain and I just wanted to make it simple and fast. I’m aware of Hidden Files but wasn’t able to install at the time of this post due to redirection to iCloud, which I don’t use. As a result, I decided to just write a simple Apple Script as an application that I can keep in my dock.
Here is the script:

display dialog "Show Hidden Files..." buttons {"SHOW", "HIDE"} default button 2
copy the result as list to {buttonpressed}

try
	if the buttonpressed is "HIDE" then do shell script "defaults write com.apple.finder AppleShowAllFiles FALSE"
	if the buttonpressed is "SHOW" then do shell script "defaults write com.apple.finder AppleShowAllFiles TRUE"
end try

do shell script ("killall Finder")

The first line launches a dialogue with button options for SHOW or HIDE. The button press result is placed in a variable, ‘buttonpressed’ and then checked in a try condition. Finder is then refreshed.
Simply compile the script and Save As an application.

I was privileged to present on RIA, on behalf of Douglas Reynolds Consulting to the Association of Information Technology Professionals group this evening. They provided an extremely nice venue, networking, dinner, and were very gracious hosts. The group was comprised of IT professionals, mainly from large enterprise corporations, with roles including Network Administrators, Embedded Systems Developers, Software Developers, Managers, Marketing Specialists, and more. The audience was involved, interacting with me during the presentation, which made presenting a great deal of fun. Below is my presentation deck on “What is RIA? Why Rich Internet Applications Are Good For Your Business.”

FITC Boston, 2011 is coming up quickly and I am finding that there are some sessions that I am interested in that are being presented in the same time slot. I am planning on doing some post-conference articles here on the sessions that I am attending. If you would be interested in “Teaming Up” on sharing notes, links, and other insights on sessions then be sure to add a comment below with a link to where your post-session write-ups may be found. Hopefully, the presenters will publish links to their slides as well and I will be including those when/if available.

My intended schedule looks like it will be:
Thursday October 27, 2011

• 9:00 AM – 12:30 PM – Getting social with Flex with Rob Rusher
• 1:30 PM – 5:00 PM – Flex Mobile Boot Camp with Christophe Coenraets and Holly Schinsky

Friday October 28, 2011

• 9:00 AM – 10:00 AM – Adobe Keynote with Ryan Stewart and Terry Ryan
• 10:15 AM – 11:15 AM – Refactoring: Getting Things Done, Keeping the Code Clean with Jesse Warden
• 11:30 AM – 12:30 PM – Customizing the look of Mobile Flex with Terry Ryan
• 1:30 PM – 2:30 PM – Cross Platform Mobile Applications from the Trenches with Christophe Coenraets
• 2:45 PM – 3:45 PM – Introducing Robotlegs 2.0 with Joel Hooks
• 4:00 PM – 5:00 PM – Mobile Payments with Flex with Sidney Maestre
• 5:00 PM – 5:15 PM – Closing Ceremonies

I would love to have a chance to meet you!! If we don’t hook up during the conference or at the hotel, I will be planning on stopping in at the Evening Event After Party presented by Digital Primates at The Lansdowne Pub @ 9 Lansdowne Street, Boston (www.lansdownepubboston.com)

First off, what makes a model a Robotlegs model? There is a base class in Robotlegs which is called Actor. By extending Actor, generally used in models and services in Robotlegs applications, we are able to access a property of Actor which is named eventDispatcher. EventDispatcher is shared throughout the Robotlegs framework, thusly, any events dispatched upon the eventDispatcher may be heard across the entire application. It is not required to extend Actor in a Robotlegs application. Actor exists as a helper, should you need to be able to dispatch an event and have it heard anywhere in the application. However, if you do not need to dispatch an event from a particular model, there is no obligation to extend Actor (it is recommended that you don’t in this case). Additionally, you may, of course, dispatch an event on the standard Flex framework and not create the dependency on Robotlegs. You might choose to do this if you plan to use your code in other framework-agnostic applications.
About models and services from ActionScript Developer’s Guide To Robotlegs:

They don’t listen, they only talk
Models and services are like the worst kind of dinner party guest. They have no interest in what other people have to say. All they do is send messages out to the framework–they never listen directly to their eventDispatcher property to see what other classes are saying.

Aside: If you haven’t read ActionScript Developer’s Guide To Robotlegs yet then stop right here. Over on the right you will find a link to the books site on O’Reilly Media, go get it NAO!!

Okay, the purpose of a model, in general, is to provide an API which preserves state in an application. A model is updated with state data that then may be used by other classes in your application. However, we don’t necessarily want to tightly couple our model to other classes. The best way to decouple our model is by dispatching events that may be heard by any classes that are interested in knowing that state data has changed. Enter Actor. By extending Actor in our model we now have access to the application’s framework eventDispatcher.

Here is the scenario: A service call requests some data from some remote data source (e.g. database, Webservice, HttpService, etc…). The result event of the service receives the data in the result and passes it to a factory class where it builds the resulting data into an object that we can use. The factory updates the model’s property that we are interested in and notifies the service where we can do whatever else we need to do. The important part here is that the model gets updated. We could dispatch an event from the factory or service that the model has been updated, but we really don’t know 100% from these classes that the model data is actually updated. The only place we can dispatch this event with complete certainty that the data was updated in the model is from the model itself.
Here is the model’s mutator that we will be testing:

public function set myObject ( myObject : Object ) : void
{
	this._myObject = myObject;
	eventDispatcher.dispatchEvent ( new MyEvent ( MyEvent.MODEL_UPDATED, false, false, myObject ) );
}

A benefit of accessors (getters) and mutators (setters). By using getters and setters in our model we create a public API. Additionally, by virtue of the setter method, we have a distinct method where a property gets set/updated. It is within the mutator that we can dispatch an event when we know for certain that the property has been updated. We also have public methods that we can test, such as testing state data is what it is supposed to be, and in our case for this example that an event is dispatched when state data changes.
The way I approach this is to simply check that the event dispatches when I provide the model’s property with a new value. We can add an event listener in the test whose handler method confirms that the event dispatched. Then we can assert that the result of the handler method is the same as what we expect. In this case, I increment a counter from an anonymous function if the event listener hears the event and then assertEquals. If the counter and expected value are equal, then our test passes. Otherwise, the test fails and we know there is a problem.

[Test]
public function testMyModelSetMyObject_dispatchEvent_MyEventIsDispatched():void
{
	var count:Number = 0;
	instanceModel.eventDispatcher.addEventListener(MyEvent.MODEL_UPDATED, function (event : MyEvent):Number { return count++;} );
	instanceModel.myObject =  MY_OBJECT;
			
	assertEquals(1,count);
			
}

A bit of convention explained here. The test name provides for three distinct pieces of information that will be valuable to yourself and anyone who later is maintaining your tests. A test class name provides the following information:

• The name of the method under test
• The state, or condition, which is under test
• The expected behavior of the test method

I then declare an instance counter that will be used to assert against. The instanceModel is the model that we are testing, by setting an eventListener on its eventDispatcher we can listen for the specific event for which we are interested. In this case, I want to know if the event/type, MyEvent.MODEL_UPDATED is dispatched when the myObject property of the model is updated. For ease of implementation, I use an anonymous function which takes the MyEvent type as an argument and returns a number to increment a counter and return its value. Then, I updated the model’s property, which should dispatch the event. Lastly, I assertEquals that the counter value is 1 as expected, meaning that the event dispatched, was heard in the anonymous handler method and incremented the counter.

In Test Driven Development (TDD) and Unit Testing, it is often necessary to provide the Class Under Test (CUT) with a stub of a class for which it has a dependency. For instance, this example illustrates a command class that injects a model. In order to run a test against the execute method of the CUT we need to ensure that the model and related model properties exist for the CUT in order to assert against the command’s execute method.
Mocks and Stubs are Different
First, I want to describe the difference between a Mock and a Stub as there seems to be general confusion over the slight difference that exists. According to Roy Osherove, in “The Art of Unit Testing” a Stub is defined as:

A stub is a controllable replacement for an existing dependency (or collaborator) in the system.

And a Mock is defined as:

A mock object is a fake object in the system that decides whether the unit test has passed or failed. It does so by verifying whether the object under test interacted as expected with the fake object.

The difference between a Mock and a Stub isn’t necessarily evident in simply looking at the test code, the two may look very similar. Instead, it is necessary to consider just what it is that a Mock does as opposed to a Stub. The difference can be found in how each one is used. Quite simply, a Mock gets asserted against, we are testing it to verify that the CUT interacted with the Mock as expected; a Stub is not under test and is provided simply as a means to fulfill a dependency of the CUT. So, again, a Mock is under test and a Stub is a helper class that is fulfilling a dependency of the CUT and it, itself, is not under test.

Here is a diagram that illustrates a model Stub (fake) as is used in a test that asserts against a class, a command for our purposes, for which has a dependency on the model. Notice the layer of abstraction that is created by the use of an Interface which allows us to swap the the Stub in place of the actual model class by injecting the StubModel rather than Model as would be used in production code:

Mockolate facilitates the injection of a “Mockolate” for us using some metadata to prepare and inject our Stub dependency. There are a couple of Mockolate helpers that are important to take note of as I will be using them in the example which follows. In FlexUnit there is the concept of a rule. Like [Before] and [After] provide that a method will be run before or, respectively, after each test, we can create a rule that defines a dependency injection and have it inject the additional functionality into our test. Mockolate’s [Rule] metadata is a helper that invokes FlexUnit’s [Rule] for us, thereby simplifying the implementation of injected dependency. Using MockolateRule will asynchronously prepare your dependency before each test and will wait for prepare completion prior to running each test. MockolateRule prepares the dependency prior to needing it, ensuring that it exists when used.
Then how do we get our dependency prepared? Mockolate has another metadata tag, [Mock]. Any public instance variable declared with [Mock] metadata will be automatically prepared and injected for us. This is very powerful and very sweet!!
So how do you use this stuff?
Let’s look at some code to help illustrate how we implement Mockolate Rule and Mockolate Mock and setup our test class:

public class MyCommandTest
{
	[Rule]
	public var rule:MockolateRule = new MockolateRule();
		
	[Mock]
	public var model:IModelInterface;
		
	private var instanceCommand:MyCommand;
	protected static const MODEL_OBJECT:ModelObject = new ModelObject();
		
	[Before]
	public function setUp():void
	{
		instanceCommand = new MyCommand();
		instanceCommand.eventDispatcher = new EventDispatcher();
		instanceCommand.event = new MyEvent ( MyEvent.DO_SOMETHING, false, false, MODEL_OBJECT );
		instanceCommand.model = model;
	}
		
	[After]
	public function tearDown():void
	{
		instanceCommand = null;
	}
}

In the MyCommand test class the following Mockolate and declarations are getting defined:

• Create a new Mockolate Rule
• Create a new Mockolate Mock of the model to be prepared and injected
• Create an instand of the command CUT
• Create a constant of the model object which is the dependency property we need

We need to write our setup and teardown methods which will run before and after each test:

• Using FlexUnit [Before], create setup which will run before each test in the class
• Create a new instanceCommand
• Create a new EventDispatcher as our Robotlegs Command needs it
• Create a new event as our command happens to inject this event
• Assign the model that Mockolate will have prepared for us
• Using FlexUnit [After], create a teardown method to clear our setup before the next test

At this point we are ready to write our first test. This test will check to see if the overridden public method execute actually does what it is supposed to. The execute method in this command updates the injected model with an object payload from the injected event. Although we need to test that the model does get updated, we are not testing the model here, we only need it because it is a dependency of the command, which we are testing to see that it successfully updates the model.

[Test]
public function testInstanceUpdatesModel_updatesModel_instanceCommandUpdatesModel():void
{
        stub(instanceCommand.model).getter("modelObject").returns(MODEL_OBJECT);
	instanceCommand.execute();
}

A bit of convention explained here. The test name provides for three distinct pieces of information that will be valuable to yourself and anyone who later is maintaining your tests. A test class name provides the following information:

• The name of the method under test
• The state, or condition, which is under test
• The expected behavior of the test method

Following the method naming, we see a Mockolate method which has not been previously discussed here. The Mockolate stub method allows us to define a Mockolate expectation, in other words, a dependency. Again, a Mock is under test and a Stub is a helper class that is fulfilling a dependency of the CUT and it, itself, is not under test.
In this case we need to stub the getter of the model’s “modelObject” property and check to make sure that it returns a value of type MODEL_OBJECT when the execute method is called on the command. The execute method updates the model’s modelObject property and the getter returns a MODEL_OBJECT object. If it returns a different type or null, then our test will fail. If it successfully returns a MODEL_OBJECT type, then it will pass.
Now, to write our command class so we have something to test. First, write the basic shell of the command with an empty execute method and run the test. The test will fail, perfect! Now, lets make the test pass:

public class MyCommand extends Command
{
	[Inject]
	public var model:IModelInterface;
	[Inject]
	public var event:MyEvent;
		
	override public function execute() : void
	{
		if ( event.myObject ) {
			model.modelObject = event.modelObject;
		}
	}
}

The MyCommand class injects the model, mapped to its interface, as well as the event which has our payload to update the model. The execute method checks to see if myObject payload exists on the event, which it will because we are providing that in our test’s setup, and then updates the model with the event modelObject. We run our test again…Pass!! Excellent! At this point we look and see if we need to refactor our command production code, if so, refactor and test again and continue this process until complete.

References:
Mockolate
FlexUnit

Here are some quick and easy solutions for trimming leading and trailing 0′s from a string in ActionScript. The examples that follow illustrate trimming leading 0′s from a string of numbers only, trimming leading 0′s from an alpha-numeric string, and trimming trailing 0′s from either a numeric or alpha-numeric string. All three are very simple to implement.
In the first problem, we need to trim the leading 0′s from a string of numbers, “00076925″ for example. This is easily accomplished using a simple parseFloat method:

private function trimLeading0sFromString() : void
{
	var numericString:String = "00076925";
	numericString = parseFloat ( numericString ).toString();
	trace ( numericString ); // 76925
}

The next problem is a bit more complex, but nonetheless simple to solve and implement. In this case we need to trim the leading 0′s from a string of alpha-numeric characters, “000076925-B72A32″. We’ll implement a simple regular expression to do the work for us here because using parseFloat would leave us with a result of “76925″:

private function trimLeading0sFromString() : void
{
	var alphaNumericString:String = "000076925-B72A32";
	var pattern:RegExp = new RegExp ( '^0+' );
	alphaNumericString = alphaNumericString.replace ( pattern,'' );
	trace ( alphaNumericString ); 	// 76925-B72A32
}

A bit about this simple regex. We are using a couple of metacharacters to help us. The caret (^) metacharacter matches the beginning of a string. We are looking for a beginning of string match, using ^0, which says – look for a match of 0 at beginning of string. Lastly, the plus (+) metacharacter matches the previous item, in this case a 0, one or many times. In this way we can look for as many leading 0′s in a string and remove them using the replace method, which simply replaces the pattern match with an empty string.

Here in our last example, our problem is that we need to remove the trailing 0′s, this expression may be used for both numeric and alpha-numeric strings. Again, in this example we’ll use a regular expression to accomplish this:

private function trimTrailing0sFromString() : void
{
	var alphaNumericString:String = "76925-B72A320000";
	var pattern:RegExp = new RegExp ( '[0]+$' );
	alphaNumericString = alphaNumericString.replace ( pattern,'' );
	trace ( alphaNumericString ); 	// 76925-B72A32
}

Note the change to the regular expression. In this example we use the metacharacter [ and ] to create a character class. We are defining that we will match any number of 0′s that we may find, matching the previous item, “+” at the end of the string “$”.

I think it is best to start off a discussion of agile development with reference to the formal origin. The Manefesto for Agile Software Development is the definition of the approach, or methodology, to agile software development. Created in 2001, by a group of 17 developers, the Agile Manefesto stands as the basis for what is defined as agile software development.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

What is the Manifesto declaring here? It is a list of principles and intentions. A public policy that states that we will value individuals and their interactions with one-another over the processes and tools that are used in project development. Individuals and their interactions are about people and organizational culture, the environment they are in when collaborating on a shared set of goals. A culture that supports individuals in a fluid structure, allowing for a sharing of roles and creativity. People are empowered in this culture, empowered to create and contribute, to provide solutions to problems and interact with anyone else on the project team. This culture is not about blame, it is about honesty and accountability where mistakes are leveraged as a tool for improvement and learning.

The Manifesto states that we will value working software over comprehensive documentation. Indeed, what is really the most important deliverable we can give the stakeholders? Working software. Additionally, the tenets of “Clean Code” provide that well written code is self-documenting. By using techniques of convention within software development, we are able to produce documentation as a byproduct of well written code. During discovery, using techniques such as user stories, we are able to capture user requirements documentation directly from the customer, which then is developed into the functionality of the project. As such, we have allowed the client to participate in, not only the definition of the project, but in the development of the project documentation. The point is that we can develop a set of documentation that provides nothing without working software. Obviously, we as developers need to understand what it is that we are going to build. In planning, we use tools to define such aspects as the functionality, the integration and flow, the user interface design, etc… These are very important to our discovery of what it is that we are building and ensuring that what we are about to build is aligned with the vision and roadmap of the project. In the end, however, it is the working software that determines success or failure of the project, not the documentation.

The next mantra of the Manifesto is customer collaboration over contract negotiation. Are you really arrogant enough to think that you know what your customer needs? Should customer collaboration be limited to a requirements document, an executive summary, change orders, project documentation, and a contract, not to mention several other standard project documents? What about interaction with the client throughout the process? Client involvement IN the project, throughout the project, has the intended effect of empowering their ownership in the project. Involving the customer in the day-to-day development ensures their accountability in the project. Customer collaboration provides that we may develop intricacies in the project that not only meet the customer needs but that are within the project scope; scope can be determined and developed in real-time with the interaction of the stakeholder. What is this collaboration thing? Collaboration is effective, ongoing, communication with the client that gives us, as developers, the means to listen and understand the client requirements. Collaboration is our opportunity to provide alternatives, point out potential problems, to guide and consult from our professional point of view how we might best achieve the client’s vision.

Lastly, the Manifesto states that we value responding to change over following a plan. We are fluid, adaptable, able to bend and redirect the project flow without causing a project failure. We are able to write code in such a way as to easily incorporate new features, change existing functionality, and provide for changing needs within the project’s lifecycle. Any plan, no matter how accurately drafted, is subject to change. “Plans in the sand”. Obviously, we must have plans in order to communicate processes. However, it is the plans themselves that must be adaptable and their authors understand that they are but a draft. Changes need to be assessed and it is important to perform impact analysis on these changes. It is important to address changes to scope and cost. The point is, that a plan be able to adapt, to communicate the effects of change, and to incorporate resulting information relevant to deliverables, risks, costs, time, and the impact on down-stream resources.

The Manifesto was created, based upon 12 self-explanatory principles as a guide to software development practice:

Principles behind the Agile Manifesto

We follow these principles:

1. Our highest priority is to satisfy the customer
   through early and continuous delivery
   of valuable software.
2. Welcome changing requirements, even late in
   development. Agile processes harness change for
   the customer’s competitive advantage.
3. Deliver working software frequently, from a
   couple of weeks to a couple of months, with a
   preference to the shorter timescale.
4. Business people and developers must work
   together daily throughout the project.
5. Build projects around motivated individuals.
   Give them the environment and support they need,
   and trust them to get the job done.
6. The most efficient and effective method of
   conveying information to and within a development
   team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
   The sponsors, developers, and users should be able
   to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence
   and good design enhances agility.
10. Simplicity–the art of maximizing the amount
    of work not done–is essential.
11. The best architectures, requirements, and designs
    emerge from self-organizing teams.
12. At regular intervals, the team reflects on how
    to become more effective, then tunes and adjusts
    its behavior accordingly.