What consumers want is different from what makers want.

When DVD Jon was arrested after breaking the CSS encryption algorithm, he was charged with “unauthorized computer trespassing.” That led his lawyers to ask the obvious question, “On whose computer did he trespass?” The prosecutor’s answer: “his own.”

If that doesn’t make your heart skip a beat, you can stop reading now.

One particular angle about the iPad is that it’s a closed system.  As a developer, I tend to like open systems myself.  I can do whatever I want with it, and I can tinker with it. However, instead of complaining about apple, developers should do better work on open platforms.

Most products aren’t used to make more of itself.  Crowbars are used to open doors, not make more crowbars.  Pans are used to make food, not make more pans.  The person eating the food (consumer), and the person making the food (maker) are two different parties.  Part of the problem for general purpose computers that it serve two masters, the consumer, and the maker.  And each has different needs.

The consumer just wants things to work.  They’re trying to get something else done, so they can go home, make more money, raise their status amongst their peers, socialize with other humans, and ultimately get laid.  They’re not interested in tinkering because this is not what they tinker with.  Apple has shown that in order to achieve this, you need control from top to bottom of both the hardware and software stack, especially if you allow 3rd party developers running native code on a device.  If the days of Windows systems crashing were any indication, you shouldn’t trust any joe developer to have the same sense of quality as you.  

The maker, however, wants to be able to do with their hardware and software, whatever they want.  The openness of a platform allows you to learn, to play, to grow.  And it’s with this very sandbox and playground that you’re able to learn how to innovate the technologies of tomorrow, which ultimately drives our economy.  If many of us weren’t able to tinker and make things with the computers we used, it’s doubtful that many of us would be innovating as programmers and engineers today.  

However, part of the motivation for making things is so people can use what we built, and consumers can only use things where makers are making them.  In order for both to happen, makers and consumers have to be on the same platform, and therein lies the dilemma.  And thus far, Apple has leaned towards catering to the consumer, because they’re the ones that pay money.  That’s not to say everyone is one or the other.  I may be a web maker, but I’m a video chat consumer.  I don’t mind making web applications, but I hate futzing around with video drivers.    

So far web apps are the only thing that bucks the trend.  There, developers can make on open platforms, like linux, and the consumer with their browser are shielded from difficulties.  However, with a foreseeable future of different types of devices, native apps are going to be around on smartphones, tablets, and who knows what else.  Until wireless bandwidth is cheap, abundant, and ubiquitous, this will the case for a while.

The only way out of a closed system of native apps is to develop use-centric applications on open platforms.  Developers and engineers are going to have to care very much about design, aesthetics, and user experience.  Something that works and is simple.  This will have to start with developers being able to empathize with frustration and with others.  Instead of lamenting about how Apple has a closed system, develop really great, simple, easy to use, and useful applications on open platforms.  

How to add paths to your emacs shell

Actually this is probably because start-process can’t find your git

executable. Try doing something like this in your Emacs configuration

(adjust the path if needed):

(setenv “PATH” (concat (getenv “PATH”) “:/usr/local/git/bin”))

(setq exec-path (append exec-path ‘(“/usr/local/git/bin”)))

If you’re trying to use magit in emacs, and you can’t figure out why it’s not recognizing your git repos, it’s probably because it can’t find git. And it can’t find git, because it’s not in the path.

Just set the path, as it’s show above, and add your own directory, wherever git is being held. If you’re on a mac, you can add /opt/local/bin for the rest of your utilities.

Erlang mode on Emacs

Although there are a few other editors for Erlang, I prefer to use Emacs for Erlang and its the only major reason I use Emacs for. Erlang now has an eclipse plugin too, called Erlide.

Erlang comes with the emacs mode as part of its standard distribution, so you only need to customize your emacs settings to use the erlang mode. Once you have Emacs installed (I have Carbon Emacs on my Mac OSX), create a .emacs file in your home directory (or use the one that you already have).

$ vi ~/.emacs

Then insert the following lines of Lisp code into your .emacs file.

