Open Source

Re-imagining the App Store in the Cloud

The app formerly known as PhoneGap (now Apache Cordova) started out with a very telling name. PhoneGap/Cordova bridges the gap between a native application’s and a browser’s access to device APIs, thereby allowing you to develop apps in pure HTML5, CSS3, and JavaScript. In addition, you can wrap up and deploy your web-standards-based application to an app store.

But a native OS could provide the same API through the browser. The major drawback to this approach is the loss of revenue generated by the app store through app purchases and in-app purchases. This gives little incentive for OS manufacturers to implement these APIs through the browser. But let’s re-imagine the app store in the cloud for a moment and see how browser support for native APIs could enable this.

Mobile Devices as a Portal

A recent article on Technorati described Google’s new hardware offering which essentially provides a “portal into Google-land.” Chrome essentially becomes the OS for the device and Google Drive becomes the hard-drive. Expanding this idea into the mobile realm is not difficult to imagine, but what value does this provide other than giving us a common place to store documents and photos?

Right now the focus of the cloud in terms of consumers has seemed to revolve around storage. How can I get all of my “stuff” in one place where I can access it from anywhere? Think DropBox, Google Drive, etc. This is an interesting problem, but only the beginning. The next step is taking our Apps and making them accessible from anywhere. After buying a new App for my phone, it would be great if I had immediate access to this same App from my other devices, my tablet, my laptop, etc. and vice versa without the need to download anything on those devices.

App Store in the Cloud

Chrome recently released the ability to login, making your tabs and bookmarks accessible across all devices that are running Chrome. This is a novel concept and could be further applied to the App Store. The starting point in your browser could be a layout of all of the Apps that you have purchased and would look very similar to the native OS representation of your App icons. In addition, one of those Apps could guide you to the App Store which allows you to purchase these Apps. Each App then runs directly in your browser and stores all its data on an external server.

This may appear to have little value initially, but now I could login to my tablet and immediately have access to the same App that I just purchased through its browser. All of my data would be accessible and there is no requirement to find and download anything further. By implementing Apps using web standards (HTML5, CSS3, and JavaScript), the adjustment between devices could all be handled through styling differences. This allows the OS manufacturers to continue to reap revenue from App store purchases, while giving the consumer the advantage of ubiquitous access to their Apps. You could even imagine a pricing model that differs based on which devices you want to enable access from.

The Future is Here… Almost

Firefox OS takes exactly this approach. From the introduction:

The idea is essentially to have all user-accessible software running on the phone be a Web app that uses advanced HTML5 techniques and device APIs to access the phone’s hardware directly via JavaScript. For Web developers, the most important part to understand is that the entire user interface is a Web app, one that is capable of displaying and launching other Web apps. Any modifications you make to the user interface and any applications you create to run on Firefox OS are Web pages, albeit with enhanced access to the mobile device’s hardware and services.

To publish a web application as a Firefox OS App, you simply have to add an app manifest, “a JSON file that describes your app, including its name, its icons, and a human-readable description.” The Marketplace then uses the information provided by the manifest to publish your web application to Firefox OS users.

Firefox OS will likely spurn competition between the OS manufacturers and it appears that Google is already making inroads into the approach with their recent releases. At the moment, the following issues remain although several will likely be solved in the next few years:

  • Native APIs – the Android and iOS browsers just don’t have access to them… yet. Apache Cordova has been a well-recognized stop-gap approach, but as browsers continue to adapt, will no longer be necessary in the future.
  • Performance – Facebook CEO Mark Zuckerberg recently discussed the issues with browser performance on mobile devices after choosing HTML5 as their strategic approach. This will only improve as time goes on and devices become more capable.
  • Connectivity – ubiquitous connectivity just doesn’t exist yet. In the basement of the parking garage, on a remote island… still having access to certain applications is beneficial in these scenarios.
  • Games – as with desktop computing, games require an extensive amount of native API access and have performance requirements that put general Apps to shame. Unless there are breakthroughs in SVG support that make gaming a snap in the browser, games will likely remain native.

