Nodeable Blog

I was recently forwarded this article from a co-worker, and I got to thinking about their list of “Best JavaScript Libraries” and how if I wrote that article, I wouldn’t have included any of those. Including PHP.js which is a joke to me (and I used to be a PHP developer). So, why don’t I write that article? Here is my list of JavaScript libraries that aren’t necessarily super exciting, but they are libraries that aren’t going anywhere, and you should really get to know them. These libraries aren’t a list of things that make the web super flashy and cool, but these are great libraries for the foundation of any serious JavaScript application.

jQuery

jQuery has been in existence for years. It’s nothing new, and it’s certainly not exciting. However, it’s the industry standard for DOM manipulation, and it’s under active development. Not long ago they gave some previews of jQuery 2.0. It’s nice to see it active and in constant improvement (unlike poor jQuery UI).

Require.js

As JavaScript applications get larger and developers need a large organized codebase, require.js steps in and fills that gap nicely. Require.js will help you to organize a large JavaScript project, and comes with a great tool to minimize and optimize your entire application, including CSS. James Burke has been tirelessly adding new features and doing great things to promote AMD patterns that are being adopted in many well-known libraries.

Backbone.js

Backbone provides a great MVC framework for helping you organize your large JavaScript applications. It’s even better when bundled with jQuery and Require.js. Recently I used it on a project to connect directly to a CouchDB instance to provide a live-updating data-driven application that makes a really nice and relatively simple stack.

D3.js

Data intensive applications need a lot of charting and graphing so that user’s can get better insight into their data. D3 provides a strong foundation that other libraries can be built on top of. Unfortunately, there haven’t been many quality libraries built for it, but it still provides a great feature set for building custom data visualizations.

Meteor.js

I’ve had my eye on this one for a long time. It provides a framework for quickly building a full client-server application that allows live-collaboration. I still don’t feel like its ready for prime-time yet, but it’s a very exciting and ambitious project. Once they tighten down the security, and allow it to be scale-able, I think it will turn into a big player.

Socket.io

This library provides great socket functionality between a Node.js server and a JavaScript application. It’s got great backward-compatibility support for older browsers and is simple to use (though difficult to master).

Conclusion

Here at Nodeable we use all of those libraries except for Meteor.js. They have been very helpful to organize a large code-base for our ajax driven web application as well as our mobile web application.

That’s it for my quick list of JavaScript libraries that are the foundations of JavaScript development. We use all of those except for Meteor.js at Nodeable, and they serve us pretty well.You should ignore all other JS libraries (except for js.js … Joking!!) I know there are probably some that I am missing, and I would love to learn what libraries you use for the foundations of your applications. Post the libraries you use in the comments, and teach me something I don’t know!

Call it irrational exuberance.  Call it hype.  Call it whatever you want, but understand that just because a big technology trend dominates the media doesn’t mean it’s The Right Thing for you or your company to embrace.  Not wholesale, anyway.

For example, consider just a few of the trends sweeping the industry, particularly those that are finding their way into job specifications.  HTML5, NoSQL (e.g., MongoDB), cloud computing, Hadoop, etc.  Spend a few minutes on TechCrunch and you’ll start to feel that YOU MUST BUY INTO THESE RIGHT NOW!

And, in some cases, you should.

But not always.  If you’re building a cloud application, for example, you’re likely going to want the scale-out capabilities of a NoSQL database like MongoDB.  But Oracle has a good point arguing that you wouldn’t want to build a checking application for a bank with NoSQL technology.   SQL has its place, and NoSQL has its place.  It just happens to be dominant for new school applications, which may not be the kind you’re developing.

Or consider Hadoop, which has dramatically lowered the (economic) bar to data mining/analytics.  Hadoop is fantastic technology, but it’s batch-oriented.  If you need real-time analytics, you’re likely going to want to couple Storm with Hadoop, as we do here at Nodeable.  Or maybe you should embrace Red Hat’s JBoss Data Grid 6, which “as an in-memory, key-value store…is much more optimized to handle the operations that Hadoop simply can’t: transactions like the kind found in e-commerce and financial trading systems.”

Does this mean you dump Hadoop and swap it for Data Grid or Storm?  Of course not.  But it does mean that developers need to look beyond the hype to determine what is the best tool for a particular job.

