Yeah, I use Google Wave to 'sign off' on informal agreements

Yeah, I use Google Wave.  I honestly don't know what everyone else is talking about when they say they don't know what it's for.

Ian and I don't talk on the phone about Graphbug maybe as much as we should.  There's a number of reasons for this, but as a result, we mostly communicate over Google Wave, which also serves as documentation for us.  

It's better than email for communications that's consistently about something specific.  We know what the other's doing code-wise, through pivotal and commit logs, and things outside of code, we update in a google wave.  Or if we have a spec that we need to hammer out, it's better to do it through wave.  It's more like a real-time wiki in this sense.

But we also use it to "Signing off" on informal agreements.  We'll type up a set of bullet points and keep editing and arguing about it in the discussions below the main wave.  The threaded nature of a wave keeps arguments and counter-arguments on target.  And then when we're both in agreement, we sign the bottom of the top wave (with all the bullet points) and the date.  

Because you can replay a wave, and that history doesn't change, we can be sure that neither one of us changed the bullet points after we've 'signed off' on the agreement.  

Of course, there's nothing verifying the authenticity of the signature (meaning we can't verify who signed it), only that it's signed at the right time.  There's probably a way, but for just us, just putting our names and date down is enough.  Given that there's only two of us we know who signed what name.

Tip!

Posted via email from The Web and all that Jazz

It sucks to visualize public data

A while back, I made a graph overlaying the senate party majority with the national debt. While correlation isn't sufficient for causation, I did learn a lot about the shape of the national debt as well as assertions between political party and national debt is not as clear cut as political commenters and pundits would like you to believe.

However, the entire experience of producing the graphs in those blog post left me dumbfounded with how tedious it was just to see the shape of the data.

First, finding the data was difficult. Many of the census bureau and government websites have confusingly bad user interfaces. It took me a while to figure out how to find the number of single females by year and state. Go ahead, try it.

Once you've found the data, you need shape it into what you need for the visualization, which is difficult because data on the web is in a sad state of affairs. Images, video, and text on the web are limited to a few popular formats. Not only that, the actual format is abstracted out with an image tag--and soon to be video tag--by the browser or flash. No widespread consensus exists for raw data, with the exception of a limited number of domains dictated by microformats, KML, and its ilk. Many publish data through html tables or CSV files, which comes in surprising variety of hard-parsable formats.

Then, it was tedious simply finding a free visualization tool that produce moderately good looking graphs. There are a plethora of javascript graphing libraries, not to mention flash libraries like amcharts and flare, each with their own strengths, weaknesses, aesthetics, and ramp-up time. It took a while to pick the one that was suitable.

The whole thing was harder than it should have been, and if I couldn't convey to you how mad I am, just insert expletives above, whenever possible.

As a programmer, I can figure out how to find and graph the data, however painfully. But it's completely inaccessible to regular everyday person that uses the internet. There's a lot of pubic data out there, but people aren't able to access it easily. If it doesn't show up on google's search, that's where they stop.

It's not that people aren't interested that data, but it's because the data is completely inaccessible. If blog and news articles about unemployment, STD rates, and gas prices are any indication, people want to know this kind of information.

Even more so, people want to be able to explore different aspects of this data like the New York Times' interactive visualizations by cutting and slicing the data as they see fit, because often times a statistic only makes sense when you can answer the question, "compared to what and how?" And people want to be able to explore it visually in a way that gives insight.

This is why I'm working on Graphbug--making public data more easily accessible through visualizations. Some questions are best answered visually.

We want to make it easy to find data that you need, and make it as fluid as possible to move between different datasets to compare them, in the same way that google maps made it fluid to navigate a map. Then if you need to do more hardcore analysis, you can download it and play with it however you like.

Of course, the topic is too broad at the moment. We'd like to focus on particular datasets first, and though we picked the US Census to start, we'd like to hear from you what sorts of datasets you'd be interested in? iPhone market share? Number of earthquakes in each state by year? The male to female ratio at colleges over the years?

So visit graphbug.com, and let us know and give me feedback or comment on whether you felt the same pain or you have a need for this. And if so, what are you currently using to solve this problem?

Posted via email from The Web and all that Jazz

What to listen for from technology scrooges

Consider today's online world. The Usenet, a worldwide bulletin board, allows anyone to post messages across the nation. Your word gets out, leapfrogging editors and publishers. Every voice can be heard cheaply and instantly. The result? Every voice is heard. The cacophany more closely resembles citizens band radio, complete with handles, harrasment, and anonymous threats. When most everyone shouts, few listen.

via newsweek.com

