Railo on SVN and Team Project Sets

Finally! You can now build Railo of SVN. Unfortunately the architecture of Railo begs for some simplification but that's beside the point really I suppose. Sean Corfield has posted some directions. The directions are pretty easy to follow but thanks to Railo's architecture it requires the setup of multiple projects in eclipse, which while not over complicated it is slightly annoying. To help out the enthusiastic folks I figure I'd take this opportunity to introduce everyone to Team Project Sets in Eclipse. Team Project Sets in Eclipse make it easier to setup multiple projects and share that information with team mates or others. Whilst it does not setup as much as I'd like it does get all the projects setup and connected to SVN with a simple import. I've put a Team Project file up on my drop box account here. To use this simply download the PSF, then in Eclipse select File->Import->Team->Team Project Set. Once you import this file Eclipse will get to work connecting to SVN and downloading all the source. The only difference from Sean's directions is I placed the dependent jar's in an Eclipse project Railo-libs (which will allow for easier updates later) so when you re-add the Jars to the build path just select Add Jars instead of Add External Jars.

Code Review and Mentoring

I've had quite a few people ask about the presentation slides for my Code Review and Mentoring presentation at cfObjective. I've been intending to post them for a while and I keep getting distracted. I think this is one of my more enjoyable topics. I feel like sometimes technical how-tos are hard to cover in under an hour but Code Reviews and mentoring you can get a good bit of ideas across in an hour. I did not get to go on my Scrum rant this time but 50 minutes is 50 minutes. Thanks to all that attended and my appologies on the delay in my slides.

CFML Portlets

Finally the presentation has been given and the world (albeit a small world) has got its first glimpse at what we (my self and Bob Burns) have kept to ourselves for way too long. I haven't really said much recently and it's because I have been very busy getting ready for presentations at cfObjective. I don't think I mentioned Bob enough, he really was to catalyst for this project many moons ago. He rocks in so many ways I really can not describe it. The presentation slides can be downloaded here. The project documentation is a bit shallow right now, that will change, and all the information will be on the Wiki. The code is in SVN (http://svn.cfinnovate.com). I'll keep this short but I promised links on my blog so there you go. If you are interested in hearing more about CFML portlets let me know I'll oblige!

Happy Birthday OpenBD

Depending on how you look at it OpenBD is a year old or just about a year old (So the date is not exact but tonight at cfObjective we have BOFs which is when OpenBD went legit with its open sourceness 1 year ago). It has been a crazy year with adversity and acceptance. I was reading my Steering Committee interview (posted a little over a year ago now) and wanted to comment on a particular question in there:

Looking ahead 12months, what needs to happen before we can claim Open BD a success?

I think there are multiple criterion for success and we'll discover new criteria as we move forward with this project. At this point I see our first major milestone as being a successful point, or version, release that incorporates functionality suggested by the community, voted on by the committee, executed by New Atlanta (or others), and verified/accepted by the community. In order for us to claim success I think we also need to see company adoption of Open BlueDragon, and contributions to the project from the community. Not really even code contributions but help with documentation, tutorials and evangelizing the product. Nothing less than world domination really.

I have to say after rereading my success criteria I was pretty aggressive with what needed to be accomplished. I knew who was involved though and I have to say we have been a success! We have now had 3 successful releases (1 major 2 minor), including an awesome admin console built from the ground up. We have had functionality voted on/brought up by the community (some not from the ColdFusion community either might I add!) and subsequently added to the engine. New Atlanta (while never releasing the admin which I had originally hoped they would) has been active in contributions as has Alan and Andy (not part of New Atlanta). Lastly but certainly not least we have had an amazing community the google groups are active with questions, discussions, help and advice. We have a wiki that the community has helped publish content, and we have had multiple bugs submitted to us.

I think this year we could stand to get better organized, offer a better/clearer road map and communicate what we are thinking about working on next. This is a challenge because we have super intelligent guys working on this project and sometimes when they get an idea BOOM its done before we have time to talk about. Also I think something I didn't say but the intent was there is we should (and do) need to have a big focus on growing the CFML community. We'll probably never (as the small group of folks that we are with just enough scratch to buy some stickers for all 4 of our fans at cfObjective ;) ) grow the community 200k+ in 1 year like Adobe but I'd like to think we can contribute to growth as well. Are some of the folks using OpenBD as an alternative to ColdFusion, yeah sure it is going to happen. What I'd really like to do is for every 1 person we get from inside the community I'd love to add 2 from outside the community. That is a lofty goal, and quite honestly I don't see us fulfilling it. If I set our expectations high maybe we can achieve a more realistic goal: grow the CFML community not just the OpenBD community.


