Category: Tools

Categories
APIs Platforms Tools

Do-it-yourself NLP versus wit, LUIS, or api.ai

 

NPL_bot_

 

Alex and I have been building bots for about 1.5 years and have talked to hundreds of bot devs through our BotsBerlin meetup, which now has over 1,000 members. Something we get asked a lot is whether it’s worth investing in building your own NLP engine, or whether it makes sense to use a third party service like wit.ai, LUIS, or api.ai.

What does a chatbot’s NLP engine do?

Let’s say you’re building a restaurant bot. These tools will help you take a sentence typed by a human, and turn them into structured data, for example:

 

NLP Module chatbots

 

Do you build yours or use third-party tools? Let us know in our DE Survey.

The structure on the right is something computers can actually work with, and you can pass this on to the business logic of your bot. For example, you would probably query the Foursquare API and fetch a list of restaurants. If there are some popular restaurants matching those constraints, you would probably suggest those to your user. If not, you might suggest a Chinese restaurant instead.

NLP-api-chatbots

Foursquare has already done the hard work of finding matching restaurants, so the trickiest part of building this MVP is finding a way to generate structured data from natural language. The great thing about tools like wit, LUIS, and api.ai is that they make this part so easy that you can build an MVP like the above in an afternoon. In our experience, 3rd party tools are an excellent way to build quick prototypes. You could just as quickly build a bot to find videos with the YouTube API, or products from Product Hunt.

Reasons to do it yourself

If your restaurant bot is a runaway success, you will inevitably want to become independent. We see that the more advanced bot teams are all developing their own NLP. Data from the Developer Economics surveys, which polled the opinions of thousands of developers interested in chatbots, are pointing towards a democratisation of chatbots through open source projects (there’s a live survey out now if you want to contribute to this knowledge pool).
Here are three real-life examples of why people switch.

API constraints

databot was a Slack app we built at the start of 2016. Databot would connect your data warehouse to your Slack, so you could ask

“

what was the ROI like for October’s facebook ads?

”

and databot would generate the corresponding SQL query and answer your question.

We started off using wit.ai, which would always default to guessing that October referred to the following October, not the previous one. So we had a lot of fun with our date library to build a workaround. Of course wit could add a feature to let you customise this default, but that’s missing the more general point. If you use an API you are have to live with someone else’s engineering decisions, and that friction tends to grow as your project matures.

Data ownership

We talked to a startup building a commerce bot, specifically one which let you look for presents for friends and family and find good deals, e.g. “my sister likes running and craft coffee and I want to spend around $30”. For them, gathering the data around people’s purchasing intentions is core to the value of their business, and they want to make sure it belongs to them. Moreover, for privacy sensitive verticals like insurance, health, and banking, sending every message to a 3rd party is not an option, users and businesses just aren’t comfortable with it.

Performance

Admithub is an education startup. This team actually has one of the most technically advanced NLP modules I’ve seen, it can recognise thousands of intents. Their bot helps university students by updating them about events and deadlines, and can answer questions ranging from “when are housing applications due?” to “can I have a salamander in my dorm room”.

AdmitHub found very quickly that third party tools weren’t up to this task (they tend to optimise for the small data use case, performing well even when a developer is getting started and there are only a few examples). Most also failed to handle misspelled words, which are common when chatting with teenagers. While simple bots are generalizable, sophisticated bots are all complicated in their own way. Every algorithm has trade-offs, and a one-size-fits-all approach can let you down when your use case becomes more advanced.

Bonus: Control your own fate

Ultimately, technological independence is compelling for many teams. It’s great to use free tools developed by big tech companies, but they may not stay free (Microsoft have started charging for LUIS) and they may disappear with little notice (like Parse did).

The rise of do-it-yourself NLP

{wit,LUIS,api}.ai are wonderful tools that make prototyping very quick. But from talking to dozens of bot teams, I’m convinced that everyone will eventually become independent. Early indications from the state of AI survey are that virtually all businesses are uncomfortable relying on APIs for their AI, and that doesn’t surprise me given the examples I’ve just talked about. The engineering case is that web APIs just aren’t the solution to every problem in programming. The business case is that you really want to own your data and be independent.

In 2017 we will see the bots that have traction moving away from 3rd party NLP services. The biggest drawback, until now, has been the engineering investment and machine learning talent required to build a custom NLP engine. It makes no sense every bot team to reinvent the same things, so at LASTMILE we decided to open source ours. You can find out more at rasa.ai. 

 

Are you involved in ML and/or AI? Take the Developer Economics Survey and shape the future of ML/AI development.

Categories
News and Resources Tools

Oculus previews a new untethered VR headset

razer fund gaming startups

Welcome to DeveloperEconomics’ weekly news roundup. In this edition Oculus previews a new untethered headset, Cyanogen shifts business strategy to a modular OS program and online furniture store Wayfair releases its first API. Read on for the full news rundown.

 

Oculus working on cheap untethered headset

 

Oculus revealed plans to release an untethered VR headset during its developer conference last week. The new VR device is intended to sit between mobile and full PC experiences, without relying on a separate smart device, like Google Daydream. The device is currently in a prototype stage and Oculus has remained silent on a release date.

 

Cyanogen shifts to Modular OS program

 

Cyanogen has appointed a new CEO and says it will shift its business model toward a Modular OS program. The new Modular OS program gives developers more freedom to borrow from Cyanogen’s technology, removing the limitations of the full Cyanogen OS stack. The company previously admitted it was having difficulty scaling its userbase and laid-off 20% of its staff earlier this summer.

 

iOS 10 adoption outpacing all other iOS versions

 

iOS 10 is now installed on 66% of active devices, according to marketing firm Fiksu. The adoption of the latest version of Apple’s mobile OS has been faster than all previous versions, according to the company. A Fiksu representative said: “We’ve never seen this kind of acceleration in the adoption curve for an iOS upgrade.” Apple’s official numbers dispute Fiksu’s and claims the OS has reach 54% of devices.

 

Oculus introduces $499 VR-ready PC

 

Oculus showed-off an VR-ready PC costing just $499, during its developer summit last week. The rig meets new Oculus minimum requirements, enabled by asynchronous spacewarp technology, which lets 45 frames per second look like 90 frames per second. The new price point is half the cost of the VR-ready PC Oculus introduced last year.

 

WaveMaker enhances app tool API integrations

 

WaveMaker has updated its platform to allow enterprise devs to create hybrid mobile apps. The update supports integrations of apps on any stack, including Java, .NET, PHP, Python and Node.js. WaveMaker says its new platform also doesn’t require the deployment of server-side components, required to access data from systems independent of the technology stack.

 

Wayfair launches 3D model API

 

Online furniture retailer Wayfair has released its first API. The API gives developers access to over 10,000 “realistic” 3D furniture and décor models. Wayfair says it’s also working on its own VR and AR app that allows customers to view its catalogue of furniture in their own home.

 

NetBeans 8.2 releases ahead of Apache hand-off

 

Oracle has released version 8.2 of NetBeans. Version 8.2 is the last NetBeans release before the Java IDE leaves Oracle and becomes part of the Apache Software Foundation’s Incubator Project. New features include ECMAScript 6 support, Docker Support, PHP7 support and NodeJS enhancements.

 