;Erlang Mode
(setq load-path (cons  "/usr/local/lib/erlang/lib/tools-2.6.1/emacs" load-path))
(setq erlang-root-dir "/usr/local/lib/erlang")
(setq exec-path (cons "/usr/local/lib/erlang/bin" exec-path))
(require 'erlang-start)

/usr/local/lib is where my Erlang is installed, and /usr/local/lib/erlang/lib/tools-2.6.1/emacs is the location where erlang.el and erlang-start.el files are, which actually define and initialize the Emacs Erlang-mode.

Update the path and version of the tools in the above code as per your installation, and enjoy the amazing features – including the Erlang shell right from Emacs.

Just something to remind me.

A REST service description language not a good idea

There's a lot of public data out there, and more being added everyday.  However, they're added in all sorts of oddball formats, like HTML in crazy formatted tables, CSV, PDFs, Excel files, etc.  For web services, at least the data format is easier to parse, like XML and JSON through SOAP and REST APIs.  

And there's no uniform way to access and parse all this data.

Even when you just focus on REST APIs, there's no uniform way to access all the APIs.  Right now, if you want to use an API, you need a separate wrapper library for each API.  Even though REST is simple enough that all you need are URIs and HTTP verbs, without documentation or a service description, you don't know what methods are available to you from the service.  Therefore, if you wanted to join data from two different REST APIs in a mashup, you currently need two separate wrapper libraries, then join the data in your application.

Taking a first crack at the problem, you might think that we should have machine-readable descriptions of these web services.  There have been some tries at that.  One is YQL, which treats the web as a database in which you use SQL-like statements to get and join data from REST APIs. 

Another is WADL, a machine-readable description of REST resources–like a WSDL for REST.  The idea is if you have a machine readable description of a resource, you can generate API wrapper code for it.  Then to join data from two different REST APIs wouldn't require two different interfaces. 

These two solutions have the problem of requiring programmers to write an explicit mapping of which service has which URI methods available, along with what parameters they take.  YQL uses a global repository of table mappings in a github repo to convert SQL statements to REST methods.  With WADL, it requires maintainers of the REST API to both update their API, their documentation, and a WADL file.  When the service API changes, the WADL/WSDL could be out of date, unless their web frameworks generates WADLs for them.  To my knowledge, none of the major web frameworks do such a thing.  

There's even a blog post by Joe Gregorio about whether we need WADL.  He says no.  I think I agree, though what he proposes is to have a limited number of service descriptors, the same way that we have a limited mime-types.  That way, when we see a web service resource description type, we expect it describe a REST API with certain methods, the same way we expect an image/png or text/html file to have certain properties and operators.  He may have something, but if descriptions of REST APIs are not the way to go, what's an alternative?

A simple guessing game in Erlang

Recently, I found out about a book called Inventing your own computer games with Python.  In it, there's a "Guess the Number" game.  Man, it takes me back to when I was toying around in GW-Basic.  I've been meaning to do Erlang again, and was going through Learn You Some Erlang for Greater Good, when I wanted a simple project to practice some Erlangian.  I had forgotten a lot of the basics, and this was a good way to get back into it.  Not a very fun game to play–maybe I'll try Bagels later on.  For now, it's just "Guess the Number".

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
-module(guess).
-export([start/0]).

start() ->
    intro(6).

intro(Guesses) ->
    io:format("Welcome to the Guessing game!n"),
    io:format("I'm thinking of a number between 1 and 20n"),
    get_guess(Guesses, random:uniform(20)).

get_guess(Guesses, Secret) when Guesses =< 0 ->
    lose_game(Secret);
get_guess(Guesses, Secret) ->
    io:format("You have ~p guesses left.n", [Guesses]),
    {_, User_guess} = io:read("What is your guess (end with .)? "),
    check_guess(Guesses, User_guess, Secret).

check_guess(_, User_guess, Secret) when User_guess =:= Secret ->
    win_game(Secret);
check_guess(Guesses, User_guess, Secret) when User_guess >= Secret ->
    io:format("The number I'm thinking of is lower. Try again!n"),
    get_guess(Guesses - 1, Secret);
check_guess(Guesses, User_guess, Secret) when User_guess =< Secret ->
    io:format("The number I'm thinking of is higher. Try again!n"),
    get_guess(Guesses - 1, Secret).

lose_game(Secret) ->
    io:format("You lost the game!n"),
    io:format("The number was ~pn", [Secret]).

win_game(Secret) ->
    io:format("You win the game! 🙂n"),
    io:format("The number was ~pn", [Secret]).

What's interesting is that basic process and components of the game map very well to each decision that must be made, so you don't need to use an if statement at all.  All you need are the guards for each function.  Also, the entire game state needs to be carried in the parameters of each function.  I can see how that can be a pain for more complex games.

Lorem ipsum for images in French Maid

Screen_shot_2010-01-26_at_2

Just yesterday, I saw a post on HN about the lorem ipsum for images, and I thought, "Hey kinda neat, but it shouldn't really require a server.  All you really need is a place holder."  So I decided to add it to French Maid, and it didn't take long…considering I was watching TV at the same time. 

French Maid is just a small little javascript wrapper library that injects common behaviors into web pages using unobtrusive javascript, based on jQuery.  All you ever need to do is set the attributes of html to standard html5 or microformats, and it'll give you some behavior that makes sense.  I started this because while working in Sinatra and Django, there wasn't built in javascript behaviors for templates like in Rails.  Turns out that was a good thing, but a bit annoying, so I wrote something to help me out.  

Lorem ipsum for images is the only non-standard in there right now.  When you're laying out a page, put:

1
2
<!-- Changes this into a div placeholder -->
<img class="lorem" data-size="200x100" />

And you'll get an image placeholder 200 px wide by 100 px height.  There's only a few options:

1
2
3
4
5
6
7
8
<!-- When you want to set the color -->
<img class="lorem" data-size="100x100" data-color="#ddd" />

<!-- Or when you want some other styles along with it -->
<img class="lorem" data-size="100x100" style="margin: 10px" />

<!-- Or if you want to override something -->
<img class="lorem" data-size="100x100" style="border: 0px solid black" />

This is pretty useful for having placeholder icons.  I usually spend lots of time picking icons when I'm laying out a page, when I really shouldn't be.  

I haven't yet made a homepage for French Maid.  Figured I would when it's more mature, but hey, if you're not embarrassed when you release something, it's too late, right?  So while I haven't gotten around to implementing all the microformat and html5 specifications, it's been useful so far, especially for standard pattern AJAX calls.  The screenshot is from the test/example/documentation page in the project.  You need Sinatra gem to run it.  Then just fire up the server by running the test file, then navigate to localhost:4567 and start clicking around.

Have fun, and if you find it useful, lemme know.  It'll be motivation to get a homepage up for it.

Getting a kid started with programming

I recently had a kid that wanted to program as well. He's about 12. Wanted to program games, but didn't get very far in a directX book.

I had a couple choices for him, due to some requirements: 

  • Something easy to install or didn't have lots of things to install 
  • Something with a all-in-one gaming library 
  • Something with some sort of community around it. 4) It'd be nice if there was a book for it.

