Brian Kotek: Inversion of Control - Development

Thoughts on Flex and HTML5

Tue, 22 Nov 2011 08:39:00 -0700

It has now been a little over a week since Adobe revealed its plans for the mobile Flash player and the Flex SDK. Now that the dust has started to settle and some additional information has been made available, I wanted to give my candid impression of what these announcements mean. I'll begin by stating the obvious: Adobe did a very poor job of coordinating and delivering these announcements. Anything I say at this point will simply be beating a dead horse. This was a PR disaster and one can only hope they learn something (ideally, many somethings) from sifting through the wreckage. I won't dwell any further on this since we have no control over what happened and I'm interested in looking at what these announcements mean going forward. I suspect that the news that Adobe was stopping work on the mobile Flash player didn't actually surprise very many people. Further, I doubt many people actually care much. Yes, it's nice to be able to view Flash content on my Android tablet. And yes, its easy to forget that the existing 11.1 player will continue to work for a long time and allow people to keep viewing the vast majority of Flash content. But no one was building browser-based mobile Flash sites. Why? Because you still had to create a non-Flash version of it if you wanted to target all mobile devices. Once the sting of all the "Steve Jobs Won" gloating wears off, I believe most people will see the wisdom of this decision. Some people appear to have a problem with this choice, but no one I know really cared at all about this part of Adobe's recent announcements. So now we move on to the other big news: Adobe announcing that the Flex SDK would become an Apache project and would go forward under non-Adobe governance. This took a lot of people by surprise, to put it mildly. First off, let me say that I don't have an issue with the idea of Flex going fully open-source. Yes, Flex was already "open-source", but we all know it really wasn't. You could view the code, but Adobe still exerted complete control over what changes were made. Anyone who ever tried to submit a patch or improvement can attest to this. Those restrictions are now gone. I firmly believe that if this announcement had been made at MAX, rather than in the middle of this PR breakdown, the cheering from the audience would have brought the roof down. I know a number of the people on the Spoon project, many of whom will probably be part of the group which will govern the ongoing work on the Flex SDK. They're all very bright people and I have little doubt that the SDK will actually see some nice benefits from this move. So from a purely technical standpoint, I think this can and probably will be a good thing. However, regardless of what you think about the SDK move, another portion of Adobe's announcement overshadowed even this news. In a post that will probably live in infamy, some of the Flex management stated "In the long-term, we believe HTML5 will be the best technology for enterprise application development." How Adobe failed to predict the resulting uproar I have no idea. But apparently they didn't. As a result, we saw an explosion of questions and concerns that essentially boiled down to: Is Adobe saying Flex is dead? I'll admit I wondered this myself. Given this statement, what was I supposed to tell the clients to whom I've evangalized Flex? Is my investment in Flex now ashes? I was angry and confused. Then I tried to detach myself from my emotional reaction and consider the situation objectively. I want to share a few of my thoughts and conclusions about this. First, one has to consider the harsh reality that Adobe never really figured out how to make any money on Flex. Their only real revenue came from Flash Builder, and it seems highly unlikely to me that sales of FB offset the money they've spent on Flex. And even that revenue is further reduced by the presence of competing tools like FlashDevelop and IntelliJ IDEA. Considered in this light, Adobe's decision to reduce the amount of resources it dedicates to Flex does make some sense, even if we don't necessarily like it. Offloading part of that cost onto the community is one way they can try to make those numbers even out. Next, I'm not sure about everyone else, but I for one always believed that eventually we'd be able to build Flex-like apps in HTML. Some of this can be done already, but it is disjointed, using a mishmash of libraries, and painful. Building RIAs in JavaScript is agonizing compared to Flex and AS3. But that's slowly changing as the tools get better and the libraries become more refined and standardized. My guess is that in two or three years we'll start seeing real parity with Flex on both features and tooling. I knew this before Adobe's announcement, so does it really change much? Or did the announcement, as poorly as it was delivered, serve as a stark reminder that Flex is in some ways a bridge between now and this eventual HTML-based future? I think this may be where some of the pain is coming from. No one wants to be told that the platform they're heavily invested in is probably going to be supplanted in the coming years. But can anyone really look at the current situation and draw another conclusion? Adobe seems to have two options here: keep pouring resources into Flex and delay the switchover a bit, or start changing direction and begin the task of improving HTML tooling from a RIA perspective. It's clear which way they've chosen to go. So where does that leave us? Like many folks, I poked around the web last week just to get an idea of the current state of HTML RIA development. It wasn't pretty. I found dozens of libraries, frameworks, UI components, tools, and workarounds to mimic proper OO features in JavaScript. To put it bluntly, it's total chaos. We're a long way from being able to drop Flex and start building enterprise RIAs in HTML. Which is fine with me. The projects I'm currently involved in are multi-year efforts built with Flex, and these aren't going away. I'll be building and maintaining apps with Flex for quite a while. On the other hand, the writing seems to be on the wall. This isn't going to last forever. Developers who have been around the block a few times know it is always a bad idea to put all of your eggs in one basket. So I'll be keeping my eye on the HTML RIA space, trying things out as that platform coalesces. GWT looks interesting, especially paired with Groovy and SmartGWT. So does brunch.io. Trying out new technologies is one of the things I love about programming, and that's certainly not about to stop. Will this change on the horizon amount to a career and knowledge "reset"? Is everything we've worked so hard to learn going to be thrown out the window? From my point of view, absolutely not. Looking around at the HTML/JS world, I see a lot of people trying to solve problems that we've already gone through. Solid OO design? Rich client models? Real-time messaging? Persistent client state? Separation of UI from client-side logic? Large-scale event-driven applications? Architecting and managing huge RIA codebases? Sound familiar? They should, because they're probably problems you've already dealt with a number of times. The programming language might change, and the UI component APIs may shift, but these fundamental problems aren't going anywhere. And I think experienced Flex developers are going to be very well suited to helping businesses and clients solve those problems, both now and in the future. Even if the platform eventually shifts to HTML5. As they say, the only constant is change. And honestly, life would be pretty boring any other way.

