Sam Odio's blog has been moved to

You're reading a blog that's no longer maintained. Read why.

Monday, March 01, 2010

A confession: I was the one who came forward about the Macbook Air

Daniel Brusilovsky recently asked the founder of a startup for a Macbook Air and offered coverage in exchange. That founder was me, the CEO of Divvyshot. I came forward to Mike at TechCrunch.

For the record, Daniel never received any compensation from Divvyshot.

While reading this keep in mind how easy it is to look back at the events that transpired and judge the participants. Hindsight is 20/20. Mike should have never hired Daniel; Daniel should have known better; I should have made it clearer to Daniel that this wasn't OK. Trust me, it's a lot harder to have that kind of clarity when all this is happening around you.

Alright, here's my story:

Daniel came to me about Air while writing this article. He wrote the article in "real time" while interviewing me. It was in this context that he told me a friend of mine (a guy I went to college with) bought him an iMac in exchange for an article. Daniel told me that the "cover story" for the iMac was that he had received it as a gift for his birthday. I don't know exactly what their agreement was as I wasn't there.

When Daniel told me about the iMac, he mentioned that he needed a new laptop and that he would cover Divvyshot's upcoming announcements in exchange for a new Macbook Air. I was stunned and responded with something like "Haha, we'll talk about it later." I hoped the issue would be dropped after that interview but over the coming weeks Daniel continued to bring up the Air.

My reaction was always "we can do this, but not right now." That was a mistake - I should've just said no. Instead it took me over a week of struggling with the issue before coming forward to Mike at TechCrunch. I'm the first to recognize that I should've handled this differently.

After each conversation I hoped Daniel would drop the idea of an Air. This did not happen. Daniel was very persistent. Every time I came up with a reason why I couldn't do it now, Daniel had an answer about how he could make it work.

At this point, it was clear to me that I was in a tight spot. I felt like I had to bring it to Techcrunch's attention but I didn't want to make an enemy out of Daniel. Since I did not want to go public about this, I feared that he would disparage me to others without them realizing his true motivations. To Daniel's credit, he has not done this (to my knowledge). I think Daniel recognizes his mistake and is simply trying to put this issue behind him. I regret that this post might make it more difficult for Daniel to do that.

I decided that I had to bring this to Mike's attention and that I would ask him to be as private about the matter as possible. I asked him to only bring up the iMac (which Daniel had already received) and to keep my identity confidential.

I have great respect for Mike and Heather at Techcrunch. Of everyone involved in this issue, the guys at TechCrunch are the only ones who are beyond reproach. It is easy to hate on TechCrunch for a lot of things but this is not one of them.

By coming forward to Techcrunch, I put myself in a very vulnerable position. They made it clear to me that they appreciated that I came forward and gave them a chance to handle the issue. They treated me with respect, kept my identity confidential (at my request), handled the situation immediately, and, probably most important of all, were as honest and public as possible (despite knowing the "knee-jerk" reaction many of their haters would have).

Why are you coming forward now?

On February 5th, Jason Calacanis posted some thoughts on the Techcrunch "extortion" story.

I found his article insightful and well written. Wanting to reach out to someone about the issues I've been struggling with, I emailed him and confessed my involvement. That was a HUGE mistake.

Jason Calacanis forwarded my email to Loren at 1938media. It has come to my attention that Loren seems to hold some sort of grudge against TechCrunch. Not exactly the guy you can hope will provide unbiased coverage.

I don't know why Jason would forward my email to Loren given its private nature. The more I learn about Jason and Loren, the clearer their malicious intent becomes.

Loren has not responded to my attempts to reach out to him. Instead, he now seems to be threatening Divvyshot and the other parties involved in this ordeal; forcing me to go public with my story:

Did you mess up?

I should've made it immediately clear to Daniel that this was not OK. Instead it took me well over a week to finally bring the issue to Mike's attention. That was my mistake - I definitely messed up here.

