Links for 05-31-2013

• How Land Rover, England's Ugliest Station Wagon, Became One of the World's Most Luxurious Brands | Adweek
• If We Still Used Punch Cards - YouTube - RT @LivingComputers: In this video @GHaff uses concise visuals to demonstrate punched card obsolescence:
• Twitter / ghaff: Hmm. Bing's running this Bing ... - Hmm. Bing's running this Bing vs. Google web search contest. Were smoked in my (blind) trial.
• The 5th Tenet of Open Hybrid Cloud: Start With an IaaS Private Cloud | tentenet.net - An under-the-covers look at #redhat technologies for hybrid IaaS by @bryanwche
• Mary Meeker’s 2013 internet trends: all the slides plus highlights - Quartz
• Doc Searls Weblog · Let’s help Airbnb rebuild the bridge it just burned - Not to defend Airbnb here, but I suspect we're going to see a lot of stress points as sharing services try to move out of the margins to something more mainstream.
• Forecast 2013 Registration - RT @opendatacenter: Enterprise tends to turn to private #cloud, but will it stay that way? @ghaff will discuss on a panel at #Forecast13:
• Why Do Not Track is destined to fail (DNT is DOA) | getwired.com - "Rather than driving efforts like DNT, which fundamentally cannot occur (in the manner users think those words mean “do not track”), we’d do a lot better as an industry to drive standards that delineate what types of information a specific site or tracking engine like Google Analytics or Adobe’s Omniture products can collect on you. But even if you throw those back at users, they’ll be overwhelmed. Perhaps the best angle is to reinforce that no activity on the Internet is totally anonymous, and no matter how hard you try, you cannot ever completely prevent being tracked."
• On the Internet, Nobody Knows You're a Dog
• NetAppVoice: Securing The Cloud: Why You Need Cast-Iron Guarantees - Forbes
• Data Science eBook by Analyticbridge - 2nd Edition - Data Science Central
• Memo to this year’s YC class: It’s damn hard to build an enterprise company | PandoDaily - RT @utollwi: Memo to this year’s YC class: It’s damn hard to build an enterprise company #SaaS
• http://maps.bpl.org's photos. - RT @flickrock: @ghaff Check out that Flick gallery using Flickrock!
• Flickr: Norman B. Leventhal Map Center at the BPL's Photostream - Cool map resource on Flickr from the Boston Public Library
• Google IO — Benedict Evans - "My main impression of Google IO was not so much any specific announcement as the overwhelming sense of ambition and self-confidence."

Data in, hunches out

"Going with your gut is out." That line, from Russell Reynolds Associates managing director Shawn Banerji, neatly summed up a big chunk of yesterday's MIT Sloan CIO Symposium. There was discussion of the computing side of things as well. I especially liked EMC CTO John Roese's description of public clouds evolving to a "chaotic" (as in heterogeneous/hybrid) pool of resources in which special purpose clouds would have specific functions. But the majority of the day revolved around data.

Not necessarily "big data" by the way. One panelist—Jack Norris of MapR—even remarked that the "big data term is probably short lived." But, rather, the pervasive use of data, in whatever form and at whatever speed, to drive decision-making. As Annabelle Bexiga, the CIO of financial services firm TIAA-CREF put it: "Big data is just a richer set of data. [It's a] natural evolution of where data is going."

Erik Brynjolfsson (above) is the Director of the MIT Center for Digital Business. He spoke to how the data explosion was a revolution of technology but was also (and required) a revolution in management. 

He offered the example of publishing, described as historically a "culture of lunches"—which is to say a culture of hunches and people networks. But Amazon brought a culture of numbers to the industry. And things haven't been the same since.

A 2011 paper, which Brynjolfsson co-authored with Lorin Hitt and Heekyung Hellen Kim found that data-driven decision making at firms resulted in 5 percent higher productivity than at firms which weren't so data oriented. 

Brynjolfsson also discussed what might be called ambient data, data collected almost incidentally from sources such as cell phone records. He offered the example of streetbump in Boston, which uses an iPhone app to find potholes. At the same time, he observed that the app did best at finding potholes in the Back Bay, Beacon Hill, and other relatively upscale Boston locales. Why? Because that's where iPhones predominate. As Sloan's Andrew McAfee would elaborate on in his closing keynote (paraphrasing science fiction author William Gibson), "the future is already here. It's just unevenly distributed."

The panel which Brynjolfsson moderated also touched on some of the privacy issues associated with this ambient data. The MIT Media Lab's Sandy Pentland told how a big data commons, created by French telco Orange, was used to reduce commuting times in the Ivory Coast by 10 percent by rearranging bus routes using location-based data from mobile phones. Pentland went on to note, with more of a bit of understatement, that this sort of thing is politically controversial in places like the UK.

