home
on exploration, introspection and creation

Archive for the ‘products’ Category

Bumper guards

Saturday, December 3rd, 2011

Bumper guards — those rubber sheets people stick out of the trunks of their cars to protect their bumpers from dents — are the surest way to:

  1. Make your car look ugly. I understand their appeal — though I haven’t verified it myself, I am sure they protect somehow from small scratches and dents, but at what aesthetic price! It’s like a bib for your car.
  2. Make other drivers bump into you more. Presumably the existence of a rubber surface will protect both cars so the driver who might otherwise be careful will take a few more liberties getting out of that ridiculously cramped parking spot.

I wonder how many people get them having done the research to figure out how effective they are. In other words, is it just a fad, or is there some merit to the idea? (While I should have checked, the disgust I feel for what they make cars look prevents me from spending much time on them. Maybe except for this post.)

Drugs of the Future

Tuesday, November 1st, 2011

I had a vision that in thirty years, people people won’t bother buying drugs from some sketchy guy on the streets and fumbling with these analog devices to administer them. In my vision, people print their own drugs, synthesized from basic compounds. Different drugs would have a different recipe — which would simply be a few lines of code.

Let’s face it, that’s probably the future of drugs. Our children will have access to such equipment (likely, the innovations that some of us come up with will aid in the creation of such equipment) capable of synthesizing any molecule.

There is an interesting enforcement question here — how can such a thing, if possible, be controlled? Would it become illegal to own the source code for the drugs? (is this freedom of expression? or intellectual property?) Would it become illegal to own the synthesizer? (why would it be? It’s not illegal to own the vaporizer.) Would it become illegal to own some specific “source compounds” which happen to be a part of the finished products? (although, if the synthesizer technology is advanced, it will probably be possible to start with really generic compounds, i.e. push the burden of the process onto code).

Elevator music (Part II)

Monday, May 16th, 2011

I think there are lots of ideas that seem good at a time (and perhaps are boosted by plenty of research) that become overimplement and thus abused, causing a reverse reaction. Two examples I was recently reminded of…

Elevator music. What was probably initially intended as a great measure to let the awkward time that total strangere spend in a claustrophobically small elevator pass more quickly, has become something I have a cynical reaction to (or one of disgust, more often). Worse, now not only elevators, but airplanes use it to, I guess, let the time pass better as I await take-off. While there may have been a study that shows that forgettable, mild music with no sharp tones, beats, minor chords or off-key notes is calming, its abuse defeats the purpose because it now becomes part of our collective subconsciousness.

Another example is the “no signal” screen that most projectors use is a pure blue screen. I heard somewhere that blue was chosen because it was relatively calming (curiously, the Windows crash screen is also a blue screen).

Of course, the blue projector screen may have been used for purposes different than psychological ones. Perhaps it was because blue is the primary color with the lowest luminance (a particular intensity of blue is three times less luminous than red, and six times less luminous than green) to ensure the bulb doesn’t burn out too easily. Of course, then my theory wouldn’t work — the abuse of blue screen doesn’t make it any more luminous — but if that was the only reason, I can think of a number of better screen-saving measures (for example, a less intense blue or a checkerboard pattern that would be impossible to mistake for blackness or an actual signal). So in a way, I hope I am right…

By the way — at first I didn’t even remember I already wrote about elevator music. I guess it truly is subconscious, after all.

Mac OS X Names

Monday, January 10th, 2011

It’s very likely that Apple knew that 10.6 would be a refactoring update before they came up with a name for 10.5 because Snow Leopard is a very natural choice for a refactoring of Leopard (and – though that’s a little less likely – they had to know way in advance since Leopard is a really nice name for an OS but Apple decided to wait until 10.5). So are they just naming them late in the game or do they have a good roadmap for their OS editions?

The Reputation of Software

Thursday, December 9th, 2010

I feel that software has a really bad reputation. I blame it on large companies (such as Microsoft and, recently, also Apple) that have, in the past ten years, set users’ expectations in a particular way.

