Doug Boude (rhymes with 'loud')

31 July 2010

THE DAY CFUNITED DIED

The Summation of My Experience

Categories: CFUNITED goog ColdFusion observations placeblogger

As you ALL know, this was the last CFUnited ever, and as an attendee, I am certain that this fact was actually a positive influence on how the conference played out. The camaraderie that is always an integral part of this event was magnified by the ever-present fact that we just don’t know when we may be able to assemble ourselves in these numbers again. I know for myself (and I do believe that I am representative of most of my CF brethren), I felt it to be even more important this year to seek out and get to know new faces, and to push myself outside of my hermit-like inclinations and spend good quality social face time. During said face time, we all engaged in the discussions of the subjects that this conference’s demise has brought to the forefronts of our minds. Why was it ending? What did it mean for our community? What would be the ramifications? Was it a sign of anything to come? as confident as we are about the future of the language we embrace and earn our livings with, the demise of the grandest exclusively CF event to grace our professional landscape in the past six years has definitely been a cause of at least minimal concern to many. But, through the process of the fellowship, the sessions, the after parties, and the after parties’ after parties, I gained an absolute reassurance that what we have witnessed is nothing more than the results of an economy that’s been on a downward trend for the past three years and is in no way a prognostication of the future of ColdFusion. In fact, what it DOES mean is that now that one of the larger trees in the forest has sadly fallen, the vacancy it leaves us with is the opportunity and catalyst to allow for the currently smaller, more focused, and/or regional conferences to flourish and fill this niche in our professional ecosystem. I firmly believe this, and have found nothing but reassurance for this belief in the past three days of being immersed among my peers and mentors.

ON THE NEGATIVE (BUT POSITIVE) SIDE...

Having highlighted how excellent the conference was, I feel the need to share a less positive opinion based on my observations this year as an attendee. This particular CFUnited seemed to greatly lack in its administration as compared to those in the past that i have attended. The staff seemed more interested in doing their own thing as opposed to being focused on the details relevant to a conference, such as session start/stop times, ensuring sound levels, recording speakers, ensuring that the doors were closed once a speaker began, giving the speaker cues as to when his or her time was nearly up, and just maintaining a positive, prominent presence throughout the event. Fortunately, and I give HUGE kudos to these individuals, there were those individuals who were in attendance that took great responsibility upon themselves to fill in these gaps. They ensured that the registration desks were properly manned and that the attendees were given the proper attention at registration, they went the extra mile and turned what would probably have been blas’e social events into OUTSTANDING social events, they invested their own time to make certain that the fellowship, the tradition, and the kindred nature that we all share as a CF community was recognized and honored. I would give specific shout outs to those who I am aware were instrumental in making this conference as memorable and awesome as it was, but truth be told, everybody in attendance had some hand in that. Together, we made this CFUnited what it should be, and we can be proud of that fact. On the other hand, the actual organizers of the event...honestly, they couldn’t have seemed more disinterested to me. Oh, and the fact that I was solicited via email to help "save" CFUnited by BUYING THE RIGHTS TO IT??? Man, that's like telling your kid you love him and then putting a price tag on his forehead. That's just wrong in my book. Like I said, just my observation and opinions here.

LOSING MY VIRGINITIES

This conference also happened to be one that resulted in a few major changes for me. Besides the hardly containable inspiration that the sessions were regarding things like alternatives to RDBMS, iPhone development, the exploration of HTML5, and a new found interest in the CF on Wheels and FW/1 frameworks, I also found myself doing things that I was certain I never would do. I, a profoundly staunch PC, discovered that I am now “i-curious”. I want a mac. It stuns me and frankly, freaks me out, every time i hear myself say such a thing, but it’s true: i want a mac. Any of my friends who know me very well are probably picking their jaws up off of the floor at reading that, as I have never even come CLOSE to waivering in my unrelenting despisings (and uninhibited vocalization OF those despisings!) of all things mac. Heck, when they first saw me palming an iPhone they nearly fainted. But after seeing the presentation on iphone development with the Coldbox framework as the backend data services, something just gave up inside of my head and I, for the first time in my life, understood what it felt like to desire a mac. I know, this almost sounds like I’m coming out of the closet, and in many ways it certainly does feel that way to me, too! A strange feeling, like I’m giving in to the thing I shunned for so long...I’m being dramatic, huh?

