Jeff Lembeck learns a code or two

Serious code business!


On May 31st of 2012, I proposed to the wonderful Racheal Bellinger. Since that point, we have been planning for our upcoming March wedding and its accompanying honeymoon. It didn't take long for us to settle on the location of Paris, France and to start planning the trip.

Now, my experience with traveling to France has been a mixed bag so far. I have been twice and learned something very quickly about the French: they're a lot like Americans. The stereotypes of rude and arrogant people are only true if that is what you're looking for and you are far more likely to encounter that abrasiveness if you do not put in the effort to fit in with the culture. That means speaking more of the language than "Parles anglais?" and so began the journey for learning French.

Learning new languages has always been a bit of a fleeting desire for me.

I've tried so far to learn: Japanese, Spanish, Italian, Tagalog, and Chinese without a lot of great success, at least no success in the way that I can carry on a decent conversation. This bothers me, a lot. I find language learning to be an incredibly important skill but I have never been able to make something stick. Part of that has been my inability to focus, which I do when I don't a specific goal in mind; part of that has been the learning methods. There just hasn't been a lot that has clicked for me. Enter Duolingo.

Duolingo is a free language learning web application that I have been using for the past few months to pick up French. I spend about an hour a day (or however long it takes for me to get past 100 skill points) going through the exercises and it's making an imprint in my head. It has a mix of translation, listening, and speaking pieces that make up individual lessons. On top of that, it has timed practice sessions where you can pick up more skill points and review what you've been learning. I go through three lessons and then the practice sessions until I hit my goal for the day and call it good there. Concepts are starting to stick and the lessons and larger sentences are getting easier, so I plan on writing a bit on the subject of learning French for the upcoming months. Hopefully I can stick with it. Writing more is also a bit of a fleeting desire for me.

A New Chapter Begins

It is with incredible pride and excitement that I announce I have accepted a position with Filament Group. To say that this is a dream job would be a huge understatement, as I get to join the masters in contextual web on their journey to make the internet a better place to be.

If you haven't seen their work, check out the first major responsive web site The Boston Globe or maybe the jQuery Mobile framework.

JRuby + Sinatra, All Warred Up

Today's lesson is in how to: create a JRuby project with Sinatra, structure it in a nice and maintainable way, and wrap it into a war file so it can use your legacy Java code.

This lesson will assume you have RVM installed and are using JRuby 1.6.7. For the deployment instructions, it assumes you have Tomcat (6 or above) installed.

We'll go through this step by step, including the very mundane.

Step 1: Create directory and move into it.

$ mkdir samplewar
$ cd samplewar/
(I told you some of this would be mundane)

Step 2: Create .rvmrc (rvm config file for your project) that will allow you to pick the version of ruby that you want (In this case, JRuby 1.6.7) with its own specific Gemset. This is so you'll keep your gems sandboxed. I find this to be a solid practice when building projects that any noob might stumble into halfway through. Lastly, make sure that you're using Ruby version 1.9. It's the future and the present of Ruby, and it will be the default in the upcoming 1.7 version of JRuby, so get used to it.

$ mvim .rvmrc
In the .rvmrc, -
rvm use --create jruby-1.6.7@samplewar
export JRUBY_OPTS=--1.9

Step 3: Create primary app file. In this, you'll start the process of building a modular Sinatra application.

:tabe sample_app.rb
require 'sinatra/base'

class Sample < Sinatra::Base get '/' do "Hello World" end end

Step 4: Sweet. You've gone and created an app. Let's download the necessary stuff to wrap this up in a war. First, let's create our Gemfile.

source :rubygems

gem 'sinatra' gem 'warbler'

