JavaScript for Line of Business Applications

I've come to expect that getting ramped up on a new framework is a rite of passage, and that indoctrinating oneself to its paradigms should necessarily be hard. After putting off my foray into AngularJS for far too long, I was pleasantly surprised to find that getting started was painless. There's a great community, extensive documentation, and tons of fantastic tutorials.To be honest, this was one of the things I found most lacking when working with Ember.js, and for better or worse, I think it may be because AngularJS is just simpler.

Is simplicity something you want when choosing a JavaScript framework? Call it a double-edged sword, or whatever cliché you choose, but I feel that simplicity is simultaneously underrated and overrated in the software world. Go too far in either direction and and you'll eventually end up cursing at your computer. Maybe Ember.js is the right choice for a really complicated JavaScript application, but that's not what we were trying to build. Inevitably, someone will point out what Ember can do that Angular cannot. Quite simply, I don't care. Angular's simplicity makes me more effective.

Here is a starting guide for securing express.js applications, specifically Express v3. It is by no means a comprehensive guide on web application security. Standard rules and practices apply to express.js apps just as if they would to Rails, Django or any other web application.

I’m going to hit the high points of items that always seem to come up.

Last time we talked about how to handle $http in a AngularJs unit test. This time around we are going to expand on this example by creating a ComplexService which takes the SimpleService as a dependency. Since our test for the ComplexService should not rely on the SimpleService we need to introduce a way to Mock our dependency.

Mocking out dependencies in services it a bit more challenging but using $provideallows you to supply mocked versions for your dependencies. You can view the full code out on github.

I've seen a fair amount of callback bashing on Hacker News recently.

Among the many proposed solutions, one of them strikes me as particularly clean: "asynchronous wait" or "wait and defer". iced-coffee-script had this a while ago. Kal just debuted with an identical solution, only differing in syntax. Supposedly LiveScript supports this with "backcalls".

I must say, "asynchronous wait" or "monads" - whatever you want to call it - seems like an improvement over callbacks. But I'm here to say that actually... callbacks are pretty okay. Further, given how clean callbacks can be, the downsides of using a compile-to-js language often outweigh the benefits.

I have 2 rules of thumb for code organization which makes clean callback based async code brainless:

1. Avoid nontrivial anonymous functions.
2. Put all function declarations after the code that actually does things.

As you have seen in the previous article, a function does not necessarily require a name: function () {} (anonymous functions) is a completely valid expression. Since functions are objects, they will have a name property which contains the name of the function as a string. For anonymous functions the value of this property is an empty string: "".

When we started planning the front end for SHIFT, the first question everyone asked was, “what framework should we use?” It was agreed upon early on that we wanted a single-page app built on the same API that we would be providing to third party developers. We wanted a solid front end framework to help us manage a large single-page app. Backbone seemed like the obvious choice because it was lightweight, easy to use, and it had a huge community. However, after doing a few prototyping exercises, we were impressed with the development speed we were achieving with AngularJS. Ultimately we were so impressed that we dove head first into AngularJS, and these are some of the things we found.

* What We Liked

* What to Watch Out For

* Conclusion

This week we have created a collection of different d3.js basic Graph and Charts with Angular.js Directives.
We have made Angular.js Attribute Directive and Element Directive with sample JSON Data for all of the Directives and documented those. Some of those are listed below.
Reader should go to the main page from http://phloxblog.in/angulard3/start.html

Displaying a list of items is one of the most common tasks in any application - and JavaScript and Backbone.js apps are no exception.

Backbone generally makes these two tasks easy. It provides the concept of a Collection to manage a list of items, and you can assign a collection to a View instance for display. But what happens when you need to filter that collection, and only display a subset of what it contains? And what if that sub-set changes when a user selects certain options or types something new in to a search box?

Filtering an in-memory collection is simple, sure. The collection has built in methods to do this. But filtering a collection and then rendering the results can create some unexpected challenges. The journey to find simple and clean code can be unexpectedly difficult.

Dedicated followers of JavaScript fashion will by now have noticed this season’s hot new trend. If you haven’t spotted it yet, here are a few projects sporting this style on the GitHub catwalk: React, Reactive.js, component/reactive and reactive.coffee

That’s right: reactive programming is the new black.

At a high level, the idea behind reactive programming is that changes in state propagate throughout a system. Put crudely, this means that in a reactive system where a = b * 2, whenever the value of b changes, the value of a will also change, rather than forever being equal to whatever b * 2 was at the time of the statement.

When we take this idea and apply it to user interfaces, we eliminate the DOM manipulation drudgery that dominates web developers’ lives.

Ractive.js is a new library initially developed to create interactive (hence the name – not to be confused with Reactive.js!) news applications at theguardian.com. It is designed to dramatically reduce the effort involved in creating web apps by embracing these principles.

This is a short post collecting some helpful debugging tools built into Ember or how you could easily implement some yourself.

You should include these few lines of code in every Ember App. I learned about those lines in the Blog of Ian Petzer. This snippet logs all exceptions that are thrown when resolving or rejecting promises. If you do not include this snippet, all exceptions will be swallowed silently and may leave you very irritated...

It is quite often that you will start your app and see no exceptions in the console, but you won’t see the desired result in the browser also. How to go about this? There may be a minor error in your template or the connected controller does not carry the right data. How to analyze this kind of error? As the Ember Contributors deeply care about usability, they are developing an extension for Chrome, which facilitates this kind of debugging. With this extension you can inspect DOM elements with one click and see the associated View and Controller. You can already install this extension, but it is not officially released yet. Alternatively you can mirror this functionality manually in the browser console. How to do that?

Ember Data has ambitious goals, and it has come a long way in the last year. If you’re the kind of programmer who loves working on upcoming stuff, you might find it exhilarating. On the other hand, it is completely understandable if you’d want to avoid it. Deprecations and changing APIs can be frustrating and time consuming.

One thing that is not always clear to people starting with Ember is that Ember works perfectly well without Ember Data! Trust me on this: Discourse doesn’t use Ember Data for persistence and it’s working quite well. Moreover, using AJAX with Ember is something that is not difficult to do.

There are many cross platform mobile development solutions, but which one should you choose? I have some answers to this question which will help you decide

I’ve published courses for Pluralsight on:

• MonoTouch (Xamarin.iOS)
• Mono for Android (Xamarin.Android)
• PhoneGap
• Appcelerator Titanium
• Native Android Development
• Native iOS Development
• MonoGame (Cross platform game development)

After working with all these different solutions and investigating others, I thought I would publish my thoughts on each of these choices and the differences between them.

I’m mostly going to focus on Android and iOS because even though there are other competitors, those are the only major players that exist at present.  Everyone else has a relatively tiny market share.