The same thing holds true in mobile, where HTML5 promised to be the end to mobile’s fragmentation problem.  Instead, it turns out native apps dominate the smartphone space, while content-friendly tablets are much more likely to be friendly to HTML5.

The list goes on.  Some swear by Node.js, but it’s best for server-side app development, and not a panacea, according to Nodeable CEO Dave Rosenberg.  Cloud?  You probably shouldn’t choose private or public, but both, declares Citrix’s Peder Ulander.  Etc. etc.

Each of these technologies is trending because it solves real needs in novel, useful ways.  But this doesn’t mean they’re right for you.  Of course, one of the great things about cloud and open source and other megatrends like these is that they tend to skew open, such that you can try before you buy.  As a vendor, this is a huge boon, as I’d much rather customers buy what they need and are happy, rather than getting duped into buying hype that doesn’t fit their needs.

That’s the old world: buy into the hype and regret is later.  The new world lets you regret your decision right away.

The gods could be crazy, or they simply may not like IT very much.  Over the past decade, trend after trend has arisen to give power back to developers to get their work done, and away from the bureaucratic IT staff that want to manage that work.  IT, however, has the potential to claim a very valuable role in the changing enterprise, but requires a new mindset and mission.

In a new research report (executive summary available for free), Gartner articulates this shift away from IT-as-king to IT-as-facilitator, and how the cloud fosters the trend:

In 2010, organizations were compelled to consume IT services from external cloud providers to achieve their business, budget, and IT goals. But organizations realize that external cloud computing is not a panacea. They still need internal data centers to house critical applications and data. However, the use of external cloud providers has conditioned organizations to expect IT resources — whether internal or external — that are offered in an on-demand, self-service manner. Therefore, IT organizations are forced to offer IT services by using the same consumption model or otherwise risk extinction.

Poor IT.  First it had to deal with the rise of open source, and now cloud.  Both trends have forced IT to loosen its stranglehold on the software, hardware, and services used with the enterprise.  All of the arguments that failed against open source are also failing to stem the tide of cloud computing.

And rightly so.

But none of this means that IT is dead.  It just means, as Gartner points out, that IT’s role needs to change.  For example, DevOps is a very real phenomenon, but I suspect few organizations will have the know-how or brazen courage to take the Netflix route and embrace DevOps completely.  The trick is to give developers more flexibility without imposing on them the burden of setting up and managing all infrastructure themselves.  Yes, some will want precisely this.  But most just want greater influence over the tools they use.

They’re not going to get this from OpenView or any of the legacy tools from legacy vendors.  They’re just not going to blend private and public cloud resources, host their code on GitHub, and be bothered with clunky old management tools.  It’s not going to happen.

So IT needs to redefine its new role.  And it needs to get new tools for doing so.  Or it’s going to evaporate into obsolescence.

Over the last few months of the Nodeable beta we’ve been obsessing over how our 400+ beta customers use the service and what they want from the product. We heard loud and clear that we should increase the value of the data we present and decrease the importance of the social features that we thought were initially interesting. Hooray for user feedback!

Cruise over to beta.nodeable.com and login.

Introducing Nodeable Insights!

Nodeable Insights are the new “messages of interest” that are surfaced by our analytics engine.Nodeable analyzes your data in real-time and applies continuous computation to determine the state of your resources — including finding and revealing anomalies in addition to providing summaries and status updates.

The New Event Stream!

We’re making big data small and doing the real-time analysis so that you know what you should be paying attention to at any moment in time.But, if you want to see every little thing that your systems are doing you can just jump over to the stream where all is revealed!

Dashboard coming soon!

There are quite a few features that we’ll be rolling over the next few weeks, including the dashboard and the Inbound Messaging Gateway that will allow you to send any type of data in Nodeable.Our rolling release cycle means you’ll automatically get the latest and greatest features while we sleep as little as possible.

Take our survey!

To make sure we’re doing the right things, we’re running a quick 10 question survey that should take you no more than 30 seconds to complete.We need your help to make Nodeable better and everyone that completes the survey is automatically eligible for an office visit from the Nodebelly himself.**
**(Note: the Nodebelly doesn’t actually exist but we will send you a t-shirt)

