Tag Archives: hacking

Defaulting to customizable

In Java, many of the the standard library’s objects have configurable settings, like timeout settings, boolean behavior flags, and so on. Sun’s documentation never says what these are set to by default. Does the timeout default to infinity? Zero? Thirty seconds? One hour? Is a new connection set to accept input, or output, by default? What’s the default buffer size of this object? Am I expected to write a little test program to figure out what the defaults are? Am I expected to grep through the Java standard library source code to find out?

On top of this, lots of the configuration values have getters, setters, and a method to set the default value for all future instances of that class for the lifetime of your application. This must have taken some time to implement. But did Sun bother to put the factory defaults in the documentation? No.

This is a classic example of over-engineering; Instead of focusing on choosing a reasonable default and writing complete, useful documentation to make the user’s (coder’s) life better, they focused on a level of configurability that is only rarely (if ever) necessary.

Internet, meet Spydentify

spydentify-400x107Spydentify is a new experiment/side project of mine. It fills a niche that I first identified over at the Typophile Type ID Board: people love looking a pictures and trying to figure out what’s in them. The site’s interface is designed to be as addictive as possible, with a neverending, rapid flow of interesting images, big, shiny buttons to click, and instant feedback on your actions. I’m going to add more ego-stroking, viral-spreading and moderation features soon.

The interface also follows the MVC pattern I laid out in this article. It uses one static HTML file, all dynamic data is loaded through XMLHTTPRequest (AJAX, for those of you who speak Web 2.0), and all HTML generation is done via JavaScript manipulation of the DOM. The backend uses Pylons, which gave me a chance to learn Pylons, Paste, Routes, SQLAlchemy, FormEncode, and Mako. And comments are rendered with my own PottyMouth.

I also designed the logo all by myself.

Check it out.

The next big thing, part 1: Resolving the conflict between Model-View-Controller and AJAX design patterns

or, how I learned to stop worrying and love the XMLHTTPRequest…

This is the first part of what will become an ongoing series.

If you’ve built a website in the last few years, most likely you’ve adopted an architecture similar to Model-View-Controller, or MVC. If not, well, either your website is terribly simple, you haven’t had to modify it yet, or your code is spaghetti and you should be fired. Just kidding. (Or maybe you’ve come up with an even better architecture, in which case you should share your insights with us mere mortals.)

In MVC architecture, the model reads and writes data to and from a back-end data-store, and organizes the relational data in a nice, hierarchical fashion to be used by the controller. The view accepts input from the controller and generates output HTML, XML, RSS, JavaScript, SVG, PDF, or whatever you want to send to the user’s browser. And the controller accepts browser input, figures out what to query the model for, and picks which view to use and what data to send it.

figure 1: The traditional MVC architecture.

Continue reading →

Why I’ve stopped reporting bugs to Ubuntu

I’ve largely stopped reporting bugs to Ubuntu because of the condescending and dismissive attitude from their developers.

I cut my Linux teeth on RedHat back in 1998, and soon after settled on Debian as the best of several flawed but promising choices of Linux distributions. When I switched to Ubuntu 4.10 in October 2004, I was excited by the promise of a distribution with the quality of Debian and frequent releases and a focus on the desktop.

Today I stumbled across what unfortunately seems like another typical example of what happens when you report a bug to them: aumix in Ubuntu 7.10 was compiled wrong, such that it won’t even launch. Recompiling the source package without making any changes to the source fixes the problem. Instead of just doing that, the Ubuntu developers spent far more time and effort bickering on the bug report and justifying their inaction by referring to official protocol. Shallow thoughts outlines the issues with aumix and contains this quote:

Continue reading →

First Impressions: Java

This is the first in a series of first impressions that I’m going to write each time I learn a new language or start using a new set of tools. I hope to keep track of what I thought and reexamine each in a few years. It will be interesting to see how my opinions change over time. This post is about Java. As I’ve been working in Python for the last few years, that colors my opinions about Java quite a bit.

Continue reading →

