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

Specs:
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

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 http://svn.macports.org/repository/macports/trunk/base
cd ./base/
./configure --enable-readline
make
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.

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.

Advertising
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:

wget http://etalambdachi.org

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

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

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

Miscellaneous

• 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:

• Palo Alto (available Fall 09)
  
• San Francisco (available Fall 09)
  
• Providence, RI (Brown) - Techhouse
  
• Panama - Cocovivo
  

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.

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 Amazon.com 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.

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 ($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 ($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.

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

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

Political:
- 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

Un-categorized:
- 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

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

The last YC dinner

We had our last YC dinner tonight. Joshua Schachter spoke about Del.icio.us and his experience at Yahoo. Here are some photos: http://dvsht.com/the_actual/

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.

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 =;"

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.

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.

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
points

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.

EFF agrees to represent BluWiki, responds to Apple

Great news: The Electronic Frontier Foundation has agreed to represent BluWiki regarding Apple's takedown request of the Ipodhash project. The EFF has also published a formal response to Apple's cease and desist email: Apple Confuses Speech with a DMCA Violation.

Also, after writing a public letter to the author of the project, he has contacted us. He sent me an extensive defense of his project that explains why he believes it doesn't violate the DMCA. I hope to publish it as soon as I can get his permission.

Right now our biggest fear is that after we contest this issue, Apple might go to Slicehost or Namecheap and slap them with takedown notices for my accounts. If they do that, all of my sites could be forced offline, including BluWiki. I'm currently trying to contact them to at least make them aware of this issue.

I look forward to working with the EFF and Apple to resolve this issue and get the Ipodhash project back online :)

Support free speech, find author of Ipodhash

On the 14th Ian Ramage of O'Melveny & Myers LLP contacted me regarding the Ipodhash project (hosted at BluWiki). They represent Apple and requested that I take the Ipodhash project offline.

Because BluWiki is a free service and doesn't have much cash or a legal team, I swallowed my pride and complied. Since then, the story has been picked up by slashdot and arstechnicia. Both sites linked to the page where I asked for legal assistance from anyone who has experience in these issues.

I've received a flood of emails from interested individuals who want to help. Most importantly, I was contacted by Fred von Lohmann from the EFF. They're currently evaluating whether they will represent us against any potential Apple litigation. This would be great, because it will enable BluWiki to continue to host the project while working with EFF to address Apple's concerns.

However, before the EFF commits to representing us against Apple, they want to speak to the author of the Ipodhash project on BluWiki. I'm posting this public plea hoping that the author, or someone who knows the author, might read it.

Plea to the author of IpodHash:
Please contact Fred at the EFF. Fred is looking to protect your right to free speech online. But he can't do so if we don't work with him. Because Fred has expressed interest in representing both you and BluWiki, all communication is confidential and protected under the attorney-client privilege. Communication with Fred can not be released in court.

If you do not contact Fred, and the EFF does not represent us, we will be forced to comply with all of Apple's demands. If Apple chooses to litigate against us, we will probably exhaust all funds in our defense. Out of money, BluWiki could ultimately be forced offline. This would be one more small step backwards in the fight for the right to free speech.

Fred's phone number is +1 415 436 9333 x123 and his email is fred@eff.org. You can find his PGP key here.

I sincerely hope that you contact the EFF so that we can restore this project and work with Apple in a way that does not violate BluWiki's founding principle: giving everyone the tools to express themselves online without censorship.