Just for fun: Some tech predictions for 2013

With 2012 wrapping up, I thought it would be fun to make some predictions for 2013. I’m normally not a huge fan of these lists since they are usually a bit dull so I’ll try and make this one a bit scandalous. So here we go, looking at startups, technology, and a bit of everything else.

Series A Crunch

It’s over hyped but still probably worth mentioning. There was a huge uptick in angel activity in the last few years and as a result there’s a glut of start-ups looking to raise a Series A round. Unfortunately, there won’t be enough Series A deals to be had and with the general cooling in the consumer web sector VCs aren’t jumping for ways to make them happen. The net result of this situation will probably be a an increased number of “zombie” start-ups, aqui-hires, and obviously deadpooled companies. Fred Destin from Atlas has a full post discussing this, Series A Crunch, Seed Blues.

Breakout Health Company

The health and wellness vertical has been heating up for a couple of years, but we still haven’t seen a company have their “mint.com” moment in the space. I think we’ll see one in 2013 because of a combination of the penetration of smartphones and tablets, growing popularity of health data interoperability, and the federal mandate that electronic medical record keeping be implemented across the board. Deep pocketed companies like athenahealth have also hinted that they’d be open to acquiring startups in this space which should up the ante.

Meta Cloud APIs

Looking back at 2012, it could be affectionately nicknamed the “year of the outage”. Several providers were hit by downtime, but the Amazon Web Services disruptions were arguably more serious and frequent than they had been in the past. For some companies, the AWS issues highlighted the fact that relying on a single cloud provider was too risky given the potential of extended downtimes, even across regions. I think because of this, in 2013 we’ll start seeing services that make it easy to provision and configure identical environments at multiple cloud providers. This would essentially allow you to have live instances running on AWS but then have an identical setup running at Rackspace. The foundations for something like this already exist in the jclouds library.

One JS MV* To Rule Them All

There’s been an explosion in the number of Javascript MV* libraries in the last couple of years. Libraries like BackboneJS, AngularJS, and KnockoutJS are all meeting similar needs for the same group of developers. I think in 2013 we’ll see at least some consolidation in the number of libraries and maybe even the emergence of a clear favorite. Hopefully this will lead to some clear patterns for Javascript MVC development just like the paradigms used by backend frameworks like Rails or Symfony.

Google Releases a Play API

Its a bit surprising that in 2012 mobile app discovery is still a disaster. Google Now can automagically tell me my flight is delayed but Google Play can’t seem to offer up even the basic recommendations. What’s even more surprising is that there isn’t an official Google Play or iTunes app store API. It’s also a bit odd that even if I “sign in” with a Google Account on a site, I can’t automatically download apps to my phone from their site. I think Google is going to change this in 2013 and open up a wave of innovation around mobile app discovery and monetization. This should shake up the app store distribution problem and also reduce the friction to convert a web user to a mobile app one.

Second Screen Showdown

With the rising popularity of tablets, the second screen TV experience will become increasingly popular in 2013. You’ll be able to download network (Showtime, HBO, NFL, etc.) branded apps which will display enhanced content as you’re watching your favorite show or team. Look for networks will use this to boost engagement and drive revenues through sales of content related items.

Anyway, these are all a bit off the cuff but I’d love to discuss in the comments.

Big Data: What is “Big Data”?

Last week, I was catching up with a friend of mine and we started chatting about his most recent project. As we were chatting, he made an offhand comment about how some of the business guys on the team love to refer to what they are working on as a “big data” play, even though it really wasn’t. This stuck with me, since because of the vague definitions around “big data”, it’s easy to shoe horn problems into a “big data” play. Because of this, I think its worth taking a step back and discussing what big data really is and what tools are available to work with it.

It’s all just data

At the end of the day, data is data. It doesn’t really matter if its stored in a CSV text file, a MySQL database, or a NoSQL datastore like Cassandra or MongoDB. Typically though, web applications tend to use a relational database like MySQL or Postgres to persist data. Relational databases store data in a series of tables which are in turn arranged as a series of rows and columns. As an abstraction, think of a series of Excel worksheets which can have links between the rows of each sheet.

For most applications, this works out fine, the database ends up managing say a few thousand customer accounts, each with a few hundred thousand objects associated with them and the total dataset fits conveniently into the server’s RAM. Since the dataset is relatively small, things like retrieving information, updating records, and running ad-hoc analytics queries are all easy to implement and relatively fast. But what happens if your dataset doesn’t fit into memory of even the beefiest of servers? Therein lies the “big data” problem.

