Food carts have become a key component of our culinary culture here in PDX. We love that we can get phenomenal food all over town without paying for the overhead associated with brick-and-mortar establishments. It also doesn’t hurt that we can then eat wherever we please—on a park bench, at the office, or, here at Janrain, on the rooftop of the Dekum building, which is a magisterial thing on the 12 or so nice days we have in a calendar year.

There are lots of phenomenal food carts, but Nong’s Khao Man Gai is considered by many to be one of a very small handful of the best PDX food carts if not the absolute, undisputed best.

So what does Nong’s serve that makes it so special? Many would assume that Nong’s serves a broad, continuously shifting array of dishes. I mean, if this place is one of the best of Portland’s over 500 carts, then surely they must have earned this reputation through a diversity of offerings, right? That’s what I would have thought. And this is indeed the approach that the vast majority of food carts take, sometimes offering dozens of menu options.

But Nong’s seems to succeed because it offers you shockingly little choice. In the picture below you’ll see the only thing that you can get at Nong’s (excluding beverages, of course):

But far from alienating their potential clientele, Nong’s thrives in a major way. They continuously win culinary awards of all sorts. They’re frequently featured in publications about Portland’s food culture. And, most tellingly, the lunchtime line is almost always exasperatingly long. And when you do make it through the line and bring your chicken and rice back to the office, your response is almost invariably the following: “That was barely a wait at all. I would have waited an hour or more for the fermented bean curd sauce alone.”

The UNIX Philosophy

So what on Earth does this have to do with UNIX? Well, it’s simple: Nong’s and UNIX have the same core philosophy. There are a variety of formulations of the UNIX philosophy, but I’ll do something super hacky and deprecated and consult the UNIX philosophy Wikipedia page and try to distill the philosophy into a few core tenets:

• Small is beautiful
• Make each program do one thing * and one thing well
• Favor simplicity and portability over feature completeness
• Write programs to work together

The antithesis of the UNIX philosophy in computing consists, then, of the following:

• Big is beautiful
• Make programs do a whole variety of things
• Favor comprehensiveness of function over simplicity
• Write programs to work autonomously

Yes, this is an extremely rough expression of the UNIX philosophy, but I do think that it elucidates some crucial points. According to this worldview, complex processes should almost always be broken up into smaller processes in the name of transparency (e.g. teasing out problems and speeding the application of solutions); it’s always better to have a toolbelt with a lot of small tools with clear purposes than to have a toolbelt with one big tool that does everything; and larger systems should be carefully woven out of these smaller pieces.

The UNIX Philosophy in Action at Nong’s

The UNIX philosophy is typically associated with computing—unsurprisingly—but I see no reason why it can’t be applied to organizational theory. Nong’s makes one thing—chicken and rice—and does it extremely well. In this, it is a spiritual devotee of the UNIX philosophy, even if an inadvertent one. Nong’s menu has no aspirations whatsoever to be comprehensive, and they seem to have no plans to change their menu. It might be fair to say that limited ambition is another core component of the UNIX philosophy.

Going down this path has benefited the organization in a variety of ways:

• Efficiency: when the line gets long—as it very often does—doing one thing and doing it well helps Nong’s with queue efficiency in a drastic and immediately apparent way. No one dilly-dallies figuring out what to order, and the cashier doesn’t have to navigate a sophisticated user interface in taking orders.
• Friendlier learning curve: new personnel are quickly brought up to speed. Instead of learning how to cook 50 dishes, they learn how to make one. Now, Nong’s chicken and rice is deceptively complex, and there’s a lot of careful work that goes into it. Nonetheless, less conceptual overhead means quicker turnaround times for new employees.
• Competitive advantage: whereas other carts always face the possibility that another Thai or Indonesian or Lebanese or Ethiopian or whatever cart is going to cut into their profits, Nong’s absolutely owns chicken and rice. If anyone came along and tried to do exactly what they do, they would be seen as a cheap knock-off.

With all of this going for it, is it any surprise that Nong’s succeeds?

Toward a UNIX-Flavored Federation of Processes?

If the UNIX philosophy can work for Nong’s, it can probably benefit all kinds of organizations and processes. Modularity and learning curves and feature completeness are not just concepts for IT departments. They also have a place in any and all discussion of organizational competency and success more broadly.

I long for the day when all of Portland’s food carts adopt the UNIX philosophy and drastically limit their scope. The result would be fewer total menu options but a far higher quotient of out-of-this-world menu options. The food cart ecosystem would be transformed from an assemblage of redundant menu offerings and reinvented wheels into a thriving federation of lean operations. So next you’re at a food cart, talk with the owner and share this vision. Urge them to consider seeking the Nong’s path.