So with those there, there was: 

Ruby and HacketyHack. http://hacketyhack.heroku.com/ It also has a app framework called shoes that you can use to build both games and apps. However, since _why left, all this requires a lot of hand hold to set up.

Lua and Love. http://love2d.org/ Lua is an easy language to pick up as it's pretty minimal, and love's 2D engine is pretty fantastic. I've used it before and it's pretty easy to get started with, and plenty of examples, as well as a vibrant community.

Python and Pygame. http://www.pygame.org/news.html Pygame has all of the above, and for me, the final winner, since there was a book that walks the kid along from basic text games to the graphics part. http://inventwithpython.com/ 

Just in case there are those of you out there that are looking for things to help out your little programmer.  Are there others you'd recommend?

Some of the best people are the ones you never hear about

“The superior doctor prevents sickness; The mediocre doctor attends to impending sickness; The inferior doctor treats actual sickness;” – Chinese Proverb

I remember the story was actually a little bit longer.  Since I can't find it on the web, I'll repeat it via oral tradition in an imperfect form:

As the story goes, a famous doctor was called a house to cure a sick wife/kid.  When he cured the disease, the husband/dad remarks what a great doctor he was.  The doctor looks at him and retorted, "Not at all."  When the husband asked why he wasn't a great doctor, since he was able to cure all sorts of diseases.  The doctor explained, "I have an elder brother who's a much better doctor.  He attends to impending sickness, but he's less famous because people don't call a doctor until they're sick.  And my eldest brother is the best doctor of all, but no one's heard of him, because he prevents sickness from happening in the first place."

