I have to admit a mild addiction to Team Fortress 2 and Valve games in general. In another life I'd like to think I'd have made a great game developer* and I highly recommend the book Masters of Doom about John Romero and John Carmack's adventure from wayward hobby programmers to creators of the entire FPS genre. But what really attracts me to Valve games are their attention to game design as a science and the way they share their revelations with their customers.
Take the TF2 team's latest blog post about the upcoming Engineer update (for the uninitiated, the Engineer is one of 9 playable classes in this online-only first person shooter team game). They describe the thought processes behind continual improvement of their game:
The goal ... was to solve a perceived problem in the Engineer's play experience: always having to be tied to your base.
This is usually how we approach our game design: Identify a problem, then discuss the ways it could be solved. Our experience told us that even when the Engineer didn't feel immediate pressure, he still couldn't range out away from his base.
Importantly, not only do they test and refine ideas, they recognise when and why ideas don't work. They use these lessons to inform future improvements.
These may seem like obvious lessons, but knowing for certain why a particular idea doesn't work can often be as valuable as an idea that does.
These are lessons that can be applied to almost any programming design choices.
* Incidentally, the first programs I ever made were Basic A pick-a-path text adventures on XT machines. Goto 10 anyone?
Add your comment »
Jeff Atwood's recent blog post about the importance of cultivating teams rather than ideas drives home a point that has been repeating many times:
...instead of worrying about whether the Next Big Idea you're all working on is sufficiently brilliant, worry about how well you're executing
In more traditional industries you would probably say "...instead of worrying about whether your marketing budget is sufficient...". This shouldn't be clearer to Telecom by now. The shocking performance of their new XT network was, of course, preceeded by a marketing campaign that portrayed the network as fast, reliable and ubiquitous. The combination of raised expectations and dismal execution have only worked to further disillusion their customers.
There are shadows of Ferrit here. Telecom's foray into online shopping was a text book example of how ugly, difficult to use and largely unneeded website can defeat even the most exhorbitant television spend. Frankly, if your online product doesn't sell itself, it's not worth selling at all. Telecom should take a hint.
Add your comment »
This code snippet doesn't quite qualify as a Weecode at 150 characters, but it's a great demonstration of what can be done with a bit of jQuery and a blatant disregard for programming technique. This is a jQuery extension that enables AJAX content loading, with caching, on a valid link selector:
$.fn.cc=function(t){$(this).click(function(){
return!((d=(o=$(this)).data(h=this.href))?$(t).html(d):$.get(h,function(d){o.data(h,d);$(t).html(d)}))})
}
If you prefer a more - ahem - readable version:
$.fn.cc = function(t) {
$(this).click(function(){
return!(
(d=(o=$(this)).data(h=this.href))
?$(t).html(d)
:$.get(h,function(d){o.data(h,d);$(t).html(d)})
)
})
}
For example, the following code will tell links with the class "load" to insert the content at their URL into the div with the id "ajax-content":
$('a.load').cc('#ajax-content');
The first time the URL is requested the content will be loaded into the div. Subsequent calls will be loaded instantly, forgoing the unneeded HTTP request. This is particularly useful for pagination.
"But browsers can cache requests internally" you say. Well, yes, and no. Caching behaviour is unpredictable, and anyway, you're missing the point.
For the sake of completeness, a jQuery extension should handle library conflicts, the possibility that it will be auto-magically appended to other scripts, allow for chaining, and support failed AJAX requests:
;(function($){
$.fn.cc = function(t) {
return $(this).click(function(){
return!(
(d=(o=$(this)).data(h=this.href))
?$(t).html(d)
:$.get(h,function(d,s){
if(s=="success")
o.data(h,d) && $(t).html(d)
else
window.location=h
})
)
})
}
}(jQuery));
As an added bonus, you can cache requests before the user even clicks on the link. I like to pre-cache the 'next' link within pagination areas.
$.fn.precache = function() {
return $(this).each(function() {
o=$(this);h=this.href;
$.get(h,function(d,s){
if(s=="success") o.data(h,d);
});
});
}
Pre-cache content by:
Download the code here.
Or, for a much more readable version: use this file.
Add your comment »
JavaScript really is the hobbyists language. Everyone has two or three run-time environments sitting around, it has some interesting language features and it is genuinely useful. Of course, that doesn't stop people like me coming up with generally useless things to do with it.
And so I present: Weecode. Weecodes are JavaScript snippets in 140 characters or less - conveniently short enough for a tweet! If you feel like contributing, send your wee functions to @weecode and I'll post them back. At some point there will be a page here where you can vote and tag snippets.
I'm looking for particularly tiny, clever or obscure code. The fewer 'higher level' constructs you use the better (who needs a pesky Math object, anyway?). Does it appear to solve quadratic equations while calculating the volume of a sphere? Even better.
The idea is to show off your abilities, have fun and maybe learn something new along the way.
To start things moving, I've posted two "useful" functions:
Figure out the nth Fibonacci sequence number - 66 characters:
function F(n){p=0;n*=2;while(n--){p-=4/((n--)*(n%4-1));}return p;}
Calculate sin of x in n iterations (n > 6 is basically as good as Math.sin) - 105 characters:
function sin(x,n){n*=2;r=0;while(n--){for(i=(f=n),p=x;--i;f*=i,p*=x){}r-=(n--%4-2)*p/f}return r;}
Add your comment »
Wednesday Links:
- If you're feeling depressed about Auckland's long history of poor planning and miserable architecture, check out Auckland City Photos for a classier look at our fair city.
- Al3x, (of Twitter fame) reminds us why being a hero is bad for business:
Heroes are damaging to a team because they become a crutch. As soon as you have someone who's always willing to work at all hours, the motivation from the rest of the team to produce reliable, trouble-free software drops. The hero is a human patch. Sure, you might sit around talking about how reliability is a priority, but in the back of your mind you know that the hero will be there to fix what doesn't work.
- Google reveals it has been under attack by Chinese hackers. In the official post, Google all but accuses the Chinese government of attempting to hack into activists' accounts and announces it's intention to stop filtering Google.cn search results, even if it means the end of Google in China.
- Finally, goat teleportation bugs are exposed in a light-hearted Chromium bug report.
Add your comment »
I've had a few websites over the years, but this is a more cohesive effort to bring together various coding projects.
I've spent the sunny weekend split between listening to jazz in the Auckland domain, flying kites and setting up Subversion and Trac on a virtual server. It's been a fun weekend.
Trac is available at http://polemic.net.nz/trac/ and SVN is available via
http://polemic.net.nz/svn/. Not much to see at the moment, except for a set of Twitter widgets created for this blog.
Who am I? My name is Hamish, I'm a coder (PHP and JavaScript mostly) from Auckland, New Zealand. I'm involved in the GIS (Geospatial Information Systems) and SilverStripe communities in New Zealand, try to keep up with web standards and try to use Open Source software where possible.
Welcome to the new website!
Add your comment »
