Ashish Datta, Author at {5} Setfive - Talking to the World

Over the weekend, Fred Wilson posted an awesome video of the unboxing and flight of a Parrot AR drone along with a note that he was planning to grab one and develop some custom node.js code for it. After seeing the video, and with spring finally here I started brainstorming about what gadgets I’d want to play with over the summer.

Parrot AR Drone

Shown in the video linked above, the Parrot AR Drone is a remote controlled 4 rotor helicopter that is controlled via an iOS or Android device. What sets the Parrot apart from other similar devices is that it there is an node.js library for simplifying development of custom functionality on the Parrot platform.

Not exactly sure what we’d be looking to build with an AR drone but the Red Bull Air Race comes to mind.

Sphero Robotic Ball

Built by Boulder, CO based Orbotix the Sphero robotic ball is a gyroscopically stabilized ball that can be controlled using an iOS or Android device. The Sphero has a software development SDK and there’s also an active app store to download pre-built apps that work with your Sphereo.

Just brainstorming, but something awesome to build with a Sphero would be an app to draw out large drawings using the Sphero to actually draw the lines. Imagine drawing a 50’x50′ line art graphic by uploading some art and then letting the Sphero roll around the canvas.

Pebble watch

Born on Kickstarter, the Pebble watch is an indie entrant into the “smartwatch” space. Sporting iOS and Android integration via Bluetooth along with a scriptable watch face, the Pebble is shaping up to be an interesting player in a developing market.

As far as development, writing custom faces to visualize information differently or pull data off a smartphone seems to be pretty exciting. It still seems a bit early to get a sense of how the Pebble will fare long term as a platform though.

Jawbone UP

Although primarily known for their speaker systems and Bluetooth headsets, the Jawbowne UP is a personal activity monitor that helps users track their physical activity, sleep cycles, and eating habits. The UP fits into the trending theme of the quantified self, where users track KPIs about their daily life in an effort to iterate and improve. Pulling data off the UP is relatively easy and it also plugins in to RunKeeper.

The “quantified self” concept sounds like it would be interesting to experiment with and using the UP to try it out seems like an obvious choice. Leveraging the UP would also make it easy to “compete” with anyone else looking to jump into activity tracking.

Raspberry Pi

Released last year after intense anticipation, the Raspberry Pi is basically a six square inch board with a fully featured computer including video output and USB ports. Coming in at $25 or $35, the Raspberry Pi is cheap enough to experiment with, hack it, and if it happens break it. With full Linux support, the Raspberry Pi is also robust enough to handle “serious business”.

Looking at the list of Rasberry Pi Hacks, theres definetely some awesome inspiration to build something cool. Using a Pi to power a TV screen with real time interactive content seems like it might be an early winner though – we’ll see where that goes.

Anyway, that’s my list, unfortunately I’m not sure what I’ll actually get around to hacking on this summer. Would love to hear about any other cool gadgets or hacks.

Earlier this week I was putting together a block of code which ended turning into a switch statement with a tangled mess of long case blocks, complicated fall throughs, and ultimately became impossible to follow. Being a stand up guy, I decided to refactor the block using a technique where the case blocks are converted into anonymous functions, indexed into an associative array, and then the correct function is called depending on the value. I haven’t seen this show up too often in PHP code so I thought I’d share.

So what’s the problem?

The life of a switch statement usually starts out relatively benign, you have a few simple conditions and each block is relatively compact:

But then, the switch grows and each case becomes complicated enough that it the entire block becomes mostly unreadable: Ellipsis for effect.

At this point, its hard to reason about what’s going to happen because each case statement has presumably gotten so large and different conditions are “falling” through so the side effects are difficult to trace through.

An alternative

An alternative to using a normal switch statement is to use a dispatch table, which is basically an array of functions indexed by whatever variable you’d normally be “switching” on. The primary benefit to structuring the code this way is that you can easily reason about side effects since the only variables that can be changed are what captures the return value or anything passed by reference. In addition, since every case is a separate function its a bit easier to edit the code. So what does this look like? It’s actually pretty straightforward:

Extending from there, you could also call the function with arguments, potentially by reference, and even have all the functions be closures which capture the variables to avoid having to call with arguments.

Anyway, questions or comments always welcome.

Last week, I was putting together a Google Chrome extension for one of our clients to help debug Javascript events on a page and I started wondering why don’t we have mobile browser extensions? Unfortunately, there isn’t a simple answer but I think looking towards the desktop can help draw analogies to where we are on mobile now.

So this desktop thing?