Spark Skins, Components, and Presentation Models

Thu, 14 Jul 2011 12:37:00 -0700

In the Flex 3.x world, I adopted the Presentation Model pattern and applied it just about everywhere. Separating the non-view logic made perfect sense, far better than the code-behind approach, and cleaned up the view components wonderfully. Then Spark came along in Flex 4, and things have changed. The framework now has built-in support for separating the "view" (skin) from the "controller" (host component). As I've been using skinning more and more, I've come to wonder if or how the presentation model approach applies in the Spark skin world. To try and answer that question, I created a fairly simple but non-trivial test application that creates the same views and behavior in three ways. I've heard each of these three ways mentioned at various times by various people, so I used them as the most commonly proposed options:

Supply a presentation model to both the skin and the host component, and let it act as a bridge between the two. In other words, the skin knows nothing about the host component, and the host component knows nothing about the skin. Create the PM as a self-contained set of methods and properties that can be applied to any relevant skin or host component. In essence, if the skin is the "view" and the component is the "controller", the PM is the "model" in this mini-MVC configuration.
Supply a presentation model to only the host component, and have the host component push state into the skin. In this case, the skin knows nothing about the host component, but the host component it tightly coupled to the skin.
Drop the presentation model approach completely. All behavior and properties are held in the host component, and the skin binds to host properties and invokes methods on the host. In this setup, the host knows nothing about the skin, but the skin is tightly coupled to the host.

After building all of these, there are pros and cons to each approach. And some definitely seem to have more pros or more cons than others. The one thing I tend to focus on is what kind of change and what kind of reuse each approach allows for. If you view the running test application, you'll see I've noted some thoughts on each in the sidebar. View source is also enabled, so if you want to look through the code or download it, feel free. I'm very interested to hear other people's thoughts on this as well. So if you have an opinion on this, or any issues with how I've built any of these versions, by all means please comment below!

Swiz Console 1.2, and an introduction to AOP in ActionScript

Wed, 06 Jul 2011 10:35:00 -0700

First just a quick note that I have updated the Swiz Console to version 1.2, which maintains parity with Swiz version 1.2. This update adds a tab to show views that have been processed with ViewAdded and ViewRemoved. As always, you can grab the swc or the source at my GitHub repository. In other news, Chris Scott put up a blog entry on the Swiz site with an overview of aspect-oriented programming in AS3. One might speculate that this is a lead-in to some very cool stuff coming in the Swiz framework, if one were so inclined...;-)

