In the Loop: The 365 Project – Canvas Prints Created with Flickr and Node.js

Every two weeks we spread the word of Node.js and the cool and incredible things it can do. We do that by profiling creative, interesting and fun uses of Node.js in various products and projects. We call it “In the Loop.”

Remy Sharp is the founder and curator of Full Frontal, the UK-based JavaScript conference. He also ran jQuery for Designers, co-authored Introducing HTML5 (adding all the JavaScripty bits) and is one of the curators of HTML5Doctor.com. Whilst he’s not writing articles or running and speaking at conferences, he runs his own development and training company in Brighton called Left Logic. And he built these too: jsbin.com, html5demos.com, remote-tilt.com, responsivepx.com, nodemon, inliner, mit-license.org, snapbird.org and jsconsole.com!

Any of these accomplishments are impressive, but Remy came to our attention when we were poring over our Twitter feed and saw one of his tweets:

In the final process of ordering a canvas print of 3 years of 365 photos. Used Node.js to generate the image dynamically from flickr.

Being the Node.js fiends that we are, we couldn’t help but be intrigued, and so we reached out to him.

You had us at “Used Node.js to generate the image dynamically from flickr.” What were you looking to accomplish?

Remy Sharp: I started a “365 project” back in 2009 which involved taking one picture each day. Nothing impressive, more of a visual diary. But the end game was to produce a canvas print of the 365 project.

The problem was the logistics of laying out the images – and in ignoring this problem, I ended up completing a full 3 years worth of photos. So I turned to JavaScript to automate the creation of the canvas image to be printed.

365 image 1

Why did you go with Node.js for this project?

Remy Sharp:Initially I had written code that would go off to Flickr and load all the images under a specific photo set. Then the images would be drawn onto a canvas element with their size and position calculated. However, because the images were coming from Flickr’s domain, it would mean I couldn’t export the canvas to a png (due to origin rules).

So I simply moved the JavaScript to the server side, included the Canvas node module and converted the regular images to be requested using the Request module. And now I was able to export the canvas to a png reading for printing.

Any particular challenges or advantages to using Node.js?

Remy Sharp:The big advantage for me was working around the origin rules that the browser was applying because Flickr weren’t adding CORS headers to their images. It was pretty exciting being able to so simply port my browser based code to the server largely unchanged.

365 image 2

Do you have any other cool ideas or plans for Node.js?

Remy Sharp: Lots! JS Bin is now running on Node.js to allow for techniques I’m calling Code Casting and Remote Rendering. With Code Casting you code on your machine, and viewers can watch the code and output being generated in real-time.  Remote Rendering lets you code in JS Bin on one machine, and with the same URL on any number of remote devices – mobile, tv, etc – update the output in real-time.

For obvious reasons, I’m very interested in the real-time space and using Node.js – but also I’ve found myself creating utilities using Node.js. For example, I ported my snapbird.org (a Twitter timeline search engine) to the command line using node:

https://github.com/remy/twitterlib (though I’ve yet to add any docs! – it’s simple npm install twitterlib to add a “tweets” CLI).

With Left Logic, you specialize in web development. What do you think the future holds for Node.js and web development? is it something Left Logic will be utilizing more?

Remy Sharp: The last 12 months has included a number of clients that used node.js for our solutions – and as time goes on, I can see us using node more and more for client solutions.

Left Logic is more of a JavaScript house than a pure web dev house, so using node.js is a simple and obvious progression for our business. And certainly we’re looking to work with more clients to help them with their solutions – so do get in touch (through our Left Logic Contact Page)!

Thanks for sharing your work with us, and best of luck in future projects!

You can connect with Remy via Github as well as via his contact page.

If you have a cool Node.js project or product you think we should profile, reach out to us at callback@strongloop.com and we’d be happy to get you In the Loop.

What’s next?

Developing a Mobile Backend Using StrongNode – Part 3

Overview

In part 1 and 2 of this blog series we discussed the technologies that we will be using to create an SMS aware mobile application with a node.js backend: StrongNodeMongoDBTitanium, and Twilio.  We also created our first StrongNode application called mobilebackend and deployed the application to our local running slc server.  We signed up for a MongoLab account, created our backend database, and created some REST APIs to communicate with our database.  Finally, we signed up for a Twilio account and configured our SMS phone number to forward incoming messages to the REST API that we created.

