Saturday, June 18, 2011

Integrated Development Environment (IDE) for APIs

I recently moved my IDE off my desktop and onto the web. I’m test driving two separate web-based integrated development environments (IDE):

  • Akshell - I like environment, its smooth and has Github integration. But its primarily a JavaScript IDE. I met the developers and like where they are going with it.

  • ShiftEdit - This is the one I’m using the most, because I work 70% of the time in PHP. I like the FTP access, but only has SVN for its repositoring integration.


As I was working with the Dropbox API, Posterous API, and Tumblr API today, and was thinking how nice it would be to have an IDE dedicated to APIs.

There are several API explorers popping up out there, that let you play with one or multiple APIs and generate requests and display responses. This is a start.

I would like a full-blown IDE that I can add RESTful APIs to my libraries and would have all the capabilities of an explorer, but also have access to client libraries, code samples, and other features of an IDE for the APIs I use the most.

I could integrate both my public and private Github repositories, and I could leverage the social coding available in the Github community.

Switching between APIs can be a bitch, remembering what I did last time I worked with an API, where the code is, the syntax, and more.  I’m also spending a lot of time using multiple APIs, in a single script. Like pulling bookmarks from Instapaper API, generating a PDF with PDF Crowd, then sending to Mimeo to have printed. That is 3 separate API calls.

I see a lot of potential for an IDE that is dedicated to the API space, an IDE that helps us developers efficiently integrate with the APIs we use most...as well as discover new APIs.


Enhanced by Zemanta

View a PDF in the Browser using JavaScript



I was sitting in on a session at the O’Reilly Velocity Conference today, by Chris Blizzard of the Mozilla Foundation. Chris talked covered a wide range of topics in his 20 minutes, but one project really caught my attention.

It is a PDF Reader in JavaScript. The PDF reader(aka pdf.js), is a technology prototype to explore whether the HTML5 platform is complete enough to faithfully and efficiently render the ISO implementation of the Portable Document Format (PDF).

Viewing PDF in the browser has always been a pain in the ass for developers, and generally a bad experience for the user. Firefox has been working on this for a while, out in the open on Github, but only recently started talking about publicly.

The project is not complete, they are still working on some features like Type1 fonts, gradients, etc. Along the way, they have had to add some new interfaces to the HTML5 canvas element, and replicate some difficult features of the PDF spec in JavaScript.

Mozilla's goal is to be using pdf.js to render PDFs "natively", within Firefox, enabling the browser to view a majority of the PDF's found on the web today. Initially pdf.js will be delivered as a Firefox extension, and eventually baking in, and shipping with Firefox.

Mozilla is open-sourcing pdf.js, and releasing under a very liberal 3-clause BSD license. You can download and get involved over at Github.


Enhanced by Zemanta

Are QR Codes Relevant Anymore?

A Quick Response (QR) code is a two-dimensional code that is readable by barcode readers as well as camera phones.

QR Codes have been around since 1994, and every couple years seem to get heralded as the next big thing.

QR Codes can be used to link the offline world, with online information, with single scan or snap of a picture. QR codes can contain links that take users to a web page. If a user sees a barcode on a store-front window, or on a flyer on telephone pole, they can can snap a picture using their phone and be routed to a web page.

Sounds pretty cool eh?

It does seem like it can be used for an infinite number of things. But QR codes seem a little irrelevevant in a time of image recognition and technology like Google Googles.

Google Goggles is an image recognition application created by Google, which is used for searches based on images captured with your camera phone or handheld device.

You can take a picture of a bottle of wine and it will tell you what kind of wine it is, and search for it. You can take a picture of a famous landmark and it will recognize it, and conduct a search for you.

So with image recognition software and applications like Google Googles, are those black and white QR codes even still relevant?

I saw an advertisement for a band the other day, the poster had a little QR code in the corner. I took a picture of the CD image on the poster, and Google Googles named the band, did a search and I was at the site.

So if I can get there with taking pictures of every day objects, why do I need QR codes? Seems like something brands should consider.

Printing Books, Brochures and Posters from Dropbox

Dropbox is a dead simple, web-based file hosting service, that uses cloud computing to enable users to store and share files with others across the Internet using file synchronization.

Dropbox is a perfect platform for printing from. You can store all your PDF print files on Dropbox, and print with Mimeo Connect.

So I threw together a couple of PHP script to show how to print a couple of common documents from Dropbox, and have delivered to your business the next day.

These samples are meant to show how to integrate commercial printing using Dropbox, into any web or mobile applicaiton.

All samples contain code samples you can download on Github, or the Mimeo Connect code library.