Fix for Using Subclipse Keyboard Shortcuts

Wed, 08 Jun 2011 12:38:00 -0700

Just a note for anyone who uses Subclipse within Eclipse to work with a Subversion repository. In the past, you could easily assign keyboard shortcuts within Eclipse for SVN update, commit, etc. In the newer builds of Eclipse I couldn't get this to work. After searching Google, I found the answer in this Subclipse ticket. In order to get the shortcuts to work, you must go to Window > Customize Perspective, then under the Command Groups Availability tab, check the SVN option. It may require a restart of Eclipse, but the Subclipse keyboard shortcuts will now work.

Swiz 1.0 Is Ready, and Updated Module and Chaining Demos

Wed, 15 Dec 2010 09:37:00 -0700

Today marks a big milestone in development of the Swiz framework for Flex and ActionScript: the team is proud to announce that version 1.0 has been released. This has been coming for a while, but we wanted to be sure we weren't rushing things and that the framework was really solid and ready for the 1.0 designation. Download the final Swiz 1.0 distribution, which contains the swc, API docs, and source code. If you like, check out the release notes to see what's new since RC2. Finally, the wiki documentation has been updated to reflect the new changes. To go along with the final 1.0 release, I've pushed some updated demo apps to the swiz-examples Github repository to show more of the chaining API and the inter-module communication options that Swiz brings to the table. If you'd rather see running code, I've got the Chaining Demo and Module Communication Demo applications live on my site. The view source option is enabled, so feel free to browse the code to see what's going on. That's all for now. I hope folks find the examples helpful!

CFUnited Clean Code and Swiz Presentations Now Online

Wed, 04 Aug 2010 15:33:00 -0700

Just a quick note that, as promised, my presentations from CFUnited are now online! Clean Code The Swiz Framework for Flex and ActionScript Thanks to all who attended!

An Awesome Alternative to a Traditional Mouse

Thu, 25 Feb 2010 09:30:00 -0700

Like most of you, I sit in front of a computer for a large part of my day. Over time, sitting and working on the computer has caused me varying physical issues, like back, wrist, and elbow pain. To alleviate this, I bought a desk with an adjustable height, an ergonomic keyboard, and an Aeron chair. These have helped greatly. But the one issue that kept coming back was wrist pain. I tried several types of mice, with varying shapes, but none of them dealt completely with the issue. For me, a big part of the discomfort in my hand and elbow came from constantly reaching over for the mouse, as well as gripping it. It might sound silly to some, but when you do this thousands of times, it adds up! Then, about six months ago, I found a blurb about the RollerMouse Free on some tech site. Having used it daily for a while, I can say that this mouse is an excellent option to a traditional mouse. The RollerMouse sits directly under your keyboard, just past the space bar. To control the cursor, you roll a bar up, down, and side to side. It sounds bizarre, but it works very nicely and was easy to get used to. The bar moves very smoothly, and is very accurate. You can easily move it with your thumbs, and you barely have to move your hands off the keyboard, or you can use your fingertips. Either way, it's far better than reaching over for a normal mouse. I still keep a regular mouse as well, but I use it pretty infrequently (except for gaming!). This odd new RollerMouse is the workhorse now. I just wanted to mention this device in case anyone else has similar problems and was frustrated trying to solve them. I was uncertain about how this thing would work out, but it really does work well. There's a video at the product web site which shows how it works in more detail, if you're interested to see it in action.

My CFinNC Presentations at SlideSix

Thu, 22 Oct 2009 12:02:00 -0700

I've uploaded my CFinNC presentations to SlideSix for anyone who's interested: Object-Oriented Design Principles Introduction to Swiz Overall, CFinNC was great. I actually had to work for a large chunk of the weekend so aside from presenting and mingling with folks later in the evening, I didn't get to attend many other sessions. That said, everything looked top-notch while I was there. The conference unfolded very smoothly and all of the attendees seemed very engaged. Hats off to Dan Wilson and the entire volunteer team for pulling this off! This conference definitely held its own against the other CF conferences I've attended. It was very difficult to tell that it was completely free. Hopefully we can do it again next year!

Flex DataGridColumn Complex Properties Bug and Workaround

Fri, 09 Oct 2009 12:57:00 -0700

