JavaScript for Line of Business Applications

I’ve been finding issues in an Ember application I’m working on where the author (me) didn’t fully grasp Ember controllers. Here are a few controller concepts I’ve learned.

Controller Concepts
* A controller is a decorator for your models. It proxies all the get and set calls to the underlying model unless that property is defined on the controller itself.
* Controllers are fleeting, but models are forever (if you’re taking an Ember Data-like approach). As you route around your application, controllers will be destroyed so don’t count on them surviving very long. An exception to this is the immortal application controller.
* You don’t necessarily need a controller, especially if you’re not holding onto application state. The router events object is a great place to save, create, and delete models.

Sometimes web services and APIs return different data sets for the same type of object. For example, the tumblr API will return a list of posts, but each post type has different data associated with it: text posts have a title and body, while photo posts have captions and images.

Since having different components and directives for each post type doesn't make much sense (especially when they're all displayed in one stream, as on tumblr), it's beneficial to be able to conditionally load a template based on the post type of each individual post.

Slides from a presentation I put together for the Web Afternoon, Front Porch, and Thunder Plains conferences.

Highlights of Durandal.js — Built on KO, picks up where it left off — Routing: based on changes to URL — View/state change transitions — Async data fetching, with Promises — Manage code modules with Require.js — Enforces consistent code structure

Moving from a full stack framework like Rails to a front end framework like Ember.js is less of a leap than you might anticipate. You’re probably already using jQuery for some elements of interactivity, but at a certain point, you came up against that wall of maintainability and ended up with a hearty serving of front end spaghetti code. Yum. Here’s where a frontend framework can help, but this can cause a different kind of confusion.

Of course, switching from Rails to a front end framework presents you with a new set of tools, many of which have the same names as the ones you are already familiar with. This really comes to a head with the issue of how responsibilities are delegated, so let’s have a Rails vs Ember.js comparison of the two frameworks to clear this up.

httpinvoke is a 4.6kb no-dependencies HTTP client library for browsers and Node.js with a promise-based or Node.js-style callback-based API to progress events, text and binary file upload and download, request and response headers, status code.

Gracefully upgrades to latest platform-specific features:
* cross-origin resource sharing - do cross-domain requests with confidence;
* progress events - get current and total bytes downloaded or uploaded;
* binary file uploads and downloads - easily use Blob, FormData, ArrayBuffer, Uint8Array or a simple array of bytes.
* Supports both NodeJS style callbacks and Promises/A+ (with progress events, see an example).
* Supports transparent gzip/deflate content decoding.
* Handles HTTP responses The Right Way™:

Get implementation details on using Node.js (server-side JavaScript), rather than Java technology, to develop systems of engagement. In this article, the IBM Extreme Blue team who developed a RESTful backend application using Node.js and MongoDB shares their thought process and recommendations.

In this article, we share lessons we learned in the process of developing a RESTful backend application using Node.js and MongoDB. We highlight our thought process in several high-level design and implementation decisions. We'll cover these topics:
* Leveraging NPM (Node Packaged Modules)
* Understanding asynchronous programming
* Structuring a large Express.js application's routing configuration
* Application-level logging
* Approaching data persistence and modeling
* Solving Passbook-specific challenges including cryptographic functions not supported by Node
* And we address subtle "gotchas" in hopes of expediting the learning process for those interested in Node.js and MongoDB development:
* Don't make assumptions about objects or their properties in a dynamically typed language
* Avoid implicit control flow
* Understand your dependencies' behavior

Programming languages like BASIC, Python, C has boring machine-like nature which requires developers to write extra code that’s not directly related to the solution itself. Think about line numbers in BASIC or interfaces, classes and patterns in Java.

On the other hand JavaScript inherits the best traits of pure mathematics, LISP, C# which lead to a great deal of expressiveness (and fun!).

JavaScript allows programmers to focus on the solution/problem rather that to jump through hoops and API docs.

* Loose Typing
* Object Literal Notation
* Functions
* Arrays
* Prototypal Nature
* Conventions
* Modules
* “this” Keyword
* Pitfalls
* Further Learning

I recently needed to add drag & drop functionality to an angularjs web application I’m working on, none of the existing directives did exactly what I needed so I built my own. In building the directive, I needed a service to create UUIDs, so I built one of them too.

Design Goals
* Provide a mechanism to respond to a user dragging one element onto another
* No dependency on external frameworks
* No html template
* Applied via attribute
* Use native HTML5 drag & drop api

As part of Shazam’s BDD process, the Web team decided to start including automated acceptance test writing during the development process, with each developer in the team writing their own acceptance tests.

As we’re a team of both front and back end developers, it was important to find a language that we all felt confident using. JavaScript was an obvious choice for this. We then had the challenge of finding a framework that incorporated BDD feature files written in natural language with automated tests written in JavaScript. After trying out a couple of different options, we finally settled on a stack using Yadda for our feature files and parsing, withWebdriverJS for browser automation, and Mocha for test wire-up. The decision to use these libraries came after some trial-and-error, and we had variety of reasons for choosing these particular components for our new automation framework.

Searching for a particular element in a JavaScript array is often carried out using a typical iteration. In some cases, forEach and some can be used as well. What is often overlooked is the potential use of Array.prototype.reduce to perform such an operation.

Let’s take a look at the following problem: find the longest string in an array of strings. An imperative solution looks something like the following code (usingforEach may simplify the loop but the idea remains the same): ...

A version which relies on reduce is a single statement: ...