We are all used to software breaking all the time. We rarely think about it. Defects cause us frustration, wasted time and money. We get angry but then we shrug it off. Such a thing would be unacceptable in any other field — imagine having a car spontaneously blow up!

Those large companies haven’t done a good job designing good software. In their pursuit of profit they preferred to set the expectations low. Somehow the entire industry followed suit, and I think the reason it’s been okay is because our human nature makes us crave new feature so much that we forgive everything else.

If a car was defective, it would be the company’s obligation to repair it. Why isn’t software the same? Why is every piece of software provided as-is? Don’t users deserve what they paid for?

Nav Systems and Early Turns

Wednesday, December 1st, 2010

I used to own a nav system in my car and I noticed that as it gave me directions, it would strongly prefer turning early. Why is this? I settled on the following two reasons:

  • The characteristics of the search that is being employed — the search could branch out early because most often, when you ask for directions you have to change the general direction in which you’re heading
  • If you are going to miss the turns, it’s better to miss the earlier ones. It gives you greater flexibility in still getting to your destination. In other words, it’s better to have the option to turn early — turn if you can, because if you can’t, you can go straight and delay turning for later. If you prefer not turning early, you may end up not having an option to turn anymore, which will mean you’re likely to stop more frequently towards the end of the trip

The structure of elevenseconds.com

Tuesday, September 21st, 2010

I tend to favor building to buying when I want to learn something, so when I first started constructing the main site elevenseconds.com I thought of building myself a small Rails-like framework. The main difference would be that it would apply to a simple principle of just-enough abstraction layers, that is, I would introduce a new abstraction layer when I left that the cost of maintaining the current code was too high. I am currently pretty happy with the structure of the site, although updating the front page takes a bit of time so perhaps it’s time to introduce a new layer of abstraction.

At a high level, all requests go to an index page

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.cgi [QSA,L]

