cookies and code

So I spoke to Simeon Bateman this weekend at cf.objective() and he was showing me something really cool, Flex talking to a Rails app. He was using a technology called Web Orb which installs as a plugin to your Rails app. In the demo Simeon showed me he started up the Rails app using WebBrick and then his Flex app worked w/o a hitch. From what I could tell, using the plugin was as simple as creating an XML file used to map controller actions in Rails to aliases which can be referenced using the RemoteObject tag in MXML or the RemoteClass metadata needed to use the AMF gateway to transfer VO across the wire.

What comes to mind which makes this really cool is the idea of rapidly producing a service layer API using Rails. Imagine what type of productivity could be gained from doing this in the Flex community.

We also had a good chat about JRuby and how it could definitely be used to create the Rails app feeding data to Flex. What’s even crazier is, would you even need WebOrb if you could write a ServiceLocator that uses the javax.script package in Java 6 to invoke JRuby services? Who’s to say that you couldn’t write an adapter and include it as a JAR dependency for JRuby for Flex integration?

Just some ideas. Any thoughts?

I’m definitely very excited for the ColdFusion community. This conference has turned out to a great step in the right direction in terms of architecture for sure. Multiple perspectives were presented and people were receptive. A good balance between design approaches was presented. People are starting to use ORM’s and seeing value in what they provide. The basic concepts of an SOA have been introduced. Best of all, everyone seems to understand the topics that are being presented.

I’m also very excited, as you can probably already guess, about the ColdBox framework. I spoke to Luis yesterday and he’s already implemented the CFEclipse XML framework configuration options for ColdBox. He also added functionality to view the contents of a RequestContext into the already crazy debugging tools available in the framework. This guy is out of control. He’s got a huge amount of drive for the framework and a focus on making it easy to use and manageable via a cool polished toolset.

ColdFusion is still kicking and once again the community has risen to the occasion.

This was the final session of the conference. The speaker, Daryl Banttari, put together a very good introduction to cryptography. Yet again another well prepared talk with a good use of terminology. Daryl discussed:

• Man in the middle attack using packet sniffing and/or ARP cache poisoning via impersonation and interception
• Vulnerabilities in WEP (he stated that it can take as little as 1 minute to break now)
• Explained the mechanics of SSL. He cleared up my misconception about what public key encryption was actually used for in SSL (to deliver a symmetric key for HTTP message encryption).
• Message digest (=cryptographically strong hash). Typically 128 bits + in length. MD5 and SHA-1 shown to be weak.
• Digital Signatures – a means by which checksums can be created for message confirmation. DS are verified by trusted resource: CA or PGP (for example)
• No support in ColdFusion for public key encryption. Java has support but has potential to be complex.
• Bad Systems
• Passwords stored in a digested form used for authentication – Use a shared key between client/server as a salt for the hashing process, this can prevent a “man in the middle” attack. Public key encryption can be used with the help of trusted sources.

There were a few questions about OpenID and the issue of trust, but Daryl didn’t get into too many details when answering the question. Overall, a good end to a great conference.

My boss, Max Porges, gave his Java talk on Sunday and did a great job. As far as this blog is concerned, I will blow as much smoke up his ass as required to make my working environment even better. In all seriousness though, he went over a great introduction to the tools and environments we use in-house with respect to Java and how easy it is to be productive. He showed a lot of productivity examples using Eclipse and a few comparisons of using CF versus Java and what the benefits were to doing each. Good stuff and hopefully encouraging to the community.

Let me start out by saying, I had little to no expectations about this talk whatsoever. In fact, I bought Internet at the conference for one day to specifically, at this talk, update my blog. Well I was very happy that my expectations were not correct. Wow, Hal Helms hit the nail on the head in terms of explaining object oriented concepts, UML, and dynamite examples. He was able to associate terminology with concepts I had yet to formalize in my head. His slides referred to a few OO books which I may buy just because of how his presentation went. Hal basically focussed on how to design the domain model associated with an application. He addressed what I’ve been calling light-weight designs, but he calls service-level designs, and how common it is that people will place their application business rules into service-level APIs, even mistake them for service-level business rules.

Overall, Hal’s talk was a great and I am happy I went and kinda disappointed I missed his Large Scale Architectures talk. Supposedly, his talks should be up on the cf.objective() site soon, so I’ll try to link to them soon.

