Doug Boude (rhymes with 'loud')

27 May 2008

Model-Glue 'Generic Read' Time Tests

Categories: goog Model-Glue

It's in the wee hours of the night and I'm trying to knock out one more item from my client's laundry list: speed up the load time of a specific template in his Model Glue app.

This particular template has several different select lists, each being populated with the results of a Model-Glue generic List broadcast. It also relies upon the return of a pre-populated object that is fairly "heavy" as far as Reactor-defined objects go (many hasOne/hasMany relationships), it being retrieved via a MG generic Read. (if you're not familiar with Model-Glue's generic database messages, check out the MG Docs). So, the first thing I thought to do was find out if a generic message was the most efficient way to interact with Reactor.

I created a simple method in my controller that, for all intents and purposes, duplicated the functionality of the generic Read:

I then modified my modelglue.xml, commenting out the generic Read and replacing it with a message to my replacement method:

<!--

-->

Now for some time tests based on Model-Glue's debugging output!

The results showed that, after the application's initialization ("init=true"), the generic Read was an average of THREE TIMES FASTER than the manual record creation using the ORM Service (99ms VS 307ms) . During initialization, the manual record creation was an average of 26 TIMES FASTER (422ms VS 11,070ms)! But, how often do you really need to reinitialize your app? I'll be sticking with the generic Read.

I didn't dig too deeply into why the performance differences might be there, but I did notice that the Model Glue's implementation of the generic Read is utilizing the ORMAdapter and the 'read/new' methods, whereas the manual call examples I found to create a Record object use the ORMService and the 'createRecord' method. Not sure what the difference there is, but there must be one.

Anyway, just thought I'd toss that out there as some rough empirical evidence to support the use of MG's generic messages (if your app uses an ORM ).

P.S. If you're interested in the raw data(er), well, it was just too bulky and boring to take up blog space with it. If you really want to see the actual times, though, here they are.

Posted by dougboude at 2:05 AM | PRINT THIS POST! | Link | 1 comment

14 May 2008

Viewing Option Text (in IE7) that's Wider than the Select List

Categories: bill's browser ie javascript goog code snippets

Though a "minor" cosmetic issue at times, it can be challenging to come up with creative ways to accommodate what I consider to be IE's shortcomings regarding the control of form items, in particular select lists. With at least one project I'm currently working on, I have a select list that lives in a fixed width div, yet there are times when the text values of the options are wider than the div itself. The client respectfully requested that I find a way to make the full option text display whenever the user clicks on the select list, so I of course referred to my reliable friend Google. After investing a couple of hours exploring different approaches to the challenge, I found none that I could get to meet my needs in both Firefox and IE. Oh, by the way, Firefox AUTOMATICALLY displays the full option text when you drop down without any developer intervention needed. Do you realize how much development time could be saved if IE worked the same as Firefox??? Anyway, I digress.

The solution I came up with (which I didn't find anywhere in all of my googling) was very simple: when a user clicks the select list, swap out the class to one without width restrictions. When they make a selection, swap the class back to one WITH width restrictions.

I make sure that I set my container div to a fixed width and set the overflow to 'hidden', that way when my select list suddenly grows, it doesn't force the div to widen OR overlap any adjacent divs. Without further adieux then, a simple before and after (bear in mind that if you're viewing this in Firefox, you won't see any problem with the first list; it's only BILL'S BROWSER that has the issue):

I am the problem select list:

I am the better select list:

Here is the code for the samples above:

width:300px;

}
.plainDropDown{
    width:145px;
    font-size:11px;
}
</style>
<div style="padding:4px;width:175px;height:75px;border:thin solid black;overflow:hidden;">
I am the problem select list:<br><br>
<select name="someDropDown" id="someDropDown" class="plainDropDown">
    <option value="">This is option 1.</option>
    <option value="">This is the second option, a bit longer.</option>
    <option value="">Drink to me only with thine eyes, and I will pledge with mine...</option>