Facebook open-sources Yarn, a JavaScript package manager

 

Facebook in collaboration with Exponent, Google and Tilde has open-sourced Yarn, a new Javascript package manager. Facebook are already using Yarn in production. It greatly improves speed compared to the official npm client and adds security by comparing checksums of the modules installed.

 

Visual Studio Code updated with TypeScript 2.0

 

Microsoft released version 1.6 of the code editor, bringing TypeScript 2.0 and more. Other improvements include Format on Save, Switch Windows (partially addresses this issue), search term history and more.

 

Facebook launches Workplace, enterprise social networking

 

Facebook has launched Workplace, an enterprise-focused messaging and social networking service. Workplace has chat, live video and audio calling, multi-emotional reactions and automatic translation services. Workplace has the Graph API for building custom integrations

Sign up for our weekly newsletter, with the latest facts and insights on the app economy.

Categories
Tools

Choosing a Javascript charting library in 2016

javascript charting library

Given the overabundance of tools available to a Javascript developer in 2016, finding and choosing the right one is often a challenge.

Especially when it comes to visualising data, either drawing animated charts or implementing custom interactive infographics, the choice becomes harder since there are a lot of tools out there: Wikipedia’s “Comparison of Javascript charting frameworks” currently lists 44 different libraries, jsgraphs.com currenty stands at 72(!) different charting tools and – to make matters worse – the Google search result for “best javascript charting libraries” over-delivers with approximately 786K results, out of which the first 20 results are all links with titles like “{{integer in multiples of 5}} best javascript libraries”.

Naturally, most of the relevant Stackoverflow questions of the”what is the best tool” nature are “closed as not constructive”.

In this article I aim to help with the above challenge by means of a slightly unconventional approach: In my research I tried to quantify the merits of the most popular libraries, given a series of “developer-friendly” metrics.

Sounds weird and subjective? It is. Read on.

Step 1: Understanding declarative vs imperative approaches

Before we start comparing, it is essential to understand how almost all of the available libraries can be split into two distinct categories based on their approach. Let us borrow from classical computer science and use the “declarative vs imperative” paradigm comparison for this.

The declarative approach

The majority of JS charting libraries follow the declarative paradigm: You write code that describes what you want to end up with, and the library ensures it happens dealing with all the minutiae.

FusionCharts, Highcharts, amCharts, Chart.js etc. all follow this approach: You pick a chart type (column, bar, pie), you specify a configuration object and the library outputs a nice looking interactive chart based on your wishes.

The imperative approach

On the other hand, tools like D3.js, Paper.js or Snap.svg follow the imperative paradigm. They provide you with helper methods which you then need to use to write code that visualises your data step-by-step.

For example, to create a bar chart with D3.js you will need to initialise the canvas, calculate where to draw the axis, draw the axis, calculate where to draw the columns, draw the columns, the legend, the point data, add the events etc.

It does feel a little counter-intuitive to choose any tool that follows the imperative approach, until one sees the amazing work implemented by Mike Bostock (creator of D3.js) for the New York Times, with animated interactive infographics such as the 2012 “512 Paths to the White house” to understand how powerful a library like D3.js can be.

In the next step I made an effort to establish “winners” in each of those two categories.

Step 2: Quantify the popularity of each tool

2.1 Mentions in Google articles

One needs to start from somewhere so my first step was to revisit the “best javascript charting libraries” Google search, filter out to show results only from the past year, open the first 20 hits (first two pages) and note down which libraries were mentioned.

95 libraries in total – see the “Mentions” tab of this Google sheet for a full reference (it’s the first tab – and yes, there exists a library called “Aristocharts”. Seriously).

I then filtered out the list to include only the libraries with at least 4 hits:

javascript-chartinglibrary.1png

Some surprises here already. No amCharts? No mention at all of Paper.js or Snap.svg? Interestingly, the fact that N3-charts “made the cut” here can be construed I believe as a testament to the popularity of Angular.js.

What comes as no surprise is the popularity of D3.js. It is also the only library in this list that follows the “imperative” paradigm making D3.js the clear choice when it comes to that approach. I marked D3.js as the “winner” in the imperative category, filtered it out and continued.

2.2 Licensing

Next step was to establish the license of each library. Many developers are partial to tools that are either open source or come with really relaxed licensing.

Library-mentions-license-visionmobile2

Some reading is involved if one wants to make sense of Google custom license for their “Charts” library (it’s free with a lot of caveats). Interestingly ZingChart offers a free (albeit watermarked) version of its library.

Please note that personal bias prevented me from filtering out the commercial offerings at this stage. I’ve used both Highcharts and FusionCharts in the past to great success and as a result I opted to not judge based on price – until I had all the metrics that is.

2.3 Github stars and watchers

Does the library have a repo in Github? And if yes, how many people are watching, how many have starred it? I intentionally steered clear of other Github measurements such as number of contributions or PRs since each repo has owners and each owner has his / her own personal approach towards how “open” they are to contributions.

On the other hand, a project’s star rating is a clear indication of how many developers (rather than simply users) “like” it. The “Watch” metric also tells us the number of devs who actively want to be notified when new things happen in the project.

javascript charting library

Google Charts had a few github repos but they were for projects that wrap / package their “Google Charts” project, e.g. GoogleWebComponents.

Two things stood out for me in the table above. The massive community support for ChartJS  – almost the same number of stars as Backbone.JS (!) – as well as the number of people who are watching Chart.js.

What is also surprising is that out of the three commercial offerings, Highcharts number of stars is orders of magnitude higher than the rest.

2.4 Stackoverflow tagged questions

Another metric that can tell us how many people are using a library is to see the number of questions that are “tagged” in stackoverflow for a specific library.

This is not foolproof – one might argue that extremely well designed and structured libraries will be so intuitive in their use that people will not be asking questions about them – but my personal experience has shown that even the simplest of tools generate a lot of questions when used by a lot of people.

javascript charting library comparison

Is Highcharts the most difficult library of all? Or is it perhaps the most widely-used one? Perhaps its developers are extremely responsive to the questions of the community? We cannot answer this with 100% confidence. What these counts show however, is that highcharts has more tagged questions in Stackoverflow than all rest of the libraries combined.

Choosing the winners

Since I’ve already opted for a (completely) subjective approach, what better way to pick a winner by simply…. adding everything up.

Here are the top 5 libraries sorted by “Score”, i.e. the sum of github stars, github watchers and stackoverflow tagged questions:

javascript charting library comparison

Full data available on the “Final results” tab of this Google sheet.

Declarative approach – Open source – Chart.js

If the Github stars are anything to judge by, there is a lot of developer enthusiasm for what Chart.js offers.

The documentation is clear and concise – http://www.chartjs.org/docs/ – with several inline examples, browser support is solid (as long as <canvas> is supported chart.js will work – this means no IE8 and some inconsistencies on <= IE 10) and the 8 chart types it offers should be more than enough for most needs.

Declarative approach – Commercial – Highcharts

I’m an avid user of Highcharts and I was pleasantly surprised to see it “rising” in the ranks of my little quantitative experiment. The massive number of stackoverflow questions clearly signifies that despite its commercial nature, the community uses it… a lot. The high number of github stars – (I repeat: for a commercial project) – is also quite indicative of the “developer feelings” for Highcharts.