For his closing keynote, Andrew McAfee (above) took as his jumping off point a fascinating graph that appears in Ian Morris' Why the West Rules—For Now. At the risk of offering up spoilers, the central thesis of the book is that, viewed from the perspective of today, the level of worldwide social development prior to the industrial revolution is effectively in the noise.

(Although McAfee didn't get into this, the answer to the book title's question is basically that the West was better positioned to create and take advantage of the industrial revolution when the factors making it possible came together. It's a great read. If nothing else, it's a good history of the world from the perspective of the Western and Eastern core.)

The industrial revolution had such an impact because it overcame the limitations of human muscles. (I suppose, given farm animals, it would be more accurate to say it overcame the limits of human and domesticated mammal muscles generally.) In any case, though, McAfee's thesis that that today we're starting to overcome the limitations of our individual minds.

He laid out four elements to this:

Cyborgs—as in new combinations of people and machines.

Open—which will define successful organizations in a variety of ways. (If you want to delve more deeply into this thought, I point you to a presentation I gave at ProductCamp Boston a few weeks back.)

Data-driven—because for the first time we have data-driven visibility in all sectors of the economy.

Evolving—for which McAfee offered the example of the car rental industry which evolved only incrementally since it was founded after the Second World War but has seen the introduction of radically new services made possible by the Web and mobile phones from Zipcar to Lyft.

So it's more than data. But data—along with the compute needed to operate on it and the networks needed to move things around and tie them together—is a common thread. Big challenges lie in gaining access to the right data, even within single organizations. Cutting across data silos was also a theme heard more than once throughout the day. Asking the right questions matters too. As McKinsey's Michael Chui summed up that thought: "Be data driven. But don't suck at it."

Links for 05-21-2013

• Photographer Shares His Lightning Quick Lightroom Workflow
• Python 3 Metaprogramming - YouTube
• Has Intel finally landed that elusive Atom deal? | ITworld - RT @apatrizio: My debut blog with ITworld on the chips biz: rumors of an #Atom-powered #Samsung #Galaxy tab.
• New Orleans Buck
• (403) http://blogs.forrester.com/james_staten/13-05-16-hybrid_cloud_future_too_late - RT @Staten7: Hybrid Cloud? You are already hybrid. The question: What are you doing about it? #Forr blog: @stefanried
• Twitter / krishnan: Best definition of PaaS I have ... - RT @sravish: HILARIOUS (and perhaps true?) -> “@krishnan: Best definition of PaaS I have come across - ”
• Making Big Data Technologies Work in the Enterprise - “A lot of the architectures and products that technology managers may have been accustomed to for traditional transactional activity don’t map well to a big-data world,” says Gordon Haff, corporate technology evangelist at Red Hat and the author of Computing Next, a book on cloud computing. “You very much need to think about an architecture in the context of big data.”
• Ten years on: How did that cloud strategy pan out? • The Register
• www.martinlamonica.com/wp-content/uploads/2013/05/Making-Big-Data-Technologies-Work-in-the-Enterprise.pdf - Nice piece on big data techs for enterprise by @mlamonica (w quotes from me)
• Netflix, Reed Hastings Survive Missteps to Join Silicon Valley's Elite - Businessweek
• 'Weeds' Creator Kohan Dishes on How Netflix Drives Hollywood Insane - Businessweek
• The Serious Superficiality of The Great Gatsby : The New Yorker - "Baz Luhrmann’s “The Great Gatsby” is lurid, shallow, glamorous, trashy, tasteless, seductive, sentimental, aloof, and artificial. It’s an excellent adaptation, in other words, of F. Scott Fitzgerald’s melodramatic American classic. Luhrmann, as expected, has turned “Gatsby” into a theme-park ride. But he’s done it in exactly the right way. He hasn’t tried to make the novel more respectable, intellectual, or realistic. Instead, he’s taken “The Great Gatsby” very seriously just as it is."
• Twitter / Caterina: LinkedIn says I could apply ... - RT @Caterina: LinkedIn says I could apply to be Sr. Product Manager of Mobile for Flickr! Plus some other jobs. Woo!

My first MOOC (Massively Open Online Course)

I recently completed my first Massively Online Online Course (MOOC), a term that presumably is at least passingly inspired by MMORGs, an online gaming genre that's most popularly represented by World of Warcraft. 

