IthacaTech Podcast - Episode 1 Interview with Casey Dreier

Direct link

Episode 1 is out!  In this episode we interview Rails developer Casey Dreier.  Casey is a lead Ruby on Rails developer and evangelist at SingleBrook Technology, Inc. in Ithaca, NY.

We discuss Ruby, Rails, Casey’s recent Rails bug fixes, the James Webb Space Telescope, and our thoughts on fostering the Ithaca developer community.

We’ve upgraded to some new-fangled audio equipment, so look forward to improved audio quality (and maybe production skills to match in the future).

Please send feedback, suggestions, and angry screeds to podcast@incandescentsoftware.com.

- Aaron

Links:

• Ruby Rogues podcast
• Ruby blocks, procs, and lambdas
• James Webb Space Telescope funding in the air
• “Ithaca Web People” Google group.  If you are in Ithaca and you do (web) development, and you are a person, sign up and check out our meetups and hackfests!

Our new audio setup, thanks to Linux Outlaws for details on their production process 

• Behringer B1 condenser mic
• Behringer MIC100 mic pre-amp
• Behringer UCA202 audio interface
• MacBook built in microphone uber alles

And thanks to people giving us weird looks as we blithely tested our equipment. <3

Podcast info

• Theme song by Brad Sucks, Flouride (demo).
• RSS feed: http://feeds.feedburner.com/incandescentsoftware/IthacaTechPodcast

Jasmine is a behavior-driven development framework for testing JavaScript from Pivotal Labs (I believe Rajan Agaskar was/is the original author). I’ve been using Jasmine for a while now to test my JavaScript code. Today I ran into interesting situation where I wanted to test events bound to jQuery element. Basically by writing code like this:

1
2
3

$('#el').bind('click', function (e) {
  // handler code goes here
});

I wanted to know if element $(‘#el’) had any events attached to it. I looked around but couldn’t find any predefined matchers in jasmine or jasmine-jquery to accomplish it. I realized that it’s pretty easy to extend jasmine and define my own matchers (which is pretty cool). Here is how you can do it:

First create your new matchers:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

var eventMatchers = {
  toHaveEvent: function (event) {
    var data = jQuery.data(this.actual.get(0));
    for (obj in data) {
      if (data.hasOwnProperty(obj)) {
        for (eventName in data[obj].events) {
          if (data[obj].events.hasOwnProperty(eventName)) {
            if (event === eventName) {
              return true;
            }
          }
        }
      }
    }
    return false;
  }
};

Then in your spec add your matchers inside beforeEach:

1
2
3
4
5

describe("Element", function () {
  beforeEach(function () {
    this.addMatchers(eventMatchers);
  });
});

That’s it! Now you can use your new matchers inside your spec. In this case I was able to use it like this:

1
2
3
4
5
6
7
8
9
10
11
12
13

describe("Element", function () {
  beforeEach(function () {
    this.addMatchers(eventMatchers);
  });

  describe("when event attached", function () {
    it("should contain attached event", function () {
      setFixtures("<div id='el'></div>");
      $('#el').bind('click', function () {});
      expect($('#el')).toHaveEvent('click');
    });
  });
});

Introducing the IthacaTech Podcast!

Direct link (see below for show notes)

This is something we’ve wanted to do for a while - start an Ithaca-based tech podcast.  Michal and I are always coming across exciting new projects and technologies and we’d like to create a venue for sharing those discoveries and discussions with others, and, conversely, learning from others in the area.

We are aiming for a local focus - we want to highlight local business, events, music, etc.  To that end we are looking for:

• web and other software developers in the area that want to talk about what they are working on
• local music we can showcase or use as bumpers
• topic and segment ideas, send them in!
• feedback and corrections

If you have suggestions for podcast topics or would like to get involved with the podcast, let us know at podcast@incandescentsoftware.com (or just email us directly :).

Note: in the spirit of DIY, we are learning as we go. :) This first episode is pretty rough since we wanted to get our first show out there ASAP, so please excuse the audio quality!

- Aaron

Episode 0 - “The Rough In” Thurs. 6/16/11 Show notes

Today Michal discusses JavaScript frameworks and Aaron explains the Fork/Join pattern.

JavaScript frameworks discussed:

• http://microjs.com/
• http://documentcloud.github.com/backbone/
• http://angularjs.org/
• http://knockoutjs.com/
• http://www.sproutcore.com/
• http://awardwinningfjords.com/2011/05/09/javascript-microframeworks-and-the-future.html

Fork/Join links

