Sunday, February 28, 2010
Thursday, February 25, 2010
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.
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.
This is why I'm working on Graphbug--making public data more easily accessible through visualizations. Some questions are best answered visually.
Saturday, February 20, 2010
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.
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.
Friday, February 19, 2010
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.
Saturday, February 13, 2010
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.
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]
"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,
No wireless. Less space than a nomad. Lame.
Wednesday, February 10, 2010
Monday, February 08, 2010
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.
Friday, February 05, 2010
Tuesday, February 02, 2010
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.
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:
- 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.
- 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.