Oh, the second thing I did that I said I would purposefully NEVER do: I had my picture taken with Ben Nadel. Again, as any of my friends who know me well will attest to, I am in general an “anti-herd” guy; if everybody’s doing it, then to me that’s a sure sign that they’re doing something i do NOT want to do. And, since everybody seemed to be giddy at the idea of having their picture with Ben up on his site, I naturally vowed internally never to do so. But then, I actually got a chance to meet Ben and talk with him a little bit. Gosh darn it, he’s just too nice! :) So, I conceded and participated in a three way with him and Ryan Jeffords. Three way photo opp, that is. :)

WHAT NOW?

So NOW then... let’s all set our sights on the next conference or conferences we’re going to attend, shall we? Our time honored tradition of supporting our community by communally sharing what we all learn individually must continue, and it will do so in the form of ALL of us making it a point to contribute and participate in whatever ways we can. BLOG, y’all. BLOG the things you learn that have made your development life easier. TWEET. Share the tiny 140 character moments of your days that reveal your knowledge, wit, charm, losses, gains, wisdom, and personality to the rest of us. SPEAK. Overcome your erroneous belief that you have nothing of value to offer your peers and mentors and volunteer to speak at your local user group, the online cfmeetup group, other user groups in other cities, and conferences. When you get the word that such and such conference is having a call for speakers, you should be prepared to submit yourself and two or three topics that you have already presented on via the user groups. I know it can be difficult to overcome shyness and such, but believe me, all of us have something of value to offer. Heck, even the very fact that someone who never spoke publicly before is making that effort is in itSELF an inspiration to others, regardless of the topic or how smooth the preso goes!

Oh, let me leave you all with this awesome resource that Charlie Arehart maintains for the sake of his community: http://www.carehart.org/cf411/ There, you can find out about all the latest conferences and other resources whereby a CF developer can get “plugged in” to his or her community and begin partaking and sharing.

CONCLUSION

This conference has left me with a LOT of new friends, personalities and faces to connect with twitter icons, a boat load of technical inspiration, and the loss of at least two virginities. CFUnited 2010 rocked, y’all! If you missed it, you really did miss a lot.

I look forward to crossing paths with you in the future! In the meantime, if you're not already, let's be virtual buddies, eh? My twitter name is dougboude

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

18 July 2006

The Elusive Gnurd Bird

CFUNITED - ANOTHER PERSPECTIVE

Categories: CFUNITED goog

This animal is a unique parallel species of homo sapien more properly classified as homo sapien³. Unlike any other species, this one rarely procreates amongst its own kind and is typically a genetic mutation resulting from a homo sapien union. As rare as the discovery of a mating pair of Gnurds is, it is even rarer that their own offspring possess the mutation that makes them a Gnurd. Though Gnurds are often not accepted or understood in mainstream homo sapien society and tend to sport unique eccentricities, it is this same rarity and uniqueness that make them special as well.

Habitat and Social Tendencies
Though usually alone, it is also what could be termed as "socialite by proxy", communicating profusely and consistently with its kind in one of several remote fashions, but rarely encountering one another physically. There are, however, certain times of the year when these typically solitary creatures stir from their dimly lit recesses and amass themselves in what would appear to be a ritualistic manner. Exactly what the purpose of these mass gatherings are remain for the most part a mystery. Some speculate that it is a re-establishment of the pecking order which cannot be accomplished by remote means; others have observed it to be more inline with a mating ritual, necessary because of the gross unbalance between the number of males of the species as compared to females. The fact that it is still a mystery is what moved me to pack my bags and go to Washington D.C. in order to observe and document one such gathering. What follows are my notes, observations, and hypothesii regarding the things I witnessed there.

