JavaScript for Line of Business Applications

I'm building a simple pimple application - and that sentence right there should scare me :). A blog engine should be simple but there are so many concerns - it's overwhelming!

Which is precisely why we're going to focus on one thing at a time.

When thinking about a blog and what it does - well you can break it into a number of smaller parts:

* The CMS Bits (Articles, versioning, etc)

* The Web/CSS (Serving pages, look and feel)

* The Admin site (dig it)

* API stuff (RSS etc)

That's how I would break it out, at least.

I love clean code. There, I said it. I pride myself on passing strict linting standards and keeping my code easy to read. It's not just a personal proclivity, but a choice I hope benefits other developers.

My general experience with teams has been that code style is something people care about and have strong personal preferences. Typically, at some point people get tired of dealing with inconsistency and a standardization meeting is called. This is, of course, an important discussion to have. The problem that tends to occur is either lack of documentation or lack of enforcement of the agreed upon style. Additionally, new team members or contributors may not have access to a clear set of rules.

Beyond the challenge of defining rules lies the supreme annoyance of enforcing them. Code reviews become cluttered with nits to be picked. Time is wasted. The solution I settled on was simply automating the conformance process.

I set forth to solve this problem:

Establish coding standards that are clearly defined and automatically verifiable.

Javascript is so much fun, except when it’s not.

There’s always the fear of runtime errors that keeps us thinking all the time while writing code. It makes us better coders - we have no other option than to visualize every line of code as if it’s running as we write it.

That’s why it’s so important to have tidy code. Small code. Pretty code. Code you just fall in love with. Otherwise, Javascript will scare you away.

I gathered some fun snippets I enjoy using instead of boring code that takes too much space. Some makes the code shorter, cleaner and more readable. Other are just plain hacks for debugging.

I learned all of this from open source code (until node.js all javascript code was open source, wasn’t it?), but I’ll write them here is if I invented them.

Thomas Herrmann discusses the advantages, challenges and lessons learned in building a multimedia-heavy, interactive HTML5 application with Ember.js.

In this episode I take you through the process of adding structure using RequireJS. Rather than take you through it in real time (the process of me converting it all would not have made great viewing), I walk you through the code after I've made the changes and explain how it works.

* Part 1: Set up Express, Mongo and our first route to show all books

* Part 2: Set up a route for viewing a single book and did some tidying of our codebase.

* Part 3: Create a route so new books can be added via a POST request.

* Part 4: Setting up Backbone and creating a model for our books.

* Part 5: Adding Backbone views and rendering data to the frontend.

* Part 6: Adding structure with the Backbone Router

* Part 7: Adding a route for viewing an individual book

Angelina Fabbro, Bill Mills call developers to help scientists progress in their research, providing advice, a project and a JavaScript tool that could be the starting point in this endeavor.

One of the beauty of the AngularJS framework is its ability to isolate complexity with services and directives; This is perfect for segmenting our code, create very testable components, and make them reusable. A directive, which is an anticipation of the future web components, is a piece of isolated javascript, HTML and CSS that encapsulate a specific behaviour and that you can easily reuse in various apps. Once created, a directive is simply invoked by adding it to the DOM via a HTML tag (<accordion></accordion>, or a custom attribute <div accordion></div>, or a CSS class <div class="accordion"></div> (and even as HTML comment).

Lightstreamer enables several forms of real-time messaging and is flexible enough to be used in any scenario, including mission critical applications.

Before we could release the visual layer, we had to release a common layer of utilities we shared across our whole library. The idea of a second project, to host the various utilities, was born... Following closer, came the idea to isolate the logging infrastructure in its own project and to also publish our testing framework. In the end, we had 4 projects to publish.

Let me introduce the various libraries to you:

* The toolkit

* The logger

* The test framework

* The visual layer

his time I want to show you how to write tests for your Ember.js application, using the Konacha gem.

Basically, Konacha is a Rails engine which allows us to test the Javascript code from our Rails application with the Mochatest framework and Chai assertion library.

This post is focused on Ember.js + Rails web applications.

* Setup
* Running specs
* Spec Helper
* DSL
* More customization
* Testing Routes
* Testing Controllers
* Integration Tests
* Filtering the tests

We will be adding 3 Layer to implement Authorization in our app* UI manipulation (Showing or hiding part of the screens based on the user permission)* Routing ( When the user access a route that he doesn’t have permission to will redirect him to an error  route )* Http Interceptor (We will Setup an interceptor that will check when the server returns 401 or403  and will redirect the user to an error route)

First thing we want to get all the user permissions before loading our app (more like a resolve but for every route) then we will store it (using a service) then for showing/hiding sections of our app that require special permissions we will use a directive for that, after that when we define a route we will add an extra parameter “permission” and give it a value for the permission that it requires then after that we will test in a routeChangeStart event to check if the user has permissions for that route (if any), lastly we will set an http interceptor & read the respond status codes if its  401 or403 we will redirect the user to an error page

Its a long list, so lets get starting

I’ve recently been working on a small application in AngularJS which will be eventually destined for mobile platforms. Now, I’ve been wanting to get a decent log-in flow for Node happening for a while now; it’s the kind of boilerplate I’m likely to use in a lot of different things. And of course, I want to be able to use the OAuth2 log-in services provided by Facebook, Google et al. A lot of my previous experiments with node and/or angular didn’t require this, and as I try to be prudent with my time it’s always been on the back burner. Until now, that is…