Archive for October, 2006

Movies: The Departed

Monday, October 30th, 2006

I saw The Departed last weekend. It was very good overall and had surprising twists and turns at the end. For me I was so used to seeing Martin Sheen as President Bartlett that I kept thinking that its a good thing the president was able to keep himself busy fighting crime in Boston now that he’s out of office.

One nit about the movie: the movie has two characters talking on the phone (to each other) on the T, but there’s no cell phone reception on the red line between Park Street and South Station.

SyncServices Example Code in Python

Monday, October 30th, 2006

I’ve continued my earlier efforts to learn the SyncServices API and their use from Python using PyObjC and am pleased to share this example script. (I’ve also submitted it to the PyObjC project). The example code interacts with Apple’s Simple Stickies example. The script performs a full “truth” retrieval, registers an alert handler to join sync sessions, adds a new sticky, then waits to handle any sync events.

Now that’s done I can use it as a basis to explore calendar syncing…

Moving On

Thursday, October 26th, 2006

I’m leaving Oracle as of tomorrow. It was interesting having the opportunity to voluntarily leave a company this time :). I was only there for a year and month or so, but I learned a lot (though some of that will be useful nowhere) and got to work with some smart folks along the way.

I’m moving on to a startup called Zingku.

Some experiments with PyObjC and the Mac OSX SyncServices engine

Thursday, October 26th, 2006

I haven’t developed any software that interacts with OSX before the last couple of days. I have to say the experience has been interesting. I’m really impressed with the usability of the interface builder as well as the power of the .NIB file. I hadn’t realized it was much more than just a description of the application layout.

The main reason I’ve never ventured into programming for OSX is Objective-c. Don’t know it, not sure if I want to know more than I’ve learned in the last couple of days. I had an idea of a project to leverage the SyncServices engine though - so I took the plunge. Into PyObjC that is. (I would have liked to use RubyCocoa but it doesn’t look nearly as fully baked).

Progress was slow at first; I had to at least learn to read Objective-C so that I could understand the docs and the example sync applications. Now that I’ve figured out some of the issues I’ve encountered I’m much more confident - if nothing else now I know what I don’t know. I have to say I’m really impressed with the power of PyObjc. It’s been really great for interactively groping my way through the SyncServices apis.

My first task was to get a feel for the apis by doing a read-only (pull) sync of the stickies saved in Apple’s Stickie’s Example. The code that does that is here. There’s currently no sample python code for the SyncServices module available, so I should hand this off to the pyobjc folks (If they’ll take my painfully un-idiomatic python) once I flesh it out some more.

Can you tell a company by its website?

Wednesday, October 18th, 2006

I’ve been looking for a new job of late, so I’ve been looking at a lot of company websites to get a feel for the company. I know the saying is you can’t tell a book by its cover (even though a cover can catch your eye and make you buy it anyway), but can you tell much about a company by its website?

I like to think you can.

The following factors tend to weigh heavily against a company in my mind (especially if they create web applications):

  • Site looks ugly or broken under firefox (I know most people use IE still, but come on. This also indicates they may be writing IE-only webapps)
  • Messy javascript
  • Poor HTML- no css, lots of inline css
  • Bad information design

I understand that a lot of these companies probably outsource their web presence, but I would think that if there were some talented designers at a company, one of them would raise some concerns about or fix the issues above, particularly poor information design.

Here’s a case study. One of my recruiters told me to take a look at Outstart which appears to be in the business of information delivery (e-learning etc) via the web. So it was especially alarming that they didn’t seem to be able to deliver information about their product line very effectively. Take a look at the screenshot below (taken from here). I’m willing to bet that a large percentage of visitors to the page try to click on the product names (in blue, bolded) next to the short descriptions before figuring out that doesn’t work and using the menu at left. Talk about misleading information scent. (Click the image for a larger version)

Lame info design