The class was on Gamification and was well-taught by Wharton prof Kevin Werbach. But my focus here isn't to review or critique this particular class but, rather, to offer more general reactions to the instructional method. To reflect on what these courses seem to do well or at least handle relatively naturally, and what they struggle at. It's just a sample size of one—well, 1.5 actually as I'm currently taking a Data Science course that offers some additional insights—but I think it nonetheless exposes certain patterns.

I also encourage those interested in the topic to read Nathan Heller's "Is College Moving Online?" in the New Yorker, a thorough examination of the state of MOOCs and their potential effects on education—both for good and ill. 

The format

The format for Gamification—which it seems is fairly typical—is built around a series of lectures. These consist of fairly typical Powerpoint slides with video of the instructor superimposed or off to the side in a small window. The production values are generally high and the combination of slideware and video is engaging.

There's a syllabus with links to various articles and other (free) materials. Prof. Werbach actually has a book on the topic of Gamification but it wasn't required for the course. None of the Coursera courses I've taken a look at had much if any in the way of stuff to buy.

The course then had a series of multiple-choice quizzes and a multiple-choice final exam—plus three written assignments of increasing length and scoring weight. My current Data Science course likewise has a series of lectures. But, in this case, the score comes from a series of programming and other assignments that relate to lecture topics although they are more hands-on and practical.

Type of schedule

Gamification, like the course I'm currently taking, comes from Coursera, which has a large course catalog from a wide range of schools. It was started by two Stanford professors and has received $16 million in funding from Kleiner Perkins Caufield & Byers.

Coursera's model, like that of the non-profit edX, is to offer classes in more of less real-time—by which I mean, an eight week course has a fixed start date followed by an end date about eight weeks later. Depending on the class, there may be more or less flexibility in how closely students have to hew to a weekly schedule for assignments, quizzes, and the like. But, fundamentally, the class is on a calendar and you can't dip in and out on the basis of work or family obligations, travel schedules, and inclination. 

The downsides to this approach are obvious. There are a couple of classes I've considered but opted against because they overlapped periods when I would't have been able to devote much time to them.

On the other hand, after taking a class, I better appreciate why one might want to run a class to a schedule. Discussion boards, assignments (especially peer-graded ones—more on those in a bit), the availability of staff to answer course questions or address problems, and just getting forced into the "flow" of a class all require or at least greatly benefit from a schedule and associated incentive structure. (Education has a lot in common with a gamification system.)

In a related vein, I also better understand why you might not want to break a course into overly granular chunks, i.e. one or two week classes. I'm not just talking about any particular administrative overheads associated with putting a course in a catalog, but a broader set of transaction costs borne by all the participating actors such as figuring out how the class is run and understanding or dealing with prerequisites or tools. In many cases, it seems these would collectively just add too much overhead to a short course unless that course were more intensive than most people with a full-time job could undertake.

Does the fact that these Coursera courses so reflect the form and content of traditional university classes simply reflect tradition and the fact that much of the content was originally developed for such classes? Perhaps to a degree. On the other hand, whatever issues higher education may have today, it's also likely that not everything about traditional class instruction is wrong.

Another form of MOOC largely goes self-paced, even if related lectures still largely parallel the content of a semester of classes. Machine-graded quizzes can still exist, as can other types of computer- or self-evaluated assignments. Udacity, another VC-funded MOOC, follows this model today. 

Other types of online instruction that increasingly diverge from a true MOOC model include iTunes University and the many instructional videos on YouTube. More focused sites, such as Code Academy, teach specific skills.

I think both more- and less-structured forms will have their place. Many of us have a limited ability to schedule courses that follow a fixed schedule and find the flexibility of watch-when-you-can attractive. At the same time, I appreciate the relative discipline and other potential benefits provided by a more formal course structure.

Grading and certification

Coursera, like edX, follows another aspect of most traditional university courses; it grades you. In Coursera's case, this takes the form of a Certificate of Completion based on your performance in various assignments and quizzes as determined by the individual class—70 percent in the case of Gamification. (Coursera is also starting to offer a "Verified" version for certain classes.) 

I suspect that, at this point, a Coursera certificate is more of a gamification element, i.e. a motivator, than something that's especially useful outside of Coursera. However, it's also true that Coursera's business model will ultimately depend on being able to sell the ability to gain meaningful certifications—which means that they need to be able to grade.

Schools have, of course, been grading forever. But remember what the "M" in MOOC stands for? It's "massive," indicating that it's not at all unusual to have 50,000 people sign up for a MOOC. (Although far fewer will complete it.) It's obviously not practical for a professor and a few TAs to grade at that scale. In the future, I wouldn't be surprised to see hybrid models in which something "MOOC-like" is augmented with one-on-one and one-to-few interaction with professors and TAs for a fee—indeed we're starting to see examples of such—but let's stick to the subject at hand for today, given that what's actually being paid for starts to become a complicated question.