There is no way I would've been able to actually buy Daniel an Air if for no other reason than the fact that I had consulted my brother and girlfriend and they would've simply prohibited me from buying it. I am very lucky that I had them in my life to make sure I didn't do something I'd regret later.

For those of you who are judging me, know this: I have thrown my life into Divvyshot for the last year. I've personally invested close to $100,000 into the company. I would probably give anything I have to see it succeed. Other than a happy and fulfilling relationship with my girlfriend, there's nothing I want more. This has probably been one of the most difficult situations I've ever been in. I let my passion for this product cloud my judgement. Again, I'm very lucky to have loving and supportive people in my life that helped me do the "right thing."

Why do you know Loren learned about this from Jason?

Simple, Jason Calacanis is the only person who knew the details that Loren now knows.

Why are you standing up for Techcrunch?

I'm sure Loren will accuse me of defending Mike in order to protect my own interests.

I have no real reason to defend anyone at Techcrunch. Techcrunch has written two articles about Divvyshot and does not regularly cover us. I don't ever expect to ask Techcrunch to write about Divvyshot again.

I have no reason to portray TechCrunch in an unnecessarily positive light.

Honestly, the way they handled the situation sharply contrasts with the way Jason and Loren are handling it. My sole advice for other startups: deal with them at your own peril.

Wednesday, December 16, 2009

Advice to would-be entrepreneurs

A friend of mine interviewed me for a college entrepreneurial course a few years ago. He was going through his archives today and sent me the paper he wrote - for old time's sake.

Going through the paper I found this quote:

For anybody who wants to be an entrepreneur, Odio’s of advice is to:
"just do it. The only way to become an entrepreneur is by being an entrepreneur. It’s hard work, but a man who loves his work doesn’t have to work a single day of his life. Just do it. Just do it now and figure out the details later. People hold themselves back. They worry too much and they hold themselves back – we’re trained to find reasons why things won’t work. You can always find a reason why it won’t work. People who are successful are ones who find reasons why it will work."

I'm not sure if that's a direct quote or not, I don't remember saying it during the interview. But even if I can't claim credit, I love the advice. It couldn't be more true.

Monday, June 22, 2009

Performance numbers on Apple's SATA firmware update

I recently updated my Mac's firmware and thought I'd publish the performance difference 3Gbs SATA makes..

13" Macbook Pro
160 GB Intel X25-m

Without the update (average):
66.84MB /sec uncached reads. 61MB /sec uncached writes.

With the update (average):
105.50 MB /sec uncached reads, 70.63 MB /sec uncached writes

That's a 58% performance increase on reads and a 15.8% increase on writes!

Read more:
TAUW: MacBook Pro EFI Firmware Update addresses SATA interface speeds

Wednesday, June 17, 2009

Installing macports on Snow Leopard

I haven't seen any documented "success" stories about getting macports (darwinports) running on Snow Leopard so I thought I'd publish the steps I took to install it on my friend's machine:

1. Installed XCode using the "Mac OS X Snow Leopard w/ Xcode 3.2" developer preview DVD from Apple. This install of XCode appears to include the x11 SDK. Note: Snow Leopard isn't publicly available yet. My friend is an Apple Developer and had early access to the OS.

2. Installed macports from source:
mkdir -p /opt/mports
cd /opt/mports
svn checkout
cd ./base/
./configure --enable-readline
sudo make install
make distclean
sudo port -v selfupdate

3. Added "export PATH=/opt/local/bin:/opt/local/sbin:$PATH" to ~/.profile:
vim ~/.profile

Edit: I've only had problems with one package: Python 2.5/2.6. I get the error when building the package: ld: warning: in Python.framework/Versions/2.6/Python, file is not of required architecture.

Tuesday, May 19, 2009

Hacker House: Lessons learned (and how to start your own!)


I've started 3 hacker houses so far and have learned a few things along the way. A few readers have reached out to me and asked for some tips on how to start a house in their city. Hopefully this will help.

