JavaScript for Line of Business Applications

In web browsers, window refers to an object that contains the global variables. This blog post explains how it works and when to use it.

* The global object and window
* Use cases for window
* The future of global variables
* Conclusion

We have seen several use cases for window. But you can normally achieve the same result by treating a global variable as a variable and not as a property of window. This is the recommended way of doing it, because your code becomes slightly more flexible and because the global scope will become less used in the future.

Restangular is an AngularJS service that simplifies common GET, DELETE, and UPDATE requests with a minimum of client code. It's a perfect fit for any WebApp that consumes data from a RESTful API.

Restangular has several features that distinguish it from $resource:
* It uses promises.
* You can use this in $routeProvider.resolve.
* It doesn't have all those $resource bugs.
* It supports all HTTP methods.
* It supports ETag out of the box.
* It supports self linking elements.
* You don't have to create one $resource object per request.
* You don't have to write or remember ANY URL.
* It supports nested RestFUL resources.
* Restangular lets you create your own methods.
* Support for wrapped responses.
* You can build your own URLs with Restangular objects easily.

I’m asked regularly about books and online resources to get up to speed on JavaScript. Seems like everyone wants to get in on the JS action and with good reason; it’s a great language to know if you’re interested in exciting career opportunities. It’s also pretty fun to play with.

With JavaScript’s increased popularity, the number of books, blogs and tutorials about the language have grown exponentially and while I can’t possibly know all of them, I’ve found some gems which I really like and would like to share those with you.

* Books

* Freebies

* Blogs

* Taking a Class

* Getting Help

Testing (i.e. linting, unit tests, integration testing etc..) client-side code is not done as commonly as it should be. The reason it is so commonly not done, besides lack of know-how, is that it is presupposed that it will take time away from other more productive development tasks.

This fallacious notion is, of course, wrong. The repeatable successes in software engineering based on testable (i.e. modular, loosely coupled, small, simple units of code) and tested code has proven again and again to be a time-saver and part of creating maintainable and understandable code. At a minimum, if code is not unit tested it is only a matter of time before it is burnt down and re-written, or abandoned altogether because it becomes unmaintainable and incomprehensible.

In this article, I am going to defend and talk about testing client-side code. It is my intention that the information in this article will give those among us who do not test, the desire and some initial testing knowledge to test, along with the ability to defend its necessity from any agent that might deter testing.

This post is a follow up to my previous post about SEO and getting your App crawled. A very important topic of SEO are URLs, as they have a big impact on your ranking by the various search engines. Therefore you will want to create custom URLs in your app. In this blog post we will have a look at how to implement custom URLs this with 3 easy steps. At the end i will show you a shortcut that allows you to skip the steps 2 and 3 and do it with 1 step! I will provide JSBins for you to play around with both approaches.

This are the 3 steps towards your custom URLs:

* Modify the mapping in your router and add dynamic segments to customize your URL.

* Implement the serialize method to create an URL representation of your models.

* Implement the model method to convert a URL into a model again. This is needed when a user enters your App via URL, e.g. a user hits refresh or someone shares a link to your page.

Lately I've seen a lot about JavaScript Inheritance and in particular different github projects that allow you to do inheritance in a certain way. Most of these solutions are about trying to use some form of classical inheritance and with good reason. If you're used to any other language then that is probably what you learned and so it makes sense. Also there can be performance gains as using a "class" means you won't be mutating an object's signature and as such a JavaScript runtime can make optimizations for that "type".

There are also some good articles about what JavaScript inheritance is really about and if you only read one, make sure to read Kyle Simpsons: JS Objects.

But do we really need long inheritance chains where we link up lots of objects and have lookups going up a chain? As JavaScript is so flexible can we learn things from Functional and Aspect Oriented styles of programming? I think we can.

Learn to test, debug and prepare the test code on your AngularJS application like a Pro using Jasmine unit testing and Protractor integration testing

AngularJS is becoming immensely popular and mainstream which means that there is a lot of AngularJS code out there that is being tested or is yet to be tested. And now that you're well on your way to test like a pro, thanks to the abundance of articles, tutorials, books and material out there on AngularJS testing & development, testing should be a mandatory process of your web development workflow.

Full-Spectrum testing with AngularJS & Karma taught us how to test certain areas of your AngularJS application, but how do we test efficiently? How do we debug a problem down the root cause? How do we skip tests, set breakpoints, and professionally mock-out our test components so that we can catch hidden bugs and unexpected scenarios? How far can and should we go with Unit & E2E testing? What else should we consider. Well lets take adeeper dive into testing in AngularJS and expand our minds by learning how to become a professional front-end tester.

Table of Contents:
* Presentation Slides + Video
* What to test and what not to test
* Preparing your test environment with Karma & Grunt
* Write tests as you go
* So when do you do your testing?
* Module & Inject Breakdown
* Powerful Mocking Strategies
* Sync' and Async' testing
* Skipping and Filtering tests
* Echoing data back to screen
* Using Breakpoints
* Writing Efficient Tests
* Testing older browsers
* Invest into preparing a CI environment
* Feedback Please!

When you first hear about AngularJS Directives, they appear magic in the 'omg what is going on here' way. As a newcomer to AngularJS, the idea of extending HTML with your own elements seems foreign, or a callback to IE6. Without mastering directives, you'll limit the potential of your AngularJS apps -- not cool.

It doesn't have to be this way: you can create Directives to reuse code and make templates easier for you (and future-you) to understand. You'll think of Directives as creating a DSL in HTML, and become a Wizard of unimaginable power! Ok, maybe not, but you will write easier reading code, and code that's easier to reuse.

All you need is that one example that turns the lightbulb on. Let's take an example from AngulaRails, and create a <multi-avatar> HTML element that displays a user's image, but with some requirements:

* If the user has a facebook-id, we want to use the Facebook image.

* If the user has a github username, we want to use Github's shiny avatar service.

* Otherwise, use Gravatar with the user's email.

Single Page Javascript Applications and specifically Ember.js applications don’t always expose the right information to Google Analytics. Usually you’ll see 100% traffic to / and nothing else.

What I wanted to be able to see what areas of the site people were using in real time. A bit of searching led to various solutions withthis post having the most upto date solution. Working in Ember you quickly become wary of older solutions posted and start filtering search results based on time. Hopefully now that 1.0 is out the correct solutions will start bubbling to the top of Google searches.

To make your Ember.js application more visible to Google Analytics you need to expose the value of your application state. I’m using the hash scheme (eg #/album) so whatever is after the hash in the url shows where a person is in the application.