Category Archives: Web Development

Rapid Lo-Dash is now available!

I’m pleased to announce that my newest video series, Rapid Lo-Dash is available for purchase through Packt Publishing.

You can get all the details and view the free sample here: Rapid Lo-Dash

If you’re a JavaScript developer, and you aren’t using Lo-Dash yet, you really need to check it out. It’ll help you write some cleaner, faster, more maintainable code. Don’t believe me? ┬áTake a look at this example, and decide which code you would rather maintain.

var numbers = [1, 2, 3, 4, 5, 6];
var odd_numbers = [];
for (var i = 0; i < numbers.length; i++) {
  if (numbers[i] % 2 == 1) {
    odd_numbers.push(numbers[i]);
  }
}
var numbers = [1, 2, 3, 4, 5, 6];
var odd_numbers = _.filter(numbers, function(num) { 
	return num % 2 == 1; 
});

Rapid┬áLo-Dash walks you through the basics of setting up your development environment, and using Lo-Dash to work with arrays. We’ll see examples of how to use Lo-Dash to work with object, collections, chaining, and get into some basic functional programming concepts.

5.Clean Up Your Code with Lo-Dash Chains

Thanks to the team at Packt Publishing for working with me to create this video series – hope you enjoy it.

Tagged ,

Reactive Manifesto – First Reactions

While visiting the Play Framework website, I noticed a new banner in the top right corner. Perhaps “new” isn’t correct – I’ve been almost exclusively in Node.js and Rails land for the past 6 months, so I might be behind the times on this one.

Screen Shot 2013-11-10 at 10.18.14 PM

Following the links takes us to The Reactive Manifesto. As of December 6, 2013, the manifesto has 3098 signatures, and a quick google search shows that the term is taking off pretty quickly. So, I decided to dive in for a quick read, and see what, if any changes it might suggest for my development style.

This architecture allows developers to build systems that are event-driven, scalable, resilient and responsive…
-The Reactive Manifesto

In General…

  • The manifesto seems to encourage some behaviors that I really like.  For example, event-driven systems are a big part of reactive applications.  As a concrete take-away, I certainly like the idea of using lightweight message queues as a way to decouple event publishers and subscribers.  And while we are at it, let’s stay away from clumsy, closed systems like JMS, and stick to open, Polyglot platforms like RabbitMQ and ZeroMQ.
  • Resiliency.  This is the part of the manifesto that I should probably spend the most time absorbing.  As much as I hate it, I’ve written Node.js apps in the past that would crash the whole server on uncaught errors.  The classic problem of Cascading Failure shouldn’t be nearly so prevalent.  Treating errors as “events” rather than failures makes your app way more resilient.
  • Big servers are for suckers.  I know a few Sys Admins still get their jollies from putting together big iron setups, but all the cool kids are scaling horizontally.  Multi-threaded applications, and the complex, proprietary technology behind them, is less attractive than single event-driven, non-blocking processes.   The Reactive Manifesto, at some level, is a guide for writing distributed systems that are resilient in their software design, but also targeted at the physical resiliency of cloud computing.

With My Java Developer Hat…

  • If you like developing in the Play! Framework, you’ll already like a lot of what the manifesto has to say.  No surprise, due to to fact that Typesafe seems to be the driver behind the manifesto.  In any event, a few obvious features that Play! provides for Reactive Applications
    • Play! (unless you opt-out) runs on Netty.io, a asynchronous, event-driven application server, that supports Non-Blocking io.  The Reactive Manifesto (quite accurately) points out that event-driven applications will remain loosly coupled, and perform better than the syncronous, blocking, multi-threaded apps.

