Cool Stuff

A while back, I stumbled upon a nice little class in Ext JS: Ext.draw.Color. It’s pretty much what it sounds like: a helper class for dealing with color (shocking!). Behind the scenes, Ext.draw.Color represents an RGB color, but provides a number of helpful methods for transforming the color, such as changing luminosity, converting to HSL values, etc. I can’t sleep right now, so I thought it might be interesting to show a few examples of this in action.

The Proverbial Hello World of Color

Of course, the natural place to begin is at the beginning, so let’s create a color. There’s not much to it. While there are a few other ways to go about it, we’ll use the handy create() method. You can pass a variety of “colorish” arguments to it to create your color. For example, let’s say we want to create the CSS color “yellowgreen”. We can do so in many ways:

In my last post, we explored the new routing functionality that has been incorporated in Ext JS 5. I had a lot of great feedback and discussions come from that (thanks!), so I thought I’d add a few more notes about some of the routing functionality that I didn’t discuss in the last post. So without further jabbering, let’s dive in.

Route Conditions

One nice feature of routing in Ext JS 5 is that not only can you add a before handler to the route execution, but you can also filter routes which will be matched based on a regex string.

As written, this route will match any hash in this form, regardless of what actual value is passed for our “id” placeholder. What this means is that if someone gets clever and starts to try to manually hack our hash with some value other than what comes naturally from our application, our before handler is still going to fire on the hacked value, and whatever code is in that handler will execute.

Obviously, we could put some error/hack handling in our before handler, but More >

My blog is 99% percent about my development exploits, but I do like other things too…like football. Next week, there are a number of rule changes up for vote by the owners. Here are a few opinions on the matter:

1. Move the kickoff from the 35-yard line to the 40-yard line.

No. Most kickoffs already go out of the back of the endzone. If we’re so interested in preventing kickoff-related injuries, why not just get rid of it altogether? I say either make the kickoff relevant (move it back to the 30-yard line), or drop it altogether.

2. Expand instant replay to include personal foul penalties.

I think this is fine. Personal foul penalties are costly, so having recourse on such calls is a good idea.

3. Eliminate overtime periods in the preseason for player safety reasons.

How about eliminating the pre-season altogether? I’d rather have a longer regular season (like 2 more games), rather than suffering through the yawn-fest of the pre-season. Since that’s not going to happen, yes, let’s drop overtime in pre-season games…no need to drag them out any longer.

4. Extend the goalposts an additional five feet above the cross bar.

I honestly don’t care. I’d prefer that the goal posts just be removed More >

With the recent updates to DragonVale v1.8, the app has seen some impressive evolution since its inception. The app now has a thriving community, and despite its ridiculous freemium business model, the updates keep coming…so money is being made off of it.

As we get closer to the 2.0 release (not suggesting it’s imminent), I thought I’d share some ideas about what should be done to really take this game to the next level. With dot releases, you don’t expect a revolution…nice touches here, a new feature there, but nothing off the chain. With the release of a whole version, though, it’s a chance to reinvent and make a play for a whole new set of players. So without further introduction, here are some things I’d like to see in the 2.0 release.

More Robust Management Tools

Currently, the app only really allows you to manage your world on an item-by-item basis. There is literally no way to get a “high” view of what’s going on. Version 2.0 needs to fix this. So what does this look like? One idea is global interfaces for managing common “types”–dragons, buildings, farms, etc. It’s tremendously annoying to have to go to each habitat in order More >

Like ArrayEach() and StructEach(), the new filter methods have a “function” parameter (which can also be either an inline function or a named function). However, unlike ArrayEach() and StructEach() which return nothing, the new filter functions return a new array, list, or struct, respectively.

To accomplish this, you need to return a boolean from the function parameter. If the current array element, list item, or structure value matches some criteria and returns “true”, it will be added to the new returned array/list/structure. Conversely, if it fails the criteria and returns “false,” it will be excluded from what is returned.

