If you live in Northern California there’s a good chance you work at a startup, at least the odds are probably higher than the national average. There’s also a good chance that you surf, that’s just what we do here. You may even be one of those fortunate people like myself that do both. If so, you’ve likely drawn your own comparisons between the two. Either way I’m pretty sure you’ll join me in stating that both are awesome. So here’s my attempt to articulate that awesomeness via a series of comparison.

Failing Fast
When you’re trying to stand up on a wave it doesn’t take you very long to find out if things are going to work out. Sometimes you don’t even catch the wave, other times you catch it, standup and end up going face first into ocean. Those waves suck and you find that out really quick. With startups failing fast is something you want to do. If your business isn’t going to work out you’d like your proverbial face to hit ocean before you’ve sunk tons of cash and time into it.

Competition
Competition for a wave can be brutal. A common misconception people have about surfers is that they’re mellow and laid back. Just not true. If you get in between a surfer and their wave you might just end up getting shanked in the parking lot. Ok, so shanking’s a bit extreme but they’ll probably throw a couple of f-bombs your way. Another excuse for a shanking? Try getting between a big company and their profits. Actually making money as an early stage startup is tough! You’ve just gotten into the game and the other guys are bigger and have more resources. In both cases though competition is an excuse to kick more ass and get better. Over time you will catch more waves and hopefully your startup will also make money.

The Drop
The drop is awesome. It’s the moment a surfer hops up on their board, stares down the wave and drops over the edge. It’s exhilarating and addictive. It’s also the point of no return. Once you’re up on your board heading down a wave you can’t bail out without getting pummeled. When you join a startup there’s always a point of no return. For some, the drop might be the moment they decide to leave their stable, higher paying job to join a company that might not even be around in a year. Speaking strictly from my own experience this was one of the most exciting times of my life.

Adrenaline
Working at a startup has been a ridiculous thrill. Every day there’s something new: a new feature pushed, app going live in the app store, a new website, a new employee. The list could literally go on and on. It’s like catching the drop off of a wave. You’re going so fast you think you might fall right off the board, and sometimes you do. But sometimes you don’t and it’s freakin’ awesome!

The problem is there are way more people looking for apartments in SF than there are apartments, or bed rooms, or closets even. I have no idea how long this has persisted, as far as I know this may or may not, just be how it goes. Nevertheless, it’s not unusual to show up to an open house and find 30 other people there, luggage in tow, ready to stab anyone who gets in between them and their precious 1 bedroom with walk-in closet and brightly lit kitchen area. Like I said, brutal, it’s less apartment shopping and more like tenant shopping. The property owners get more applications than they need to fill the apartment so they’re at the advantage of picking and choosing the lucky winner of an exorbitant rent payment, 300 square feet and a parking space that only exists every other Tuesday at 1:00pm.

So maybe you’ve decided you’re ready to suck it up and damn it… you’re going to live in San Francisco. Well, I hear you, obviously that’s what I’ve done so I understand all the reasoning behind it. If that’s the case I have a few tips that just might make your search a bit less painful, provided you avoid getting stabbed by fellow applicants:

Tip #1: Credit Report With Credit Score. This is the best move I made. Get yourself over to annualcreditreport.com and get your free credit report. Then pay the extra $8 or so to get your FICA score. Why? For starters every place you visit will ask for it. It will save you money because you don’t have to pay a fee for each place to run your credit. This also means your credit doesn’t get dinged 50 times after you’ve submitted applications all over the city. Finally, it makes the process smoother for the property owner and anything you can do to make things easier for them is a gold star in your favor.

Tip #2: Be There First. With all the competition you’ve gotta set yourself apart from the masses and also beat them to the punch. One really good way to do this, and also say “Hi, I’m genuinely interested and responsible” is to show up first. At open houses get there early so you can be at the front of the line (cuz you know there’s a line). Also, check CraigsList multiple times a day. Posts are added throughout the day and if something’s more than 24 hours old, the masses are all over it by then.

Tip #3: Your Rental Resume. I already mentioned the credit report but there’s a few other things you should bring with you. The items that should make up your rental resume are as follows:

• Credit Report with Score (already mentioned this one)
• Pre-Filled San Francisco Rental Application
• Copy of Last Paystub
• Copy of Drivers License

I’ve found that the SF Rental Application suffices for nearly everybody, even those companies that have their own application form. Having all of this on hand will make the application process smooth, and saves you and the property owner lots of time (especially you!). I printed out copies of each of these along with a coversheet that included my contact information and put it all in individual plastic folders. Now when I want to apply I just give them one of the folders with everything they need. I’m overly process oriented at times and I haven’t seen anyone else do this but it definitely shows you’ve got your shit together and has saved me enough time to write a blog post about it.