Being a believer in web standards and seeing the exciting possibilities of HTML5, Firefox OS truly presents a breath of fresh air. Let’s hope that the other OS manufacturers take notice.

Power up your HTML5 with D3

The power of HTML5 is remarkable. I’ve seen impressive demos in presentations and great looking example pages that people have developed in their spare time, but it always looks highly complex. In addition, the examples are usually just that, examples, with little to no real world application. Here we’ll look at an example that shows how D3 enables HTML5 to provide real business value.

D3 helps to hide some of that complexity, allows you to operate directly on data sets, and provides the capabilities necessary to quickly apply the power of HTML5 in real-world scenarios. This javascript library uses HTML5 standards to generate some of the flashiest (sans Flash) visualizations I’ve seen from a library. While it has a feel similar to jQuery, the use of SVG makes the animations much more advanced.

Let’s look at an example that creates a simple bar graph. You can review the example by itself here. Or, simply click “GO” below the to see the bar graph in action.

This animation uses no images or flash, just HTML5 standards with the help of D3. When you view the source, you’ll notice that an <svg> element is defined, sized to the expected width and height of our bar graph.

<svg id="bargraph" width="800" height="400"></svg>

The bar graph is generated from the following logic:

bargraph().data([10, 18, 12, 24, 15, 13, 22, 17, 8]).plot();

Defining the bargraph object

The first step is to define our object:

function bargraph() {
  var colors = ["#2d578b", "steelblue", "#777"],
    data = [10, 15, 20],
    xCoordinateSpacing = 50,
    yCoordinateSpacing = 70;
	
  function bargraph() {
		
  }
	
  bargraph.data = function(d) {
    data = d;		
    return bargraph;
  }

  // … …
}

The bargraph object defines a set of attributes. The colors attribute defines the various colors the bars will be. The data attribute is an array of numbers that will be plotted on the bar graph. We can change the default list of data points by invoking the data() method. The xCoordinateSpacing and yCoordinateSpacing attributes are simply common attributes for plotting shapes consistently.

Now let’s look at the render() method.

bargraph.plot = function() {
  svg = d3.select("#bargraph").append("g");
		
  renderDataPointsAsStrings(svg);
  renderGoButton(svg);
}

The first step is to define a group within the <svg> element to contain our SVG shapes. Once the group is defined, we pass it to the methods that render our data points and the “GO” button.

Rendering the data points

Now let’s render the data points.

function renderDataPointsAsStrings(svg) {
  var text = svg.selectAll("text").data(data, String);

  text.enter().append("text")
    .text(String)
    .attr("x", function(d, i) {
      return i * xCoordinateSpacing + 20;
    })
    .attr("y", yCoordinateSpacing);
}

This method appends the data points as elements. If you are unfamiliar with the syntax of D3, here is a quick rundown:

  • svg.selectAll(selector) – follows similar selector syntax to jQuery and returns a list of results matching your selector
  • data – defines the data points you want to operate on across the selected elements
  • elements.enter() – for each data point the enter logic will be invoked

This is a common pattern in D3 that you will see consistently. Notice that for every data point we append a text element. The attributes of the text element can be calculated by a function or simply provided directly. Here we show both options.

The actual text we are going to show in each text element is the data element itself. By passing the javascript String function to the text method we are indicating this.

We make use of the xCoordinateSpacing and yCoordinateSpacing attributes to determine the starting points of each data element. The “x” attribute is simply a calculation that evenly spaces the text elements. The functions can receive both a d and i parameter providing both the data point itself and the index of the data point respectively.

Showing the bar graph

The “GO” button itself is rendered by the renderGoButton method, but once rendered, an onclick event is attached that shows the bar graph:

svg.selectAll(".gobutton").on("click", function() {
  showBarGraph(svg);
  // … …
});