Certain applications generate an enormous amount of data on a daily basis. For example, look at Mixpanel, tracking discreet user interactions is going to produce hundreds of thousands of datapoints every day even with just a few clients. With this volume of data, typical relational databases quickly start performing sluggishly and eventually stop being effective entirely. Even simple queries like counting the “# of clicks by user” start to take hours to run, effectively becoming intractable. Although specialized relational databases like Vertica and Oracle 11g do exist to help solve this problem, they’re expensive and proprietery.

Enter the elephant

One of the first companies to publicly discuss their big data strategies was Google in Bigtable: A Distributed Storage System for Structured Data which described their BigTable datastorage system. Although a proprietary solution, the research paper was used as the basis for Apache Hadoop, an open source framework for running MapReduce style jobs over large datasets.

At this point, Hadoop has distinguished itself as the most popular open source big data solution with a rich ecosystem of tools and several companies providing professional services and support including Cloudera and Hortonworks. What Hadoop provides is a low level framework for allowing computation jobs to be distributed across several servers within a cluster. This allows tools to split up very large datasets into smaller chunks, distribute computational tasks across the cluster, and finally assemble the result. So with the Hadoop framework in place, you still need specific tools built to leverage the distributed framework.

The toolbox

There are several tools that effectively leverage Hadoop but here are some of my favorites for quickly building out a cluster:

Apache Whirr – Automates deploying, bootstrapping, and configuring a Hadoop cluster. Whirr will save you hours of time because instead of manually starting 4 EC2s and configuring them all you can kickstart a cluster with a single command.

Apache HBase – A column store database that is similar to Google’s original BigTable system. Great for storing billions of records across a Hadoop HDFS file system.

Apache Hive – A datawharehousing solution that allows you to run “SQL like” queries using Hadoop. It also has native support for pulling data out of MySQL, making it a convenient addition to a stack includes MySQL.

Apart from these, there are dozens of other Hadoop powered tools but its impossible to recommend a single silver bullet without knowing the details of your “big data” problem.

Twitter Bootstrap: What it (really) is

Early on Tuesday Bootstrap 2.2.0 was released which included a handful of improvements, a couple of bug fixes, and some documentation updates. News of the update made the front page of Hacker News and generated a heated debate surrounding the usefulness of Bootstrap itself. The top comment basically railed against Bootstrap saying it’s useless since it just introduces a load of boilerplate CSS without any added benefit. It struck me that looking through the Bootstrap documentation, there isn’t a straightforward explanation of what it really is and more importantly, when you should use it.

At a high level, Bootstrap is a “CSS framework” which contains a set of CSS classes to help you develop CSS for a project. Bootstrap wasn’t the first and isn’t the only CSS framework, projects like BlueprintCSS, 960gs, and Foundation are also competing CSS frameworks. What makes Bootstrap stand apart though, is the tight integration between “base” classes and “high level” classes along with the number of components included in the standard distribution. Using Bootstrap, you can effectively use a single toolkit to take your project from a layout grid, through styled HTML forms, and finally stylish Javascript plugins.

The next thing to consider is give your requirements and team, is Bootstrap an appropriate choice for your project. As CSS frameworks go, Bootstrap is pretty heavy and it’s going to introduce conventions and assumptions into your project that if you don’t use, you’ll end up fighting against. Given that, when is a good time to Bootstrap? In my opinion, Bootstrap will end up being the most useful when you have a fast moving, new project that needs a good “default” style for prototyping as well as a style guide for developers to follow. So concretely, a typical team of 3 engineers starting a new project will probably benefit from Bootstrap. Meanwhile, a digital agency designing a micro site for a client with exiting assets and branding probably isn’t going to. So what does Bootstrap get you?

Consistency and re-use

With a single developer using a single CSS file, its pretty easy to keep class names consistent and effectively re-use styles. However, as additional developers and additional CSS files are added to a project it becomes increasingly difficult to effectively re-use classes and often prevent near duplicate definitions. Bootstrap helps mitigate this by introducing classes for styles you’ll probably need right off the bat. Need a button? Use “btn”. Need a bordered table? Add a “table-striped”. Unfortunately, Bootstrap isn’t a silver bullet but it’s better than nothing.

Looks good out of the box

This one will be a bit controversial but it’s important for a lot of people. Out of the box, Bootstrap looks pretty good which gives you a more flexibility in rapidly developing prototypes, proof of concepts, and MVPs because you’re free to focus on the functionality instead of the design. If something ends up moving into production, you should obviously customize Bootstrap away from the stock theme. Bootstrap actually makes this significantly easier because it uses LESS to generate its CSS files. LESS introduces several pre-processors on top of CSS which makes it easy to make a cascading edit throughout the framework. Need to change the colors across your site? Just edit variables.less and re-generate the CSS.