</select>
</div>
<br>
<hr width="150px;" align="left">
<br>
<div style="padding:4px;width:175px;height:75px;border:thin solid black;overflow:hidden;">
I am the better select list:<br><br>
<select name="someDropDown" id="someDropDown" class="ctrDropDown" onBlur="this.className='ctrDropDown';" onMouseDown="this.className='ctrDropDownClick';" onChange="this.className='ctrDropDown';">
    <option value="">This is option 1.</option>
    <option value="">This is the second option, a bit longer.</option>
    <option value="">Drink to me only with thine eyes, and I will pledge with mine...</option>
</select>
</div>

One More Note:
This solution is a little bit less than perfect in that if you click the select list and don't choose a NEW value, the class doesn't switch back until you actually blur, or click off of, the select list. I have been unable to find a solution to that one anomaly, so if anybody out there has an idea, please do share!

Hope this helps somebody.

Doug out.

Posted by dougboude at 11:31 AM | PRINT THIS POST! | Link | 12 comments

Inline CSS and Ajax Issue with IE

IE Got Me Again

Categories: bill's browser ie goog

After spending more time than I care to say troubleshooting a CSS issue with IE7, I thought I'd share the details here in case it saves anybody else some time later down the road.

The Scenario...
I have an application that updates the contents of one of its divs using an ajax call that returns html. Within that retrieved html is a style block (<style>...</style>) defining how I want my table headers (<th>...also contained within the retrieved html) to appear.

IN A NUTSHELL: IE7 does not recognize inline styles that were retrieved via an ajax call.

Perhaps this is a "duh" item to some of you who already knew it, but since my beloved FIREFOX accepted them just fine, it didn't occur to me until I had tried every other possible iteration and syntax to move the styles out of my retrieved html and into my app's global CSS template, which (by the way), is the solution to this issue.

Hope this saves someone else some time and emotional pain.

Posted by dougboude at 11:00 AM | PRINT THIS POST! | Link | 9 comments

09 May 2008

The Perfect Alternative to Gas Powered Vehicles

Categories: Personal idea

I'm sure by now we're all of the opinion that we have GOT to find an alternative to gas powered vehicles. I was musing on this very topic last weekend while sunning myself on the banks of the Guadalupe river, and came up with what I think is a GENIUS idea (though my wife whole heartedly disagrees for some reason):

A giant wind up car.

We know how the little wind up cars work...wind up a spring, then utilize the potential energy as the spring uncoils. Well, why not make one that's big enough to seat two or four people? Of course, we'd have to engineer the "perfect" spring, perhaps a pair of them to work in tandem. I'm thinking some elongated, layered, torsion type spring, working similar to those airplanes that use a rubber band that gets twisted. And we'd need some really good gear ratio math in place to get the most bang for our potential energy. And here's the cool part: each passenger is fitted with a set of pedals, so when the spring gets to say, 50% or less of its total wind-up, the passengers and driver start pedaling to wind it back up again (from its center, or opposite end) and the car just keeps rolling along.

Now tell me that isn't PERFECT! It isn't like you'd have to pedal yourself around, just pedal on occasion to keep the spring wound up. and with good gear ratios on the pedals (and even a shifter so you could choose how hard or easy to make the pedaling), it shouldn't take a lot of leg work to keep things going.

Whadayathink???? NO pollution, NO high tech, NO noise, EASY maintenance (like a bike!)...sheesh, what's not to love? Let's make this thing happen. Any high torque spring engineers out there in whose brain I have spawned the beginnings of a blueprint???

:0)

Posted by dougboude at 11:56 AM | PRINT THIS POST! | Link | 1 comment

07 May 2008

Promoting Family Unity: Lowering Your Utility Bills!

Categories: Personal family

Okay, I just have to boast a little bit about the great success my family and I had this past month with our energy conservation, evidence being our electric bill. Grand total for the month of April: $96.

For context's sake, here's the scenario:

We live in a two story, 2500 sq foot home that is half brick. It is situated east-west, so our back porch area sees the sun all day long (thus making the southern most rooms warmer). Currently, there is a minimum of five warm bodies occupying the house and using the resources at any given time, this number expanding up to ten and twelve bodies every other weekend or so when my kiddos stay with me (My wife and three of my step children live with me full time, I have seven kids and she has one more who comes over periodically as well). As you can imagine, in a typical scenario like this every light in the house would be on, the tv would be blaring, the fridge left open, water running and toilets flushing constantly...moderately managed chaos. Ah, but in our house it doesn't quite go that way. Here are some of the things my wife and I did to achieve such a monumentally tiny electric bill...

First, we both became electricity nazis, in more ways than one. Not only are we tenacious about making sure no electrical appliance is ever in use unnecessarily, we're also expert brainwashers and masters of persuasion (or coercion, whichever you prefer ;) ). So now, even with as many kids as we have running around, it is indeed a rare occurrence for ANY of them to leave an empty room with the light on, or a radio playing when they are finished with it, or even the computer monitor on after they're done updating their Myspace. In addition to making sure that the rules of the house are keenly observed, I also installed the alternative fluorescent light bulbs throughout the house. Fact is, they may NEVER actually pay for themselves, but for some reason it gives me peace of mind knowing that for every hour of light a person uses, I'm only using up one fifth of the electricity to do so.

I think the most effective thing we did, however, was when I took on the addition role of AC/Heat nazi. Living in south Texas, we are blessed with some fairly moderate weather for a good portion of the year between winter and summer. So, I made myself king of the thermostat and when people complained of being cold, I did the most OFF THE WALL THING: I told them to put some more clothes on or grab a blanket. When they got too hot I made yet another unique suggestion: take off some clothes and put yourself under the ceiling fan or go outside. When taking off more clothes wasn't an option (we don't subscribe to the nudist philosophy), I went out and bought everybody their own personal floor fan. Here's my logic: You as an individual are either hot, cold, or just right when it comes to the ambient temperature surrounding your current location. So where is the logic in spending the electricity to drop an entire house three degrees when you will only ever be occupying one spot in that house at any given time? All you really NEED is for the place you happen to be in to be comfortable for you, temperature-wise. So, put yourself in front of your fan. It's at least 10 degrees cooler in the low breeze of a floor fan, and perfectly comfortable. So, by taking this approach we've managed to only use our AC probably three times so far this year, and each time only for a couple of hours (when even I said, "DANG, it's HOT in here!").

Let's see...besides that, I think the only other thing we actively do to conserve is to also be fridge nazis (figure out what you want in there BEFORE you open the door, then get it and close it as fast as you can!).

So, the consistent, collective effort of a family to help bring their bills down to manageable amounts DOES pay off! It also helps lend cohesiveness and a sense of teamwork to the family unit, and you can't get too much of that stuff, eh?

Posted by dougboude at 3:20 PM | PRINT THIS POST! | Link | 1 comment

01 May 2008

Why I Hate ORMs (a solicited rant)

Categories: OOP Frameworks rant goog ColdFusion Model-Glue

A necessary disclaimer...
Everything in the following post that appears to be an opinion most likely is and should be taken as such. My personal view on a topic does not (necessarily) invalidate any other opposing view. Readers should ascribe whatever value they so choose to the information that follows and either adopt it or reject it at their own discretion.

In the comment thread to a post I did on custom validation in Model Glue, I shared the fact that ORMs aren't my friends. In so doing, it prompted another commenter to ask me to share more details about my decision to be anti-ORM, as they too are weighing out the pros and cons of incorporating it:

" Doug,
Can you elaborate on why you've abandoned ORM? I browsed thru your blog but didn't see any references to this decision. I'm wrestling with its costs vs benefits as well and would be interested in hearing from someone further down that path.

Thanks,
Dave "

What follows are those details.

Why I am Anti-ORM

The Beginning