What do you think, Dear Reader? Should modularity trump completeness? Are limited feature sets usually a good thing? Am I crazy for thinking that the UNIX philosophy has real-world relevance?

Last night, the Technology Association of Oregon honored some of those companies who are putting Oregon on the map with their technology and mission. It can’t be easy to choose just four to put a spotlight on, because Portland has an abundance of technology companies who have or are on the verge of success.

For all of us at Janrain, just to be in the company with the likes of Iovation, Puppet Labs, FEI, Digimarc, Vendscreen and the other nominees for Technology Company of the Year is such a compliment to all that we’ve achieved. And to be selected as the Rising Star Technology Company of the Year is a huge and humbling honor that reflects the smart, dedicated people who bring their talent and passion everyday to the important work we’re doing on behalf of our customers.

Congratulations to all the nominees, winners and those who devote themselves to this incredible technology community. Thanks to the Technology Association of Oregon for acknowledging the great work we, and the entire community, are doing.

By the way, the Portland tech community would likely edit that common goal mentioned above to read: bring the very best technology to the world, and put Portland, Oregon’s Silicon Forest on the global map as the premier community for starting and growing world-class technology companies.

What you’ll find below is more of a streamlined presentation of a lot of disparate sources (for example here and here) than a 100% new tutorial, but I hope that it serves to put in easily digestible narrative form a lot of the currently existing information. I’ll be putting together an extremely simple product management tool (basically the most barebones and useful Basecamp clone out there). I will do nothing on the UI level and will interact with the server only via cURL. I’ll save views and fancy aesthetics for another day.

Get a Snap Application Up and Going

Since this tutorial also serves as a rudimentary introduction to Snap for the uninitated, I’ll briefly walk through starting a new Snap application. If you’ve installed Haskell, cabal, and Snap, simply create a new project directory (we’ll call our project projectomatic), navigate to the directory, and initiate a new Snap application:

mkdir projectomatic
cd projectomatic
snap init

Once we’ve done that, if we run ll or ls or whatever, we’ll see that a variety of files and directories have been created. I won’t delve too deeply into that here, so I recommend reading up here if you want to learn more about the anatomy of a Snap application. I could have run snap init barebones to begin with a much more stripped-down application, but I’m going to go for a full installation so that we can more quickly get up to speed on using Snaplets.

Setting up Our Application to Use PostgreSQL simple

Snaplets are somewhat difficult to explain, but I’ll try to encapsulate it briefly. Snaplets are sort of a portal to the outside world from within a Snap application. Snaplets enable you to access state—database transactions being a perfect example of that—in a relatively painless fashion. Setting up our application to use PostgreSQL Simple involves using the very handy PostgreSQL Simple Snaplet. First, install that using cabal (cabal install snaplet-postgresql-simple), then add that to your dependencies in your projectomatic.cabal file, run cabal install, then modify your src/Application.hs file like so:

{-# LANGUAGE FlexibleInstances #-}

import Control.Lens
import Snap (get)
import Snap.Snaplet
import Snap.Snaplet.PostgresqlSimple

data App = App
    { _pg :: Snaplet Postgres }

makeLenses ''App

instance HasPostgres (Handler b App) where
    getPostgresState = with pg get

With the normal snap init install, your application is set up to use a few other Snaplets out of the box. Feel free to leave those in. I will remove them for the sake of brevity in this tutorial. What you see above is that I’ve embedded our Postgres Snaplet within our App data type and then used the makeLenses ''App function to generate an accessor pg that we can use elsewhere. Lastly, I’ll define the instance HasPostgres (Handler b App), which will enable the application to have access to Postgres-related state.

Now that we have our handy pg accessor, we need to go over to our src/Site.hs file and do some additional setup. First, add the PostgreSQL Snaplet to the imports:

import Snap.Snaplet.PostgresqlSimple

Now, we need to add our pg constructor to the core of the application. Let’s modify the definition of the app function to include our Postgres Snaplet:

app :: SnapletInit App App
app = makeSnaplet "app" "My stunningly advanced Snap application." Nothing $ do
    pg <- nestSnaplet "pg" pg pgsInit
    addRoutes routes
    return $ App pg

We’re almost ready. All we have to do now is configure our Postgres connection. When we ran cabal install after adding the snaplet-postgresql-simple module to our dependencies, Snap created a snaplets/postgresql-simple directory on its own (wasn’t that sweet?). In that directory, there’s a file called devel.cfg where we specify our database connection. Here’s what mine will look like (yours will vary, of course!):

host = "localhost"
port = 5432
user = "luc"
pass = ""
db = "projectomatic"

There are other configuration possibilities, but this will be enough to get me up and going. Once this is done, try running cabal install and see if you get any compiler errors. If so, see if you can debug on your own. If not, then let’s move on to the next section.

Our Project Data Type

Haskell is a real stickler for data types, so we now have to start being both explicit and careful about everything we do. Let’s define our Project data type in our src/Site.hs file. We could do it in a separate file if we wanted to, but let’s keep it simple. I’ll be using the Text data type here—as use of strings is widely considered to be deprecated in Haskell)—so I’ll make sure and add Data.Text to my imports:

