Broken Build Alarm Using RPi And Custom PCB

TLDR: Checkout this Github repoRPi CodeEagle BoardBOM

Anybody who knows anything about CI, knows that a great CI system is the one that really goes out of it’s way to make sure your team know when builds are broken; furthermore, the more obnoxious the alerting mechanism is, the better.  At we were looking for a cool way to bring this nugget of wisdom home and use it as an excuse for a cool hack project.  Thus was born a project to wire up this truly annoying strobe light to the API so the team knows when there’s a broken build that needs mending.  Here’s the general idea:

There were 3 main pieces to building this project: 1) The API which was used to check for broken builds.  2) The Strobe light (most important part) and 3) A Raspberry Pi which was used to poll the API and trigger the strobe light.  Fortunately, we had a Raspberry Pi already sitting around the office running an analytics dashboard.  All that was necessary to integrate w/ the API was to write a little bit of Python (super easy).

However, the real trick came when we attempted to wire up the Strobe light to the Raspberry Pi.  Turns out the RPi GPIO pins run 3V but this Strobe light requires 12V.  This completely makes sense given how bright and awfully annoying it is.  It’s hard to drive that amount of irritation on only 3V.  Furthermore, the current limitation on these pins is pretty low as well.  Another solution was needed.

Enter the N-Channel MOSFET.  If you’ve never encountered the magic that is the MOSFET, I strongly recommend reading up on these things a bit.  You’ll find that these are basically the atomic building blocks that make computers go.  In fact, if you were so inclined you could wire a bunch of these guys up and make your own logic gates.

All that tangent aside, that’s not what we were planning to use it for.  The basic function that a MOSFET performs (gross simplification here), is it let’s you switch one Voltage Source (VDS) on/off using another Voltage Source (VGS).  Also, this VDS Voltage Source can be a (much) higher voltage than VGS, the switching voltage.  At this point you can probably see where I’m going with this.  Basically we needed to introduce a MOSFET between the RPi and the Strobe light, with a 12V power source and we’d be golden.

So, that’s exactly what we did.   And damn, it was super cool when that Strobe light went off, triggered by our RPi and powered by the 12V power source!  In fact, here’s the first iteration, cobbled together using a breadboard.

Ok, so at this point we could have stopped.  However, not only were all these dangling wires ugly and potentially “dangerous”, but this was also a great opportunity to put together a nice custom PCB to clean this up.  So, to that end I used Eagle CAD to design a simple PCB to replicate the circuit from the breadboard.  The components on this board included:

  • Barrel Jack for accepting the 12V power source from a wall wart plug.
  • The MOSFET itself situated right in the middle of the board.
  • A Pull-Down resistor, necessary to keep the Gate voltage from floating
  • 6-Pin header for connecting the RPi output and the terminals from the Strobe light

If you’re not familiar with Eagle, or making PCB’s, I strongly recommend checking out Sparkfun’s online tutorials.  This is the one that got me started.  My background is software (not hardware); nevertheless, I found this whole process much more tractable than I originally thought.  Furthermore, every time you get a new PCB in the mail it’s kind of like Christmas, so long as it works.

Once I had my design ready to go, I uploaded it to OSH Park and waited for it to arrive in the mail, which took about 2 weeks.  Once it came, I soldered all the parts (from Sparkfun) and plugged it into the RPi, and… it didn’t work.  Turns out I wired the pull-down resistor wrong.  Crap, well, that’s just how it goes.  It’s all good though b/c the 2nd rev worked beautifully!

So, admittedly this was overkill to make an obnoxious Strobe light flash when a build breaks.  More to the point though, this was a great opportunity to learn about designing circuits with MOSFETs.  It was a super fun project and I strongly encourage more software folks to play with PCB design.  It’s incredibly fun and at times even useful!

Selling My First Company

I’m pretty excited to announce that I recently sold cisimple to ElectricCloud. In fact, at this very moment, they are in the process of getting everything back up and running, and with lots of improvements I might add. cisimple is also being rebranded to and is entering public beta as of today. My involvement going forward will be transitioning to an advisory role with the company once everything is off the ground.

This was my first company and I’ve got to say, navigating the acquisition process was a bit like stumbling around in a dark room. Fortunately, I didn’t fall face first on any proverbial coffee tables but I definitely stubbed my metaphorical toe a few times. I also noticed that there are really very few blog posts out there that discuss the mechanics of the acquisition process. And, while mileage is likely to vary substantially for different companies/founders, I figured I would share a few things that I’ve learned over the last few months.