One Flex limitation I've had to work around for a long time is the need for having a complex property name as the dataField for a DataGridColumn, like this: I had written a nice, generic, custom labelFunction as well as a custom NestedPropertyDataGridColumn to handle this, and it all seemed to work well. I just discovered that the Flex team had addressed this in the Flex 3.4 SDK update, though I don't think you'd ever know it since I couldn't find any actual note that this was added. The only reason I discovered this was actually looking at the source code, and then finding this ticket in the Flex issue tracker. So yay, we can use complex properties in our DataGridColumns now! Except...it's broken. Ugh. Really, guys on the Flex team? This was added and no one ever bothered to click on the column to sort it? Hmph. Anyway, as one workaround, you can use a custom DataGridColumn combined with a custom Sort to get proper sorting in most cases:

js|
package com.briankotek.util.datagrid
{

import mx.collections.ListCollectionView;
import mx.controls.DataGrid;
import mx.controls.dataGridClasses.DataGridColumn;
import mx.core.mx_internal;
use namespace mx_internal;

/**
 * A custom DataGridColumn that supports sorting a column that has a nested child property path for the dataField value.
 */
public class DataGridColumnNested extends DataGridColumn
{
	public function DataGridColumnNested( columnName : String = null )
	{
		super( columnName );
	}

	/**
	 * Override itemToLabel to force a ComparableSort custom sort class onto the parent DataGrid dataProvider.
	 * This works around a bug in sorting columns with complex property names in the dataField value.
	 * @param data
	 * @return
	 */
	override public function itemToLabel( data : Object ) : String
	{
		var parent : DataGrid;
		if( owner && owner is DataGrid )
		{
			parent = owner as DataGrid;

			if( hasComplexFieldName && parent && parent.sortableColumns && parent.dataProvider is ListCollectionView &&
				(
					!( ListCollectionView( parent.dataProvider ).sort ) ||
					!( ListCollectionView( parent.dataProvider ).sort is ComparableSort )
				)
			  )
			{
				ListCollectionView( parent.dataProvider ).sort = new ComparableSort();
			}
		}
		return super.itemToLabel( data );
	}

}
}

js|
package com.briankotek.util.datagrid
{
import mx.collections.Sort;
import mx.collections.SortField;

/**
 * Custom Sort class that forces the correct compareFunction for a given field to be used.
 */
public class ComparableSort extends Sort
{
	public function ComparableSort()
	{
		super();
	}

	override public function findItem( items:Array, values:Object, mode:String, returnInsertionIndex:Boolean = false, compareFunction:Function = null ):int
	{
		if( !compareFunction && fields && fields.length && fields[0] is SortField && SortField( fields[0] ).compareFunction )
		{
			compareFunction = SortField( fields[0] ).compareFunction;
		}
		return super.findItem( items, values, mode, returnInsertionIndex, compareFunction );
	}
}
}

This forces the custom Sort class onto the grid's dataProvider, and then forces the correct compareFunction from the SortField to be used by the Sort's findItem() method. Hopefully we'll get a fix for this soon, but in the meantime, maybe this workaround will help out some other folks.

On the CFPanel Podcast with Mark Mandel and Barney Boisvert

Fri, 04 Sep 2009 12:11:00 -0700

I'm happy to say I'll be participating in the CFPanel Podcast on September 8 at 8 PM EST. We'll be discussing ColdFusion and Java integration. I hope to add some helpful substance to the conversation, but I'm really looking forward to hearing what Mark (who created JavaLoader) and Barney (who created CFGroovy) have to say. Listen in if you can, or check out the Connect recording afterwards. Thanks!

ColdFusion and OOP - Match Made in Heaven, or Long Road to Hell?

Tue, 14 Jul 2009 06:29:00 -0700

Hal Helms, Ben Nadel and I recorded a conversation over the weekend on the subject of OO in CF. I'm supporting the position that OO is still a good thing in CF, Hal disagrees, and Ben is undecided. As you might expect, Hal is left a trembling husk as the weight of my arguments unmercifully crushes him. You know those scenes in superhero movies where someone gets punched so hard they end up in a crater in the ground? It's like that. Only worse. In all seriousness though, it was a very fun talk and I think there are some solid points made from all involved, but I'll let you, gentle reader, be the judge. You can download the recording here. In the interest of keeping any discussion on this topic from fragmenting, we've decided to disable comments on our respective blog entries and instead created a Google Group to act as a central sounding board. Hopefully this isn't too inconvenient, I realize it's something of a departure from the norm, but let's see how that works. I'm not sure yet whether this will turn into any kind of regular discussion, but I suppose it could. We'll just have to see what folks think! Thanks.