import qualified Data.Text as T

We’ll keep our data type simple:

data Project = Project
  { title       :: T.Text
  , description :: T.Text
  }

Setting up Postgres to Handle Our Data

Postgres is a traditional columnar database (though with a of sugar on top), so we can’t simply start throwing a bunch of key/value pairs at it and expect it to start storing things. We’ll need to create tables that are ready to do our bidding. Oh, and our database. We should make one of those, too. Let’s start with that. In a *nix environment, chances are strong that you can create a new database from the command line (presuming that you have Postgres installed):

createdb projectomatic

If that doesn’t work, either consult one of many Postgres installation tutorials or cut to the chase and download Postgres.app for real ease of use. If that did work, then let’s write a projectomatic.sql file and place it in our main project directory. Here’s what it will need to look like:

CREATE TABLE projects (
  title TEXT NOT NULL,
  description TEXT NOT NULL,
);

Each project will simply have an integer identifier, a title, a description, and a set of users involved with the project. For sake of simplicity, we’ll set things up so that each user will simply have a username and a set of projects that they’re associated with, and none of the values we’re working with can be NULL.

Let’s open up our database using psql projectomatic in the command line and run our SQL script when we get there:

\i /path/to/application/dir/projectomatic.sql

If we get CREATE TABLE as a response, then we’re probably good to go. It’s a good idea to double check by running \dt and making sure that projects and users tables currently exist and are properly constructed. Once they do, we should be good to go within Postgres itself.

Making Our Data Types Ready for Postgres

Like I said before, dealing with data types in Haskell is tough. While I would never assert that dealing with data types in any programming language is “easy” per se, Haskell really does present a pretty formidable learning curve. Fortunately, it’s not too bad if you’re doing fairly basic things.

Previously, we specified our Project data type, but that’s not yet enough to get them to actually interact with Postgres. Putting data into Postgres would likely work fine at this stage, but taking data out of Postgres and transforming it into something that Haskell can use within the application is going to take some work.

So in our Site.hs file, we need to set up a FromRow instance of both of our main data type. This will require the Control.Applicative module as well as a special submodule of PostgreSQL Simple, namely FromRow. Here’s what needs to be added to our Site.hs file:

import Control.Applicative
import Database.PostgreSQL.Simple.FromRow

instance FromRow Project where
    fromRow = Project <$> field <*> field

The funny <$> and <*> operators come from the Control.Applicative module. The most important thing is that the number of fields that you use when constructing the instances matches the number of fields in the database, or else you’ll get all kinds of nasty compiler errors, just as you will if there’s a type mismatch (as when you try, for example, to put a Haskell integer into a Postgres field that takes only a varchar or text).

Setting up these FromRow instance constructors enables us to take data from Postgres (for example the results of a SELECT * FROM projects-style query) and use it in our pure, pristine Haskell application. One thing we should also do is to define a Show instance for our data type. This is necessary because when we make an HTTP request to see a Project (or a list thereof), we want to specify what that will actually look like in the command line. If we don’t specify a Show instance, that means that we won’t actually see anything, even if we’ve done everything else right. I’ll keep it basic:

instance Show Project where
    show (Project title description) =
      "Project { title: " ++ T.unpack title ++ ", description: " ++ T.unpack description ++ " }\n"

Note that we need to use the T.unpack function, taken from the Data.Text module, to convert text into strings (else we get a compiler error).

Time to Get Back to Our Application

So that was a lot of setup, no doubt about it. Now it’s time to actually convert HTTP requests into PostgreSQL queries and consequently data. I’m going to set up our server to take requests that do the following things:

1. Create a new project
2. Return a list of all projects
3. Delete a project