The documentation is stellar (with a really powerful “Demo” showcase where every single example is linked to a working JSFiddle), the API browser / reference is a great resource and browser support is not an issue since Highcharts auto-falls back to VML rendering for older IE browsers.

Check out this JSFiddle to see how easy it is to visualise a table like the one shown in “Choosing the winners” above:

choosing a javascript ibrary

Imperative approach – Open source – D3.js

The central principle of D3 is to enable developers to programmatically construct SVG objects and render them as they see fit. As long as you can visualise it, D3.js can help you (a) draw it, (b) make it interactive and (c) animate it.

D3.js is the tool to use when a charting library simply won’t cut it. And the community demonstrates this very clearly:

Github stars – 54848
Github watchers – 2653
Stackoverflow tagged questions – 22036

If I had to score this the same way I scored the charting libraries, then D3 leaves everyone behind by a factor of 2 with a score of 79537.

Categories
Tools

The state of UI and Interaction Prototyping tools in 2015

UI design

The UI design process has changed radically over the past few years. With the addition of innumerous tools for wireframing and prototyping, designers are spoilt for choice. Which is the best tool to use?

One thing is for sure, static designs simply won’t cut it any more. A designer ought to employ animation and interactive elements to stand-out from the crowd, now more than ever.

Why Prototype?

A prototype is an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from.

The most obvious reason to incorporate prototyping in your design process is the ability to evaluate the interaction pattern before moving to development phase. This is extremely important especially for mobile applications, where implementing an advanced animation or interaction usually takes a significant amount of time compared to desktop websites. Prototyping will solve your design problems before they even arise.

The other major reason is to enhance intercommunication between designers and developers. While an animation might be very clear in the designer’s mind, a developer will often struggle to actually visualise and implement it. That’s where prototyping comes into play. Instead of trying to verbally explain how the UI design should look or feel like, the designer can use a visual prototyping tool to communicate to the development team exactly what they have in mind.

Flow Prototyping

The most basic form of prototyping that every designer needs to know is flow prototyping, which can be used to create an interactive and functional screen-to-screen prototype. Flow prototyping can help showcase a product and thus act as the basis of communication between designers and developers.

What you should look for in a proper flow prototyping tool is ease-of-use, speed, collaboration features (e.g. user/team management, comments), and version history.

Invision & Marvel

For basic screen-to-screen prototyping, the two most popular choices are InvisionApp and MarvelApp. Both apps allow designers and product teams to quickly come up with working prototypes for their web or mobile applications by simply uploading screens (or working designs), adding hotspots and transitions from one page to another, and forming solid prototypes that can be used for collaboration and/or developer handoffs.

invision-screenshot

A large amount of transitions between screens is provided out-of-the-box, therefore allowing users to create high-fidelity prototypes with an extremely easy-to-use interface that requires little to no learning time. It’s worth noting however, that none of these apps provide a way to transition or animate individual elements of the UI (with the exception of the overlay feature of Invision that can mimic such behaviors up to a point).

In terms of collaboration, Invision is a clear winner because of its sharing options, user and team management, project management tools, and moodboards. However, the Invision free plan allows for one project only, as opposed to Marvel which has an unlimited projects free plan and is perfect for designers who are just looking for a tool to get the job done without a price.

UI Design: Advanced Interaction Prototyping

When it comes to advanced screen transitions or in-screen animations and interactions, Invision and Marvel are not enough. Τools like Framer, Principle, Quartz Composer and Form make advanced interaction prototyping easy for designers and developers.

Principle

Principle is probably one of the easiest-to-use tools out there, giving designers the ability to create high-fidelity prototypes in a very short period of time, with the great addition of a timeline viewer for better animation handling. If you’ve ever used Keynote for prototyping, you’ll find yourself at home, with an out-of-the-box “Magic Move” transition as well as a variety of tools for advanced transition handling.

Integration with Sketch is excellent, allowing direct copy-paste of layers and groups, which saves time from importing/exporting particular elements – a time-consuming, repetitive task most designers prefer to avoid.

principle-screenshot

Framer

Framer is one of the most advanced prototyping tools out there, mainly because it’s based on code. Unlike Principle, there is no fancy WYSIWYG editor and Drag & Drop interface.

All the interactions and animations are done through CoffeeScript/JavaScript. This naturally results in a steeper learning curve, but on the bright side it means designers can prototype pretty much anything they like.

http://share.framerjs.com/a0aaba2lyu5l/

Framer has a very strong community and an unending collection of examples and tutorials to learn from, which makes it one of the most solid tools for prototyping for people who aren’t afraid of code. It features integrations for both Photoshop and Sketch, allowing for easy asset importing straight from the designs. Prototypes can be viewed on an actual device as well, like all of the other popular tools out there.

Quartz Composer, Origami, Form

Besides purely code-based tools like Framer, and completely WYSIWYG tools like Principle, there is another set of tools that utilize the so-called Visual Programming or Node based Programming. Tools like Quartz Composer or RelativeWave Form (now acquired by Google) let users prototype through building blocks (called patches) that are connected through noodle-like arrows, in order to describe interaction and transitions between states. Although these tools have a much steeper learning curve than Principle, they also allow for more advanced animations and interactions between states – making them an alternative for code-based tools like Framer.

Summing it up

Product Company Cost Advanced animation features Requires coding skills Overall
Invision Invision Free for 1 project, up to 25$/mo for unlimited No No For quick flow prototypes and simple animations. Good collaboration features.
Marvel Marvel Free with limited features, up to 15$/mo No No For quick flow prototypes and simple animations.
Framer Framer 99$ one-off Yes Yes Very detailed prototypes. Steep learning curve. Based on code (Javascript/Coffeescript)
Principle Principle 99$ one-off Yes No Easy to create prototypes and export video. Uses a Visual/WYSIWYG Editor.
Quartz Composer Apple Free (included in the Xcode Development enviroment) Yes No Very detailed prototypes. Steep learning curve. Based on visual programming (nodes).
Form RelativeWave, acquired by Google Free Yes No Very detailed prototypes. Steep learning curve. Based on visual programming (nodes).

For the majority of designers who want basic UI flow prototyping and team collaboration, Invision or Marvel will cover most of their needs, while requiring little to no time to pick up and enabling them to start prototyping right away. When it comes to more advanced transitions and animations, Principle is an excellent choice, taking into account the exceptional ease-of-use and time needed to come up with a solid result. For even more advanced interactions designers can use either Framer if they’re into coding or a Node-based tool like Quartz/Origami or Form if that type of visual programming appeals to them.

One thing is for sure, modern designers should master prototyping and interaction design as soon as possible. Tools might change, but incorporating rapid prototyping and motion design in their workflow will change their perspective and potential and undoubtedly help them create outstanding experiences.

Categories
Tools

Android cryptography tools for beginners

android cryptography tools

Mobile applications draw the attention of hackers more and more each day because they have something that the attackers want, user data. Hard-coded secret keys, personal information stored in plain text on SD cards, usernames and passwords found unencrypted in databases, analytics collected and sent in the clear to remote servers, are just a few cases that make the life of an attacker easier. This post focuses on Android Cryptography tools for beginners

android-cryptography-tools-for-beginners

How do you go about protecting your users’ data? Take the Developer Economics Survey and let us know. You might win amazing prizes and new gear.

