David Stump - Building Programmers Podcast

2017-02-21T00:00:00+00:00

About this Episode

This week, Kevin and David talk about becoming a programmer, fun languages, and the irresistible siren song that emanates from southwestern Ohio. Then they play the hot game “YCombinator Startup or Star Trek: Deep Space Nine Character”. How does David do? Who is Michael Dorn? Tune in to find out!

Please check out all of the other awesome episodes on Building Programmers

Episode Links

Episode Details

February 21st, 2017
35 mins 33 secs

Using Phoenix with Legacy Rails Applications

2016-09-27T00:00:00+00:00

Here’s the situation: I love writing Elixir and Phoenix, but many of my clients have existing legacy Rails applications that have been running in production for years. Doing a full rewrite of all of their systems at once is time-consuming, expensive and potentially dangerous. The best-case scenario would be to gradually add or update small features on their existing application utilizing Phoenix behind the scenes. As more and more of these features get updated, the app slowly transforms from a “Rails App with a little bit of Phoenix”, to a “Phoenix App with a little bit of legacy Rails”. The nice part of this approach is that it is easy to experiment with and gradually make changes without introducing more bugs and degrading the overall user-experience of your client’s application. This way we can add value for our client by leveraging an ecosystem with improved power and performance while avoiding disrupting the application flow that users are already familiar with.

Setup

To get started, we need running Rails and Phoenix apps:

rails new my_app ...
localhost:3000

mix phoenix.new my_new_app ...
localhost:4000

Next, we need an easy way to let our rails app proxy features to our new Phoenix app. For this, I used the gem rails-reverse-proxy. After bundling, I added a basic helper method to my ApplicationController like such:

def proxy_to_phoenix
  reverse_proxy "http://localhost:4000" do |config|
    config.on_missing do |code, response|
      redirect_to root_url and return
    end
  end
end

This method will allow us to proxy an action over to our new Phoenix app, or redirect to our root path (or whatever makes sense for your use case) in the case of a missing path.

Adding a new feature in Phoenix

Now that we have our setup complete, lets add the ability to create basic Posts in our new Phoenix app. To do that, I am going to use a generator to create a basic crud endpoint for posts.

mix phoenix.gen.json Post posts title:string author:string body:text

As instructed by the generator, we need to add this line to our Phoenix routes

resources '/posts', PostController

And finally migrate our Phoenix app up to include the new Post feature

mix ecto.migrate

Great! Now we have a working Post feature that will allow us to perform basic CRUD actions on a Post model and get JSON data back. To have some usable data to demo once we get our Rails app setup to use this new Phoenix feature I am going to add a few dummy posts:

changeset = Post.changeset(%Post{title: "Using Phoenix with Rails", author: "David Stump", body: "Hello, from Phoenix!"})
Repo.insert(changeset)

changeset = Post.changeset(%Post{title: "Another Blog Post", author: "David Stump", body: "I like turtles."})
Repo.insert(changeset)

changeset = Post.changeset(%Post{title: "Even moar Blog Posts", author: "David Stump", body: "Ping Pong"})
Repo.insert(changeset)

Wiring Up Our Existing Rails Application

Now that we have our setup done and our new feature implemented in Phoenix, lets introduce it into our legacy Rails app. To do this, we are going to use the reverse proxy helper we implemented in our Setup section. We will need a controller on the Rails side to handle requests to our new Posts feature.

class PostsController < ApplicationController
  include ReverseProxy::Controller
  prepend_before_action :proxy_to_phoenix

  def index
  end

  def show
  end

  ...

end

In the Rails controller above, there are two unique lines that let this handle our Phoenix feature. First we have the code include ReverseProxy::Controller which imports the basic actions from our reverse proxy gem. Second, we have the code prepend_before_action :proxy_to_phoenix which just tells each method in this controller to proxy to phoenix when a request to that action is received. Finally, our controller has all of the normal restful actions of a traditional Rails controller.

