Gadgetopia

Picosecond : A picosecond is pretty fast – one-trillionth of a second.  As a point of reference:

330 picoseconds (approximately) – the time it takes a common 3.0 GHz computer CPU to add two integers

So, your addition operation requires one-third of one-billionth of one second.  If you had optimized correctly, you wouldn’t have incurred this penalty, you hack.

80legs : Interesting service – a Web spider for hire.

80legs is a service platform for crawling and processing web content. Our service is very powerful and very affordable. […] Crawl up to 2 billion web pages/day. […] Only $2 per million pages crawled and $0.03 per CPU-hr used.

Why I switched from PHP to Python : Here’s the best description I’ve heard yet for why PHP is the way it is (emphasis mine).

What makes PHP, as a language, awesome is also what makes it horrible to work with, which is that it’s not really a language, but rather a giant plugin architecture for exposing lower level libraries in a high level fashion. Most of the language that developers use are, in fact, thin wrappers around popular C functions (curl, mysql, gd, etc.). Most of the time these libraries’ functions are simply exposed as-is. Anyone who’s coded curl in C will feel right at home while using curl from PHP. The problem with this is it leads to wildly inconsistent API’s.

The whole article is a great comparison of Python and PHP.  Worth reading.

I’d like to learn a new programming language, but I’m struggling with what to learn.  My experience has been in procedural (VBScript, crappy PHP) and object-oriented languages (C#, good PHP).

The temptation is to learn something like Python, but it’s just another OO language really.  There are syntactical differences, but, in the end, the paradigm is the same.  Sure, Ruby has some syntactical sugar to it, but it’s still from the same bloodline.

I’m thinking about going way, way out on a limb…

• Lisp
• Scala
• Erlang
• Prolog
• R
• Processing
• Smalltalk

I want something that’s going to make me look at programming from an entirely different direction.  Any recommendations?

C# is now a better language than Java: Interesting post from a Java programmer and self-admitted Microsoft hater.  Whether or not you like ASP.Net, C# is a fantastic language.

But Java, the language, depresses me lately. It’s being left in the dust by other languages. Scala, my current favorite language on the Java VM, incorporates many newer (and some not so new) ideas that have yet to find their way into Java.

Worse, though, for Java enthusiasts: Java has fallen behind C#. […]  Sun and the Java community have allowed Java, the language, to stagnate to the point where, compared to C# and Scala, it is almost painful to use. As a long-time Java programmer, I have to say, that makes me a little sad.

Seaside: Your Next Web Application Framework: This is a look at a Web framework written in Smalltalk.  Now, I know, we need another framework like we need a hole in the head, but what I found really interesting was at the top of page 2 – a discussion of “continuation-based programming.”

Consider:

[…] instead of having to throw away or explicitly save all local state after a web page is generated and recreating it all again on the next hit, you can pretend the web isn’t even involved.

They provide this code sample, which is pretty easy to figure out, even if you don’t know anything about Smalltalk.

Here’s an explanation:

[…] this code reads almost exactly as what it’s doing: Show the first page (probably containing a form), and when the page is submitted, determine if the form elements are valid. If not, keep showing the correction page until it comes back correct. Finally, show the last page.

Simple enough, but consider this cool part, which essentially says that the system is able to toss back HTML in the middle of execution, then pick up where it left off when the form is submitted.

showFirstPage is clearly returning a pile of HTML back to the user (using canvas and brushes like we saw earlier). But as the page is being returned to the user, Seaside notes that it’s about to execute the second line of this method and transparently arranges for the form submission to restore this method execution right at that spot.

The Web Curriculum: I love Tim Bray’s idea for a Web-centric college curriculum.

I propose that the World Wide Web would serve well as a framework for structuring much of the academic Computer Science curriculum. A study of the theory and practice of the Web’s technologies would traverse many key areas of our discipline.

I’ve long-maintained that a CS degree doesn’t prepare people as well as it could to work on the Web (if that’s where they want to end up).  I’ve interviewed several people with CS degrees that just had no concept of what working on the Web meant or the skills they needed.  We almost need a CS degree with an emphasis on Web technologies.

Tim proposes courses like:

• Web 101: Architectural Introduction · Core idea: Teach what happens when you click on a link and a page with some multimedia and personalization is rendered for you.
• Web 230: User Interfaces · Core idea: Survey UI issues, but assuming the browser as a delivery platform, to put the focus on the content not the technology.
• Web 340/440: Persistence · Core idea: Study the issues surrounding persistent storage of data
• Web 470: Issues in Large Distributed Systems · Core idea: Study problems that arise in systems much too large for a single computer.

There are quite a few more behind the link.

SQL Databases Are An Overapplied Solution (And What To Use Instead): Another rant on how we all need to start looking beyond relational databases.  The author presents some good options for alternatives and when to use them.

[…] developers [find] themselves reaching for the SQL database for any job at all. It’s the default, the catch-all for storing nearly anything the application developer can think of - and even some things that aren’t data storage at all. When all you have is a hammer, etc.

Overapplication of the solution has given SQL databases a bad rap. Instead, let’s shift our thinking: use SQL databases for what they are good for, and select a different tool for other kinds of jobs.

No to SQL? Anti-database movement gains steam: This is a really good article about how relational databases are falling out of favor with many, in favor of “alternate” datastores like key-value databases or XML databases.

Like the Patriots, who rebelled against Britain’s heavy taxes, NoSQLers came to share how they had overthrown the tyranny of slow, expensive relational databases in favor of more efficient and cheaper ways of managing data.

“Relational databases give you too much. They force you to twist your object data to fit a RDBMS [relational database management system],” said Jon Travis […]  NoSQL-based alternatives “just give you what you need,” Travis said.

In Chicago, the big vibe I got was that content management in general is moving away from relational databases and towards XML databases, like Xindice, eXist, Mark Logic, etc.  It’s weird, and will take some getting used to, but there are some huge advantages to it.

Here’s another article along the same lines: Should you go Beyond Relational Databases? It covers things like CouchDB, MapReduce, BigTable, etc.

And if you’re really in for something funky, I present you with Caravel, a CMS that uses LDAP (a key-value store, at heart) as its storage mechanism.

Even if you swear you’re never giving up your relational database, read these articles for some perspective.

So, Eric Higgins from Google posts an article called PHP performance tips in which he presents all sorts of ways to supposedly make PHP execute faster.

In response, Gwynne Raskind from the core PHP team, responds with:

[…] all of the advice in it is completely incorrect. We at the PHP team would like to offer some thoughts aimed at debunking these claims, which the author has clearly not verified.

Gwynne then proceeds to debunk Google’s article, piece by piece.

The example the author gives results in absolutely no significant use of extra memory […] This is exactly the opposite of correct advice. […] this piece of advice is total nonsense […]  We also urge the author to consider the troubling security implications of his examples, at least one of which suggests an extremely dangerous coding style.

Awkward (said in a happy sing-song tone).

Hidden Features Of [insert language here]: This is a collection of one of the neatest community-driven features of StackOverflow.  This guy explains it well.

[…] one day someone at StackOverflow started a “Hidden features of” post about a famous language (I don’t feel like finding out which one was first exactly), and it turned out to be so popular that other posts in the same series started popping up.

Such questions were quickly turned into community wikis, for the purposes of harvesting and organizing information coming from the best developers on the planet and voted by users of the site. There are literally hundreds of answers, sorted by votes.

Your language is probably in there.

www.phpwtf.org: PHP haters rejoice.  A PHP annoyance, posted every day.

LESS - Leaner CSS: This is so necessary.  It’s an improved, lighter CSS syntax that you store in your source, with a compile (more like an “expander”) that generates actual CSS for deployment.

Less is Leaner css. Less extends css by adding: variables, mixins, operations and nested rules.

Less uses existing css syntax. This means you can migrate your current .css files to .less in seconds and there is virtually no learning curve.

I could see building this expansion into a build script in Nant or CruiseControl or something.

PUT or POST: The REST of the Story: A good word to know.

The crux of the issue comes down to a concept known as idempotency. An operation is idempotent if a sequence of two or more of the same operation results in the same resource state as would a single instance of that operation.

Good article too, if you’re an HTTP protocol geek.

If you work with a development platform enough, you develop some weird, imagined relationship with the platform’s development team, even if you never meet them.  In working with the fruits of their labor day-in and day-out, you develop some mental picture of them, their general competence, and their mental processes.

Let’s consider two hypothetical platforms —

• Platform A is a never-ending pain-in-the-ass.  It never works how it should, it constantly drives you nuts, and it makes you want to throw your computer out the window at regular intervals.  It’s a mess of dead-end code, trainwreck APIs, and inexplicable architecture decisions that leaves you shaking your head in frustration a dozen times a day.
• Platform B is a joy to use.  It’s simple, it’s powerful, and there’s a background elegance to it that you identify with.  Every development decision slots neatly into the others, and the parts work together intelligently.  The platform becomes a force multiplier for you – your talents and capabilities are magnified by the elegance and intuitiveness of the platform, and you have success after success developing with it.

With either platform, you start to have visions in your head of the people who developed them.  The developers of Platform A are a bunch of barely-literate monkeys that couldn’t code their way out of a paper bag, and the developers of Platform B are Gods in Aerons – kings of programming that graciously cast their benevolence down on you.

I’ve worked with both Type A and Type B platforms extensively (sometimes both in the same day).  It’s made me understand how much of development is what I’ll call “feasibility speculation” and what effect those platforms and imagined developers have on it.

With development, and with content management especially, a lot of what you do is speculating whether or not a goal can be achieved.  So many conversations with clients start with, “Can we…” or “Is this possible…”  You need to draw together everything you know about their platform and figure it out.

In doing this, you often sit around and think, “Would the developers of Platform X have thought of this requirement?  Would they have accounted for it?”

With Platform A, your default answer becomes “no.”  You just assume that the people who built the platform would never have thought of that.  Their product has kicked you in the teeth enough times, and that you’re not even willing to put in much research time to find out.  If you do decide to research the problem, much more likely to give up early, because you just don’t trust it anymore.

With Platform B, you’re default answer becomes “yes” or something along the lines of “I’m pretty sure we can do that…” because you just know it will work.  You have this vision in your head of the developers as being competent and benevolent, so you just know they would have thought of just this situation.  Furthermore, you’re willing to put in some time to research the situation, because you have a great expectation of success.  When you do research, you’re very persistent because you know the decision is likely right around the next corner.

It’s this imagined relationship between you and the platform developers that drives success or failure.  Once a platform betrays you enough times that you stop trusting it, that’s tough to come back from.  They might make an improvement or two to the system, but there will always be this background uneasiness that the next disaster is right around the corner, and you should keep your expectations as low as possible.

It comes down to respect in the end.  Your opinion of a platform is, in large part, a reflection of the respect you have for the people that built it.  Once they lose your respect, your ability to do anything with their software is vastly reduced because your heart’s not in it anymore, and you’re not willing to give them another chance or the benefit of the doubt.  Your attitude sours, your expectations drop, and you stop believing that the platform can ever make you happy.

From there, it’s an almost impossible road back.