Cryptography is the right tool to use in order to protect sensitive data, and ensure confidentiality and/or integrity. On the other hand, [tweetable]cryptography is hard to use and easy to misuse[/tweetable]. Note that broken cryptography (e.g. using insecure algorithms or hard-coding keys into binaries), is listed in the top 10 mobile risks for 2014. So what’s the lesson to be learned? Well, whereas not using cryptography can be bad, not using cryptography in the right way is just as bad (not to mention time-consuming).

Let’s see then how cryptography can be used in a way that’s both easy and appropriate, in order to develop secure applications for the Android platform.

First, an overview of some popular cryptographic libraries that can be integrated into Android applications. Cryptographic libraries can be seen as cryptographic toolsets that contain tools, such as encryption algorithms, padding schemes, and hash functions.

Bouncy Castle

The Legion of the Bouncy Castle is a charity from Australia that has written Bouncy Castle, a widely used library that provides both a light-weight cryptography API and a Java Cryptography Extension (JCE) provider. The Android platform already ships with a cut-down and outdated version of Bouncy Castle (with small changes in order to make it work on Android). Consequently any attempt to build and use the latest full version of the library in your application, results in classloader conflicts.

Spongy Castle

The motivation behind Spongy Castle is to allow Android developers to bundle any version of the Bouncy Castle library they want with their applications. Spongy Castle is basically a repackage of the latest version of the Bouncy Castle library; all org.bouncycastle.* packages have been renamed to org.spongycastle.*, and the Java Security API provider’s name has been changed from BC to SC.

OpenSSL

OpenSSL is an open-source toolkit that provides implementation for the SSL and TLS protocols, as well as a general-purpose cryptography library. OpenSSL has been ported to many platforms, including Android. As an alternative, you can also build it from source (using the Android NDK) and bundle it with your application.

Let’s assume now, that for application purposes, you want to encrypt some data. What encryption algorithm should you use, AES or DES? How long should your key be, 128 or 256 bits? Which encryption mode should you use, ECB or CBC? If you do not have an answer to all these questions, along with a good reason for each answer, then it seems that you have found yourself in a position where, although you probably have all the tools you need, you are not absolutely sure which ones to use and how.

This is exactly the point where cryptographic toolkits for dummies come into play. These toolkits do not implement any exotic cryptographic functionalities, nor do they intend to replace the cryptographic libraries presented above; they rather built on some of them with the sole purpose of making cryptography easier and safer to use.

Contrary to a general-purpose cryptographic library, such a toolkit normally supports only a subset of the algorithms, modes, schemes, parameters, and other cryptographic tools that are out there. Instead it provides you with sensible defaults in case you (a) know what you want to do but don’t know how to do it, or (b) don’t really care as long as you end up with a safe solution. Let’s examine some of these toolkits to better understand their role.

Keyczar

Keyczar is an open-source toolkit originally developed by two members of the Google Security Team. It has implementations in Java, Python and C++. It supports authentication as well as both symmetric and asymmetric encryption. Keyczar provides safe defaults for algorithms, key lengths and modes, key rotation and versioning, automated generation of initialisation vectors and authentication codes, and internationalisation. This specific toolkit is based on JCE, and its demo for Android (available here), uses Spongy Castle’s security provider.

AeroGear Crypto

AeroGear Crypto is a small Java library provided by AeroGear. It supports authenticated symmetric encryption, elliptic curve cryptography, and password-based key derivation. It also provides sensible defaults for algorithms. AeroGear Crypto depends on Spongy Castle for Android and Bouncy Castle for other platforms. The library is also available for iOS, Windows Phone and Cordova.

Conceal

In an attempt to find a fast and memory-efficient way to encrypt and authenticate large files on SD cards, Facebook developed Conceal. Conceal supports both authentication and encryption, and provides default implementations for key management. It uses OpenSSL, but includes only the necessary parts of it, thereby keeping its size at 85KB. Results published on the site of the library show that Conceal outperforms Bouncy Castle.

A summarised view of the libraries presented above is given in the following table. Note that, although all these libraries aim to safely fill in the gaps for developers that are new to cryptography, advanced developers can skip the defaults and specify all the details themselves (as they would do when using any crypto library).

Library Company License
AeroGear Crypto AeroGear Apache 2.0
Conceal Facebook BSD
Keyczar – Apache 2.0

To sum up

If you are a mobile developer, you need to spend time making your applications usable, functional, and attractive BUT you also have to spend time making your application secure. If you do not know how to do so or if you’re worried that you might not get it right, then use one of the libraries described in this article in order to get started. No matter what cryptographic tools you decide to use, avoid implementing your own cryptographic algorithms and/or protocols; use only algorithms and protocols that are widely used, accepted, and ones that users have already spent enough time trying to break.

 

Which skills you can develop to be more effective in protecting your data?Take the Developer Economics Survey and we will let you know. Plus you may win new gear.

Categories
Languages Platforms Tools

Why JavaScript will win on mobile

javascript will win on mobile

JavaScript is not the world’s most elegant programming language. So much so that one of the world’s top experts on the language wrote a book about “The Good Parts”. The book carries the headline “Unearthing the Excellence in JavaScript” because that excellence is quite deeply buried. Even so, it has rapidly become one of the most popular languages in the world. That popularity is deserved, because despite the flaws in the language, JavaScript gives developers significant advantages that they can’t get with other languages. Some of those advantages were created when browser vendors agreed to standardise on JavaScript (OK, technically ECMAScript) as the language for the web. Others are inherent to the web app programming model and more yet have been created through tooling enhancements. However, despite the fact that native apps are dominating web apps on mobile devices, JavaScript’s advantages are steadily transferring to mobile. Will it eventually dominate there too?

why-javascript-will-win-on-mobile

Popularity not priority

The latest TIOBE Community Index has JavaScript in 6th place amongst all programming languages and rising. The TIOBE method of ranking tends to favour older, more established languages and is not so quick to pick up trends. By contrast, the Redmonk rankings have JavaScript in first place. The Redmonk method is somewhat biased towards languages with strong open source communities but more accurately reflects current interest and trends. Our own Developer Economics surveys have shown that [tweetable]HTML5/JavaScript combination is the second most popular language amongst mobile developers[/tweetable] with 55% using it, just narrowly behind Java (at 57%). However, even if we combine those who prioritise HTML5 and JavaScript (19%), they’re still a long way behind Java (29%) on this metric. It seems likely this is going to shift significantly over the next few years. [What do you think? We have a new survey out, so take the survey and let us know your thoughts]

JavaScript breaking free from the browser

This is not a standard “the web will win” argument. I don’t believe that browser or webview-based apps will eventually dominate on mobile devices. Use will grow but they won’t be the norm. If true open web standards are to dominate in the future then they need to move on from the Document Object Model (DOM). The DOM is a base for building documents, not apps. Of course you can build an app around a platform originally designed for documents but you’re starting from a position of handicap. Look at the modern frameworks that allow you to build fairly performant apps for mobile browsers/webviews: React.js, Famo.us and Ionic. All three share the common feature of touching the DOM as little as possible.

