stephenwoods.net

This book title, though amusing, can’t possibly be submitted by the author or publisher. How did this happen? Social engineering, a hole in the api?

A screenshot in case they fix it:

Everybody loves web services. It seems like the perfect architecture, back-end (database) stuff is handled independently with front end servers communicating with the back-end via HTTP. The benefits of the RESTful way of building web apps are well documented elsewhere. The is one probably with restful architecture, especially is you are using php.  There are to major consequences of this, the first most obvious one is that when you are making web service calls your app cannot be any faster than the web service. If the web service is slow your site is slow.

There is another consequence that you won’t notice unless you get a lot of traffic. If your server is getting three requests per second or more you will notice that your cpu is suddenly pegged. For most people, when they get this kind of traffic they just buy more hardware, but if your site depends on web services they may be the culprit for all the cpu load.

It turns out that web service requests are actually very expensive in terms of cpu. If you use curl you typically use it synchronously, you make a request, wait for the response and then process the data received. This doesn’t sound difficult, but the trouble is that your os is not smart enough to notice that the thread executing php is just waiting, it can’t reclaim that cpu for other uses. So even though the php curl operations aren’t that much work for the processor they can quickly overload it.

There is an easy solution of course, and that is caching. On the server most developers know about caching pages. Unfortunately a lot of modern applications deliver a custom experience for the user that cannot be cached. But your web service calls can. Say you are making some sort of custom news page that aggregates a user’s favorite news and flickr feeds. You cannot cache the html output, because every user is different. You can however cache the rss feeds you are using to build the page.

This only works if the web service calls aren’t all different, which is why the rss aggregator is a good example. I assume that many of the feeds would be popular with lots of different users. My approach is to generate an md5 hash of the feed url and use that as an id for your cache, that way any time a user requests the same feed you know it and can serve it from cache rather than hitting the web service again. If you are on a low-traffic site or shared hosting plan the best way to do this is to just cache in the file system the same way you would cache a dynamic html page, just make sure the unique identifier for the file is that hash, and that you expire the cache often enough that the content is fresh, but not so often that you get no benefit from caching. If you have a high traffic site you already know that caching to disk is insanely expensive (php file_exists() is very expensive), so you will want to cache in memory. The good news is that APC (Alternative Php Cache) exists and is awesome. It is not as awesome as memcached (which is replicated), but it is what memcached is based on and for many cases it will be just as effective. When I just recently used this technique I actually did all my processing on the web service response before caching a serialized php object so I could save the time of doing that on every request.

The performance benefits can be amazing. And this is way easier to implement than memcached.

Once you get past the basics of Javascript managing the “this” keyword becomes more and more complex. For me, when writing object-oriented js, I often find it frustrating that methods are loosly bound to their objects. So If I pass a function pointer to somewhere else it is impossible to determine what object that pointer belonged to, because “this” might refer to a different scope.

I hacked together a very ugly solution to this problem:

    function scopeChange(func, obj){
        obj.temp = func;
        return function(){
            obj.temp(arguments[0], arguments[1], arguments[2];
        };
    };

Now, this is a crappy solution, because it breaks with too many arguments and it also creates a pretty ugly closure. Now, luckily I ran this by some people, and it turns out there is a much better way to do this, the “apply” method of the function prototype in javascript allows you to execute a function in the scope of a passed object. So the new “scopeChange” funciton will look like this:

    function scopeChange(func, obj){
        return function(){
            func.apply(obj, arguments);
        };
    };

Much nicer! Now how did I get this far in life without knowing about function.apply?

I am a gradiuate of the USC Film School, currently called “The School of Cinematic Arts”. I have never really worked in the entertainment industry, and of course now I write code at Yahoo!. Interestingly enough, another person in my cinema graduating class also does “internet stuff”, but I think he is somewhat more successful than I am.

Intel’s 45nm roadmap reveals that procs with the power of desktop CPUs are on their way to the mobile platform. The fact is all the old concerns about mobile development are quickly becoming irrelevant. These things will have plenty of power to run any web app you can throw at them. The issue will become not one of “making things work” on the browser, but making apps that will be usable for mobile users.

So, you like your job? I like mine pretty well and the reason is I haven’t followed these steps:

1. Office gossip is your friend. If you like your job now just listen to and believe everything people tell you. We are all getting laid off, they are moving the division to India, we are migrating to windows. Whatever they say, believe it. Then tell other people about it.
2. Make sure to worry about things you can’t control. Maybe you don’t like the backup policies of the finance team. Worry about that. Look up better tools. Angrily tell people that the finance team is using the wrong tools. Even better, if you aren’t in marketing, think of reasons your marketing is crap. Visualize the sales numbers dropping.
3. Get involved in office politics. Assuming everyone is saying bad things about you behind your back. Respond by saying bad things about them behind their backs. Try and get people on you side of an issue. Learn from Karl Rove: Go negative early and often.
4. Complain about everything. If you aren’t complaining out loud your new negative attitude is going to waste.
5. Assume other people are talking about you all the time. If there is a meeting and you aren’t invited, make sure to ask what it was about.
6. Blame people for things. If something goes wrong, someone should be blamed. Make sure you do the blaming.
7. Think up ways people with different jobs could do them better. Tell everyone about it.
8. If other people are unhappy, ask them why. Then agree with everything they say
9. Repeat this to yourself: you are underpaid. It doesn’t matter how much you make, you deserve more.
10. Find your company’s biggest competitor. Write a list of reasons they are better.
11. Look for a new job. But do not apply to the new job. You just need to think about how much better the other job would be. (note: if you screw this up and take the new job, return to step 1)

I think there are other techniques, but these are the best ones I can think of. The trick to hating your job is embracing negativity. Every job has annoying things. If you just ignore them and focus on the tast at hand you are probably just not going to start hating your job as much as you should.