Acquisition Type
First, there are two common types of “acquisitions”: Stock Purchase Acquisitions and Asset Purchases. The first occurs when the buyer purchases all of the selling company’s stock. This is a complete acquisition of the selling company and is usually the simplest, mechanically speaking. An Asset Purchase on the other hand is when the buyer purchases all of the selling company’s assets. This is still often times referred to as an acquisition because in most cases all of the assets required to run the business are purchased (i.e. product, office furniture, etc.) effectively transferring ownership of the company.

As a founder, it’s helpful to understand the differences between these two. Stock Purchase Acquisitions, for example, are typically much more friendly to the Seller. Aside from being mechanically simpler, standing contracts and agreements (partnerships, office space leases, etc.) that the Seller has in place will not be affected. Note, that “change of control” clauses will definitely apply here so any agreements you have in place might be impacted in that sense. A Stock Purchase also results in a more favorable tax situation for the shareholders. In fact, if you’ve owned your equity for more than a year… Congratulations! You’re probably going to get a long-term capital gains rate.

By the way, this is a good time to mention that I am in no way a tax/legal professional. Not even close… Seriously.

Asset Purchase acquisitions however, are often times preferred by Buyers because they come with less “baggage”. Since only the assets are being purchased, any agreement you previously had in place with Partner X may have to be renegotiated with the Buying company. Also, any employees working at Seller Co. will have to be hired by Buyer Co., which is not a terribly comfortable place for people to be in. Finally, with an Asset Purchase the sale is treated as regular income for the company, which means you’ll be spending a lot more in taxes.

The reality is that which type of acquisition a Buyer and Seller agree to is going to be driven by many factors. If the Buyer wants the team, the product and is comfortable with any of the legal risks introduced by the Seller then it’s unlikely they would object to a Stock Purchase. In fact, they’re likely to prefer it since it’s simpler. In any case though, I think it’s worth being educated about the implications of either approach. In the least it’s something that can help protect you when you’re negotiating the size and mechanics of the deal.

As part of any acquisition, there’s going to be a diligence phase, during which the Buyer vets the Seller. This period can take quite a bit of time and a lot of work from both sides. It also has the potential to be very expensive since lawyers will almost certainly be involved. I strongly recommend negotiating up front for the Buyer to cover all legal expenses. It’s likely that they’ll try to cap it but try to avoid it if you can since it’s tough to predict how much lawyer time you’ll need. Besides, they’re the larger company anyway, and if they’re looking to make this acquisition they can afford it.

There are several types of diligence that we covered during the cisimple sale:
1. Intellectual Property
2. Business Metrics
3. Product/Technology

The first step was to verify that I, or rather the company, actually had a legal right to sell the Intellectual Property. This is one of those times when you’ll be glad you’re great at keeping your records organized. Fortunately, while my desk is a bit of a mess, I was pretty religious about keeping every document involved with the running of the company around: Employment Agreements, Contractor Agreements, Advisor Agreements, Investor Notes, etc.

It’s also highly likely that if your product is a software application, it will be subjected to an Open Source software scan. While these are well intentioned, they can be a nightmare of tracking down licenses for every font/Ruby gem you use in your product and even documenting every 3rd party product you mention on your blog. I’ll just say that it’s a good idea to keep this stuff documented but in no way is it sane to reach the level of documentation required to completely pass one of these scans.

The next step of the diligence process involved analyzing metrics around the running of the business. A couple of key pieces of information were MRR (Monthly Recurring Revenue/Customer), burn rate, and the customer funnel. These are obviously, all things any SaaS founder should be keeping an eye on however, it’s also incredibly helpful to have the backing data easily accessible as well. In the very least, I strongly recommend being able to rattle off these numbers from memory as I found them to be an important part of the negotiation process.

Have a good lawyer
Finally, I can’t stress how important it is to have a lawyer that has your back. Unless you passed the Bar yourself, you’re bound to run up against something you don’t know. Fortunately, Gary Marshall from WSGR was awesome and I don’t know how I would have pulled it off without him. When it comes to the finer points of negotiating a Purchase Agreement, you definitely want to have someone on your side that has seen a lot of them. After all, your Buyer definitely will.

What’s Next?
So what am I up to now? Well, I’m helping ElectricCloud get off the ground for starters. I’m also involved with a handful of really exciting consulting projects, most of which are in the IoT space involving hardware and BLE. I always love hearing about new projects/startup ideas so if you want to grab a coffee some time give me a shout:

Don’t Over-Engineer Your Engineering Team

As I write this I’m taking a bit of time between jobs.  I decided to take a couple of weeks off to, you know… write blog posts and hack on some stuff.  I won’t get into my reasons for leaving Breezy but it was an amiable separation.  I’ll likely post on this some time down the road. 

Working as CTO in a seed stage startup, was probably about the most fun I’ve ever had at any job.  Actually, I’m not even sure I’d call it a job.  Sure, I got paid, but I was getting to do what I love (build stuff) and hang out with other smart people doing the same.  Most of the time it didn’t feel like a job.

I could go on about things I’ve learned over the last year but one thing I found myself thinking about a lot was what engineering practices we should follow.  You know, should unit tests be required for all of our products?  How do we do QA?  What about deployments? etc.  These sorts of questions didn’t keep me up at night but they were genuine problems to solve and fun ones at that.

A bit about my background:  Ignoring all the random jobs I did before my first engineering gig (pond installations, lifeguard, server, etc.), my “career” in software officially started at Walt Disney World.  This place was about as far from a startup as anyone could contrive.  Hundreds of engineers, cubicles, change control policies. It defined enterprise.  After that I spent some time at Vertigo Software, relatively speaking a much smaller shop with about 50 people.  These guys operate very differently and move much more quickly.  It was an enlightening adjustment.

Having worked in both large and small environments (and medium-ish) I think I’ve become very pragmatic about engineering practices.  What I mean by that is there’s no religion to it.  There are no absolutes. I refute any argument that certain engineering practices should always be followed because it’s the “right” way.  Frankly, that would be too easy an answer.  As with most things in life, pragmatic engineering is about maximizing for the right variable at the right time.


Optimizing for Ship Time

When I started at Breezy, we were a small team.  I mean really small, as in just the founder (Jared Hansen) and myself.  He was working on scaring up some customers, meanwhile we needed a product people could touch ASAP.  I wrote a lot of code those days building out our Rails API, our Windows app, etc.  Jared and I both split QA responsibilities and deployments were typically pushed right after the code was committed.  It was strategically expensive to do anything that wasn’t product so very few unit tests were written.  Also, because it was such a small team things like branching strategies had very little value.

Implementing Process

After our MVP (Minimum Viable Product) shipped and our team grew, eventually reaching 5 engineers, a few things changed.  When our intern started, his first task was to retro-fit our API with unit tests.  This added immediate value and helped us discover a few bugs.  More importantly, we were able to refactor with confidence and going forward all new API development happened with unit tests.

Another huge process improvement was the addition of Continuous Integration.  Our Windows application had 4 different builds: 2 distributions (Enterprise & Consumer) x 2 environments (PROD & TEST).  Our Android application had 3 builds: DEV, Marketplace, and Enterprise.  We also had a similar build configuration for Blackberry but unfortunately never got around to setting it up for iOS.  Having all of this automated saved huge amounts of time.  Furthermore, it decreased the likelihood that human intervention would introduce errors into some build destined for Production.


Process Levers

There were two levers that I saw impacting how much process we implemented.  The first was product stage.  Early in the game, having something to show interested, potential customers was more important than worrying about how easy it would be to refactor a given piece of code.  We were building an MVP and that has a very different set of goals associated with it than a piece of software for a company that has, well… revenue.

The second, and in my opinion more significant one, was team size.  I think you reach a point at which, no matter what stage your company or product is at, some process is needed to manage the complexity.  Things like branching strategies and standups are very useful for any team larger than 2 engineers for example.  You get a greater degree of flexibility if the team members are developing on independent products.  However, within the same company, especially at a startup, that’s rarely the case.


Process Components

Here’s a short list of a few elements that made up our engineering processes.  There are several more I could add to the list (standups, backup schedules, etc.) but these stood out as being more significant.

Task/Bug Tracking – I can’t understate the importance of having a solid process in place for tracking on a task list (or backlog).  When things kicked off a Breezy I started by using a spreadsheet.  We also wrote tons of lists all over our walls.  At the time our office walls were covered in IdeaPaint so we had significant amounts of whiteboard square footage!  I eventually started using a combination of Pivotal and Asana, which are great solutions to this problem but support slightly different use cases (more on that in another post).