Yes, there’s WebGL (or HTML5 Canvas if you must) too but those are low level graphics APIs. You need large, probably multi-megabyte, frameworks on top to create a good platform for building most apps. That’s not a good fit for the web app programming model, where the latest application code lives on a remote server, particularly not in a mobile environment. It’s true that you could have a hybrid app with a large framework on top of WebGL stored locally and just fetch the application specific code from the server but then why use the browser at all? Why not just JavaScript on top of some other cross-platform framework built for hardware graphics acceleration (hint: Qt has a nice offering here). One with a higher level API so there’s not so much overhead bridging between languages. Perhaps also one that’s less restricted when it comes to accessing device specific functionality.

There are now a couple of really interesting new options that fit this description, React Native and NativeScript. These work in different ways but both build apps with a native UI using JavaScript. Appcelerator’s Ti.Next may also be interesting, although they’ve been talking about it for a couple of years without an actual release yet, so we’ll wait and see.

The JavaScript exception

Here is where Apple has restored JavaScript’s advantage on mobile. A key thing that has prevented most developers from adopting an agile, web-style continuous delivery model on mobile is Apple’s ban on code downloading. Without that iteration is significantly slowed and split testing is much harder to do. This effectively means developers, particularly startups, learn slower. Until very recently, the only ways to get more rapid iteration were to go Android first, or build a hybrid app, since Apple made JavaScript downloaded in a webview an exception to the code downloading rule. In the first case it means moving away from the platform with the most early adopters. Unfortunately in the second case the UX trade-offs are too great, with most developers that went that route for a consumer app failing or switching to native. But in iOS 7 Apple added the JavaScriptCore interface to their own JavaScript runtime and in the latest iOS Developer Program License Agreement they modified the exception to code downloading rules to include JavaScriptCore.

This makes sense from a security perspective. Apple can audit and update their own runtimes, whereas if they allow 3rd party runtimes to download code they have no effective way of monitoring or dealing with security issues. Since JavaScript is Apple’s only scripting option and they can’t allow native code downloading, JavaScript is restored to a privileged position – the only option for those that want to iterate fast. The availability of JavaScriptCore triggered efforts like React Native and NativeScript and the timing of Apple’s relaxation of the code downloading policy has been perfectly timed for their public release.

Will open win?

Web advocates sometimes suggest that the open-standards-based web must eventually win because open always wins in the end. However, Linux is a very clear case where an open ecosystem thrives without a committee agreeing standards. With React Native, Facebook appears to be very rapidly building a developer ecosystem around their open source project. Already having a rapidly growing community around React.js obviously gives them a headstart but the NativeScript team at Telerik are working with Google such that Angular 2.0 should integrate seamlessly. Google are going to support non-DOM environments whether the web standards go in that direction or not. Microsoft and Google might take a long time to agree on the standards they’ll implement in their future browser versions but they’re working together on TypeScript, to make it easier to build complex apps with JavaScript (it turns out compilers are much better than people at spotting type mismatches).

Apple has built some fairly impressive tooling for their new Swift language, particularly the interactive playgrounds. However, Facebook possibly already has a better developer experience with React Native in terms of immediate feedback and rapid cycle times whilst coding. Apple will continue to iterate on that tooling alone, whilst the developer community can now enhance the tooling for these new JavaScript environments. Android may technically be open source but it’s not open in terms of community contribution. Google are enhancing the Android platform and tooling alone. [tweetable]Perhaps it’s really open developer communities that win[/tweetable] and genuine open source based communities can iterate faster than open standards based ones. For these “native UX built with JavaScript” environments to succeed, the platforms don’t have to lose. Apps will still be tailored to the platform look and feel and adopt new platform-specific APIs.

Javascript will win on mobile.

At the moment it looks like the very open JavaScript developer community will win because they get to build apps with native look, feel and performance but a web-style development experience. The closed platforms also win because apps are still being tailored for their captive ecosystems. For now, open web standards lose. It seems likely they can only win if the mobile browser vendors can agree to new standards that enable the creation of apps that genuinely offer an equivalent experience to native ones.

Update: Where we right in our predictions? Here is a latest update on the popularity of Javascript.

What do you use?

Do you think JavaScript will dominate on mobile in the future? Or Java, Objective-C and Swift will continue to lead? What about for the Internet of Things, or on the backend via Node.js? Let us know what you’re building your apps with by taking our survey.

Categories
Community Tools

Developer Interview: Building Apps for Wearables Isn’t about Tools

apps for wearables
Digital magazines

Softeq Development is involved in everything mobile: from business apps, digital imaging and utilities to mobile games, wearable technology, sensor-rich equipment and its remote management. They have built dozens of embedded solutions, web, and mobile applications for such clients as Nike, NVIDIA, Omron, AMD, Atlas Copco, EPSON, Disney Parks and Resorts. T. Our associate author, Alkis Polyrakis, discussed with Softeq’s CEO, Chris Howard.

What is the philosophy that you employ in order to assist companies take advantage of the full potential of the latest technology?

To me, our philosophy is to be ahead of the curve. It means we try to know and adopt new APIs, tools, and technologies before customers actually need it. We obtained and evaluated Google Glass, EPSON Moverio, Oculus Rift, LEAP motion controller and many more new tech novelties long before the first project came along. Once a customer approaches us with a project for those new technologies, Softeq is already the most competent tech provider the customer can possibly find on the market. Having close ties with many companies in Silicon Valley, we were one of the first tech firms in the world to access and implement, for example, Microsoft’s high speed video APIs on Windows Phone before they were available to the public.

Digital magazines
Digital magazines

What are the benefits of implementing a Proof of Concept in business projects?

A proof-of-concept (PoC) is a great first step on the way to a new product, device or technology that was never seen before because it’s a low-risk and low-investment approach. Often, it requires a 10-20 times smaller budget than actual new product development.

In our business, we have come across two different goals, or approaches if you like, to building PoC apps. One is when a customer is looking to prove the feasibility of his new business idea. At times, our clients need to demonstrate a working prototype of an upcoming product at a trade show, board meeting, or at an investor meeting. Prototypes later can become Minimum Viable Products (MVPs) and both can be stages of a full product development cycle if the idea gets approval.

Xamarin framework Business apps development
Atlassian Jira Project management
LabView – LabWindows – MathLAB Wearable devices
Flurry – Google Analytics – Localytics – Adjust – Parse Monetization
Unity Games development

Softeq’s Toolset

The second typical need is when a technically advanced company researches next-gen ideas, software or hardware they’re looking to jump into. Here, building a proof-of-concept in the first place is a way to test the feasibility of their vision for the application of new technology, a hardware component, or form factor. Just like that, our R&D teams have been working for Nike, Intel, and EPSON to help then visualize their new ideas and prove it is actually possible to do what they envision.

Do you have a specific development procedure when working on a PoC?

As a PoC is always something pretty innovative and non-standard, generally the development procedure is to identify the key features of what a client is trying to do in a bigger project, focus on only testing and proving out the specific new APIs or new hardware, and building a very simple framework in order to demonstrate that specific capability. After the PoC is approved by the management team, the investor, or the end-client, we proceed to flesh out the rest of the features and ship an actual product.

Which development and project management tools do you employ in order to facilitate your needs in cross platform development?