Basically, we’re running simple CRUD operations on the Project data type.

Let’s start with creating a new project. First, our route:

("/project/new", method POST createNewProject)

Here’s our corresponding function:

createNewProject :: Handler App App ()
createNewProject = do
  title <- getPostParam "title"
  description <- getPostParam "description"
  newProject <- execute "INSERT INTO projects VALUES (?, ?)" (title, description)
  redirect "/"

Let’s unpack this a bit. First, notice that this is embedded in a do block, which often (though certainly not always) means that you’ll be dealing with I/O. The first thing that this function does is extract the title of our new project out of the form data passed to the server with the getPostParam function (the same goes for our description). Now, we’ll use the execute function to actually interact with Postgres. In contrast to the query_ function that we will encounter later, execute is typically used in situations where you don’t expect a return value (as when you write to a table).

The dual ?s that you see are places in our SQL bytestring where we will insert values. Immediately after the bytestring, we specify which values we want inserted (in this case the title and the description that we derived from the URL).

Now, let’s work on using the query_ function instead of execute. This is a bit trickier because it involves getting data back from Postgres that then needs to be processed and handled on the application side (whereas with the execute function we passed already-formed data on to Postgres). We’ll start with setting up a route that displays all projects. The route:

("/projects", method GET getAllProjects)

And the handling function:

getAllProjects :: Handler App App ()
getAllProjects = do
  allProjects <- query_ "SELECT * FROM projects"
  liftIO $ print (allProjects :: [Project])

A few things to notice here. First, we store the results of the query in the allProjects variable. That’s pretty straightforward. What’s more difficult, however, is actually displaying those projects. First, have a look at the print function. What is being printed? The allProjects variable is going to be printed as a list of projects. But we can’t just use print on its own because print produces IO (which is always tricky in Haskell).

This is where the liftIO function comes in handy. This function gives us access to the I/O in which the application is engaging, and in our case it will convert the type IO () into the type Handler App App (). And so print is producing IO which is then brought into the application context. Because we haven’t set up any views or anything fancy for displaying the data, the print function will make the results of our GET request show up in the console.

So now we can create a project and get all projects. Let’s add a route and a function for deleting specific projects. First, let’s set up a route to delete a project based on the project’s title:

("/project", method DELETE deleteProjectByTitle)

In a serious project, you would probably want to delete on the basis of an integer project ID or something of the sort, but we’ll keep it simple. Now, our corresponding function:

deleteProjectByTitle :: Handler App App ()
deleteProjectByTitle = do
  title <- getPostParam "title"
  deleteProject <- execute "DELETE FROM projects WHERE title = ?" (Only title)
  redirect "/"

Notice here that we’re only passing one value into our SQL bytestring, hence our reliance on the Only instance. Also notice that we’re not passing the project title via URL, but rather by way of form data.

So now we have some routes that interact with Postgres and do some really basic things. Let’s put our server to the test.

cURLing Our Way to Victory

As mentioned before, I’ve said nothing about views or HTML rendering or any of the sort. At the moment, our application has zero views. I’ll cover Snap’s default templating system, Heist in a future tutorial. For now, though, we’ll interact with our server the old-fashioned way: via cURL (my favorite tutorial can be found here).

Let’s go through a set of examples involving each of the routes that I set up earlier. First, let’s fire up our server.

cabal install
projectomatic -p 3000

Now, let’s get a list of all of our projects:

curl -X GET http://localhost:3000/projects

At first, this should return an empty list (no surprises there). So let’s create a project. Let’s create a project called “Getting in shape” and give it the description “Daily exercise:”

curl -X POST http://localhost:3000/project/new \
-d 'title=Getting in shape' \
-d 'description=Daily exercise'

Now, when we run a GET request on /projects again, we should get the following in the CLI:

[Project { title: Getting in shape, description: Daily exercise}
]

This means that our server works. *whew*

Now, let’s delete the project that we just added to the database. Remember from above that the URL takes the form /project, while our title is passed in via form data. Our cURL request should look like this:

curl -X DELETE http://localhost:3000/project \
-d 'title=Getting in shape'

If we have more than one project in the database with the title “Get in shape,” then all projects with this title will be deleted. This is yet another reason why working with integer IDs for important data types is much better than working in terms of attributes like this. In a future tutorial, I’ll do a deeper dive into Snap and Postgres that does precisely this.

Just a Basic Intro