A couple observations about the state of grading in MOOCs.

Multiple choice works well, subject to the limitations of multiple choice. Given well-written questions, there's no more ambiguity than with any other multiple-choice exam. It's easy and instantaneously graded by computer. And modest feedback can be made available with respect to the answers. 

Computers also do well at grading freeform but well-bounded and unambiguous answers, such as a numerical solution with only one correct response. It's "42" or it's wrong.

However, start talking more open-ended problems, even in quantitative topics like programming, and automated graders can start failing answers in unexpected ways. Without going into all the gory details, the autograder for the first assignment in my current data science course was highly sensitive to, for example, how the programmer chose to parse text fields and to any quirks in the output's format. While not fatal flaws, it's indicative of how automated grading challenges magnify exponentially the more creativity is allowed in solving an open-ended problem.

Also problematic is peer review. On the one hand, this offers a way for massive scale evaluation of freeform text in a way that it's hard for imagine computers tackling anytime soon. On the other hand, across a huge class with students of all ages, skills, language abilities, and interest, it's not hard to imagine that the evaluations can be… quirky—even given a relatively detailed scoring rubric. 

I didn't personally have a huge problem with my results. But it was obvious from the discussion boards that a lot of people took low evaluations made without comment and evaluations made with obvious disregard for the scoring instructions very personally. And it's worth observing that, given a large class, statistics suggests that some will have simple "bad luck" with those they draw to evaluate their written assignments—even given multiple graders, multiple assignments, and algorithms to screen bad actors.

At the current stage of MOOCs, I personally find it easy enough to shrug my shoulders and get on with things. I have lots of diploma and certificate things gathering dust somewhere. But say a class has a written assignment contributing say, 33 percent of the grade. To the degree this grade has meaningful consequences for the student (for a resume or for tuition reimbursement if MOOCs start charging in some form), that's a problem. It's also fair to say that, real world significance aside, grades can have a motivating factor for many as well.

This hasn't been intended as an exhaustive look at the "grading issue" but it's been evident to me it's something that will have to be at least improved on—not that students are ever wholly happy about their grades—as MOOCs look to start collecting money from people and offering meaningful certifications.

Overall

I got a lot out of this course and it looks as if there's a lot of quality content out there—more certainly than I'll have time to dig into. I'm also happy to see both for-profit and non-profit initiatives probing at ways to make higher-education better and more efficient. 

What I don't have a real opinion on is what the effect of Coursera, edX, and their ilk will be. The effect will certainly be uneven although one wonders if some aspects of MOOCs can replace elements of classes even at elite institutions. (Though I'd note that we've had the technology to replace 500 student freshman lectures for at least a decade.) I do suspect, or at least hope, that MOOCs—or at least MOOC methodologies—can replace low-value-add broadcast education in many situations.

One of the reasons that this particular crystal ball is cloudy is that higher education is often this odd hybrid of credentials, socialization, and learning that can be impersonal, highly personalized, solitary, involving lots of peer interaction, or some combination all of those. MOOCs clearly don't address all those modes but it arguably can do a subset rather well.

 

Links for 05-13-2013

• The Guerilla Guide to R
• Nathan Heller: Is College Moving Online? : The New Yorker
• Head First SQL: Hands On
• The Numbers News - Analysis: The Most Popular Character Names in Movies
• Good description of python and unicode
• Design of Computer Programs: Programming Principles - Udacity
• SQL Tutorial
• Data Science Toolkit
• Obama Signs Open Data Executive Order: U.S. Government Data To Be Made Freely Available - Forbes - "The order states that “going forward, newly generated  government data shall be made freely available in open, machine-readable formats, while  appropriately safeguarding privacy, confidentiality, and security. This requirement will help the  Federal government achieve the goal of making troves of previously inaccessible or unmanageable data easily available to entrepreneurs, innovators, researchers, and others who can use those data to generate new products and services, build businesses, and create jobs.”"
• Project Open Data - "Data is a valuable national resource and a strategic asset to the U.S. Government, its partners, and the public. Managing this data as an asset and making it available, discoverable, and usable – in a word, open – not only strengthens our democracy and promotes efficiency and effectiveness in government, but also has the potential to create economic opportunity and improve citizens’ quality of life."
• Mechanical MOOC
• How to hire data scientists and get hired as one — Tech News and Analysis
• Data journalism | Media | The Guardian
• Moleskine logo contest dubbed 'Molescheme' by angry designers - mUmBRELLA
• GeoJSON and KML data for the United States