There are several cross-platform frameworks trending on the market now, and this is fair enough. The mobile market is no longer dominated by one platform, and most of our customers, both in the B2B and B2C segments, need to target wider audiences with various OS preferences. We use the C# based Xamarin framework for business apps, and Unity for games. Speaking of project management tools, we use Atlassian Jira by default or any other tool the client is more comfortable with.

Our readers would like to hear some examples that show how you managed to pump up a company’s marketing efforts with your apps.

Marketing apps for Blizzard and Branson Ultrasonics
Marketing apps for Blizzard and Branson Ultrasonics

Marketing apps vary, and we’ve delivered several dozen of them: from Blizzard’s BlizzCon event management app for helping improve the guest experience, to mobile CRM, promotional games, mobile magazines for corporate clients, and demo apps for tech events and industry-specific trade shows and all the way up to international tech summits and even Mobile World Congress where companies present their new or would-be products. We’ve built several kiosk apps for in-store demonstration of new gadgets to buyers. One of them was for NVIDIA’s SHIELD – the world’s first Android TV console. The kiosk mode allows demonstrating all functional features, including games, videos and music playback, while blocking access to system settings.

What are the main challenges that you face when you attempt to build solutions for wearable devices?

We’ve been working on embedded devices for a very long time, over 15 years now, that’s why the era of wearables came very natural to us. The challenges anyone designing a wearable device inevitably faces are technical limitations of the form factor, such as short battery life, small amount of memory, insufficient performance, custom communication protocols (infrared, Bluetooth low energy) and more.

However, Softeq is uniquely positioned in this market and beyond, in the Internet-of-Things (IoT) space, because we do everything from hardware, low-level and firmware to web backends and mobile apps covering all our departments end-to-end. To extend that further we have a game department, and that even gets mixed in with wearables and the IoT.

Hardware Design and Embedded Development Lab deployed in Softeq's HQs in Houston, Texas
Hardware Design and Embedded Development Lab deployed in Softeq’s HQs in Houston, Texas

Can you tell us about some of your wearable device projects and the tools that you employ?

One of our current projects involves embedded touch panels, and we do both firmware for the panels and Qt-powered games for them. Another product we helped create – the BlinkFX Wink, which is a wireless control LED light wearable device – is being used for an upcoming game show at CBS.

There’s a wide range of tools and instruments, mainly in C, that we use for such projects. For instance, recently we started receiving multiple requests for projects involving drones. We suggest using such behavior modelling tools as LabView, LabWindows and MathLAB, but it’s not the tools that matter most. The most complex part is building math models and algorithms based on them.

Do you provide consulting services as to which model can maximize a game’s revenue?

The monetization system of a game is usually built by a tandem of experts – a game designer and a marketer. The game designer is responsible for building game mechanics in terms of monetization and balancing economics while the marketer drives user acquisition campaigns.
To ensure we deliver the maximum amount of effort on our end to ensure the game’s success, our game designers invest a lot of time in research, comparative analysis of top apps, exploring best practices and efficient mechanics to put them in our arsenal. From the game design perspective, we certainly consult developers at the early stages of building the monetization system: building the core loop, the in-game store, retention mechanics, economics balance, analytics, A/B testing system implementation, etc. For instance, we work with such analytical tools as Flurry, Google Analytics, Localytics, Adjust, Parse and the selection of tools depends largely on the game specifics and client’s preferences.

Thank you very much for taking the time to share your strategy with our readers.

Categories
Languages Tools

The Rise of Mobile C#

mobile c#

Microsoft have been struggling to get traction with their mobile computing efforts, with Windows Phone stuck at around 3% share of the smartphone market. Windows 8 is doing a little better in the tablet market but is still a distant third to iOS and Android. Despite losing in the platform wars, Microsoft’s developer ecosystem is still strong and they’re not showing much sign of wanting to give up their tools. The latest Developer Economics survey showed that 38% of mobile developers were using C# for some of their work and 16% use it as their main language. Those developers are not all focused on Microsoft platforms by a long way. They’re not all building games with Unity either. So what are they doing?

thumb

Not just Windows Phone, particularly not for pros

Whilst 30% of all developers in the survey were targeting Windows Phone, that doesn’t quite account for the majority of those whose main language is C#. Also, more than half of the developers targeting Windows Phone are Hobbyists and Explorers[bctt tweet=”more than half of the developers targeting Windows Phone are Hobbyists and Explorers” username=”DevEconomics”] – i.e. those not working on mobile apps full time. If we focus on full time professional mobile developers, as we will for the rest of this article, then just 50% of those that use C# as their main language are primarily targeting Microsoft platforms. Apple’s iOS (with 23% of developers) and Google’s Android (14%) are in fact more popular targets than Windows 8 (10%). So, how do developers use C# on other platforms? With cross-platform tools, particularly Unity and Xamarin.

More enterprise apps than games

Unity is by far the most popular engine for mobile games, in fact in the Q3 2014 Developer Economics survey a massive 47% of game developers were using it for some of their projects. C# is the most important language in the Unity developer ecosystem, although there are two other languages supported (UnityScript – a JavaScript variant with type annotations – and Boo – a statically typed language with Python-like syntax). However, a lot of developers are using Unity to build games in their spare time. When we look at the full time pros we find that games are only the 4th most popular category of app. The top 3 categories are Business & Productivity tools, Enterprise-specific apps and Utilities, all staples of the enterprise-focused app developer. Developers are either building these apps for Microsoft platforms, using Xamarin to reach iOS and Android with them, or both. Indeed it’s the combination of a familiar language (and code portability) and tooling for many enterprise app developers with the cross-platform reach they can get with Xamarin that’s making C# such a popular choice in this area.

A flexible cross-platform approach

A lot of popular cross-platform tools for mobile development only support iOS and Android. As such, for those also wanting support for Windows Phone and possibly desktop Windows and Mac too, Xamarin is one of very few serious options. That said, it’s not just a default choice. Using Xamarin.Forms, developers can get the write-once-run-anywhere efficiency that drives many decisions to use a cross-platform approach. The downside to this approach is that it can give a lowest common denominator of functionality; not allowing developers to really optimise for the unique features of each platform. However, Xamarin also directly wraps the native platform APIs, allowing developers to call anything in the native SDKs. They can even automatically create bindings for popular third party libraries on each platform. The other key reason developers often go with a native rather than cross-platform approach is performance. However, a recent independent performance test (by an early Google engineer) showed Xamarin’s compiler produces raw performance that’s comparable to native on iOS and Android. Raw performance isn’t the only thing that counts of course – a garbage collection pause causing a stutter in your animation is jarring, however fast the the code is executing otherwise. Enterprises customers will usually put up with mild inconveniences of that nature to get the cost savings and maintenance benefits of a single code base across platforms though.

Better revenues

Possibly the best measure of the success of C# on mobile devices is the revenues of the developers using it. Whether you believe the same level of smoothness in the user experience can be achieved or not, it only matters if it costs users and revenue. Here there is no room for debate. The revenues of full time professional developers whose main language is C# are comparable to, or better than, those of other developers targeting the same primary platform with the native language. For example, the revenue distribution for C# developers on iOS is extremely similar to that for Objective-C developers and the average revenues are higher. This is both because there are more C# developers earning more than $10K (46% vs 36%) per month and while there are slightly fewer earning more than $100K per month (16% vs 17%), a significantly greater fraction of those using C# earn more than $500K per month (14% vs 6%).

