FuseNG Update

A few months back I tweeted that anyone can build a framework in CF; what we need is more good software out there. Given the choice between maintaining a framework and listening to the nagging whining community or developing an open source application and listening to nagging and whining community I'll take the application. My heart is just not in FuseNG, or any other framework, and I can't hold onto the framework to make people happy or ensure it has a support person. That's just not what I want to do.

For those that thought it would never get off the ground congratulation you were right! To those that had new hope for the future of Fusebox, sorry FuseNG will not be it for you. You see over the past year my career has change drastically. I do not officially work on ColdFusion at work any longer and I never find myself in the situation where I am using Fusebox. I can not continue to develop a framework I don't use, it will stagnate. I hope someone else in Kroger will step up and take on Fusebox or revive the FuseNG fork, but that is up to the other individuals that originally looked to me for leadership of FuseNG. As much as I am sure some of you would like to leave feedback or comments I'd rather not open the potential for flames so comments are off. If you really must share your opinion feel free to email me.

CFUnited Presentation Roudup

CFunited was busy for everyone involved so I have no excuse for falling behind in making blog entries as many others just as busy as I did kept up just fine. I'll only post 2 entries for CFUnited this one with all my presentations and then a second one recapping my CFUnited experience (spoiler: It kicked ass!). On with the recap!

Red Green Refactor
PDF Keynote

I was fortunate enough to be given the opportunity to present this topic 2 times at the conference. I feel like both presentations were solid and entertaining; including a reference to old Purple Pants (if you do not know, probably best not to ask :) ). Barney B was disappointed in my lack of gratuitous vulgarity, I'll attempt to not let him down next year. I got really good feedback, even testimonial that TDD does speed up development!

Fusebox Past Present Future (Busy Developers Guide to Fusebox)
PDF Keynote

This was a bit awkward given the current situation surrounding Fusebox and Myself. The first half I did my best to sell on the framework and break down some of the old myths. At about 5:55 I entered my 5th Myth: Fusebox is Dead and instead of really getting into that I made the attendees aware of the current state (at the time) and announced I was resigning. I think spent the second half of the presentation talking about FuseNG (or Fork-a-doodle-doo). Expect more entries soon surrounding FuseNG 1.0 (code named Cuddles).

Code Review and Team Dynamics
PDF Keynote

This started my 3 hour marathon of presenting. It was also a late add to the conference, I was subbing for Jake Munson who was unable to present do to person reasons. I love this presentation, I've given it a few times previous. I felt really good about my delivery and I think everyone got something out of the presentation. I think I might create a new presentation on the same vein but with more emphasis on Team Dynamics and mentoring for next years conferences. I appreciate all the positive feedback from everyone!

Busy Developers Guide to Java Part 1
PDF Keynote

This was one of those presentations with so much content it has to go perfect or you run out of time. I screwed up 2 times and ran over. I was also called Drill Sgt. and Reverend after this presentation. Apparently I was too brash haha! I felt everyone still learn a great deal about java and I got some great positive feedback as well, definitely help enable folks in this one. This was the second session I got to repeat. The second iteration I tried not to preach as much I also pulled some content that might have been too preachy. I ended right on time and had some great interaction, just like the first time. I think this session has great replay potential for future conferences.

Busy Developers Guide to Java Part 2
PDF Keynote

This was my final presentation of the 3 hour presentation marathon. I'll admit that about halfway through the Part1 session I felt ill. This continued into part 2. About half ways through one of the most embarrassing things happened, I had to excuse myself from the presentation for a moment. Luckily this was the last session of the day and everyone was very understanding and allowed me to run over the time and finish the content. I appreciate everyone's patients with me. Aside from the total misery I was in as far as how I felt I think this presentation was awesome. I got good participation from the attendees and very positive feedback from many folks. Anytime I stick around after a session to answer additional probing questions seeking to learn more is awesome.

Overall I had a blast presenting. I hope everyone attending my presentations was entertained and learned or was motivate. As long as I was able to positively affected at least one individual that is all the more I can ask for as a presenter the rest is gravy. Our community is growing and I am glad to be part of the growth. Here's to CFUnited and any other conference that facilitates collaboration and growing! Thanks Stellr for organizing, promoting and kicking ass.

FuseNG Announced

I have a quick, and I mean quick, moment to post something exciting and sad to my blog. The creation of a new framework is official, the name: FuseNG. FuseNG (think, Fusebox Next Generation) is the official name of the fork from Fusebox 5.5.1. I can't say it was a rough decision to make. I wish I could say otherwise in a sense but it was just so depressing seeing where we were as a community as Fusebox I felt I had no choice. On the other hand I am lucky enough to have a great community behind me; that was really empowering for me and helped make the decision to fork extraordinarily simple.