Like I said before, this application has no views or rendering, no error handling, no authentication. It’s just an HTTP server talking to Postgres. I’ve also only covered a minimal smattering of what the PostgreSQL Simple Snaplet has on offer. But I hope that it has at least served to show that using Postgres and Haskell in a web development context is not as intimidating as it may seem at first. There are some conceptual leaps (at least for a previously OOP-oriented person like myself), but patience pays off.

How cool is that?

We’re thrilled to be honored with membership into Gartner’s “cool social technology” club (our words, not theirs) along with 140 Proof, Influitive, Woobox and Zuberance. The report’s focus is around the opportunity that exists for digital marketers in leveraging the social web to reach their online goals, and goes on to recommend these cool vendors for organizations to call upon.

Our motivation at Janrain isn’t necessarily to “be cool” but we think it’s pretty darn awesome to work with brands we all like, know and buy from such as Universal Music Group, Fox, Dr Pepper, Samsung, AMC, Guitar Center and Pac12. In our book, it’s our customers that we find pretty cool because they understand exactly what Gartner analyst Julie Hopkins means when she writes:

Janrain simplifies the process of managing multiple online identities to remove the “digital hassle” often associated with the user’s broad social participation.

In other words: our customers know that password fatigue is a real problem and leverage our social login technology to remove the obstacles that stand in the way of allowing their website visitors to quickly log in to their site.

So, while we’re humbled to be called a “cool vendor” and thank Gartner for the recognition, we really want to thank our customers who make us who we are by choosing Janrain in the first place and relying on us to earn their trust everyday.

Disqus

Disqus was looking for a technology partner to help publishers collect and organize valuable user profile information to enhance and develop their registered audience base.  The company joined the Janrain Fusion Partner Program to make it easier for publishers to create personalized and targeted content for visitors based on a user’s declared interests and demographics.

Ro Gupta, vice president of business development for Disqus, believes that this integration is extremely compelling for publishers who want to develop deep relationships with their most engaged audience – those that consume content and participate in discussions. It allows the publisher to verify the user and gather key information about preferences, which in turn gives the user a better, more personalized experience on the publisher site.

Gupta knew Janrain specialized in user management, which Disqus wanted to enrich based on keen publisher interest to capture and verify more user data.  He views this partnership as a great example of two industry leaders working together to tangibly increase the value of online engagement.

For more information on Fusion Partners and the program, check out our partner section.

The advent of social media has emboldened us to foster personas for ourselves online.  But the social media landscape is fragmented.  We tend to use Facebook to interact with friends and family, Twitter to follow influencers and share opinions, LinkedIn as our professional network, and Gmail, Yahoo! or Hotmail to communicate directly with our important contacts.  Combined, more than 2.5 billion of us maintain accounts with these services, and social login solves the registration challenge by making it possible to use those identities to easily sign up and log in on sites across the web.

But which identity providers are the most popular choices?  Each quarter, we seek to answer this question by analyzing social login preferences for online consumers across all websites using Janrain.  Why do these trends matter for digital marketer?  Social login preferences are a leading indicator of consumer trust in the different online identity providers.  If I use my Google account to login and participate on sites across the web, for example, that choice serves as an indication of the trust and affinity felt toward Google’s service.

__________

When it comes to social login, our data shows that people want choice. Facebook currently leads as the most popular identity provider for social login.  During Q1, Facebook did lose ground to Google for the second consecutive quarter, dropping in popularity from 49% during Q4 2012 to 46% in Q1 2013, while Google’s share of social logins ascended from 31% to 34% during the same period.

Despite the moderate decrease in share of social logins during Q4, Facebook still remains the most popular choice for the ninth consecutive quarter.  After reaching an all-time quarterly high during Q3, Twitter’s share also decreased moderately during each of the last two quarters.

LinkedIn enjoys substantial popularity on sites that cater toward business professionals, with as many as 80% of business professionals choosing to log in with their LinkedIn identity on some B2B websites.  A majority of us maintain our professional online identity on LinkedIn. When using this identity to register on B2B sites, consumers can choose to grant the website access to their LinkedIn profile information, including a verified email address, first and last name, company name, job title and industry. The site can then use this information to conveniently pre-populate a sign-up form, which eliminates the need for consumers to fill out the form from scratch or enter lots of redundant details about themselves.

We also have observed disparate preferences across geographic regions.  For example, Hyves contends with Facebook as the most popular social network in the Netherlands, and social login preferences on Dutch websites substantiate that notion.  In Brazil and India, Orkut is a popular identity provider for social login, while in China, Sina Weibo and Renren maintain popularity.  Mixi is a common social login choice in Japan, while VK is preferred in Russia.