This is not to suggest that C# is somehow a better language for targeting iOS than Objective-C. This is correlation and not causation. The cause of the better revenues is that the C# developers are much more likely to be targeting enterprises than the Objective-C developers and that’s where the higher revenues are most likely to be found. There’s an enormous pool of developers trained in C# and related Microsoft technologies. A lot of them are working on desktop enterprise apps or the server side. As it becomes increasingly clear that C# is a viable language for successfully delivering cross-platform mobile solutions, C#’s rise on mobile looks set to continue for several years yet.

The Rise of the Mobile C#

Infragistics

Categories
Tools

Developer Interview: Which tools is WillowTree using?

The official University of Virginia app for Android

WillowTree (www.willowtreeapps.com) is a leading app development company that has produced over 300 titles since 2007, such as My Pregnancy Today that has seen more than 12 million downloads. Our collaborator, Alkis Polyrakis, discussed with their Systems Architect, Alex Shafran, who led the development of projects for GunBroker, Quintiles, the Red Cross and the NBA, about their strategies and tools of preference.

Please begin by giving us some information on a few of WillowTree’s most successful apps.

WillowTree has helped clients succeed in a variety of markets. Johnson & Johnson’s Baby Center apps have been a worldwide success, grossing over 10 million downloads and consistently ranking high in the App Stores. We recently released the new version of the official NCAA app, which is the main source of college sports scores and news. In the enterprise, we built an app for the AOL marketing team that auto-generates sales slideshows based on a quick questionnaire. This app saves each salesperson hours each day and allows them to prepare less and sell more.

BabyCenter Birth Class offers advanced video integration
BabyCenter Birth Class offers advanced video integration

WillowTree claims to tackle complex enterprise-grade mobile deployments by beginning with a simple question: “Where should what logic live?”. Can you explain what this quote means to our readers?

Even the simplest “mobile apps” require infrastructures to support them. Ordinarily, this “backend infrastructure” is software running on a collection of servers in a data center. By asking where should live, we are referring to the separation of concerns between the app on the phone and the backend servers. Consider Pandora, the popular music streaming app. When the Pandora app is downloaded from the App Store, the phone now has the code to run the app. However, the phone must get the music from somewhere — the entire music catalog is not stored on each user’s phone (that would be redundant…and impossible). This is where backend servers come into play. At a basic level, Pandora has a collection of severs that store the millions of songs in their catalog. When the apps need to play a song, they use the internet to download the song in real time from one of these servers.

Pandora is the most obvious example of “where logic should live” — clearly the entire music catalog should not be on each phone. But we encounter different flavors of this problem everyday, from “Should the phones store the user’s password” (the answer is no, NEVER), to something as basic as “Should we use the phone’s clock or the server’s clock in our realtime bidding app?”. While the answers might come easy to us, talking through these details can help our clients understand the benefit of adding an additional component to the system.

The Barclays Center app helped the stadium become one of the most technologically advanced arenas in the world
The Barclays Center app helped the stadium become one of the most technologically advanced arenas in the world

The sheer number of mobile apps that you have developed for major clients is impressive. In addition to quality project management, this is a clear indication that you are using the right development tools. What are those, and how do they make your job easier?

Development tools are only part of the story. They are critical to keeping projects on track, but they must be used as a supplement, not a replacement, to in-person communication. Our entire development team is colocated in Charlottesville, Virginia, which gives us massive efficiencies. When possible, we like to share those efficiencies with our clients. We regularly send entire project teams to client sites, and their development teams visit us just as frequently. There is no replacement for in-person collaboration.

Of course, we also make regular use of phone checkins and online tools. We use Teamwork for project management and communication. It is so simple and powerful that many of our enterprise clients have also adopted it internally. Project/sprint planning is done in Jira, which helps us gauge project burndown and overall progress.

Our continuous integration system (CI) is the most automated tool in our process. When a developer commits code, the CI downloads the newest code, builds it, runs the auto-mated tests, and releases it to our QA team (and the client, if appropriate). This entire process can take under a minute, but the same tasks could take a developer half an hour.

Is prototyping part of your development process? If so, which tools do you prefer for your apps?

Absolutely. We try to get usable software into our client’s hands as quickly and as often as possible. Prototyping is often the fastest way to do this, via static prototypes or even stubbed code. Before development even begins, our UX team uses InVision to turn visual mockups into clickable prototypes. These prototypes run on the phone just like real apps, which allows us to get critical feedback very early in the process. We highly recommend using InVision when possible.

The official University of Virginia app for Android
The official University of Virginia app for Android

Clients often want their apps to support in-app purchases and ads. Do you prefer to build a business model around the project before the development even begins? What is your monetization platform of choice?

There are a several monetization models available on mobile, from: free, ad-supported, in-app purchases, and paid download. The first goal of any application is to get the user to download the app, and we have found that a price-tag of even $0.99 can be a deter-rent for apps in saturated markets or lower-income demographics. In these situations, our clients should consider alternate monetization policies. If the basic functionality can be provided at a low cost, then it might be a good idea to consider a “freemium” model, where the app is free to download but premium features must be purchased (e.g. Evernote). Ad-based models (Facebook, Flixter) can also work, and companies are getting very creative with “native” ads that look like real content. The freemium-ad hybrid model is also popular, which is where a user can pay to remove the ads. However, the paid-download model, like the Dark Sky realtime weather app, can succeed if the app provides functionality that is otherwise unavailable.

Compare the development tools that were at hand when WillowTree started out 8 years ago to the current ones.

When WillowTree first started out 8 years ago, mobile was a very small (but rapidly-growing) industry. The tools we used were either provided by Apple/Google (the xCode IDE) or ported from other tools (Eclipse for Android). There was no third-party ecosystem of tools to modify for our needs.

Now, we use Android Studio, which is an extension of IntelliJ specifically for Android development. xCode for iOS is more robust (and hardly crashes), and both tools are a core part of our Continuous Integration (CI) workflow, which took years to fine-tune. It allows us to automatically (and safely) ship tested code to clients and to the App Stores. Our build distribution tools, TestFlight and HockeyApp, now allow us to see which versions of the app the client has installed/tested. These automated workflows take the burden off developers and allow them to focus on writing quality code.

Categories
Tools

API Management tools: How to find the one for you

Launching an API is hard. You need to make sure your service is reliable, secure and well-documented. This is where API Management tools come into play. They provide the means to expose your API to external developers in an easy and affordable manner. One of the best definitions of API management is the one introduced by APIacademy:

But first, let us know which are YOUR favourite API management tools. Take the Developer Economics Survey and you may win amazing prizes and gear.

api-management

“Creating a centralized API architecture that makes the process of composing, securing and managing high-performance interfaces significantly simpler and more consistent.”

Features of an API Management service

