Bakuenryu!

Now that '09 has finally come to a close, I'm able to take a look at the year in World of Warcraft recruitment data (at least, what's available to me via WoW Lemmings). Aside from a basic side-by-side report of the recruits found, as compared to the previous year, some interesting data comes out of Google Analytics regarding who searches for what. Here is a tidbit of the "Warcraft-related" stuff.

The top 10 keyword filters used were:

late
late night
holy
tank
ele
resto
casual
weekend
night
prot

The top classes searched for were:

Druid: 20.6%
Shaman: 19.4%
Paladin: 16.8%
Priest: 11.5%

Then, a sharp decline into the remaining classes:

Death Knight: 5.3%
Warrior: 5.1%
Mage: 3.8%
Warlock: 3.5%
Hunter: 3.0%

Not surprisingly, more people made general searches of all classes (2.08%) than people who actually searched for Rogues (1.86%).

And, for the grand finale, the top 10 WoW Lemmings search criteria all year were:

1: US Alliance
2: US Horde
3: Horde
4: US Alliance (No Idiots)
5: US
6: US Alliance PvE
7: US Alliance Priests
8: US Horde (No Idiots)
9: US Alliance Druids
10: US Alliance Shamans

Interesting what "perceived" class need is by guild recruiters.

It's been awhile since I've made an update to WoWLemmings, your #1 World of Warcraft recruitment tool on the web (proudly built in ColdFusion, I might add), but there has been work going on behind the scenes, and I'll share a bit with you now.

First, I'm proud to announce that WoWLemmings now has its own Twitter account, and it is fielded by none other than the WoWLemming Bot. If you're a hard-core twitter nerd, or you like to get random guild recruitment-related tweets, head on over to Twitter.com and follow the bot. He's not the most insightful or profound chatterer at this point in time, but he will give you semi-regular updates on recruitment data. Specifically, the bot will periodically send updates on what new types of classes are being found on various recruitment sites (and subsequently added to the WoWLemmings index). The bot also monitors the website's usage, and reports back on what people are searching for.

For the ColdFusion folks reading this blog post, the Twitter bot was created with ease, thanks to CFTwitterLib by Pedro Claudio. Be sure to check it out if you are contemplating doing any kind of Twitter integration. Looks like he just updated it for the beta of ColdFusion 9.

Secondly, in the small update category, I've added another site to Kathune's spider list: Maintankadin. Thanks to the folks over at Elitist Jerks for referring that site to me.

I have a number of updates in the works that I hope will speed up your recruitment tasks even more, the first of which will be an Ajax-based pop-up for the recruits that supply links to their character on The World of Warcraft Armory. This will be one-less click for you recruiters that are trying to assess player value effectively.

I recently picked up a copy of World of Warcraft: Ashbringer
by Mickey Neilson. It's really just the four-comic miniseries bound together and pitched as a hard-cover graphic novel. It was a light fun read and I get very few opportunities to actually do any comic-book reading in my (somewhat immature) adult life, so it was a nice change-of-pace from game manuals, programming blogs and news feeds.

It covers one of the more important story lines in the Warcraft universe, namely the creation and mythos surrounding the Ashbringer, a weapon that was created by the founding fathers of the Scarlet Crusade, for the purposes of cutting down the armies of the undead. The key characters are Highlord Alexandros Mograine, whom eventually wields this weapon, and his two sons, Renault and Darion. The breadth of the comic spans Alexandros' discovery of the magical orb which has its power injected into the blade (via Magni Bronzebeard, of all people), as well as his rise to leadership of the Scarlet Crusade and eventual death at the hands of his son, Renault. It also explains how he is brought back as a Death Knight by Kel'thuzad (the truly old-school WoW players will remember that he was one of the original Four Horsemen in Naxxramas), at which point, the focus of the novel transitions to young Darion Mograine.

It is interesting to finally get some additional insight into the background of Darion, who eventually becomes the head of the Knights of the Ebon Blade (though that happens far beyond the scope of the comic), as well as see how the Mograine family-line intertwines with those of the Fordrings (Tirion, Taelen). All in all, an enjoyable comic and recommended for you WoW lore nerds.

This could become a very long and complex post, so I'll keep to the basics, and make some assumptions out of the gate:

1. You know what ColdFusion is.
2. You have basic knowledge of Objected-Oriented Development, and understand the implications of inheritance in a class hierarchy.
3. You know what Fusebox is (a CF framework for building websites) and are aware of basic fusebox setup and naming conventions (MVC, circuits, fuses, XFAs, etc.)

Problem

ColdFusion has no concept of a "Static" class. This is a class that does not need to be instantiated in order to have its methods accessible, and does not have access to any encapsulated data from previously instanced objects of said class. One of the more common ones in Java is the Math class. Hence, this is valid:

Math.random()

as opposed to:

var mathObj = new Math();
mathObj.random();

In this example, Math, as a Class, doesn't have any hidden internal variables, it doesn't maintain state, it has no knowledge of any other Math objects. It simply exists as a series of methods (much like a common UDF library) that can perform stand-alone functions as needed.

Assumptions

Assumption #1

Fusebox, as a framework, allows you to implement circuits as CFCs. These CFCs (which are Classes for the non-CFer) are the various Controllers in your MVC Fusebox setup. Since these Circuits are CFCs, they may be inherited from and this can serve to enforce a common class hierarchy for your website.

You are dealing with a Fusebox website that handles fruit.

You are aware of a Controller class hierarchy being implemented as such:

Controller.Fruit
-- Controller.Apple
-- Controller.Banana

Controller.Fruit has a fuse called showInfo() which produces common information to the screen about said fruit.

Controller.Apple (which derives from Contoller.Fruit) has no showInfo() method. The assumption is that when someone calls showInfo() on Controller.Apple, it inherits functionality from Controller.Fruit, and applies the information accordingly. If you made this assumption (and you are still with me), you would be correct.

Controller.Banana does have a method called showInfo(). It produces additional Banana-related info to the screen, and ends by calling super.showInfo(), which ensures that the common fruit-related info is also processed.

This is a typical URL for the site you are working with:

http://www.myfruitbasketbox.org/index.cfm/fuseaction/apple.showInfo/apple_id/4

So far, so good.

Assumption #2

XFAs (eXit Fuseactions) are commonly used by Fusebox developers to implement a common naming convention for any dynamic destinations in a given site. The site in question happens to have an XFA called "XFA.FruitInformation", which is set like so, from within Controller.Apple:

<cfset event.xfa( 'FruitInformation', 'showInfo', 'apple_id', '' ) />

and like so, from within Controller.Banana:

<cfset event.xfa( 'FruitInformation', 'showInfo', 'banana_id', '' ) />

Don't let the blank space on the end distract you; it is done this way so that the developer can dynamically append an ID from within her generic fruit-wide template. What you need to be concerned with is that for each of these XFAs, the name of the primary key or "identifier" is different: apple_id for Apples, and banana_id for Bananas.

Assumption #3

Any Controller CFC that implements a prefuseaction() method and/or a postfuseaction() method allows the programmer to enforce that a particular method is run pre- and post-fuse. This is part of the Fusebox framework. It can be argued that a good place to set up XFAs is from within a prefuseaction(). This site happens to do just that.

The Case

Now, the conundrum. You soon discover that the site implements the concept of a "Mystery" fruit. Upon re-investigating the Controller hierarchy, you see:

Controller.Fruit
-- Controller.Apple
-- Controller.Banana
-- Controller.MysteryFruit

This tells you that a MysteryFruit derives directly from Fruit, and furthermore, implements all of the fuseactions that are implemented in Controller.Fruit, such as the aforementioned showInfo(). The core of Controller.MysteryFruit.showInfo() is quite a bit different than that of Controller.Apple or Controller.Banana(). It includes a line that looks like this:

<cfset myFusebox.do( action="#myFruit.circuit()#.showInfo" ) />

Although not the cleanest solution in the book, the code tells you that MysteryFruit.showInfo() dynamically determines what kind of fruit it is handling at runtime, and calls the necessary "known" fruit's showInfo() method. In this case, if it is dealing with an apple, it will call Controller.Apple.showInfo(), likewise, Controller.Banana.showInfo(), if the fruit is a Banana.

You also notice that Controller.MysteryFruit implements its own special display of fruit information, by the presence of this XFA in Controller.MysteryFruit.prefuseaction():

<cfset event.xfa( 'FruitInformation', 'showInfo', 'fruit_id', '' ) />

However, the problem is this: Once Controller.MysteryFruit.showInfo() fires, it first processes functions and data in its own prefuseaction; in this case, the XFA listed directly above. However, once the showInfo() method itself is reached, and it hands off the request to Controller.Apple.showInfo(), the prefuseaction within Controller.Apple.showInfo() also fires. The end result is that MysteryFruit expects XFA.FruitInformation to have a dangling 'fruit_id' parameter on which to append a value to, but instead, gets an 'apple_id' parameter, since the Controller.Apple.prefuseaction() fired as well.

In this bizarre setup, it would be nice to be able to instruct Fusebox to call another Controller's fuses in "Static" mode; that is, to produce only the business logic encapsulated within showInfo(), and ignore (or prevent) the execution of any pre- or post-fuseactions.

Solution

In order to create this pseudo-Static Controller functionality within Fusebox, I added a top-level prefuseactionCheck() function that attempts to determine if the Controller in question is derived from the original Controller accessed by the user. This allows me to preserve the prefuseaction() execution-hierarchy all the way up the Controller chain ( in this case, firing both Controller.Apple.prefuseaction() and Controller.Fruit.prefuseaction() ). Meanwhile, if a fuseaction from outside the hierarchy is accessed, I can suppress the execution of that Controller's pre- and post-fuseaction, generating only the core business logic of that fuse that is required.

First, grab hold of the first Controller that becomes available to the Fusebox framework:

        <!--- at the first opportunity, assign OriginalController --->
        <cfif StructKeyExists(myFusebox, 'ORIGINALCIRCUIT') and
 NOT event.valueExists('OriginalController')>
            <cfset event.setValue('OriginalController', this) />
        </cfif>

The StructKeyExists test is necessary because in No-XML mode, Fusebox can't guarantee it knows its fuses and circuit out of the gate. As a result, it's pointless to compare myFusebox.THISCIRCUIT with myFusebox.ORIGINALCIRCUIT, because there is a possibility that when you need them the most...they won't be available. Better to just take myFusebox.ORIGINALCIRCUIT as soon as it exists and store it as the OriginalController.

Next, compare the Controllers to see if there is class heredity or not. Do this using the function IsInstanceOf()

         <cfif StructKeyExists(myFusebox, 'THISCIRCUIT')>

            <!--- Is the original circuit's controller an instance of Me? If not, I am a statically-called class --->
            <cfif IsObject(event.getValue('OriginalController',0)) and
 NOT IsInstanceOf(event.getValue('OriginalController'), 'controller.' & myFusebox.THISCIRCUIT)>
                <cfset isStatic = true>
            </cfif>
           
        </cfif>

This code then generates three comparisons up the class hierarchy:

MysteryFruit.showInfo() -> MysteryFruit.prefuseaction() -> "Hello, I am Controller.MysteryFruit. Is Controller.MysteryFruit an instance of me?" TRUE (one and the same)

Apple.showInfo() -> Apple.prefuseaction() -> "Hello, I am Controller.Apple. Is Controller.MysteryFruit an instance of me?" FALSE (I am an instance of Controller.Apple, which is also an instance of Controller.Fruit)

Fruit.showInfo() -> Fruit.prefuseaction() -> "Hello, I am Controller.Fruit. Is Controller.MysteryFruit an instance of me?" TRUE (Controller.MysteryFruit derives from me, so we are both of type Controller.Fruit)

Once this is implemented, you can hand back the TRUE/FALSE results to the calling prefuseaction and process/suppress any additional code as necessary. Furthermore, the technique I use here can also be used to determine if a particular circuit's prefuseactions have already fired once up the class hierarchy, so that heavily granular fusebox apps with many fuseactions don't unnecessarily call prefuseactions over and over.

Wednesday proved to be lucky for me, as I wrapped up an ongoing achievement in World of Warcraft, the grind-worthy Bloody Rare. I've noted on several public forums that those of us whom have completed either Bloody Rare or Frostbitten (or worse, both) are prime candidates to be inducted into the "huge nerd with no life" hall-of-fame. After having played the game non-stop for four+ years, successfully lead the same guild for that duration, and have leveled numerous alts to their max level (at that time in the game), not to mention my embarrassing passion for the lore of the game...I think it's a safe bet that I cashed the huge-nerd-with-no-life check long, long ago.

In reality, Bloody Rare was not that difficult to complete, especially considering a Death Knight spends only a fraction of their time in Outland during the leveling process. Once I got rid of all the necessary quests to complete in Northrend, and began working on the various reputation grinds that were introduced with The Burning Crusade, I found myself spending a lot of time crossing the wastelands once known as Draenor. If I recall correctly, the breakdown went something like this:

1. During the initial leveling grind, I left Outland once I hit 68. Starting from Hellfire Peninsula and diligently completing quests in the order of the zones, this put me right at the start of Nagrand. So, when the time came to return to Outland, Nagrand is where I resumed. As a result of this choice, Goretooth was the first rare to bite the dust, followed soon after by Voidhunter Yar.

2. Once finished with Nagrand, I returned to Terrokar Forest to begin the Sha'tari Skyguard reputation grind. I prioritized this reputation early on because it grants you Nether Ray mounts (for Mountain o' Mounts), a Nether Ray pet (for Lil' Game Hunter) and a tabard (for Twenty-Five Tabards). Since I spent a lot of time in Terrokar for this grind, I made certain to note the spawn/roam points for the rares. Crippler was the first to bite it, followed by Okrek.

I didn't find Doomslayer Jurim for quite some time, but again, this worked out, because he is normally seen walking the road to Shadowmoon Valley, and by the time I had transitioned to Shadowmoon, I was already following the road closely. He eventually popped his head out, and was slaughtered.

3. As noted above, Shadowmoon Valley was my next prioritization, as I wanted to begin work on the Netherwing faction (which would also contribute to Mountain o' Mounts). If memory serves, Ambassador Jerrikar was the first to bite the dust, and I hadn't even begun the Netherwing grind yet; I was still working on completing Shadow of the Betrayer and he just happened to be up.

Collidus the Warp-Watcher was next on the kill list, and it was a convenient kill because one of his spawn points is along the south-east edge of the Valley, which you fly over en-route to Nethwering Ledge. I distinctly remember flying over his dead body (twice!) and having that "uhhhhh....just a few seconds too late" feeling you get during a near miss. As luck would have it, I spent a good deal of time working on Netherwing, and I eventually killed him on that south-eastern ledge.

I killed Kraator last, as I was nearing the end of the Netherwing grind. Kraator is one of the few mobs I had previously found and killed in The Burning Crusade, so I had a bad feeling he was going to give me a problem showing up (which carried over to another mob, read on) but he soon made his appearance and was dispatched with great vengeance.

4. I moved to Netherstorm next, because my plan was to wrap up Shattrath Divided, and I had already completed all the necessary Scryer-based quests in Shadowmoon Valley, so it made sense to wrap up Into the Nether, while continuing to grind Sunfury Signets/Arcane Tomes. Chief Engineer Lorthander was killed almost immediately, and in fact, made his appearance several times during my completion of the Netherstorm quests. I also found Nuramoc twice, calling in a fellow guildy for the second kill.

Once I had completed the Netherstorm quests, Ever-Core the Punisher still hadn't made his grand entrance, so I adjusted my Scryer grind to his known patrol locations: around the circumference of Manaforges B'naar, Ara, and Ultris. I finally caught him at the latter, and delivered a fatal blow.

5. Blade's Edge Mountains was next on my list, which was the focus of On the Blade's Edge, which in turn, would lead to Loremaster of Outland, and I additionally was looking to begin work on A Quest a Day Keeps the Ogres at Bay. Morcrush was first on the list to perish, whom I found while handling the Rexxar storyline, flying between Thunderlord Stronghold and Mok'nathal Village.

Hemathion was next to die, as he spawns right smack in the middle of where the Ogri'la daily quests are done. As of this writing, I'm still working on Ogri'la, and have seen him two additional times...so one might argue he's the most easily found of all the rares.

I eventually found and killed Speaker Mar'grom, just by doing my standard 'fly-over-the-spawn-points-if-you're-in-that-zone' plan, wrapping up the rares for Blade's Edge.

6. At this point, I had only a few stragglers left. I had previously killed Bog Lurker and Coilfang Emmisary in Zangarmash during the initial level grind, yet Marticar escaped me. I had a hell of a time finding Marticar, and frustration soon set in.

Remember my previous statement about killing Kraator back in TBC? Marticar also shared this trait. Many moons ago, when there was no Northrend, and I had no Death Knight to speak of, I was raiding on a Shadow Priest. My food buff of choice for her was Blackened Basilisk, which I farmed with the greatest of ease off of Marshrock Threshalisks, in their native habitat along the northern edge of The Dead Mire. As a result of this decision, I spent a lot of time in-transit between Swamprat Post and the Basilisk farm area, which coincidentally, is right smack in the middle of one of Marticar's spawn points.

I saw him many, many times throughout the course of TBC. What's bittersweet about it is that I farmed on my level 63 Warrior, and (at that time) Marticar was a level 63 Rare Elite...which simply could not be solo'd by a Warrior of the same level. As a result of this, Marticar taunted me every time I saw him while farming for spell damage food, as I couldn't even approach him without fear of being blown up.

Now, as a level 80 Death Knight that lays waste to anything it comes across, the rare Fen Strider continued to taunt me simply by not showing his face. I stayed diligent, and continued to fly over his spawn points as often as I could, en-route to Blade's Edge while continuing to work on Ogri'la. Finally, one random evening, my targeting macro picked up his ugly bright pink body. I swept down into the swamp, and gutted him like a fish. My Warrior has been avenged.

7. All that remained was Hellfire Peninsula. Since I was hyper-focused on leveling the DK when I was last in this zone, and hadn't even really started to plan out my achievement whoring map, I didn't think at once to prioritize any search for rare mobs, so all three still needed to be killed.

I lucked out with the first mob, Fulgorge. Here's the deal: There is a targeting macro that you can use to expedite Bloody Rare. I've pasted the macro below for your convenience.

/tar Fulgor
/tar Mekt
/tar Vorak
/tar Martic
/tar Bog Lurk
/tar Coilfang Em
/tar Crip
/tar Doomsay
/tar Okrek
/tar Goretoo
/tar Voidhunt
/tar Morc
/tar Hema
/tar Speak
/tar Nura
/tar Ever-Core
/tar Chief Engineer L
/tar Collid
/tar Kraat
/tar Ambassador J

Once you have this macro set up, add it to your hotkey bar, and as you fly over Outland, be sure to fly over the known locations of the rares, and spam away; if the rare is up, you will target it automatically, and can drop down for the kill.

However, the trick with Fulgorge is that he is a Sand Worm, and like all sand worms in the game, travel the world underground, leaving only an animation of "rubble" where they will pop-up. You cannot target this rubble, so the targeting macro will not work on him. I had to take desperate measures for him, which my Mother used to refer to as elbow grease. I focused in on his known pathing locations, and watched closely for the "red rubble" that many of the comments on WoWHead mentioned. The first red rubble animation that I actually noticed on my own was just west of Falcon Watch. Dropping down off my flying mount, I ran over to the rubble and engaged...and sure enough, up popped Fulgorge, knocking the first of the three rares out. As a side-note to this, I paid close attention to the other colored rubble in Hellfire Peninsula, some of which is white, and I can say with certainty that the red rubble is not the identifying trait of Fulgorge, as there are other sand worms that create red rubble. With Fulgorge, while it is most certainly red rubble, it is a much larger radius that what is typical for sand worms, so if you see one that is unusually large, it's probably a safe bet that Fulgorge lies beneath it.

Nothing too special about the second kill, which was Vorakem Doomspeaker; I caught him along The Legion Front, just south, towards the Alliance NPCs. This left only one rare mob on the list: Mekthorg the Wild. By this time in the game, I was traveling back and forth between Hellfire Peninsula and Netherstorm, as I was grinding Zaxxis Insignias to work on Chief Exalted Officer.

I would do the work in 1 hour shifts: Fly across his spawn points, spamming the macro. If he wasn't up, I'd fly straight north to Netherstorm and farm Insignias for an hour. I'd then fly back to Hellfire and repeat the process. About a week ago, I recall one evening where I was flying back from Netherstorm to Hellfire and, for some reason I can't recollect, went AFK for about 15 minutes. When I came back, I flew over Mekthorg's spawn points...and found him...dead.

Ugh. I hate when that happens.

Just a few days ago, I was completing my usual lunchtime banking routine and had a few minutes to kill before heading back to work. There was enough time for a quick fly-over, so I flipped to my Death Knight and commenced with the macro spamming. To my great surprise, I caught him on the road, traveling north toward Hellfire Citadel. I dropped off my mount and engaged, and with a swift blow from Armageddon, so concluded my journey through Bloody Rare.

Now...onto Frostbitten...

With time running out on the release of the upcoming 3.1 patch for World of Warcraft, raiding guilds are continuing to stress-out over the changes to Glory of the Raider, namely in regards to the removal of the Black and Plagued Proto-Drakes from the achievement. I am, unfortunately, not immune to said stress. With every other achievement in the meta already complete, I am at a loss as to how to the guild will pull this feat off.

For us, the issue is not one of skill; the team of raiders I take to Naxxramas each week to work on The Immortal are the cream of the crop. They are exceptionally well-played, communicative, can adapt under pressure, and handle emergency situations with reasonably good reflexes. Sadly, what plagues us is what will plague a good many guilds attempting to knock this achievement out; those parts of the WoW game mechanics that lie outside our realm of control. People disconnecting in the middle of a fight, thanks to a poor ISP (or even worse, a good ISP...that just happens to have bad latency / packet loss that particular raid evening). People locking up, due to performance issues, either with the game, or with their own PC's limitations. Or a flat-out crash of the WoW client.

These rare edge-conditions can be mitigated, as stated by many of the strategy guides, with such things as Guardian Spirit or a Divine Shield/Divine Guardian combo, but in all honesty, is this something should be mandatory? How realistic are these solutions? More importantly, for a game that has already levelled the playing field in the PvE deptartment, is there really a need to deprive the effort of guilds an adequate reward that judges your performance as a whole not by skill...but by the stability of your internet provider?

We had a near-flawless run of Naxxramas last night, but sadly, fell victim to one of the issues listed above. One of our star players simply "locked up" on Thaddius during a polarity switch, and was unable (in only a few short seconds) to announce the problem over vent. By the time his computer caught up, it was too late; the polarities were crossed and he took a blast of damage that caught the healers off-guard, and he fell over, dead...thus, wasting yet another week's worth of work.

Don't get me wrong, I'm very much in support of The Immortal-like achievements, and feel they are great accomplishments to strive for. Where I take offense is when they are compiled into the meta-achievement for Glory of the Raider, which is supposed to be a composite of raid skill across the board, and rewards said-skill with a mount that is going to be inaccessible in a few short weeks. Some of those other prerequisites are not pushovers, either: Guildox reports the worldwide achievement rate for The Twilight Zone at 17%, and You Don't Have an Eternity at an abysmal 4%. However, both achievements allow you to retry, again, and again, finding weaknesses in your strategy, and adjusting appropriately until you find what works, and solve for x. With The Immortal, there is no re-strategizing, or re-thinking, there is no sending someone out to respec, or having someone craft some frost resistance gear on-the-fly. Trust me: for the guilds that have already completed everything else in the Glory achievement, it isn't about how to stay alive...

...it's all about a roll of the dice to see if tonight is the night that nobody disconnects.

The good news is that Blizzard concurs (for now) with this mentality, and is removing The Immortal, Part Two from the Glory meta-achievement that will be attached to Ulduar. The bad news is they still feel that some mounts should maintain a degree of rarity, and for this, are adamant on changing the existing achievement.

This, in my opinion, is sad way to treat the playerbase, especially for the amount of effort that many raiding guilds are putting into the achievement. Once 3.1 launches, and we happen to see the occaisional Black or Plagued Proto-Drake flying around, it will only serve to indicate the guild "lucked out"....and didn't have any players disconnect that evening.

If you have a story about how your guild blew The Immortal, I'd like to hear about it.

You know, I have to comment on a trend I've been seeing recently. Now that I have subscribed to various blog aggregators, I'm being exposed to a higher volume of developers (and their work) than I would normally. As a result of this, I'm surprised to find developers that are calling other people's work their own, either directly or implicitly.

Case in point: I just found a blog post from a CF developer who created an online presentation discussing design patterns, and how to implement them. I paged through the presentation, which I found contained examples that bore a striking resemblance to the Decorator Pattern chapter in Head First Design Patterns. The book's first example? A Duck domain object. Surprisingly, the same in the presentation. The second example: A Coffee domain object, oddly enough, second in the presentation. The textbook uses a Pizza domain object as the third example. Take a guess at what the third example in the presentation is.

I'm more inclined to let it slide when someone adapts what was written in the text more closely to the language they are working with, which in turn acts as an instructional tool for junior developers of that language. As it turns out, this is what another CF developer did (and a fairly well-recognized one, to boot), and their "article" remains online at the ColdFusion Developer's Journal site to this day. I appreciate the work that went into it, and I'm glad that it served as a CF-based decorator lesson, but c'mon...was it you "really standing in line at your local coffee shop" that inspired your Coffee-themed decorator article? Or was it more likely that you also picked up a copy of Head First Design Patterns (which, coincidentally, was published and hit the shelves four months before your article). Pretty surprising coincidence, considering the examples of "options" and "syrups" used in both.

I can almost hear the naysayers now: Cut these people a break. You can only customize coffee so many ways. It isn't surprising at all that these programming examples bear similar attributes.

That sound you hear is me rolling my eyes.

Why is it so hard for people to give credit to the material that taught them in the first place? Is it that important that you have to try to have your knowledge stand on its own? Does it make you more credible when you don't cite your sources, and thus, act like you knew this information all along? Wouldn't it make sense that, once your article was found to be a near-copy of something already published, you would have less credibility than before?

I feel bad for the original authors, honestly, whose work it was is now being billed as someone else's. It's my opinion that, if you want to use someone else's work, you should either come up with your own specific examples that apply the same knowledge, or at least make a reference to the information that taught you in the first place.

The presentation I mentioned at the start of this post ends with a classic "Any Questions?" slide. Yeah, I have a question:

What part of the presentation were you planning on citing the sources pulled from that O'Reilly text?