It’s like Microsoft is watching as the train barrels towards it, but refuses to get out of the way.  Even as the world moves to the cloud and open source, Microsoft’s general counsel, Brad Smith, proclaims:

Pleased the ITC ruled in our favor today against Motorola’s Android platform. Licensing is the path forward: bit.ly/Jd5MYL

— Brad Smith (@BradSmi) May 18, 2012

No, Brad, licensing is emphatically not the path forward, for Microsoft or many other companies.  Yes, you continue to make gobs of money selling licenses to Office, Windows, and such.  But perhaps you’ve noticed where all the new money is going?  It’s not going to buy office productivity suites at all.

It’s buying services.  That run on the web.  Only a tiny fraction of which are sold by Microsoft.  Doesn’t this bother you?

Sure, you have managed to eke out some semblance of a mobile business by suing and/or scaring would-be licensees into paying you for Android (since almost no one is paying you for Windows Mobile).  But you’re missing the point.  Even Apple, proprietary in ways you never dreamed of being, doesn’t license software.  That’s what we did back in the 80′s and 90′s.  But it’s not where business is going, and your obsession with living on past business models is tripping you up from embracing the future.

I’ll do you a favor.  There’s a book that talks about this.  It’s called The Innovator’s Dilemma, and was written by Clayton Christensen  Perhaps you’ve heard of it?  I’ll give you a summary version from an excellent article in The New Yorker profiling Christensen (You’ll have to buy the magazine to get the full version because The New Yorker is part of your crowd, and paywalls its content):

Christensen didn’t blame big companies for moving upmarket.  They had to grow a certain amount every year, so selling bad products at low margins (like rebar) was never going to seem like the sensible thing for them to do.