Getting started
Ideally, there's a core contingent of about 2-3 coders that are willing to go in with you on a house. I wouldn't recommend renting a house before you've found at least one other coder. Conversely, it's hard to get 5 people on board before hand and even harder to find a house once 5 guys are involved in the decision.

Once you have the house and a few people living there, finding others is pretty easy. I started the Palo Alto house with only one commitment from a friend. I had 3 commitments when starting the SF house. Both houses quickly filled to capacity.

I found coders in the Charlottesville house by using flyers around UVA's campus. Some of them directed visitors to a puzzle which they solved to gain more information about the organization. Other flyers were simpler:

(we'd then display a special page for the wget user agent).

The point was to get the "right" kind of people interested. If you have access to a local tech-oriented campus, you might want to try doing something similar.

Something in a college town or major city works best. It should be easier to find hackers and there will probably be a lot of pedestrian friendly restaurants, bars, shopping, etc. For some reason, having restaurants and cafes that are open late and within walking distance is very important. I've noticed that coders congregate around these areas (SF, Cambridge, Berekeley, Palo Alto, etc.). You won't get many members if they have to drive your house to code and then drive downtown when they want to get food at midnight.

If you're lucky enough to be near a college town, coordinate the lease with their school year.

Find a place with 3-6 rooms. Anything larger gets unmanageable. If a few want to share a room, that's great. Our rent formula for sharing a room is: P = 1/2n + $200 (where P is what each roommate pays and n is the original rent for the room). This means when a room is shared the house gets an extra $400 - lowering everyone else's rent.

Make sure there is ample common space for everyone. Ideally, you have two separate common areas: one for coding (put desks & LCDs here) and one for relaxing (playing Wii, reading a book, etc). The Palo Alto house had no area to relax. We found that this made staying in the place for more than a few months very difficult. You don't need an dining room - most coders will eat at their desks or over the sink anyways.

Cohabitation vs Coworking
You should pick one. In Charlottesville I tried an early model of the HH (it was a two bedroom apartment). The apartment had one resident and 8 desks/monitors for drop-ins. Based on that experience I'd recommend either going 100% coworking (nobody living there) or 100% cohabitation (no drop-ins). For some reason, the mixture just didn't work. It was hard to create an environment with the "right" feel to it. Residents were bothered by coders coming or going at all hours and the coders were bothered when a resident would wake up and spend 30 minutes working in his bath robe.


  • Make sure the rate per room is below the market average (coders usually optimize for price over nice)
  • You should be able to get quality high speed internet there. <- This is key (obviously).
  • The place should have a relaxed landlord that is comfortable with multiple unrelated guys living there (this is more likely near a campus).

Want to start a house?
A couple houses have already started:

Others have contacted me about organizing houses in their area:

  • San Francisco
  • New York (contact Jimmy Kaplowitz - you can find an email on google)
  • Austin (contact: joshuak531 at google's mail service)
  • Boston (see comments below)

If there's already a house in your area, I'd suggest contacting them first. If there isn't a house in your area, you can email me and I'll add you to this list.

Wednesday, May 13, 2009

Use a kitchen timer to maximize your productivity


I can sometimes find it extremely difficult to stay on task. Unproductive "necessities" like checking email, reading twitter, and blogging often squeeze out the productive hours in my day.

My worst days used to look like this:

  • Wake up around 9-10AM
  • 2 hours in the morning to "get ready" (go for a jog with the dog / take a shower / eat breakfast / check email / etc)
  • Start work around Noon
  • Open up Textmate and figure out what I'm doing for the day (15 minutes)
  • Check twitter / hacker news / reddit (1 hour)
  • Grab lunch (1 hour)
  • *maybe* get a few hours worth of work done (2 hours)
  • Check email and do some administrative stuff (2-4 hours)
  • Dinner and hang out with friends (1-6 hours)
  • Spend the rest of the night on twitter / hacker news / reddit / blogs
  • Go to sleep

I felt like I should spend at least 6 hours every day coding and needed something to make sure that would happen. My solution was a kitchen timer. I recently bought one (pictured above) from and I'm pretty happy with it. I find I prefer its mechanical feel and physical presence on my desk to some of the software solutions out there.

In fact, this thing has worked wonders.

Every morning after my run I set the timer for a 60 minutes. That's the time I have to take a shower, get dressed, read email and check twitter, read the news, etc. After that hour is up I close my email client. The rest of the day is spent coding. Online Textmate, my terminal, and Safari are open.

In the afternoon I give myself another 30 minutes to check email, write a blog post, and do anything else I want to do. I'm spending my 30 minutes this afternoon on this post :).

This, along with finding a separate space to work (see my coworking post) have been two of my three most helpful productivity aids. I'll blog about the third tomorrow.


Monday, May 11, 2009

My impression of San Francisco coworking spaces

I recently spent a day visiting every coworking space in San Francisco. I thought I'd post my impressions (since I have at least one friend that's also looking at spaces).

My Favorites
Five star recommended!
Sandbox Suites
Sandbox Suites ($495/mo) - Pros: Cool environment and convenient location. I like how the lounge area is separated from the desks. There are varying levels of privacy allowing you to choose the desk that best suits your need (and budget). There's a decent conference and phone room. They also have an active event calendar. Cons: It's expensive. Especially for a private desk.

SVT Group Coworking space ($300/mo) - Pros: The people seemed nice and the price is reasonable. Cons: Coworking is not the main intent of this space. It's basically SVT's office space with room for a few extra desks.

Seemed Interesting
I wouldn't mind working from any of these places, but they weren't my first choice.
2431 Mission
2431 Mission ($175/mo) - These guys almost made it in the "favorites" category. Pros: The desks in the public area are probably the best deal of all the spaces I saw. I also liked the atmosphere - very eclectic. Wether you do will be a matter of personal taste. To get an idea of what it's like check out some photos. Cons: Everything (including the fuseball table) is in earshot of the work areas. Don't think you could get a private desk and play your music without it being heard throughout. Also, the people didn't seem too friendly. This is probably because there was no designated greeter when I stopped by - everyone was busy working. Most other coworking spaces had someone who's job it was to manage the place and show you around.

CitizenSpace ($425/mo) - Pros: The place is dedicated to coworking and has been around for a while. Convenient location. Cons: They had the worst work/play separation of any of the spaces I looked at. There's only one big space that includes private/public desks, a kitchen, and a "chill area" with couch, TV, and Wii. The floor was concrete and sound would easily travel from one side of the room to the other. If you have a loud keyboard (as I do) everyone knew when you were working. There were no dividers between the private desks. I never saw anyone use the Wii - probably out of fear that it would disrupt everyone else.

PariSoMa ($350/mo) - Pros: Cute place and the people seemed nice. There's a lot of light from some huge windows, which could be a pro(not depressing) or a con (screen glare). There's a cool little nook where you could relax and read a book. However you couldn't take a phone call there without interrupting the rest of the office. Cons: Only marginally more private than CitizenSpace. Most people there aren't coders (which was important for me). This would be better suited for indie designers (hence the name). Also, the space was a little small and not as well equipped as Sandbox Suites.

I would rather work from home.
Dreamfish, SF - Way too cramped (unless you like working while standing up). I'd have a hard time working here even if I was good friends with everyone else in the room.

iList - Drop in only. No permanent space available. At the time I saw the place they were moving to a new office. I don't even think they had available chairs.

HatFactory - There was just one big common desk that everyone works at. I didn't feel like I could bring my own keyboard/mouse/monitor and leave them there. Also I think some guy lives here.

NASA CoLab - Seems inactive / nonexistant. Their wiki has gone offline.

Labels: ,

Wednesday, May 06, 2009

The coder's bookshelf

I've spent a decent amount of time and money assembling a book collection that's relevant to the coders in the Hacker House. I thought I'd publish what we have so far. Apologies in advance for the made up genres. Some of these books were contributed by John Devor & Dan Grover but most were purchased used off of Amazon. In total I spent about $400.

The collection was partly based off of these recommendations:
- The Top 9½ In a Hacker’s Bookshelf
- Book Reviews by Joel Spolsky
- What is the single most influential book...
- What would you put on a hacker's bookshelf?

Feel free to suggest any other books in the comments below!

Oreilly reference books (programming):
- Learning Python
- Python in a Nutshell (indispensable)
- Programming Collective Inteligence
- Version Control with Subversion
- Python pocket reference
- CVS pocket reference
- Facebook Cookbook
- FBML Essentials

Other reference books (programming):
- How to Design Programs
- Structure and Interpretation of Computer Programs (I'm currently working through this book... it will take me a while)
- The Little LISPer
- The Little Schemer
- The C Programming Language
- Core MAC OS X And UNIX Programming
- Programming Ruby
- Agile Web Development with Rails
- The Definitive Guide to Django
- Practical Django Projects
- Pro Django
- Simply Javascript (sitepoint)
- PHP Developer's cookbook
- Object-oriented PHP
- Beginning OpenGL

Obviously there are many other reference books worth owning. We chose the above books because they cover the languages relevant to us.

Anecdotal "Nonfiction" / historical startup-related stories:
- DEC Is Dead, Long Live DEC
- Burn Rate
- The Perfect Store
- Once You're Lucky, Twice You're Good
- Microsoft REBOOTED
- Founders At Work
- Revolution In The Valley (My favorite book in this section.)
- Hackers by Steven Levy
- Crypto by Steven Levy
- The Fall of Advertising & The Rise of PR
- The Search by John Batelle (Needs more research/interviews from Google founders & employees.)
- Blog Blazers

Programming/startup-related stories & essays:
- The Pragmatic Programmer
- Joel on Software (A great first read for any CS student entering the workforce.)
- Facts and Fallacies of Software Engineering
- The Mythical Man-Month
- Design Patters
- Hackers & Painters
- The Monk and the Riddle

Other hacker books:
- The Best of 2600 (A Hacker Odyssey)
- 2600 Magazines
- Computer Networks (A Systems Approach) by Peterson & Davie
- Computer Networking by Kurose & Ross
- Mathematical Structures for Computer Science
- Applied Cryptography by Bruce Schneier

Motivational / Organizational:
- The Last Lecture by Randy Pausch (A quick & inspirational read. Life-changing stuff. Read the wikipedia article first.)
- Getting things DONE
- How to Win Friends & Influence People (A classic, but can easily be paraphrased.)
- The Art of the Start
- The Creative Habit
- Bit Literacy (A gift. A good book for the computer (semi/il)literate.)
- Influence by Robert Cialdini
- 7 Habits of Highly Effective People
- Talent is Overrated

Writing / Literature:
- Best Software Writing by Joel Spolsky
- On Writing Well by William Zinsser
- Writing Down The Bones
- A Glossary of Literary Terms

Finance & Economics:
- Basic Economics by Thomas Sowell (If you want to learn Econ, read this book.)
- Freakonomics
- The Visual Display of Quantitative Information
- Buffett by Roger Lowenstein
- The Intelligent Investor
- How to Invest $50-$50,000

- Several books by Bob Woodward (The War within, Bush at War, etc)
- The Quotable Atheist
- The Squandering of America
- The End of Faith
- The Selfish Gene
- Atlas Shrugged
- The world is Flat (There's a debate as to whether these books belong in the economics section. My vote is no.)
- Hot, Flat & Crowded (same as above)

Science & History:
- 100 Scientists who Changed The World
- A short History of Nearly Everything
- Gödel, Escher, Bach: an Eternal Golden Braid
- On Speed: the Many Lives of Amphetamine
- Guns, Germs, and Steel
- Sex, Time, and Power
- Outliers
- The Double Helix

- Around the world in 80 days
- A Confederacy of Dunces
- Walden
- Civil Disobedience
- A Brave New World
- The Power of One
- One Flew Over the Cuckoo's Nest
- Profiles In Courage
- Geek Silicon Valley (If you're a geek in the valley you need this book.)

Recent purchases (haven't yet arrived):
- Zen and the Art of Motorcycle Maintenance
- Art of Computer Programming, Volume 1
- Code Complete


Sunday, April 12, 2009

YC interview advice

I've been asked a few times what an applicant should know before walking into the YC offices for an interview. Here's a short list:

1) Build something
You should have a demo. It doesn't take more than 2-3 days to quickly mock something up that you can show the partners so there's no excuse not to.

This is actually great advice for the entire program. Start building your product early -- don't wait until that YC acceptance or the start of the program. I think the ideal time for a YC company to launch is in the first week of the batch.

2) Become an expert in your market (and your product)
Hard facts work. Have them available. What's the size of your market? What's the revenue of your closest competitor? What about their monthly traffic? How much time to visitors spend on your site?

3) Have a path to positive cash flow
It has become clear that in this market you should have revenue by demo day. Ideally you're ramen profitable. It'll be much harder to find investment if you're not. I am ABSOLUTELY positive that YC will be thinking about this when interviewing.

Be prepared for the question "how are you going to make money?" and the answer probably shouldn't involve ads.

3) Do mock interviews
Ask others to interview you. Ideally, practice with previous YC founders or someone that understands the hacker mentality.

4) Show some passion
Make it clear that you're excited about your product and that you're not going anywhere. If you don't believe in the idea/product, why should anyone else? One of YC's biggest problems is with founders that aren't in it for the long haul. You should communicate this both in the way you talk about your product and in the preparation you've done before the interview (see above).