Tip #4: Dress It Up. When you go to an open house or a walk through dress it up a bit. You don’t want to look like you’re already homeless (even if you are), that only raises the question in their mind as to why you’re homeless. Maybe cuz this guy doesn’t pay his rent? Instead your clothes should say “Hi, I’m super responsible and always pay bills on time. I just came from a really responsible meeting where I was doing extremely responsible things. You know, like paying bills and getting paid lots of money.” Yeah, dress like that.

Tip #5: Follow Up. You don’t want to get lost in the shuffle. After the meeting follow up with an email or phone call and just ask if there’s anything else you can provide and make sure they know who you are. If it was an open house, tie it back to the meeting and refer to something recognizable. Part of this process is likability, you’re not very likable if they don’t know who you are.

Good luck with your search. If you’ll join me in following these few simple tips, together we can end homelessness. Probably not for the guy talking to the bushes and camping in Golden Gate Park but at least for ourselves.

If you don’t have your very own Arduino yet you should get one. What exactly are you waiting for? Arduinos are tons of fun, especially once you hook up some servos and start driving them around. Add a few pieces of military grade weaponry and you have your very own deathbot!

One of the first things you have to figure out once you’ve decided to personally catalyze the robot apocalypse is how to remotely control your robots, i.e. tell them when to turn left, turn right, stop, and of course… fire rocket launchers. There’s a number of ways you could do this. One of the more common I’ve seen is to open up a server port on your Arduino, connect to it and send it messages directly. The problem I ran into doing this was two fold: 1) I have to know the IP address of the Arduino on my network to make the connection and 2) I have to be on the same network as the Arduino. None of these things are very convenient and IP addresses and networks can change.

The solution I came up with was to use Pusher, a real-time push notification service that runs over WebSockets. Since the native Arduino libraries come with support for TCP connections, making this work involved writing a WebSocket Client library, as one does not appear to have previously existed, and building a Pusher client on top of that. Because the Arduino is connected to a Pusher Channel I don’t have to know anything about the actual device to control it, I just send messages to the Channel. My mechanized Arduinos of destruction are free to roam around, switching networks and destroying civilization, meanwhile I can still control them with my iPad from a hammock in the Bahamas.

Building the WebSocket Client

WebSockets are an interesting hybrid between HTTP and raw TCP connections. They start life very much like a normal HTTP GET request. In the request the client sends a bit information asking for an “upgraded” connection. Once the server sees this, if WebSockets are supported it sends a response back with a status code of 101 indicating that the connection was successfully upgraded. Then, and here’s where things diverge from HTTP, nobody closes the connection. Both the client and the server remain connected to each other. Here’s what this looks like at the socket level:

Client Requests a WebSocket Connection

GET /app/yourpusherapikey?client=js&version=1.9.0 HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: ws.pusherapp.com:80
Origin: ArduinoWebSocketClient

Server responds indicating that the upgrade was successful

HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: ArduinoWebSocketClient
WebSocket-Location: ws://ws.pusherapp.com:80/app/yourpusherapikey?client=js&version=1.9.0
Connected

Now that they’re connected both the client and the server can send each other messages any time they want using a process called Data Framing. Data Framing is a protocol for indicating the start and end of discrete messages on the socket. The Arduino Websocket Client Library currently only supports Text Frames, which use a 0×00 byte to indicate the start of a message, a 0xFF byte to indicate the end, and UTF-8 data in between. The WebSocket Specification also allows for Binary Frames, which use a length prefix followed by binary data. Here’s what the Arduino code looks like for sending a WebSocket message:

void  WebSocketClient::send (String data) {
     _client.print((char )0 );
     _client.print(data);
     _client.print((char )255 );
}

Building the Pusher Client As I mentioned before Pusher is a real-time push notification service that operates over WebSockets. Like any WebSocket implementation they use Data Framing for passing messages back and forth but they’ve built their own messaging protocol on top of Data Framing. Each message sent to or received from Pusher is formatted as JSON. This is good for the Arduino because JSON is light weight and also easy to parse. Once the Arduino WebSocket Client was built developing the Arduino Pusher Client was a matter of implementing support for sending/receiving the right messages.

Sending a message is called “Triggering An Event”:

void PusherClient::triggerEvent(String eventName, String eventData) {
    _client.send("{\"event\": \"" + eventName + "\", \"data\": " + eventData + " }");
}

Receiving a message from Pusher:

void  PusherClient::dataArrived(WebSocketClient client, String data) {
     String eventNameStart = "event" ;
     String eventName = parseMessageMember("event" , data); 

     if  (_bindAllDelegate != NULL ) {
         _bindAllDelegate(data);
     } 

     EventDelegate delegate = _bindMap.getValueOf(eventName);
     if  (delegate != NULL ) {
         delegate(data);
     }
}

Controlling our servos of destruction in response to events received from Pusher:

PusherClient client("your-api-key-here");

//Setup delegates for the Pusher Events
client.bind("forward", moveForward);
client.bind("backward", moveBackward);
client.bind("turn_left", turnLeft);
client.bind("turn_right", turnRight);
client.bind("stop", stopMoving);

//Subsribe to our Pusher Channel
client.subscribe("robot_channel");

void moveForward(String data) {
  leftServo.write(0);
  rightServo.write(180);
}

void moveBackward(String data) {
  leftServo.write(180);
  rightServo.write(0);
}

void turnLeft(String data) {
  leftServo.write(0);
  rightServo.write(0);
}

void turnRight(String data) {
  leftServo.write(180);
  rightServo.write(180);
}

void stopMoving(String data) {
  leftServo.write(95);
  rightServo.write(95);
}

All Wired Up

We’ve now solved what is likely the most challenging part of developing your Arduino army.

Pusher messages being received:

Tremble in fear of the Pusher Powered Arduino-Bot:

It’s magic and it works. So what’s the problem? The problem is we currently solve this notification challenge by having the Connector poll our web service. This is less than optimal for a number of reasons: 1) This places a significant (seriously…) load on our backend infrastructure 2) This introduces latency because the Connector is polling on an interval. Finding a better solution is difficult because most of these Connector installations are sitting behind firewalls and are on a consumer’s home network. This means you can’t expect any additional setup other than installation of the software so any sort of direct connection initiating from the server is out of the question.

So what’s option 3? In a word Websockets. This nifty little protocol has silently made its way into web browsers and web servers over the last few years. It’s most common use case is allowing servers to send messages to web browsers, allowing the display of real time data and notifications. Web Sockets are similar to long lived HTTP connections except that they allow bi-directional messaging between both the client and the server. After the initial handshake the connection is “upgraded” after which time data is exchanged using a process known as Data Framing. Websockets also run over HTTP/S ports 80 and 443 so there’s no worry that they’ll be blocked by firewalls. For these reasons Websockets are also a great solution to our Connector’s polling problem.

Cool, so Websockets, now what? We could have built a Websocket server that’s capable of handling thousands of live connections at a time, implemented a nice security layer and defined our own messaging protocol but… that’s a lot of work. It’s a beautiful world we live in where people build these sorts of things for us and let us use them. That’s where Pusher came in.

Why did we choose Pusher?
Pusher didn’t just save us time it made refactoring our architecture possible. The work required to implement a notifications infrastructure that would handle our traffic requirements is simply intractable for us. Furthermore, out of the box it has many of the less obvious features we needed like security, presence information and a well documented messaging protocol.

What problems did Pusher solve?
Pusher allowed us to offload the vast majority of our backend traffic to their notifications infrastructure. This will result in significantly improved performance and dramatically lower costs as we scale. Furthermore, this adds value to our customers because we can print a document in “real-time” rather than forcing them to wait several seconds for the next poll.

What was missing from Pusher?
One feature I’d like to see added is the ability to receive callbacks when clients connect to a Channel. This would help us keep track of what Connectors are actively connected and ready to receive notifications. Currently our workaround is a process that is constantly checking with the Pusher API to see who’s active. This has been somewhat time consuming and challenging to develop, it’d be nice if we could remove this “moving part” in the future. I’ve talked to some of the Pusher guys and it sounds like this is on their near-term roadmap, definitely looking forward to seeing it.

Also, they seem to have their client libraries separated into Client and Server functionality. This provided a bit of a challenge for us because we needed some of the “client” functionality available from our backend which is written in Rails. This meant that we had to add this functionality to the Pusher gem, also a bit time consuming. For our scenario it would have been nice to see a single gem that encompassed both client and server functionality but frankly I’m not sure how common that is.

If your app only has one View, your app is probably pretty boring. However, if you’re building an interesting app you’ll probably have to switch between multiple Views, maybe go back and forth and have some nice animations. You could write your animations and manually do the transitioning yourself but once you get more than 2 or so Views that’s gonna get tough to keep up with (and messy!). Fortunately the ViewFlipper solves this problem quite nicely.