Just over a year ago, my team and I embarked on a journey to learn the ways of the object oriented programmer. We evaluated some of the popular Coldfusion MVC frameworks and decided to go with Model Glue. At the time, the trend was also to utilize other frameworks alongside Model Glue, so we too jumped on the bandwagon, reasoning that if we were going to adopt the tried and true standards of the OO world, we were going to embrace it completely. So, we architected our first MVC application, opting to utilize MG as our MVC framework, Coldspring as our IOC framework, and [brand X] as our ORM. For those of you who may not know what each of these frameworks are for, ModelGlue is the framework that separates, organizes, and "glues" together your views, your CFCs, and the controller CFCs that act as liaison between the other two. Coldspring is the IOC (Inversion of Control) framework whose job it is to manage the relationships between your CFCs. For instance, you might have a User.cfc that needs to perform a function located within another CFC such as Security.cfc. Using Coldspring, you can define that relationship ahead of time and, rather than hard coding the instantiation of your Security.cfc within your User.cfc, Coldspring will do that for you automatically whenever your app asks for the User.cfc. Ah, and now for [brand X]. {brand X] is an ORM framework whose job it is (and here's where my opinion and personal understanding heavily apply) to add a layer between your app and your database. The reason for this, you might ask? The reasons that my team and I saw for doing so were:

1) To allow us to easily change backend database platforms later down the road, should the need occur (not likely, right?)

2) To allow us to take advantage of some of the nifty "helper" features, such as auto-validation and scaffolding (automatically building Create, Update, View, and Delete forms for a given table)

3) To allow us to pre-define relationships between data so that we could "drill down" into child data by calling auto-generated methods, without having to query for it

4) Because using [brand X] was what every CFer "in the know" was doing, so it must be the right thing to do!

Sound like decent reasons, right?

I'll summarize, from my experience, the reasons that ORMs gave me to despise them. I'll try my best not to rant (actually I already did a lot of that in this other post).

The Reasons

The first reason my ORM gave me to hate it was that it forced me to have to synchronize case between field names and elements within different XML files. Coldfusion has LONG been a case-insensitive language for the most part, but suddenly now, as I am embarking on a journey through the foreignness of ORMs, I have to ALSO be mindful that everytime I type in a field name, I had just BETTER make sure I type it exactly the same way every time! Of course, I learned about this the hard way, through many hours of troubleshooting, following nearly useless error messages, and piecing together scraps and tidbits from here and there on the net building myself a "Franken-Solution".

Second reason: the Coldfusion ORM frameworks are a work in progress, and thus subject to undiscovered anomolies coded into their core. While my team and I were burning the midnight oil trying to learn and use our ORM, it kept changing on us. We'd update and replace core files only to find that some behaviors had suddenly changed. The one thing that DIDN'T change were the nearly useless error messages, though...that kept it "interesting" for us.

Hey, this ever happen to you? You're building an application and suddenly realize you need another field in a certain table, so you...go ahead and add it? Sheesh, it happens ten times a day sometimes! A very common occurrence, a very expected occurrence, right? Which leads me to the third reason my ORM gave me to hate it: our ORM didn't take kindly to change. It took us FAR too long to try and figure out how to cause it to see and propagate database changes throughout the app without spilling its groceries into a useless error message. The final solution, that took us weeks of evolving to: nuke it. Just delete the whole cotton-picking cache of files that our ORM had automagically generated for us and FORCE it to recreate them all. This approach defies common sense, and thus it was the end of our evolution and not the beginning. Why's an ORM gotta defy common sense?

The fourth reason: gluttony. As mentioned in the list of reasons why we chose to use an ORM, we wanted to leverage the beauty of pre-defining data relationships and be able to drill down into child data with ease. In theory, this is a beautiful thing. In practice, it's a disgusting hag. The bloated, inefficient objects within objects within objects that get created in this process can cause an app to literally CRAWL. What would take less than a second to perform the traditional way can take many hundreds of times that amount of time when using these auto-generated object nests. When you do take the time to define all of these relationships as they truly are (and good luck getting that right the first five tries), the resulting objects are ginormous and slow as molasses on a cold January morning. Painfully slow. Not acceptable, ORM. Not acceptable.