As with prior analyses, we have taken a sampling of sites in four industry verticals to measure trends in consumer login preferences.  While the overall story arc is similar, there are disparate preferences within each vertical that merit attention.

Despite its decreased share across all Janrain customer websites, Facebook still leads other social networks and email providers across prominent industry verticals including media, retail, entertainment and gaming, consumer brands, and music-related sites.  Its popularity is especially pronounced on entertainment, gaming, retail and consumer brand websites.

Google is performing well as the second most favored portable identity provider across each of these verticals, but its popularity is most evident on retail and consumer brand sites, which could perhaps be a reflection of the trust that people place in Google as a secure provider of their online identity. With Janrain’s recent launch of Google+ as a sign-in provider, we expect the propensity for consumers to choose a Google identity for social login to increase throughout 2013.

What do these findings mean for your business?  As you work to add a social layer to your site to improve engagement and drive conversions, social login and sharing should be fully integrated.  We hope these findings provide a useful benchmark as you optimize your on-site social media strategy.

For Digital Marketers:

Social login helps solve the challenge of how to collect more accurate data on your users while increasing registration conversion rates at the same time. Social login shortens the registration process to a single click and gives you instant permission-based access to rich demographic, psychographic and social graph data on your users. This social profile data can be leveraged for content personalization or product recommendations and more tailored segmentation and targeting. Social sharing enables your users to broadcast content and activities from your site to their social networks, increasing brand advocacy and creating an effective source of qualified referral traffic back to your site.

For Developers and Technologists:

It can be a big headache to implement the plumbing to each social network API on your own.  These networks use different protocols under the hood, such as OpenID, OAuth, hybrids and proprietary technologies. As a result, coding social login on your own requires a significant investment of time, engineering expertise and ongoing maintenance as the networks change their APIs, often without advanced notice. Your social login and sharing solution should allow you to easily connect to all the social networks by writing once to a single API. By cutting deployment times from weeks or months to a couple days, you can focus on your core competency while trusting that the social and user management tools on your site just work.

Success is determined by our ability to deliver exceptional products and services that delight our customers, and it also requires a high degree of trust. We believe that trust starts with openness and transparency. That’s why, as part of our ongoing commitment to promote transparency with our customers, we have introduced a new site to proactively communicate the status and availability of Janrain’s services – trust.janrain.com.

This site will be the primary resource for Janrain customers seeking to monitor the availability of the Janrain service as well as learn about our infrastructure, security and compliance. The trust.janrain.com site includes:

• Real-time and historical data on system performance
• Incident reports and notification of planned maintenance
• Information about how we safeguard and protect the privacy of your data
• Information on Janrain’s product infrastructure

Trust.janrain.com was inspired by conversations directly with our customers. We know that our customers hold us to a high quality standard, and we strive to provide you with the tools you need to hold us accountable to our commitments.

Please check out the site and bookmark it for future reference. And as always, don’t be shy about dropping us a line to let us know if you have any feedback.

It’s scarcely believable just how powerful and comprehensive these tools have become given the state of JavaScript just a half-decade ago. If I were building any kind of heavily event-driven client-side application with a lot of fancy UI elements and a structured data model–essentially what we now call the “thick client”–I would still opt to build it on top of a big MVC (or MVVM or MOVE or whatever) framework. The thought of building a thick client using the naked DOM API by itself is, to put it mildly, a slightly less than pleasant one.

Another path

Yet in spite of the wonders of contemporary JavaScript, there are times when clearing away the underbrush and getting back to the DOM API–the closest thing to bare metal that you’ll get in JavaScriptLand–is absolutely the only way of doing things.

When the original Janrain development team started making heavy use of JavaScript some years go, this was precisely the conclusion to which they came. For our use case–which involves allowing developers to simply copy and paste a JavaScript widget into their application that then enables social login and/or user registration and data storage–reliance on jQuery or Underscore or anything beyond native JavaScript was simply a non-starter.

Why? Because we have to write JavaScript that plays nicely with anything and everything with which it interacts. We can’t afford namespace or dependency clashes. Organizations that want to use Janrain Engage or Capture need to be able to drop a small snippet of JavaScript into their application (a snippet like the one included below) and to have it work unproblematically and without any additional work on their part…ever. Both the drop-in widget and the JavaScript that gets piped through the widget (more on that in a minute) have to demand nothing from the developers using Janrain. Our entire business model depends on it.