5) Be humble
The last thing you want to do is argue with the partners. Accept criticism and show that you've thought about the objections they raise. If you don't have an answer, be honest. Offer to do the research and follow up later in the day.

6) Finally, find a cool place to crash
Don't get a hotel. Find other hackers to crash with on HN, craigslist, or airbnb. You can also stay at the hacker house. Getting an idea of what its like to be a hacker in the valley is almost important as the interview itself.

Edit 10:32 AM: I almost forgot another very important point: don't bring a deck. The 10 minute interview is going to mostly consist of the YC partners asking questions and you answering them. You won't be able to script the whole thing slide by slide.

In fact, anything the YC partners have to sit through won't go over well. This also includes a video of your product. From talking to PG, this is one of the most common mistakes. Don't do it.

Edit 11:04 AM: PG wants to clarify some of this advice. To avoid leading anyone astray I've reposted his comments below:

"the answer probably shouldn't involve ads"
Actually we're not as down on ads as other investors seem to be. We liked Heyzap, and they make money from ads.

"The last thing you want to do is argue with the partners."
That's an overstatement. We don't like people who supinely agree with everything we say. That's as bad as refusing to listen to anything we say. What we look for is a middle ground: people who respond intelligently to our suggestions.
Some of the suggestions we make are stupid. If people agree with those, we conclude they're stupid. (We don't do this on purpose to catch people. We just don't understand very well yet what each group is doing.)