Ever since I started trying to be a better engineer/programmer/designer/architect, I've looked for good hackers to emulate.  Surely someone else has figured out things that I haven't yet.  It's good to learn from them.  But where do you find them?

In the last couple of years, I've found that some of the best people are the ones you've never even heard of, often better than the self-promoting blowhards out there might seem like they're really good, but in fact, aren't that great.  Not that some famous programmers aren't great.  Just that there are ones you've never heard of that are really good too.

Just like a doctor that doesn't get famous for preventing sickness, a hacker doesn't get credit for removing code.

The fastest code is the one you don't run, the easiest code to understand is the one that isn't written.  As in graphic design, sometimes what's great about a solution is not what's there, but all the stuff that's not.  

This should be of no surprise to people working for a while with different types of people.  But it's hard to keep in mind, and makes hiring just that much harder.  Some of the best people aren't ones that wrote something, but knew what not to write, and attack the problem from another direction instead.

The bumps on the road to javascript

I’ll say it.  

The Rhino Book is a bad way to learn Javascript.  It often gets recommended as the de facto book on javascript, but it’s too much heft that doesn’t point out what really separates Javascript from other languages.

When I first heard about javascript, it was back in the 90’s, when most examples for it was to put snowflakes on the screen and trails of kittens that followed your cursor.  In the last 4 years; AJAX, jQuery, V8 javascript engine, node.js, server-side js with Rhino all contributed to javascript’s growth.  I’m picking javascript for client-side implementation because of its ubiquity, flash doesn’t have a future(1), and its ability to teach me something about programming.

I haven’t brought some of the newer js books like the good parts, or ninja, but I was able to spend time going over John Resig’s Advanced Javascript tutorial.  Resig is as much of a force for good for Javascript as _why was for Ruby, by being able to teach others.  I’d recommend going over that tutorial, as it cleared some bumps along the way I had about understanding basic parts of the language.  

Here’s some of them.  Maybe it’ll help someone else out.  I’ll keep ’em short.

Scope

Javascript scope had always tripped me up.  In languages like C, Java, and Ruby, scope was usually pretty apparent, because you can see it in the code, sectioned off by block delimiters.  Variables can see out, but they can’t see in.  In javascript, it’s the same, except this (or in other languages, self), changes when you call a function.  This was especially frustrating in cases where I was using map functions in javascript.  This would change inside of the anonymous block passed to map.   

There are already a number of scope tutorials on the web. I won’t repeat what they say, but what helped was understanding that This changes depending on who calls the function. Scope and context of this can be controlled on a function by function basis

Prototype-based Object Orientation

Reading the Rhino book’s Prototype based inheritance was confusing.  Instead, it was easier to think of javascript’s object model was more like how CSS worked.  You have an object that served as a template (or aptly named, prototype), and if you need to override any properties, you do so.  Anything missing is looked up in the prototype.  I don’t know why this was that hard.  It must have just been the name.  I thought it was something completely different.

Javascript has very few core elements

That you can use to build what you need.  At the core, there are functions, arrays, and objects.  All three of them have properties, thought of as ‘slots’ you can put variables, functions, arrays, and objects in.  What makes it more like lisp is that you can treat functions as data you can pass around, as first class citizens.  Javascript’s core minimalism really reminds me of Lua.  I much prefer Lua, and would have preferred it to be the lingua franca of the web, but Javascript is good enough for now.

That said…