HTML 5 Isn't Going to Kill Flash

Thu, 09 Jul 2009 07:17:00 -0700

Lately I've seen a number of blog posts and news stories touting HTML 5 as some sort of Flash Killer in the RIA space. Am I the only one shaking my head at this? First off, let me say I'm thrilled that HTML 5 is in the works, and that the markup language is being improved. I could say it's about time, but I won't. (I guess I just did though!) That said, the people claiming that HTML 5 is going to kill Flash seem to have a pretty poor memory. According to the editor of HTML 5, it's not going to become a proposed recommendation until 2022. That's over a decade, folks. That's a long, looooong time. Think back a decade. Remember 1999? Most people were using IE 4. There was no AJAX, and there were no RIAs. There were no social networks. There was no Twitter, and no iPhone. Now project that kind of change forward 10 years, only double the rate of change. So much is going to happen before HTML 5 is widely adopted that it's not even funny. Heck, something might even kill Flash. But it's not going to be HTML 5. And even if the new spec offers some kind of parity with Flash, Flex, and Silverlight, it's not like the existing RIA platforms are going to stand still. There will be huge advances over the next decade. So being, among other things, a Flex developer, I'm probably biased here. But I just don't see what all the fuss is about. An updated spec is great, and I sure it will find many uses and offer a lot of interesting features. But to trot this out as yet another Flash Killer seems unrealistic at best, and reeks of ulterior motives at worst. What do you think? Am I right? Or am I just blinded by my association with Flex?

OO Can't Ruin Businesses, but People Can

Tue, 26 May 2009 10:32:00 -0700

Blogging newcomer Marc Funaro made a provocative first post over the weekend with his entry How OO Almost Destroyed My Business. It has gotten a lot of comments, some supporting him, and some taking issue with his conclusions. I started to comment but decided it would be better to generate a secondary discussion rather than add onto the already long thread. Marc says he picked up ColdFusion as a non-programmer, and had good success with it until fairly recently. With the movement toward object-oriented development that is happening in the ColdFusion world, he ran into trouble. He read some books, some blogs, and took a class on Java development. And he ended up overwhelming himself with unnecessary complexity in terms of frameworks, design patterns, and OO architecture. He sums up the result of doing this pretty nicely:

"The bottom line is, when you NEED to use some OO concept, YOU'LL KNOW. *That's* the time to start writing OO-style code, and only then... not everywhere else."