Wednesday, April 08, 2009

The last YC dinner

We had our last YC dinner tonight. Joshua Schachter spoke about and his experience at Yahoo. Here are some photos:


Monty updates; Anybots at the Stanford TODAY (Wed) 12-6PM

Savraj (from Wattvision) and I spent some time at tonight's YC dinner playing with Monty. The robot now has stereoscopic vision with 3D goggles - which is very cool. The goggles also give you control of Monty's head. You can look up and down and the robot will do the same. If you look in a direction that Monty's head cannot physically follow the goggles will show a stiched-together view from the robots perherphial cameras.

Other nifties: You can turn around or bow and monty will imitate you.

Want to see more? Anybots will be showing QA (their newest robot) at the Stanford Cool Product Expo tomorrow (wednesday). Its open to the public so anyone is welcome to come.

Date: 4/8/09

Location: Stanford Arrilaga Alumni Center

Time: 12-6PM

More details.

Labels: ,

Friday, January 23, 2009

Adding custom attributes to django modelform fields

Finding an elegant way to solve a particular problem that's been stumping you for a while is always a nice feeling.

Savraj and I were talking about django's modelforms today. My modelform conversations always seem to gravitate toward lamenting about how it is hard to customize them. That's been a problem that's bothered both of us in the past. My solution was to customize the CSS of the form. This worked for some elements (such as the form's length), but not others. Another solution is to explicitly declare each field with the customized attribute, but this seams to defeat the whole purpose of modelforms.

