A little less than three months ago I started working on my new project, Cohaico, and today I'm launching the public beta of the website. From the announcement post on the Cohaico blog:

Let us fix that for you.

Guess what - your friends are already sharing everything they know about stuff. They do it on social networks like Twitter.

But if you get on Twitter - you'll just see what was said in the last few hours or so. It's hard to see what all your friends said about a particular thing.

This is what Cohaico does.

Exciting times!

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

People are zombies

Bubble

This place is a bubble. And I don't mean "startups are being funded too easily" bubble. Which is also true. I mean that people are just so into everything internet, that any kind of stupid idea flies. Which is pretty dangerous because the rest of the world just don' work dat way ™.

I mean, homeless people ask you for help with Twitter API here...

Dress

On the other (better) hand: South Bay is warm.

Getting around

Getting down to the South Bay (Palo Alto, Mountain View and the such) is trickier. You can take the Caltrain but then you're most likely need a cab too. I really recommend signing up for Zipcar. They have cars everywhere and is the best-value option for when you need a car for a few hours. If you have an Israeli driver's license you'll need to produce some papers from the Ministry of Transport. I am in the process of doing it, will update...

Use a coupon for some free hours too.

Getaround sadly don't work with Israeli licenses at this point.

Update (July 22nd): Getting to meetings specifically in Palo Alto is doable with a Caltrain as the station is within 10 minutes walking of most locations on University Ave (this is where your meeting is going to be). Pro tip: schedule for half-past as Southbound trains get to Palo Alto at :03 past every hour between 10am and 4pm which gives you a good 30 minutes to walk there, then if you manage to end your meeting in 50 minutes you have 20 minutes to walk back to the train back that leaves at :41 past every hour (tip by @rutipo).

Hitting the meetups

Finding geeks/founders/investors/hackers in a social environment is super easy. Check out Meetup.com and Startup Digest for a ton of events. After a week you'll start recognizing faces...

Working space

The city is full of coworking spaces. I am working out of Next Space which is great - nice people, great location and good facilities. Lots of activities (kind of like The Junction back home :)). I didn't do any extensive research but some people I talked to did and they settled on Next Space so I guess it's fine. Reasonably priced too, at $285/month.

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

Over on the Cohaico blog, I wrote about some things I learned during the first months of working on a new startup:

Products that succeed? They are the ones that got the crazy distribution by getting people to use their service, other companies to partner with them etc. On the outside, this often looks like "destiny" or "force majore". You built such a kick-ass product that people are just magically drawn to it. Bullshit. Nothing happened by itself. Every successful product came to be because somebody, deliberately, carefully and thoughtfully kicked ass doing sales and did it better than the competition.

Read more.

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

Google Chrome (and now also Firefox 4) have the useless little feature of allowing the user to resize any <TEXTAREA> on a page.
I've found the perfect use case for it:

1. Go to a page in your website that contains a <TEXTAREA>, like my Delver profile page:







2. Drag the corner of the <TEXTAREA> until reaching a particularly obnoxious appearance:




3. Now make a screenshot and send an email to your favorite QA person.
This is the part where you should really get creative. Here's my suggested format:

Subject:

OMG crazy UI bug in profile page - ON PROD!!

Body:

Hi [QA person name],
Check this out (found on my profile page in PROD).

I can't *believe* we missed this and let it reach production this way. Please handle ASAP. Bug should be assigned as "critical"!

thanks,
[Your name here]

You should also CC the QA team manager on this.
Enjoy.

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

Here's a c# example of consuming the Twitter Streaming API.
Suppose you want to take all Tweets mentioning a country and save it to a database.
I will be using the Twitterizer c# library. Let's first look at the complete code and then walk through it:

private static bool streamEnded = false;
public static void HandleStream()
{
  DateTime end = DateTime.Now + TimeSpan.FromSeconds(60);

  OAuthTokens tokens = new OAuthTokens { ConsumerKey = "YOUR_KEY", ConsumerSecret = "YOUR_SECRET", AccessToken = "ACCESS_TOKEN", AccessTokenSecret = "ACCESS_TOKEN_SECRET" };
  TwitterStream s = new TwitterStream(tokens);
  s.OnStatusReceived += new TwitterStatusReceivedHandler(s_OnStatusReceived);
  s.OnStreamEnded += new TwitterStreamEnded(s_OnStreamEnded);
  FilterStreamOptions ops = new FilterStreamOptions { Track = new List<string> { "italy", "germany", "spain", "france", "england" } };
  s.StartFilterStream(ops);

  while (DateTime.Now < end && !streamEnded)
     Thread.Sleep(1000);
 

  s.EndStream();
}
static void s_OnStreamEnded()
{
   streamEnded = true;
}
static void s_OnStatusReceived(Twitterizer.TwitterStatus status)
{
  SaveTweetToDatabase(status);
}

