When it comes to queues, whether they’re implemented as JMS, database tables (i.e. what Ruby’s Delayed::Job uses for a queue), or even Amazon’s SQS, the most common metric used to evaluate the state of a queue is its length. In essence, one derives an efficiency metric based upon how many messages are residing in a queue at any given time. If there are just a few messages, the queue is operating efficiently. If there are numerous messages, things are inefficient and alarms must be sounded.
HTML5 is important for three reasons. And its importance starts with the end of browser plugins. That’s right. With HTML5, rich media aspects that were formally handled by plugins (think Flash), are now built-in. That’s why there are new media tags like
Think about it for a second – when’s the last time you visited a site on your tablet that asked you to install a plugin? Never.
That’s also why some older plugin laden sites do not work on your mobile device. Remember the whole ”Steve Jobs no flash” kerfuffle years ago? Yep, Mr. Jobs was adamant that the iPhone would support HTML5 and not fall into the plugin trap. Incidentally, Google and other major vendors have since followed suit. HTML5 has the support of all major browser vendors now – Apple, Google, Firefox, Opera, and yes, even Microsoft.
The good news is that you can emulate asynchronous callbacks in Java. In fact, I did just that recently with a library I’ve dubbed Ahoy!, which is an asynchronous SQS adapter for AWS’s Java SQS library.
Apple’s app signing process can be a real pain-in-the-neck; nevertheless, it works to keep apps trusted. You know when you download a Bank of America app from iTunes that it’s the real thing. You know that the app comes from the Bank of America.
On the other hand, Android allows apps to be self-signed. This has a fundamental flaw: an Android developer can claim to be anyone they want, including Bank of America. Thus, when you download an app from an Android App store, there’s a real possibility that the app was submitted by a charlatan. What’s more, those charlatan apps can actually be malicious!
While ElasticSearch is easy enough to work with via its RESTful HTTP API, there are myriad client libraries available in almost every conceivable programming language. If Node.js is your language of choice, then there’s at least two actively supported libraries available.
Sadly, lots of early Internet beer recipes aren’t necessarily in an easily digestible format; that is, these recipes are unstructured intermixed lists of directions and ingredients often originally composed in an email or forum post.
So while it’s hard to easily put these recipes into traditional data stores (ostensibly for easier searching), they’re perfect for ElasticSearch in their current form.
Accordingly, imagine an ElasticSearch index full of beer recipes, since…well…I enjoy making beer (and drinking it too).
ElasticSearch supports clustering; that is, you can have a series of distinct ElasticSearch instances work in a coordinated manner without much administrative intervention at all. Clustering ElasticSearch instances (or nodes) provides data redundancy as well as data availability.
Best of all, clustering in ElasticSearch, by default, doesn’t require any configuration – nodes discover each other. You can set up a cluster in about 60 seconds. Let me show you how!
As we draw closer to the glorious month of Movember, I find myself pondering the myriad template engines available for Node apps. The most popular is still probably Jade as its syntax is Haml-like and results in quite clean views, lacking in HTMLish clutter.
While Jade is handy, it takes some time to get used to. Plus, if you find yourself working with a UI person who prefers to speak in HTML, you’ll find yourself translating between HTML and Jade (which isn’t that hard with web apps like HTML2Jade, but nevertheless involves an extra translation step).