In this part of the blog series, we will create a mobile application for both the iOS and Android operating systems that will display all incoming SMS message to our twilio phone number on our mobile device.  If you recall from the first post in these series, the Titanium SDK is a platform for developing cross platform mobile applications using only JavaScript that is written and maintained by Appcelerator. The Titanium SDK has bindings to interact with the native UI components of the mobile device platform of choice which allows for a native experience for the user of the mobile application.

Downloading and Installing Titanium Studio

Titanium Studio is an IDE provided by Appcelerator to help developers create mobile applications quickly with features such as project management, debugging, code completion, and all of the other niceties that one would expect from a modern Integrated Development Environment.  We will be taking advantage of this IDE for the remainder of the blog post.  In order to download the latest version of the IDE, point your browser to the appcelerator website and click on Download Titanium.

After you click on Download Titanium, you will be prompted to create an account for the Appcelerator Platform.  Having an account will allow you to post questions and answers on the developer site and well as many other benefits.

After you have completed the sign up form, you will be sent an email with a validation link that you will need to click.  Once you have clicked the link, you will be presented with a page where you can finally download Titanium Studio. Select the appropriate binary distribution for your platform and begin the download process.

Once the download is complete, install the software using the instructions for your particular operating system.  I am using OSX so I simply had to mount the .dmg disk image and drag Titanium Studio to my applications folder.

 

When you run Titanium Studio for the first time, you may be prompted to install a Java runtime if you don’t already have one installed.  The reason for this is because Titanium Studio is based upon the popular Eclipse IDE which is written using the Java programming language.  In order for the IDE to run, we will need to provide a JRE to run the Java bytecode.

When Titanium Studio starts up, you will be prompted to provide a directory for your workspace.  The workspace is a directory on your local machine where all of your source code for the mobile application will reside.

Once you have selected the location for your workspace, you will then be prompted to sign in the Appcelerator Platform with the username and password that we created earlier in the blog post.

After you have successfully authenticated with your credentials, Titanium Studio will load for the first time.  Given that this is the first time that you have ran Titanium Studio, the software may prompt you to update to the latest version of the SDK.  At the time of this writing, the latest version is 3.1.2 GA.  If prompted to update, go ahead and follow the instructions to update your version of the SDK to the latest.

Installing XCode and the Android SDK

In order to build, run and deploy iOS and Android applications, the developer must have the appropriate SDK(s) provided by Apple and Google on their local operating system.  By default, Titanium Studio does not ship with these SDKs so the developer needs to install them before continuing with the remainder of this blog post.  Installing XCode and the Android SDK has been widely written about and instead of covering the instructions in this post I will refer you to the official Appcelerator documentation on how to install these for your platform.

Official Instructions for installing the Android SDK

Official Instructions for installing the iOS SDK

Creating our Project

Now that we have Titanium Studio downloaded and installed, we are ready to create our mobile project.  On the left of side of the IDE, you will see a button for creating a new project.  After clicking that button, the new project wizard will be presented.  On the first step of the projection creation wizard, select to create a mobile project as depicted in the following image:

After clicking on the Next button, select to create a single window based application and click the Next button

.

On the next screen, you will need to provide some information about the application you will be creating:

wizard3

Project Name: A name the identifies your project and will also be used as the application name on the mobile device.  For this project, let’s use the name of StrongLoop Mobile

App ID: A unique identifier for your application.  If you plan on deploying your application to the App Store, you will need to ensure that your App ID matches the official certificates that you generate for the platform SDK.  Since we are not deploying this application to application store, we can use any ID.  I will be using com.stronglong for this example.

Company/Personal URL: The URL for your company that you would like to be included in the manifest file of the mobile application.  For this blog post, you can simply use the URL that you deployed your StrongNode mobile backend to.

Titanium SDK Version: I have selected to use the newest SDK available at the time of this writing, 3.1.2GA.

Deployment Targets: Select all of the platform that you would like your application to be built for.  I will be selecting the iOS platforms but you are welcome to select any platform(s) that you have the SDK available for.

Editing the Source Code

The first thing we need to do before editing our source code is to ensure that our project and SDK is correctly installed and configured.  This can be verified by running the project that we created while targeting the iPhone Simulator.  To run your project on the iPhone Simulator, select Run -> Run As -> iPhone Simulator.  If you have everything correctly configured, you should see the following screen.

At this point, we want to replace the Welcome to Titanium! message with all of the incoming SMS messages that we receive to our Twilio number.  This file is located under the Resources -> UI -> common directory and is named FirstView.js.  Go ahead and open that file and it should look like the following:

firstView

Replace the contents of FirstView.js with the following code, ensuring to replace the URL of the REST API with the correct URL for where you deployed your StrongLoop mobile backend application.

The above code makes a request to your REST API that you created in a previous post  and formats the resulting message in HTML and then displays them on the mobile device.

You will also notice that I when I declare the function, I use the setInterval syntax.  If you are not familiar with this syntax, it simply defines the function and then calls that function given the specified amount of time.  This allows us to refresh the mobile application with new incoming messages every few seconds.

Give it a try!  Run your application and then send an SMS message to your Twilio number.  You should see the incoming message as well as the city and state that you are sending the message from.

Conclusion

This ends the blog series on how to develop a mobile backend using StrongNode.  In this series we performed a lot of steps that allowed us to quickly assemble a full stack application using StrongNode on the backend with a MongoDB database, Twilio as a connecting bridge for SMS messages, and a mobile application that brought all of the pieces together.

And best of all — we used JavaScript for the entire application!  We were able to use the same language on the backend, datastore, and front end mobile device.  As you continue to explore using StrongNode, you will quickly realize the benefits of choosing this platform that will allow you easily manage complex code bases across different devices and platforms with a single programming language.

What’s next?

Node.js and Mobile News Round-up – September 24, 2013

Welcome to our latest summary of the week in Node.js and Mobile news covering September 17 through September 23rd. Every week this time we will look at some of the Node.js-related news, tutorials and commentaries we’ve seen online.

How StrongLoop Plans to Take Node.js Everywhere — Including the Enterprise

Sam Charrington from VentureBeat looks at the opportunities and risks of StrongLoop’s mBaas offering.

Node.js Goes Mobile: StrongLoop Launches Open Source mBaaS

Zef Hemel from InfoQ looks at the launch of LoopBack.

AppDynamics Acquires Node.js Monitoring Solution Nodetime

Jyoti Bansia announces the growth of the AppDynamics family.

What is the MEAN Stack?

Tamas Piros compares MEAN and LAMP stacks and tells you why you would want to use the MEAN stack.

A Taste of FruitJS

Andrew Hushbeck introduces a new Node.js utility for writing and compiling technical documentation.

Node.js: a Jumpstart for Devs

Jeremy Osborne gives some code suggestions and demonstrations.

Getting Physical: Networked Hardware with Node.js

Ted Hayes discusses WiFi, XBee and their associated network topologies, and demos a networked pong game controlled with a physical joystick using Node.js.

Easy API Scaffolding with Simple-API and Node.js

Joseph Wegner teaches you how to write an API for a ToDo list in less than 300 lines of code.

Aronis Mariano takes three minutes to tell you about Node.js, “probably the most underrated platform right now.”

Aronis Mariano takes three minutes to tell you about Node.js, “probably the most underrated platform right now.”

Fancy Node.js-based Blogging App Ghost Goes Live to Backers

Lee Hutchinson goes hands-on with the app that aims to leave “old guard” PHP-based blogs in the past.

What’s next?

In the Loop: Stackato, a Platform-as-a-Service That You Can Deploy and Manage Yourself

Every week or two we spread the word of Node.js and the incredible things it can do by profiling creative, interesting and fun uses of Node.js in various products and projects. We call it “In the Loop.”

This time we’re chatting with the Phil Whelan about of Stackato, the application platform for creating a private, secure, flexible Platform-as-a-Service (PaaS) using any language on any stack on any cloud. Stackato is comprised of many components written in many languages, including Node.js, Ruby, Go, Python, Perl and Tcl components.

Phil Whelan is a Developer Evangelist for Stackato at ActiveState.

Can you give us the rundown on Stackato? What is it and how does it work?

Phil Whelan: Some developers are familiar with Heroku or EngineYard, which are Platform-as-a-Service, or “PaaS” for short. Stackato is Platform-as-a-Service that you can deploy and manage yourself. You can run it on your laptop or at scale in production. Developers just push their code to this platform and Stackato takes care of installing dependencies, managing the framework, provisioning databases, message queues or caching layers. Your application and databases are hosted within the Stackato cluster, and scaling up an application is one-click or an API call.

Developers (whether on Windows, Linux or Mac) can run Stackato on their laptops during development and be sure that their code will deploy to QA and production systems without modification. They can even test scaling during development!

stackato image 1

What inspired development of this product?

Phil Whelan: We have supported dynamic programming languages, such as Perl, Python and Tcl for many years. We have also been very focused on open-source for enterprise. This is similar to what StrongLoop is doing with Node.js. We have built enterprise versions of Perl, Python and Tcl and we are proud to say that 97% of Fortune 1000 companies use ActiveState products.