Podcast: Kinvey's Sravish Sridhar on Backend-as-a-service

One of the challenges with mobile app development is that they require a number of services, such as user authentication, that can take a lot of effort to develop--even though the requirements are largely common across many different mobile applications. Kinvey offers hosted services that mobile applications on clients can consume.

Listen to MP3 (0:16:26)
Listen to OGG (0:16:26)

Gordon Haff:  Hi, everyone. This is Gordon Haff, cloud evangelist with Red Hat. I'm sitting here with Shravish Sridhar, who is the founder and CEO of Kinvey, which is a backend app development platform. Greetings.

Sravish Sridhar:  Hey, Gordon. It's great to be here.

Gordon:  We actually used to work together for a while a few years back.

Sravish:  We did. I was always star‑struck by how awesome Gordon was. It's just funny that I'm now sitting at a podcast with him.

Gordon:  You're embarrassing me. Let's talk about your company. What is Backend as a Service?

Sravish:  Backend as a Service started with the premise that mobile and tablet developers need an entire backend stack to build really, really rich applications. In order to build these rich applications, they needed access to data, to push notifications, to file storage, and to interconnectivity with various other data end points like an Oracle database or a Salesforce CRM, et cetera. When you think about it, how is a mobile developer going to build this entire backend stack from scratch? That's what we do. We've taken the entire backend stack and provide it as a cloud service and tied it to iOS, Android, and JavaScript libraries so that it's easy for you to build mobile applications with them.

Gordon:  Really, when we were talking about app development these days, I think a lot of the time, if you're not talking about mobile, you're really ignoring the elephant in the room.

Sravish:  I fully agree. When we find people thinking about new user experiences, they're actually thinking of both mobile and web. They need to connect to their user where and when the user wants to connect to the information. And so, whether the user is mobile or sitting behind a desktop, you need to do both all the time from here on.

Gordon:  We'll talk a little bit more about exactly what your company does, but maybe for our listeners who may have heard various types of terms applied to this space. There's this idea of MEAPs for enterprise application platforms. Where do you fit into that space?

Sravish:  We get asked this question in two fronts. One is, we often get asked the question, "How is Backend as a Service different than Infrastructure as a Service or Platform as a Service?" The way we think about it is that Infrastructure as a Service provides you with hardware on demand and lets you scale it up and down. Platform as a Service lets you run applications, so it solves the hosting and scaling of the runtime, but you still have to build the entire backend if you want to have a backend stack.

We think about it as, Infrastructure as a Service and Platform as a Service helps you with the plumbing, so they're in the plumbing business, and Backend as a Service helps you with the data, so we're in the water business. If you look at mobile enterprise application platforms, or MEAPs, they started off about five or six years ago as classic on‑prem enterprise software.

It takes a lot of money and effort to install them, customize them, and learn how to use them, and they lock you in, into a specific, WYSIWYG, HTML5 SDK that each one of them have. As an enterprise, you don't have the flexibility to use any native or hybrid SDK of your choice.

Our philosophy is we want to deliver everything through the cloud, the entire backend stack through the cloud, securely bridge your enterprise backend systems, and do the whole thing through a self‑service mechanism so that any developer that you employ or that's part of a dev shop or an SI can use the platform immediately, day one, without any setup upfront.

Gordon:  Let's say I'm a mobile application developer. I'm developing for Android, developing for iOS, probably both platforms in many cases. I need to authenticate users. I maybe need some data store in the backend to maybe store information about my users across different instances of the application and so forth. What do I do?

Sravish:  You come to Kinvey, you sign up for an account, and we have this notion of add‑ons. An add‑on is a specific backend feature that you want. You can use us as the entire backend stack, for your entire application, or you can use us for only a handful of features. You would say you want user management, and in that case, you can use us either to authenticate your users via regular user name and passwords, or you can use any one of the numerous OAuth providers we work with, or you can use us to integrate with an LDAP or Active Directory system that you have. You can use us only for user management if you want, and that ties down to your mobile libraries. You can also turn on a data store, and that gives you a full data store as well as a file store, to store anything from data to large files and videos. You can also use us to run business logic or connect to your enterprise OAuth system.

It's essentially, you decide, as a developer, which backend features you want, you turn them on, and then you consume them through our libraries. The one nice thing that you get is, whether you use one feature or whether you use all the features, we have an in‑house mobile analytics platform, so we track all of your usage and tie them into identity of the users so you know who's doing what over time with your mobile application.