NOTE: The array/list/struct filter() functions return NEW arrays/lists/structures. The original arrays/lists/structs against which the filter() functions are called are unaffected.

An Example

Let’s say that we have a simple set of “circles” for a Google+ account which includes a circle for friends, one for co-workers, and another for family. We might model this data like so:

Earlier today, I was looking through the “New Functions in ColdFusion 10” doc, and noticed a few gems: ArrayEach() and StructEach(). These are huge, because until now, there has been something of a disconnect between dealing with arrays and structures in CF, and their counterparts in other languages, like JavaScript. All JS libraries (like ExtJS) have “each” methods attached to basic objects which allows you to treat collections of the same kind of thing in a bulk way. Fortunately, CF10 introduces two very handy new methods to apply an “each”-like process to both arrays and structures.

NOTE: The ArrayEach() and StructEach() functions act on the original array/struct. Therefore, if you make changes to the array/struct within these functions (as in the ArrayEach() example below), the original array/struct will be affected (thanks Andy!).

ArrayEach()

So, for example, let’s say you have an array of friends’ names, and you want to make the list all uppercase. Pre-CF10, you might approach this by looping over the array, and executing a function at each iteration. Fine, easy enough, and it works. However, with ArrayEach(), you can ditch the clunkiness of the for-loop, and keep everything self-contained to the array. And, you can execute either an “inline” function, or More >

With the public release of ColdFusion 10 Beta yesterday, I thought I’d play around a bit with some of the new capabilities. One of the features added in this release is the ability to group in query loops using <cfloop>.

As expected, this is pretty straightforward, and has the same capabilities as the <cfoutput> corollary. Here’s a quick example:

Today’s excursion into Ruby is a short one. The 3 Koans (constants, control statements, and true/false) are pretty basic. However, upon completing them, I am now officially over 50% done with Ruby Koans!

Of course, I am by no means ready to really start doing anything with Ruby. However, I do feel like I am grasping basic concepts, and my journey through the Koans is becoming less of flailing blindly and more of thinking about what I’ve learned and trying to reason through the challenges I encounter. Granted, not impressive, but it is progress

Constants

The first Koan dealt with the concept of constants. The role of constants in programming is pretty well-understood, so there’s nothing difficult to understand about their usage in Ruby…in fact, the Koan dealt mostly with how to access constants (within and outside of their definitions relative to particular classes). I did find a nice, more in-depth explanation of the role and usage of constants within Ruby. Check it out when you have a chance.

Control Statements

Ah, what would programming be without control (if, else, for, while…) statements? Probably not worth doing!!

A couple cool things I want to point out about control statements in Ruby.

In this experiment, I’m using a few things I’ve not messed with much in the past: keyframes and the flex-box model.

Flex-Box Model

If you’re a web designer, you’ve no doubt spent endless hours trying to coax HTML and CSS to do simple things like expand “columns” a particular percentage in width and height. This is a horrible nightmare to endure, and it usually ends in a lot of hacks and more cursing, just to More >

Over the last month or so, I’ve watched a BUNCH of zombie movies. From absolute classics like Night of the Living Dead, to foreign offerings like The Horde, I’ve seen the good, the bad, and the terrible in the way of zombie movies. While this is to be expected of all movie genres (but perhaps especially those which tend to hover around the B-movie monicker), for me, it’s not the typical things that make zombie movies great or awful. Some movies live and die on acting, special effects, and plot. While these are certainly not un-important in a zombie flick, they don’t sit on the top of the list in my book. Rather, what makes a great zombie movie is one which follows the rules of zombie movies.

The Rules

Ok, first of all, I don’t think there are *really* any hard-and-fast zombie rules. Sure, some will argue about whether zombies should be able to run, or whether they should be intelligent enough to organize efforts on a minimal level, or whether they should have enough dexterity to turn a doorknob. But in my thinking, trying to pigeon-hole such an expansive field of horror-creature is just wrong.