Which is pretty good advice. It's something that any knowledgeable proponent of OO will tell you. I'm sorry that it took him a good amount of time and frustration to reach that conclusion, but I'm glad he finally did. Where he goes wrong, though, starts right in the title of his entry. OO can't ruin anything, but people making bad decisions absolutely can. And what Marc did was make some bad decisions, because he was new to OO, confused, and, as he says, "downloading one framework after another, piling them all into an application". This is like reading a book on construction, and then going out and trying to build the Taj Mahal when all that was needed was a garage. Bad decisions don't mean a person is stupid or foolish. Smart people make bad decisions all the time (I'm not conceited enough to call myself a smart person, but I definitely have made some bad decisions). Usually, it's simply a lack of knowledge or experience, or a failure to understand the implications of the choices you're making. But even that is OK, because when someone makes a bad decision, it can still have a positive outcome if it results in learning something. OO does not equate to using a framework, and it does not require the application of every design pattern under the sun. It's simply a way to organize code, manage complexity, and accommodate change. Sometimes, that is best served by using a framework like ColdSpring or Spring. Sometimes, design patterns can offer solutions to encapsulate variations in a system and cope with change. One of the key things anyone using OO must understand is that there are pros and cons to every decision, and multiple solutions to a given problem. The only way to learn how to assess these trade offs is through experience. The reality is that a lot of ColdFusion applications don't require a massive OO system to power them. Many of the small- or medium-sized applications don't need an n-tier architecture loaded with abstractions and design patterns. But that doesn't mean that some of the good ideas of OO, like encapsulation, can't be used with big benefits. One doesn't need to turn every query into an array of objects. Just creating well-defined interfaces to expose behavior to the rest of an application will get you a long way. Once something is encapsulated, it's much easier to change it later if you need to. It might be just a few CFCs to wrap up the bulk of the logic and hide the implementation. That might be all that will ever be needed. But if (and, more likely, when) things get more complex and it comes time to start adopting a broader set of OO principles, you'll be in a much better position to do so. However, there is another reality that can't be denied: in the debate between procedural and OO development, OO has won. It won many years ago. ColdFusion is one of the few languages left that supports procedural development to a large degree. If you want to keep being a software developer, or ever want to move to a language like ActionScript, C#, Java, Groovy, or Ruby, you're going to have to know OO. That's just how it is. And as Marc points out, even within the CF world, OO is taking over, and the number of jobs available to people without OO experience are going to keep getting smaller and smaller. Some folks may not like this and may attempt to rebel against the trend, but you can't stop the tide. OO is not going away, in fact, it's only going to get ever more ubiquitous. So it's probably in your best interest to learn about it. One doesn't have to use it on every project, nor does one have to use it to create a complex, over-engineered mess. But experience is the best teacher, both in terms of learning OO and increasing your demand in the marketplace. So, with respect to Marc, don't do what he did. Don't try to swallow the entire OO buffet in one bite. If you try, you'll fail. You'll get frustrated. And in that red haze, you'll probably miss the simple benefits of OO. Instead, learn what you can and take time to digest the information. Experiment with it, but don't get carried away. Apply what makes sense to you where you can, in small bits. Remember that the goal is to learn, but it is also to help you do what works for you and build applications that satisfy customers. I suppose the bottom line is: Don't be afraid of OO. Be afraid of anyone who says that OO is the only way to build an application, and be just as afraid of anyone who blasts OO because they got carried away with it and got burned.

SilverFlash Beta Released: A Joint RIA Platform from Adobe and Microsoft?!

Wed, 01 Apr 2009 06:41:00 -0700

Microsoft and Adobe just announced the public availability of a joint RIA platform called SilverFlash. While it is only in early beta, and the future plans are somewhat vague, this looks like it could be something quite interesting for Flash and Flex developers for several reasons. First, it actually goes far beyond Microsoft's current Silverlight platform, in that it actually merges the Flash platform with the Windows Presentation Foundation (WPF). In some ways this seems similar to what Adobe AIR provides, except that the WPF extends much more deeply into the Windows operating system. That means a lot more power when doing desktop integration. But obviously the real draw here is that we'll have a unified RIA platform that is backed by all the major players in the industry (even Sun is on board) and that runs on any operating system. Just imagine: the power and ubiquity of Flash combined with the stunning calendar widgets of Sliverlight, all wrapped in a Java applet. You can download the beta at the SilverFlash Launch website. This is going to do for RIAs what the Apple Newton did for handheld computing!

Is the ColdFusion Community's Generosity Encouraging Laziness?

Fri, 27 Mar 2009 15:10:00 -0700

I've been using ColdFusion for a long time. When I started back in late 1997, I was a very novice programmer. There wasn't much in the way of mailing lists, online forums, or books. There was no Google, and there were no blogs. As a result, I developed what I'd consider a pretty self-reliant nature on the subject of programming. I had to read the documentation, experiment, and try things out. And doing this, I was able to solve my problems. I am a member of a number of public discussion forums and mailing lists, and have been for many years. I moderate several forums and lists. Over the years, I've tried to help others by answering questions or pointing them in the right direction to solve their problems. I'd like to hope that I've helped save some people some of the pain and time that I had to go through when I was learning ColdFusion. Lately I've been seeing a disturbing trend: a rapidly increasing number of what I will call "lazy questioners". Sure, some of these folks have always been around. But in the last six to twelve months it seems like the number of these people has been making a rapid upturn. On the one hand, this might be good news: it seems to indicate that more new people are coming into the community. I think that's great. However, what I don't think is great is their approach to asking questions. If you are also a member of one or more forums or mailing lists, have you also noticed the increasing number of questions like these?

