The road less traveled

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

noreply@blogger.com (Sam Odio) — Wed, 20 May 2009 00:33:00 +0000

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:

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

noreply@blogger.com (Sam Odio) — Wed, 13 May 2009 20:19:00 +0000

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

noreply@blogger.com (Sam Odio) — Mon, 11 May 2009 19:47:00 +0000

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

noreply@blogger.com (Sam Odio) — Wed, 06 May 2009 22:58:00 +0000

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

noreply@blogger.com (Sam Odio) — Sun, 12 Apr 2009 16:34:00 +0000

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

noreply@blogger.com (Sam Odio) — Wed, 08 Apr 2009 08:34:00 +0000

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

noreply@blogger.com (Sam Odio) — Wed, 08 Apr 2009 08:05:00 +0000

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

noreply@blogger.com (Sam Odio) — Fri, 23 Jan 2009 19:02:00 +0000

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

noreply@blogger.com (Sam Odio) — Thu, 08 Jan 2009 17:06:00 +0000

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'

noreply@blogger.com (Sam Odio) — Sat, 13 Dec 2008 03:13:00 +0000

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

noreply@blogger.com (Sam Odio) — Wed, 26 Nov 2008 05:17:00 +0000

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

noreply@blogger.com (Sam Odio) — Tue, 25 Nov 2008 20:16:00 +0000

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

noreply@blogger.com (Sam Odio) — Sat, 22 Nov 2008 19:06:00 +0000

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.

Dear apple

noreply@blogger.com (Sam Odio) — Fri, 31 Oct 2008 17:25:00 +0000

Apple Receipt,
originally uploaded by odiosam.

Please stop sending me receipts for free downloads from the app store. They're clogging my inbox.

