I love the NFL. Let's get that right out there. The players, the personalities, the strategy, the matchups - it's an amazing game, and an amazing business. Having said that, I think the NFL is hanging onto tradition without reason, and it is hurting the franchise.

What am I talking about, you might ask? The league announced that the Rams, holders of the 2nd pick in this weekend's draft, could not negotiate with any plaers prior to their selection on draft day, even thought the Dolphins have already signed the 1st pick, offensive tackle Jake Long.

NFL draft weekend is an anachronism that needs to end. Why limit the negotiations? Let players start negotiating with teams as soon as they like. My understanding is that some of the owners are afraid of cutting down on the media coverage (and advertising opportunities) of NFL Draft if they allow negotiations outside the first pick before draft day.

I think the NFL is being shortchanged. for the draft, and so are the fans. I suggest allowing the process to start after the NFL Combine and run until the end of April. The league should cover the entire process, end to end, through a social network on nfl.com as part of NFL Network. Link in the NFL Network channel, mobile Internet, SMS, and other social networks, and you have daily coverage of the draft for weeks on end. That kind of highly targeted Web traffic (based on profiling all users of the social network) is worth gold to advertisiers. The NFL needs to make the Web 2.0 transition and build an emergent Web-based system around the draft, and the league in general. 

What's more, turning the draft into a multi-week saga will appeal to what fans really want - drama. The league is trying to attract more female fans, well here is the opportunity. The human drama, player by player, of the NFL Draft is more exciting than any contrived "reality" TV show. Let the fans experience what the players experience, up close and personal. 

Lately at Emergent Path we have been building applications using ColdFusion on the server side and Flex on the front end to create very compelling Rich Internet Apps. I have settled on a standard set of technologies and frameworks that provide a standard way of building web apps, and I wanted to share my thoughts.  I am hardly alone in the direction I am moving. Anecdotally, several people I know have been building applications in a simliar way, and blogs and mailing lists are starting to fill with technical questions around various parts of the solution.

On the client, we use Flex with the Cairngorm framework to build well-organized, maintainable code. Cairngorm has a reputation as being a little heavy, and we have experimented with variaous cusotmizations and simplications of the framework. There are other Flex frameworks out there, but Cairngorm at the moment is the most widely used, so that is our current standard. Flex handles the View and Controller aspects of the application.

On the server, we use ColdFusion 8 (and that's important, upgrade your server!) with Coldspring to handle the Model. Coldspring is robust and scalable and is rapidly becoming my favorite ColdFusion framework. It only handles the model, and it is a complimentary technology to Fusebox, Mach-II, Model-Glue, Coldbox, and in this case, Flex. 

Coldspring supports the Transfer and Reactor ORM frameworks, but to date we have not used them in any development projects. We tend to customize the model code, and ORM for us has no clear advantage over other code generators. We have been using the Illudium Pu-36 Code Generator for our base model generation. It is a fairly limited tool, supporting only 1:1 table-entity mapping, but it is very easy to use and allows for customization of the code templates to suit your own architectural style.

Under this paradigm, our ColdFusion apps end up with an Application.cfc and index.cfm in the root, the coldspring folder, a model folder, a services folder (for remote service proxies), and that's it. The Coldspring.xml config file, and any other folders (such as upload/download directories, db scripts) can be held outside the webroot and accessed through the local file system. Images and CSS elements are held in the Flex source folder and deployed at compile-time to the proper location.

This paradigm offers simplicity, rapid development, scalability, and good code organization for long-term maintainability. I've been thinking about making an acronym for it, but I haven't come up with anything yet. 

Apple just released a big patch bundle for OSX, 88 patches in all, 105 MB You can read about the full details in an article on the Register   I wonder if the "big bang" patch release system set up by Apple is related to the release cycles of open source projects like Apache, OpenSSH, and ClamAV? 

 I like the idea of releasing fewer patches with more frequency, but I don't know if Apple has that luxury. Ubuntu has a six month release cycle, and I see some packages missing a release on occasion if their project teams are not on the same schedule. I wonder if it would be possible to get major open source vendors on a common release schedule? Maybe they try, I am going to ask someone from an Ubuntu team and see what they say. If you know the answer, drop me a comment, I would love to know.

One thing I know for sure is that Ubuntu is big, REALLY big, 17015 packages and counting at the moment. Even if only ten percent of those packages are being actively worked, that represents an enormous logistical challenge to get all the project team to hit specific targets. Ubuntu contributors are using collaboration software, especially emergent systems like wikis and blogs, which are great for software projects. I'd love to see someone attempt to build metrics around the use of these collaborative tools in the development of Ubuntu, because it is such a big open source project and it provides both transparency to make it easy to study and enough size to provide both a really good sample of data and scaling evidence from projects large and small.