I just figured out a more flexible solution that I'll share here. It allows me to modify the attributes of a django widget without explicitly declaring the field (which is great). In the example I modify the onclick attribute. You can use it to modify any attribute you want (eg. size, max_length, value, etc).

class PhotoForm(forms.ModelForm):
    class Meta:
        model = Photo
    def __init__(self, *args, **kwargs):
        super(PhotoForm, self).__init__(*args, **kwargs)
        self.fields['name'].widget.attrs['onClick'] = "this.value =;"

Thursday, January 08, 2009

The coolest thing you'll see at CES all day


Anybots just announced QA, a new tele-operated robot. I've been fortunate enough to have spent some time with it and it's pretty impressive. If you're going to CES, it's worth checking out in person. They're in the Robotics tech zone at the Sands Expo center (Booth #72239, Exhibit hall C).

The form factor is similar to Monty except much simpler. This means the cost will be in the thousands, not the hundreds of thousands. Unlike monty, QA is 100% battery powered, and gets 4-6 hours of runtime on every charge. Monty's pneumatics required it to be tethered at all times. Also, its much lighter at around 35lbs. Monty is too heavy to pick up.

The obvious disadvantage is that QA doesn't have arms and therefore no real way to manipulate its environment. While I'm sure that it was a hard decision to move forward without arms, it was probably smart. Arms are hard to get working reliably and require a custom user interface. QA can can be controlled by any laptop that's connected to the internet.