The Gathering
The first day of the gathering found other gnurds still arriving. It was already apparent, though, that certain ones were being viewed in higher esteem than others, and I could see by the plumage being displayed that some of these creatures had been leading solitary lives FAR too long for their own good, boasting such outer markings as "CF_RELAX" and "What Would Ben Do?". There were what I am calling the "groomer" birds who would meet each gnurd as they arrived and adorn them all with similar vestments and a large grey gnurd bag. Soon the gathering place was a sea of Gnurds, constantly churning in every direction. As part of their acclimation to physical socializing, the gnurds at first milled about with very little interaction between them, though that was quickly beginning to shift. What just hours before could be called an 'awkward moment' when two gnurds accidentally made eye contact was now resulting in physical interaction and inquiry. The standard initial Gnurd meeting cry was something along the lines of, "so where do you work?", with the standard gnurd reply of "for so and so". In short order these rhetorical ice breakers were resulting in gnurds pairing off or congregating into small sub groups, typical conversations consisting of discussions of their more esteemed peers and latest gnurd controversies.

The second day of the gathering was when the formalities were casually imposed, with those gnurds higher in the pecking order taking turns addressing the hordes of other gnurds. There was obvious respect for these articulate birds, with the crowds growing silent and attentive as their knowledge was conveyed. The remaining days of this brief and rare gathering followed a similar style and pattern.

Gnurd Rivalry
Blatant rivalries among Gnurd birds during their gatherings is almost unheard of and rarely witnessed. Any kind of conflicts that may exist between these creatures is manifested at such a subtle level that only another Gnurd can even detect it. Only one time during the entire gathering was it ever obvious. The situation occurred between one of the beasts which was present at the gathering and another who had been unable to make the trek but was communicating via remote means. The first beast would squawk out some nearly uninteligable phrasology, challenging the other and ascerting its point on something that sounded to the human ear like "framework bad". The remote Gnurd would respond calmly and with utter confidence. After a few moments of the sqawking gnurd getting his own feathers ruffled, the spectator Gnurds suddenly lost interest, seeming to have sided with the remote Gnurd almost unanimously, and then disseminated into the rest of the flock.

Gnurd Mating Ritual
Very little is known about the details of the Gnurd's pre-coital rituals. Chance smiled upon me, however, as I was given the once-in-a-lifetime opportunity to witness the attempts of one male Gnurd. He was sitting and casually preening his feathers when a female Gnurd approached and sat within squawking distance. The male Gnurd immediately turned her way and began spouting a unique blend of casual conversation and techno babble. The female gave the male her attention for a few moments, and then suddenly put her wing up against her head, as if to cover her ears. The male took this as a sign of disinterest, and rather bullishly inquired as to whether or not she would prefer that he cease his noise. The female responded with a squawk that meant "no, it's just that my allergies are acting up and my ear is itching inside". The male then held out his pinky and replied (and I'm going to translate the Gnurd babble here), "You wanna use my finger to scratch it"? It became obvious to me at this point why the Gnurd population is so limited and unique, and why the male of the species has such difficulty procuring a mate.

In Conclusion
All told, the trip was well worth it. Gnurds are such awkward creatures that simply to have the opportunity to observe them in social settings provides a steady stream of unique, inexpensive entertainment. Oh, and if you REALLY want to be entertained, set a keg in their midst and see what a mild alteration of their perception of reality does to spice things up.

Posted by dougboude at 4:48 PM | PRINT THIS POST! | Link | 9 comments

30 June 2006

CFUNITED - Coldspring and AOP made simple

Categories: CFUNITED Frameworks goog ColdFusion

If you've been anywhere near a blog or even another CF developer lately, it's quite likely you've at least heard of Coldspring, and you may even be aware that it is a 'framework'. In an informative session entitled 'Inversion of Control and Coldfusion: Using Coldspring', speaker Dave Ross succeeded in conveying a good basic understanding of what Coldspring does and why you should consider it as part of your application's architecture.