And ah, the grandest reason of them all that I pretty much despise ORMs: losing my beloved sql. Now, I wouldn't have a problem with losing sql as long as my ORM provides me with a suitable substitute. But it does not. The task of translating a simple sql statement into "ORM-speak" is far, far from simple, my friend. I and others I know have quite literally spent an entire DAY trying to figure out how to write the code, leveraging our ORM, to execute a simple join. Don't get me wrong, it IS do-able. But from the perspective of someone who knows how to query a database, doing the same thing using only ORM objects is convoluted, WAY over-complicated, gluttonous from an efficiency point of view, time consuming, and in the end....what the heck good is it anyway? What did I just do to help myself by spending an entire DAY figuring out how to define object relationships in a way that my ORM likes, defining events that have every parameter present and properly cased, making sure that the database changes I make along the way are actually recognized by my ORM and my application has been properly reinitialized, and then synchronizing the whole thing and crossing my fingers that it'll actually work and not throw me back some useless error? Writing and executing what was and is simple SQL is ridiculously convoluted by an ORM, eats up a huge amount of precious development hours in figuring out how to do it, and gives me only negative return on that investment by creating code that increases my bottom line in IO and makes it so that only another person who has drunk the ORM kool-aid can possibly ever understand. Oh yeah, and when you DO finally figure out how to write a simple join, you then realize that there are actually probably four or five different ways you could have done it using the ORM objects; which one is most efficient? who the heck knows, and you'll only know if you invest the hours to write it with each approach and time it yourself. And even your ORM's BEST and most efficient approach will STILL NOT beat the time you would get by executing straight SQL...there's no way.

Conclusion

What this and any decision comes down to is really just a list of reasons TO do something versus reasons NOT to do it. In this case, based on what I consider to be thorough personal experience combined with that of my peers, adopting an ORM has an extremely sparse list of "Pros" which in no way even come CLOSE to outweighing the list of Cons that come with it.

I realize I didn't do very well at filtering out my ranting. I also realize that, if you happen to be a person who has already gone to ORM prison and now you're used to the lifestyle of having it dwell within your apps, you're going to have a totally different take on it. But I'd be willing to bet money that even you die-hard ORMians felt the same way I do at one point in your J-Curve, only instead of ceasing to knock your head against the wall, you banged a little longer and finally broke through it. Now it's second nature to you to know where NOT to step in order to avoid the landmines, so you can play soccer freely in the minefield having only lost a few virtual limbs in the process. HOWEVER, if you are the person who has yet to step into that tempting and beckoning ORM minefield, if you're still on this side of the kool-aid, you should know that forcing yourself to use and learn an ORM is a bit like forcing yourself to learn to smoke. Yeah, given enough choking, hacking, and puffing, you CAN eventually learn to love the feeling of hot, acrid, killer gases in your lungs; but is the miniscule physical pleasure and social "coolness" worth the initial pain, suffering, and certain long term problems that go with it? I say no way, and after having hacked and puffed on my chosen ORM for a solid six months, I say no way to that as well.

I am of course committing a social faux pas by pre-judging all ORMs based on my experience with one, much the same way as it is commonly said that you can't judge all women by the way one woman treated you. But you know what? Even the slickest ORM is STILL only going to provide me with 2 or 3 pros, tops, and will STILL of necessity be adding overhead to my application's efficiency and learning curve to my timeline. From that perspective then, yes, I AM pre judging and have every intention of remaining "ORM Celibate" from here on out. I've worked on several applications since the one I mentioned earlier, all completely without an ORM involved, and have been utterly delighted with their performance. Good riddance, ORMs, I'm not missing you at all and will probably never recommend you.

Doug out.

Posted by dougboude at 11:54 AM | PRINT THIS POST! | Link | 20 comments

My Score: 9,001

Read (and recommend)

Reading

<<	May, 2008					>>
S	M	T	W	T	F	S
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31