I’m here at Taste for Bar Camp Orlando which is going great so far. There are two presentation rooms with the bar along the front of the larger room. There’s been relatively few hiccups so far, and a lot of passionate presentations up to this point. So far I’ve lucky enough to attend ones on designing for the Iphone, OpenMoko, MixelPixel (which went into Facebook apps written in Flex), Learning to Love JavaScript, Passion and Inspiration in Innovation (which was all about embracing your passions) and I’m currently sitting in on Groovy with Swing. Each presentation has 20 minutes, the final 5 of which is supposed to be for questioning. I’m sure to come out of this with passion peaking and ready to work on some interesting projects.

Although I came in with the intention of doing a PureMVC talk, I thought it seemed a little too out there for someone new to Flex. Instead I ended up doing a Simple Amazon Webservices Application in 15 Minutes with Flex talk based on some sample code. Turned out OK, although I had to copy/paste from the finished example a few times to get it done in time.

In the recent spirit of posting top 10 lists, I thought I’d throw in my 10 ColdFusion related pet peeves. These aren’t peeves about the language itself though, but peeves in how people code. We all know there is no “right” way to make an application, so all of these are up for debate, but that doesn’t mean they’ll stop annoying me.

1. Cased tags. Why some people insist on putting CF tags in all caps I’m not sure I understand. It could be to differentiate them from regular HTML, but if that’s become a problem then you’re probably mixing logic or unfamilar with HTML. To me it just looks like the tags are shouting.
2. Cased functions. Not all case is bad. I prefer using the official case found in the CF docs for ColdFusion functions. Having these in all lowercase makes them harder to read, and all uppercase gives the same problem as the first one.
3. Uppercase scopes. Scopes shouldn’t be yelling either! variables, application, url — looks better to me than VARIABLES, APPLICATION, URL.
4. Not returning this in CFCs. This isn’t a clear cut rule of course, but for most day to day applications working with object makes things a lot easier. In my first experiences with CFCs this wasn’t the most obvious way to do things, so I can see why some people might have not have learned a other ways, but this will help.
5. Using the this scope. This one has almost been cleared out of common practice, but using the this scope in CFCs for variables isn’t the best idea. When you store a variable in the this scope it will be available from outside the object. This breaks encapsulation, and also makes for ugly code.
6. Forgetting output=”false”. This could be a CF pet peeve as well, but assuming CF doesn’t change we’ll need to continue adding output=”false” to all methods we don’t want output to the browser. Usually this is just about all methods too. It seems redundant but it’s helpful, and nice not seeing a whole lot of blank space at the top of your pages.
7. Not using var scope in CFCs. Within functions, you need to localize your variables by prefixing them with var, as in <cfset var qry = "" />. This will keep that variable within the function. Not doing this might not seem like a big deal, but there are two notable side effects. For one, if this object is persisted, so will any saved values. Also if this object is persisted, say in the application, then run by multiple pages, they might overwrite each others variables if they’re not defined with the var prefix. Some things like querys and query generated variables also need to be var scoped.
8. No trailing slash This is a big one for me actually. In order for CF to look more like a valid language it’s important to close trailing slashes.
9. New mappings needed. It seems like just about any application you download needs to have a mapping added for it. Although in CF8 there are ways of doing this within the code, it’d still be nice if there was a more universal standard for naming packages so that less mappings were needed. Imagine having a “com” and an “org” mapping and all frameworks were pretty much in those? I’m probably oversimplifying the solution, but it’s an idea. In the meantime it is possible to add a base directory to the cf tags directory then throw all your frameworks in there. From what I’ve seen, this works with most frameworks such as ColdSpring and Fusebox, although it doesn’t work with Reactor since it stores it’s created CFCs within the /reactor mapping.
10. Reinventing the Wheel. You knew it was coming. Creating an in house framework sounds great, but building off something that’s already there usually makes more sense. I was originally thinking “CFC heavy sites that don’t use ColdSpring” for this one, but any under use of a framework could apply.

Any big pet peeves of yours that I’ve missed?

If you’ve built, or attempted to build, a “web 2.0″ style site, you have no doubt come across the difficulties in creating rounded corners. It’s one of those problems in modern web development that there is no silver bullet for. The solutions for solving it aren’t just many, but they span many different methods. Choosing a method will help you decide what method you want to use. So what methods are there for rounded corners?

What do we want?

We want to be able to create rounded corners on for any element, usually divs, with minimal effort. It’s important to be able to create multiple rounded corners on a page. The aim should be to produce something that loads the fastest in a client browser and works as long as the user is using a modern browser; ideally without javascript.

The Basics

Almost all CSS techniques and some javascript techniques require the use of some number of “corner” images. These are those little images that may only be 20×20 in size, but when placed at the corner of a div it will give the appearance of a rounded corner. These little images will usually need the foreground and background color set in them to match those colors of the div that you’ll be rounding. The annoying part about this approach is that changing the color in your css requires updating your image files. It also complicates adding borders to your rounded boxes, because that will also need to be match in the div, meaning your graphics need to be more precise.

When rounding corners with Javascript the methods open up a little more. Some methods don’t require any image files, and will even allow borders. Javascript opens the playing field for more flexibility, but at the downside of performance. It’s also one more thing the user will have to have enabled in order to view the page as you want it. So what are methods people use to do CSS and Javascript rounded corners?

CSS Only

In my opinion this is the only true way to go. Rounded corners deal with how the view is displayed, and CSS is what describes that. If only it were that easy. In order to anchor images to elements, you need, well, elements. One of the most common ways is to have your CSS sprinkled with lots of elements, like this:

<div class='rounded-outer'>
   <div class='rounded-1'>
      <div class='rounded-2'>
         <div class='rounded-inner'>
            This is a rounded corner box
         </div>
      </div>
   </div>
</div>

Is this the best way? Definitely not, but it’s fast and it could be a lot worse.This works by adding each of the four corner images to those four divs. They’ll all be right on top of each other, so the end result will be a single rounded box with the text “This is a rounded corner box.”. There’s a lot of other approaches that use 4 individual elements to anchor images to that work in this same way.

Examples:
Guide to Rounded Corners