API management services have a multitude of features. Their main focus is to make designing, deploying and managing an API easier, as well as to ensure that it is safe, secure and functional. Some of these tools facilitate integrations, transformations or API orchestrations. Ideally, an API management service should at least cover most of the below basics:

  1. Documentation – Sounds boring, right? Still, one of the most common problems of developers is figuring out how an API works. Development time is too precious to waste in trial and error of an undocumented API. An API management service has to provide an easy way to read the documentation and enable developers to “try before they buy”. In some cases it is even possible to provide interactive documentation. Simplicity and usability are the keys!
  2. Analytics and Statistics – It is critical to understand how people use your API and get insights for your business.
  3. Deployment – Should be flexible and support public or private clouds, on-premises implementations, or combinations.
  4. Developer engagement – Engaging with your API consumers, developer or partners is important. Getting an easily accessible developer portal will significantly facilitate onboarding.
  5. Sandbox environment – This feature will increase both the value of an API and its adoption rate. What better than being able to develop and test your code.
  6. Traffic management and caching abilities.
  7. Security – APIs carry sensitive data, so it is important to protect the exposed information. The service has to at least provide identity and access management for users and developers.
  8. Monetization – Provide the capability to monetize your API.
  9. Availability – Should be available, scalable and redundant. An API environment can become demanding and the service should be able to deal with any kind of errors, problems or temporary traffic spikes.
  10. Support of Legacy systems.

To Proxy or not to Proxy?

The vendors in the API management space provide a number of solutions across the above main categories but that does not mean they support everything. They are implementing their solution in three different ways: Proxies, Agents or Hybrid.

  1. API service providers that use the concept of a Proxy. Their solution “sits” between the customer and their users and the traffic goes through them. Proxies provide caching capabilities and protection of customer’s back-end infrastructure from traffic spikes. The main criticism they receive is that they increase the cost and bring up privacy and latency issues. Apigee, Mashape and Mashery are examples of such implementations.
  2. API service providers that use the concept of agents. Agents are plugins that integrate with your server. They do not get in the way of the API calls like proxies. As a result they do not introduce network latencies or 3rd-party dependencies. On the other side, features like caching are not easy to implement. 3scale is an example of such implementation.
  3. API service providers that use a hybrid approach. This means you may get an agent and a proxy. For example you may want to use a proxy for the caching and the agent for authentication. Companies like Apigee or 3scale we talked before are also moving to hybrid solutions.

13 API management tools

Deciding on an API Management Tool, you are faced with lots of choices. Available solutions may focus in one or two or cover many of the features discussed above and vary greatly in price. There are tools that were acquired by bigger vendors like Intel or CA or Microsoft. Open source tools are also available. Last but not least, some tools are heavy enterprise focused and other much less so.

Name Type License Stackoverflow questions Market segment Strong Points
3scale Agent, Proxy Commercial 15 Startups to Enterprises Wide range of tools
ApiAxle Proxy GPL 9 SMBs to Enterprises
Apigee Proxy Commercial 598 SMBs to Enterprises Powerful Analytics
Axway Proxy Commercial 9 SMBs to Enterprises
CA Layer7 Proxy Commercial 35 Enterprises Advanced support for mobile applications
IBM API Management Agent, Proxy Commercial 17 Enterprises Large Scale, User friendly
Mashape Proxy Commercial 106 Startups to Enterprises Monetization, discoverabilty
Mashery Agent, Proxy Commercial 57 SMBs to Enterprises API strategy services
Microsoft’s Azure API Management Agent, Proxy Commercial 262 Startups to Enterprises
MuleSoft Proxy Commercial 134 Enterprises Based on proven open source technology, programmableweb
Oracle SOA Proxy Commercial 213 Enterprises Large scale, SOA
Akana (formely SOA Software) Proxy Commercial 3 Enterprises
WSO2 Agent, Proxy Apache 4421 Startups to Enterprises Open source

3scale

3Scale is very active on the API management space with a wide range of customers, ranging from startups to enterprises. They provide a hybrid solution to help you deploy, manage, distribute and monitor your API. They offer an on premises API management solution along with cloud based API administration, analytics, reports, developer and partner portal.
More about 3Scale: http://www.3scale.net/api-management/

Mashape

Mashape does not offer an API Management service per se. They provide important features that are part of such services though. You may test an API, generate code, and get a developer portal and user management. Most importantly they provide out-of-the-box monetization, a developer community and discoverability through their API marketplace.
More about Mashape: https://www.mashape.com/

Microsoft’s Azure API Management

Microsoft’s Azure API Management became available to the public rather recently. You can provide and manage an API, get developer portals, documentation, security management, performance management, statistics and analytics. They have on-premises and cloud versions (not limited to the Azure cloud).
More about Azure API Management: http://azure.microsoft.com/en-us/services/api-management/

Apigee

Apigee provides a range of services, from free API tools for developers to large API management solutions for enterprises. Their solution can be deployed in the cloud or on-premises. They offer API analytics, developer portal, transformations, traffic and performance management. Apigee seems to provide the richest API analytics platform compared to other companies. In mid-2014, they launched the new version of their big data predictive analytics platform.
More about Apigee: http://apigee.com/

Mashery

Mashery is an Intel company since 2013. They provide an all-around API management solution that supports SaaS and on-premises implementations as well as a few hybrid oriented ones. Their services cover from API technology and infrastructure to business strategy.
More about Mashery: http://www.mashery.com/api-management

CA Layer7

Layer7’s API Management is heavily enterprise directed. They offer on-premises and cloud deployment solutions. Their services range from integration, security management, performance management, mobile API gateways, mobile optimization and developer portals. CA’s support for mobile applications is considered to be more feature reached compared to other solutions.
More about CA: http://www.ca.com/

IBM API Management

IBM’s solution comes either as on-premise or cloud hosted. It covers a lot of the API management needs of a large company and it is considered a much user-friendly platform.
More about IBM API Management: https://apim.ibmcloud.com

Oracle SOA

Oracle provides an API Management solution that consists of its API gateway and SOA suite. The API gateway is used for securing and managing APIs and as a first line of defense in SOA environments.
More about Oracle SOA: http://www.oracle.com/us/products/middleware/soa/api-management/overview/index.html

MuleSoft

MuleSoft’s solutions is based on open source technology. They offer easy API design, advanced integration and testing features. It is widely used and they also work a lot with developer communities.
More about Mulesoft: http://www.mulesoft.com/

Akana (formely SOA Software)

They provide a unified Enterprise level API management and SOA Governance solution. It can be implemented on-premises or in the cloud. They offer a horizontal solution from design and building an API to policies, security and lifecycle management.
More about SOA Software: https://www.soa.com/solution/api-management

Axway

They offer an API Gateway that provides everything you need to develop, integrate and manage APIs. They provide security management and of course an API Portal for developers and partners.
More about Axway: http://www.axway.com/en/enterprise-solutions/api-management

WSO2

WSO2 is considered the most complete open source solution today. It covers API integration, management, identity and mobile. It supports public, private clouds, and hybrid implementations. WSO2 follows an open development process, where customers can provide input.
More about WSO2: http://wso2.com/

ApiAxle

It is an open source API management and analytics solution. It is a proxy that sits in front of your API and manages caching, security, performance and traffic. As an open source project, you may contribute to its code base.
More about ApiAxle: http://www.exiconglobal.com/apiaxle/

Epilogue

Not all companies launch API programs and not all API programs have the same goals. Some APIs are used as a revenue model or part of a product or service, others are free. Certain APIs are used to provide access and information to an ecosystem of companies. As the requirements vary, the tools diversify. So choose your API strategy and pickup the right tool.

 

Which are your favourite tools? Let us know and shape the future of developer economics. Take the survey.