Several years ago, we had been looking at better ways to deploy many of the programming languages we support and we were building a PaaS solution when VMware released the Cloud Foundry open-source PaaS project. We knew this project would get wide adoption and we knew we could make an enterprise-ready version and be a catalyst for wider adoption of Cloud Foundry within large organizations. Adoption by large organizations is key to the success of any PaaS solution.

Over the past few years we have succeeded in bringing many large enterprise customers into the Cloud Foundry ecosystem via Stackato. We will remain compatible with the Cloud Foundry open-source project, so that our customers retain the option for portability throughout the Cloud Foundry ecosystem.

Stackato allows you to create using any language on any stack on any cloud. How did you manage to build this level of diversity?

Phil Whelan:The original foundation for multiple language and framework support in Stackato came from the Cloud Foundry project. ActiveState added Perl and Python to Stackato and contributed the Python support back to the Cloud Foundry project.

We have since done a great deal of work on all areas of language and framework support. An important language for enterprise is obviously Java, but Node.js is something enterprises are definitely interested in. To date, many large organizations do not support languages such as Node.js because they do not have the operational resources to support additional languages outside of their core expertise. We are pleased to see Stackato give developers this flexibility without burdening operations teams.

Moving forward we are seeing wider adoption of Heroku’s buildpacks. This a nice way to get any language or framework installed at deployment time into the PaaS. For instance, I can now deploy Racket apps https://github.com/activekjw/stackato-racket-example, which is not natively supported by Stackato, by using a buildpack. Buildpacks are also a great way to deploy a Node.js app using StrongLoop’s distribution, with near zero effort.

stackato image 2

Node.js is one of the languages that you have made work with Stackato. At what point did you determine Node.js would make the cut?

Phil Whelan: Including Node.js was a no-brainer and was part of the original Cloud Foundry implementation. It is very popular and does certain things very well. Regardless of its current popularity, the *rate* at which it is gaining traction, means it would be foolish to ignore it.

In fact, Node.js is a core part of Stackato itself. The Router, which sends HTTP requests to the appropriate web application and load-balances across multiple web application instances, is written in Node.js.

The original Cloud Foundry router was written in Ruby, which utilized an additional Nginx process. We found Ruby to be the wrong language choice for such a component. Node.js is great for writing a HTTP proxy. There are a lot of cool features we want to add to this component of Stackato and Node.js gives us the ability to do this.

stackato image 3

Were there any challenges bringing Node.js into the fold?

Phil Whelan: Since the router was a critical part of Stackato and we had no other moving parts within Stackato that were built with Node.js, we obviously had consider it carefully. Was it reliable? Would it still be supported in X years? Could it perform well under high load?

Jamie Paton, who oversaw all development in this area, pointed out that big brand names such as LinkedIn, Ebay and Walmart were already using it in production, even for their full stack. There were even PaaS solutions out there that were being built purely in Node.js. There is a great infographic that shows the popularity of Node.js infographic that shows the popularity of Node.js

Aside from the initial obstacle of proving that Node.js was something we could rely on, the integration of Node.js was a pain free process. The tooling and binaries make installing and using Node.js very simple. There is an active module ecosystem at http://modulecounts.com/, which means that most components are already available. Therefore, you find yourself re-using code instead of reinventing the wheel.

We were quickly able to prototype a pure Node.js router and we were pleased to see it perform 10x better than the legacy-router, which was a combination of Nginx and Ruby. Now we have just one process, instead of two.

With Node.js we were also able to provide WebSocket and SPDY support before any other Cloud Foundry based PaaS. We have also recently added some new features to the router. This includes custom SSL certificates without downtime, statistics and sticky session support. This would have been much more difficult to do in a compiled router like Nginx, Golang or HAProxy.

Technically, one of the more challenging aspects has been overcoming system limits and tuning Node.js for maximum performance. This includes use of the cluster module to allow the router to work across multiple processes. We have also made kernel tweaks and tuned TCP parameters similar to this to squeeze as much performance as possible out of Node.js.

We are looking forward to Node.js 0.12, which promises to deliver even more HTTP processing performance.

Do you have recommendations for anyone considering Node.js for a project? And does Stackato have any future plans involving Node.js?

Phil Whelan: There are many moving parts involved in running a PaaS. Currently, Stackato is built using Ruby, Python, Perl, Go, Node.js and Tcl (there may be others I’ve missed). We are not just supporting polyglot, we are building in a very polyglot way. I think we will see more Stackato components being written in Node.js in the future. We already have a second component, called Harbor, which is a service for provisioning UDP and TCP port for applications.