Another core reason: performance. The JavaScript that we compose that ends up in others’ applications has to be blazingly fast, and it has to work on as many devices and for as many use cases as humanly possible. It has to be as close to 100% agnostic toward its end destination as the DOM API allows for.

If we had chosen to use framework-heavy JavaScript, it would have meant two things for us:

1. The good: it would have made our lives a lot less complicated because it’s far easier to find and then hire people to write jQuery or Backbone with most of the guts of JavaScript abstracted away.
2. The bad: it would have made our lives vastly more difficult because we would have to require customers to go back and re-code all of their front-end JavaScript to ensure that it plays nicely with their supposed “drop-in” social login widget.

For customer-facing JS, this path was unacceptable, and so we decided to go all in on all-native JS.

Dependency-free JS example: drop-in widget

While Janrain uses a lot of libraries like Knockout, jQuery, and others in building dashboards and other thick client-style applications, all of the JS that we write for customers is dependency free (although we do offer widgets that depend on jQuery, but only if our customers ask for it). I could give hundreds of code examples here, but I’ll stick with the most stripped-down widget that we offer, simply in the name of offering a taste of the mechanics of low-level JS to the uninitiated.

This widget basically acts as a portal into the DOM for the more feature-rich JavaScript that powers a social login interface. Let’s have a look at what such a widget might look like in its entirety and go from there:

<script type="text/javascript">

  (function() {
    if (typeof window.janrain !== 'object') window.janrain = {};
    if (typeof window.janrain.settings !== 'object') window.janrain.settings = {};

    janrain.settings.tokenUrl = 'http://www.your_site.com';

    function isReady() { janrain.ready = true; };
    if (document.addEventListener) {
        document.addEventListener(DOMContentLoaded, isReady, false);
    } else {
        window.attachEvent('onload', isReady);
    }

    var e = document.createElement('script');
    e.type = 'text/javascript';
    e.id = 'janrainAuthWidget';

    if (document.location.protocol === 'https:') {
        e.src = 'https://rpxnow.com/js/lib/luc/engage.js';
    } else {
        e.src = 'http://widget-cdn.rpxnow.com/js/lib/luc/engage.js';
    }

    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(e, s);
  })();
</script>

 
First off, notice that this is a self-executing snippet of JavaScript. Any time you’re working in JavaScript and you see something of the form

(function() {
    ...do stuff here…
})();

 
you know that you’re dealing with something that isn’t going to need to be called from outside of the function. So this sets up the widget to execute itself as soon as its loaded.

Now, let’s see what’s actually going on in this self-executing function. In the first line, we see

if (typeof window.janrain !== 'object') window.janrain = {};

 
This is essentially a kind of guard to check if there’s already a window.janrain something-or-other floating around in the DOM. If there is, and it isn’t an object, it needs to become one. And so whatever that window.janrain is will immediately be converted into an empty hash (i.e. a JavaScript object). After that, the widget does the same check regarding any window.janrain.settings. In these first two lines, the widget basically ensures that we’re starting from the right place with an object of this form:

{
  window: {
    janrain: {
      settings: {}
    }
  }
}

Working with our empty window object

Now, we can begin populating this somewhat barren object. First, we need to fetch the tokenUrl from the application-specific URL (a URL that we provide you when a new Janrain-powered application is created). This URL is used not by the widget but rather by the JavaScript that will arrive in the application a few milliseconds later.

Next, we define an isReady() function to be used later. This function, when invoked, declares that the document is ready to go, so to speak. It should remind you immediately of the $(document).ready() function from jQuery. What that means in jQuery is that anything that happens inside of .ready( … ) happens as soon as possible and doesn’t wait for the page to load.

In the next line, we’ll see why this is important:

if (document.addEventListener) {
  document.addEventListener(DOMContentLoaded, isReady, false);
} else {
  window.attachEvent('onload', isReady);
}

 
This is here to ensure cross-browser compatibility. It says that if the addEventListener function is invoked, it will take the form either of the addEventListener function understood directly by Chrome, Firefox, Safari, and newer versions of Opera and Internet Explorer, or of the attachEvent function understood by older browsers. And so no matter what the browser, an event listener will be added to the document at large that basically waits until all of the DOM content is loaded (the onReady event for older and DOMContentLoaded for newer browsers) and then declares the janrain object ready (janrain.ready = true).

Piping JavaScript into the DOM from outside

So far, the widget hasn’t really done anything to modify the DOM in any significant way. In the next code block, that all begins to change:

var e = document.createElement('script');
e.type = 'text/javascript';
e.id = 'janrainAuthWidget';

 
Here, the widget is inserting a new <script type='text/javascript' id='janrainAuthWidget'> element. Next, a source for the script is found. In the next block, the widget checks to see if the application in which it’s embedded is currently using HTTPS or HTTP and then acts accordingly:

if (document.location.protocol === 'https:') {
    e.src = 'https://rpxnow.com/js/lib/luc/engage.js';
} else {
    e.src = 'http://widget-cdn.rpxnow.com/js/lib/luc/engage.js';
}

 
Clearly, the URL used as the source of the script is specific to the application that I created in RPX. So now our <script> tag is complete and ready to be inserted into the DOM:

var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(e, s);

 
The first line simply locates the first <script> block in the DOM. The second line ensures that our new <script> is placed before it.

And that’s it. On the basis of this self-executing widget, the DOM will now be populated with an application-specific engage.js file (itself dependency-free, unless the customer wishes otherwise) that will be loaded in an asynchronous, non-blocking fashion, which means that other JavaScript that needs to be loaded won’t compete with it and can load at the same time.

Going dependency-free: not for everyone

This is a pretty basic example that involves only a small handful of functionality available through the DOM API, but I hope that it shows that dependency-free JavaScript really isn’t as scary as you might think.

As I said before, I’m not necessarily arguing for a “return to roots”-style movement in the JavaScript community, in which we all toss aside all the frameworks we’ve been using these past few glorious, framework-enabled years. I do think, though, that dependency-free JavaScript is very much worthy of consideration in a larger variety of cases than you may think.

Our Janrain Engage widgets are textbook use cases for ditching frameworks and getting back in touch with the DOM API, as motley and inelegant as it may sometimes be. We think that developers that want to use Janrain have enough to worry about; there’s no reason to make them worry about delicately tiptoeing around our widgets.

So if you think that you might have a good use case for weaning yourself off of JS dependencies, give it a shot. There may be less to lose than you’ve been brought to think.

You may not recognize the name Automattic, but you’re certainly familiar with the WordPress.com platform, the most popular content management system (CMS) on the web. Automattic manages the enterprise arm, WordPress.com VIP, which powers some of the largest publisher and media sites, including CNN, New York Times, CBS and Forbes.

These media executives have been trying to find a technology solution to personalize their brand experience. The solution had to be easy to integrate, scalable and secure.

Automattic has joined the Janrain Fusion Partner Program to provide VIP sites a technology solution to better understand and engage their audiences. The JUMP integration provides turnkey registration, social profile storage and user insight solutions so WordPress.com VIP customers can acquire more users and provide better, more engaging experiences.

Vice-president of platform services for Automattic, Inc., Paul Maiorana, is looking forward to offering their customers the ability to streamline the traditional registration process for their end users, thus helping website owners better understand visitors to their site. He says this key partnership with Janrain allows his customers to easily enable these additional services and features on their site with just one click. Paul notes it also provides confidence that the functionality is well integrated and supported by both teams.

For more information on Fusion Partners and the program check out our partner section.

That’s why we’re excited today to launch a new integration with Google+ Sign-In.  With this product launch, Janrain customers can streamline the registration process for Google users, and gather additional profile data to better engage with and improve their experience.

Here is a run down of what’s new:

Simple, secure login

Google+ Sign-In helps improve registration conversion rates by offering a convenient and secure way for visitors to sign up on your site. We’ve made it really easy for websites to get up and running with Google+ Sign-In via Janrain Engage Social Login.

Gather Additional Public Demographic Information

In addition to a verified email address and a first and last name, users can now choose to share additional information from their Google+ profile when they log in to your site. Collect demographic and psychographic data such as gender, location, birthdate, interests, work history, education history, relationship status, profile photo and any other information made public within the user’s Google+ profile.

Access Google+ Social Graphs

Google+ Sign-In enables users to provide access to their Google+ circles of friends. Utilize this social graph information to let users discover what their friends are up to on your site, interact with friends, and surface content recommended by friends.

Drive Adoption of Android Apps

Let your website users instantly download and install your mobile or tablet app to their Android device.  Your users with Android devices don’t need to visit the Google Play store to install your Android app – instead, you can easily prompt them to do so in a single click when they sign in to your site with their Google identity.

You are invited to check out Google+ Sign-in on NPR, HSN and several Universal Music Group artist websites, including LadyGaga.com, Eminem.com and JustinBieberMusic.com.

The team at Janrain has been hard at work, and we are excited to offer the benefits of Google+ Sign-In to you. As always, your feedback is welcome.