I can imagine a number of applications where a mobile telepresence robot is still valuable - even without arms. However it will take people more creative than me to think of all the ways QA could be used. We might see these robots patrolling dangerous neighborhoods in a few years, calling in the cops when any suspicious activity is observed. Who knows.

Edit, 10:09AM Anybots has updated their website with more details. Head over to their about the robots page.


Friday, December 12, 2008

Django tip: AttributeError: 'str' object has no attribute 'has_header'

Here's another quick Django tip that I couldn't find an answer for on google:
AttributeError: 'str' object has no attribute 'has_header'

The error is the result of returning a string in a view instead of using HttpResponseRedirect. For example I accidentally wrote:
return urlresolvers.reverse('crowd-detail')

When what I meant was:
return HttpResponseRedirect(urlresolvers.reverse('crowd-detail'))

Hope that helps someone out there.


Wednesday, November 26, 2008

In defense of Ipodhash

The author of the Ipodhash project recently sent me an email explaining why Ipodhash does not violate Apple's DMCA copyright. I thought I'd republish it here. I can't vouch for the accuracy of his defense, but it sounds like an interesting argument.

The iPod hash is added to iTunes database to protect it against
modification by third party utilities (to prevent third party
utilities from synching with iPod or iPhone). Now there are a few

1) iTunesDB does not fall under the category of copyrighted material.
The iPod hash protects the database. A database is not copyrighted
information. It is created on the user iPhone/iPod by iTunes, and
iTunes adds this hash to make sure that no other application can
modify the database. But that does not make the "database" a
copyrighted material.

2) The hash protects the database from writing, i.e. Thirdparty
applications can still read the database in presence of this hash.
DRM schemes usually prevent reading by thirdparty applications. Hence
this scheme does not fall under DRM protection.

3) The DMCA does not outlaw dissemination of information, which could
lead to circumvention devices.

4) We are doing this for interoperability with other platforms (such
as linux). DMCA explicitly allows reverse engineering for
compatibility purposes.

Hence I believe that there was nothing illegal, about the project.