I chose FuseNG as the name for a couple of reasons:

1. Suggestions like Fork a doodle doo, while very entertaining (the first 500 times it was suggested to my by someone), do not represent what I want people to remember about the framework.
   
2. I am a tad bit on the uncreative side and most of the cool names with Cold or Box are taken :)
3. I love Star Trek TNG so doing anything that resembles one of my favorite television series is cool
4. I feel that it reinforces a core value: FuseNG is not intended to alienate the Fusebox community with the fork. It really is about pushing the framework forward into the Next Generation of the framework. A bit of a history lesson Fusebox almost became FuseNG one other time interestingly enough I was told this after I chose the name without prior knowledge.
   

I will remain active on the Fusebox forums and websites, I think it is important that Fusebox exists in some capacity to provide those that may not know about our new endeavours a starting point to learning about frameworks, MVC and code generation. So with that I bid Teratech adieu.

An Open Letter to The Custodians of the Fusebox and the Community

I feel like I have shielded the community about strife that has existed within Fusebox team too much. It's not my intent to air dirty laundry out in public but I do think I should have been more open with the community about my disapproval of how Fusebox has been run. Presently, Teratech has ownership of the Fusebox domain and the rights to the source code. While I believe Teratech sought to gain those rights with the best interest of the community at heart, I believe it is time for a change.

Fusebox has the prestigious history of being the first major ColdFusion framework and Fusebox, in all its forms, powers thousands of applications worldwide. It is imperative Fusebox continues to prosper and advance. The Fusebox Framework has stalled and is as a rudderless ship among the seas of source code. What Fusebox needs is an injection of active, willing leaders that are willing to take an active role in the evolution of the framework, with the community at the forefront of road map. A group has formed, consisting of me (Adam Haskell), Robert Burns and Tony Bommarito and Chris Weller and is willing and able to provide the energy and leadership to move the framework forward.

After a spirited conversation with Michael Smith the other night it is clear we have irrevocable differences centering around the leadership of the team behind Fusebox. Fusebox has a bright future ahead of it under the proper leadership. We have an opportunity to make Fusebox easier to use and provide tools and options to allow a developer to grow with the framework. New active leaders can focus attention on more than just the framework's code by fostering more active community involvement in documentation and tutorials. Fusebox has grown tremendously under Teratech and provides great tools for developers and I think we now have the opportunity to make the framework easy to jump into, something that can be leveraged in less than 30 minutes. We can accomplish all this and more and remain free and open in source and in policy. The license can remain Apache licensed and free for everyone (let me be clear here Teratech is NOT threatening to change this). To be clear I have no intention of changing the license from Apache either. This is my commitment to the community.

This is what I would like to see from Teratech to prevent a fork in the framework:

1. Pass control of Fusebox Domain and Source Code to Community under the leadership and copyright of myself (Adam Haskell), Sean Corfield*, and Robert Burns
2. Work closely with the community and be willing to provide certified Fusebox training produced by the core group
3. Become an active member of the community, the community can only gain from Teratech's involvement

On a final note I do want to sincerely thank Teratech for what they have done, if they (and Sean Corfield and Simeon Bateman) did not step up 3 years ago and subsequently get Fusebox under the Apache license I would not being posting this today. They have empowered the community to ensure Fusebox remains a stellar framework. Teratech has affirmed their rights to the domain and to the source code under the name of Fusebox. While I respect the law in this case, there are irreconcilable differences between me, as Lead Developer of the Fusebox Framework, and Teratech. As such, I ask the community to let their voices be heard and to act quickly. Should these differences between me and Teratech remain unresolved, I'll resign from Lead Developer of the Fusebox Framework on August 12th, 2009 at 6:00PM EST. At which point in time a fork will be made available to the public and the essence of Fusebox will live on under a new banner.


*Myself, Tony, Chris and Robert all work for the same company and I felt it best that a person from the community outside of our company was on the copyright. Since the mind share of the current version of Fusebox is Sean's I felt it appropriate that he be on the copyright, we have spoken and he is in agreement.

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.

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.

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.

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

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.

Fusebox 5.5 Documentation

I know a lot of folks have asked for more documentation for Fusebox 5.5. This morning it occurred to me that maybe, like myself at one point many months ago, folks are not aware of Sean's excellent release notes. I have to say Sean did a great job with his release notes for 5.5 and 5.5.1 (missing). These 2 PDFs that may not be indexed by google which may be why not many people are aware if them. I will try to get some of this content copied out and into the wiki over the upcoming weeks but if you have not read these docs please do so. I really think they do a good job covering Fusebox 5.5 functionality. Also please remember Jeff has now released a new book for Fusebox!

Fusebox in Java??