I saw this short opinion piece from 1995, and it's related to the technology myopia I wrote about recently, even amongst the technologically well-versed.

Once again, it's easy for us to say Mr. Stoll here is a fool. But that's not what we should glean from this. We now know that even if every voice can be heard cheaply, that data can be easily accessed in text form, and someone will come up with an algorithm to organize it all. Not only that, there's more than one algorithm. Some, like Pagerank is all in a computer. Others, like Digg, Reddit, and HN, are computer-human hybrids that require a bit of social engineering. So while Mr. Stoll correctly identified the problem, he let that stop him there. It was beyond his imagination if, much less how, that problem would be solved.

The same goes when any technology pundit talks about the current new crop of technologies. He might just not have the background to know whether it's possible at all, or he might just not have the imagination. You need both to see clearly.

That's not to say you should ignore everything these pundits say. Instead, listen carefully. The hard part of product development is making something people want. What pundits have done is the hard part of identifying the problem. It's up to you to figure out how to prove them wrong.

Posted via web from The Web and all that Jazz

I take it back. Haml's got some vinegar for a reason.

I take it back.

I gave HAML a second shot, and I rather like it. The conversion was pretty easy, and having emac's haml-mode saved a lot of indentation headaches--even moving blocks left and right in indentation.

How come I liked it better the second time around?  The first time I saw it, it was written by someone that ignored convention and just powered through nesting HAML div elements 10 to 12 levels deep in one file.  You know what?  You're doing it wrong.  

Writing HAML from scratch this time, and reading Haml Sucks for Content, I've found that HAML is designed with intentional weaknesses to make you stay clean and clear. Indentation too far in an HTML document? Chances are, there are repeating elements. Refactor it out to a partial, and you get to start at column zero again. Have the urge to make multi-line ruby statements? Refactor it out to a helper. You'll live longer that way.

By making some things intentionally hard to do--giving them some syntactic vinegar, you'd hope that your users end up Doing the Right Thing™.  But then again, some people just are immune to having code indent 10 to 12 levels deep, or name their variables 'ii' and 'jj' when they're not programming in Fortran.

Posted via web from The Web and all that Jazz

Who would pay for a message sent to nobody in particular?

I recently read a post on how Technology isn't Everything on HN, about how the ranter wouldn't use eBooks.  

 

Consider books. I still buy and read all of my books in the form of compressed wood pulp. There are newfangled e-book readers, but I don't want one. Why? Because the only places I read are 1) In the bathtub, and 2) Lying in bed. Taking a computer into the bathtub is generally not a good idea, and holding a Kindle above my head for 3 hours is awkward compared to lying a (3-D) book on the bed beside me with one page bent up so I can read it. 

via briancarper.net

It's something I hear often about new technologies--"Why would I want to do that?"  I hear it on flamebait blog posts.  I hear it in person during meetups.  When I hear something like this, I'm reminded of quotes about technologies that we take for granted as being obvious now.

Let's start with the radio.  Back before radio as we know it now (as radio stations), when people said 'radio' in the 1920's, they meant the wireless transmission of messages over the air.  They considered it as a communication medium to relay news, like the sinking of the Titanic.  Because of that, people use to pay directly to send messages.  No one was using it as a way to broadcast music like the way we know it now--the concept of a radio station.  And hence, there was no sense of imagination that advertisers would pay ads alongside music broadcasts.  And when David Sarnoff was pioneering the idea, what was the reaction by his potential investors?

By 1916, along with Armstrong and de Forest, [David Sarnoff] was using his newfound fame to push the idea of commercial radio, something he called the "wireless music box," although this idea was before its time. Even as late as 1920, one potential investor wrote him to say, "The wireless music box has no imaginable commercial value. Who would pay for a message sent to nobody in particular?" 

Even the Marconi Company, his employer, rejected the idea of radio as anything but a communications medium. So he went to work for the Radio Corporation of America [RCA] in 1920.
-- Radio Pioneers enter story of the wire on David Sarnoff's associates in response to his urgings for investment in radio. [emphasis mine]

Who indeed.  We laugh now, but we have the luxury of living in the future with our buddy Hindsight.  It's easy to forget what use to be non-obvious.  What's more interesting is that DeForest, also at the edge of innovating on the wireless music box, had this to say about television:

"While theoretically and technically television may be feasible, commercially and financially I consider it an impossibility, a development of which we need waste little time dreaming."  

-- Wikiquotes -- Lee DeForest, American radio pioneer and inventor of the vacuum tube,

Sounds like what people have been saying about Twitter since it came out.