To receive requests to this controller, we are going to need to add it to our Rails routes:

resources  :posts

And we are all set!

It’s Alive!

If we navigate to our various restful post paths in our Rails app, we will now see the appropriate JSON response coming from our Phoenix code through our existing Rails application. We have successfully introduced a new post feature using Phoenix and Elixir into our legacy Rails application. To an outside viewer, this feature looks just like any other output from our Rails app. As stated in our initial goals, this allows us to gradually introduce Phoenix into existing applications in a much slower and more deliberate fashion. (click to enlarge GIF)

Optional: ActiveRecord

As a followup, I thought I would demonstrate one possible approach for introducing interactions to these new Post records via Rails and ActiveRecord. To allow both applications to connect to the same data store, I entered the same MyApp credentials into the Rails database.yml as well as the Phoenix dev.exs. Once both applications were referencing the same data, I added a generic Rails model like so:

class Post < ActiveRecord::Base
end

Once that model is in place, I can fire up a Rails console and perform the following query:

> Post.count
=> 3

> Post.first
=> #<Post id: 3, title: "Using Phoenix with Rails", author: "David Stump", body: "Hello, from Phoenix!", inserted_at: ..., updated_at: ...>

Awesome! Now we could interact with Phoenix created Posts from our existing Rails code should the need arise.

But wait, you say, what about having two models with full control over the posts table in the database?? Good Point! What we need to do is to tell Rails that it is only allowed to read the posts table, and is forbidden from making any changes. We want to make sure Phoenix is the owner of that table, and all Rails can do is reference the data if it needs. To do this, we are going to update the Post model we created in Rails to this:

class Post < ActiveRecord::Base
  after_initialize :readonly!
end

Now, if we attempt to create Posts from the rails side, we get a stern talking to from the database:

> Post.create(inserted_at: Date.today)
  (0.2ms)  BEGIN
  (0.4ms)  ROLLBACK
  ActiveRecord::ReadOnlyRecord: Post is marked as readonly

Conclusion

The strategy outlined in this articles is far from the only one, however, it provides us with a clean way to slowly integrate new features with Phoenix into an existing Rails application. This allows us to leverage all of the power, speed, fault tolerance and concurrency of Elixir without first needing to convince a boss or client to undertake a time-consuming, expensive and potentially risky full rewrite of your application. We can now quickly add powerful, fast and concurrent features to our applications today. That’s awesome :)

As always, I am more than happy to add or update sections of this article as people respond with suggestions, experiences and feedback.

Cheers!

Phoenix Beyond the Browser - ElixirConf 2016

2016-09-02T00:00:00+00:00

Audience

Elixir/Phoenix developers with an interest in iOS/Swift development

Summary

Leverage the Elixir and Phoenix foundation of concurrency, speed and reliability toward making powerful realtime applications in Swift

Description

Elixir and Phoenix are built on a foundation of concurrency, speed and reliability. Thinking beyond the browser, these features are ideal for the backbone to any successful mobile application. Together we will explore leveraging the powers of Phoenix and WebSockets to get started building realtime mobile applications in Swift. Along with a basic introduction to Apple’s (relatively) new language Swift, we will explore how to setup a mobile application to communicate with a Phoenix application in realtime using Phoenix Channels. We will also discuss the impacts of some of the newer Phoenix features, like Presence, and how these can be used to enhance your applications. Attendees will get a brief introduction to the basics of iOS development, explore how to easily connect Phoenix and iOS applications through WebSockets, and discover how to use the power of Elixir and Phoenix to create complex realtime applications and games.

How to Send Email From Your Phoenix App in Under 5 Minutes

2015-06-08T00:00:00+00:00

Sending scheduled or automated emails from your application is a very common problem with a number of solutions. In this write-up I am going to demonstrate one particularly easy approach to adding email functionality to your Phoenix App. Phoenix is a web framework written in Elixir that is enjoying a meteoric rise in popularity recently. Many people are jumping onto the Phoenix bandwagon for its explicit, non-magical and functional approach to development.