A couple of weekends ago I stepped into my Java developer shoes and attended No Fluff Just Stuff, think cf.Objective() in attendance size, cfUnited Express in local feeling, and cfUnited (or SOTR) for quality of speakers. I wrote up the majority of the entry during that conference. Instead of publishing it at that time I decided to sit on it for a bit before rereading my thoughts and posting this entry. At NFJS Neil Ford talked about polyglot programming, something I myself have joined in about in the past. If you will recall polyglot programming has morphed into this thought process of using the appropriate language to complete a task. The JVM has become a very powerful platform, now supporting some 200+ languages. Most of these languages can interact with one another at some level, if not directly then they can use the the Java level. While CFML happens to be my preferred language to write most of my applications in I have to wonder should frameworks be written in CFML?

Historically we were bound to strictly CFML, putting any part of a framework for CFML apps in Java would require putting the class on the classpath, not so shared hosting friendly. Well we have all progressed and learned a thing or 2 about Java and this traditional thought process needs to evolve some. Thanks to Mark Mandel and some of his crazy cool java class loader work, even if you don't know much about class loaders, we are not bound to our traditional thoughts about how we can load java classes. We can now easily load java classes after server start up from places other than the predefined classpaths. Armed with this knowledge I can now objectively ask, should Fusebox be written in CFML or should it be written in Java (or groovy or anything else that I could consume from CFML)? Even weeks later, presumably after all the Java Kool Aid has left me system, I still am leaning towards Fuseox should be written in Java. Maybe should is a bit too string of a word there, Fusebox could benefit from being implemented, at least in part, in Java. This is not a proclamation that I am going to rewrite Fusebox into Java, remember I said I was going to think out loud when it came to Fusebox development, but I really am leaning towards writing parts of Fusebox in Java.

Eclipse Plugin for Fusebox (re: Marc Esher's Comment)

Marc Esher, someone I've grown to call friend over the past few months, left a question in my post yesterday inquiring if Kroger would be donating an eclipse plugin for Fusebox. What Marc knows but others do not is we have built a plugin at Kroger to help kick start project start up. The plugin is a fantastic help to driving consistency and help get a project's code base off on the right foot. The short answer to Marc is no. But I didn't want to leave that sort of comment in my comment trail as that's the short answer. The longer answer goes something like this.

The plugin we have inside Kroger is pretty Kroger specific and reaches far beyond the boundaries of what Fusebox should offer/dictate, in my opinion. Beyond that it is mixed and jumbled up with a large amount of Java web app generation as well. There is also the added complexity of competitive advantage that might keep me from being able to release it. I have not asked so I am not sure where that would take me at this point. All in all the plugin would force way too many things on developers and most would probably find it's restrictions more problematic than it is worth. That being said the concept of the plugin is rather nice and I think I maybe have even mentioned to Marc at one point about making a plugin available. It would not be the Kroger plugin but instead a separate one that I build with lessons learned from inside Kroger. In fact as I think about it what I'd really like is to create a plugin that allows additions to be added, so I can use it internally as the core/seed to Kroger's plugin and externaly folks can use it as the core for Fusebox project creation or Model-Glue generation. In all honesty the plugin does little more than what a nicely written ANT task can do, it just feels cleaner and has a slightly nicer flow to it inside Eclipse. At the end of the day I am one person though and I have to make a decision on what is worked on. Personally, as I said before, I think Fusebox itself is in a happy place right now, it is stable and has reasonably good functionality. So chances are I'll probably work on things like this before picking up the core and flopping it around too much. In short no Marc Kroger's plugin as it is today will not ever be released. After some refactoring some of it, it might be release. There's still the the whole getting permission to do it that may or may not work out.

Hello Team Fusebox

I've been very busy lately with many projects so my blog has been quiet, though I hope Bill Shelton, myself and Marc Esher (among others) can pimp some of this stuff we are working on soon. I did want to take a minute to make mention of the announcement that was made in the cfConversation's round table. It's now official, I am the new developer in charge of the Fusebox core files. Check out the announcement for my brief statement, also check Sean's blog (like you haven't already). Expect me to think out loud a lot on my blog about new features and changes to Fusebox in the future. I do want to thank Sean for entrusting me with the core as well as his kind words, I appreciate the opportunity.

In all honesty Fusebox is in a happy spot right now and aside from bug fixes I am not planning on touching the core much right away. I've heard some rumblings about getting full support for Fusebox 3 and I'd relly like to hear why, and see how many want this. Over time as I get more comfortable with the core files I might try to achieve full Fusebox 3 compatibility but that will take time. Intially I think I am more interested in experimenting with speeding up the core, small enhancements to the no XML features, and providing more definition to layouts (more on this soon this is very much an incomplete thought). So what do you hate about Fusebox?