Automated Builds – As I mentioned earlier, setting up a Continuous Integration/Automated Build process was a huge process improvement that saved us significant amounts of time. One downside to CI though is that it’s expensive to setup and maintain, and I mean that from an “engineer-time” perspective.  I think our setup was pretty typical, EC2 + Jenkins, but when you factor in environment configuration and maintenance, it adds up.  While I would have liked to have had it earlier it was set up about 3 months into the game (post – MVP).

Unit Testing – Few things inspire crusade-like fervor within engineers quite like the debate over unit testing.  My humble opinion is that Unit Tests are very useful, but they’re also expensive.  For some products/teams they are affordable, however for some they are not.  When we were pre-MVP we could not afford to build unit tests and so none were written.  They were eventually retro-fitted to our Rails API but we never wrote them for our mobile applications.  I’ve been asked if looking back I feel like this was the right decision and I do.


Engineering Your Engineering Team

It seems to me that there are many approaches to building software.  In my opinion, different approaches simply seek to optimize different variables.  The best engineers I’ve seen are the ones that are able to shift between approaches at the right times.  Building a good software product (quickly) is a complex equation and there are no right or wrong ways to do it, only more and less efficient approaches.  I think the same goes for building an engineering team.

My Fight Against Homelessness – Apartment Hunting in San Francisco

Let’s face it, apartment hunting is one of those somewhat unpleasant things that perpetual renters have to do every once in a while, kind of like going to the dentist or spending the weekend with your parents (love you mom!). There’s the paperwork, the phone calls, open houses… If you’re shopping in San Francisco you’re probably putting more hours into your search than the realtors that are trying to sell the place to you! Admittedly it’s not all bad, the prospect of moving into a new place can be quite exciting. A new neighborhood means new restaurants and shops nearby, especially in SF, and your apartment is never as clean as when you first move in. Nevertheless, apartment shopping in SF right now is brutal!

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

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.

World Domination Using Arduinos and Websockets

