JavaScript for Line of Business Applications

Ember.js is an outstanding client-side framework for building single-page applications. To make your application truly come to life, Firebase, being a real-time backend, is a natural choice as the server-side component.

Sending data between the server and the client is a task all web applications have to address. However, if one uses the Firebase-Ember.js stack, this problem is largely abstracted away by these wonderful frameworks.

To make them work together, the Firebase team released their official Ember.js bindings, emberFire.

This article describes how on{X} is used in conjunction with Node, Express, and Socket.IO to control web pages from an Android device.

I had lost my phone. I left it on a couch in a shopping mall and returned back to find it gone. Someone had been gifted a new phone via the awful art of stealing. I sent JavaScript code remotely to my phone over the web that sent me the coordinates of the device any time I texted it. I tracked it to a Sizzler restaurant until they turned the phone off and it disappeared forever. I bought myself a new phone but saw new potential in a powerful app I’d barely used until that point called on{X}.

In this article I’ll be sharing a very different use of the app compared to the horror story of my lost phone. I’d like to show you how you can use your Android device to send remote instructions to a live web page. I’ll be using the example of remote controlling a HTML presentation but the concepts can be expanded to do any number of interesting things.

D3 a very powerful tool and at times can be a bit overwhelming. Today I would like to simplify things by walking you through building a bar chart using D3.

First step is to create a barChart directive.

It will will take an data array and add a svg tag to our element. We will using this svg to build our chart.

D3 allow us to resize our data to the portions of the SVG using d3.scale. We tell the scale the upper and lower bounds of the dataset using domain and the upper and lower bounds of the chart using range. Using x and y functions generated from d3.scale.linear(), we can then place bars in the right spot on the SVG.

Tutorial on how to write behavior driven tests of ExtJS 3.4 components with Jasmine.

Developing your own ExtJS components for your application is more fun and results into more resilient code if you write them hand-in-hand with test code. A solid test basis can also facilitate the task of refactoring your software.

Although, test driven development is easy for javascript code, how can ExtJS 3.4 components be tested? Which parts of our components should be tested to accomplish a successful refactoring?

In this post I want to shed some light on this in JavaScript hopefully bring some clarity to how this works. It’s not all dark magic, learning about this can be tremendously helpful to your development as a JavaScript programmer. 

* How this works
* Tampering with this
* Scoping this
* Other Issues?

When discussing primitive data types in JavaScript, most are aware of the basics, starting with String, Number, and Boolean. These primitives are fairly straightforward and function as you might expect. This article, however, will be focusing on the more unique primitive data types known asNull and Undefined; what makes them similar, dissimilar, and overall unusual.

In JavaScript, null is a literal and language keyword that represents no discernible object value. In other words, it’s an indication of “no value”. While similar, undefined actually represents the non-existence of a value. Both are completely immutable; have no properties or methods, and are incapable of property assignment. In fact, attempting to access or define a property will raise a TypeError. They are, as their names suggest, completely void of value.

When developing a Backbone.js mobile web app recently, I needed to create a unique history state without a unique URL when opening an overlay. This was done to allow the user to hit back in the browser and be returned to the view which launched the overlay. While solving this problem, I landed upon a concept of microstates which I thought might be of interest to other web app developers.

In this post I will first give an overview of the HTML5 History API, then talk about how to create a microstate in a Backbone app, and conclude with the implications of exposing microstates.

In this Angry Birds session we uncover concepts of modern JavaScript development. Each bird represents an area of JavaScript along with its strengths. Some topics covered include code organization, events and messaging, prototyping and mocking, design patterns, linting, and build systems. The goal is to defeat the pigs and by doing so produce highly tested quality JavaScript code.

If I could go back and stop myself from making a whole bunch of mistakes in that app, I would have started with explaining that a directive is just a simple little reusable component for describing the way HTML should behave. The Angular docs try to harp on this but inevitably they make it seem obtuse and complicated. Note: Though they could be better I don’t think it’s cool to hate on the Angular docs. They’ve gotten way better even in the short time I’ve been using the framework.

In my opinion it’s a very useful tool because it allows you to encapsulate functionality in a semantic way that will (hopefully) make sense to anyone looking at your markup, and keep your functionality well “chunked” so that you can keep track of what is happening where instead of dealing with things mutating globally (which most of us hopefully know by now is bad news).