• http://en.wikipedia.org/wiki/Fork-join_queue
• http://gee.cs.oswego.edu/dl/papers/fj.pdf
• http://download.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html
• http://www.coopsoft.com/ar/CalamityArticle.html

Local links

• http://www.topographymarketing.com/ (thanks for letting us use your space guys!)

Podcast info

• Theme song by Brad Sucks, Flouride (demo).
• RSS feed: http://feeds.feedburner.com/incandescentsoftware/IthacaTechPodcast

A few people have asked me lately about books and other resources related to JavaScript. I’ve decided to list them here for reference. 

JavaScript Books:

There are many books about JavaScript. Some of them are better than others. Here is a list of books I read and recommend:

1. JavaScript: The Good Parts by Douglas Crockford  
2. Eloquent JavaScript: A Modern Introduction to Programming by Marijn Haverbeke 
3. JavaScript patterns by Stoyan Stefanov
   
4. Essential JS Design Patterns by Addy Osmani 
    

Blogs about JavaScript:

1. http://javascript.crockford.com  by Douglas Crockford (a lot of interesting topics)
2. http://dmitrysoshnikov.com/ by Dmitry Soshnikov (fantastic overview of ECMA-262 implementation and more)
3. http://perfectionkills.com/ by kangax (exploring javascript by example)
4. http://javascriptweblog.wordpress.com/ by Angus Croll (a lot of JS topics usually with great examples)
5. http://www.adequatelygood.com/ by Ben Cherry
6. http://ejohn.org/category/blog/ by John Resig
7. http://mir.aculo.us/ by Thomas Fuchs
   
   
   

Websites about JavaScript:

1. JavaScript Garden: http://bonsaiden.github.com/JavaScript-Garden (this is a good resource but please also see the feedback about it here)
2. DailyJS http://dailyjs.com (every day you can see what’s new in JavaScript world)
3. JavaScript Weekly http://javascriptweekly.com
4. Annotated ECMAScript 5.1 http://es5.github.com
5. Badass JavaScript http://badassjs.com

Mailing Lists:

1. JSMentors: http://jsmentors.com (discussion of JavaScript, mentoring, code reviews)

Client-Side JavaScript Frameworks and Tools:

Frameworks come into many flavors (monolithic, hybrid, micro) and different people advocate for different approaches. You can read more on the topic here: http://mir.aculo.us/2011/04/11/i-for-one-welcome-our-new-micro-framework-overlords/ and here: http://tomdale.net/2011/04/imagine-a-beowulf-cluster-of-javascript-frameworks/ and choose your side or just use the best tool for the job :).

1. Backone.js http://documentcloud.github.com/backbone/ (model centric, evented based)
2. Spine http://maccman.github.com/spine
3. MicroJS http://microjs.com (collection of small tools and libraries)
4. Sproutcore http://www.sproutcore.com (version 2.0 is more a hybrid approach)
5. EmberJS http://emberjs.com
6. ZeptoJS http://zeptojs.com (micro framework which follows jQuery API and targets mobile webkit)
7. KnockoutJS  http://knockoutjs.com (Model - View - View Model approach)
8. Angular http://angularjs.org (another hybrid with some interesting patterns behind it)

Online JavaScript Tools:

1. JSFiddle http://jsfiddle.net (a playground for web developers)
2. JSLint http://www.jslint.com (The JavaScript Code Quality Tool)
3. JSHint http://jshint.org 
4. JSONLint http://jsonlint.com (JSON validator)
5. jsPerf http://jsperf.com (JavaScript performance playground)

So there you have it. I’ve been collecting these materials for a while now. This list is not set in stone and I’m curious if you found some other resources worth mentioning. I’m collecting a similar list related to Node.js and CoffeeScript which I may share in the future.

- michal

As our computing environment and needs change, certain programming styles and patterns which are less effective recede and others which are more applicable rise in popularity. As these previously implicit patterns are identified and discussed they are ascribed proper names.

“Fork/Join” is one of these patterns which is gaining prominence. It refers to both a simple and ubiquitous concept (intuitive enough that you probably hadn’t thought to name it) and a very specific and narrow implementation of that concept.

Small-f “fork/join” is a general approach to parallelizing a decomposable task. The main task is decomposed into many sub-tasks that can be run independently, these tasks are then run in parallel on multiple threads (forks), and the main task waits (joins) for their completion before proceeding. This can be easily implemented with existing concurrency frameworks such as Java’s Executors facility:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

List<Callable<Output>> callables =
  new ArrayList<Callable<Output>>(inputs.size());

for (Input i: inputs) {
  callables.add(new Callable() {
    public Output call() {
      // do some work here
      return output;
    }
  });
}