CFCs objects have the very useful ability to utilize other CFC objects within themselves. For instance, I may have a USER object that handles all aspects of a user, and an EmailServices object that handles aspects of email for my application. By creating an instance of my EmailServices object inside of my User object, my user object can, internally, utilize whatever methods EmailServices provides. In order to accomplish this from a coding perspective, however, we essentially have to do one of the things that OO says we shouldn't: hard code the relationship. This is the niche Coldspring fills.

Coldspring is a framework that is essentially an object factory. If you're using Coldspring, then whenever your app needs an object it asks Coldspring to instantiate it rather than the code instantiating it itself. In our previous example, rather than have our User object creating an instance of EmailService, Coldspring has already been informed via an XML file that whenever we ask for a User object it should ALSo include an instance of the EmailService object within it. Coldspring has just allowed us to keep our components decoupled, and this is a very good thing. Now, if my EmailService changes the way it is instantiated, I don't need to go into every other component that utilizes it and alter the instantiation code. Since Coldspring will be the one creating the EmailServices object, it will deal with those changes alone. By passing the control of object creation to our Coldspring factory we have implemented the buzzword mentioned in this session's title: Inversion of Control.

Dependency Injection is another buzz phrase associated with this topic, and essentially refers to the scenario where one object is depending on another (our User object depends on our EmailServices object), and the fact that Coldspring is 'injecting' an instance of the EmailServices object into our User object...Dependency Injection. There are two types of dependency injection, each one differing only in the way that the User object internally refers to the EmailServices object. The first type, called "Constructor-Argument injection", means that the EmailServices object will be passed in via the constructor of the User CFC, in the init method. The second type of injection is called "Setter Injection". With this one, rather than passing in the EmailServices object during instantiation, we're simply going to "set" it as a variable within one of the User object's methods. Here's why two methods even bother co-existing: circular dependency.

Circular dependency is another way of saying that object 1 uses an instance of object 2, and object 2 uses an instance of object 1. If you tried to use Constructor-Argument injection, CF would not allow you to have this circular dependency. By using Setter Injection, however, you can.

Lastly, Dave Ross elaborated on another facet of Coldspring called Aspect Oriented Programming, or AOP. In a nutshell, AOP is what allows you to take one method from a given component, let's say the LogIt method from the LOG.CFC, and cause that method to be executed at various times and places throughout your application. As an example, let's say that you wish to log every action executed against a user record, as well as when logging in or logging out of the application. Old-School style, you'd have to go to each of those methods and add a line to perform the logging. Ah, but with the beauty of Coldspring and AOP, you simply set up logging within the XML configuration file that already defines the relationship between CFCs, adding a few more definitions telling Coldspring to execute the logging before, during, or after the execution of other CFC's methods. Niiiice.

Setting up Coldspring is not or the faint of heart or those who are convenience enthusiasts, but if you will take the time to learn and implement it, you'll find yourself a better programmer for it.

Posted by dougboude at 1:29 PM | PRINT THIS POST! | Link | 11 comments

29 June 2006

CFUNITED - Top 10 Security Threats

Categories: CFUNITED goog ColdFusion

Adam Lehman works for the State Department, and knows very well the intricacies of hardening a ColdFusion application. In this enlightening and informative session. he walked us all through the top 10 most common security holes found in applications in general, and then expounded upon ways to address these holes for CF applications. Let's count them down together.

Number 10. Insecure Configuration Management. An app can be anally secure, but if you don't remember to actually secure the interface used to manage that security, it's all for nought. Some things to remember for this one are:

Do not deploy CF Admin or sample applications to your production environment.
Do not deploy RDS to a production environment. RDS is strictly for development, and should have no place in production whatsoever.

Number 9. Denial of Service Attacks. Bots and scripts designed to do nothing more than pound your application with a barrage of legitimate http requests, doing so at such a rate as to consume all available resources on the server. For this one, there really isn't a lot that can be done from an application architecture point of view. It can help if you limit your need to access databases and how much data is stored in session. Ultimately, however, your best bet lies in ensuring that all server patches and service paks are kept up to date, as well as networking hardware designed to sense and deal with DNS(denial of service) attacks.