which grabs the desired page to be visited from the URL as well as the subpage option (I thought it would be cool to separate the option with a colon — I never liked the questions marks and ampersands, and overloading slashes for paths and parameter separations never agreed with me. And so http://elevenseconds.com/photography/italy:slides takes you to an index page which knows to display a page called photography/italy with an option of slides.

Most of the pages are very similar so I put in place a kind of Metacontent-Metaview paradigm: every page request will fetch content from the /content/ directory. The ruby files there are organized in the same hierarchy as the URLs, so the above link will fetch content from /content/photography/italy.rb.

The actual content file is very configuration-like; let’s take a look at a part of the main content file (root URL resolves to /content/main.rb):


append = []
append << rendering('text', {
  'x'=>1,
  'y'=>0,
  'text'=>'<img src="/images/ui/whatis.png"/>11seconds: on exploration, introspection and creation'
})
append << rendering('verticalLine', {
  'x'=>1,
  'y'=>2,
  'size'=>3
})
append << rendering('imageWithCaptionOnRight', {
  'x'=>1,
  'y'=>2,
  'link'=>'http://blog.elevenseconds.com/trends/',
  'src'=>'/images/thumbs/main/glogo.png',
  'text'=>'trends'
})
append << rendering('imageOnRight', {
  'x'=>1,
  'y'=>11.5,
  'link'=>'/pictures/glowdoodle',
  'src'=>'/thumb.cgi?im=/images/pictures/glowdoodle/sadterminator.jpg&x1=197&y1=74&ss=344',
  'id'=>'projects',
  'text'=>'glow doodles'
})
render('main', {'append'=>append})

append is really a collection of items to append. Each item is a rendered view with some parameters. Each view is simply some HTML markup with Ruby inline code. For example, imageOnRight.rb contains

<div class="rightOfLine" style="left:#{x*35+2}px;top:#{y*35+69}px">
  <a href="#{link}">
    <img class="image" src="#{src}"
      onMouseOver='caption("#{id}", "#{text}", "#{link}")'
      onMouseOut='caption("#{id}", "", "")'/>
  </a>
</div>

(To make the page more structured, I decided on absolute positioning — maybe that’s because I’m a bit of a control freak.)

Note that I’m not quite allowing hierarchical content — there is no need for it given the current design of the site. All I need to do is a two-level hierarchy: a main view (the last line in the main.rb file above may include a bunch of other views.

I needed to introduce another abstraction because a lot of the sites with photography looked the same and I saw myself writing the same code over and over again. So I wrote a function that displays a generic set of pictures. Take our italy.rb content page:


category = 'photography/italy'
caption = 'italy june 2010'
images = [
  ['italy-0', true, '115, 45, 305'],
  ['italy-1', true, ''],
  ['italy-2', true, '296, 20, 54'],
  ...
  ['italy-45', true, '117, 75, 85'],
]
append = []
append << generateSeries(images, category, caption, [534, 356, 2.42])
render('main', {'append'=>append})

The above specifies the absolute minimum that is needed to render the Italy photographs — a definition of each images (I don’t always just number them in sequence), with a specification of whether the image is in landscape (true) or portrait (false) mode, and the top-left coordinate and the size of a window which will be made into a thumbnail. If not specified, the function chooses a smart default.


$explore = [
  ['http://www.gagneint.com/Final%20site/Animation/Sensology/Sensology.html', '/images/thumbs/main/sensology.png', 'sensology'],
  ['http://js1k.com/demos', '/images/thumbs/main/js1k.png', 'demos'],
  ...
]

I do the same with the front page — since it’s mostly made up of a bunch of links, I define each (in the example above, all I need for a link is a URL and a thumbnail picture) and then just cycle over the array. I only look at the latest 10 images for each category (except for EXPLORE which gets 20) but when you click on the link you get them all (http://elevenseconds.com/detail:explore) — again, code reuse.

As the content gets more streamlined (and as I get more lazy), I’ll probably go a step further towards configuration and just define everything in some standard configuration format like JSON (XML may be human-readable, but it’s certainly not human-writeable!). My goal is not quite to minimize the number of characters that I type (because then the conventions at play will no doubt be too obscure, plus the amount of plumbing code I’ll have to write too much for me to remember what I wrote in a year), but I’ll want to get close to it.

The thumbnails are also pretty painless. The utility page, thumb.cgi, generates a thumbnail out of any picture. You just need to specify the top-left coordinate and the size of the window to made into a thumbnail, and the resulting size. Most thumbnails on my page are 32×32 (it’s a kind of hallmark of the site). Some are 67×67 (not 64×64 because I want the images to line up — two 32×32 in a row actually take up ((1+32+1)+1+(1+32+1)) = 69 pixels because of the border and the one-pixel gap so to replace it with a bigger picture means it needs to be 67: (1+67+1)=69.

thumb.cgi saves the autogenerated thumbnails in a cache directory so that the images don’t have to be scaled each time the page is loaded. That is, when thumb.cgi is called with the same arguments again, it will just bring up the saved thumbnail instead of resizing and cropping the picture:


# by default output png unless the target size is specified
format = cgi.has_key?('sc') ? 'jpeg' : 'png'
hash = Digest::SHA1.hexdigest(ENV['REQUEST_URI'].to_s())[0..7]
cacheFile = "cache/" + hash + "." + format
if(File.exist?(cacheFile))
  puts cgi.header("image/#{format}")
  file = new File(cacheFile, "r")
  puts file.sysread(20)
  exit
end

But (great example of just-enough abstraction layers), I go even further: instead of having thumb.cgi do the logic, I replace the source of the image when rendering the view with its cached image. That way I don’t even have to call thumb.cgi which significantly speeds up the page load:


def gen2cache(html)
  source = html.clone
  links = []
  while(source =~ /"(\/thumb.cgi\?[^"]+)"/)
    links.push($1)
    source[$1] = ''
  end
  links.each { |link|
    format = link.index('sc=') ? 'jpeg' : 'png'
    hash = Digest::SHA1.hexdigest(link)[0..7]
    cacheFile = "cache/" + hash + "." + format
    if(File.exist?(cacheFile))
      html[link] = "/"+cacheFile
    end
  }
  return html
end

I guess the next step would be to actually autogenerate the entire HTML response.

Anyway, while Rails is certainly a much better solution to arrive at the final answer, I’ve learned a great deal about Ruby through this exercise. I doubt I’ll make the site much more complex than that.

Branding, part II

Sunday, September 19th, 2010

Words have a lifecycle; hey are born and they die. They die for many reasons; some die naturally (get out of fashion). Others die more untimely death (for example, they suddenly acquire a negative connotation). There are also words that get perceived as politically incorrect — they are on life support because there is still a large group of people who use them, if just to spite everyone else.

This is a good thing. Language is a strange combination of social conventions and explicit structure, and it’s dynamic to reflect the changing needs and thoughts of the society. A language that wouldn’t be allowed to change would be dead. I’m glad unfriend is now a word.

It’s interesting to note that the half-life of phrases seems to have decreased over the past fifty years or so — we get tired of words more quickly, perhaps because as consumers, we’re not satiated and are looking for the next big thing faster and faster. We react to words, and a new word can make us switch from one product to a different one. Inexpensive becomes economical and we suddenly stop thinking of ourselves as cheapos and instead pat ourselves on the back for not wasting money.

Branding is also one way to keep up with class inflation. We don’t want to be gardeners, stewardesses or waitresses. We want to be landscapists, flight attendants, and servers (although the latter seems to me — and to many waitresses — as a step back). A different word — borrowed from what used to be a slightly different role — changes our perception enough to trick the same minds of ours that make us think that it’s somehow less glamorous than it once was to have such a profession.

However, this can also be used as a political tool, to cover up issues or make them seem less like issues. Why do we need to rebrand dwarf to vertically challenged? Is it because it makes us appear to do something about the issue? Or are we ashamed of the fact that the characteristic has found its way into popular culture as a signifier, just like retarded has?

The Three Commandments of Every Enterprise

Saturday, September 18th, 2010

Granted, I haven’t spend much of my life working. But the few years I have spent allowed me to see some things that work and some that don’t. Here are some of the high-level principles that in my view make companies excellent:

  • Innovation — a company that doesn’t innovate by definition becomes obsolete — its days are numbered. All products have a lifecycle, and so innovation is a necessary component of staying ahead of that natural process of product aging and death. Note that innovation should apply not only to the stuff you make; it should apply to tools (upgrade them!) and processes (think of better ways to get something achieved!) you use and also people you hire (train! hire the right talent!).
  • Codification — once innovated, products and processes need to be systematized. This lowers the costs, makes the output more predictable, and protects you from losing the things you innovated on. Again, this applies to the stuff you make, but also in general — any decisions you make
  • Flexibility — if you can’t turn around your product (but also your processes and people) fast enough, you will never be able to deal with the increased complexity that is inherent in anything that grows. This may necessitate meta-innovation: the innovation of processes to deal with complexity itself.

Life Hack #29: The Best Time to Buy Things

Tuesday, September 14th, 2010
  • Wrapping paper after New Year’s
  • Patio furniture after Labor Day weekend
  • Car on weekday mornings in September
  • Groceries on Sunday evenings
  • Airplane tickets on a Wednesday, 21 days (or a couple of days earlier) before your flight
  • Appliances during a holiday weekend
  • Baby clothes during your pregnancy
  • Broadway tickets hours before the curtain rises, at TKTS
  • Champagne in December
  • Clothing on Thursday evenings, six to eight weeks after an item arrives in stores
  • Computers and electronics just after a new model is launched
  • Gas on an early morning or late evening on a weekday
  • Gift Cards a day or two before you give it
  • Shrubs, Trees and Other Plants in the Fall
  • Televisions six to 12 months after a particular model is launched
  • Wedding Dresses between Thanksgiving and Christmas
  • Wine in the early fall

[Source]