The point to notice here is not: "People in the past are dumb and haha, they were wrong."  The point is, when a new technology or a new use of technology comes out, we're often colored by how we use similar technologies now.  This is especially true when the new thing is bad at doing what the current thing does--"Why would I use eBooks when a regular book would never run out of batteries?"  This is why even the most tech savvy amongst us deride new tech with, "Why would I use that?  The current thing does that much better."  What we often miss is though the new thing isn't as good at something (yet), what new usage vectors does it introduce?  You might not be able to read eBooks in the tub like paper books, but what does it allow you to do that paper books can't?

In fact, there's already a whole book written on the subject.  I'll summarize from the review in Amazon:  Seagate was the biggest producer of 5.25" hard drives in 1985, and was doing research into 3" and 5" drives.  However, they shelved the research because marketing found out that the biggest current customers weren't interested in 3" and 5" drives.  Who needs that?  They don't store as much as 5.25" drives and they're not as fast.  So Seagate didn't develop the 3" and 5" tech and had their lunch eaten by startups attacking that emerging market because as it turned out, the rise of laptops and small personal devices like the iPod needed small drives.  

The iPod is also another famous example with CmdrTaco, the editor of Slashdot saying:

No wireless. Less space than a nomad. Lame. 

 via Slashdot

The same was true of Posterous when they were in our batch.  I remember founders of other startups in the batch thought it was a pretty dumb idea and thought Posterous was going to fail, but now, they're some of their biggest fans.  

When it comes to eBooks, what new usages does it allow that normal books can't?  Though I might not be able to read it in a tub and the batteries might run out, I could easily look up definitions of a word right there and then without consulting a separate dictionary.  I can potentially make comments on a textbook shared by everyone in the class as study cliff notes in real time.  I can search the reference books and textbooks for exactly what I'm looking for.  I can potentially read a book in another language machine translated by my eBook right there and then.  All these things are things that eBooks can do that regular books can't--and not only that, introduce new possibilities.

Just as we laughed as a predecessors, people in the future are going to laugh at you.  So when you look at Google Buzz, don't just think about what it does that seems the same as Twitter, but think about what it allows you to do that Twitter can't.  When you look at Blippy (like twittering your reciepts publicly), don't just ask why anyone would do that, but also what it allows user to do that they couldn't before.  Same when Facebook introduces a new feature or layout.  Same when you look at FourSquare and Loopt.  Same when you look at the iPad.  

Of course, that's not to say that every new thing has potential.  I don't know that the electric can opener has the same potential.  But that's more a lack of my own imagination.  Be wary about dismissing something on first glance, especially when you never tried using it yourself.  In all likelihood, a failure of imagination on your part doesn't mean that something isn't necessarily there.  

Posted via email from The Web and all that Jazz

Google Buzz seems more like Friendfeed than Twitter

A lot of people compare Google Buzz to Twitter.  On the surface, it looks more or less the same, where you multicast some sort of status.  But I think there's some fundamental differences that make the usage a little different.

Buzz enables public conversations that you can see all in one place.  In twitter, everyone can be talking about something, but most clients don't show this view unless you explicitly search for a particular hashtag.  And peoples' replies to a status is fragmented across the board--if you don't subscribe to someone, you can't hear what they're saying.  So conversations are regulated to people that know each other directly.  Buzz and Friendfeed takes it one step further and make a semi-public conversation between friends and friends of friends possible.

Friendfeed's insight is that people like to converse around something and making it easy to come up with topics.  In fact, Friendfeed--and subsequently Google Buzz--are basically forums and bulletin boards that have really lightweight thread creation.  So lightweight, in fact, instead of having to come up with a topic, you have topics implicit in the activities that you do online.  Posted pictures on Flickr?  Your friends can talk about it, even if they don't know each other.  Listening to music posted on your gchat status?  Your friends can make other suggestions or berate your bad taste.

What Google was able to do that Friendfeed needed a couple years' of traction to do was to tie it to already existing google services without asking.  That provides a lot of topics of conversations without setting anything up and people can get started right away.  

Facebook has all the mechanisms I've described above, with the exception that culturally, it's private.  I've rarely seen friends of mine talk to each other through the commments unless they know each other already.  Google starts semi-public, and it gives people permission to talk to each other, even if they don't know each other.  That, I think is a plus.

Posted via email from The Web and all that Jazz

Linking data in XML and HATEOAS

Earlier, I had talked about how a description language is not a good idea for REST services.

To continue in that vein, we start with Tim Berners-Lee. Tim Berners-Lee was talking at TED about linked data as being the next step for the web. He's thought deeply on the formats and protocols of the web, and I think he's right about the overall benefits of linking data. If you could link data together, you can easily join different datasets together simply by traversing it.