Gordon:  What would be the relationship with something like your Backend as a Service to, say, an on‑premise Platform as a Service, like OpenShift? How would you use those things together?

Sravish:  We find that relationship very important. The reason is we believe that mobile is one of the key drivers of cloud in the enterprise. As CIOs are championing mobile and tablet projects, they want to build those mobile and tablet projects using cloud infrastructure. A lot of the data that these mobile and tablet projects have to access is sitting inside the firewall. By partnering and working together with a company like OpenShift that provides both on‑prem as well as cloud‑based Platform as a Service, the enterprises have the flexibility to connect their data with Kinvey by running what we call a data link on these PaaS environments. It's completely secure. It stays on‑prem, running on OpenShift, and then can be consumed by the mobile developer through the library.

From a mobile‑developer standpoint, all that connectivity is abstracted. It's connected via their library into Kinvey, and Kinvey then connects to an on‑prem OpenShift environment and moves the data back and forth through OpenShift.

Gordon:  What's your business model here?

Sravish:  We are a classic cloud‑based subscription model. Customers pay us on a monthly basis, as long as their apps are alive. The kinds of research that we've done is, for a classic enterprise application, on average, enterprises spend anywhere from $250,000 to $500,000 per application per year, and this is to build it and then maintain it on an ongoing basis. With Kinvey and companies like OpenShift, the joint value proposition goes from a half a million dollars to closer to about $50K to $100K for an application. It's a substantial savings for the customer. They pay us anywhere from a few hundred to a few thousand dollars a month, as long as the app is live. It's a very small buy‑in for an enterprise to keep an application going.

Gordon:  You're very involved in the mobile‑development space. What are some of the interesting trends you see happening that our listeners might be interested in?

Sravish:  I think a couple of years ago, when folks were using Kinvey, we found that iOS was, by far, the number‑one platform people were building apps on. Now, we're seeing that Android and JavaScript applications are the fastest‑growing kinds of apps on Kinvey. We find a tremendous number of Java developers that are picking up Android and building Android apps. We find a large number of Web developers that are migrating to building HTML5‑based mobile applications and using tools like PhoneGap to create hybrid applications.

A big trend is the growing adoption of Android development and JavaScript‑based development. Then the other is enterprises are now making buying decisions today to build a standard mobile stack. Most enterprises are slowly and surely building out their mobile reference architecture, and as part of that, cloud is becoming an integral solution for how they deliver these mobile services.

The combination of growth in Android and JavaScript, as well as the growth in enterprise mobile applications, are two big trends that we're seeing today with our business.

Gordon:  That's actually interesting, because one of the things we at Red Hat are seeing with our OpenShift PaaS, in the enterprise space in particular, is a lot of organizations are really looking at PaaS to standardize their development work flows. Part of that is obviously having common sets of composable services that you can plug into your applications rather than writing a new authentication module every time you write an application.

Sravish:  That's absolutely right. The same explanation also exists for mobile. People want a standardized mechanism to build mobile applications. Part of the issue, quite frankly, is skills. If you go to an enterprise and say, "Who's building your mobile applications or tablet applications today?" very few of them have complete in house skills to build these mobile apps. And so, they are using SIs or dev agencies to build up these applications.

And so, they don't want to make the mistake where every project is built in a silo and then they have to deal with all this legacy. Instead, they're looking at what are these standardized building blocks that every stakeholder uses on a consistent basis to build the same kinds of mobile applications.

Gordon:  Of course, you talked about things like dev team security. There's a real risk if somebody who doesn't have the skills just sort of hacks something together.

Sravish:  Absolutely. In this BYOD world where data's sitting on an employee's device, security keys are sitting on people's devices, authentication tokens are sitting on people's devices. You need to make sure that you're providing all the developers, in house or outsourced, the same kinds of frameworks and rules so that you're ensuring that you have a secure application being built.

Gordon:  You mentioned BYOD and enterprise apps. Of course, historically you had enterprise apps that were very much designed for a specific type of client with some sort of proprietary data connect or going back to a specific backend. But today, you really have to develop apps, whether or not they actually end up running on a mobile device or not, so that they can run on a mobile device because really, the movement is towards having client side just being whatever and connecting to a backend.

Sravish:  I wholeheartedly agree. I think it's definitely a ubiquitous use case. People need access to data when and where they need it. As an enterprise, you can't decide anymore whether somebody should only have access on a desktop or not. Furthermore, it's not only connecting to one backend. I think enterprise thinking has changed, where they're thinking about, "How do I make my employees most efficient?" That includes connecting to multiple backends.