Naked javascript really sucks.  Some mix of jQuery, Underscore, Functional, Prototype, MochiKit, or Closure should really be parts of the core language.  Without each, map, and reduce, I find having to write for loops to be a pain.  If people from multiple libraries are implementing the same basic things, that’s a good indication it’s a weakness of the language.  I’ll use for loops when I need to optimize something later.

Javascript is still missing some features from other languages, like tail-call optimization.  It’s like it doesn’t want to admit it’s a functional language (albeit unpure).  It also has no method_missing call.  Firefox has implemented a __noSuchMethod__ call, but it’s non-standard.  I haven’t found a way to replicate it with its current features yet either.

I’m sure there are others, but I haven’t gone deep enough into the rabbit hole yet.  I still find some things about javascript pretty grating, but the platform it sits on–the browser and the web–makes it pretty exciting.  

(1) When I say doesn’t have a future, it’ll still be around, but like the way radio is still around as a medium when TV and internet came around.

The hard part about unit testing

There are lots of things for people to argue over on HN.  When it comes to unit tests, I think that you should do it, judiciously, of course.  

I don't write unit tests when I'm sketching a program.  Or when I'm just playing and when I'm not sure if this is exactly what I want.  Sometimes, this is the case when I'm doing a feature as well, because chances are, the direction of the startup might change, so the tests and features that I write might not make the next revision.  

Along with that is the discipline to shape up and write the unit tests when you know that you're going to be stuck with the program and feature for a while.  It's far too easy to fall into the trap of not cleaning up a sketch.  I believe this is especially true when you're working on a code base with other programmers.  When you write a program, you're not just writing something for a computer to execute–you're writing something for your fellow programmers to understand.  Unit tests definitely help with that.  

The important thing is to know what your goal is, and write accordingly.  Just as in drawing and writing, you can draft and sketch, and then start checking the elements of style when you know this is exactly what you want.  

This morning, I read a Perler's attempt at making TDD like an addictive game.  It's a neat idea, as it keeps him in the "game" and has him bouncing back and forth between setting goals and meeting goals.  Looking at this workflow chart, I thought about how I did things and whether this worked for me.  

For the most part, I've stuck to the basic test framework Test::Unit, and it's worked pretty well for me as long as I was disciplined about it–use descriptive names, test one thing, keep it simple, etc.  But currently, as the codebase got larger and larger, I found that I hated doing tests, and that's lead to some minor bugs slipping into production.  Why was that?

Reading tests are a pain.  There is often too many details when doing assertions, and when you're just skimming code, they all look the same.  Tests are also rather repetitious.  Sometimes, you have a scenario that you want to test with multiple parameters, like access for different users for different methods.  You can either use cut and paste, which ends up with a lot of boilerplate.  Thoughtbot's Shoulda alleviates this somewhat by allowing you to have nested conditions.  Cucumber has a test matrix, but the whole system is usually more cumbersome than I need.  

But really, the most difficult part about writing tests is the setup.  Setting up the conditions of the program so that you can run the test.  Writing fixtures is a pain.

And reading this post about OOL, I realized that it held parallels in testing with machinist blueprints of activerecord objects.  

Joe Armstrong (Erlang) once said "The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

When you have a banana class to test, and you'd like nothing better to instantiate it.  But, in order to do so, you need to tie it to a gorilla, which in turn assumes that it's living in a jungle.  This is what's meant by coupling objects to each other.  It not only muddles up your design, but also makes testing way harder.  When you're writing constructors, don't rely on having other objects passed in as much as you can.  The only exception is when you're moving up a layer in abstraction.  

The less that you have objects that need each other to get started, the better.  Have defaults that make sense that the client object can adjust later.  To avoid having to create special objects, and use them as parameters, avoid having data classes and use hashes and arrays instead.  Just as Unix commands communicate by text, your class instantiations should communicate by arrays, values, and hashes.  Every object would know how to read them without instantiating and passing in another class object.  

I'm not exactly sure how to solve this testing problem.  While you can design around it with the coupling of your code, I'm sure it won't get everything.  Pure functional programming languages say they don't have this problem, but I don't have enough experience with one to know for sure.  For now, I'll architect my way out of it, but there should be a better way.