Step 1.

Let’s start all the way at the beginning, File -> New Android Project. Feel free to use your own Application and Package Names but make sure you tell it to create a MainActivity. This will be the Activity that controls the transition between Views.

Step 2.

Once you get your project set up you’ll need to add a ViewFlipper to main.xml. In this example we’ll also add a couple of buttons that let us go back and forth between our Views.

main.xml

Step 3.

Next in MainActivity ‘s onCreate method, wire up ClickHandlers to the Buttons and use the ViewFlipper’s showNext() and showPrevious() methods to move between Views.

MainActivity

Step 4.

Now, if all you wanted was a simple transition between Views you could stop now. However, that would be… boring and we can do a heck of a lot better by adding a nice slide transition. To make this work we’ll use the 4 animations below. These allow us to slide in and out from either direction depending on whether we’re going forward or backward and they also add a very subtle alpha fade in and fade out. If you’re interested in checking out other types of animations look no further than your Android SDK directory: Android_SDK\Platform\android-{version}\samples\ApiDemos\res\anim

view_transition_in_left.xml

view_transition_in_right.xml

view_transition_out_left.xml

view_transition_out_right.xml

Step 5.

Finally, we need to update MainActivity to set the ViewFlipper’s inAnimation and outAnimation properties. We’ll use a slide in from the left when the user clicks “Next” and we’ll slide in from the right when the user clicks “Previous”.

Finally, run your app and behold the wonder that is the ViewFlipper sliding your Views in and out!

Splash Screens are a common feature of many apps. They’re a nice way to show off the awesomeness that is your logo or maybe just dazzle your users with some eye candy while your app downloads things from the web, crunches numbers, or calculates the 2000th digit of the number pi. Whatever your reasons are for building a Splash Screen you’d probably like it to have a few nice features. This example shows how to build a Splash Screen that removes the title bar, fixes the screen in Portrait layout and prevents the user’s back button from returning them to the Splash Screen.

Step 1.

Let’s start all the way at the beginning, File -> New Android Project. Feel free to use your own Application and Package Names but make sure you tell it to create a SplashActivity. This will be the brains of our Splash Screen.

Step 2.

We need to add another Activity to our application that we can transition to when our Splash Screen is done. Add a new Activity named MainActivity and create a new layout XML file named splash.xml. Then configure the SplashActivity to use the splash.xml file for it’s layout and the MainActivity to use main.xml. If you’d like to make changes to these layout files to spruce things up go ahead. For this example I’ve added an image to the SplashActivity and changed the text in main.xml to read “Hello World, MainActivity!”

Here’s what your package should look like.

MainActivity

SplashActivity

Step 3.

Once your project is set up, open SplashActivity.java and we’ll make a few changes. Add a variable named splashDelay to hold the length of time to keep the Splash Screen up. Then we’ll use a Timer and a TimerTask to help us schedule the transition to MainActivity. Note that before starting the new Activity we call the finish() method on the SplashActivity. This prevents the user from being able to use the back button to return to this Activity.

Step 4.

Finally, we need to make two changes to AndroidManifest.xml. Set the application element’s theme attribute to Theme.NoTitleBar to get rid of the Title Bar and on the SplashActivity’s activity element, set the screenOrientation attribute to portrait to fix the SplashScreen to portrait layout.

And finally our Splash Screen.

Intro

July 7^th marked the release date of the 2^nd version of the Silverlight Media Framework, aka SMF, aka the Smurf. It was such a big deal that everyone took Monday off of work and celebrated over the weekend with fireworks and BBQ’s! What? Didn’t hear about it? Busy celebrating some other holiday? Well then check it out, no it’s cool I’ll wait…

Ok, now that you’ve built your first Silverlight video player capable of handling huge online video events like SNF and the Olympics I think we can move on. So while technically this wasn’t a national holiday it was still a great day for a very cool framework. Of course I toss around words like “great” and “very cool” but admittedly I am a little biased given that I’m the project lead. Nevertheless, we’ve been getting some good feedback and I’m constantly hearing about new projects spinning up that are using SMF. Take a look at the forums, there are many smart folks building innovative video projects. One of the coolest I’ve seen recently is Nascar 3D. By the way, if you’re one of those folks who happen to post in the forums give me a shout via twitter some time. I try to reply quickly but, unfortunately I have to sleep sometimes, and I have a girlfriend, she prefers my eyes be glued to her and not the monitor sometimes J

