Author: rakesh

Houston to get its own sort-of Central Park

Houston Downtown Park

I’m excited to see Houston embarking on a project to add a major park in the middle of Downtown. I used to live in Downtown after following the efforts to revitalize it for several years. Houston, historically a heavily suburban city with a weak city center, had its very own Downtown re-development bubble back in the late 1990s, but like other bubbles, this one has since burst and Downtown real estate appears to have seen a correction. Anyways, details of this new park in Downtown are at DiscoveryGreen.com. It will include:

* One-acre pond
* Playground and children’s areas
* Interactive fountain
* Outdoor ampitheater
* Doggie park
* Jogging trail
* Wifi accessible indoor and outdoor ‘reading room’ areas
* Old oak promenade
* Recreation fields

Americans own a lot of TVs

When I happened to be in Delhi for Barcamp Delhi earlier this year, I gave a short presentation on SnapStream and during that presentation, I took an informal poll on how much time poeple in the audience spent watching TV.  I don’t remember the exact numbers but the numbers were really low and people were shocked to hear how much television the average American watches (4 hours per day for adult men, 5 hours per day for adult women).  Well, as another data point for our country’s addiction/obsession with television, the average American household now has more televisions than people. 🙂

Move too quickly, do too much

I love this quote from Larry Page because it captures one aspect of how I like to operate in business:

Take the case of Sheryl Sandberg, a 37-year-old vice president whose fiefdom includes the company’s automated advertising system. Sandberg recently committed an error that cost Google several million dollars – “Bad decision, moved too quickly, no controls in place, wasted some money,” is all she’ll say about it – and when she realized the magnitude of her mistake, she walked across the street to inform Larry Page, Google’s co-founder and unofficial thought leader. “God, I feel really bad about this,” Sandberg told Page, who accepted her apology. But as she turned to leave, Page said something that surprised her. “I’m so glad you made this mistake,” he said. “Because I want to run a company where we are moving too quickly and doing too much, not being too cautious and doing too little. If we don’t have any of these mistakes, we’re just not taking enough risk.”

(emphasis added by me)

Summarizing last week’s trip to ‘Future of Web Apps’ event

Deciding to get out of the office to attend an event like last week’s Future of Web Apps event in San Francisco is never easy for me. Going to something like FOWA means time spent flying both ways (which totals out to about one to one and a half working days for a round trip to San Francisco, when all is said and done) and being out of the office for a couple of days. And we’re a small company so there’s always a lot to be done and things I’m working on definitely do fall behind (though I also get certain types of work done while I’m traveling that aren’t as easy to get done while I’m in the office).

So anyways, if last week’s FOWA was any indication, it’s definitely worth it to get out to these industry events. Being in Houston, we simply don’t get the same level of knowledge-sharing and idea cross-pollination (at least not outside of the office) that I believe are commonplace for people working in technology in Silicon Valley. So getting out of Houston and getting immersed in that is definitely a good thing, if nothing else, for motivation. From the Seven Rules of Motivation, attending events like these nails both “increase knowledge of subjects that inspire” and “socialize with others of similar interest.”

Unlike the few other “social software” events that I’ve attended in the past (basically, Gnomedex this year and last year), I took _LOTS_ of notes and in a sort of experiment, I’ve taken the time to put them all online.
My favorite talks were from:

  • Tom Coates (he highlighted principals behind social software in a generally theoretical framework)
  • Ted Rheingold of Dogster (his presentation was, I thought, the practical yin to Tom Coates’ more theoretical yang)
  • Cal Henderson (presentation on lessons learn at flickr– a mix of operations and developer stuff)
  • Cal Sjogreen of Google Calendar (basically a walkthrough of the process, from vision to launch, that lead to Google Calendar being created).

But there wasn’t a single presentation that I didn’t learn something from including those from Evan Williams, Matt Mullenweg, Jeff Veen, Mike Arrington, Steve O (Feedburner), Kevin Rose, and Dick Hardt (SXIP). And I have to admit that there were a couple of presentations that I missed… unfortunately.

All in all, this was a great event — thanks to Ryan and his wife Gill and Lisa Price for putting together such a great event.

Evan Williams’ five best screwups at Odeo