Arduino Websocket Client Arduino Pusher Client Pusher – Real Time Push Notifications Follow Me On Twitter: @kevinrohling

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

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 0x00 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((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 ) { 

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

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

void moveForward(String data) {

void moveBackward(String data) {

void turnLeft(String data) {

void turnRight(String data) {

void stopMoving(String data) {

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:

Polling is Evil, Start Pushing

It’s an exciting time to be working at Breezy right now. We’re past the initial rush to build our MVP and can finally loop back around and focus on making things more awesome. One of the biggest challenges we’ve had to solve is how we notify our Connector applications that documents are ready to print. A bit of context, the Connector is a piece of software that sits on desktop PC’s that have printers. When a user chooses to print to a printer that’s “connected” to this PC we notify the Connector and it does the work of actually sending the document to the printer.

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.

Using a Slide Transition with the Android ViewFlipper

Github Repo

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.


1 <?xml version=”1.0″ encoding=”utf-8″?> 2 <LinearLayout xmlns:android=”; 3 android:orientation=”vertical” 4 android:layout_width=”fill_parent” 5 android:layout_height=”fill_parent”> 6 7 <LinearLayout android:orientation=”horizontal” 8 android:layout_width=”fill_parent” 9 android:layout_height=”wrap_content”>10 <Button android:id=”@+id/previousButton”11 android:text=”Previous”12 android:layout_width=”wrap_content”13 android:layout_height=”wrap_content”/>14 <Button android:id=”@+id/nextButton”15 android:text=”Next”16 android:layout_width=”wrap_content”17 android:layout_height=”wrap_content”/>18 </LinearLayout>19 20 <ViewFlipper android:id=”@+id/viewFlipper”21 android:layout_width=”fill_parent”22 android:layout_height=”fill_parent”>23 <TextView android:layout_width=”fill_parent”24 android:layout_height=”wrap_content”25 android:text=”View 1″/>26 <TextView android:layout_width=”fill_parent”27 android:layout_height=”wrap_content”28 android:text=”View 2″/>29 <TextView android:layout_width=”fill_parent”30 android:layout_height=”wrap_content”31 android:text=”View 3″/>32 </ViewFlipper>33 </LinearLayout>34

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.


1 publicvoid onCreate(Bundle savedInstanceState) { 2 super.onCreate(savedInstanceState); 3 setContentView(R.layout.main); 4 5 final ViewFlipper viewFlipper = (ViewFlipper)findViewById(; 6 7 Button nextButton = (Button) this.findViewById(; 8 nextButton.setOnClickListener(new OnClickListener() 9 { 10 11 @Override 12 publicvoid onClick(View v) { 13 viewFlipper.showNext(); 14 } 15 16 }); 17 18 Button previousButton = (Button) this.findViewById(; 19 previousButton.setOnClickListener(new OnClickListener() 20 { 21 22 @Override 23 publicvoid onClick(View v) { 24 viewFlipper.showPrevious(); 25 } 26 27 }); 28 29 }

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


1 <?xml version=”1.0″ encoding=”utf-8″?>2 <set xmlns:android=”;>3 <translate android:fromXDelta=”100%p” android:toXDelta=”0″ android:duration=”300″/>4 <alpha android:fromAlpha=”0.0″ android:toAlpha=”1.0″ android:duration=”300″/>5 </set>6


1 <?xml version=”1.0″ encoding=”utf-8″?>2 <set xmlns:android=”;>3 <translate android:fromXDelta=”-100%p” android:toXDelta=”0″ android:duration=”300″/>4 <alpha android:fromAlpha=”0.0″ android:toAlpha=”1.0″ android:duration=”300″/>5 </set>


1 <?xml version=”1.0″ encoding=”utf-8″?>2 <set xmlns:android=”;>3 <translate android:fromXDelta=”0″ android:toXDelta=”-100%p” android:duration=”300″/>4 <alpha android:fromAlpha=”1.0″ android:toAlpha=”0.0″ android:duration=”300″/>5 </set>


1 <?xml version=”1.0″ encoding=”utf-8″?>2 <set xmlns:android=”;>3 <translate android:fromXDelta=”0″ android:toXDelta=”100%p” android:duration=”300″/>4 <alpha android:fromAlpha=”1.0″ android:toAlpha=”0.0″ android:duration=”300″/>5 </set>6

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

1 publicvoid onCreate(Bundle savedInstanceState) { 2 super.onCreate(savedInstanceState); 3 setContentView(R.layout.main); 4 5 final ViewFlipper viewFlipper = (ViewFlipper)findViewById(; 6 7 Button nextButton = (Button) this.findViewById(; 8 nextButton.setOnClickListener(new OnClickListener() 9 { 10 11 @Override 12 publicvoid onClick(View v) { 13 viewFlipper.setInAnimation(MainActivity.this, R.anim.view_transition_in_left); 14 viewFlipper.setOutAnimation(MainActivity.this, R.anim.view_transition_out_left); 15 viewFlipper.showNext(); 16 } 17 18 }); 19 20 Button previousButton = (Button) this.findViewById(; 21 previousButton.setOnClickListener(new OnClickListener() 22 { 23 24 @Override 25 publicvoid onClick(View v) { 26 viewFlipper.setInAnimation(MainActivity.this, R.anim.view_transition_in_right); 27 viewFlipper.setOutAnimation(MainActivity.this, R.anim.view_transition_out_right); 28 viewFlipper.showPrevious(); 29 } 30 31 }); 32 33 }

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

Building an Android Splash Screen

Github Repo

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.






Step 3.

Once your project is set up, open 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.


Social Smurf: A Social Media Plugin for SMF

Live Example
Source Code
SocialSmurf XAP (rename from .zip to .xap)
PluggableSmoothStreamingPlayer XAP (rename from .zip to .xap)



July 7th marked the release date of the 2nd 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.


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(““””)

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=”;/>
<param name=”minRuntimeVersion” value=”4.0.50401.0″ />
<param name=”InitParams” value=”pluginurl=,
mediaurl=[Insert Your Video Url Here]”

Geolocation Search with SQL Server

As some of you may know, as a side project, I’m building an app that involves geo-location and social media.  When I went to build the geo-location part of the app my requirements were pretty simple.  I have people in my application with lots of GPS data and given a specific GPS coordinate, maybe where I’m standing now, I need to search all those people and see who is nearby.  So how to do this?  Well, you obviously don’t want to do this in the application, right?  You’d have to pull all that data back and do a search in memory.  The database is a much better place, and fortunately SQL Server 2008 (and now SQL Azure) have geospatial support.  Here’s a great MSDN article with more information.  And this is a simplified version of the Stored Procedure I came up with that will search a database table (Location) for all records within a specified distance (meters) of a target lat/lon position:

    @SearchLatitude decimal(12, 8),
    @SearchLongitude decimal(12, 8),
    @Distance decimal(12, 8))

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