Jared, that's booties, with a "t," not a "b." Dale knitted (or crocheted, or whatever it is that involves a trip to Michael's Arts and Crafts) a pair of booties for a friend who's having a daughter, and I guess she decided that our dog, Indi, would make a good model. It made for an odd picture, so I thought I'd share...
33 comments - Posted by Joe Rinehart at 9:21 PM - Categories: Off Topic
There's a new GTalk version available that has things like iTunes/WMP/Winamp integration, voicemail, and some other fun toys. However, the URL isn't up on GTalk's homepage, and it's not showing up for everyone who uses "Check for updates...". You can, however, get it directly by hitting http://desktop.google.com/download/googletalk/googletalk-setup-testing.exe.
5 comments - Posted by Joe Rinehart at 9:47 AM - Categories: Off Topic
I've had a few people ask me a few questions about when Model-Glue:Unity will be released, what enhancements are coming, etc. So, here's an update.
4 comments - Posted by Joe Rinehart at 10:24 AM - Categories: Model-Glue
In the past week, I've read a number of posts about feature requests for ColdFusion 8 ("Scorpio"). I thought I'd let them digest a bit before posting my own thoughts.
The first post I saw in the trend was from Simon Horwith, an open letter to the CF team asking for 24-ish features. Soon, others chipped in, comments started, etc. A lot of the discussion focuses on more "Object Oriented" features like constructors, interfaces, and method overloading.
Basically, I don't want to see any of that. I understand that none of it would be required, but simply providing these three features can lead to much more complicated systems design and architecture - without much gain in effectiveness.
Simply put, I don't want the accomplishment of anything we can already do (such as fully Object-Oriented Web apps and RIAs) to get any "harder" or complicated than it already is.
Method overloading, in particular, can lead to monumental headaches, even in strictly-typed languages. I don't even want to think about its implementation or use in a dynamic language. It also has about zilch to do with fully "OO" language. After all, Smalltalk, the grandaddy of them all, doesn't do method overloading.
ColdFusion has always been about making the complex (such as building a Web Service) magically simple. It's a model that's being proven again as Rails grows in popularity. The last thing Adobe needs to do is make any task harder than it already is.
15 comments - Posted by Joe Rinehart at 2:43 PM - Categories: ColdFusion MX
I was ordering a pizza online today from Papa John's, mistyped a digit in a credit card number, and was informed that the "Credit Card number cannot be used for this reason: FAILED LUHN/MOD10 CHECK." Well, that's fine and dandy, but only because I know what it means. Not all that helpful to an end user.
I'm a big fan of always reiterating the basics: make sure your validation makes sense to an end user. Always ask someone who has no knowledge of your project to look at a basic error state and see if they can effortlessly fix input. If they can't do it immediately, or if they start asking you for clarification, it's drawing board time.
1 comments - Posted by Joe Rinehart at 2:58 PM - Categories: Best Practices
Something thing I've quietly been up to is taking a bit of time to learn Rails. Not Ruby in its full depth, but enough to understand it in the scope of what pieces you'd use to deliver a Rails app.
47 comments - Posted by Joe Rinehart at 11:39 PM - Categories: Causing Trouble
In an earlier post today, I stated a bit of why I like Reactor, and why it's what I'm using for the automated database functions in the upcoming "Unity" release of Model-Glue. Simon Horwith asked a bit about which others I had looked into - here's the list, starting with my own experiments, "Arf!" and "Paste."
Arf!
Arf! was my own toy in which I created a "record factory" that would basically create a mixin that "blended" persistence and relational/composition functionality into any CFC extending a base ActiveRecord CFC. It had a bit of a Rails flavor to it, and I do have a production application running with it.
However, it causes a lot of "kitchen sink" CFCs that act as a service layer, gateway, and bean all surrounding a single entity. Great during quick prototyping, but a little bit painful when applications grow.
Paste
"Paste" never went public. It was intended to be a compliment to Model-Glue. Fueled by Inversion of Control, it was intended as a generic "inline" code generator that focused on JDBC metadata. You could define "types" of CFCs to generate via XML (like a "Gateway"), tell it where to put the "base" (like a Reactor "project" CFC) and customizable shell (like a Reactor /model/data CFC) CFC, and it'd spit out code based on whatever CFM-based template you wrote (I hadn't learned XSL yet, and stuck with what I know.)
Basically, you could plug in your own types of code to generate, and use statements like paste.create("gateway", "Contact") to generate whatever you defined a Contact gateway to be.
Heavy stuff, but a bit of the underlying architecture (generic code generation configured by Coldspring) is stuff I'm talking to Doug about for Reactor 2.0.
ObjectBreeze
I just have a really strong bias against getProperty(propname:string) and setProperty(propname:string, value:any) methods. To me, it's against the concept of programming to interfaces. However, I really like how easy this one is to use. It was a little like Arf!, but sort of different in that you just ask for an object instead of dealing with a hard CFC. I'm also not sure how you'd add additional business logic to a given entity.
Transfer
Transfer is, to say the least, looking very robust. It's just not quite as easy to use (for me) as Reactor. Basically, I saw Reactor, it clicked in my brain, and I've been able to use it very well while never actually reading the documentation. Haven't quite had the same luck with Transfer, but some of its capabilities (such as caching) look very promising. If it exposes table metadata, it'd be pretty interesting to try to build another ORMAdapter and ORMController implementation to see if I could scaffold and generic ORM using it instead of Reactor.
Woodi
I played with it for a bit, trying to use its libraries to generate basic persistence CFCs etc, but it didn't provide implementations of the patterns needed for MG:U, and was Oracle specific (I was doing an Oracle project at the time - it uses Arf!).
Reactor simply worked. Out of the box. It was simple, and it works the way I think (in respect to bean/dao/gateway CRUD). It allows me to simply add business logic where necessary, and doesn't try to build a service tier for me, which I rather like - I can refactor to one as necessary.
5 comments - Posted by Joe Rinehart at 9:05 PM - Categories: Reactor