That being said if you are at cfObjective and you have played with OpenBD and/or are using it find me or Matt Woodward and ask us for stickers we got 'em and I know we'd both love to hear success stories, and pains.

CFML landscape

I had been meaning to publish this for a while but I decided to sit on it and wait for some of the dust to settle. I was eager to see exactly how many people would join the new Broadchoice Railo.

Now that Railo has finally opened up I think it is high time we take stock in the CFML landscape. What follows is how I view it with (of course) my personal twist/insight in each engine. I've tried to keep my personal commentary to a minimum, or at least hold it off till the end.

Open BlueDragon is GPLv3. It is the most open system with the most open development, though I think we could improve some. Anything that comes from OpenBD is GPLv3 or compatible. It is extensible but currently does not offer any store or other automated mechanism to add the extensions to the engine (though it is not hard and it is documented). So long as a commercial extension does not try to package and distribute the entire engine there are not problems with commercial extensions. Open BlueDragon is backed by a AW2, not New Atlanta. AW2's business model does not rely (primarily) on the CFML engine, though they do leverage it in some of their work from what I understand. When OpenBD was announced the project tried to gain confidence from the community by include some high profile names in the project steering committee (personal observation: BlueDragon had a bad name due to some old NA bad blood with Adobe and many were skeptical).

Railo is LGPL (sorry I can not remember the version I think 2 but maybe 3). It is mostly open. The core offers compelling compatibility and an astounding set of functionality. It is extensible via an app store type model where modules can be added onto the engine (I have not done enough looking to see if this is still manual or automated through the admin). Railo itself plans to make some functionality for pay. Railo the engine is backed by Railo the company and the business model s structure entirely around the Railo engine (services and product sales). Railo has positioned themselves inside the CF community as a competitor to Adobe by sponsoring CF centric events and hiring prominent figures in the CFML community.

ColdFusion is currently the most closed (in terms of source and openness to talk about what is being worked on). It is commercial and when you pay you get the whole kit and caboodle. ColdFusion can be extended through a couple of different means but not quite as tightly integrated as Railo or OpenBD at this point (the main extension point at the Java level is through CFX tags). ColdFusion is the original engine to use CFML and has gone through 2 acuisitions. It's a steady income for Adobe, they care about the CF community and do their part to keep it alive and happy (it is after all steady income for them).

To Adam Lehman's credit I think the information about CF9 has been much more open than previous releases. Don't take this comment too lightly this is a large shift for a large corporation. This comes from some one involved in many previous releases of ColdFusion and I personally see a huge difference in this release. The last couple of releases of ColdFusion have been driven heavily by the community. This is good but at the same time, the community is not full of big thinkers and typically we ask for functionality we need right now. This has resulted in stagnation of the ColdFusion platform, sure it has kept up but it has not PUSH forward much. Let's face it while Adobe (and Macromedia before them) have done a stellar job developing a great product the whole platform itself has sort of dwindled as they have focused on the language too much (not saying the platform has not grown it has but more evolutionary than revolutionary). The innovation seems to have slipped away and as a direct result we have multiple engines available to us now.

Ok now that I got my little side bar tangent out, which engine is right for you? I'm not going to make that decision for you, what is important (in Open BlueDragon team's eyes) is you have an option. We see that as possibly the most important part of being available, you have options. Each engine has compelling reasons to consider it for use. For me personally, in my development, I like the fact that I have complete control over the source code if I need/want it. I like that and that drives me towards OpenBD. For my company, we like a solid platform backed by a single entity and ColdFusion offers that to us.

Fusebox Update

As of a little before the posting of this blog fuseboxframework.org has moved onto a new set of tools to communicate with the community, trac.fuseboxframework.org will begin redirecting shortly. Firstly, and one I am very excited about, is the move over to our new Confluence wiki. Confluence is a very powerful wiki with an amazingly easy GUI to edit entries. My hope is that this increase in ease of use over trac helps the community provide more documentation, as it seems like this has always been sore spot in Fusebox. I also found there was some pretty good documentation already on the wiki it was just hidden, hopefully the (complete, and auto updating) Tree view on the left will help expose that wonderful documentation that has been hiding. I've still got work to do to improve the wiki but I felt that since all the (known/important) content has been transferred it's time for the new wiki to launch. Feel free to check it out (and bookmark it!):