Number 8. Insecure Storage. The need to access application-centric, sensitive data exists. Information such as datasource names, usernames, passwords, social security or credit card numbers are all types of information that need to be protected. The main tip provided to help address this area of compromise was to either encrypt or hash the information before storing it, if possible. If not, then tuck it away into a most obscure location, preferably not in the path of the webroot.

Number 7. Improper Error Handling. Error handling is in place to help the developer by showing him or her as much information as possible about the unplanned situation that just took place. When an application doesn't intercept and intelligently redirect errors, information that provides clues as to the database structure, application structure, and server can be revealed to would-be hackers. The answer is to implement an application-wide error handling mechanism that diverts detailed info to email or a log while showing the end user something more generic. This error handling code should preferably in a central location such as application.cfm/cfc. In addition, you can and perhaps should disable robust error handling and debugging in the CF Administrator.

Number 6. Injection Flaws. Here's one we don't often (if ever) hear about typically. This requires a bit more sophistication on the part of the hacker. What happens is that the hacker hijacks a variable, or finds some other way, to inject malicious script code into your application. Most times this code's target isn't your application at all, but some other underlying system such as the database or the server itself. Some things that can be done to make it more challenging for the hacker:

Setup sandboxes in order to limit access to such CF system tags as CF_Execute and CF_Registry.
Limit the database access of the user that drives your CF data sources to only what is needed.

Number 5. Buffer Overflow. Not typically a concern of web apps. For this one, like 9, make sure to keep patches up to date.

Number 4. Cross Site Scripting Flaws (aka, XSS). unlike injection flaws (number 6), XSS injects code that targets other users of the system. This is done in two manners: stored, and reflected. Stored XSS will do things such as write javascript functions to the template, where it will execute whenever that template is requested, performing some action on the client side. Reflected XSS utilizes such things as email to reflect the attack to users on other systems. Here are some things you may want to consider:

CF Admin has a "magic checkbox" to enable protection for all scopes. This will perform system regex checks against variable values flowing through CF to ensure no malicious code is present.
Within your application.cfc, the line "this.ScriptProtected" enables protection on an application level as well.

Number 3. Broken Authentication and Session Management. Well, not really broken, just weak. Here are some tips for strengthening these items:
Enforce more complex password rules, such as requiring special characters, etc.
Limit failed login attempts. When a user exceeds the count, lock them out for a period of time.

Store passwords as a hash rather than human text.
Perform the actual authentication process via https/ssl
Transmit session IDs via https/ssl
Do not put session IDs into the url
Use J2EE sessions

Number 2. Broken Access Control. Basically, the code you use to "lock down" certain areas of your application that require a person be authenticated for access. The recommendation here is that, rather than scatter "login checking" throughout the app, move it to a central place that runs on every request, such as application.cfc.

And Number 1: Unvalidated Input. DO validate submitted data! You can never have too much validation in place. You may use client side javascript to perform validation, but never rely on it as your primary validation. Consider the following:

Build in server side validation to ensure that submitted data is of the expected types
use cfqueryparam to ensure that values submitted to queries are of the correct types
put as much of your functionality into CFCs as possible, as the inherent use of CFARGUMENT will be yet another level of validation.
Learn about and USE the CF function IsValid(). Do it. Do it.

Posted by dougboude at 6:45 PM | PRINT THIS POST! | Link | 1 comment

CFUNITED - MVC Unraveled

Categories: CFUNITED goog ColdFusion Model-Glue

I spent the first hour of my morning listening (and gladly so) to Joe Reinhart preaching the need for us all to focus on just comprehending exactly what MVC is. Personally I felt like he started the presentation a few feet over most of the audience's head, using terms that were quite comfortable for him but new to many of us. Not his fault, and to his credit he did take the time to define many of the terms for us. Despite the elevated theme, in our short one hour together he accomplished his task in a two-fold manner: by increasing the audience's vocabulary, and by creating a sample app that used the MVC pattern.