For example, it's no longer that I want to give my employee field Salesforce rep just a CRM app. I want to connect my CMS with my CRM so that, through this single app, my sales rep can not only update customer information but can also download and access presentation material or brochures that I want to show my customer when I'm talking to him or her.

Now, apps are getting sophisticated and connecting to multiple backend systems, but providing a much more streamlined capability through one application.

Gordon:  It's interesting, this mega trend of things coming from the consumer world, and enterprise certainly needing more things in terms of authentication and governance and audit and that kind of thing, but still, in many ways, being an outgrowth of the simplicity and so forth of the consumer area. Your company itself has kind of evolved from a B2C‑oriented business towards increasingly B2B.

Sravish:  Yeah, fair and absolutely. In fact, there's a parallel there. The parallel is we're all familiar with the phrase "consumerization of IT," where employees and enterprises want services to look and feel like the B2C applications that they're used to. I also feel that there is a thing called the "developerization of IT." I think developers today that work in big companies go and muck around with Amazon Web Services or other public services, and they know what self‑service looks and feels like. They're demanding the same level of usability for enterprise development tools in‑house.

I think it's forcing ISVs, like Red Hat and like Kinvey, to start providing its tools and its services in a completely documented, self‑service fashion, to make it really easy to stand up applications for customers.

Gordon:  I think the case can perhaps be overstated, but my former colleague, Stephen O'Grady, has a new book out called "The New Kingmakers," and the idea really being that developers really are increasingly in control of buying decisions within enterprises.

Sravish:  That's definitely true. In fact, a lot of our focus was building a strong developer community from day one for Kinvey. In the last two years, we've been able to do so. Now that we have an enterprise product that's up and running, a lot of these developers who are using us for their side projects and for their personal apps have contacted us and said, "Hey, we would love to see if you can come in and provide value in our day jobs."

And so, it's the folks that were using us for their side projects that are not becoming our proponents inside their companies.

Gordon:  That reflects what we've been doing with OpenShift as well. We've been putting a lot of energy into not only being open source but making that open source simple to consume and really putting a lot of energy into putting information for developers out there that isn't even necessarily product specific like how do you write a very geolocation aware type of application?

Sravish:  Totally. Examples, examples, examples. If developers can learn through your content, then they will start to create a brand affinity with you where they respect the fact that you're actually helping them with their skills and they're more in tune with wanting to work with your products.

Gordon:  Anything else you'd like to add?

Sravish:  No, this has been fantastic. The next time we chat, I look forward to a much more detailed integration on how OpenShift and Kinvey can work together.

Gordon:  That would be great. If our listeners want to get out there and try out your service, what do they do?

Sravish:  They go to Kinvey.com. K‑I‑N‑V‑E‑Y or you can just search for Backend as a Service on Google and we're the first link that shows up. You can sign up. It's free. You can start building mobile applications tomorrow.

Gordon:  That's great. Thanks for your time.

Sravish:  Thanks so much, Gordon.

Links for 05-07-2013

• The Harold and Maude Project Home Page
• Cheating to Learn: How a UCLA professor gamed a game theory midterm | Which Way L.A.?
• Course Catalog for Free Online Classes - Udacity
• Stanford Online
• (404) http://t.co/XkxdxR8I - RT @opensourceway: Since it is conference season: Writing an Excellent Post-Event Wrap Up Report | Hawthorn Landings | …
• Solving Equation of a Hit Film Script, With Data - NYTimes.com
• 50 Years of Stupid Grammar Advice - The Chronicle Review - The Chronicle of Higher Education - "Notice what I am objecting to is not the style advice in Elements, which might best be described the way The Hitchhiker's Guide to the Galaxy describes Earth: mostly harmless. Some of the recommendations are vapid, like "Be clear" (how could one disagree?). Some are tautologous, like "Do not explain too much." (Explaining too much means explaining more than you should, so of course you shouldn't.) Many are useless, like "Omit needless words." (The students who know which words are needless don't need the instruction.) Even so, it doesn't hurt to lay such well-meant maxims before novice writers."
• jsonviewer.net
• a beginners guide to streamed data from Twitter (tecznotes)
• English and Dravidian: Unlikely parallels | The Economist - RT @TheEconomist: Pairings of languages, like Old English and French, have created fascinatingly hybrid languages around the world
• | data.gov.be
• Where to Find Open Data on the Web – ReadWrite
• (184/1) Data: Where can I find large datasets open to the public? - Quora
• Many Eyes
• Public Data Sets : Amazon Web Services
• HEXAWE | multi boss | piggy tracker | net audio | label & radio
• Behind the Data: Max Shron of OkCupid | visualizing.org
• IDC: Virtualization's March To Cloud Threatens VMware – ReadWrite