It’s modern

As a framework, Bootstrap leverages several modern development techniques including responsive design, HTML5 data-*, and several others. Taken individually, none of these techniques are particularly notable but as part of an integrated framework they’ll help you write cleaner, more maintainable, and more compatible code.

This isn’t an exhaustive list by any means but hopefully it’ll serve as a good basis for what Bootstrap is and why you should consider using it.

Be Responsive: A History of Responsive Design

During the last two years the number of mobile devices has grown at an exponential pace, with one Cisco estimate (http://bit.ly/zVdFJD) predicting more mobile connected devices than people by the end of 2012. Due to this growth, providing a first class mobile web experience has become increasingly important and is now a paramount concern for websites. Union Square Ventures’ Fred Wilson went as far as to point out that new web apps are commonly designed “mobile first web second” (http://bit.ly/gQTtBp)

Within the last year a technique known as “responsive design” has become an increasingly popular way to tackle “mobile vs. desktop” web design issues. There have been several reasons for this rise in popularity which we’ll talk about after an abridged history of the mobile web.

How did we get here? Well it all started with WAP… Back in the dark days of the mobile web, well before the average consumer was accessing the Internet from a cellphone the majority of web content was served via a technology called the Wireless Application Protocol. Even I am to young to really have experienced it in all of its glory but the “Criticisms” page on Wikpedia should convey just how awful it was – http://bit.ly/wWxY2c Big takeaways? Imagine writing websites in XML, oh and it has to validate.

Anyway, fast forward a couple of years and vaguely recognizable devices are slowly starting to come online. From the Nokia Symbians, to Palm, and of course the venerable Blackberry mobile devices are beginning to access the nascent mobile web (yay!). The problem? The browsers on these devices were severely limited in terms of CSS and Javascript support, standards compatibility, and available bandwidth. As a result of these limitations, developers chose to basically develop “stripped down” basic HTML versions of sites to present on mobile devices.

One last trip in the DeLorean and we’re zooming from the initial release of the iPhone during the summer of 2007 to today with thousands of smart phone and tablet models and billions of connected devices. During this period, developers tended to build specific “mobile” sites which were usually an entirely separate HTML/CSS/JS(kinda?) code base from their desktop sites. Understandably, this situation was less than ideal since at the minimum it meant maintaining two code bases and the mobile site often lacked the full functionality of the desktop site. Additionally, as both desktop and mobile browser development rapidly progressed consumers began to expect a consistent experience across their devices.

So how do we address these issues and improve mobile user experience? Enter, “responsive design”. The central tenant of responsive design is that you (the designer/developer) should be able to use the same HTML, CSS, and Javascript to serve devices with different screen sizes and resolutions. The idea is that your layout should be able to respond by adapting the it’s presentation layer depending on any number of factors.

The key technology this process relies upon are Media Queries. Fully adopted by CSS3, media queries allow CSS directives to be conditionally applied depending on the result of a boolean query. In practice, this means a single CSS stylesheet can contain one set of directives for a 480px screen as well as different directives for a 1200px screen. Lets look at an example. If you open http://www.agentvita.com/ and then progressively shrink your browser window you’ll see that the elements dynamically adjust depending on the size of the screen.

Well that’s some history and a quick demonstration, now for some nitty implementation gritty details. Unfortunately, there’s no “magic bullet” to automatically take a standard desktop layout and responsively adapt it for different screen sizes. In my opinion the best approach is to start with a solid framework, keep your markup clean, and of course be cognizant that you’re planning to adapt the layout for different screen sizes. Or if you’re feeling brave, start with the mobile layout first and then progressively enhance the layout as your screen size increases.

Here are some specific resources to get started:

Boomerang via @fredwilson and @cdixon

Hope everyone had a great Christmas and that you’re gearing up for a great New Years!

Anyway, I picked up a Kindle Fire for Christmas and decided to use it as an eReader at least once in its life. I had remembered seeing Boomerang by Michael Lewis recommended by both Fred Wilson and Chris Dixon so I figured it must be worth checking out.

The book is a short, easy read but it offers a fascinating perspective on the global financial crisis through several different viewpoints. As Chris pointed out, theres also a couple of funny anecdotes and bizarre cultural highlights. If you have some time to kill, I’d definitely recommend picking up Boomerang and giving it a once over.