However, for a programmer implementing a web app, there's no immediate benefit of linking data. It doesn't show up in web browsers, usable semantic browsers are pretty much non-existent (maybe Disco), and none of the web frameworks makes it easy to link data. The fact that none of the maintainers of Rails, Django, etc do is indicative of the high cost to benefit ratio of doing so.

Taking a look at the Linked Data homepage, I felt the barrier was pretty high and heavyweight just to link data together. You'd not only have to learn RDF, but also OWL and SPARQL. And a simple search for RDF projects in github only reveals one project (reddy) with any attention from other devs with 3 forks and 39 watchers. It seems overcomplicated to have a separate RDF file linking data together.

While having ontologies is great, I don't think it's a low hanging fruit. I was searching about REST when I tripped on a concept called HATEOAS. It is a design constraint of REST that gets overlooked as using hypermedia as the engine of application state.

Given that idea, here's the punchline: Why don't we link data directly from within the XML data? Instead of messing around with RDFs, why can't we link in XML? Here's part of the data returned by the Sunlight Foundation's API when I query for a single legislator.

Notice that some of the fields are pointer to URLs, but for the twitter_id, it only gives the twitter id. With the state, it only states "HI" for Hawaii. Why not point twitter attribute at the URL of the twitter API? Instead of stating the state, why not link it to geonames.org? It might look something like this:

This way, you can traverse from XML document to XML document. So if you needed to look up further information about the attribute "state" with value "HI", you can do so by following the link to http://ws.geonames.org/search?name_equals=hawaii&country=US. So in your application, you can traverse it as if it was composed data. Now, when you execute @legislator.state, you don't only get back "HI", but you get back another set of data with attributes returned from geonames for the state of Hawaii.

You don't need to link to just other web services, but you can link back to your own API. Instead of having just the district number our legislator works in, Sunlight should link back to its own API for districts. When you do this, you push the burden of maintaining application state to the client. The state of the client is merely the XML document it last requested.

And more importantly, if different methods in your API need a specific order to be called, no longer will you need to state this in the documentation of your API. The only allowable methods to be called are the only href links in the XML document. It's best described by an example quoted by subbu:

There are three pages in a UI. The first page has a link to go to the second page. The second page has a link to go to the previous page as well as the third page. The third has a link to the second page and another link to the first page.

A client starts from the first page, and then through the link on that page, goes to the second page. The fact that this page has one link to the first page and another to the third page implies that the current state of the application (i.e. the interactions) is that "the client is viewing the second page". That is what it means by hypermedia as the engine of application state. It does not necessarily mean serializing application state, such as "<page>2</page>" into representations.

Right now, our REST APIs are returning XML with just IDs. It's up to you to figure out what they're pointing to. It's like if we had webpages that just said "next page" and expect you to know which URL to go to and just change it in the address bar of your browser

Obviously, I'm not the first to think about this. Tim Bray has talked about linking plain ole XML, and others have mentioned the xlink for xml, but nowhere in my searches did there seem to be any explicit connection with Tim-Berners Lee's Linked data or with finding a consistent way to access REST APIs. None of the XML data returned by REST APIs had links to them, and none of the API wrapper libraries I've used tried to traverse to a different REST API URI using links in the XML documents.

It seems like a really simple solution to linking data and it's way overlooked. When it all came together for me, it seemed like something people would be excited about, but doing a search on google, google trends, and google adsense keywords, no one seems to be talking about it.

Anyone know why XLink was abandoned, or why linked data doesn't follow this concept?

Posted via email from The Web and all that Jazz

If you forked technomancy's emacs-starter-kit, upgrade nXhtml

UGH.  I recently forked technomancy's emacs-starter-kit, and all was well, until I started editing erb files.  After a while, it would stutter (hang and then go), eating up 94% cpu while editing erb files.  I didn't know exactly what was causing it.  Emacs kept complaining about "MU new post-command chunk" in the *Message* buffer, and something about "not safe forward word".  It took a whole night's worth of digging to figure this out.  

Solution: make sure you upgrade to the latest version of nXhtml (2.05-091202), if you forked technomancy's emacs-starter-kit commit 452c395556e0aac213b0d7d1653f2673554a4b73 or earlier

Sometimes, I hate emacs.

Posted via web from The Web and all that Jazz

I want to use SASS, but not HAML.

The title of the post is more-or-less a verbatim quote from a coworker, as well as from an unrelated colleague of mine from a previous job. I was asked that question and, to be honest, I was a little thrown both times. I didn’t actually know why I use HAML.  I guess I’d never really considered it much after I started doing everything with it.  It just seemed better and more fun.

