Posts tagged Nerd
Using the abbr tag
Oct 2nd
Kroc Camen, long time OSNews reader and frequent IM buddy of mine, has an interesting piece examining the use of the <abbr> HTML tag. Kroc is one of those people who is very serious about the presentation and efficiency of his code, a trait I do not share, at least in practice, at least, to the same degree that he does, and it makes us good companions. My focus is typically on clean, fast, scalable code that forsakes beauty in favor of performance. My code, in the form of OSNews, has sustained a simultaneous Digging and Slashdotting, something of which I’m very proud.
But my CSS isn’t going to win any awards, my javascript could be collapsed a lot and made much more efficient, and my HTML often suffers from “div-itis” and “class-itis.” Enter Mr Camen, whose motto, “code is art,” is evident upon initial inspection. Kroc’s code is not only well written, the source itself is actually beautiful. We have collaborated on both CSS and PHP in the past and both are the better for it.
That said, we have strikingly different positions about publshing on the web. Kroc writes his website for himself, and as a result, publishes in HTML 5; his site doesn’t work in IE, his mindset being “if you choose to use a subpar browser, you will have a subpar experience. ” Indeed, his site is a complete mess in IE 7, the fault only of IE and its abysmal CSS support, not the code itself. I, conversely, attempt to code with a much more conservative bend, coding to the masses, at the expense of using several great tricks.
Getting back on track, when it came to discussing the <abbr> tag, both of us found ourselves remarkably on the same page. Although one can get into the nitty-gritty details and find the whole conversation trivial, I think there’s something to be said for using tags properly and getting your information properly parsed. After all, screen readers exist with regularity today, XML is very popular (most commonly in the form of RSS), and search engines spider the majority of popular websites several times times a day if not every hour. Using tags, and using them properly, should be important to content publishers and republishers.
I also agree with Kroc’s point that it’s not your job to educate your reader like an encyclopedia. The <abbr> tag is not so much about education as it is about properly marking up your code.
As the second wave of the browser war heats up – as Tracemonkey, Squirrelfish Extreme, and V8 start really setting themselves apart from IE in even larger ways, coding to standards will become even more important. Understading lesser used tags is elemental in writing the best, most concise code and ranking well in search engines.
PHP Weirdness
Aug 14th
Beware: this post is definitely not for the feint of heart. It includes a lot of code. You have been warned.
I wrote an application some time ago for my company that looks up the longitude and latitude of an address for use in our geocoding initiative. It relied on yahoo_geo(), a function written by PHP creator Rasmus Lerdorf and the Yahoo Maps API. It was largely dependent on this function:
function yahoo_geo($location) { $q = 'http://api.local.yahoo.com/MapsService/V1/geocode?appid=rlerdorf&location=' .rawurlencode($location); $tmp = '/tmp/yws_geo_'.md5($q); request_cache($q, $tmp, 43200); libxml_use_internal_errors(true); $xml = simplexml_load_file($tmp); $ret['precision'] = (string)$xml->Result['precision']; foreach($xml->Result->children() as $key=>$val) { if(strlen($val)) $ret[(string)$key] = (string)$val; } return $ret; }
This function worked for over two years for us with no problems at all. Then suddenly, in the last month, it started getting spotty. I fixed things by commenting out the caching parts of the function and forcing each execution to run again. Then I got errors about the libxml_use_internal_errors() function, so I commented that out. But today, the function just flat out failed, every single time returning the same error:
Warning: file_get_contents(http://XXXXXXXXXX/XXX) [function.file-get-contents]: failed to open stream: HTTP request failed! in /home/intranet/html/fetch.php on line X
What the heck? This code is all over the web. I’ve tried a million permutations of this function, including using fopen() and ob_get_contents(), and none have worked. And most frustratingly, I could load the URL successfully in Lynx and eLinks, so the machine could quickly and easily fetch the URL.
So I ventured into a sandbox I’ve never really played before: cURL. cURL is an interesting animal. But the interesting thing is, once I got it working, it worked faster than ever! So, without further ado, here is the new and improved yahoo_geo() function:
function yahoo_geo($location) { $q = 'http://api.local.yahoo.com/MapsService/V1/geocode?appid=rlerdorf&location='.urlencode(trim($location)); $ch = curl_init($q); curl_setopt($ch, CURLOPT_HEADER, 0); ob_start(); curl_exec($ch); $stream = ob_get_contents(); ob_end_clean(); if($stream) { $xml = simplexml_load_string($stream); $ret['precision'] = (string)$xml->Result['precision']; if($xml) { foreach($xml->Result->children() as $key=>$val) { if(strlen($val)) $ret[(string)$key] = (string)$val; } } curl_close($ch); return $ret; } else { return FALSE; } }
Note: If you’re reproducing these functions elsewhere, be careful – WordPress may have converted the quotes into smart quotes that will need to be fixed before this script will run properly.
OSNews vs. WordPress
Aug 13th
I’ve spent quite a bit of time, over the last 5 or 6 days, diving into WordPress and learning what makes it tick. Parts of WordPress are really impressive – just flat out cool. The way some of it works is fairly complex and deciphering it sometimes means reading page after page after page to understand an entire routine. But sometimes, when you finally see, end to end, how something in WordPress works – I mean really see individual bits of the engine – you have to admit it teaches you a little about PHP. WordPress, underneath it all, is a pretty big beast and its strength and ubiquitous presence comes largely, I think, from the fact that it can do virtually anything. The really sweet plugin system, the ways hooks work, “The Loop,” the dynamic options panel – it’s all very educational.
The interesting thing here is that I’ve browsed the source of Slash, Scoop, phpNuke, and now WordPress, and all of them are definitively more complex and much heavier than the entire OSNews codebase. Now, before you jump all over me – firstly, Slash and Scoop are Perl, and I don’t really read Perl, so I can’t speak as an expert there. Secondly, WordPress and Nuke both are very portable and dynamic, whereas OSNews has a narrow focus and, location-wise, is very static. But that aside, OSNews has withstood simultaneous link bombs from Slashdot and Digg. As amazing as WordPress is, it’s mostly amazing that it functions at all and loads in less than 2 minutes per page with as much going on as I can see behind the scenes. That’s not a cut on WordPress, by the way.
In fact, if anything , what is really impressed upon me is how smooth and simple OSNews code is, if I may be so bold. OSNews runs superfast due, in part, to lots of creative caching, some on-demand, some via cron. But it also does so because of highly efficient queries that are measured for speed on their JOINs, meaning in some cases, it’s faster to do 20 simple queries than one complex one, or build a long and scary chain of “OR x=a OR x=b OR x=c OR x=d…” Watching WordPress code in action is really fun for me, but watching OSNews work knowing what I now know about how much work PHP can cram into its threads is even more fun.
Math in Real Life, Part 1: Fruit Algorithms
May 21st
I recently went to Costco and bought a rather large tub of blueberries. I am a huge fan of blueberries – in fact, the engine of this blog was once named “blueberry,” – and I am a huge fan of fresh fruit in general. While picking from said tub, I mentioned to a friend that as I munch away, I frequently scan the entire viewable area of berries and quickly select the “best” one in view for my next berry. I do this not just with blueberries, but with strawberries, raspberries, blackberries… in fact, I probably do it with many more foods. But in this case, we did an experiment, which goes thusly:
Shake a tub of berries so it’s a fresh “layout” and have a friend peruse it. Then, you each reveal the “best” berry – the one you’d go for if you were choosing. The first FIVE throws we matched 100%. The next few took us up to two or three picks to match. But the fact remains, we agreed that as we ate, we’d do a quick scan – all in an instant, of course, the deliberation is almost entirely subconscious – and choose the best remaining berry/berries. And furthermore, in the first five throws, we were able to agree with no debate as to which was the best remaining berry, without defining what qualities should be prized in an assessment of “best.” I think many people do this, and not just with fruit, but with all sorts of things. Is it just human nature?
There you go: math in real life.
An Argument for PHP
May 11th
Currently, over on Slashdot, there is an article on forthcoming features in PHP version 6. And, like most PHP articles, the comments section is flooded with jackasses arguing that PHP sucks as a language. I get frustrated by the entire “PHP sucks” campaign, largely because it’s like the HTML e-mail argument – mostly driven by the fact that it’s stylish to hate them – but I’m going to go further. I argue than everyone posting about how PHP is a bad language as a whole is an idiot. Every single one. Each is a foolish, arrogant, nerd sheep who can’t think for themselves. Update 5/14/08 20:39 UTC: Okay, this piece was linked by several sources, and the truth is, I had just read some George Carlin, so I was probably more aggressive than I intended to be. What I really mean is that people posting about how PHP is a bad language as a whole without citing any reasons are generally following a trend, trying to look cool, or too narrow-minded to be considered credible. And the responses I’ve seen across the net have, thus far, supported this argument.
Why? Let’s argue for a second that everything people say about PHP is true, as many of the complaints are sound.
It’s true the primary namespace has way too many functions – over three thousand, I’m told. It’s true that the function names are inconsistent, some have underscores, some don’t. It’s true that the function names are often verbose. It’s true that OOP was weak until recently, it’s true that register_globals was a security nightmare. All those things are potential issues, and all languages have them. As the “real programmers” who write Perl would never admit, reading other people’s terse Perl is often a f’ing disaster, even for seasoned Perl-ites. And when using compiled ASP.net – for best performance, natch – you must update your entire site (well, all the concerned ASPX pages and DLLs) to make elementary changes.
That said, PHP is easy. Really easy. And it’s a trivial task to get a website up and running fairly quickly. And you can serve enormous amounts of traffic as proven not only by OSNews (who have been dugg and Slashdotted concurrently), but by Yahoo!, Wikipedia, Flickr, Facebook, and many, many others. And why are there so many open source PHP frameworks, apps, CMSes, etc? Because PHP is installable virtually everywhere, it’s very portable, and it’s really simple to hack up. Try installing something dependent on mod_perl (e.g. Slash or Scoop) and get back to me on the ease of the install.
The fact is, even if everyone’s fears about writing insecure code is true, the ability to make mistakes does not mean everyone does, and those who would forsake “the right tool for the job at hand” shouldn’t be trusted even to water your plants, because they are obviously nitwits. If you can’t concede that PHP can be the right tool some of the time for some situations, you shouldn’t be trusted to code or make adult decisions. No, I argue that the reason they dislike PHP is because many start with PHP and thus, admitting to liking it would make them appear to be a “noob.” It’s because they must appear to be seasoned pros. It’s the bragging rights on the 21st century.
Nobody has ever claimed PHP is the solution to everything, but it is a remarkably easy tool for scripting dynamically generated HTML. And, in my opinion and experience, it does so better than Perl, better than Ruby, and a hell of a lot better than both ASP.net and JSP.
Dope Wars for the iPhone
Apr 30th
I love my jailbroken iPhone, and I am always looking for a new “game of the week.” I’ve been through several, at first, it was LightsOff, but that ends at 225 levels or so. Then it was Five Dice. Then 4 Balls, Domino, and finally PuzzleManiak. I was so happy recently when someone decided to port Dope Wars to the iPhone in the form of “iDope.”
iDope currently has a lot of bugs. Mainly, your jacket storage is irrelevant, you can actually store unlimited items, you just can’t buy unlimited items unless you hit “buy all.” You can’t store money in a bank. It never ends until you die. You are mugged or fight the cops maybe 80% of the time you travel. But most importantly, this:
Notice my dollars? That’s right, I have $2,147,483,647. Two billion, one hundred forty seven million, four hundred eighty three thousand, six hundred forty seven dollars. Recognize that number? If you read my blog regularly, you might. After all, it’s the upper limit of signed integers. The game is officially boring – no matter what I do, I’m always capped at that number, I can never get more money. I wonder if the iPhone can support BIGINT.
Anyway, I really hope to see iDope get some love and attention, because Dope Wars is a fabulous and addictive game, but as is, I eventually get to the upper limit and have to start over… and over… and over.
Slashdot: Slowing Rotting from the Inside Out
Apr 28th
Sometime ago, say, 1999, Slashdot was the king of the online tech world. In fact, from a “hits” standpoint, they may still be, if not second to Digg. Slashdot has always been the first big blog-style tech site, long before the word “blog” meant anything to anyone, and somehow, Rob Malda and crew are still relevant in the scene.
Not too long ago, Slashdot started overhauling their incredibly horrendous HTML and rewriting in mostly compliant HTML. The goal of the rewrite, amongst many other things, such as incredible bandwidth savings, was to support stylesheets and graceful degrade. When all was ready, Slashdot held a contest to solicit new stylesheets and received tons of submissions, some really cool and others really ugly, and chose a very nice, very reserved, very modern-but-conservative one as their new default style.
Let’s back up a bit: Slashdot is written in Perl – ack! – and is built upon an open source system called, simply enough, “Slash.” Slash code is horrendously out-of-date and the last download is pathetically old. In fact, the only way to get Slash in any recent form is via CVS access. Slash requires mod_perl and tons of Apache and perl customization. Since Slash is tried-and-true, it’s not really “new” code. And it shows in many ways.
Not too long ago, the Slash folks started realizing that new technologies and new sites were introducing amazing interactive features. Perhaps they realized when a chunk of their userbase got fed up and left for sites like Digg, Techcrunch, Mixx, or some other aggregation type site. Nonetheless, the Slash team started hacking in features that emulated many of the Web 2.0 sites. First it was tagging. “Taggging” has been in beta for some time now. It allows users to arbitrarily tag a story with keywords. The FAQ says that once enough people use a tag, it shows up as a suggestion for others. But I always see weird tags suggested. Either way, it’s pointless, because I don’t know what good tagging does for me.
Then came the “firehose.” The Firehouse is essentially Slashdot’s answer to Digg. The diea is this: users submit stories, links, bookmarks, journal entries, etc, and other users vote on the stories. As the stories get “warmer,” or redder, the entries because available to the editors to convert into real news items. Neat, huh? The idea is cool, except the interface is nowhere near as dynamic or alive as Digg’s, and the content doesn’t rotate as fast. And the load time hurts. So I never use it.
In the last 6 months to a year, Slashdot began rolling out “D2,” their new dynamic discussion system. It is a replacement for the static comment system of days past. The problem is multi-fold, however. Firstly, the layout is a screaming nightmare. There is so much whitespace and what is there is totally overwhelming. Big garish buttons take the place of links or real buttons. Dynamically fetched text takes many seconds to load, even generic insertions like a comment form takes 5 seconds plus to appear. Slashdot has become flat out slow. And D2, which should have remedied a lot of that, has not lived up to its promise.
All the places where things got dynamic on the site feels like a new paradigm being smashed into old code. I wonder if Slashdot might be better off rewriting the entire engine as version 3.0. I know that sounds scary, but when OSNews was starting to feel the pain, we ditched the entire front end and rewrote it – every single line of PHP and HTML and CSS and JS. A combination of creative time-based caching, caching on request, and sleek, optimized queries resulted in a snappy and very responsive front end with smooth ajax integration, a super fast loading page (minus the ads, subscribe today!), and a zero lag experience. The differences between the v3 backend and v4? None. If you exclude new features we built in (news tags, extended user preferences, and conversations), the backend is exactly the same.
Slashdot’s database likely won’t have to be dumped or modified at all to rewrite all of their Perl and Javascript/Ajax. But it might result in a faster, smoother, nicer looking front end. It’s time to reel in the speed issues – the entire site takes forever to load (a 200K front page plus externals doesn’t help). It’s time to fix the ajaxian display weirdness. It’s time to get your JS working well in Opera. Fix those and then perhaps we can deal with the elitist userbase.