One of my favorite new features in SMF v2 is definitely the plugin framework. SMF has a number of extensibility points you can plug into, like adding on screen UI elements, Logging, and supporting the playback of new types of media. What makes this really interesting to me is the built in ability to support downloading plugins over the network, thanks to integration with MEF. This allows developers to easily share and distribute plugins for SMF.

For a while now, I’ve had an idea of my own for a plugin that would integrate SMF with social media networks. What I want it to do is let users easily share a link to, not just the video, but the position in the video that they’re watching at that moment. Let’s take a quick look at how to do this.

Step 1. Build the Control

The control itself is pretty straight forward. It’s a horizontal StackPanel with a series of buttons, one for each network: Twitter, Facebook, LinkedIn, Delicious, and Email (not really a social network but still a cool way to share video). When the user clicks on a button, we build the URL that we’re going to share and launch a popup window that allows them to post to the network they clicked on. Each network has a different URL, I used this site to get the format needed to support each of the ones I’m using here.

Step 2. The SMF Plugin

As I mentioned, SMF supports a number of plugin types. Implementing a plugin has two parts: 1) Implement the interface and 2) Add the Export Attribute. In case you’re wondering what #2 is all about, SMF uses MEF (Managed Extensibility Framework) to discover and load plugins. A discussion of MEF is well outside of the scope of this post but it’s a very useful framework and I owe Glenn Block a public “thanks” for his guidance on using MEF to build a plugin framework.

For this example I’m implementing a Generic Plugin, which gives me a reference to the SMFPlayer instance. When my plugin gets a reference to the player I search the visual children for a Grid named PlayerRoot and add SocialSmurf to its children. To do this I need to implement the IGenericPlugin interface and add the ExportGenericPluginAttribute to my class. All SMF plugin attributes take as parameters the name, description, and version of my plugin.

Step 3. Supporting the PluginUrl InitParam and “Link To Position”

The SMF v2 release on CodePlex includes two prepackaged XAP files, one for Smooth Streaming and a smaller one that only supports Progressive Download. This allows you to easily embed the SMF player into your web site without having to write a line of code or even open Visual Studio. Instead you can configure the player using init params in your HTML file. One of my goals for this plugin was to make it as easy as possible to load into an SMF application and to do this I wanted a prepackaged XAP file that would support the loading of plugins via init params as well. Since this feature isn’t currently supported in the public version of SMF I decided to tweak the existing Smooth Streaming Player and add this feature.

Finally, I wanted to support “Link To Position”, letting users share specific positions within the video. Supporting this is pretty simple, I just check the query string for a variable named “position” and parse it the value into a TimeSpan.  After that, I wait for the Player’s MediaOpened event to fire and call SeekToPosition(…) on the player setting it to the specified position.

Summary

This was pretty quick and easy, I think I had a functional prototype up and working in about an hour.  The most time consuming part was, by far, doing the string parsing necessary to create the URLs that launch the different social media sites.  Also, adding the position to the URL was tricky as well given edge cases, like when there are already parameters on the query string.  There’s probably a better way to do this but it did the job.  The SMF integration was a piece of cake, however, I must admit that I do have an unfair advantage given my hand in writing it.  That said, I’d love to hear any feedback.  Is this really easy to the average dev?  How could something like this be made better??  Seriously, I’d love to know!   Also, if you think this is a generally useful plugin let me know if you have any feature ideas.

To add this plugin to your SMF application:

Uri pluginSource = new Uri(““http://www.enginexp.com/files/socialsmurf/socialsmurf.zip””)
player.BeginAddExternalPlugins(pluginSource);

To include this player in your site, add the following HTML snippet:

<object data=”data:application/x-silverlight-2,” type=”application/x-silverlight-2″ width=”100%” height=”100%”>
<param name=”source” value=”http://www.enginexp.com/files/socialsmurf/pluggablesmoothstreamingplayer.zip”/>
<param name=”minRuntimeVersion” value=”4.0.50401.0″ />
<param name=”InitParams” value=”pluginurl=http://www.enginexp.com/files/socialsmurf/socialsmurf.zip,
mediaurl=[Insert Your Video Url Here]“ />
</object>

CREATE PROCEDURE SearchLocation (
    @SearchLatitude decimal(12, 8),
    @SearchLongitude decimal(12, 8),
    @Distance decimal(12, 8))
AS
BEGIN
    SET NOCOUNT ON

    SELECT  l.UserId
    FROM    Location l
    WHERE   l.LocationPosition.STDistance(geography::Point(@SearchLatitude, @SearchLongitude, 4326)) < @Distance
END