There’s a good write-up over on Om Malik’s blog but here are my notes from part of Evan Williams’ talk at the Future of Web Apps event in San Francisco last week:
“Evan Williams at Future of Web AppsMy five best odeo screw ups:

1) we were trying to build too much stuff from the get-go

2) building for people not like ourselves: should have focused on listeners more, it turned out that not a lot of people didn’t want to use our podcast building tool

3) not adjusting fast enough: should have been more honest; wasn’t a purple cow by the time we got it out into the market engineered more and more for on page listening, flash players you could embed in other pages

4) raising too much money, too early

  • $70k to build the first version (Noah and a couple of contract developers)
  • opportunity to announce at TED
  • Ev joined the company full-time and put in another $100k
  • Angel-fund raising went well (over $1M committed after a month)
  • went and talked to a couple of VCs, made the rounds at a few different firms, charles river ventures (George Zackary)– three times valuation that we were raising the angel money at–> what should we do? –> decided to do at VC valuation instead of angel valuation. Rolled angels into that round
  • why was this problematic: think of money like fuel, see how people apply that fuel… you need to have the engine to put that fuel into, you can pour it on the floor and light a fire and do nothing (ha). Odeo didn’t have a product or a proven market
  • Google has fuel
  • scaled down our team
  • best scenario is probably to have the fuel waiting around until you are ready to burn the fuel

5) Not listening to my gut

“When I came hom from work I sat down and I forced myself to code for a hour or two. The enemy was thinking, whenever I paused or started to think I would force myself to type something, its amazing how much you can get done when you just type.” –Markus Frind, plentyoffish.com

‘Don’t talk. Type.’ big poster…”

Matt Mullenweg, “The Story Behind WordPress”, my notes

IMG_2925 Matt, creator of the popular blogging software WordPress and the popular Akismet anti-comment-spam service (we use it at SnapStream and love it) gave a talk at the Future of Web Apps conference in San Francisco last week. Notes from his talk:

Here’s what downloads of WordPress have looked like:

version | downloads
1.2 – 822 a day
1.5 – 2506 a day
2.0 – 5115 a day
2.1 – ???

SourceForge –> no SourceForge, it slowed us down because it took 20 clicks to trigger a download

It’s good to install your app from scratch every so often, that’s how we discovered the terrible download process that was part of SourceForge

More eyes = better software

  • is this true? everyone wants their 15 pixels of fame, if there’s a disagreement, the easiest resolution is to satisfy everyone (“put it on the left and the right” or “implement both features”) –> not a good way to do design, openoffice’s horrendous configuration menu is an example of this

Plugins++ — “luckiest thing that I ever did”

“there are no more killer features, there aren’t any because there are now 10,000 killer plug-ins and they’re all developed by the community.”

APIs++ — breaking APIs is WORSE than never having any at all–> put a little bit of thought before you build

Plug-ins vs. core

  • should everything be a plugin? (like Drupal) –> Matt says “no”, something that does everything generally doesn’t do anything well.

Do your own support: viscerally feel the pain of your users, example: Easter massacre at WordPress where a lot of stuff got deleted, Matt answered every message himself like self imposed punishment.

Pages: to figure out what to create, watch what they do, not what they say (people wanted multiple blog functionality — but it turns out they were using multiple blog to do content management… so the “Pages” capability came from this)

Plugins for design (themes): people switch themes ***ALOT***

What sucks now?

  • no central aggregation of wordpress themes and plugins


Pingomatic

  • search engines like Technorati, etc need to know when a new blog posting is made or updated.
  • it’s really, really heavy… 30M pings
  • you will get spammed –> if there’s anything I know about the future of web apps
    • Yes, you
    • Social software is anything that gets spammed”
  • plan for success
    • have you ever seen a car chasing a car, what happens when the dog catches the car? “rawr” and that’s it?