WWBD. This is literally the shirt a bunch of us wore while Ben Forta gave his talk. I think it was meant to flatter and mock … that being said, there were a bunch of us and I’m a follower. In any case, Ben went over the newly released facts for ColdFusion 8 today. The biggest of all of them was a confirmation that the release date was truely MID 2007, so probably June or July.

Unbeknown to Ben, he revealed a feature that everyone had been showing all weekend, the CF AJAX debugger… We were a little confused about what was going on, but he explained a little more about it and I guess it was cool. He basically showed us that when using the <cfform> tag and its AJAX capabilities, ColdFusion loads its own DOM into the browser via a <script> include. If you want to add custom messages to their AJAX debugger, you can do so through their DOM.

Ben also reviewed the current capabilities of the ColdFusion Extensions for Eclipse. He showed a wizard to build modular window-based Flex app within Eclipse and then revealed a way to do the exact same application using CF and AJAX in a wizard for Eclipse. I had never seen the ColdFusion extensions for Eclipse, so it was cool to see how some of the “out of the box” applications have been created.

The coolest part of the talk, in my opinion, was when Ben revealed that they’ve integrated the CF Debugger into Eclipse’s default debugging perspective. You configure Eclipse to listen to the remote debug port on Scorpio and then when a request is made to the ColdFusion Server while you have that code open (in debug mode), Eclipse will begin the debug process. Watch expressions, break points, and all the fun goodness that we know for Java is said to be supported. We’ll see if this includes hot deploy of code during debugging like we can do in Java.

The final feature Ben revealed was that FDS can now be installed within the same application server context as ColdFusion to increase performance. I haven’t done any CF/Flex integration, but this will definitely make it easier to mess with later if I want to. He said the install process for CF8 will even ask you if you want to install it. Pretty cool stuff.

This session was with Paul Kenney who is now working with Adobe in their Hosted Services Group. He is also the creator of cfcUnit, so I was eager to see what the framework could do compared to our experience with cfUnit.

Paul basically described test driven development (TDD) as the incremental process of designing your unit test cases prior to writing your code. He was explicit in saying however that you should develop test cases and their corresponding code one at a time. The goal was not to spend the entire time developing a test suite that didn’t have the ability to run. He said TDD was the process of implementing the most basic functionality needed (the provided specs in most cases) to satisfy the Test (I usually call this a test method). Once you’ve completed your code base and test cases, TDD requires that you participate heavily in refactoring to seek out the following issues:

• Duplication of responsibility
• Unclear Intent (classes with low cohesion)
• Code Smell (=Intuition about your code)
• Adding relevant comments
• Indentifying if something should be a data class (which I think is what he’s calling a VO)
• Code Duplication
• Inappropriate Intimacy
• Large Classes (possibly low in terms of cohesion in which size is a potential indicator)
• Lazy Class (not sure about this one)
• Long Method (again another low cohesion issue)
• Switch Statements (possible indicator for seperation of responsibilities)
• Shotgun Surgery (code changes propagated across multiple classes, possible identification of tight coupling)

I like some of the terms he used because they’re quirky, but I didn’t see a lot of formalization in the presentation.

Paul then showed us the basics of how cfcUnit works. He has a nice test runner compared to cfUnit, but with the CFEclipse integration now, I don’t see that as a huge advantage. I also noticed that on a failure, only the failure message, default or custom, is delivered in his test runner, but no line number is available. This kinda sucks and I’m not sure cfUnit has that functionality, but it’d be nice to see. Overall, I didn’t really see a reason to switch over to cfcUnit from cfUnit at work. Pauls says now that he’s getting a lot of community support, he is going to start putting together a bunch of new resources for the API, improving support, and begin looking into what upgrades he can give the framework. I’d definitely like to see more in terms of the hacked form of annotations I’m seeing used now at the conference (idea of added extra attributes to a tag, so getMetaData() can be used during introspection on the tags).

