Parse, Heroku, OpenShift and building the mobile web

I recently walked through the steps of setting up Parse, Heroku and OpenShift accounts in order to get familiar with each and learn more about developing in an entirely *aaS environment. It’s my own exercise to see if you can build a device/web application and never touch the command line of a server. I wanted to answer the question “how easy is it to build a mobile app that includes data services on *aaS providers today?”

I chose these 3 because they popped up in my reading for different reasons and had the things I was looking for. Each has their own toolsets, SDKs and specialized features. They all covered the architecture necessary for data services. They also share the features of being free (at some basic level) and completely cloud based. Here is how each advertises itself:

  • Parse: Backend data-store and Mobile SDK
  • Heroku: Cloud application platform
  • OpenShift: Platform as a Service

In this list, one is pretty clearly not like the others. Parse is more like a data-store for your application than anything else. Heroku and OpenShift are more like hosting and are nearly equivalent in features. These providers seem to be able to cover all of the architecture I would imagine needing for an application. So what’s it like to get started?

Parse

Parse starts with a very nice “QuickStart Guide” tutorial and basically gives you a templated project that includes everything you need to save your first record in your account. This is comforting. Seeing your first “save” happen and being able to verify it immediately is a huge win. The Dashboard is also very impressive. I mean – a Data Browser? Wow. Nice touch. I have no idea how this looks or performs with millions of records, but just the presence of it is very nice. Lastly the coup d’etat is the “Export Data” feature. Really? I can get all my data back? Very cool.

Heroku

With Heroku you begin by setting up the Toolbelt. This is a set of command line tools that integrate really nicely with all of the Heroku services. Essentially it’s based off the Git workflow: when you push code it installs it and runs it on the Heroku platform. However it adds other tools such as Foreman which is a way to run your app locally. The “Resources” management of your applications is also very slick. It’s almost too easy. You could quickly setup your account to have everything. Including a database which they advertise as the largest and most reliable Postgres service in the world. The most intriguing part of Heroku in my opinion is that many of the tools they provide are available open-sourced on Github. I do want to elbow them on 1 particular thing: Node.js is not a language. You should change that in your Dev Center docs. It’s kinda silly. But with that said – they cover all of the more popular languages right now and that’s cool.

OpenShift

OpenShift also has a command line tool to facilitate service integration. They also provide a very clean and impressive application templating system. You select the “runtime” you’d prefer and it provides a template project with a lot of commented code to demonstrate integration with the rest of the platform. Very nice touch. One of the more interesting features with OpenShift is it’s Jenkins integration. It appears (I’ve not set this up yet) that you can add a Jenkins app to your account and have any other apps CI with that Jenkins install. This is – as far as I know – the first CI service provided by a *aaS provider. In my opinion what OpenShift has going  over other *aaS providers is the “Do-it-Yourself” cartridge. Essentially they are giving you a RedHat instance, an IP and a Port. Is this better than a command line to a server?

So that’s more or less the advertising for each of these providers and a little bit about the first interactions with each. Now I’m going to mock out my services etc and see which one makes it easy.

Insight and Perspective

There was a flurry of debate on the internet the last few days about a blog post by Jeff Atwood. In it he made the argument that you shouldn’t desire to learn to program because it’s hard. And that we don’t need more mediocre programmers. And that you shouldn’t want to write code at all. Let’s say it didn’t get a positive reaction. 

http://influencehacks.com/why-i-desperately-needed-to-learn-to-code

This is a blog post that seems to be in response to that. I believe the lessons learned listed in this blog post are worth more than the whole debate about learning to program or not. 

I like the list. I like the perspective gained. I wish this was more pervasive.

OpenShift

Created an OpenShift account tonight. The application creation is pretty simple, but the cartridges that are available are pretty limited. And the Ruby apps seem wanting at only version 1.8.7. Don’t understand why that’s the case and why not 1.9.2? It seems to me that with RVM the version should be a choice. But who knows, there is likely an architectural nuance that forces their hand to limit it to 1.8.7.

Regardless it’s a rather clean and simple setup. The rhc client is nice and it’s extremely cool that the project starts with a template (at least the Node.js application I created did). The project template has README files documenting available cartridges and hooks for build/deployment cycles (nice touch).

I’m a big fan of Heroku. I have an account there too. Now if I’d only build applications to host on each of them :)

The Virtual Machine – why just Java?

I’ve mentioned it before and I think it’s worth repeating: Oracle should remove the name “Java” from the Java Virtual Machine. Popularity of other languages besides Java is growing and specifically growing on the JVM. This article points out some poll data showing Groovy, Scala and Clojure use on the JVM.

Seems to me it would be cool to a name like “Polyglot Virtual Machine”.

Changing how CSS works: Hitch