Looking back to the desktop, arguably one of the strongest drivers of Firefox’s growth was its rich extension ecosystem. Compared to Internet Explorer, Firefox extensions were easier to develop, leveraged web technologies (XUL, JS, CSS), and offered powerful abstractions out of the box. Because of this, developers began building powerful extensions for Firefox which drove “power user” adoption and ultimately helped spur mainstream adoption. Developers built extensions like Firebug, Greasemonkey, and companies like Rapportive inside the Firefox extension ecosystem. Following Firefox, when Google Chrome launched it debuted its own even simpler extension infrastructure and eventually the Chrome Webstore to help distribute and monetize extensions.

Although largely positive, the extensions developed for Firefox and Chrome weren’t always user friendly. Between redirecting search traffic and surreptitiously injecting ads, “greyhat” extensions negatively impacted user experience while generating revenue without generating value. These “greyhat” extensions fueled what’s colloquially known as Israel’s download valley and ultimately millions of dollars in revenue.

Right so what about mobile?

Compared to the desktop, the landscape on mobile is notably different because of an Apple and Google duopoly with Apple primarily monetizing hardware and Google monetizing search advertising. Additionally, compared to the desktop, Apple and Google have an unprecedented level of control over user devices, all but ensuring that devices will arrive with either Safari or Chrome installed.

I think because of this control, Apple and Google have little incentive to open up Mobile Safari or Mobile Chrome to 3rd party extension developers since doing so would compromise the browser user experience for little gain over the competition. But what about Firefox?

Although Mozilla has released a Firefox build for Android, I think they’ve recognized that trying to win market share away from Chrome on Android is a losing battle and they’re starting to seriously pursue FirefoxOS. Because of this, I don’t think Mozilla will invest in Firefox mobile extensions since it’s clear that there’s more opportunity in powering the OS layer of a user’s phone.

Yesterday, Daum and I hung out at HackHarvard and gave a presentation about how we started Setfive, the challenges we faced, and some of the lessons we would tell our younger selves. The feedback and resulting discussion was pretty interesting so it seemed like it makes sense to share. Some of these things are probably mistakes you have to make for yourself and 90% of advice is crap.

Don’t get bullied

Looking back, a lot of the early “negotiations” I did with clients was really them pushing me around and me accepting whatever terms they ultimately demanded. People were using veiled threats of yanking the deal, asserting that “I didn’t know how business was done”, and being overly demanding with changes and calls to manipulate the direction of the deal. In addition to professionally, I also remember several instances of real estate brokers and landlords trying to strongarm me personally. Anyway, so the takeaway has been in life or work there’s a difference between negotiating and bullying.

Don’t be afraid to say “I don’t know”

During highschool and college, I’d always been conditioned that when someone asks a question, especially an “adult”, I should obviously know the answer. Professor singles you out to answer a question? Better know the answer. Unfortunately, this feeling stuck with me into the “real world” and I had a tough time admitting that I didn’t know the answer to a question on the spot. This usually resulted in overpromising, having to backpedal later, or being stuck bullshitting through some half baked explanation. After being around the block, it became clear that saying “I don’t know, let me get back to you” was acceptable and the better move. Turns out, in the real world everyone isn’t a walking manpage.

“Big” $ numbers are just numbers

Coming out of college, the largest check I had written was for $5000 and the largest check I’d probably cashed was for around the same. Because of this, I had a hard time taking myself seriously while asking for “big” dollar numbers. After a while, I started to realize everyone has a different concept of what a “big” number is. $5,000 might be a mountain of cash to me but to someone else its just their monthly Salesforce.com subscription. Once I understood this, it became much easier to walk into a meeting and confidently talk about money.

If they look clueless, they probably are

Throughout highschool and college, I hadn’t experienced many instances where someone was trying to seriously cover up the fact that they were clueless. Over in the real world though, this seemed to start happening frequently. Initially, I had a hard time wrapping my head around the fact that the “Senior Developer” explaining his “master/master” setup was just entirely wrong. The issue with having these blinders was that it made it difficult to effectively communicate with stakeholders when there was someone bollixed in between. Once I realized that cluelessness was really cluelessness, it became much easier to marginalize the people that were lost and get shit done.

Everyone is not like you

Something that took awhile to realize was that not everyone is like me. I had a hard time figuring out why everyone didn’t “get” how to use certain websites or why everyone didn’t immediately jump on new tech products. Turns out, everyone isn’t a heavy drinking software engineer that reads Hacker News. After realizing that, it became easier to emphasize with different types of users and also better connect with stakeholders.

Anyway, these are my notes to send back to 2009. Would love any thoughts or feedback in the comments.

Monday was a horrific day in Boston and its been an uneasy day after. I don’t have anything to add to the discourse but I would like to urge you to join us, along with the technology community in supporting the victims.

TUGG has setup a fundraise.com page here – https://www.fundraise.com/technology-supports-victims-of-boston-marathon-bombing and over $100,000 has already been raised.

Author: Ashish Datta

Gadgets: 5 gadgets for your summer wishlist