Other strikes here (besides the different order of the products in the page and in the menu):

  • Parts of the site don’t render well in Firefox. (like the country drop down box) I don’t want to work on an IE-only app again. Ever.
  • The url is ugly and complex. It contains at least 100 characters, many of which are in hexadecimal. They break down into three coordinates on the menu to decide which page to show. Only each id is a 32 hex characters, which means there are 10^24 possible menus, and the same number of possible items per menu, and the same number of base menus. I guess they’re thinking about growth, or adding the entire internet to their menu structure. At 10^72 combinations, they might be able to have a page for every atom in the universe. Way to plan ahead for growth.
  • The HTML is broken. There’s a chunk of CSS before the html tag. No Doctype.

I’d expect more from a company that builds web apps to deliver e-learning, wouldn’t you?

Getting more organized at last

Thursday, October 5th, 2006

I’ve read David Allen’s Getting Things Done at least twice now but never really implemented many of the ideas until now. I’ve looked at many productivity tools, both open source and not, in search of something I could use. I liked the tiddlywiki and GTDTiddlyWiki apps, but I don’t carry a laptop to and from work and didn’t want to have to carry a USB key everywhere. I’ve used backpack a bit recently, and its handy for some simple things, but it wasn’t really enough for my needs (especially without paying for it - I already pay for hosting so I might as well use it more than I do).

I found Tracks and its been great! Its written in Ruby using Rails, so you can easily host it somewhere public (as I do now) or run it locally on your own computer. There’s a free to use install at zenlist

As an aside, I was building ruby 1.84 on my macs, and I was really taken back that my macbook compiled twice as fast as my G5 Imac given that they’re roughly the same clock speed and the Imac’s disc is probably a bit faster. I was also surprised back when i got the imac that it wasn’t that much faster in non floating point tasks than my old G4 ibook despite an 800mhz advantage, so I guess I shouldn’t be amazed that the duo runs circles around the G5.

TRETC Panel: Innovation and The Energy Crisis

Thursday, October 5th, 2006

The most captivating and depressing session from TRETC was easily “Innovation and the Energy Crisis”. The panelists (well three of them: Nathan Lewis, Joseph Romm and Robert C. Armstrong) painted the most dire picture of global climate change that I have heard yet. They argued that within twenty years there will be massive redirection of capital into mitigating the effects of climate change, which will have such priority that relative luxuries like the space program will go by the wayside (clarification on this here).

The central issue is that in order to minimize climate change but still meet growing energy demands, we have to double today’s energy infrastructure but without any increase in carbon emissions. The problem with this is there are no magic bullets - society has to start using every technology at its disposal from conservation to generation, and the sooner the better so that we can figure out if some technologies (like carbon sequestration) will even work. Discussions on energy policy based on cost alone will never help to solve this problem, risk assessment must become part of energy decisions.

Some interesting tidbits from the discussion:

  • Wind power can likely never account for more than 10% of the worlds energy output.
  • Almost all the significant hydro-power resources are already tapped.
  • There is more energy worldwide in natural gas reserves than uranium. If the world’s ~11 TW energy was to be generated entirely with uranium, it would only last 10 years. This means that breeder reactors using plutonium have to be part of the arsenal, which means dealing with their proliferation issues.
  • The amount of geothermal energy available is on average just 55mW per square meter - so large scale geothermal power may never be possible (but home and business heat pumps are still an effective way to assist in cooling and heating)
  • China’s geology prevents any underground carbon sequestration except for a small portion of the north west. (They’re also apparently asking for the right to “catch up” with the developed nations in terms of cummulative CO2 emmissions before having to participate in any reduction treaties)

The short time frame to turn this around immediately made me think about patents and how they could help or hinder the process - as companies invent better energy technologies, can governments incent them to turn them over to the public domain or make them available for inexpensive licensing without taking away the financial incentive to invent in the first place?

I put the question to the panel leader Robert Armstrong after the talk. He drew a parallel to the mobilization of the US economy during world war 2, where it took just 9 months to switch from cars to bombers and any inventions were quickly disseminated among all producers. (I think another parallel is the way the US government guarantees certain sized orders of vaccines in order to foster their development today)

I wish the audio of the panel was online. [UPDATE! sometimes wishes come true quickly!. The MP3 of this talk is here.] There is this brief article. Here’s a description of some new research that appeared just before the conference and drove some of the discussion.