JavaScript for Line of Business Applications

So, how can we combine these two immensely powerful libraries to do something interesting? Or at least vaguely interactive.

Let’s see if we can use D3 to draw some rectangles, described in a Knockout view-model, which we can modify using D3 or by altering the data itself.

There is some overlap in functionality here: KO enables us to generate DOM content based on data, as does D3. In theory we could use a KO template to generate fragments of SVG markup for each of our view models. But that would involve generating the elements long-hand and we wouldn’t have the association between view and view-model.

Now, we need a way of getting the KO data fed to D3 at the right time: when it’s updated.

One of the first things to notice is that if we observe the array of rects, we only see changes to the array, not to its elements. In other words, we only know when items are added or removed, not when elements properties are changed. Seeing as we need to know when a rectangle’s position changes, we’ll need to do some more work.

- See more at: http://www.voyce.com/index.php/2013/06/23/dynamic-d3-with-knockout-js/#sthash.IDxcsa5W.dpuf

You may want to read this post if:
* you want your URLs to look like /posts rather than /#/posts and to interact with browser history properly
* you need to support browsers that do not support session history management
* the Ember.AutoLocation feature is not yet available

If enough of that is true that you're still reading, then keep reading and I'll explain how to use History.js to make the pain go away.

Backbone.js deserves a lot of credit for bringing MVC to mainstream client-side Javascript development. That said, many beginners ask what the ‘right way’ of doing something with Backbone is. The bad news is that there’s not necessarily a ‘right way’ – it all depends on the problem you are trying to solve. The good news is that there are definitely some ‘wrong ways’ that you should avoid on your way to finding the right solution for your particular problem.

In this post I’ll cover some of these anti-patterns, as well as some general advice for the new starter. I’ve ordered the anti-patterns roughly by significance from the major to the more trivial. Don’t be too upset if you’ve done something on this list – I’ve made most of these mistakes myself 

This time, I would like to show you how to add a simple pagination helper to your Ember.js application.

For this example, I will be using Rails + Solr for the backend and Ember.js as my frontend framework.

I am doing this with Rails and Solr, but you can do it using other backend frameworks, as long as the JSON's response resembles what we have here:

Before we start, there's something I want to say, just in case you are using the ember-rails gem. 

I have created a new Model, Serializer and Controller on Rails. So, all this means that I'm going to need a newEmber.js model, in order to get it working. Remember, the store is in charge of finding the models through the adapter. It will communicate with the new Rails controller to serialize the new model.

From my point of view, we can have many paginated collections inside an application. So, one way to avoid code duplication is the use of Ember.js Mixins. 

A module done "the right way" primarily means: it works. It doesn't error or run code in an unexpected way when you're deploying, have other developers running your code or come back to update a project some time in the future. Other problems like files space and ease of use should be secondary concerns.

I am using the term "modules" in the most generic sense of the word. These concepts can apply to your project structure, package manager or the very way you write code. I'll attempt to explain these concepts a generic way then provide real world examples.

JavaScript is single threaded, meaning that two bits of script cannot run at the same time, they have to run one after another. In browsers, JavaScript shares a thread with a load of other stuff. What that stuff is differs from browser to browser, but typically JavaScript is in the same queue as painting, updating styles, and handling user actions (such as highlighting text and interacting with form controls). Activity in one of these things delays the others.

* What's all the fuss about?
* Events aren't always the best way
* Promise terminology
* Promises arrive in JavaScript!
* Browser support & polyfill
* Compatibility with other libraries
* Complex async code made easier
* Promisifying XMLHttpRequest
* Chaining
* Error handling
* Parallelism and sequencing - Getting the best of both
* Promise API Reference

I had a chance to perform investigation of JavaScript based compression. In this investigation I tried to
compare Compression, Decompression and Integration with other platforms (like Java) of all libraries I was able to find.

Current post contain libraries overview and test conditions. Next posts will contain actual result of compression, decompression and integration:
* Compression ratio
* Compression performance
* Integration of compression librearies with other platforms
* Deflate libraries integration
* LZW libraries integration
* Other libraries integration
* Decompression performance
* Decompression on other platforms

AMD (short for Asynchronous Module Definition) is a JavaScript API specification for structuring modular code. The web abounds with blog posts illustrating its use in front-end application development (and there’s plenty of healthy debate around its necessity, too). The topic of unit testing (despite being integral to the process of software development) does not receive much attention in these discussions.

As it happens, AMD has an impact on how one authors tests. More than just dictating some additional function calls, AMD (and the RequireJS library in particular) can actually enhance unit test suites.

Finally, if you’re convinced AMD is right for your project, then the truth is: your hands may be tied. The structure of an application dictates the structure of its unit tests. This means your test environment is going to have to account for that sweet, sweet asynchronicity of your module definitions.

I was surprised by the good feedback for JavaScript template engine in just 20 lines and decided to blog for another small utility function which I'm using often. While we are talking about JavaScript in the browser, most of the operations are asynchronous. We are dealing with callbacks all the time and sometimes we end up with awesome callback hell.

Let's say that we have two functions and we want to call them one after each other. They both operate with same variable. The first one sets its value and the second one uses it.