http://wiki.fuseboxframework.org

Second up, and admittedly not as smooth a transition, is Jira. I've worked with Jira for a long time at my work and I enjoy the product, though I will say I enjoy using it a lot more than setting it up. I think there are areas to improve in getting the Jira site really humming but I do feel like I've made it far enough. Tickets can now be create anonymously, as can comments, I am still working on all the spam filter stuff though. I have made an attempted to transfer all outstanding tickets that may warrant attention over to the new Jira system. Unfortunately there was no good tool to transfer from Trac to Jira so I might be missing content. You can find those tickets in a different project. If you have a ticket you want priority that is in the Old Fusebox Project I strongly suggest recreating it or sending me a note to move it (I'll be more than happy to move it). The new ticketing system can be found here:

http://jira.fuseboxframework.org

SVN browsing is lagging behind but I do plan to stand up fisheye and I will be taking over the SVN repo in a short while. I want to thank Simeon for hosting Fusebox for such a long time, he's dedication to Open Source is really awesome. I felt it was time to take responsibility myself, I hope everyone enjoys the new tools as much as I do. I always interested in feedback, positive or constructive.

MXUnit ExpectedException

I'm glad to see the next minor release of MXUnit :) I'm even happier to see ExpectedException make it into the release. I'd been doing a lot of development in Java and using the latest JUnit and the expected exception annotation was so nice. When I went back to writing test cases for Fusebox I found myself avoiding writing tests that would throw errors (like testing bad paths for Fusebox parsed files). Well long story short I found myself one night debugging something in Fusebox only to find Fusebox should have been throwing an error. Since I never tested for it I never caught that Fusebox was not throwing an error. That motivated me enough to spend the 30 or so minutes it took me to write a couple test cases and add the functionality to MXUnit.

So the old way to test for an error was something like this:

      <cffunction name="ensure_error_on_load_extentions_with_bad_path">
           <cftry>
               <cfset extManager.loadExtensions(getDirectoryFromPath(getCurrentTemplatePath()) & '/notthere') />              
               <cfset Fail("Last line should have thrown an error") />
               <cfcatch type="mxunit.exception.AssertionFailedError">
                   <cfrethrow>
               </cfcatch>
               <cfcatch type="fusebox.BadDirectory" />
               <cfcatch type="any">
                   <cfset debug(cfcatch) />
                   <cfset fail("Bad Error")>
               </cfcatch>
           </cftry>
       </cffunction>

Now all we have to do is this:

       <cffunction name="ensure_error_on_load_extentions_with_bad_path" mxunit:expectedException="fusebox.BadDirectory">
               <cfset extManager.loadExtensions(getDirectoryFromPath(getCurrentTemplatePath()) & '/notthere') />              
       </cffunction>

I love the feature, and I hope others enjoy it too.

Disc Golf Anyone

As I mentioned previously I'll be speaking at cf.Objective this year and I finally booked my tickets and hotel. One of the things I love about cf.Objective is the location; Minneapolis/St. Paul has tons, I mean TONS, of Disc Golf courses. Not to mention the second most kick ass Disc Golf Shop in the US (the first is local here in Cincinnati). Any rate I love it so much I am showing up a day and a half early to go out golfing a few times. I'll be flying in on the 12th and flying out on the 17th. My hope is to get 1 or 2 courses in on the 12th and likewise on the 13th, and if I am lucky (and not too wiped out from the conference) I might sneak a course in on the 16th. If anyone in the area has suggestions for a course let me know, and if anyone is interested in going out let me know. If you've never disc golfed before and are interested come along I have plenty of discs for first timers. It's always fun to watch TSA inspect my bag of discs (they are hard enough plastic to register on the x-ray and they always ask me). Can't wait for cf.Objective!

Speaking at cf.Objective()

Proclaimed to be the only Enterprise level conference for ColdFusion cf.Objective has really stepped it up a notch this year. I am not just saying that because I am speaking there this year I am genuinely impressed by the line-up. The schedule for the conference is amazing, it really does have some awesome presentations that many would consider Enterprise Level (Glassfish, Salesforce integration, BlazeDS integration the list goes on). This will truly be a standout year for cf.Objective(). What am I presenting on? Fusebox, or TDD? nah not for cf.Objective (besides Marc Esher has a sweet TDD preso for the conference). This year I committed to learning more about something for my enterprise level presentations. Don't get me wrong I think I could have given a great presentation on Fusebox, honestly I would kind of like to do a Fusebox BOF, but I really wanted this conference to be an opportunity for me to grow personally and present something fresh and exciting, CFML portlets. So many enterprises have or are moving to portal servers, be it Websphere, Jboss or something else and I have seen a lack of discussion about CFML being relevant in portal solutions. That's not to say it is not happening in the community just seems to be happening quietly. In addition to talking about something fresh for me I get the opportunity to present on something not so new but very close to me and that is Code Reviews and Mentoring.

Fusebox Enhancement: Type Converters

How many times do you have boiler plate crap in your controller to wire up a domain object(s). Even worse have you ever passed a string ID throughout your system? Type Converters to the rescue. Type Converters offer an elegant way to move Domain creation code out of your controllers (or delegated from your controller into your service). It also allows your system to focus on object interaction not string manipulation/passing. Best of all since I am fairly simple minded they are dead simple to use. You write the object creation code in a Type Converter, register the converter with Fusebox as well as the url/form parameter to convert. When Fusebox detects that url/form parameter it will call on the converter to create the Domain object. Converters could be as simple as hydrating a Bean from an ORM or more complex using caching stategies to find the bean, since Fusebox exposes it's applicationData you can even delegate to ColdSpring for most of the object creation. Any way you choose the point is it removes this logic from your controllers or various other non standard places and puts it into a standard (hopefully) well organized place.

Why are they called type converters? To understand this it's important to know where this concept comes from. As of late I've been doing a fair bit of Java development and we use a framework called Stripes for all our web based java apps. Stripes too has Type converters. Type converters make a bit more sense, semantically, in Java since one of the tasks of a type converter in Java is to take a browser response of YES and turn it into a true boolean type (humm sound sorta like a really cool dynamic language we all know and love). Type converters can be more complex in Stripes as well taking an arbitrary string and allowing you to return an object. I found this functionality extremely useful in my Java app. When I looked back at my Fusebox app I've also been pecking away at I quickly realized how adding type converters to Fusebox would allow my controllers to become even dumber and more OO (read: less string based) at the same time.

I know historically a large segment of the CFML community has not looked to Fusebox for OO capabilities. I get that this feature could have a small # of folks that will enjoy it but I felt it was a very good addition and worth a blog entry. The code is in its very early stages and is fairly rigid right now; this should change over the next couple of iterations as I play with the functionality more. Feel free to check it out and give me some feedback. I've provided an interface (fuseboxTypeConverter) for documentation sake. There is no reason to ever implement the interface as all Fusebox really cares about is that the converter has an init constructor and a convert method. The only other thing you'd need to know to start to play would be how to register the converter with Fusebox.To register the converter add this to your fusebox.xml (the fuxebox.dtd is updated so you should see it in there):

<converters>
<converter class="full.path.to.Component" parameter="someId" target="Object">
</converter>

Target is optional and if it is left off Fusebox will replace the current string value with the returned value from the converter. The code is available in the BER, as well as in SVN.

Got the Beta Blues?

Rightly or not the cf-talk boards have had threads where it was made known ColdFusion 9 is in beta testing. Last year Adobe announced they would be more transparent in the development, even announcing the ColdFusion advisory board. It seems like that transparency is a slow build, which I understand as nothing happens over night. I did want to take a second to pimp OpenBlueDragon and say we are working hard to be as as transparent as we can be. If you have the Beta Blues and want to share some ideas on how you thinkCFML can be made stronger, more competitive, or otherwise improve your life check out Open BlueDragon's google group and feel free to submit a ticket to our ticket system! CFML is a great language and I am confident ColdFusion 9 will deliver a great new set of functionality, I also have to say I am very impressed with how OpenBD has progressed through the months. Did you know we are considering adding cfvideoplayer and well as cfvideo? We'll talk more about this as soon as we figure out how we think it should work, until then you tell us how you think it should work. Also add it as a favorite so we can gauge the interest in this feature!

CFUnited session # 2!!

I know at least one man will be very happy to know I will be presenting Red Green Refactor at CFUnited! I gave a presentation at bFusion about TDD and MXUnit with the same title that got a lot of great feedback. This presentation will follow a similar tone as that one, only less MXUnit and more rants about BDD. I've previously ignored talking specifically to BDD as I felt (and still feel to an extent) that BDD is really just TDD done right. After the recent cfSpec announcement I got to talking to Sean Corfield about BDD and he made a comment of getting BDD over TDD. This leads me to think I should talk more about BDD (it seems to make more sense to more folks). I'm still of the mindset that BDD is little more than TDD done right but, I think BDD is starting to become more relevant as the concepts mature and evolve. I will probably focus more on some BDD concepts than I previously had planned. This should give me a chance to learn more about BDD in the process, I can't wait to give this presentation!

Fusebox back under development

A while back, maybe September or so right after finishing up a couple of additions to Fusebox, I decided to take the rest of the year off from coding. I had done some work with MXUnit, Fusebox and OpenBD and thought, I need a break. During that time I had the opportunity to fix up one of the worse Fusebox Apps I've ever had the misfortune to lay eyes on, internally at my company. It was great to get my hands dirty in an application to test out some of the new stuff I've added to Fusebox, as well as our base application we use at work. It gave me some really good insight into things I could add to Fusebox to make life easier for No XML development, and Classic Fusebox as well. John Bliss also made a feature request the other day which I've already made some additions (this will be the topic of a future blog entry).

Before I get back to too much coding though I am working with Simeon to take over Fusebox's ticket, wiki and version control. I expect the switch to happen sometime this month, there's a bit fo coordinating that need to be done. I want to give a HUGE thanks to Viviotech for donating the VPS for all this to live on now and into the future. As part of this move to the new server I'll be changing some of the software being used for the project. Fusebox's wiki will be moving to Confluence (from Trac) and the ticket system with move to Jira (from Trac), I've not drank the git cool aid yet so for now we'll be sticking to SVN. Confluence is a very powerful wiki which I hope will improve documentation, the templates for pages is very nice and powerful and I can add work flows which might open the window for more open security for editing pages. Jira is equally as nice and quite frankly I am much more knowledgeable about these 2 products than Trac and I'll be able to do more with them than Trac. Another driving factor for Jira is the integration in Mylyn (for eclipse) and IntelliJ is bar none. Due to how Trac was configured, I was unable to integrate my IDE with Trac and it was really irking me. My hope is to sooner or later get around to looking at Bamboo as well and getting that to do some continuous builds for some other projects that I've not talked about yet.

Vote for me! CFUnited

I completely failed to mention CFUnited posted the long awaited survey for session in 2009! Don't forget to check out the details for all the session in the PDF. I've got quite a few topics up this year, including learn Java which I am ultra stoked about folks taking interest in the underlying language of most CFML engines! Of course I could not submit topics without adding one for Fusebox and I figured I'd round it out with a BDD/TDD presentation. The select few that went to bFusion and attended my presentation there can attest to it being a great time. My only regret is I did not submit an OpenBD topic, if you want it you can submit a proposal in the survey so ask for it!!!! I love presenting and I hope I get the vote in, if you haven't filled out the survey get to it.

OpenBD v1 out. What about v2?

Open BlueDragon has released v1 and it has a great feature set. It's nice to see a good mix of essential functionality from ColdFusion and our own ideas. I'm particularly happy with CFSMTP and memcache integration and support for this.mapping. For the official release head on over to OpenBD's website.

Work does not stop at v1 though we've started a road map and we plan to continue to build that road map out, no time to rest we're just getting rolling. ColdFusion 9 is currently in beta (or so Andy Alan happily announced it was on cf-talk) and I am sure there are wildly debates going on about how to improve ColdFusion. The sad part is it's entirely behind closed doors, if you are not a one of the chosen hundreds (to say few is not fair enough I know how big these programs are) you blindly will have to wait. I don't mean to be overly critical of this process, Adobe has very good reason to do it this way. I do not fault them, it is just different than an open source project. If you are down and out about not being on the beta, or maybe just interested helping CFML evolve, head over to Open BlueDragon's google forum and start sharing ideas on how to improve CFML. CFML is a 2 way stream and we have seen features of other engines make their way to ColdFusion (and of course vice versa). Best part is if you have an idea a large group agrees on you don't have to wait weeks or months for the beta build (or a year + for a new version). OpenBD is built every night, as soon as a feature is coded it will be checked in and added to a nightly build. In the past we've gone from concept to implementation in just over 3 days! If you don't feel like heading over to the forums but would like to see a feature added feel free to leave a comment here.

OpenBD Status

Back in the mid November time frame a kind feller asked about the status of OpenBD, also suggesting maybe we the Steering Committee post a short little summary. Alan kindly responded and made him aware of how the project is doing, which is fantastic. I've been busy so I didn't even read the email until about 10 minutes ago. About a month ago I was also invited to speak at Mid Michigan's CFUG (note this as also my last entry b/c I have been so busy) and a similar sentiment was conveyed. I was told that OpenBD has some cool features and we really should be talking about it more. Now with these 2 bits of information bopping around in my head I decided maybe now is a good time to talk, give my personal explanation about my silence about OpenBD and a quick update about OpenBD's status.

After CFunited and the rather subtle (or not so sublte) slap in the face from Adobe, not being involed/invited to participate in the CFML advisory committee (nor even told that there would be one and this is why you are not being invited), I went back and reread many posts about OpenBD's announcement, as well as Railo's. I felt part of the problem has been the perception of OpenBD trying to steal away or otherwise fragment the ColdFusion community. I understand that sentiment due to the association with New Atlanta and I don't hold it against anyone for not involving OpenBD. I personally felt constantly coming to the community and pushing OpenBD and publishing constant updates would come off wrong, just another attempt to steal ColdFusion people yada yada yada. I care about the community a lot and I also care about every's opinion of me (to an extent) and I did not want to rub people the wrong way or give folks fodder to rally against OpenBD. This is one reason I have been fairly reserve about OpenBD on my blog. Also at the end of the day the ColdFusion/CFML community is but one community OpenBD seeks to help and it really is the least important to evangelise to, you are already using CFML!* Since the vast majority of my blog readership is ColdFusion developers I think it is a pretty bad medium for me to get the word out about OpenBD. Instead I have engaged people personally, and even evangelised at user groups outside of the ColdFusion community (anyone at bFusion might recall some very boring slides about ColdFusion the platform, those were in there to introduce people to the ColdFusion product). I think maybe I have gone too much to the extreme and now maybe OpenBD comes off as a dead project to some or a project that completely doesn't give a crap about the ColdFusion community. Neither are the case I will attempt to strike a balance of providing the appropriate amount of info in the future. Always though, if you are interesting in OpenBD please ask, I am more than happy to take time to talk to you or a group of you. Heck if you know of a user group that is not ColdFusion/CFML that might be open to seeing other technologies please send me their way or send them mine.

(*I think it is very important to be clear that when it comes to features and evolution of OpenBD I very much care about the CFML community's opinion, we understand the language/platforms and have a good idea of what can be done to improve.)

Now the fun part, the status of OpenBD. The steering committee discussion board has been quite a buzz recently and with good reason. As some folks have already found, we have finally put up a wiki and content is rapidly being added. For now the wiki is PHP, it is MediaWiki. We chose MediaWiki for a very good reason it is one of the leading open source wiki software packages today. This alone is not enough, it is also happens that the OpenBD CFML wiki that we hope to release early next year is 100% compatible with MediaWiki. This wil be an entirely open source (GPLv3) CFML wiki engine that is feature complete and compatible with MediaWiki content. It's been in the works for a long time and Alan keeps wanting to add to it instead of finalize it and release it. In the upcoming months you will also be able to find a road map of OpenBD, as well as history about the legacy of dbServlet (the original engine that has evolved into OpenBD today).

<> And one more thing. We decided on a versioning schema and we set a date for the release. You will see an official v1.0 release of Open BlueDragon by the weeks end! It was, interestingly enough, a very hard decision to label OpenBD as v1.o. The engine itself has such a legacy and many, rightfully so, felt it was an unjustice to label such a mature product as v1.0. v1.0 has significances though, OpenBD is a new product. Yes the core has a long mature legacy but the name has a legacy too, not always a positive one either. We felt v1.0 was symbolic in a way; OpenBD is a new beginning. OpenBD is on its own now and it is at v1.0, we've all moved on and do not want to dwell on the past. I can not communicate it justly how hard it was for Alan and Andy to let go of the legacy and agree to v1.0 but they did because they too see the value and significances of what v1.0 means.

Speaking @ Mid-Michigan CFUG

It's my pleasure to announce the first of what I hope to be many Open BlueDragon presentations I will be doing for local CF user groups. Rick contacted me a short while backing asking about a presentation and I happily accepted. I was originally (shortly after OpenBD's launch) a little hesitant to do this due to the negative stigma around OpenBD. I think much of that has past plus Railo seemed to be welcomed at UG and I'd like to expect the same courtesy for OpenBD. If your user group has an interest in OpenBD please feel free to contact me, a.haskell on Google's email service. For my limited Fusebox readership that are PHP users if you have a user group I'd love to get an opportunity to show you an open source alternative to PHP. OpenBD might serve you well with some customers that have CFML in house already (not to mention you can still use FB on it!). CFML is an incredibly powerful language and OpenBD gives you a great free alternative. I'll be presenting OpenBD to the Mid-Michigan CFUG on Nov. 11 @ 7pm.

Some lovin' for Fusebox 3

Issac has done a great service and provided a concept application to demonstrate how to move from FB3 to FB5. I won't talk about it but I wanted to make sure to get a post up about it and point you his way to check it out. I'll post a full review this weekend once I, .like you, have had a chances to poke around and look at what he is doing. His description in the post makes sense!

FB3 upgrade path

Why bother Getters & Setters

This morning I was provoked by Seth Bienek to rant a little more than Twitter would allow about getters and setters. You see this all started when Brian Rinaldi made the mostly innocent statement, "90% of the time, writing getters/setters is a stupid, annoying and utterly useless task." So my question is simple why the hell are we writing these getters and setters?

Now before you go off on your happy Groovy has, or ColdFusion 9 will have, or Action script as implicit getters and setters kick maybe I should reword my original question to provoke some more thought. Why the hell is your code written in a way that you need useless getters and setters? This just smacks of a poor design, probably a data centric design. I know there are some valid reasons why we need them, transfer objects for over the wire communication is a great example of when you might need objects with useless getters and setters (though I would argue in this case they really aren't useless now are they??). Please stop justifying your obsession with getters and setters, chances are if you are using tons of getters and setters your design sucks. Now don't get all offended your design could be perfectly fine, but think about it objectively.

We all need to realize how much crappy code we have laying around that we think (or thought) is good code. I mean we did pushed it into CFCs so it's good code right? Yeah not so much. Take some of those objects you have laying around and give em a good looksee. You know that one that has 25 properties and 52 methods, 25 of which are getters and 25 of which are setters. Yep that ultra important one that you spent half a day debating if it should have a DAO or a gateway. Alright now that you have your steaming pile of dung do a search on "variables." and replace it with "this.". Hey look no more useless getters and setters! I can hear you blindly complaining about encapsulation from here. Bluntly put, who gives a flying pig's ass about encapsulation here? You are getting zero, zero, value from your methods and really all your are doing is freeing yourself to rename your internal variables later, yippie. Besides, how many times have you looked at a variable and said that name sucks I want to change it? Okay so maybe a couple of times. Well good thing it was so encapsulated behind that method, it made that variable change so easy... except now the method name is different from the variable it affected. Every time you look at that object now it's like a game of guess who trying to remember what methods match to the [better named] variable. The whole point here is think about what you are doing and think about your design before you blindly make a variable private and put useless getters and setters in your code*.

At this point you're either drinking the cool aide or really wanting to punch me. Hopefully you are drinking the cool aide. Wait you are still not sold on this? Okay listen dude[t] if all your are doing is writing getters and setters and not doing anything in those getters and setters it's freaking pointless. Don't give me this whole "well what about the future" crap either. We can speculate all day about the future of our applications. As developers we love puzzles but we need to be pragmatic and ask what does the current design need. If we speculated all day we wouldn't ever get anything done, trust me I've been here unproductive and hating life. Remember "What's the simplest solution right now?" Don't introduce unnecessary complexity. Just access the variable directly or just replace it with what your object most likely is anyway...a structure.

Hopefully most of you are not satisfied with this uber structure idea. Trust me, I am not overly thrilled with it but given the choice between useless getters and setters or public variables I'll vote for public variables each time, until someone convinces me why to not. Besides for some it will save them a whole bunch of typing and they can still go to bed at night happy they are using CFCs. If you are truly interested in why I think you should not waste time on getters and setters that are useless it's because getters and setters are mostly well useless. I know there's some circular logic in there we'll work through it here in a second bear with me.

When you design your objects, and more importantly object interaction, try to avoid objects that are data consumers or providers. If the majority of your objects are data consumers or data providers then you have successfully taken something that is probably simple and best suited for something with much less OO overhead and made it complicated and less maintainable. Congratulations for getting your CFC check mark for the resume! Objects should be behavior driven, asking each other for favors. Does that mean applications I write do not have getters and setters? Hell no! I am just as guilty as the next person for writing Data Driven OO. I've got over my OO kick though I am comfortable with knowing where the rigors of OO makes sense and where they make waste, finding that balance isn't easy and its hard to teach. I'm writing this article as much as a reminder to myself to not be an idiot as I am for anyone else. Just because you have getters or setters does not mean your objects are not doing something, they just aren't doing enough probably. Sometimes getters and setters are important. For example, maybe we pop data off a stack on a get or validate data as we pass it into our object. Another example might be we went ask an object to do something but creating objects internally is bad so we provide a setter to inject the object into ours. Don't get confused with this whole encapsulation when you don't need to leverage it though. If you don't do anything that requires encapsulation don't get all complicated on me. Thanks for sticking it out to the end, enjoy the cool aide.



*As an aside in Adobe's ColdFusion each method is an inner class in Java so all of these useles getters and setters are also forcing the JVM to load bunches and bunches of useless classes as well. Generally I don't like to focus on things like this but I figured it would be a good mention for folks.

Fusebox Status

The last 2 weeks I have sat down every evening and [re]read through parts of Fusebox's core files, I also had a very energetic discussion with Team Fusebox (more on that some other time). First I have to say Sean put together on hell of a beast in Fusebox 5.5. In some aspects Sean and I have a different coding style so I feel like I would have done a couple of nit picky things differently but overall Fusebox looks to have been very well thought out and put together nicely. My main gripe is the abundant [ab]use of public parameters on the CFCs which sometimes makes it hard for me to track something down, especially since most of the time they are defined for the first time inside one of the methods of an object. Sometimes I get lost in all the parameters that are set but that's just the amount of data Fusebox is dealing with at times. The one thing that I was left without that disappointed me was unit tests. To that point I am working on some unit tests for the core files but I still do not have a good enough handle on all things Fusebox to begin to write good unit tests. The tests I have are mostly checking the skeleton right now (which works ok but I am on my TDD kick right now ;) ). With the small bad I have to say Sean left me with one of the most solid code bases I have ever seen. Some of the stuff he does in Application.cfc are pretty cool and thanks to its nicely done design I've been able to get in and make some additions already. The features I am talking about here are implemented and will be available in the BER I publish this weekend. I want to hear feedback on them, please please please let your voice be heard!

I've not tried to hide my disdain for circuit XML in Fusebox (have no fear it is going no where and will get lovin' when it needs lovin', too many of you people are masochists and like the XML). As a sign of good faith I added a feature to the XML fusebox that had always really bugged me (I'd like feedback on the good/bad side of this change). I've always hated having 15 circuit.xml files open in the editor which lead to the addition to the circuit.xml finding algorithm. Fusebox (in the BER that I plan to push sometime this weekend) will now find alias.xml or alias.xml.cfm in the path specified in Fusebox.xml.

The second feature that I added was something I really wanted to see, and I wanted it at Kroger. Fusebox now supports defining No XML circuits in fusebox.xml. What this means is you do not have to rely on Fusebox's location conventions to leverage No XML circuits. In Kroger our application layout does not match the conventions that Fusebox wanted to impose. I had a long discussion with some friends and colleagues about changing Kroger's application layout vs adding some functionality to Fusebox. In the end I felt it was a feature that would give Fusebox users a nice mesh between configuration and convention.

Like I said I plan to get this stuff into SVN this weekend so anyone interested can start playing with it. I've turned off comments on this entry so as to drive all comments to the Fusebox Group on yahoo, I am doing my best to keep the discussion in one main place.