That's right, MVC (Model View Controller) IS an application design pattern used across the board with any object oriented language. It also happens to popularly be known as the king of patterns, itself being an efficient symbiotic relationship between three other patterns of lesser scope and with more focused purpose. The Strategy pattern, Observer pattern, and the Composition pattern are what allow MVC to do what it does so well: keep our application segregated (loosely coupled) while allowing each portion of the app to remain highly specialized and autonomous (encapsulated).

The M in MVC is the Model. This is the portion of the application where nearly (if not all) of the business logic and database access will live. Business rules, queries, special validation...basically, if it has nothing to do with the user interface, then more than likely it will live in the Model. Physically the model will be a collection of CFCs that contain the functionality mentioned previously.

The View is that portion of your app responsible for displaying and gathering data. It knows nothing about the Model, the database, the backend system...it only knows that it will display the data given to it, and it will deliver the data it collects. Physically the View will consist of CFM templates containing primarily just layout information, such as forms, tables, and CSS.

lastly we have the Controller. It's job within the MVC design pattern is nothing more than passing data back and forth between the Model and the View; that's it.

The last 10 minutes (that's right, 10 minutes) of the presentation were spent building an entire basic blog application from scratch. Using the Model-Glue Unity framework and some Eclipse Ant scripts, he quickly was able to add in all of the CRUD (Create, Read, Update, Delete) functionality for blog entries and comments. How was this possible? By leveraging the many hours of hard work that have gone into producing and uniting three frameworks that have been all the buzz lately: Coldspring, Reactor, and Model-Glue. By strategically editing XML configuration files and using such shortcuts as "scaffolding", it is possible to auto-generate what would otherwise take a person days to code by hand.

Witnessing the creation of an entire application in just a few minutes is both exciting and disconcerting. On the one hand, Model-Glue Unity provides the developer with shortcuts that are nothing short of amazing, allowing productivity levels that I believe are unachievable otherwise. On the other hand, I could very well empathisize with the framework opposition camp, seeing how it is they could say that the usage of advanced frameworks such as Model-Glue will lead to the de-evolution of the CF community, removing many of the "needs" that often motivate developers to learn and grow. My own opinion, however, is that although frameworks such as this will allow us developers to become more productive, the convenience of it all will never quench the insatiable curiosity that has driven us up to this point, and we will always be "peeking under the hood" regardless of how much automation we adopt.

Posted by dougboude at 5:58 PM | PRINT THIS POST! | Link | 11 comments

CFUNITED - The Frameworks Debate Continues

Categories: CFUNITED Frameworks goog ColdFusion Model-Glue

Most of you may be aware of the debate over frameworks that has been raging off and on since at least CFObjective back in March of this year. In the one corner, representing all that is opposed to the preaching of frameworks to the masses is Simon Horwith. In the other corner, representing framework evangelists and followers from all over the globe is Hal Helms.

I first became aware of this schism at CFObjective when I attended a seminar by Simon Horwith entitled 'Object Think'. It would more appropriately have been entitled 'Friends don't let Friends use Frameworks', as he openly bashed everything else that conference was about and made himself the public prosecutor of the majority of the CF expert community's opinion on frameworks. Last night was no different, as I sat in on a session here at CFUNITED entitled 'Celebrity Death Match'.

It was an open and formal debate between Simon Horwith and Hal Helms, who himself participated remotely via Breeze. The conference room was filled to the hilt as newbie and seasoned alike gathered to be judge and jury for the topic at hand. Let me summarize for you the two opposing arguments, and then tell you what the verdict was.

The Framework Opposition says that frameworks are a crutch that essentially stifle and hinder a developer's professional and technical growth. This camp says that if a developer begins his or her career using an open-source comunity developed framework, they will remain handicapped and incapable of ever being able to truly build an application from the ground up on their own, resulting in a pool of 'talentless talent'.

The Framework Supporters maintain that using a framework, though it is indeed a greater initial investment of time and resources, is a ONE time cost that is greatly offset by the long term benefits afforded at every level. The use of frameworks creates a community-accepted standard that takes an already robust common vocabulary to an exponential level, not only enhancing our ability to transfer and share knowledge on a large scale, but also to easily exchange entire applications and code without the need for significant investments of time to utilize. They also counter that in NO way does the usage of frameworks stifle a developer's technical growth, citing the fact that none of their own growth was stunted when they started using Model-Glue and the like.

Near the end of this mock trial, Simon made a point that set me free of the conflict of the debate. He related an account of a project he had worked on in England some time in the past in which he had 100 developers under him. He shared how it was that this large team had tried using Mach II, tried using Fusebox, and in both instances found those frameworks wanting. Then he showed them his own 'methodology', which they readily adopted and used to successfully complete the project. Simon's point was that he and his team had accomplished a large task, and didn't need to use a framework in the process. But between Simon's words lay the whole truth of this matter, the truth that finally freed me from the points and counterpoints that were tugging my intellect in both directions. This truth, folks, is this: Any application that actually works uses a framework. Simon likes to call his framework his 'methodology', resisting the urge to give it any kind of formal name or documentation, and thus disguising it obscurity and vagueness. Nevertheless, it is indeed a framework. So folks, this whole debate is bogus, the opposition's stance is vapor, and in reality is a one sided debate with the answer to the question of the validity of frameworks already woven into the very fabric of both sides of the argument. The answer, my fellow CF coders, to the question of whether or not using frameworks is a good thing, is an unequivocable "YES". You need frameworks, and whether you roll your own or adopt a community standard, there is no way to avoid them...logic will not permit it.

After being set free by this epiphany, I then had to wonder at what it is that truly motivated Simon Horwith to take such a public stance. What moved him to place himself in the limelight and accept the label of 'framework-hater'? Is he plain and simply a rebel, one who will swim against the current on principle alone despite the direction it takes him? Or, more than likely, is it that he is simply a self-appointed sentinal of the free thinking world, fearing the loss of innovation and open-mindedness and the onset of apathy and weakness in the CF community's skill set? Finding nobody else who could see what he saw, did he then, in our defense, take up the cause to protect what it is he cherishes and believed to be utterly at stake, giving his all to "keep balance in the Force"? We are the jury here....

Back in the conference room the smell of popcorn and cotton candy filled the air as the debate was brought to an end. The judges called for final comments and then a show of hands from the "jury" as to who had won this debate. Almost unanimously, the jury sided with Hal.

Bottom line folks: ignore this debate and give the hard work of your more advanced and experienced peers the attention it is most worthy of. Must you choose a religion (framework)? No. Choose them all, choose one, choose none and roll your own; it doesn't matter. It's all good, it's all good. what IS important is that you keep striving to learn, always push yourself to new levels of understanding, and then you, like ALL those in both corners who are so zealous for their CF causes here, are right.

Posted by dougboude at 12:23 PM | PRINT THIS POST! | Link | 8 comments

28 June 2006

CFUNITED - Recursive Functions presentation

Categories: CFUNITED goog ColdFusion

Andrew Schwabe gave an outstanding presentation of a subject that can be somewhat difficult to wrap one's mind around: recursive functions.

Having already traversed the learning curve involved with this subject, I went hoping to learn something new and was not at all disappointed. Andrew approached the subject in a very simple and understandable manner, taking the observer from zero to 60 in one smooth transition. I was quite impressed with Andrew's almost exclusive use of Custom Tags, which nicely complemented my own preference of using CFSCRIPT.

Rather than regurgitate all the details of recursiveness in this post, it's probably simpler to refer the reader to both Andrew's presentation code and a recent blog post of my own regarding the subject matter.

Posted by dougboude at 5:35 PM | PRINT THIS POST! | Link | 13 comments

My Score: 9,001

Read (and recommend)

Reading

ON THE NEGATIVE (BUT POSITIVE) SIDE...

LOSING MY VIRGINITIES

WHAT NOW?

CONCLUSION

<<	September, 2010					>>
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