For this demonstration, we are going to use an external library that integrates Mailgun into our Phoenix application. Phoenix includes the Elixir configuration file mix.exs which we will use to add our new dependency. We will add {:mailgun, "~> 0.1.1"} to the list of “deps” our project is currently using.

defp deps do
  [{:phoenix, "~> 0.13"},
   {:phoenix_html, "~> 1.0"},
   {:phoenix_ecto, "~> 0.3"},
   {:postgrex, ">= 0.0.0"},
   {:phoenix_live_reload, "~> 0.4"},
   {:cowboy, "~> 1.0"},
   {:mailgun, "~> 0.1.1"}]
end

Running mix deps.get from our terminal will pull in all required files for including our new Mailgun library dependency.

$ mix deps.get
Running dependency resolution
Dependency resolution completed successfully
  mailgun: v0.1.1
* Getting mailgun (Hex package)
Checking package (https://s3.amazonaws.com/s3.hex.pm/tarballs/mailgun-0.1.1.tar)
Using locally cached package
Unpacked package tarball (/Users/david/.hex/packages/mailgun-0.1.1.tar)

Now we need to setup our Mailgun configuration in config/config.exs. First, however, you will need to jump over to http://mailgun.com and sign up for a free sandbox account. Once you are logged in, you will want to add your first domain (under the Domains tab in the top navigation). Once created, you can click on this new domain to view the API Base URL and API Key. We will need to add both of these values to our config file. In your config.exs add the following information:

config :my_app, mailgun_domain: "YOUR_MAILGUN_DOMAIN",
                mailgun_key: System.get_env("MAILGUN_API_KEY")

Next we need to create a Mailer module to use throughout our application. In your lib directory, create a new file named mailer.ex (not required - just my preference). Within that new file you will need to define our new Mailer module and reference our Mailgun client and configuration information.

defmodule MyApp.Mailer do
  use Mailgun.Client, domain: Application.get_env(:my_app, :mailgun_domain),
                      key: Application.get_env(:my_app, :mailgun_key)

end

You will generally add a module attribute specifying the from address of your application emails within the Mailer module.

@from "noreply@mydomain.com"

Finally, we add simple functions to handle the html and text versions of our application specific emails.

def send_welcome_text_email(email) do
  send_email to: email,
             from: @from,
             subject: "Welcome!",
             text: "Welcome to MyApp!"
end

def send_welcome_html_email(email) do
  send_email to: email,
             from: @from,
             subject: "Welcome!",
             html: "<strong>Welcome to MyApp</strong>"
end

Once we have our email functions complete, we are ready to send emails throughout our Phoenix app.

MyApp.Mailer.send_welcome_html_email(user.email)

And thats it!

Helpful Tips:

Attachments

Should you want or need to send attachments along with your email it is equally simple. All we need to do is add an attachments key to our email and provide it with a list of maps that respond to path and filename. The Mailgun library we are using handles reading the actual file so long as we give it a valid path.

def send_welcome_html_email(email) do
  send_email to: email,
             from: @from,
             subject: "Welcome!",
             html: "<strong>Welcome to MyApp</strong>",
             attachments: [%{path: "priv/my_file.csv", filename: "my_file.csv"}]
end

Templates

You will most likely want to write your markup for an HTML email outside of the Mailer module. This is extremely easy to accomplish. You will want to update the text of your email to point at an external view. This would look like:

html: Phoenix.View.render_to_string(MyApp.EmailView, "welcome.html", some_var: some_var),

Congratulations. You can now send emails throughout your Phoenix application. For more information please check out the following sources:

Cheers!

Swift Extensions

2014-06-06T00:00:00+00:00

This past Monday, Apple made a shocking announcement. They are moving forward without Objective-C. After the murmuring lessened, Apple went on to demonstrate an attractive, clean and expressive new language called Swift. Once the Taylor Swift jokes had subsided, the developer community seemed genuinely excited about this new look for iOS development. More information about the new language can be found on Apple’s site.

Over the past year I had begun digging into iOS development and learning Objective-C. While the thrill of seeing something you built on your iPhone was enticing, every time I started playing with it again, I was reminded how little enjoyment I got out of writing Objective-C. As someone not intimately familiar with the language, Objective-C proved hard to digest, write and understand each time I hopped back into Xcode. Sadly, without any other option for iOS apps, your only option was to keep trudging on. Monday changed that.

During the announcement on Monday, my eyes lit up with the prospect of a clean and easy-to-grasp language to ship applications on iOS and OSX. With that, I dove into the WWDC Videos and full length book available for free on iBooks to learn as much as I could about this new and attractive language. Coming from Ruby, I loved what I saw: optional parenthesis, no semicolons and concise, expressive code. To give you a sense of the improvement I saw my first steps into Swift, here is a basic “Hello, World!” app written in both Objective-C and Swift:

Objective-C

  #import <Foundation/Foundation.h>

  int main(void)
  {
      NSLog(@"Hello, world!\n");
  }

Swift

  import Foundation

  println "Hello, World!"

Like the first time I experienced Perl after being a Java developer years ago, I was hooked.

One of the first powerful features in Swift I started to enjoy playing with were Extensions. Extensions, similar to monkey patching, allow you to add new functionality to existing structures such as classes, structs, or enumerations. As a rubyist, my first experiments have been focused on bringing some of the joy I get from using ActiveSupport helpers to my iOS development space. An example of a basic extension to add the ability to uppercase a string with uppercase instead of the more verbose uppercaseString is as follows:

  extension String {
    var uppercase: String { return self.uppercaseString }
  }

This makes the following valid Swift syntax and instantly adds this method to Xcode’s autocomplete and syntax highlighting.

  var name = "David"
  name.uppercase # "DAVID"

To try my hand at a somewhat more technical extension I decided to add the helper method times to the Int class in Swift. To do this, I needed to define a function times that accepted a function as a parameter and executed it as many times as defined by the initial Int value.

  extension Int {
    func times(task: () -> ()) {
        for _ in 0..self {
            task()
        }
    }
  }

Using this extension my Swift code begins to look very familiar…

  5.times {
    println "Hello, World!"
  }

  # Hello, World!
  # Hello, World!
  # Hello, World!
  # Hello, World!
  # Hello, World!

Finally, before admitting defeat and going to sleep, I added a few helpers onto the Array class to bring some rubyisms to Swift.

  extension Array {
    var first: T { return self[0] }
    var second: T { return self[1] }
    var forty_two: T { return self[42] }
    var last: T { var last = self.count - 1; return self[last] }
  }

  var things = [1, 2, 3, 4, 5]
  things.first # 1
  things.second # 2
  things.last # 3
  things.forty_two # Answer to The Ultimate Question of Life, the Universe, and Everything

Cheers!

Fun with Variants and Enums in Rails 4.1

2014-04-21T00:00:00+00:00

The release of Rails 4.1 this past week included some cool new features two of which are the introduction of enums and variants. Enums give us some syntatic sugar for handling attributes like status, role, etc. Variants allow us to handle separate types of templates from within a respond_to block on a given action. I setup a tiny Rails 4.1 application to demonstrate one possible use for these two new features.

Enum

This application has a basic user model with a name string and an email string. The users controller contains basic index and show actions to show a list to users and their respective details. In the user model, I included an enum attribute role to handle differentiating between users of different types (student, admin or staff). The basic way of defining an enum attribute is as follows:

enum role: [:student, :admin, :staff]

However, with enums used in this fashion, order must always be maintained or you risk recasting your users with a new role unintentionally. Suppose, months later, a new developer comes along and adjusts the code above like so:

enum role: [:golfer, :student, :admin, :staff]

We have now, inadvertanly, cast every user previously assigned with the role :student to :golfer. Oops.

For this reason I would most likely use explicitly defined enums to avoid any potential future mishaps:

enum role: {student: 0, admin: 1, staff: 2}

In this example, even if my new developer friend stumbles across this and updates it, they would have to explicitly overwrite the role associated with a given integer to cause any harm.

Once I have my enum defined, I now have access to all kinds of goodies to use throughout my application. I can now easily determine a given users role:

user.role # => "student"

I can easily determine if a user is a member of a particular role:

user.student? # => true

I can quickly assign/update a user’s role:

user.staff! # => [sql] true

Or see all of the users scoped to a particular role:

User.staff # => #<ActiveRecord::Relation []>

Variants

Variants can be used within a respond_to block to handle the same action in separate ways. Using the User model from above, we can render a show page unique for a particular user’s role.

def show
    @user = User.find(params[:id])
    request.variant = @user.role.to_sym
    respond_to do |format|
        format.html do |html|
        html.student
        html.staff
        html.admin
        end
    end
end

In this example, the variants of the show action such as html.student will render a view template with the name matching: show.html+student.haml (or erb if you prefer). This allows us to use the same logic from our show action but render different content/layouts. This pattern could also be used to present different templates for mobile devices, webviews inside native mobile apps, etc.

With very little additional code, enums and variants allowed me to add a very basic role engine to my application and render content unique to a user’s role. These are just two of the fun new updates released in Rails 4.1. Check out the Release Notes for some additional reading.

Cheers!

How to Use Angular and Keep Loving Rails

2014-02-21T00:00:00+00:00

I love writing Ruby and I love using Rails. So when I started looking for a client-side framework to help organize my front-end process and code, I was cautious of frameworks that demanded I abandon my “Rails Way” and adopt their process, style, and approach. I was looking for a framework that added value to my “Rails App”, not a solution that wanted Rails to instead act as a compliment to my client-side app.

Enter Angular stage left.

But wait, you say, tons of Angular apps use Rails (or any other framework) as a backend api for their purely client-side application. Yes, you would be very correct, however, unlike numerous other client-side frameworks, Angular allows me to easily and quickly sprinkle it on top of my traditional Rails app if that’s my preference.

CAVEAT - This article is only meant to demonstrate how I stayed a happy, healthy Rails developer while still enjoying all the advantages Angular provides. If, in your heart, you want nothing more than to make purely client-side apps every day, then more power to you for being focused. Thanks for reading this far - and please accept my token of thanks.

My happy-place with Angular and Rails is to let each framework do what it’s good at and then move aside. For Rails, it is well suited to handle routing, helpers and primary application logic. For Angular, it is best suited to handle client-side interactions, dynamic bindings, ajax requests and presentation logic. Using this approach I can stay away from so many headaches caused by Angular routing, Rails remote linking and endless arbitrary jQuery listeners.

Once I had settled on an approach to co-existence of Angular and Rails, my next obstacle was the somewhat verbose and obscure Angular syntax.

CoffeeScript Sanity

Personally, I love using CoffeeScript (through that is in no way required to enjoy Angular on Rails) and my first step in incorporating Angular into my daily Rails flow was to get a handle on some of the more obtuse Angular syntax in favor of the CoffeeScript class approach.

The first step was to create a base class (NGObject) to handle basic dependency injection. This class iterates through the array of dependencies passed via the class @$inject variable and creates an instance variable with the same name. This gives us the ability to easily reference scope, services, etc passed into our angular object by friendly means (@scope, @Thing, @ThingSvc, etc). Once the dependencies are handled, the NGObject class will check for an init() function and call it if one exists.

class @NGObject
    constructor: (dependencies...) ->
        for dependency, index in @constructor.$inject
            @[dependency.replace('$', '')] = dependencies[index]
            @init?()

Next, I use that NGObject base class to build a variety of other classes to handle specific angular object types such as NGController, NGService, etc. Each of these classes exposes a register function that wires up our object to the correct angular application. During object construction, we take the attributes of a given object (controller, service) and apply them to the proper scope. This allows us access to the attributes and functions of any object in the view layer.

class @NGController extends @NGObject
    @register: (app) ->
        app.controller "#{@name}", this

    constructor: (@scope) ->
        @scope[key] = value for key, value of this when !@scope[key]?
        super

Specifically for service objects, we setup an NGService object that implements event notifications allowing controllers, directives, etc to register callbacks for specific service events. In the service, whenever desired, you can call the

notify function and inform all registered observers that the specific event occurred.

class @NGService extends @NGObject
    @register: (app) -> app.service "#{@name}", this

    observableCallbacks: {}

    on: (event_name, callback) ->
        @observableCallbacks[event_name] ?= []
        @observableCallbacks[event_name].push callback

    notify: (event_name, data = {}) ->
        angular.forEach @observableCallbacks[event_name], (callback) ->
            callback(data)

We use an event_name for each event type which adds the ability to sanely register and call multiple events explicitly as so:

handleEvent: -> notify 'my:event'

MyService.on 'my:event', -> doStuff()

Included in my Rails projects, this helper allow me to write concise and legible angular code in my preferred CoffeeScript class syntax. Here is a short example of a rewritten Angular controller with the new syntax and format:

class CalendarCtrl extends @NGController
    @register window.App

    @$inject: [
        '$scope',
        'Calendar',
        'Panel',
    ]

    init: ->
        @config = @Calendar.config()

Is there anything explicitly problematic or wrong about the verbose traditional Angular syntax? Absolutely not! Does this syntax make me a happier developer and allow me to get my code out the door quicker? Without a doubt. Setting up this syntax was a fun endeavor and my hope is it makes at least one other developer’s life happier!

Rails Resource To The Rescue

One of the last remaining hurdles to quick and easy angular development with rails is wiring up Rails resources with Angular. One source of frustration is Angular’s handling (or lack thereof) of nested resource parameters. Here are a few recent GitHub issues as examples of that frustration fix(ngResource): Add support for nested params and Query params not serializes as expected. Thankfully, Angular uses a modular approach to resource handling, so swapping ngResource with a different library is a breeze.

After months of massaging the flat params from Angular in my Rails controllers, I stumbled across Rails Resource. Rails Resource is a promise based resource module that handles Angular resources exactly as a default Rails application would expect. With very little code, we can wire up Angular with our Rails resource and be on our way.

As an example, I have a basic Rails app with a model Beer that

belongs_to a Brewery. To wire up Angular with these resources using Rails Resource I could write an Angular factory such as:

App.factory "Beer", ['railsResourceFactory', 'railsSerializer', (railsResourceFactory, railsSerializer) ->
    resource = railsResourceFactory
        url: "/beers"
        name: "beer"
        serializer: railsSerializer ->
            @nestedAttribute 'brewery'
    ]

This code creates an Angular resource ‘Beer’ and maps it to the appropriate endpoints in our Rails application. Our next step is to setup the association with the Brewery model. You can see this done above with the following lines:

serializer: railsSerializer ->
    @nestedAttribute 'brewery'

The serializer in Rails Resource looks to be quite powerful in allowing you to both specify relationships and alter the json coming and going to resource endpoints. The factory we have created above sets up a Beer resource in Angular that

accepts_nested_attributes_for a Brewery resource. With only the code demonstrated above, the parameters sent to the logs on a create action (for example) are just what Rails expects and is handled easily by a traditional Rails create action.

Started POST "/beers" for 127.0.0.1
Processing by BeersController#create as JSON
Parameters: {"beer"=>{"name"=>"Goose Island IPA", "description"=>"Hoppy Goodness",
            "brewery_attributes"=>{"name"=>"Goose Island"}}}

The Result

During this article I have described three tools I use to make me a happier Rails developer leveraging the power of AngularJS in my applications:

Letting each framework handle what it’s good at
The CoffeeScript helper that allows me to write more concise code in a syntax I enjoy
A resource module that wires up Rails resources with ease

Using these methods I setup a very basic CRUD Rails application on Githubdavidstump/beers. With the exception of the factory shown above, the only Javascript required was a short and sweet Angular controller:

class BeersCtrl extends @NGController
    @register window.App

    @$inject: [
        '$scope',
        'Beer'
    ]

    init: ->
        @loadBeers()

    loadBeers: ->
        @Beer.query().then (results) =>
            @all = results

    create: ->
        new @Beer(@newBeer).create().then (results) =>
            @loadBeers()

    destroy: (beer_id) ->
        @Beer.$delete(@Beer.resourceUrl(beer_id)).then (results) =>
            @loadBeers()

This style of Angular fits seamlessly into my familiar mental model formed from my time developing Rails applications and ultimately makes me a quicker, happier and healthier developer.

I would love any and all feedback (and Pull Requests) on both these approaches as well as the NGHelper library itself. Thank you for taking the time to read through my thoughts and happy coding!

Cheers!

Simple Touch Events in CoffeeScript

2013-05-06T00:00:00+00:00

I am an avid fan of simple, clean and elegant CoffeeScript (and thus JavaScript of course). On top of your code being more approachable, I love the sense of accomplishment when I find a clean way to solve a problem without immediately jumping to an external library or plugin. Thus, when I was faced with the problem of handling touch events on handheld and tablet devices for our new site, I started with a blank page in my favorite editor.

Touch.coffee is a simple and straightforward CoffeeScript class written with pure JavaScript that emits touch events to your application. The only dependency this class utilizes is EventEmitter to aid in handling the event triggers. The full source for this class is available for browsing on GitHub

To get our class started, we will setup a few variables that will help us along the way.

@Touch=
    horizontalSensitivity: 22
    verticalSensitivity: 6
    touchDX: 0
    touchDY: 0
    touchStartX: 0
    touchStartY: 0

The sensitivity variables allow us to specify how long a touch event should last before we go ahead and emit our event to the rest of the application. This helps us differentiate between a swipe style gesture versus a simple tap. The next two variables will help us gauge the distance travelled during our touch event. Finally, the last two will let us store the starting point of our event.

bind: (elements...) ->
    for elem in elements
        elem.addEventListener "touchstart", (event) =>
            @handleStart(event, elem)
        elem.addEventListener "touchmove", (event) =>
            @handleMove(event, elem)
        elem.addEventListener "touchend", (event) =>
            @handleEnd(event, elem)

First we want to add a bind method to our class to attach the appropriate touch events to whichever DOM element (or elements) specified. This method handles one or more elements and attaches the touchstart, touchmove and touchend events and delegates the appropriate handler methods for each type.

handleStart: (event, elem) ->
    if event.touches.length is 1
        @touchDX = 0
        @touchDY = 0
        @touchStartX = event.touches[0].pageX
        @touchStartY = event.touches[0].pageY

Once we have the events attached to the correct elements, we need to tell our class how to handle the various event types along the way. Here we store our initial values once the touch event is initially registered.

handleMove: (event, elem) ->
    if event.touches.length > 1
        @cancelTouch(elem)
        return false

    @touchDX = event.touches[0].pageX - @touchStartX
    @touchDY = event.touches[0].pageY - @touchStartY

Next we need a method fired during the portion of the touch event where our finger is moving across the screen. During this event we want to detect if another touch event is registered and reset our listeners to avoid complications. We also want to update our two variables tasked with telling us the distance our touch event has travelled.

handleEnd: (event,elem) ->
    dx = Math.abs(@touchDX)
    dy = Math.abs(@touchDY)

    if (dx > @horizontalSensitivity) and (dy < (dx * 2 / 3))
        if @touchDX > 0 then @emitSlideRight() else @emitSlideLeft()

    if (dy > @verticalSensitivity) and (dx < (dy * 2 / 3))
        if @touchDY > 0 then @emitSlideDown() else @emitSlideUp()

    @cancelTouch(event, elem)
    false

Once a touchend event is triggered and the gesture is complete, we need to gather the total distance travelled both horizontally and vertically. Once we have these values, we can use our sensitivity variables to determine if the distance of the event is great enough to warrant emitting to the rest of our application. We can also use the positive or negative value of our difference/distance variable to indicate the specific direction of our event and emit the correct notification.

emitSlideLeft: -> @emit 'swipe:left'
emitSlideRight: -> @emit 'swipe:right'
emitSlideUp: -> @emit 'swipe:up'
emitSlideDown: -> @emit 'swipe:down'

Finally, once we have successfully registered a touch event and determined that it passes our sensitivity threshold set initially, we need to emit the correct event to our application. Using EventEmitter we can easily send out the proper event notification with very little code.

With our new touch class, we can now bind touch events to any elements in our application.

Touch.bind document.getElementById('menu')

Once we have our bindings set, performing actions based our touch events is as easy as calling a method when a touch event is detected.

Touch.on 'swipe:left', => @toggleMenu()

While this class certainly doesn’t handle every possible interaction on a handheld or tablet device, it does provide you with a great base for handling basic touch events throughout your application with very little code. I welcome and look forward to any and all feedback, suggestions and improvements and hope this little class proves helpful!

Cheers!

Use Git to Manage Your Time

2013-02-10T00:00:00+00:00

Donec eget ex magna. Interdum et malesuada fames ac ante ipsum primis in faucibus. Pellentesque venenatis dolor imperdiet dolor mattis sagittis. A gem that uses your git commits to manage a Freshbooks timesheet

As an extension to my git-based timesheet I wrote about at the beginning of the year, I went ahead and setup a self contained gem with some additional features. The gem, mytime, can be found at: rubygems.org/gems/mytime as well as github.com/davidstump/mytime for your browsing pleasure.

The mytime gem uses your git commit history, in the same manner as the timesheet alias did, to pull a log of your daily activities. Once you have this daily history, you can tell mytime to ‘push’ all of your commits as a timesheet log to Freshbooks using their API. Additionally, you can ‘submit’ custom timesheet entries to Freshbooks as needed.

MyTime Documentation

Use your git commit history to track your time. Uses Freshbooks API.

Installation

Add this line to your application’s Gemfile:

gem 'mytime'

And then execute:

$ bundle

Or install it yourself as:

$ gem install mytime

Usage

To link to your Freshbooks account (you will need your Freshbooks username and API token):

$ mytime setup

To initialize mytime in a project directory:

$ mytime init

To see project details:

$ mytime project

To list log:

$ mytime status

To submit custom time entry:

$ mytime commit [hrs] [custom_message]
$ mytime commit  1.5 "Add an additional note if desired"

To push your git logs from today for a given project:

$ mytime push [hrs]
$ mytime push 4.5

I would love some feedback and/or pull requests to extend this little gem to include other timesheets, features, etc. I made this to help myself keep track of my daily commits per project, but hopefully it helps out a few others along the way. Thanks for reading!

Cheers!

A Better Fullscreen Experience in Sublime

2013-01-15T00:00:00+00:00

While I love coding with my editor in fullscreen mode, I also enjoy having apps such as Campfire or Rdio accessible on another monitor. One complaint I have had with the default OSX fullscreen mode is that it causes a second monitor to show nothing but the grey textured spaced background. I was thrilled the other day when I discovered a feature in Sublime that allowed me to use a “simple” fullscreen mode which behaves differently than the standard OSX mode. If you add the following to your Sublime preferences:

"use_simple_full_screen": true

Using the Enter Full Screen shortcut will allow you to have nothing but your code on one monitor and still use your second monitor for whatever apps your heart desires. Simple preference edit that has made my work flow that much better.

Cheers!