// following call performs the fork and join
List<Future<Output>> futures
  = EXECUTOR_SERVICE.invokeAll(callables);

On the other hand, Fork/Join also refers to a specific application of the “fork/join” pattern which has been proposed by Doug Lea for inclusion in Java 7: http://gee.cs.oswego.edu/dl/papers/fj.pdf

Going back to our previous fork/join example, note that in a generic implementation tasks will be run on independent threads which will typically block on a single task queue. When the number of threads scales up, and the size of tasks scales down, lock contention on this queue becomes problematic.

The Fork/Join implementation that Doug Lea proposes is aimed at a very specific (I would say narrow), but possibly very common case: parallel algorithms which do not block. When a purely cpu-bound algorithm is parallelized, there will be high contention on any shared queue. The Fork/Join implementation deals with this by using an alternate queuing arrangement call “work stealing”. Instead of all threads pulling from a shared (and contended) queue, each thread has its own dedicated (mostly uncontended) task queue (a deque). Only when a given thread runs out of tasks will contention occur - it will attempt to “steal” a task of the end of another thread’s queue.

The hierarchical (and possibly cyclical) decomposition of tasks, and execution of tasks via a “work stealing” arrangement is what is referred to by “Fork/Join” proper.

There is at least one critique of Fork/Join’s inclusion in Java 7 which seems well reasoned to me: http://www.coopsoft.com/ar/CalamityArticle.html. I for one remain skeptical that this implementation will produce significantly better results than the simpler “fork/join” pattern with a standard thread pool and shared queue, to outweigh the cost in implementation and conceptual complexity. However Doug contributed the Executors framework to start with, so he certainly knows his concurrency.

If you’re like me then hopefully the above explanation has cleared up the term “Fork/Join” and distinguished the-pattern-i-was-using-all-along from the very specific framework/library proposal for Java 7.

Having performed numerous customizations of third party or upstream/vendor applications based on the Spring framework, I’d like to share some patterns I’ve identified. These patterns form a hierarchy based on preferability - if it is not possible to implement one approach you may have to back off, and try the next best, repeating in stepwise fashion. I am going to list them from least preferable to most preferable in order to walk you through the rationale behind each approach.

We will assume an application distributed in binary form, containing a Spring context with a service interface com.sample.ApplicationService and implementation com.sample.ApplicationServiceImpl defined as an “applicationService” bean which we want to override with some local customization.

Direct class override

The simplest and most direct approach is to simply create a new class named com.sample.ApplicationServiceImpl and arrange for it to appear in the classpath before the upstream implementation. If you have no other options (or are simply prototyping or debugging something) then this might work for you, but it cannot be considered much more than a hack.

There are numerous problems with this approach. First, while it may initially be superficially possible to contrive a classloader chain which results in your implementation being picked up first, this is brittle and may lead to very confusing results when it breaks in the future. You will either be duplicating the service implementation by copying and pasting, or otherwise lying about the pedigree of this class. This will certainly make debugging harder, and will also convey an immediate maintenance overhead. Imagine upstream diverging from the base you forked - you will now have to continually reconcile any future changes to upstream (this may not phase users of decentralized version control systems but is certainly endless and error-prone tedium when working with central SCM like SVN). If you hoped to submit your customizations for inclusion upstream, then overriding the class directly may complicate acceptance. If behavior has changed, tests may fail. Or the change may be rejected because it is not suitable as a default for all users.

A better approach would be to implement a separate class and submit this implementation as an alternative (with tests specific to this implementation of course).

Explicit context inclusion

In order to supply an alternate implementation, you will need to override the service bean defined in the application’s Spring context (let’s assume there is such a bean defined). Unless the application has provided some way for you to inject a context to override this bean you are still in the first situation: having to directly override a file (the Spring context this time) relying on classloader precedence. Let’s assume the application has implemented a specific provision for you to specify your own Spring context for inclusion. It may look like this:

1
2
3
4
5
6
7

String customContext = System.getProperty("customContext");

if (customContext == null) {
  context = new ClasspathApplicationContext(DEFAULT_CTX);
} else {
  context = new ClasspathApplicationContext(new String[] { DEFAULT_CONTEXT, customContext });
}

In this situation you can construct a Spring context which redefines the application bean by name (“applicationService”) and supply the context via a system parameter:

1

-DcustomContext=MySpecialCustomization.xml

However this requires explicit, programmatic, support by the application.

Automatic context inclusion

A better approach for the application to implement is to take advantage of Spring’s resource syntax to import a wildcard resource expression. For example:

1

<import resource="classpath*:com/sample/*Customization.xml">

If placed in the application’s context, this expression will cause the import of any contexts matching the glob “com/sample/*Customization.xml” in any classloader without any additional coordination between application and implementer.

The “classpath*:” syntax tells Spring to look in all classloaders. See Spring’s documentation for a better understanding of classpath resource expressions:

If using Maven, for example, simply adding an additional dependency containing the customization (e.g. “com/sample/MySpecialCustomization.xml”) to your project is sufficient to implement the override.

One theoretical downside is that it may be expensive for Spring to iterate through classloaders looking for matching contexts. This is complete speculation on my part, and given the maintenance burden and complexity of the other solutions, it is probably worth a (startup) performance penalty.

Missing bean definition

The above approaches will not work (directly) if you encounter the following situation: You wish to override a class which is not defined as a bean. It is likely this class itself is used (eventually) by a service, which means you need to walk the caller hierarchy to find affected services, and then resume with the above approaches on those services. You will need to override the services, providing implementations (ideally shallow subclasses) which override the minimal number of methodsnecessary to replace invocations of the old class with your new class.

For bonus points, make the aforementioned class injectableas a Spring bean, and submit this enhancement upstream. This will allow you to migrate your customization to a simple bean and throw away your unnecessary wrapper classes/beans.

AOP magic

With the approaches discussed so far, you ultimately still have to replace an entire service. If the application has been modularized sufficiently then this may not be a concern. However, it may be the case that replacing an entire service is heavy-handed, or that the functionality you need implemented is not necessarily best done by replacing a service implementation.

In these situations there is another trick up our sleeve. We can wrap the existing implementation bean with a Spring AOP (Aspect Oriented Programming) aspect. For example we can surgically override a single method on a large interface. Or we can apply common logic to all methods (e.g. caching). We can secretly mutate method arguments and return values. In some situations this is much more convenient than overriding a service (imaging having to override a large service simply to change arguments and delegate to the wrapper service…).

While this is the most loosely coupled approach, there are several downsides. First, AOP can be hard to understand and maintain. Secondly, AOP can complicate debugging as errors can now occur “between” known call frames, and behavior introduced dynamically via AOP will not be obvious to the external observer. Lastly, AOP can only be applied to services defined as beans.

For details on Spring AOP see:

Conclusion

Well, despite the lack of code examples I hope that this post has been helpful. I may in the future construct a sample case that illustrates each of these approaches, and the amount of “maintenance” overhead they impose.

To sum up, I’d like to conclude with:

Direct class overriding: JUST DON’T DO IT

Automatic context inclusion: PLEASE implement this provision if you are writing an application or service in Spring which you anticipate users having to customize

We have some exciting news! First, Couchbase the company behind couchdb published a case study about the Menagerie Whiteboard (Thank you Couchbase :)). Our solution is built entirely in JavaScript and HTML5 (the Couchbase guys are calling this approach ‘couchapps’) and it’s served directly from couchdb. It means there is no need for the traditional backend. Our JavaScript code is based on the wonderful Backbone.js library.

The second piece of exciting news is that we just released a new version of the whiteboard which now works on iPad (check our demo here). We redesigned the UI and changed few things around to support the iPad platform.

We plan to write more about our experience and technical challenges we encountered on the way so please stay tuned.

We’ve received a few requests about mobile app development in the past few weeks. We were looking for different options and wanted to use something which could be written once and used on different devices including iOS and Android. We found two solutions: one called Titanium Mobile and another one called PhoneGap. If you are wondering what the differences between them are, you can read more here.

We decided to stick with PhoneGap for now mostly because it looked simpler to start with. PhoneGap provides a set of project templates and a common JavaScript API for building “native” mobile applications. It supports iOS, Android, Blackberry, Symbian, and Palm. The JavaScript API allows for interaction with the native API’s for things like contact management, camera, GPS and other.

In our previous projects we used a lot of JavaScript. Our code was structured around a great tool called Backbone.js. We also used a lot of jQuery. We wanted to bring this experience to our mobile solution and decided to give jQuery Mobile a try. As a proof of concept we created a simple project called Happy Pointer.

The app makes use of the data coming from awesome SimpleGeo and it’s integrated with Google Maps. It basically searches for things near you. (it searches for coffee places by default).

You can find the code for the app on github here: https://github.com/incandescent/happypointer or check the demo. jQuery Mobile is very easy to learn. You don’t have to write any JavaScript to start with something simple. It comes with numerous useful widgets and components. In order to use them you have to add a “data-role” to your html elements. For example if you want to render a button you can do:

1

<a href="index.html" data-role="button">Link button</a>

or lets say you want a list:

1

<ul data-role="listview"></ul></pre>

Overall we think PhoneGap and jQuery Mobile are great solutions for people who already have experience with web technologies and don’t want to fight with Android or Cocoa Frameworks. We plan to write more about our experience with Backbone.js and more about our adventures with mobile development in the future so please stay tuned.

Linode is a great VPS/Cloud provider and we use it to run a development/testing machine and a production MongoDB server. It also has an easy to use REST API which, unlike Amazon EC2, requires only an access key and no complicated X509 configuration. There is a nice Ruby library for this API on github: https://github.com/rick/linode

We use Puppet to manage node configuration once a node is provisioned (and this is cloud-provider agnostic), however provisioning the node requires use of the particular cloud provider’s API and this is where the library above comes in. There are libraries like libcloud that provide an abstraction layer that works with many cloud providers - using the Linode API directly made the most sense for us.

The Ruby Linode library above exposes the Linode API directly, and it is fairly low level (no model of the node, config, etc.). Since (re)provisioning requires successive interactions with the same Linode instance, as well as a notion of a static configuration which can be applied to the node, it’s nice to have a higher level model of the virtual machine. We created a small library which wraps the Linode API and adds a couple of abstractions. You can find it here on GitHub:

https://github.com/incandescent/linode-utils

This linode-utils gem provides a simple model of a Linode Machine, as well as a small Linode configuration DSL.

Machine operations:

• boot
• reload
• shutdown
• get_disks
• delete_disks
• delete_non_swap_disks
• delete_configs
• used_disk_space
• create_disk_from_stackscript
• create_config
• wait_for_job

Here is how we (re)provision a Linode instance:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

api = Linode.new(:api_key => api_key, :username => username, :password => password)

LinodeUtils::LOG.info "Looking for linode named '#{name}'"

LINODE = Machine.new(api, name)

LinodeUtils::LOG.info "Current linode status: " + LINODE.linode.status.to_s

if LINODE.linode.status != Linode::TERMINATED
  LINODE.shutdown
end

LinodeUtils::LOG.info "Deleting non-swap disks"
LINODE.delete_non_swap_disks

LinodeUtils::LOG.info "Deleting configs"
LINODE.delete_configs

root_disk_id = LINODE.create_disk_from_stackscript({
  :size => LinodeUtils::MAXIMUM_DISK_SIZE,
  :distro => DISTRO_LABEL,
  :stackscriptid => STACK_SCRIPT_ID,
  # stack script options
  :root_pub_key => pub_key,
  :fqdn => hostname
})

config_id = LINODE.create_config(KERNEL_LABEL, root_disk_id)
LinodeUtils::LOG.info "Booting Linode..."

LINODE.boot(config_id)

(this is the interesting bit; the full script is about twice as large but the rest is mostly setup and argument parsing)

There is also a small DSL for constructing the Linode “config”. Here is an example:

1
2
3
4
5
6
7
8

config = LinodeUtils::LinodeConfig.build LinodeUtils.init_api do
  label "My favorite config"
  kernel /Latest 2\.6 Paravirt(?!.*x86_64.*)/
  comment "first comment"
  disk 0, :root_device => true
  comment "second comment"
  disk 1
end

After implementing this automation for Linode, I think we could probably easily move to another service. The basic steps are the same:

1. provision an instance - this requires selecting or building an OS image, and ensuring a root SSH key is installed
2. install a first-boot script to perform config/bootstrapping (how this is implemented differs to some degree from service to service)
3. ssh as root to execute any commands required to finish bootstrapping (if you have a configuration server that is known to the bootstrapped node then this step can be eliminated)

On that note, stay tuned for future posts on bootstrapping a node with Puppet+Git, how to use Hudson and a “stable branch” Git methodology for continuous integration with Rails, and our foray into CouchDB-based desktop apps.

Small businesses have it tough. They do not have the advantages of economies of scale that larger companies do, but are at the same time more reliant on word of mouth and personal networking to market their business. When it comes to a web presence, small business owners are often stuck in the realm between purchasing a pricey custom-built web site, or going it alone with a Do It Yourself tool and spending their time navigating the intricacies of web development and social media instead of running their business.

We think small business owners could use a no-hassle service which allows them to easily create a web presence integrated with popular social media outlets out of the box.

So with that said, we’ve launched the closed beta of our new product, Whizpage!

If you are a small business owner, feel free to sign up and try it out. We are launching early and building features based on user feedback. We’d love to hear from you!