Ever had this happen with jQuery? You need to do some JavaScript magic with a particular element on the page, and so you give it some arbitrary id so you can access it with$('element#id'). Now you get to write a bunch of JavaScript that listens for the relevant events, checks the element’s state to see that it is congruent with our expectations, modify its class to change how it is displayed, and so on. It starts out as a few simple functions using a very powerful tool that soon grows into a complicated mess of callbacks, weird looking selectors, and re-render functions. It may be strewn across several files with no rhyme or reason.

Not only is it no fun, it makes it very hard for your designer friends to look at your markup and know what the expected behavior for that HTML is. So, Angular provides us with directives, which are actually pretty simple to create. So don’t be scared of them like I was. 

This article is a tutorial of how to set up the knockout.js environment in a MVC4 application and perform CRUD operations on it.

I have been browsing multiple sites for a complete end-to-end tutorial or article upon CRUD operations using Knockout.JS and MVC 4. Unfortunately all I found were incomplete or short explanations. In my last article we learned about imlementation of CRUD in ASP.Net web forms using MVC and EntityFramework. This article is the continuation of the series. My effort in this article will be a kind of tutorial to explain how to set up the knockout.js environment in a MVC4 application and perform CRUD operations on it.

While the source code for emojitracker has been open-source since day one, the technical concepts are complex and varied, and the parts of the code that are interesting are not necessarily obvious from browsing the code. Thus, rather than a tutorial, in this post I intend to write about the process of building emojitracker: the problems I encountered, and how I got around them.

I’d been playing around with the idea of realtime streaming from the Twitter API on a number of previous projects (such as goodvsevil, which was the spiritual predecessor to emojitracker), and I was curious about seeing how far I could push it in terms of number of terms monitored. At 842 terms to track, emoji seemed like a prime candidate.

Emoji are also a great way to get insight to the cultural zeitgeist of Twitter: the creative ways in which people appropriate and use emoji symbols is fascinating, and I hoped to be able to build a lens that would enable one to peer into that world with more detail.

* Background Understanding: Emoji and Unicode

* Emojitracker Backend Architecture
Feeding the Machine: Riding the Twitter Streaming API
Data Storage: Redis sorted sets, FIFO, and Pubsub streams
Pushing to Web Clients: Utilizing SSE Streams
Performance Optimizations for High Frequency SSE Streams
Gotcha: Many “cloud” environments don’t properly support this (and a workaround)
Not crossing the streams: The admin interface

* Frontend Architecture
* Frontend Performance
* Deploying and Scaling
* Things I’d still like to do
* Reception and conclusions

Nunjucks does a lot of things, like loading templates, calling filters, and more. All of this is synchronous by default (which isn't a problem for loading templates, since they are loaded once and cached forever). This limits what you can do in filters and template loaders, since you can't use any async functions.

This hasn't been a problem for a long time, and for most people never will be a problem. You don't want to mix too much logic with your templates, so you usually do all the complicated async work in a controller and pass the data to the template.

However, I can imagine sites that are heavily template-driven and developers wanting to wrap up some sort of behavior that depends on an async operation into a filter or custom tag. Nunjucks is built to allow people to add logic to their templates as needed, and works great for large content-heavy projects where not everybody is familiar with the backend.

Regardless, I think asynchronous control is an interesting feature that doesn't adversely effect existing templates, so I decided to dig into it. Here's what I came up with.

By leveraging the Node.js middleware “express”, we can create functionality for viewing, adding or deleting JSON data.

The goals for this article are:
* Allow the user to view all data in the database
* Allow the user to make a JSONP call to get all data
* Allow the user to add a new name to the Sales database
* Allow the user to delete all data in the database

When completed, this will be far from a robust or production-ready application, but we will, at minimum, learn how to view / add / delete data in our MongoDB database, using clean URLs in the browser.

Backbone.Notifier was born as part of JSNAIL.IT (not live at the moment, maybe will revive it some day), an independent project I've worked on. It started as a component I were quite pleased with, and thought it may be also useful by others, so I've decided to add some features, make it completely independent and open it's source.

After years of working and using dozens of open-sourced projects, I'm glad to contribute to this amazing community and hope you'll find it useful. Feel free to contact me for any purpose.