How do I invoke a trigger from ColdFusion?
Why doesn't this work: <cfif IsDefined("#url.id#")>...
Why does my if block always run: <cfparam name="url.id" default="0" /> <cfif IsDefined('url.id')>...
How do I zip something in ColdFusion?
What is wrong with my query? [paste SQL]
This doesn't work please help me. [paste 300 lines of code]
Why doesn't this work? #XMLParse( [string with invalid xml characters in it] )#
Will this work? [paste code]

The list really goes on and on, these are just a few of the ones I recall seeing recently. If you're asking yourself "what's wrong with those questions?", I'll tell you: either they're horribly presented questions or they could be solved in 30 seconds just by doing a Google search or actually looking at the documentation. So what's the problem? The next response is probably "just ignore the question if you don't have anything nice to say." That's a valid response. And it would work, provided that everyone else also followed it. But they don't. When questions like these come up (daily at this point), at least one good-natured person decides to try and help. They politely provide a useful answer. Which is admirable. I often do this myself. But after thinking about the overall situation, I've come to the conclusion that it's actually a harmful choice. Here are some of the reasons why: First, all this does is encourage the questioner's laziness. In fact, it encourages laziness for anyone asking a question. Why would someone bother to find an answer on their own when they see they can just ask someone else and know they'll get an answer? It also means the person probably hasn't really learned much. They certainly haven't learned how to find the solution to a similar problem when (not if) they encounter one. The old adage "Give a man a fish, feed him for a day. Teach a man to fish, feed him for a lifetime." has never been more applicable. Answering a lazy question almost guarantees more lazy questions in the future. The questioner is banking on the generosity of others, and allowing them to shift the time and effort onto a bunch of other people. And, unfortunately, it works. Which leads directly into the next negative result, which is an overall decrease in the usefulness of the list or forum. Lazy questions decrease the signal to noise ratio of a resource. They take time and attention away from valid and well presented questions. And it's not just the initial answer. Often, when a lazy question is answered, it triggers a long exchange where the questioner says "that still doesn't work" or "what about this variation". In response, the kind folks answering keep feeding into it, many times offering additional information that the questioner would have discovered themselves if they had put even minimal effort into solving their problem through Google or the documentation. In essence, I think the ColdFusion community is too forgiving of lazy questions. I might get flak for saying this, but it's true: we're too nice when it comes to this issue. Now to be clear, I'm not saying we should be mean, or that we should stop answering questions. We should absolutely keep answering questions. I certainly will keep trying to help people. But anyone asking a question should understand that there is a certain minimum level of effort that should be met before you ask. To me, the minimum level of effort is:

Have you actually tried to run the code? What was the result?
If there is an error, be able to provide the exact error to the best of your ability
Have you read the documentation?
Have you searched Google?
Have you searched the past threads/messages?
If the problem is SQL-related, have you run the query directly against the database, outside of CF?
If you plan to paste code, have you eliminated all extraneous code and limited the code to only what is involved in the problem?
Have you attempted minimal debugging with cfdump, cfabort, or cftrace?

This is not a lot to ask. In fact, this should be done out of common sense and common courtesy. If someone chooses not to meet this minimum level of effort, they should be met with a terse, blunt response, and NOT the answer to their question. There is a much more general and lengthy resource on this subject at the Smart Questions FAQ. Here are a few situations where I say the questioner's laziness should be called out:

The answer could be found by simply reading the documentation on the tag or function, and it is obvious that they have not
The answer could be found with a 30 second Google search
The questioner is asking an advanced question on a complex subject when it is clear they have limited understanding of the subject or what they're even asking about, and they're expecting a free class on the subject (i.e. "I don't know much SQL, but how do I write this complicated query")
The questioner is asking if something will work when they haven't even tried to run it
The questioner is asking others to write their code for them
The questioner is pasting huge amounts of code and expecting others to sift through it

In many other communities, lazy questions are met with harsh responses that range from "RTFM" to "JFGI" to derisive abuse. I'm not asking the community to go down that road. I love the fact that for the most part, the CF community is a very open and encouraging place. I just think that a small but growning number of people are taking advantage of that generous spirit. It's time to impose some minimal expectations on those who would ask for our time and assistance. I'm expecting this to trigger some interesting feedback (hopefully nothing too rough, but if you disagree and can point out some flaw with my logic here, by all means go for it). What do folks think about this issue, and what is the best way to deal with it?