Here we select on a CSS class selector and attach a function to fire onclick. The showBarGraph() method performs the magic necessary to render the bar graph:

  function showBarGraph(svg) {
    var rect = svg.selectAll("rect").data(data, String);

    rect.enter().append("rect")
      .attr("class", "bargraph")
      .attr("x", function(d, i) {
        return i * xCoordinateSpacing;
      })
      .attr("y", yCoordinateSpacing + 10)
      .attr("width", xCoordinateSpacing - 10)
      .attr("height", 0)
      .attr("fill", function(d, i) {
        return colors[i % colors.length];
      });
		
    svg.selectAll(".bargraph").transition().duration(1000)
      .attr("height", function(d) {
        return d * 5;
      });
  }	

Here we again follow the pattern we described previously. For each data point we append a rectangle shape below the text we rendered previously. By using the xCoordinateSpacing and yCoordinateSpacing attributes to calculate the “x”, “y”, and “width” attributes, we are provided consistency in the location of are rectangles in comparison to the text.

Notice the use of the “fill” attribute. Here we utilize the index of each data point to vary the color of each rectangle based on our colors array. Finally, we apply a transition to the bars that causes them to expand to a height representative of each data point over the course of 1 second. We are using the most basic transition, but through the use of the ease() method, you can vary the style of transition.

That’s it! There’s more to the example as you review the source code, so if you have any questions please feel free to post them in the comments. Also, for more complex examples and some great tutorials, visit the D3 website.

7 Strategic Reasons to use Open Source Software

Even with the prominence of open source in today’s market, as a consultant, I am often asked to bolster the argument about why open source is the right option.  Convincing management that open source solutions make sense is imperative.  The following reasons describe why open source makes sense from a strategic business perspective.

Limit your risk

Companies fail and in today’s volatile market it is important to limit risk by not leaning too heavily on a company’s viability. Closed-source software increases this risk as the fate of the software is tied to the vendor who creates the software. With open source software, this risk is mitigated. Even if the company fails, the source is available allowing you to continue to use the product while a migration strategy is formulated.

Ensure a quality product

Closed source software is limited by the number of developers on staff that can resolve bugs while adding features to the software. Open source software is maintained by the community and end users are able to participate in that development. While there are a limited number of individuals able to alter the product itself, they are aided by community members pouring over the source identifying bugs and submitting patches. With all of these eyes on the source, this leads to a higher quality end product.

Development for free

Cost cutting is critical to the success of the business.  Bug-fixes, features, and documentation all incur cost for your IT organization. With open source, these requirements are developed and maintained by the community. If the community has not yet addressed an issue, participation in the community is easy by simply getting involved.

Only pay for what you need

Developing a product using open source software is an investment in effort. A software product can be implemented rapidly and released with minimal cost. Yet, many organizations will want support for products they are releasing into a production environment. Enterprise level open source software products are backed by organizations that provide this support as well as indemnification for their products.

Attract the best talent

Have you heard of the 10x developer? These developers are 10 times as productive as their peers due to their skill and passion for what they do. The open source community is full of these talented, passionate developers ready to work on an exciting project. By using the products that interest these developers, your organization will attract these highly skilled individuals and increase the productivity of your organization.

Validated by industry use

The “free” aspect of open source software has led to rapid, widespread adoption in both small and large organizations alike. This has led to the validation of these products in far-reaching domains and production environments. Rather than relying on the promises of a vendor, you can be assured by industry use that the product will meet your expectations.

Product transparency

Being developed by a community means transparency. Bugs are found, short-comings are noted, and new capabilities are discussed and voted upon all in a public forum. This not only allows your organization to stay informed, but also provide input on product direction.  Open source software evolves according to market demand rather than being tied to vendor constraints.

None of this is to say that proprietary solutions are unreasonable. But with these reasons in mind, open source software products should be considered as a viable option. As with proprietary solutions, open source software products should be evaluated according to the features they provide, market share, and cost benefit to the organization.

If you have reasons of your own, I would certainly like to hear them.