Don't forget to install Bundler to make this work.
$ jruby -S gem install bundler
Fetching: bundler-1.1.3.gem (100%)
Successfully installed bundler-1.1.3
1 gem installed
Then install your gems.
$ jruby -S bundle install
Fetching gem metadata from
Installing rake ( 
Installing jruby-jars (1.6.7) 
Installing jruby-rack (1.1.4) 
Installing rack (1.4.1) 
Installing rack-protection (1.2.0) 
Installing rubyzip ( 
Installing tilt (1.3.3) 
Installing sinatra (1.3.2) 
Installing warbler (1.3.4) 
Using bundler (1.1.3) 
Your bundle is complete! Use bundle show [gemname] to see where a bundled gem is installed.

Step 5: Good deal. Now let's configure Warbler to make sure the .war file loads properly. Create the configuration file.

$ mkdir config
$ jruby -S bundle exec warble config
cp /Users/jlembeck/.rvm/gems/jruby-1.6.7@samplewar/gems/warbler-1.3.4/warble.rb config/warble.rb
Open the configuration file and configure that thing.
$ mvim config/warble.rb 
Details on how best to tune this can come later, but for right now, that file is REALLY well documented, and we'll probably have to come back to it as we build out the project.

Step 6: Next up, create your Rackup file.

$ mvim
And put this data in it. 'sampleapp' is a reference to the main app filename. Sample is the class that is inheriting from Sinatra::Base and is therefore the name of the modular application.
root = File.dirname(FILE)
require File.join( root, 'sampleapp' )
run Sample

Step 7: Let's do our first customization of the warble.rb file now. We don't have any folders yet, so configs.dir can be cut out.

# Application directories to be included in the webapp.
config.dirs = %w()
Meanwhile, we DO have a solo file we'd like to include.
# Additional files/directories to include, above those in config.dirs
 config.includes = FileList["sampleapp.rb"]
Also, aren't we running this in Ruby 1.9 mode?
# Set JRuby to run in 1.9 mode.
  config.webxml.jruby.compat.version = "1.9"

Step 8: Let's give this a whirl and build that war now.

$ jruby -S bundle exec warble
rm -f samplewar.war
Creating samplewar.war
And there you have it! You've created a JRuby war file. Now, if you want to deploy it to your local Tomcat to give it a spin...
$ mv sample_war.war /srv/tomcat7/webapps/
$ /srv/tomcat7/bin/ 

And check it out at http://localhost:8080/sample_war. You should see this:

In things that are bad ass that I've found on the internet lately, here is a post on how to do Python's SimpleHTTPServer: ruby's “python -m simplehttpserver”

I've been using it ever since.

The meat of this is to install rack (sudo gem install rack), throw the code into a rackup file

#!/usr/bin/env rackup
#\ -E deployment

use Rack::ContentLength

app = Dir.pwd
run app

And have fun.

Thanks, SAMSON WU.

Also, hey, watch this thing grow:

Require.js, Backbone, and jQuery Mobile Part 1

I've spent some time over the last year or so working on mobile web applications, and each time I do, the separation of the client and the server becomes greater. It's getting far too easy for me to put something together with a thick, rich client and to use Sinatra or Node to build a nice RESTful API.

When moving this logic to the front end, code organization becomes paramount to the success of your application. I've been digging into the Asynchronous Module Definition (AMD) API. As stated in the wiki, AMD:

specifies a mechanism for defining modules such that the module and its dependencies can be asynchronously loaded. This is particularly well suited for the browser environment where synchronous loading of modules incurs performance, usability, debugging, and cross-domain access problems.


A great tool to use for this purpose is Require.js.

Let's roll up our sleeves and dive into this. We'll start by downloading the sample:

Now, let's look at the Alternate Integrations in there. Since we're going to eventually bring this together with jQuery Mobile, we're going to need to make sure it and jQuery load before any other scripts (yes, it's a huge bummer, but it's the best way to prevent FOUC.

Open app.html, and make the change: Change the source of the script tag to "scripts/require.js" (make sure to download this from Require.js.

    baseUrl: 'scripts',
      paths: {
          "jquery": "",
          "jquery-mobile": ""
      priority: ['jquery', 'jquery-mobile']
  }, ['main']);

Now, open up scripts/main.js and change to this:

require(["jquery", "jquery-mobile", "jquery.alpha", "jquery.beta"], function($) {
    //the jquery.alpha.js and jquery.beta.js plugins have been loaded.
    $(function() {
      var $body = $.mobile.activePage;

Get this running in your local webserver (might I suggest and test it out.

Getting this all connected with Backbone will come in step 2.

Photo Share app

I wrote a photo sharing app at one point using Java and JRuby + Sinatra + MySQL. It never felt quite as fast as I'd like it to be. Tonight I started kicking it out in Node.js with pretty phenomenal results. The real difference seems to be coming from having non-blocking IO with the AWS client.

I plan on hooking it into a db soon. As for now, though, it can be found: here.

My Time at South By

One of the things that working at UIEvolution affords me is the ability to travel to conferences with the purpose of learning what's new in technology and meeting and conversing with some of the best minds in the business. This March, I was bestowed the gift that is South By Southwest.

South by South Southwest (SXSW) is a conference held yearly during March in Austin, TX. It's a week long and focuses on what is new and hot in the fields of Technology, Film, and Music. It packs the streets of the capital of Texas with tech celebrities, musicians, filmmakers, foodies, and a strong marketing push for all of the above.

The technical talks given at SXSW read like the UIE playbook. A focus on the connected experience was prevalent, from the Web to Mobile Apps to Auto, there was always a talk or a meetup that focused on something pertaining to what we build. Being the mobile web junkie that I am, this meant an almost overload on stimulus as I ran from panel to panel, focused on acquiring whatever knowledge I could regarding browser development tools, HTML5 APIs, mobile best practices, new advancements in CSS, responsive development, strategies for implementing mobile sites, etc.

When the chance arose, I went to watch one of our partners speak (Michelle Avary of Toyota) on the auto industry's movements into the connected experience. I bubbled with excitement in the third row as she discussed the Entune platform and UIEvolution's role in the process. Soon came the tweets and the discussions. App developers are on the edge of their seat for what's next. They cannot wait for the system to open up and move forward. This was a current that surged through each talk on the future of auto.

The most important theme throughout all of these talks was that there is still so much room for discussion and change. The barrier for entry to be somebody who shapes and builds the technologies that will influence our next generation is: willpower, a hunger for the new, the experience to know when something is better for prototypes than for production, and a well-researched opinion. If that doesn't inspire somebody to create, I don't know what will.