You’re a crappy programmer, your language sucks, and I’m better than you

I agree with all twelve of Damien Katz’s Signs You’re a Crappy Programmer (and don’t know it). I’d even add two more signs:

  • You want to reinvent the wheel.
    You look forward to implementing all the building blocks of your program without first checking for libraries and packages that can do most of the job for you. You are so excited about building an object-oriented email-sending library that you don’t even notice that the language you’re using already has all the email-sending functions you’ll ever need in its standard library. This is a failure to focus on getting the task at hand done, and it’s also a variation of talking just to hear the sound of your own voice. Get over it.
  • You use language constructs without really understanding what they are for.
    You use multiple inheritance from a large set of empty classes, or multiple empty interfaces, as configuration “flags” for your classes, and then test for the flag’s presence with issubclass(). Or you encapsulate related data into an object, and then write a function that takes that object as an argument and operates on it, instead of a method on the object. Or you buffer input and output between short strings and regular expression operations. You are just like those annoying people who simultaneously overuse and misuse some big word like obsequious or audacious. Get a manual, and learn the language you’re speaking.

Continue reading →

Revolutionary and wrong

What Larry Wall is doing (or has been doing, for the last seven years) with Perl 6 is revolutionary:

There needs to be a universal root language, and ways of warping that universal root language into whatever dialect you like.

It’s incredibly valuable to examine all the ways in which a (programming or natural) language can vary. I’m sure they’re learning a lot that will be useful to language designers everywhere. Perl 6 will undoubtedly be a great tool for quickly prototyping new languages, too.

It’s also wrong for a production language. The last thing I want in a programming language is diversely variable and configurable syntax and semantics. Sitting down to maintain or debug someone else’s Perl 6 sounds like a nightmare. Not only would you have to figure out what they are trying to say, you’d have to figure out what dialect of Perl 6 they were using, and exactly how that dialect works.

For this reason I’d tend to avoid Perl 6 for new projects, nor would I want to join a Perl 6 project mid-stream. If I had to work in Perl 6, the first thing I’d do would be to convince the entire team to stick to the standard dialect (or maybe some other, popular dialect) and never re-configure it.

I doubt we’ll see much traction for Perl 6 outside of research settings. The benefit of picking PHP and Java over Python or Ruby is that it’s easier to find PHP and Java programmers, than it is to find programmers for even the relatively popular Python or Ruby. Trying to find a programmer who knows not just Perl but Perl 6 and your dialect of Perl 6 is going to be even harder.

PottyMouth 1.0

PottyMouth, my tool for transforming completely unstructured and untrusted text to valid, nice-looking, completely safe xHTML, is finally ready for its 1.0 release. I’ve added implicit list support, which was the last feature I wanted to hold up 1.0 for. Read about what PottyMouth is and what it does here. And if you know someone who’s building a website that might need it, tell them about it.

I’m not going to say I told you so

The whole flap about Apple “bricking” unlocked and hacked iPhones with the latest software update reminds me of this article I wrote about Kaleidoscope in 2003.

I won’t say I told you so because I didn’t, exactly. (In fact, re-reading my article on Freshmeat makes me cringe; it’s a half-thought-out piece of naiive open-source evangelism.) But looking back, this is a story that gets repeated over and over again. It goes like this:

  1. A company releases a popular, closed product.
  2. A third party “hacks” the product and adds killer functionality via an undocumented, reverse-engineered API or infrastructure.
  3. A future update to the software eliminates the hack or alters the reverse-engineered API enough to eliminate the killer functionality.
  4. Go back to step 2.

I’m not suprised that this story is being repeated with the iPhone, because if there’s any company that’s extremely likely to take step 3, it’s Apple. Their entire business is based on total control of the whole widget, and they are doing a killer job. It wouldn’t be fair to expect them to even care about whether a new OS will break unofficial uses of hardware interfaces in the iPhone that weren’t documented or intended for third-party use.

It’s an old story, and I’m sure we’ll hear it again someday.