One of the most popular technologies in web development today is CSS. It’s a language that controls the presentation of HTML pages to browsers. It’s also one of the most complicated languages to truly master. CSS has a deceivingly easy syntax and rule construction, but is as close to any imperative/declarative language as can be in its execution.

To further complicate things, web browers (Chrome / Firefox / Opera / Internet Explorer) all treat the rules of CSS differently. Even though there are standards written on what should happen for certain features and constructs, they still each have their own nuances. Seemingly simple things like rounded-corners are handled differently by a few of these browsers.

Now you can reverse that paradigm: Hitch

Right now browser vendors (Google / Microsoft / Mozilla / Apple) control how CSS works in the browser you’re using. There are utilities out there that make writing CSS easier and better, while trying to minimize these vendor differences. For example, Sass is a CSS superset in which you can write CSS with certain syntactical features and Sass will re-compile your Sass into standard CSS and specifically for each vendor’s nuances. It does not however change how CSS works, and relies on the browser’s current functionality for CSS features. There is also LESS – very similar to Sass. (These are both wonderful utilities and you should use them.)

Hitch switches the control of the web page from the vendor to the developer. It provides true functional changes via CSS, not just syntactical extensions. The way Hitch does this is through a JavaScript API that hitches onto the execution of CSS, intercept it, change it and then let it continue. Specifically it’s designed to extend the CSS pseudo elements and pseudo classes by making them more like filters.

An Example

Imagine you need to style the links in your web page according to an information architecture where the nested level of the link’s URL path is important. For example the URL path /2012/05 is important because it represents a month and /2012/05/05 is important because it represents a day. The markup for these is very simple:

<a href="/2012">View 2012</a> 
<a href="/2012/05">View May</a> 
<a href="/2012/05/05">View May 5th</a>

With standard CSS there is no way to apply a style based on the path nesting. But with Hitch there is:

/* links with /-- should be black */ 
a:-links-local(0) { 
    color: #000000; 
} 
/* links with /--/-- should be blue */ 
a:-links-local(1) { 
    color: #336699; 
} 
/* links with /--/--/-- should be gray */ 
a:-links-local(2){ 
    color: #333333; 
}

With the Link Pseudo Class filters you can specify a style for any number of nested paths and even base the style on whether the path is local to your web page or external. The CSS rules are subtly different (but still very standard) while the functionality is extremely new and currently not doable without Hitch.

Not only does Hitch come with a few built-in features like filters, widgets and constants – it is also extensible by you. And this is where it breaks the current paradigm:

Now you can control your CSS functionality and not be bound to a vendor.

Note: Hitch is a rather new project. It has amazing potential and also a few things yet to be built. It’s open sourced and available on Github: https://github.com/bkardell/Hitch/. Fork it. Change how CSS works!

Things I’m working on

I’m listing out a few things that I’m going to spend more effort working on in my free time. Some of this I’ve already started. Most of this is entirely new to me and I’m treating as education.

Parsers

There are tons of parsers out there. And frankly the field is quite big. But honestly I’m pretty humble about my expectations. I created a project called Peggy.js and I hope to get some activity in that library. I’d like to be involved in the many web projects out there that require their own grammar/parser. What I’m learning so far is that nearly everything in software development is some form of parsing (more than one might imagine). And it can be very difficult.

Sentiment Analysis

Sentiment analysis is another field that is rather big and actually becoming quite popular (or trendy I suppose). To be honest, I’m not even sure that the field has a name like that. It’s basically the study of emotion/attitude/opinion in content users submit to web applications. At least that’s my definition. Essentially I’m interested in the Front-End perspective. How do web/mobile applications handle sentiment analysis? Is there a way to do so on the Front-End that will add better user experience? Or is it really only suited in the post-content-submission perspective. I’ve started (I use that term very loosely) 2 projects for this. One in Ruby and one in JavaScript: Sentiment.js and Altimeter. I’m really hoping to capitalize these projects as not only learning experiences, but potentially career altering opportunities.

I have a ton to learn. I’m very interested in these things. Hopefully something will come of it.

Nothing goes as planned

This last week has been great and exhausting. It has reminded me that nothing goes as planned.

When you’re a kid you plan on big things. You believe in big ideas. Some time later you give up on a few of those. Then as age creeps up on you, it starts to remove the gloss on those shiny plans you had.

It’s so obvious, and yet very hard to really accept. Plans are meant to be broken. You just can’t control life. Fate or higher power, call it whatever you want, just understand it’s not you.

Willie wrote once: “We are not in control. And that’s Ok.”

If you let plans slip, and allow it to be Ok, life is much easier to understand. Otherwise you can waste a lot of time being frustrated and confused.

This week a one or two things didn’t go as planned and it caused me a lot of stress and frustration. My patience got really thin a few times. But I can look back to this week and be happy, because while my plans changed my life didn’t.

And that’s Ok.