<![CDATA[GhettoCo.de]]> 2012-07-29T01:19:37-04:00 http://ghettoco.de/ Octopress <![CDATA[Creating angularjs services in coffeescript]]> 2012-07-28T23:26:00-04:00 http://ghettoco.de/blog/2012/07/28/angularjs-services-in-coffeescript For my latest personal project, MicBooker, I’ve decided to go with the AngularJS framework. In a very short amount of time, I’ve been able to get further, faster with Angular than I have with any of the other MV* javascript frameworks I’ve tried. Nothing against the other frameworks, it just seem they’re all changing and improving so rapidly that the documentation isn’t keeping up.

So far, I’ve found Angulars docs to be much better and they even have several screencasts and tutorials to help you get up-to-speed quickly. That said, I did run into my first issue that caused me a bit of head-scratching. It took me a couple of hours of experimentation to implement custom services and filters in Angular.

In case you’re having similar problems, here’s a brief outline of what worked for me.

First, I load the vendored angular files using the pipeline. I also load my micbooker file where I create my app’s module and register it with Angular.

app/assets/javascripts/application.js
1
2
3
4
5

...
//= require angular-1.0.1/angular-1.0.1.min
//= require angular-1.0.1/angular-resource-1.0.1.min
//= require micbooker
...

Create my app module and make it available globally. I’m injecting the ngResource module, as well, which we’ll need for the RESTful resource later.

app/assets/javascrips/micbooker.js.coffee
1
2

MicBooker = angular.module('MicBooker', ['ngResource'])
(exports ? this).MicBooker = MicBooker

Now that I can access my application module from other parts of the app, here is an example of creating a filter. This filters an array, returning an array of only those objects whose status is “confirmed”. (I’m using underscore.js’ filter method. It’s a great convenience library. Check it out.)

app/assets/javascripts/angular/filters/spots.js.coffee
1
2
3
4

MicBooker.filter('confirmed', ->
  (inputArr) ->
    return _(inputArr).filter( (element) -> element.status == "confirmed")
)

And the thing that really drove me nuts was creating a service. ngResource already provides a nice interface for interacting with a back-end restful service. But if you want to DRY up your app, you’ll want to create a wrapper so you don’t have $resource constructors all over the place. I won’t bore you with all the things I tried. But here’s what finally worked for me:

app/assets/javascripts/angular/services/spot_assignment.js.coffee
1
2
3
4
5
6
7
8
9
10

MicBooker.factory('SpotAssignment', ['$resource',
  ($resource) ->
    $resource('/users/:user_id/spot_assignments',
      {user_id:gon.current_user.id},
      {
        query: {method:'GET', isArray:true},
      }
    )
  ]
)

Using my service in a controller would look something like this. Notice that I’m injecting into the controller the SpotAssignment service I created above.

app/assets/javascripts/angular/controllers/spots_ctrl.js.coffee
1
2
3
4
5
6
7
8

class SpotsCtrl
  constructor: (@$scope, SpotAssignment) ->
  $scope.spots = gon.spots

  $scope.refreshSpots = ->
    SpotAssignment.query( (result) ->
      $scope.spots = result.spots
    )

And finally, using everything we’ve built in the html markup would look something like this:

1
2
3
4
5
6
7
8
9

<html lang="en" ng-app="MicBooker">
  <head></head>
  <ul class="unstyled">
    <li ng-repeat="spot in spots | confirmed">
      Comic: 
    </li>
  </ul>
  <%= link_to 'Refresh', '#', "ng-click" => "refreshSpots()" %>
</html>

We’re using our custom filter to show only confirmed spots. And the refresh link uses ng-click to set the clickHandler to refreshSpots() which in turn uses our $resource wrapper to load the spots from the server. If the array of spots has changed, angular’s data-bindings will take care of updating the UI for us. Slicker than snot on a glass door-knob, eh? If you’re in the market for a JS framework, I suggest kicking the tires on Angular. And if you do, hopefully this little writeup will help you avoid the minor speed-bumps I ran into.

]]> <![CDATA[Y'all cray]]> 2012-04-27T16:20:00-04:00 http://ghettoco.de/blog/2012/04/27/yall-cray Technically, I currently work for a well-established company. Workforce-wise, they’re not huge but their operations are significant. Couple that with the fact that they deal primarily with banks, and it’s no surprise that their process is very “enterprisey”. Luckily, I don’t “really” work for that company. I’m the CTO of a much smaller “startup” that’s being seeded by the owner of said larger company.

It’s so funny to talk with the C# and Java developers from the parent company because they just don’t “get” how we work. For instance, testing. We’ll be consuming their services via a SOAP API (I said they were enterprisey). Today, one of their devs came by my office to talk to me about the various error conditions and codes in their API. Some of them will be newly created in their system specifically for how we’ll be using the system. The developer assured me that they’d get them implemented as soon as possible so I can start to test my logic for handling them.

I told him not to worry and assured him that as long as the service will match the specs, then I can start writing and testing my code before they get finished building it.

“But how can you test hitting our service if it’s not built?”

“Oh, I could do it a bunch of ways but I’ll probably just stub out the calls with webmock or something. Even after the service is built, most of our tests won’t actually hit the service anyway unless I delete the VCR cassettes.”

blink blink…stare…what…I don’t…did he just say VCR cassettes?

As he was walking away, I swear I heard him whisper under his breath, “That dude’s crazy”.

One of these days, I hope get a minute to sit down with those guys and show them how we run tests. Until then, I guess we’ll just have to live with being those crazy kids down the hall.

]]> <![CDATA[Bootstrapping Design]]> 2012-03-20T12:05:00-04:00 http://ghettoco.de/blog/2012/03/20/bootstrapping-design I can’t count how many times I’ve started a new project, wireframed it, built it, and then had the whole thing fall apart when it came time to do the work of actually finishing the design. Usually, it’s a personal project that, while you hope others may find some value in it, it’s not a money-making venture. So I don’t want to spend much on it.

