Tuesday, August 30, 2011

Site outages are like roller coaster outages

I was just at CedarPoint and a few of the coasters had some outages. The Dragster was out of commission for 30 minutes while I waited for front seat (could have gotten in the middle, but who does that). The Millenium shutdown for the whole day (I was in line for about an hour, it shut down, I waited 45 minutes and then exited the line). The Maverick ran empty test cars while I was in line for about 10 minutes, then went back on. The Windseeker was down all day because it was too windy (ironic).

As I waited in these lines, I was reminded how similar the outages are to web site outages for customers. There was terrible communication, the rides were in strange states (the Millenium car was stuck on the incline for about 25 minutes, then they pushed it over), and all the other people waiting in line were speculating on the problem thinking the worst.

Only difference in the outages between a site and a coaster is that those waiting in line can observe the actual failure happening to someone else (the stuck cars). The socialization was the same as if people were using Twitter to complain. We could see the technicians working, which is a bit different, you never get a live webcast of the developers and engineers on the technical teams for a site working to resolve the problem (that would be cool though, expose the conference line to customers and give video of the WAR room).

No additional thought, just that. Oh yeah, I had a great time.

Monday, August 22, 2011

Event data and inheritance

I spent some time working on a little project this weekend (I'll post about that separately). Regardless, two interesting things I learned were jQuery event data and inheritance in Javascript.

jQuery Event Data

Something I didn't realized that I made use of was jQuery event data. I recently posted about callback scope for Ajax, but I guess there is an easier way via the event data verses hacking the Ajax options.

Again, I had to do this in an object structure where the callback function was a method on an object. Simply passing the function gives no reference to the instance of the given object being used. So in the event data, you can pass the "this" to maintain the reference to the containing instance of the function being passed as the callback.

For example:
SomeObject.prototype.eventCallback = function(e){
This function "eventCallback" will be the function passed to the event such as a click.
$("#submit").click( {callingReference: this}, this.eventCallback);
See the options being passed in the click? The "this" is the instance object which "eventCallback" exists on. "this" will contain the state for the given constructed object. This click assignment is contained within a "setup" function on the same instance of "eventCallback".

In the "eventCallback" function, accessing the "this" data is a bit different:
var lCalRef = e.data.callingReference;
"e" is the function argument, and on it you can access the data passed in, which we are looking for "callingReference". It's assigned to "lCalRef" for shorthand.

Javascript inheritance

I've seen a lot of Javascript articles lately talking about object oriented implementations, inheritance, classes, prototype chains, etc. While, interesting, I never really needed this until this past weekend. Here is what I came up with.
// parent object
function Parent(){ ... }
// method on parent
Parent.prototype.buildBoards = function (){ ... };

// child object
function Child(){
// in the child constructor, call the parent constructor

// set the prototype of the child to a new parent instance
Child.prototype = new Parent();
// reset the constructor of the child to the child's constructor
Child.prototype.constructor = Child;
// reset the function to override on the child to the child's version
Child.prototype.__proto__.functionToOverride = Child.prototype.functionToOverride;

// define child version of function to override
Child.prototype.functionToOverride = function (){...};
Credit to this site which I stole from: Classes and Inheritance. What's happening here is manipulation of the prototype chain in Javascript to simulate inheritance. The child object is set to act just like the parent initially and then told to use it's own version of the defined function to override. The "prototype.__proto__" first points to the child's prototype, and "__proto__" is the parent's ("__proto__.__proto__" would work, but it was nice to show a difference).

In my testing, I found that the prototype chain manipulation to set the function to override must be done before the function declaration.

See also:

Tuesday, August 16, 2011

RSS feed changed for "itworksonmylocal"

Few days ago I posted that the RSS path for this site will change. The RSS URL is now:


Please update your readers if you are an RSS subscriber. Thanks.

Sunday, August 14, 2011

Back end or front end?

Where to start beginners in your organization? I'm talking about software people. College fresh. They know the basics, had some internships, worked on some open source projects, have their own projects, etc.

Now it's real life and you've hire this person. In the world of the web there is integration and front end usually. Integration is data, commands, logic, controllers, middleware, messaging, ETL, SQL, etc. Front end is UI, HTML, CSS, Javascript, the view, DOM, jQuery, Dojo, element positioning, AJAX, etc.

Which is best suited for a new hire, or recent graduate? I have no idea, but at my last job, fresh hires were front end people, and those with a few years experience we backend people. While I don't know which is best, I do know the blind statement that the front end realm is easier for beginners is completely wrong.

I went the other way, I started in the backend and recently and now spending my days in the browser. For me, this was a good fit. In college I wrote simple command line tools, and applications. I studied data structures and algorithms. I did some UI work for dumb web apps in my database class, but nothing with "style". I took and HCI course, but it wasn't about "design", it was interaction, psychology and humans. I knew Linux, the shell, scripting, etc. I knew Apache, MySQL, PHP, Python, C/C++ and Java.

I didn't learn about the browser, UI, styling, design. Why would the front end be a good start for a recent computer science graduate? For me, I have no idea.

Server side languages for the view are also not easy. PHP is prone to terrible code. I've seen some terrible JSP implementations with no respect to reuse of what already exists in the context. Functionality is thrown together with little guidance or best practices until you know better. Maybe there are better languages than PHP now, but I imagine they are still prone to inline HTML with simple functional concepts.

I guess in summary, bad fits make for bad results. Beginners don't "always" belong in the browser, or in server side languages for the browser. They belong where they "fit". If on their resume they have a lot of theoretical nonsense academic work with no portfolio on the web, they belong on the back end. If they have sweet start up sites and demo's, maybe the front end. Or, the person you are hiring does not want to do what they already know and want something new. It all depends. Don't force people into organizational stereotypes because it's what you're used to.

Saturday, August 13, 2011

Attention RSS Subscribers

If you follow this site via the RSS feed, I'll be changing the feedburner feed address.

Right now it's the old "awordon". I plan to switch it soon, if you stop seeing the daily delicious posts in the feed, come back to the main site and re-add it to your reader.


See also:

Friday, August 12, 2011

Content, business users and real development

Business users are not developers if they are called business users. When business users want control of content that feels like development, then it is development. Development of code belongs in version control, not content. Content that impacts the source controlled site is not content, it's code. Content development that can't be pulled from the source system for all developers that impacts other developers is mismanaged. If you think your content generator is pretty good at their job, they need to start learning the software development cycle. If the content generator can't pick up on the software development cycle, they aren't cut out for actual software development and their work needs to be passed to a developer.

Bypassing change control is not a reason to make something content. Again, you've missed the concept of the development cycle. Issues are scheduled, prioritized, worked on, tested and released. Issues are not fixed by business users via content in same day and released.

HTML, CSS and Javascript are code, not content. These technologies are complex. When you make them content and bypass the development cycle, you've bypassed technical review. There is a good chance you'll break the site due to your precious glamour content.

Dear content people, I understand you like your work, I like mine. But let's work together verses avoiding each other. When I make a change in the actual code (version controlled code) simply done in HTML, CSS and JS, why do I have to abide by ticketing, review, testing and releases, while you don't? Seems wrong.

Share on Twitter