While you're at it, you might as well not require that I input my account password to download them as well. It's a hassle on the tiny keyboard, and pointless (somebody's going to steal my phone and rack up charges downloading free software?)

Using Gmail with Django

noreply@blogger.com (Sam Odio) — Wed, 22 Oct 2008 17:57:00 +0000

It's easy to set up django to send emails through Gmail. Just use the following settings:

DEFAULT_FROM_EMAIL = 'user@gmail.com'
EMAIL_HOST = 'smtp.gmail.com'
EMAIL_HOST_USER = 'user@gmail.com'
EMAIL_HOST_PASSWORD = 'password'
EMAIL_USE_TLS = True
EMAIL_PORT = 25

Gmail supports other ports, which you can use as well. This is important if you're running thee server on your local machine, and your ISP blocks port 25.

testing out twitter feed.

noreply@blogger.com (Sam Odio) — Tue, 21 Oct 2008 20:28:00 +0000

I've been trying to integrate all my online "personalities" and I think I've finally got it.

Here's what I have:
- Startup twitter feed (divvyshot)
- Personal twitter feed (sodio)
- This blog
- The divvyshot blog (coming soon)
- Friendfeed
- Facebook
- Linked in

What I'm doing is using twitterfeed to repost my blog posts on their respective twitter feeds. Then I'm using FriendFeed to aggregate the two twitter feeds, along with LinkedIn. I think have installed the facebook FriendFeed plugin, which should aggregate all that data on my fb wall.

We'll see how it all goes...

taking quick notes

noreply@blogger.com (Sam Odio) — Fri, 26 Sep 2008 17:26:00 +0000

I usually email myself stuff I want to remember. That's nothing new - I'm sure most of heard of it before.

But what about quick notes that don't merit an email, or even a post-it?

For example, whenever I'm on the phone with some company I get a confirmation number... they're usually worthless but sometimes can come in handy. I don't want to clutter my inbox or my desk with these confirmation numbers.

Instead, I google them.

For example, I just talked to USPS about an address delivery problem. They gave me a confirmation number, which I promptly googled: "usps confirmation #CO329235921" There's a google bar in most browsers these days... so and I leave my browser running throughout the day so this is pretty convenient. Then if I ever need to talk to them again, I hit CMD-Y (for history), and search "usps conf..."

Of course google searches aren't 100% private - so be sure to only google stuff you can afford to publicize.

Another tip: I set my browser to keep a 120-day history (I find I'm always looking for stuff I visited several months ago, and storage is cheap, so why not). You may want to consider changing your default expiration if you think you're going to need your notes for longer than a month.

Tried change_stage in module django.contrib.admin.views.main. Error was: 'module' object has no attribute 'change_stage'

noreply@blogger.com (Sam Odio) — Thu, 18 Sep 2008 15:40:00 +0000

Another Django upgrade hint:

Tried change_stage in module django.contrib.admin.views.main. Error was: 'module' object has no attribute 'change_stage'

Your forgot to update urls.conf as follows:

# OLD:
from django.conf.urls.defaults import *

urlpatterns = patterns('',
(r'^admin/', include('django.contrib.admin.urls')),
)

# NEW:
from django.conf.urls.defaults import *
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
(r'^admin/(.*)', admin.site.root),
)

Note to self

noreply@blogger.com (Sam Odio) — Thu, 18 Sep 2008 15:40:00 +0000

This is an excellent post about being a web entrepreneur:

Jason Fried - 10 Things We’ve Learned at 37Signals

Django: Error while importing URLconf 'django.contrib.admin.urls': No module named urls

noreply@blogger.com (Sam Odio) — Thu, 24 Jul 2008 14:35:00 +0000

I didn't see a lot on google about this error so I thought I'd post something. If you're getting it, it's likely you updated to the latest Django SVN release, and haven't upgraded your admin site's configuration.

Read more here: http://code.djangoproject.com/wiki/NewformsAdminBranch

One button sign up (continued)

noreply@blogger.com (Sam Odio) — Thu, 03 Jul 2008 14:39:00 +0000

There have been a number of comments about my previous post a one button sign up. I thought I'd re-post them here and clarify.

OpenID is easier: http://openid.net/

OpenID is easier and it's not mutually exclusive to what I'm suggesting here. OpenID or not, many websites will still need to collect additional information. The idea is not to force the user to give you that information in order to use basic site functionality.

If a user sees an auction ending in 1 minute but is then required to jump through some hoops before bidding - thats just as bad an experience.

You're right - so maybe eBay should require accounts just to browse listings? Obviously, that idea doesn't make sense. You shouldn't force the user to sign up early just so that in the off chance they want to bid on an item that's ending soon, they can.

Instead, I'm suggesting you give the user as much access to the site as possible, as soon as possible. Prompt the user for additional information with messages like "Update your address for quick bidding." If your users decide to wait, that's their decision - don't make it for them.

I want to feel involved. Plus, if I'm using a website to the extent that I'm going to want a username and password I pretty much expect that I may have to fill out more information upon registration so it is not as bothersome.

I disagree. Long and tedious registration forms are a horrible way of involving the user. The less information a user needs to enter for the same functionality, the better.

By giving people random user names, you force them to do more work long term.

Step 1: Click the one button and get my user name Step 2: Go write it down somewhere Step 3: Cookie expires/is cleaned - now user forgets the random user name or email. Step 4: Go look it up, enter info

The user should never actually see (or need to remember) their random username. What I was referring to is simply a unique backend identifier. Tracking a user without a username isn't that radical - even Amazon does it.

Amazon (and other stores) do one button sign ups

When I first visit Amazon, the site gives me as much functionality as possible. I can look at products and even add them to my cart - without logging in. Like I was suggesting - Amazon does upsell for more information, prompting you with messages like "Sign in to turn on 1-Click ordering."

After I've visited a product page, I'm in Amazon's database. In this example, simply viewing a product is the equivalent of "signing up" - even though the user doesn't realize that. That's great. Sign up buttons don't always have to be big and green. Ideally, the first step of the sign up process should occur transparently.

Every time I return to the site, Amazon recognizes who I am and suggests similar products to ones I've already viewed:

Now, if I choose (or am required) to create a login, Amazon seamlessly associates it with all my previous "anonymous" data. For example, I still have my previous browse history:

By making it as easy as possible to start using the site, creating a "transparent user" to track my history, and up-selling to gather more information in order to gain additional functionality, Amazon is doing almost exactly what I described in the previous post.

But why limit this process to online stores which by their nature must collect most user information during checkout? Every site should collect as little information as feasible and do it as late in the user experience as possible. That's the whole premise behind one button sign ups.

One button sign up

noreply@blogger.com (Sam Odio) — Wed, 02 Jul 2008 21:06:00 +0000

I've stumbled across a new sign-up process: one button. That's it. From now on, the user will only have to click a button on all of my new projects to sign up.

"But Sam," you might ask, "How will you collect user information?"

Easy. Ask for it when you need it. If you only ask for the user's address when the user wants to do something that requires their address, then you have a carrot to encourage the user to give you that information.

If you ask for the address up front, then not only does the user have little incentive to give it to you, but you discourage the user from signing up at all

Take, for example, ebay's registration form:

Does ebay really need my address if I just want to watch an item? Requiring me to fill out all this information just to preform basic actions (like watching an item or searching closed auctions) discourages me from using the site at all.

Why not not create a "one button" sign up with a default user account and random username? Allow me to use as much of the site as possible, while asking for (but not requiring) information to gain additional access.

"But Sam", you counter again, "what if the user forgets their random username?"

That's easy, authenticate with cookies and/or a unique URL (see craigslist). At the same time, prompt the user (maybe at the top of every page) for a unique username or email address for logins.

EDIT: I've continued this discussion in my next post, One button sign up (continued)

Free Mohammed Maree

noreply@blogger.com (Sam Odio) — Tue, 24 Jun 2008 03:41:00 +0000

Student 'Twitters' his way out of Egyptian jail,
originally uploaded by LCLD.

By now, you've all probably heard of James Buck - a university student jailed in egypt. After twittering that he was arrested, friends, journalists, bloggers and many in the online community rallied for his release.

While it's nice to see the world unite behind such a good cause it's unfortunate that James' friend (Mohammed) hasn't received the same level of attention.

Needless to say he's still in some Egyptian jail, having endured several weeks of torture: http://jameskarlbuck.com/

Interested in helping? Check out James' blog

Well I cancelled embarq... and I now have a new ISP

noreply@blogger.com (Sam Odio) — Thu, 19 Jun 2008 01:36:00 +0000

My new ISP,
originally uploaded by odiosam.

I've had embarq for about 2 years, and I think I'm fed up with them. I was paying ~$200/mo for business class DSL with a few static IPs. For that price, the connection should be FAST and rock solid.

It wasn't.

After about a weekend of downtime (which caused a permanent 35% decrease in BluWiki's traffic) - I was done. Here's my solution: I'm hosting my servers on slicehost for ~$130 / month, and for my personal internet, well, I'm using my friends' connections :)

In the attached photo, you see what I came up with to facilitate doing that.
Parts include:
- DLB 2300 Deliberant AP (no longer sold, had this laying around)
- Buffalo WHR-G125 (not sold in the US, you have to buy it off ebay)
- U.FL to RP-SMA adapter (for the buffalo's antenna)
- Hawking Hi-Gain Directional Corner Antenna 15db
- Yagi 2.4GHz 14.5dBi
- 4 port switch
- Power strip
- Cheap tripod

Basically, I followed the instructions over at i-hacked (www.i-hacked.com/content/view/261/42/), except I substituted the WHR-G125 for the router and the 90 degree corner antenna instead of the yagi. This setup will scan within a 90 degree radius for the strongest open network.

I then use the DLB 2300 in WISP mode to aim the Yagi antenna at the network and repeat it on the switch.

I've decided against repeating the network wirelessly to eliminate any WIFI interference.

It works pretty well :)

Error creating thumbnail: /path/to/wiki/bin/ulimit.sh: xrealloc: ../bash/subst.c:514: cannot reallocate 512 bytes

noreply@blogger.com (Sam Odio) — Thu, 05 Jun 2008 04:21:00 +0000

MediaWiki's software was giving me this error, and I couldn't find a solution on google. I thought I'd post one.

I was able to fix the problem by moving the bin folder to bin.bak, downloading a new copy of mediawiki, and copying the bin folder from the new installation.

I suspect that the error occurs when you set the permissions on ulimit.sh to global read-write (777). The ulimit.sh in the new bin directory was set with limited permissions:

total 20K
-rwxr-xr-x 1 root root 88 Jun 5 04:18 svnstat
-rwxr-xr-x 1 root root 52 Jun 5 04:18 ulimit-tvf.sh
-rw-r--r-- 1 root root 53 Jun 5 04:18 ulimit.sh
-rwxrwxrwx 1 root root 53 Jun 2 01:54 ulimit.sh.bak
-rwxr-xr-x 1 root root 48 Jun 5 04:18 ulimit4.sh

Correcting the error may be as easy as changing the permissions, but if that doesn't work, you can follow the steps I outlined above.