This wasn’t a session at the conference, but it caused me to miss a few sessions today. I wasn’t that impressed with the topic selection today anyway so this was more fun and more educational. I was able to catch up with Luis Majano for almost 4-5 hours today. I interviewed him at my previous job and really got a chance to know him better today. He humored me and gave me a full walk-through of ColdBox over an espresso. Wow, he has really found a good balance between convention and configuration I think. I really think that ColdBox has the ability to do for ColdFusion what Rails did for Ruby, or least to certain degree. Luis has built-in more tools than I can think of to help with productivity and debugging. ColdBox has framework configuration options available in XML, but the bulk of the work done by the application programmer is done by using convention. ColdBox has tools to generate a working application skeleton, a robust caching mechanism, and an amazingly sexy debugging utility. What even crazier is that ColdBox gains most of its power from the massive number of plug-ins available for the framework and the ease in which they can be created. ColdBox comes with support for Java localization and layout management out of the box and even better, if you want they can be turned off. There are tons of things I’m leaving out but I would definitely suggest checking it out. I’m seriously considering it over Fusebox after talking to Luis.

In an effort to better understand how the framework works and to help Luis with the 2.0 release, we sat down and did a domain model analysis to see if we could develop a more descriptive domain model. We made some good progress and will hopefully pick back up tomorrow.

The sheer amount of work that Luis has put into this framework is amazing. With the current documentation available for the project and Luis’ robust approach to product management, this framework is not going away. The tools alone make it worth using this framework. Definitely check it out.

Well, in my normal indecisive fashion, I’m giving the CF community its check mark back. Sean Corfeild fails to disappoint. Even though he’s not working with Adobe anymore, he went into the details of how Adobe.com absorbed Macromedia.com and built a robust service layer used by “tons” of web applications. He outlined the basic necessities of building a SOA as below:

• Data Dictionary (aka Canonical Data Model)
• Service Directory for discovery purposes
• Creation of software APIs as services (SaaS)

He gave some pretty cool statistics regarding SOA growth in the USA. He showed a study which revealed that SOA-based applications have grown by 20% over the last year and are expected to increase by 6% annually. His prime example of this was SalesForce.com, but I’ve heard nothing but bad things about their success, so who knows.

Sean outlined the distinction of 4 tiers commonly found in SOA:

• Controller/Presentation
• Service
• Business/Local Model
• Database/Persistence

In Adobe.com they implemented all of the tiers using ColdFusion and Oracle for the persistence tier. Here are a few points he made regarding good practices:

• When creating services for the Service Tier, try to use stateless services which can be used to emulate business processes.
• When requesting a service, authentication should be a major concern. Sean suggested using SSO solutions with randomized tokens being passed. When using this approach, it was mentioned that a policy for token clean-up should be addressed up-front.
• When constructing datatypes for the canonical data model, consider using primitive types which are shared between environments.
• Perform a full analysis of the protocols available in your environment and the ability of each environment to work with that protocol (e.g. – SOAP and Java not as easy as it may seem whereas with CF it’s much easier).
• When creating the canonical data model, expose the minimum amount of commonality in your data. Exposing information specific to some systems but not other may cause dependencies though misuse of the API and accidental tight coupling with consumers.
• When creating a common exception data model, keep the means by which an error is reported as simple as possible. Distinguish success and failure. For success, return the result of the RPC call. For failure, return a basic exception model containing a type, message, and details. In doing so, programmatic mappings can occur as well human readable messages.
• Solving caching concerns are difficult. If you can utilize an existing commercial protocol for messaging, like JMS, do so to avoid having to write code for this problem.
• Unit test the crap out of everything.
• Don’t allow legacy data models to dictate your canonical data model. Start from scracth to avoid being stuck in stale models.
• Avoid SOA explosion and extreme API granularity.

It was funny to see Sean say that they chose REST’ful web services instead of JMS for internal messaging. His reason was they could get things done more quickly with web services, but acknowledged JMS would have been a better solution and they got lazy.

This talk was extremely reassuring and a just a great talk. Great job Sean.

The selections for today’s session were kinda stale. I started with this session and only went to 2 others. Matt Woodward gave the talk and it was ok. He is a good presenter but he was introducing a very light-weight approach to architecture and didn’t mention anything regarding other options. Felt kinda one-sided but whatever. I finally learned how the ColdFusion community is using certain terminology in this session. A DAO is regarded as a proxy for datasource that returns single instances of domain objects. A Gateway (referring to the Table Gateway pattern) is used as a proxy for a datasource which returns multiple instances of a domain object but in query form. Exactly, wtf. There was no notion of a collection of objects anywhere, so that mark I gave the CF community yesterday, yeah … I take it back.

Overall, it wasn’t a great choice and I got a good survey written for the session so I said my peace. The other choices were Database Tuning and Hal Helms Large Scale Architectures, so the lesser of 3 evils I guess.