JJinuxLand

Just because I have to use a callback-oriented style on the client doesn't mean I want to use a callback-oriented style on the server. Now, before anyone gets all upset and tells me that I don't know the difference between async and a kitchen sink, let me explain :)The client is necessarily an event-oriented place. If I don't know which button the user is going to press, it makes a lot of sense to use a different callback for each button. The server is different. If I'm waiting for the result of a database query before I can continue processing a request, it sure is convenient to just block and wait.My key point is that it's important to separate what style you want to code with and what performance and scalability characteristics you want. You shouldn't necessarily pick a callback-oriented style just because you want the performance and scalability characteristics of asynchronous networking APIs.My favorite two examples are gevent and Erlang, but Go is si…

I went to HTML5 Dev Conf yesterday. The following is a loose collection of my notes.First of all, the place was packed! Even the second-tier talks didn't have any standing room left over.The Backbone.js talk was especially packed. Not only could I not get into the room, I couldn't even get anywhere near the door. In general, Backbone.js was an extremely hot topic. However, most people admitted that they hadn't used it.Douglas Crockford's KeynoteJSON has no version number. "Everything with a 1.0 gets a 1.1 and a 2.0, and it's all crap until you get to 3.0, so JSON has no version number." He talked about the first browser, Mosaic. Some company patented an <embed> tag to embed content in a rectangle in the browser. He said that the company was a patent troll, and they went after everyone trying to make money. They figured their patent covered JavaScript, image tags, etc. Apple settled. M$ fought them for years. Yahoo finally led the defens…

I got into a discussion about code reuse with my co-worker, Jarek. I remember reading books on object oriented programming from a few decades ago in which OOP promised to increase code reuse. A lot of people doubted that serious code reuse would ever happen. OOP suggested that code reuse would be possible by reusing and subclassing existing classes. I even remember hearing C++ programmers talk about purchasing libraries of useful classes.To some degree, this did actually happen. For instance, QT is a wonderful library for C++, and it certainly makes coding in C++ a lot easier. It was even proprietary up until a few years ago. Library reuse also happened via language-specific package sites such as CPAN (for Perl), PyPI (for Python), and a range of sites for Ruby. Furthermore, most languages come with a lot more stuff built in these days. For instance, compare Python's standard library ("batteries included") with that of C.However, compared to decades ago, there i…

One thing that's great about a lot of video games is that you don't have to read any documentation in order to start playing them. I tend to play games on the Wii with my wife, and those games tend to teach you what you need as you go along.I think the same thing applies to user interfaces. Having to read documentation kind of sucks. Being able to learn as you go along is much nicer. A user interface that is easy to get started with is great, and one that teaches you on the fly how to become a power user is even better. For instance, I think that menus are a great way to enable users to discover new features. Menus that also show you the relevant shortcut keys are great because you become a power user by gradually memorizing frequently used commands. A user interface that does useful things automatically (assist and suggest) is the best of all (for instance, code assist).Another thing I feel strongly about is that a piece of software doesn't have to be hard to use i…

I gave a talk on Dart in Glasgow, Scotland. A big round of thanks go to my friends at Moviecom.tv and 29studios for not only setting up the talk, but also recording and editing it.

Unit tests don't find bugs. They find regressions. This is a painful lesson I learned when I first started doing TDD (test-driven development), and it's well known among most TDD circles.TDD's goal is to prevent programmers from introducing new bugs into working code. However, when you're writing code from scratch, your tests won't help you find all the bugs in your code. That's because you can't possibly write tests for all the ways your software will be used (or abused). When I first started doing TDD, I had really good tests, but I was too tired to do much exploratory QA. However, my boss wasn't, and I was very embarrassed to find that my software had lots of bugs. Simply put, he used my software in ways that I hadn't intended.I've seen a lot of companies that don't bother writing any tests or doing any QA. They just let their users find all the bugs. Needless to say, I've never had respect for those companies.However, it'…