What we like about Node.js is how easy it is to start playing with it and with PaaS it is very easy to deploy. I have seen customers write just a few lines of Node.js and just push it to Stackato. Within seconds they have a highly scalable proxy running in their private cloud providing support between two legacy systems.

For anyone starting out in Node.js I would recommend taking a look at Mozilla’s “A Node.js Holiday Season.”

What does the future hold for Stackato?

Phil Whelan: The PaaS space is still young and rapidly developing. We are glad to have our foot in the door and be seen by enterprise as the current best option, but things change quickly in new markets. Our team is growing quickly and we see plenty of potential in where things are going. Also, our customers do provide a good basis for our direction. Unfortunately I cannot share our roadmap. What I can say is that we will continue to provide enterprise support for the Cloud Foundry ecosystem and will retain compatibility with Cloud Foundry.

Phil, thanks for chatting with us.

You can check out Stackato’s PaaS via their web page and get started in minutes.

If you have a cool Node.js project or product you think we should profile, reach out to us at callback@strongloop.com and we’d be happy to get you In the Loop.

What’s next?

StrongLoop Closes $8 Million Series A Funding and Announces LoopBack API Server

SAN MATEO, CA, Sep 18, 2013 (Marketwired via COMTEX) — StrongLoop, the company behind Node.js, has closed a $8 million Series A round led by investors Shasta Ventures and Ignition Partners. Along with the funding, StrongLoop announced that Issac Roth has joined as CEO. Roth is a former Red Hat executive and visionary behind Red Hat’s OpenShift Platform-as-a-Service. He joins StrongLoop founders Ben Noordhuis and Bert Belder who are top contributors to Node.js. Jason Pressman of Shasta Ventures and Nick Sturiale from Ignition Partners have joined the StrongLoop board of Directors. The new financing will be used to expand engineering, product and marketing efforts.
Additionally, StrongLoop announced today the general availability of LoopBack(TM), an open source mobile backend-as-a-service (mBaaS) based on Node.js that can be deployed either in the datacenter or in the cloud. LoopBack was developed with the advice of leading web companies such as LinkedIn who built their mobile backends on Node.js.
“Node.js, not Java or Ruby, is the language to use when you want to connect mobile devices to many different types of data sources,” said Kiran Prasad, Sr. Director of Mobile Engineering at LinkedIn. “Mobile developers who already know JavaScript can quickly implement Node. This means the same developer can code the front and backend of the application.”
JavaScript is the most commonly known programming language. Node.js allows JavaScript to be used on the server. Only four years old, Node.js has already been downloaded millions of times in 2013 and is one of the most popular projects on GitHub ahead of jQuery, HTML5 and Ruby on Rails. LoopBack is part of StrongLoop Suite, a complete solution for developing, deploying, scaling and managing Node.js.
“Just like websites in the 90′s didn’t do much until they were connected to data, mobile applications today scratch the surface of what will be possible when they become data rich. The value of the web was unlocked when application servers bridged the browser to enterprise data,” explained CEO Roth. “In the same way, a Mobile API Tier is needed to connect corporate data sources and mobile applications. Node.js is incredibly popular, but what many don’t realize is that Node.js has become the de-facto language of mobile backends — as Java is to the web, Node.js is to mobile.”
“Customers, employees and partners are forcing enterprises to create mobile apps. To make it possible to do real work in the field, applications on tablets and phones need to be data rich — unless you’re a game vendor, Angry Birds just doesn’t help to meet the quarterly number. This demand for mobile backend connectivity creates a huge opportunity for StrongLoop who have collected an amazing talent pool of Node.js experts. Node.js is taking off and StrongLoop is positioned to be a critical vendor,” said Nick Sturiale of Ignition Partners.
For more information, visit strongloop.com, try LoopBack or register for the webinar: “Introducing LoopBack: an Open Source Mobile Backend-as-a-Service based on Node.js.”

About StrongLoop:
StrongLoop is based in San Mateo, CA and employs over 30 developers working on Node.js. The company is backed by Ignition Partners and Shasta Ventures and includes Marten Mickos, CEO of Eucalyptus (previously MySQL) as an advisor. StrongLoop develops StrongLoop Suite, a leading Mobile API Tier along with being the primary code contributor to Node.js. StrongLoop Suite adds to Node.js with an open source private mBaaS, certified modules, an operations console and cluster management capabilities.
StrongLoop Suite is available for download and on major clouds including Amazon, Cloud Foundry, Heroku and Red Hat OpenShift.

For more information, visit http://strongloop.com.