'Personal' Category

Why won’t my span respond to click events? Strings vs. DOM elements

I had another fun opportunity to work on a web app (I’ve been doing a lot of them lately) over the last week. This time I built on my recent JSON experience by writing a Rails app that only communicates in JSON. Rather than have the output built using Rails views the output is sent as JSON to a JavaScript client in the user’s web browser.

Once in the web browser, the data has to be parsed and split up into different sentences based on what the user wants to do with the data.  Once the data is split into sentences it’s appended to divs that show the sentences in the web browser.  Some of these sentences have to be clickable, they must respond to a “click” event coming from the user.  This is completely ordinary in most JavaScript web apps.  The user clicks, the browser responds.  Imagine my surprise when my sentences weren’t responding to the click input.

I wasn’t surprised for very long, however.  By looking at how I prepared the sentence in the JavaScript code made it pretty obvious what was going on.

data[index] = data[index] + ". <span class=\"my_class\">" + choices[choiceIndex++] + "</span>";

This created the sentence that was to be clickable. It’s just string data that creates a span with a class. This is something jQuery can find by doing $(“.my_class”). Once I have all the spans with that class I can add a click event to them. Well, that’s true, but those spans have to be DOM objects before jQuery can find them.

The way I was doing it, those spans were just string data. Sure, the browser displayed them with the correct style but jQuery was unable to find them because they were not internalized as DOM objects. Opening a JavaScript console with Google Chrome would allow me to run the same code to make the spans respond to click events and it would actually work. Chrome’s console reads the DOM after the page has been rendered and creates the DOM objects based on the rendered page when the spans are in place. This is no good to me. I can’t tell my customer to tell his customers to open a JavaScript console and run this cryptic command after loading the page.

In order to get the behavior we want we have to create DOM objects using jQuery so jQuery can then find these objects to add the click behavior to them. Rather than creating spans as string data we use the jQuery function to create a DOM element with the correct class and text.

elm = $("<span class=\"my_class\">" + choices[choiceIndex++] + ". </span>");
elm.click(function(){
                  alert("Hey! You got the right answer!");
                  document.location = "http://localhost:3000";
                });

The jQuery function, $( ), first looks for elements based on the class, id or attribute selector passed in to it. If there is no selector then the function looks for any tags in the string passed in to it. If there are tags, in our case span tags, jQuery creates the appropriate DOM element based on the content of those tags! This is great! Now I can pass in my string data and have jQuery return a DOM element that I then bind to the click function specified.

Adding the click function later also works now.

$(".my_class").click(function() {
                  alert("Hey! You got the right answer!");
                  document.location = "http://localhost:3000";
                });

I’m happy with the way I can build a DOM element using the jQuery function. In order for jQuery to find the objects we look for those objects have to be DOM elements, not just string data appended to a div. DOM elements respond to events, strings do not.

Thoughts on the Economics of the AWS Cloud

A couple days ago Amazon published a short whitepaper on the considerations one might make when building a data center vs. using Amazon’s web services. In my experience most people use EC2 and S3 for their app, and the more adventurous people branch out into Amazon’s other services. Most people need storage and compute power, fewer people need Elastic Map Reduce.

Financially, for a small scale production or testing platform using the Amazon Web Services makes a lot of sense for a company whose core business is not IT-centric. Running a couple m1.small EC2 instances and paying for a backup to S3 or EBS is cheaper than purchasing a box and running the app in colo.

Since the start of the AWS platform I had the opinion that, as one starts using more and more EC2 instances and S3 storage space, there comes a point where it would be cheaper to bring the IT platform in house and hire a staff to run it instead of running on AWS forever. I have no idea where that point is, nor do I know of anyone with credibility who does. I thought the dollar amount where in-housing is cheaper is quite high.

I say those things in the past tense. At the risk of being accused of falling victim to Amazon propaganda, after reading the Economics of the AWS Cloud paper I think the expense of bringing a production app in-house for financial reasons alone is too great to overcome the benefits of using Amazon web services. What Amazon provides in terms of reliability, redundancy, management and scale can not be overcome unless you plan to compete with Amazon. This completely ignores in-housing due to compliance and auditing. AWS is not an option in that case.

The paper makes the argument that we can hit closer to 100% server utilization than an owned IT infrastructure. Though I’m not sure I buy this argument, idle CPU and unused memory are idle wherever they are, using a pay-as-you-go service implies someone might be more aware of hardware utilization because using more costs more in EC2. I guess the comparison is owning 10 boxes at 5% utilization vs. renting 2 EC2 instances at 60% utilization. Over 5 years renting EC2 instances at full price is cheaper than the capital expense of buying those 10 boxes.

The Power Efficiency and Enabling Redundancy sections of the paper are particularly important. Running a data center costs more than just the price of the computers in it. Power and cooling isn’t free. Rack space isn’t free. The investments Amazon can afford to make in improving power efficiency and data center design is much greater than most other data center owners can afford. If you can afford to make this investment you’re already operating at Amazon-scale – why aren’t you competing with them?

Based on the go-big-or-go-home data center, who should build data centers? CDNs, hosting providers, colo facilities and business that are subject to regulation? Is that it? As someone who has been using AWS and other hosting providers for years for small customers and doing hardware recommendations for existing, poorly designed, non-regulated company data centers for large customers, I’m partial to the AWS/hosted approach if there is not already hardware that can do the job on site. Hardware procurement in large companies is a nightmare and hasn’t changed since I started doing this.

So where are we headed with AWS? Are new tech startups going to forego hardware purchases and use AWS as their infrastructure? In the last year I have worked with a lot of people making that choice. What about existing small businesses? I haven’t done a lot of work where people are migrating away from their colo’d software and I don’t expect them to, at least until the next upgrade cycle. Upgrade cycle – that’s another thing Amazon handles “in the cloud” for us. Certainly a small business needs to be aware of the AWS option and I don’t have a lot of experience with the IT companies that small businesses out-source to.

Of course I expect (non-regulated) big business to continue building poorly designed data centers based on use-it-or-lose-it budgets. “Our team has 30 boxes sitting idle and we need to order 10 more!”

These were just some of my thoughts while reading the paper. Leave a comment with any feedback or your own thoughts on the Economics of the AWS Cloud paper.

Getting started with Mechanize

I think this will start a short series on black-box webapp testing.  This is just the first in a series and we’ll add quite a bit of content to it in the next week or so.

A weeks back I helped a development team set up a testing environment for their Ruby on Rails webapp.  The webapp is about 18 months old and had exactly zero tests.  Reverifying its intended behavior was a full time job for some of the developers on the team because there was no way to prove any behavior worked as intended at any given time.  Worse, behavior verification was a manual process and obviously error-prone.
(more…)

Dummy Code (Quick’n'Dirty vs. Engineered)

When creating software, two people will never write the same implementation of a method or system of non-trivial design.  Creating software is a problem solving process and there are usually many ways to solve one problem.  The solutions may differ in elegance and efficiency while giving the same output for a given set of inputs.  A correct solutions is a correct solution regardless of implementation. (more…)

Do you ever run your code? Another case for unit testing

A few of my most recent jobs have been with start-ups.  Working with a start-up can be stressful due to the urgency of getting to a product release.  Some of the employees of one particular start-up I worked with put in over 70 hours per week.  This wasn’t because they were under-staffed.  There were plenty of people to do the work but the company leadership was unable to come up with any sort of plan or priorities for the work.  What they had was people furiously working on projects that were irrelevant to the company.  Some people were working on projects that wouldn’t be needed for years, if ever.  One thing I recall about this company is that a lot of things were broken.

(more…)