How Open is Eating the World (and what it means for marketing)

I gave this presentation at ProductCamp Boston last weekend. I confess to this not being an especially self-documenting deck. I'll try to get a video or narrated version up at some point. You can also download the PDF.

Book Review: Vintage Tomorrows

You probably know O'Reilly for their programming books. However, they also publish books in a variety on variously geeky themes—a number of which I've rather enjoyed. So I readily accepted their PR agency's offer to review a copy of Vintage Tomorrows: A Historian and a Futurist Journey Through Steampunk Into the Future of Technology. One author, James H. Carrott, is a freelance historian and former Xbox 360 hardware product manager. The other, Brian David Johnson, is a futurist at Intel. 

The steampunk themes explored in the book that resonated the most with me were those of exploration and making. 

The Victorian era—steampunk's nominal origin and venue—was a time of great scientific exploration and wonderment, when things like carbon arc lights were still marvels.

To light the sea underwater, there is a strong light or 'ships lantern'  in an exterior enclosure at the aft end of the top deck.  The enclosure is tall enough for Nemo to rest his elbows on it while he gazes on the surface of the ocean (perhaps 1.2 m or 47 inches) and the sides must be pretty nearly vertical, also.  The windows are Fresnel lenses with annular rings, like windows in lighthouses.  Fresnel lenses can be circular, square, or cylindrical, surrounding a light, so Verne may have had any of these in mind.  This light illuminates the sea all around the Nautilus so it is more a flood light than a search light with a narrow beam. The light source is an electrical carbon arc in a vacuum, with graphite points.   The exterior light or lantern of the  Nautilus  combines the best technology of Verne's day.

Claire Hummel says in the book that "I really love the Victorian sense of exploration, never giving up on exploring new things and new worlds. We have covered most of the planet but we still discover new deep sea creatures or go into outer space. That's why I like steampunk—at it's core it's about discovery and wonder."

According the authors of Vintage Tomorrows—and their many interviewees—steampunk is also a celebration of making, the antithesis to mass-produced, featureless goods. As Cory Doctorow puts it in an interview: "Technology should be tinkerable." This dovetails into ideas such as individuality, the ability to change, and the control over technology. 

As Carrott notes:

There was a time when you could take apart devices. A pocket watch is just one example. People took apart things like rotary phones, transistor radios and cigarette lighters. An ordinary person could take one of these apart, understand how it worked, and maybe even put it back together! Empowering, right? You were smarter than the device. You understood how it worked.

The book features lots of interesting interviews, rumination, and dinner party conversations around steampunk and vaguely related topics. I'm sure that I (and many of you) would have enjoyed being guests at those dinners and other events. 

That said, the prologue warns that "We couldn't tell this story in a traditional manner. It literally defied our every attempt. So we gave in and let it lead us."

In fact, the book is not really a narrative on the topic as you'd probably expect, but more of a journal or memoir about writing the book and filming the associated documentary. It doesn't really have a narrative flow as such. 

I also confess to finding that the style of Carrot's writing in particular—most of the book explicitly separates the voices of the two authors—often seemed to be about making interviews as much about himself as his subject:

"Well, there's something going on," he [science fiction author William Gibson] agreed. "There's something wider going on culturally that I don't identify with steampunk, but I think steampunk might be another slightly more exotic symptom of it."

I couldn't suppress a grin. Bill-freaking-Gibson (I know that's not his middle name) had just, without prompting or a direct question, affirmed the suspicions I'd voiced from the story of this project. There's something bigger going on. And that's what this chapter is really about—the something bigger.

Far from being unique, the above text typifies much of the book. It's not a case of an author occasionally personalizing some experience. It's about constant interjection.

Furthermore, the book makes frequent references to works such as Gibson's The Difference Engine, a book which the index tells me is mentioned on eight different pages. Yet, although it also profusely quotes Cory Doctorow's introduction to a 2010 edition of The Difference Engine, it nowhere really explains what it is about this work that makes it worthy of so much attention in a book about steampunk and how it relates to the various steampunk themes discussed throughout.

Such is probably the nature of interviews; interviewees don't always provide a lot of context for what is, to them, well-plowed ground. But that's the value of wrapping interviews with additional narrative and background. Of which there's too little here.

Ultimately, this book contains plenty of interesting—even fascinating—primary source material. And that may well be enough for someone with a strong interest in the topic at hand. It was (barely) for me. But I can't help feeling that Vintage Tomorrows succeeds better as source material for a book about a "journey through steampunk into the future of technology" than it is at being that book.