That means I definitely don’t want to pay a designer. Nothing against designers. I’m in awe of them and the products they produce. I just can’t justify the cost of a good designer for a pet project that even I’m going to be over in a couple of months. And if I’m going to use a not-so-great designer, I may as well do it myself.

That’s why I was intrigued by Jarrod Drysdale’s new ebook, Bootstrapping Design. It’s a design book specifically targetd towards developers and aims to help us make our projects suck less. It states up front that it’s not going to make us world-class designers, but it will provide enough knowlege so we can DIY our projects design and do a good enough job to at least do justice to the hard work we’ve put into the functionality itself. I’m down with that.

I initially balked at the price. I can get an ebook and a hard-copy from somewhere like Pragmatic for $39! But I continued on and downloaded the sample pdf. Fonts! Choosing fonts is exactly where I usually get completely overwhelmed with design. There are so many choices. And rules, rules I don’t know. But I do know people make fun of you if you break the rules. So I read through the sample chapter and now I think after a few more readings, I can safely pick fonts for a new project and not have to worry about my designer friends having to say, “bless his heart”, behind my back.

So I’m excited to read the rest of what this ebook has to offer. If it helps my next project keep a designer from screaming and kicking a puppy, it’s worth it.

]]> <![CDATA[Paperclip defaults and the Asset Pipeline]]> 2012-03-19T14:28:00-04:00 http://ghettoco.de/blog/2012/03/19/paperclip-defaults-and-the-asset-pipeline The latest stable version of Paperclip hasn’t yet been updated for the Asset Pipeline. This only affects the default image which is served if no file has been uploaded for the attached asset. If you’d like your default “missing” images served from image assets in the pipeline, configure the default_url like this:

app/model/foo.rb
1
2
3
4
5

class Foo < ActiveRecord::Base
  has_attached_file :avatar,
    :styles => {:small => "300x300>", :thumbnail => "80x80#"},
    :default_url => ActionController::Base.helpers.asset_path('missing_:style.png')
end

Now just put your default images –in this case missing_original.png, missing_small.png, and missing_thumbnail.png– into the directory app/assets/images and they’ll be used as the default images for your model.

Of course, you can also place the files somewhere under the public directory to allow your webserver to serve the file directly. This makes sense if you’re using local storage for the files. You don’t want to put the uploaded files or their derivatives in the asset pipeline since they are static files and won’t need any of the preprocessing that the pipeline offers. But if you’re using Amazon S3 or another storage system for uploaded files and want to keep your limited image assets together in your app codebase, now you know how.

]]> <![CDATA[Multiple Asset Pipelines]]> 2012-03-18T14:04:00-04:00 http://ghettoco.de/blog/2012/03/18/multiple-asset-pipelines I’m working on a project that needs both mobile and web interfaces. We’re building the mobile interface with Sencha Touch and the web version with good ol’ jQuery.

I setup the app for mobile similar to Ryan Bates’ Mobile Devices RailsCast. This allows us to serve different views to the client depending on whether or not the device is a mobile device.

But what about the javascript and coffescript? We’re going to need different behaviour on the client side depending on which view is rendered and I want it all to take advantage of the Asset Pipeline. So I decided to try and make a parallel asset pipeline so I can do something like this:

“app/views/layouts/application.mobile.erb”
1
2
3
4
5
6

<head>
  ...
  <%= stylesheet_link_tag    "mobile", :media => "all" %>
  <%= javascript_include_tag "mobile" %>
  ...
</head>

And have Sprockets build the coffescript, javascript, and css the same as this:

“app/views/layouts/application.html.erb”
1
2
3
4

  ...
  <%= stylesheet_link_tag    "application", :media => "all" %>
  <%= javascript_include_tag "application" %>
  ...

I decided to create an asset structure under app/assets/mobile to house the javascripts, stylesheets, and images for the mobile app. Then, I added those directories to the Sprockets search path.

“config/application.rb”
1
2
3

%w[javascripts stylesheets images].each do |dir|
  config.assets.paths << Rails.root.join("app", "assets", "mobile", dir)
end

mobile.js first require’s Sencha Touch and then requires all of the coffeescript and javascript under in the app/assets/mobile/javascripts directory.

“app/assets/javascripts/mobile.js”
1
2

//= require sencha-touch-all-debug
//= require_tree .

Similarly, mobile.css requires all the files under the strylesheets directory structure:

“app/assets/stylesheets/mobile.css”
1
2
3
4

/*
 *= require_self
 *= require_tree .
*/

Now we’re ready to require the mobile.js and mobile.css in our mobile layout and have a clean seperation of the javascript and css between the mobile and web versions of our app.

]]>