And venturing into markets that barely existed (like teen-age radio consumers [or cloud computing or that newfangled Internet thing or tablets that aren't clunky and simply tired renditions of your desktop Windows experience]) didn’t seem sensible, either, because, without the benefit of hindsight, how could you tell the difference between a bad product poised to take over the nation and just a bad product? You couldn’t invest in every dumb thing that came along — you’d go bankrupt. The sensible thing for big companies to do was to pursue higher margins, or to wait until a new product’s market became visible enough to be analyzed and large enough to be interesting–but by then it was too late.

Meanwhile, the big companies kept doing what they were supposed to, listening to their customers and improving their products in ways that mattered to those customers, until they had improved them too much, climbed so far upmarket that they sailed right off the upper-right-hand corner of the graph, adding more features and power and degrees of perfection than anyone could possibly use, and by that time the bad, cheap, low-end product had improved to the point where it could finally appeal to the big companies’ customers, and the big companies failed.

Kind of like what happened this week with the U.S. Department of the Interior announced it would move 90,000 employees over to Google Gmail and Apps.  Microsoft has been slowly embracing online services, but when virtually all of your money comes from your old-school licensing business, what can you possibly do but continue to try to force customers down that road?  Think of how much easier it would be if your revenue were tied to an Office service rather than a one-off licensing event, with ongoing maintenance.  I bet you think of that every day.

But then you tweet about how licensing is the future, when it is so clearly the past.

Don’t believe me?  Get out of Redmond and drive down the 520 to Seattle, where you can visit Amazon, which is polishing the nails for your coffin with Amazon Web Services, which is the platform for the next 10 to 20 years of computing.  Not Windows.  AWS.  It’s already enabling the next wave of innovative startups, as Amazon CTO Werner Vogels recently pointed out, but the shift is much deeper and broader than that.  The future is not being built on Microsoft technology.  Period.

And telling the world to license your mobile technology, when it’s clearly going down the Apple or Android routes, is a losing strategy.  While Facebook goes public on a $100 billion valuation your world is threatening to layoff 25,000 people, and that’s just at one company.  Eventually those people will find their way into companies focused on the future, but not if they heed your advice and fixate on licensing.

Unfortunately, your advice isn’t even good for Microsoft, and that’s a bad thing, as we need a competitive Microsoft again.  You make great software.  You just need to start distributing software the way the world has chosen for the 21st Century: think service subscriptions, not software licenses.  We’ve met before at OSBC and at Stanford Law School, and I think you’re a wonderful person.  I just happen to think you’re woefully misguided with this licensing fixation, and it’s hurting your company and the industry.

For the past 10 years, the LAMP stack has laid waste to proprietary software stacks.  Yes, Microsoft has held onto gargantuan profits, but LAMP has become the foundation for leading web services, whether Google or Facebook or [Insert Big Web Brand Here].  LAMP is the future.

Or was.  That is, until cloud killed it, as Eucalyptus CEO (and former MySQL CEO) Marten Mickos posits in a great keynote from the Percona Live: MySQL Conference & Expo 2012.

No, LAMP is not going away.  But it’s comfortable existence as a somewhat coherent instantiation of Linux-Apache-MySQL-Perl/PHP/Python is gone.  Mickos, despite speaking at the MySQL conference, was quick to point to big changes in the database market, many of them not conducive to MySQL’s dominance in the cloud:

As he notes, we’re less concerned with stacks anymore:

From 2000 to 2010, it was all about the LAMP stack. To build an app, you took one Linux, one Apache, one database, one language. You stacked them on top of each other. You multiplied them to scale out….Today applications have many different languages and databases, and they’re not stacked upon each other.  We don’t stack things anymore.

Furthering this idea, today, in the cloud, users spin up new VMs. Each VM can have its own version of Linux. Each app typically has many databases (MySQL, Memached, Sphinx, Hadoop, etc.) and they are not stacked on top of each other. Scaling out may mean scaling out with different instances.

On top of the database, you can have many languages. The same app may use PHP, Python, Ruby, JavaScript etc. Again, these are not stacked on top of each other but they are next to each other, and perhaps even next to each other in different VMs.

Mickos points to Amazon Web Services as an example: 10,000 images available for people to use. Those are the new distributions. Not Ubuntu or RHEL or whatever flavor of Linux you prefer.  They contain numerous different combinations of tens of pieces of software.

This doesn’t, of course, render a Red Hat or MySQL (Oracle) obsolete.  But it changes the game considerably, and makes managing the diversity of infrastructure within the enterprise much harder in many ways.  Indeed, following Randy Bias’ thinking, this complexity may be the exact opposite of what is needed to scale in the cloud.  While Mickos is right to point to the disparate software configurations Amazon offers on AWS, AWS itself uses a very unified set of infrastructure components, down to the hardware.

Still, Mickos’ point feels correct: right or wrong, we no longer rely on a unified LAMP stack to run our applications.  We use a variety of Linux distributions, databases, programming languages, etc.  Whether we’ll get back to a unified infrastructure “stack,” in the way Bias suggests we should if we hope to scale, is an open question.  Maybe it will be the successor to LAMP.  But for now, it’s complexity all the way down.

When you’re charting new territory with a product or service, it can be difficult to explain exactly what you’re doing.  It’s easy to say “We’re like XXX, but faster/cheaper/better.”  But when you’re helping to create a new market, you have to invent a new vocabulary to describe it, or at least find old markets that can serve as analogies for the new market.

Such is the case with a rising breed of social, enterprise services.  Wells Fargo analyst Jason Maynard is predicting a $4 billion market in “engagement apps” over the next few years, a market that hasn’t existed before and can therefore be somewhat squishy to describe.  In a new report — “Fostering the People: The Shift to Engagement Apps” — he makes a valiant attempt:

Business applications are moving beyond merely transactional and analytical functions and are becoming critical tools to engage with customers, to improve productivity, and to facilitate collaboration within the enterprise and throughout the entire value chain. With the digitization of local commerce and the growing adoption of social operating platforms, mobile computing, and global value chains, we believe the trend toward business of adoption of “Engagement Apps” will grow rapidly and rise in importance over the next five years.

These systems represent a new layer in the application topology, moving beyond analytical and transactional systems. We define engagement apps as applications, processes and analytical tools that enable companies to actively interact and empower interactions with customers, with and between employees, and with external partners across the value chain.

These apps should be native cloud, socially aware, mobile ready, and embedded with intelligence. Collectively we contend the shift to engagement apps will manifest into a new system of engagement for these processes that sit above existing transactional and analytical applications and data. We think engagement apps can be segmented in the following three main categories: (1) social CRM or customer experience management, (2) internal productivity, and (3) external value chain collaboration.