via blog.digimonkey.com

Oddly enough, I want to do Sass, but not Haml.  Html isn't too hard to begin with, and I guess it's never bugged me.  

What I do dislike about Haml is the indentation on a larger piece of code.  When I want to shift elements around, suddenly, I'm not sure which level of indentation to put it, let alone make sure all the sub-levels are indented correctly as well.  haml-mode in emacs didn't seem to help much.

This means either two things:

1. web markup should be more shallow and I'm doing it wrong.  Perhaps with rails helpers and partials I can compress it more to keep myself DRY.
2. The very Nature of web markup is a deeply nested tree, and haml's indentation's not a right fit for it.  This seems more likely, though again, it depends on the design of the page.  If a page is designed to be with heterogenously abundant page elements, then this is true.

I've yet to decide on either.  Perhaps I'll give Haml another shot.

CSS, on the other hand, has a fairly shallow structure.  In fact, it doesn't have nested structures at all, and you have to re-declare parent tags.  This lends itself to really long files that I can't keep track of.  I've often wished for color variables too.  SASS indentation is good here because it gives you a way to group your css together in a more compact way with hierarchy.

Hence, HTML is too deep for whitespace indentation, and hence in my opinion, not a good fit for HAML.  And CSS is too shallow, and hence perfect for SASS.

So it's not that I don't want to learn HAML because it's something-new, but because it doesn't seem to fit a need I have for the markup I'm working with.  SASS, on the other hand, solves a pain problem I've had with CSS.  

 

Posted via web from The Web and all that Jazz

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")))

via groups.google.com

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.

Posted via web from The Web and all that Jazz

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.

via sacharya.com

Just something to remind me.

Posted via web from The Web and all that Jazz

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?

Posted via email from The Web and all that Jazz

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".

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.

Posted via email from The Web and all that Jazz

Lorem ipsum for images in French Maid

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:



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



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?

Posted via email from The Web and all that Jazz

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.

Posted via email from The Web and all that Jazz

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.

 

Posted via web from The Web and all that Jazz

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.

Posted via email from The Web and all that Jazz

Bubbles and triangles

Lately, I've been looking at more information visualizations, and it's not been said enough that simple geometry is often ignored.

via informationisbeautiful.net

Often times, I'll see visualizations like this, where bubbles are employed to visually compare different records. It seems likely that people judge and compare difference in size by area. However, the artist/designer makes the mistake of mapping the data to the radius instead. This doesn't work for circles because of your old 4th grade math, stating that A = pi * r^2, where the area doesn't increase linearly as a proportion of the radius.

For the record, it's done correctly here in the visualization above, as far as I can tell.

via reflectionof.me

Here, the designer decided to use triangles. If he mapped the data to the height of the triangles, that's fine, because for triangles, A = 0.5 * b * h, and hence area varies in linear proportion to height.

However, looking at Hungary, the red triangle doesn't seem quite a quarter of the black triangle.

Beyond that, for these two examples, I really see no reason to use circles or triangles. People are able to judge spatial difference much more easily, as opposed to size. It would have been far more effective to use bar charts and rectangles instead of shapes like triangles and circles. In my opinion, you only use that if the spatial x and y axis are already being used to convey other information already.

Posted via web from The Web and all that Jazz

Practice coding faster

map_with_index. Why is there no map_with_index in ruby? Ends up it's because you don't need it. You can simply do this:

Even now, I'm learning things about Ruby. The rabbit hole is deep.

Anyway, a post about learning how to code fast came across my desk. I knew that I wasn't quite as fast as other coders, but I had always thought that I thought deeper on the solution. But I think what he says makes sense. I know that violinists slowly ramp up their speed to a point where they're almost making mistakes, faster than they'd actually play the piece to practice playing it at the correct speed. Same with drawing. The more you practice drawing faster, the better you get at being economic with your strokes. So I figured I'd try the same with programming, since I've never done much of this type of exercise.

I decided to do the first Ruby Quiz, since I was most familiar with Ruby, and I should be able to do it quickly. It took me about three hours, including reading the instructions, going on bathroom breaks, etc. I think I should have been faster, and I noticed where I slowed down. I found myself trying things out in irb a lot because I didn't know the exact behavior of some array and string functions. Also, I spent some time in the beginning pondering how to structure it--should it be a class, or just a collection of functions, or should I extend the classes?

I'm not thrilled about how it's structured, but it works. Well, there's a small bug in there, but I'm going to refrain from fixing it. It'll tack on another 30 mins. The point of the exercise is that I can see what I need to work on. I'll try again next time with the next ruby quiz.

Posted via email from The Web and all that Jazz