WordPress.com

  • pageviews has been growing faster than visitors –> 2.2M pageviews per day
  • far larger scale
  • all hosting sucks — 100% SLAs are a fiction
  • redundant networks and power –> a fiction, don’t pay too much more for that
  • make backups constantly
  • get a bunch of sucky hosts and hope that no one hosts sucks at the same time
  • wordpress.com easter massacre: all files that had ever been uploaded
  • buy cheapest hardware possible –> IF you can stay up when it goes down
  • in the initial dell boxes that we used, they were vastly, vastly overpowered
  • there are three numbers in computing: 0, 1 and n+1, the more data that you have, the more important it is to distribute
  • make it easy to contact you — contact form tripled the contacts coming through to us
    • the guy doing support for us was a nurse for 19 years working with clinically insane people
    • if I turn off my computer, does my website go away
  • what sucks? (on wordpress.com)
    • there’s no feature list on wordpress.com
    • there’s no tutorial
    • documentation is pretty sparse
    • 2200 sign-ups every day: these people really trust us
    • our sign-up emails should be better, some parts of the application that you don’t interact with a lot when developing the product are often areas that need attention.

Akismet

  • anti-spam system
  • ham (legit comments), spam (growing far, far faster than legit users)
  • developer API from the very beginning– simple REST API (is this spam, hey you missed something that is spam)
  • 20+ implementations from Ruby to Lasso (wikis, bugtrackers)
  • scalable business (in all the ways that pingomatic isn’t)
    • the more data, the better the service performs
    • Akismet launched on a $80 / month server and it’s still running on that server (plus some others ?)
  • social software

Be a painkiller, not a vitamin
did some research into these industries
– $300-500M vitamin industry
– $800M painkiller industry

Future of web apps

  • global
  • personal: not interested in subscribing to 800 blogs anymore, care about the people I have real relationships with
  • useful
  • humble: don’t be self-important, frame things in terms of you, the user, not me the application

Speakers –> the speakers on stage here aren’t the important ones. Who is? Next slide…

You. Build for yourself first. Working for someone else, not always the most attractive thing.

Business model –> important.

Never forget how lucky you are –> Don’t waste it.

Notes from Jeff Veen’s talk

Jeff Veen, who moved to Google as a part of Adaptive Path’s sale of “Measure Map”, gave a talk titled “Designing better web app interfaces”.  I didn’t take as many notes in Jeff’s talk, but his entire presentation is available online at:

http://www.veen.com/nextgen.pdf

And the few notes that I took are here:

Bubbles:
1) 17th century in Holland: Tulipmania: technological revolution, trade ___ opening up with Turkey
2) Industrial revolution: cars
3) abstraction of wealth into information (stock exchanges)
4) Tokyo in the 80s
5) Pets.com (web 1.0 bubble)

booms and busts happened all the time

fold.com… folds (from the frontpage of techcrunch)

Web 2.0 –> what does this mean for design
— not just visual design (typography, color, layout)
— also interaction design: the way that the way an application works and how that communicates what the application does

1) Giving up control (especially true with visual design)
with print, the designer had full control of the design
huge shift: now control is in the hands of the user

use visual design competency to built trust with users, empowering them to control their data

– Caution this sign has sharp edges… fine print: also, the bridge is out ahead

iFilm — catch errors before they happen (let ’em know that their username is taken — ifilm.com)

Providing context to people

Feedback: how the system responds
— really imporatnt to respond to changes people are making

Information architecture: how information on our site is organized and communicated to our users

“Given enough eyeballs, all bugs are shallow.” The Linus Law

Cal Henderson’s talk at FOWA: lessons learned at flickr

Notes from Cal Henderson’s talk at the Future of Web Apps conference in San Francisco:

(note, a PDF of his slides can also be found here):

I’m not going to talk much about scaling, you can buy my book or this other book.

Flickr’s come a long way

Diagram: Things we already know, things we needed to know (there’s a small intersection point and it’s labeled as “HTML”)

What we learned, wasn’t unique (we weren’t unique and beautiful snowflakes)

Advance notice of outages (if we’re going to be down, we let people know 2 hours ahead of time and we put it across the entire site)

Disable stuff by component — put architecture in place so you can take one thing out of service and keep everything else running. Obviously, this can’t be done with everything.

Tell your users
– communicate what’s going wrong, be completely open
– if you are down for xyz reason, explain that xyz reason (obviously, if you have a crash, don’t go post your stack trace)

Clear escalation paths
– large applications are going break
– the most important thing you can is having escalation paths — what happens when things break?
– who are people supposed to call when there is something wrong, Stewart Butterfield is surfing at 3am and photos aren’t uploading correctly, who should he call. Cal? DBA? or our 24×7 team? (ha)

In-process alerts

Communication! Creative ways to handle this… put a coloring page up during an outage, clear communication is cheap!

Stats tracking is hard (and important!)
– if you want to know what’s going to happen in the future, have to look at the past
– More graphs, much more graphs, can fit huge dense sets of information on graphs
– tens of thousands of real-time graphs of things

Good tools for graphing stuff
– Cacti (ajax zoom stuff)
– Ganglia (massive stat tracking, friendster using)
— very good for tracking stats for network usage, memory, disk, etc.

Web stats
– usually bad, all of the free ones are awful
– measuremap is good for certain things (blogs)
– webtrends is pretty good, but it gets pretty expensive

Create dashboards!
– Konfabulator, sidebar-like stuff

Visual Complexity
http://www.visualcomplexity.com/vc/
how to visualize large amounts of data

APIs = cool
Who knew?

APIs force clean interfaces– UK power socket photograph
APIs allow for easy regression testing
Automated regression testing

Beware of abuse of APIs: not a whole lot harder to abuse than just web-based scraping, but…be weary of people that are bad at programming (I’m making 20 calls per second? I thought I was making one per hour… Ah decimal place (ha))

Track usage of APIs carefully

URLs

  • I heart (clean) URLs I heart (clean) URLs I heart (clean) URLs I heart (clean) URLs I heart (clean) URLs — I’m obsessive about them, understandable by humans (maybe not all humans) but at least all humans in this room
  • (under 60 characters means things will behave better in emails)
  • (put more improtant stuff on the left and less important stuff on the right so maybe if something gets cut-off, it still works)
  • Never break URLs: December 20th: amazon.com changed the format for wishlist URLs and broke all wishlists, don’t break things, don’t break things!
  • Careful of middle tiers: that is, what is I remove the 1234 from http://www.amazon.com/products/books/1234? What if I remove /books/. If your URLs make sense, what’s the bits that fit between one end and the other end?
  • Don’t navigate by URLs: when developing we’ve released features that aren’t linked to from anywhere because we refer to stuff by URLs– ack!
  • Don’t expose auto-incremented variables: makes scraping every page from the system super easy, maybe this isn’t so important
  • /noun/verb/ :URLs should go from least to specific to most specific from left to right, if you have an action as a part of your URL, that action (verb) should be at the far right.

Hiring people, developers, is really tough
– Good people have jobs
– maybe you can poach people away from something they are already doing…
– Read Joel’s recent article on thi
Giving notice/moving house

Older the product, longer the induction (induction: take a new employee and turn them into an awesome engineer)

Documents saved my life
– one way to reduce the time required for induction is to document!

Release early, release often
– new features and new work, not new products (so what Carl from Google Calendars said yesterday is logical and makes sense too)

Old days of the Internet– Under construction sign everywhere…–> it’s been replaced by an endless beta, “nothing is finished on the Internet” (Cal didn’t say this as a bad thing but as a new application/service software paradigm)

Small increments, visible progress: release in small bits, everytime you release, less moving parts

Lightweight QA, no safety net (we don’t test a whole lot of stuff, we don’t have a QA department… flickr doesn’t have one! we have a bit of an odd process, someone will build it, test it themselves and then be responsible for releasing it) no back and forth of building it and then to testing and then ot build it an then to testing and then to release manager…. too SLOW!!! Correct model for really large teams. If you have three developers, that’s not really large. Without QA, there’s no safety net… true but we’re safegaurded against this by releaseing early and relasing often

At Flickr: developers own processes and not the features: developers own stuff

Avoid branches

Shared development environment –> all three or four or five developers working on at the same time, find conflicts much quicker, you know you won’t have to spend a day after working for three having to merge your code in with the trunk.

No developer is an island: everyone works together

One touch deployment

Automating everything — army of robots, robots and scripts very important

Many tools –> componententize (army of robots!)

Always deployable –> agile, always keep the trunk deployable (being able to release once a month != agile, at least not for web apps)

Pragmatic –> make it work. if it’s maintainable, that’s good too.

Beautiful code –> not a priority, idealogical purity is not a priority, I’d rather get something that works
————————–

This stuff doesn’t work everywhere
Takes the right people and process

Like extreme programming doesn’t start working until you do it all… but then it pays off