Now let's look at the code in depth. First, as we'll be processing tweets in a loop, let's set an end to our loop. Let's say we want to process tweets for 60 seconds:

DateTime end = DateTime.Now + TimeSpan.FromSeconds(60);

Next, we setup the Twitterizer class used to handle the Streaming API:

OAuthTokens tokens = new OAuthTokens { ConsumerKey = "YOUR_KEY", ConsumerSecret = "YOUR_SECRET", AccessToken = "ACCESS_TOKEN", AccessTokenSecret = "ACCESS_TOKEN_SECRET" };
TwitterStream s = new TwitterStream(tokens);

The class TwitterStream is part of the "addons" to Twitterizer, so you will need to download the source of the 2.3.2 release of Twitterizer and make a small fix as I described here.
You will pass to TwitterStream the app keys of your Twitter application which you set up here and the OAuth tokens.
Next, we set up event handlers for the stream of tweets:

s.OnStatusReceived += new TwitterStatusReceivedHandler(s_OnStatusReceived);
s.OnStreamEnded += new TwitterStreamEnded(s_OnStreamEnded);

s_OnStatusReceived will be called by TwitterStream when a tweet is received from Streaming API and s_OnStreamEnded will be called when the connection to Twitter ends.
Next, we may add some options to the Streaming API. There are several methods to access the Streaming API: you can either get tweets for a list of keywords, a list of users or a random sample of all tweets. In our example, let's ask Twitter for tweets mentioning a country and open the connection:

FilterStreamOptions ops = new FilterStreamOptions { Track = new List<string> { "italy", "germany", "spain", "france", "england" } };
s.StartFilterStream(ops);

The last thing to do is wait for the amount of time we decided on in the beginning and then close the stream:

while (DateTime.Now < end && !streamEnded)
     Thread.Sleep(1000);
 
s.EndStream();

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

Here are some tips for creating more useful software specs that I gathered from my experience working on Delver.
Note: these are mostly relevant for specs that deal with user-facing features, but some apply in general.

Tell a story

Try to structure your document as a story that describes what the user does in the same sequence users are going to do it in the eventual system.
This conveys the experience better than just describing different pages and functions as standalone objects.

A picture is worth a thousand words

Include as many sketches of what the user sees instead of trying to describe it in many words. Things like interactions between elements and lists of fields are much clearer when looking at them the same way the user will.
Include in your spec a sketch of every significant UI "state" the user will go through (I use Balsamiq Mockups to create my sketches).

Use nested sections to create structure

Structuring your document with hierarchical sections creates structure and helps navigating your spec when reading it repeatedly. The spec will be used as a reference for a while. For the first read - the story-like narrative is best. For subsequent reads - the ability to jump to the relevant part is more useful.
If you're using Word - use the built-in "Styles" feature for the titles of your sections. This also creates a handy navigation and allows you to quickly create a table of contents if you want:

Start new sections on a new page

It's better to start a new section on a new page (Word shortcut ctrl-enter). This makes it very easy on the eyes when trying to read just a particular section:

Focus on what's important by removing the tedious details

By nature, the spec contains a lot of details. You want the person who reads your spec to be able to grasp the main ideas and the UX flows while not being distracted by the details. Later, you want the details to be available for someone who's interested in the details for reference, having already understood the flow and the main idea.
You can achieve this by moving details like form field lists, message lists and long if-else logic, out of the main story and into the appendix of the document.

Track changes

Add a changes table at the top of your document. In this table, list the date and main points of every change you make. Your spec will be adjusted during the review and development process. Documenting the main changes helps people who already read your spec once quickly understand what has changed since the last time they looked.

Use conventions

Like in code, it helps to have a few common conventions in all of your specs. Usages of this are a specific font/background color for literal text that is displayed to the user, developer notes and so on.
For example, I use the following standard for literal text:

Hey user, welcome to the website!

Don't worry about DRY

If you're a past/present hacker, you love the principle of DRY. Don't worry about it as much when writing your specs. It's ok to repeat yourself and describe the same thing twice in two different places if it helps the story-like nature of the spec and its clarity.

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

Out of the few Twitter API libraries for .net out there, the ones that seem most complete are: Twitterizer and TweetSharp.
I've been developing with both in the past couple of weeks and both are generally stable, complete and provide a clean one-per-one wrapper for the Twitter API methods. Which is great news (tm).
TweetSharp currently does not support the Streaming API, which is a major drawback and the reason why I am sticking with Twitterizer for now.

I recommend using the latest 2.3.1 source code of Twitterizer.

Small but important note: Twitterizer's team is not currently officially supporting the Streaming API, so to use it (in assembly Twitterizer2.Streaming) - comment out the following line at the end of TwitterStream.StartStream:

request.Abort();

Otherwise - it will not work.

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

I hate saying "I told you so"... ;)

5 months ago I tweeted:




And yesterday it was announced that Google is buying fflick.

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co