With My Node.js Hat…

  • Node.js developers should sign the manifesto, and be proud of the common ground they can find the with Java/Scala developers using Play!.  The event-driven, non-blocking approach works with the Node.js theory perfectly.  A couple specific things that sync up well
    • Node Streams implement a lot of functionality for fulfilling the “responsive” part of the reactive manifesto.  The current version of streams provides an intuitive interface, good backpressure controls, and resistance against overloads on traffic bursts.  If you are doing IO, and not using streams, you may be missing out on a big opportunity.
    • Callbacks, Queues, Streams, & EventEmitter all provide nice ways to keep your app asynchronous and message driven.

With My Rails Hat On…

  • This one is a little bit harder.  Don’t get me wrong, I’m 100% sure you can write reactive apps using Rails, I just don’t know that the framework encourages it as readily.
  • Unlike Play! or Node, the web server is a little more of a wild card when using Rails. Webrick, Unicorn, Thin, Puma, etc.  To my knowledge, the only one of those that supports non-blocking IO is Thin, but even that is subject to the blocking aspect of Rails.
  • EventMachine has some nice features for writing reactive, event-based ruby apps.
  • I think I’m going to have to stop there, and work on a who separate post re: Reactive Applications in Rails.

Yes, I signed.  While the manifesto smells too much like a marketing tool for Play!/Typesafe, I can’t hate on a good idea.  Read the manifesto, sign it if you like what you read, and leave me some comments if you think I’m way off base on this one.

Screen Shot 2013-11-10 at 11.35.08 PM

Backbone.Validation with Chaplin and CoffeeScript

Any sizable web application needs validation. Doing it yourself is for the birds, so I wanted to incorporate a backbone plugin to help solve the problem. For this example I chose to use Backbone.Validation.

Start with a basic framework. Brunch Application Assembler is a great way to bootstrap these projects. I used Paul Miller’s brunch-with-chaplin skeleton.

brunch new gh:paulmillr/brunch-with-chaplin

To start up the server, type brunch watch –server and go to http://localhost:3333/ in a new browser window. If everything is good, you’ll see this:

Screen Shot 2013-09-06 at 3.25.22 PM

You’ll need a basic application to test out our concept, so we’ll modify the routes and the controller, and add a new view and template to our project.

module.exports = (match) ->
  match '', 'home#index'
  match 'form', 'home#form'
Controller = require 'controllers/base/controller'
HeaderView = require 'views/home/header-view'
FormView = require 'views/home/form'

module.exports = class HomeController extends Controller
  form: ->
    @view = new FormView region: 'main'
View = require 'views/base/view'
Form = require 'models/form'

module.exports = class FormView extends View
  autoRender: true
  className: 'form-view'
  template: require './templates/form'
  events: 
    'click a.validateButton' : "validate"

  initialize: ->
    super
    @model = new Form()

  validate: (e) ->
    @model.validate()
    e.preventDefault()

<form>
  <div>
    <label for="name">Name</label><input type="text" name="name" class="name" />
  </div>
  <div>
    <label for="phone">Phone</label><input type="text" name="phone" class="phone" />
  </div>
  <div>
    <label for="email">Email</label><input type="text" name="email" class="email" />
  </div>
  <a href="#" class="validateButton">Validate</a>
</form>

With that code in place, lets do a quick checkpoint http://localhost:3333/form. We should get an ugly view like this:

Screen Shot 2013-09-06 at 3.50.32 PM

So, we know we want a basic form that can save name, phone, and email. Following the guidelines on the validation docs https://github.com/thedersen/backbone.validation, lets add the rules to our model.

BaseModel = require 'models/base/model'

module.exports = class Form extends BaseModel
  validation :
    name:
      required: true
    email:
      required: true
      pattern: "email"

We’ll also need to add the code to our vendor/scripts folder.

In a perfect world, the @model.validate() call would execute our validation rules. However, in this world, we get a javascript error

Uncaught TypeError: Object # has no method ‘validate’

There is one final step. We need to bind our model to the validation, so add the call in the attach method of our view:

  attach: ->
    super
    Backbone.Validation.bind(@);

Thats it! Full source code for the example is available on github.

Tagged , , ,
%d bloggers like this: