tpitale

Prism.js with Ruby in Github Pages

2013-08-06T13:58:11-07:00

After quite a long time, and quite a few blog posts using gists for embedding code samples with highlighting and the rest, I’m giving something else a try.

I’ve added prism.js and a ruby language extension by Sam Flores.

Here’s the quick and dirty way to add prism.js to your own blog (or in my case, Github Pages).

Add prism.js and prism.css
Add prism.ruby.js
Link to both in your layout

And then just write some code inside <pre><code class=”language-ruby”> tags!

class Cow
  def says
    puts 'moo'
  end
end

Cow.new.says #=> moo

Simple as that! I’m gonna give it a try for a little while. Let me know how you think it looks, and how the code reads for you. Thanks!

How I've Been Running Email Standups

2013-07-31T10:10:40-07:00

Lots of people do standups, but most frequently they're done synchronously; either in-person or over video chat of some variety. After reading this post from the development team at Treehouse on why it might be best to do them asynchronously I decided to try out their ideas with my small team.

As suggested in the blog post, we set up Google Groups. In order to send the email from my own account to kick things off, I had to tweak some settings. First I had to enable sending as the group email from my own account. Then, in order to actually receive my own emails, I had to tweak a setting in Google Groups. See the instructions below.

And of course, since I have stuff to do every day and I'm a "good" developer :-), I automated the sending of the email with a little cron and a ruby script.

All in all, this as been a huge success for us. Our favorite benefits:

reduce this mundane but useful task to something I can do when it's convenient to take the time
do not pull me out of my own work for a standup
do not start other discussions not related to standup
link to PRs, commits, and code in Github directly from the email
it's all logged and searchable by the project/product managers

Lots of win, there. We were happy to find even more reasons to stick with this approach than are given in the initial Treehouse post.

The only downside we could come up with is that we're taking away a time when we get to socialize. But this barely counts. First, we don't want to use the standup time for socializing and building camaraderie. And second, if standup is the only time your team is socializing, you'll want to make an attempt to correct that.

Make it Happen

At a high level, getting it set up involves:

Create a new google group.
Go to settings in your gmail to allow you to send mail as the email for the google group.
Confirm that you have access to that email by clicking the link.
Put the mail script somewhere in your path.
Set cron to trigger it when you would like to have your standup.

Google Group Settings

Inside groups > settings

Information > general information: Allow posting by email.
Information > Content control: Archive messages to the group.
Information > Web view customization: Allow users to highlight code.
Permissions > Posting permissions: Post As The Group should include Owners and Managers

The Ruby Script

standup_email ruby script gist

Personally, I put this in my home directory .bin, and call it with the absolute path. Note: If you have two-factor authentication turned on for your Gmail, you'll need to generate a token to use.

Cron


    0 10 * * 1,2,3,4,5 /bin/zsh -ic '/Users//.bin/standup_email' > /tmp/standup.log 2>&1

I've been running standups this way for 3+ months, and everyone on the team loves it. Surprisingly, everyone still knows what other people on the team are working on. Perhaps even more so, now!

I can't vouch for how this will scale to a team of greater than 5 people, so YMMV. I do expect there is an upper limit to how well this will work on large teams. That being said, it's probably the same constraint on time that holding a large synchronous standup would have anyway.

So please, give this a try, and see how it works for your team. Tweet at me with your results, I would love to know how it goes for you!

P.S.,

If you'd rather pay for this sort of functionality, and not mess with Google groups, you should check out iDoneThis.

Developer Fear

2013-07-25T16:05:37-07:00

I loved Adam's post, I don't have time to not teach. It's the perfect length. It's straight to the point. And, I've had a very similar experience.

I Don't Have Time to be Afraid to Teach

Inspired by this, I wanted to share a thought, or sentiment, that I've had over the years: don't be afraid. Don't be afraid to teach, to share, or to guide. Someone, anyone.

One of a developer's greatest fears is to be seen as ignorant. But, for a long time, I was very afraid to share something I had learned, thinking that surely everyone else knew about it, and I would be found out for my ignorance.

As it turns out, there is always someone learning. Always someone who knows less than you do. So teach, share, and guide others. Do it through writing, speaking, or best of all: pairing with those nearest you.

Sharing Photos with Lightroom Publish Service and PhotoDrop

2013-06-23T11:37:48-07:00

In this screencast I'm going to show how I use Lightroom's Publish Service to share my photos with PhotoDrop.

I would have normally embedded the screencast here, but Vimeo's embed has garbled the audio beyond recognition. So, here's a link to it!

Check out the PhotoDrop shared Favorites folder I just made.

Create as many more published smart folders in Lightroom and they'll all be available on PhotoDrop in no time!

ActiveModel::Serializers with DataMapper

2013-03-10T12:25:19-07:00

Now that Steve Klabnik has released ActiveModel::Serializers version 0.7.0, and Ryan Bates has produced a fantastic Railscast on its usage (episode 409), I'd like to share how I'm using ActiveModel::Serializers with DataMapper to build an API for Ember.js with ember-data.

I love ActiveModel::Serializers and I love DataMapper. With a little work, they are a match made in heaven! Thankfully, the integration of the two is actually very easy, once you get down into it.

The biggest change was a commit I added to ActiveModel::Serializers to make eager loading work properly in DataMapper. Steve has already released this as a gem, so be sure to use a version >= 0.7.0.

Otherwise we just include the right support modules. I've chose to do this in an initializer in Rails called simply 'serializer.rb'.

Serializer Gist

Now you should be able to create Serializers to your heart's content and everything from DataMapper should work just like we want it. Thank you Steve and Ryan!

I'll followup with a blog on how I'm using ActiveModel::Serizliers to build APIs to work with well with ember-data and Ember.js.

Recieve Gmail Email Messages in Rails

2013-02-04T17:40:00-08:00

I want to announce the release of mail_room and tell you a little bit about it and how it fits in with your Rails app.

Suppose you have a Rails application, and you would like to receive email from your customers, your users, or someone else. Out of the box, the mail gem can get messages from a POP3 server and allows you to query for messages in a very nice way. Unfortunately, in order to receive new mail, you have to ask the server at regular intervals.

With mail_room, we can let gmail's IMAP do the work, using the IDLE command. As soon as a message arrives, mail_room will get it to your application.

mail_room

At its simplest mail_room will forward your incoming gmail email to a URL you define.

It starts and runs as a process on its own. Given a configuration file like this, mail_room will open a connection for each gmail account and use the IMAP IDLE command to wait for new mail to come in. As soon as new mail arrives, mail_room will POST to the delivery_url you have configured.

Messages are sent to your application's delivery_url as RFC822 and can be received and parsed by the mail gem. From the mail object, you can see from, to, subject, body, and html for the message.

A delivery_token can be set to provide a simple mechanism to verify the sender. If an https delivery_url is provided, mail_room uses the excellent Faraday under the covers. By default, Faraday will attempt to use a verify_mode of OpenSSL::SSL::VERIFY_PEER.

Trying it out

If you'd like to try it out, but don't have an endpoint to receive the messages from mail_room, it can be configured to do more. Messages can be written to a log file, or better yet, they can be received and opened by Ryan Bates' (of Railscasts) fantastic gem, letter_opener.

Descriptions of the other configuration parameters for delivery methods can be found in this section of the README.

Start it up from your terminal using mail_room -c /path/to/config.yml.

When you're ready, you can simply use the mail gem to parse the body that mail_room sends using Mail.read_from_string(message). In this example 'message' is the POST body.

Next Steps

mail_room has greatly simplified the code I need to have in my Rails applications in order to have email pushed to me.

Try it out for yourself.
Watch the code for updates, new features, and an end-to-end example Rails integration.
Open an issue for any problems or questions you have.

Dividing Our Views and Templates in Rails

2013-02-03T13:00:00-08:00

TL;DR: I created a gem called simplest_view that makes it easy to move logic out of your Rails templates and into a class, in a conventional way.

You can see it on Github at tpitale/simplest_view

Feel free to start using it, but read on to see how I made it.

Is it a View or a Template?

Rails views are actually ERB templates. However, they're found under app/views. I think this manifests as a problem when our ERB templates grow in complexity as:

more data (in more instance variables) is passed to the ERB template
logic is embedded within the template
none of this is sufficiently tested

My goal was to be able to put my code in views, rather than letting my templates handle logic. That meant I needed to split the view from the ERB templates, so I could have a real view object. The template's only responsibility should be the display of markup, json, xml, etc.

Moving the Templates

The easy part is the existing templates.

I started by moving any existing "view" templates from app/views into app/templates. To make my app work I added self.view_paths = ['app/templates'] to my ApplicationController.

If you're following along, you could run your tests and this should work.

A Little Spelunking

Now, for the fun part: views!

If you've ever done something like <% puts self.inspect %> inside of an ERB template, you'll see that it's just a class. To know what functionality it has and where it comes from, I had to dig into Rails just a bit.

The first thing I saw was that the class's ancestors include some interesting things like ActionView::Base and, of course, my ApplicationHelper that gets included. The real question is, 'Where does this view get made?'

And the Views

The answer is found within the rendering module that is mixed in with AbstractController. Within, I found two methods: view_context and view_context_class. An anoymous class is created, which inherits from ActionView::Base and is used as the context for any ERB templates.

I made some small changes to view_context_class to make it use my own view classes.

To start I made up a convention for the view class that mirrors the templates. Something like app/views/posts/index_view.rb will have the view for PostsController#index defined as class Posts::IndexView < ActionView::Base.

Using that class name, I just did what Rails 3 does, which is to create an anonymous class, and include the routing and misc helpers. This class then becomes the context for my ERB templates.

It will have access to all the instance variables from the controller, and the ERB template will have access to any methods defined on the view.

What I've got now is the simplest split between Rails templates and views. This lets me clean up any logic that may have crept into my ERB templates over many months or years of development.

You can see the completed code module on Github.

Test Drive

If you would like to try this out in your project, please give SimplestView a spin.

Next Steps

It would definitely be a huge help if you could try it out, see how the approach feels in your project.
If you can spot a better way to hook into the view_context, let me know.
And lastly, open an issue if you find anything wrong or broken!

Thanks for reading!

Dropbox Thumbnails Into S3

2012-11-27T19:00:00-08:00

While building PhotoDrop I needed to upload thumbnails returned from Dropbox into S3. This should be an easy task, and it is, once you get passed this one little snag: the thumbnails from Dropbox are strings of data representing as if you just called File.read on the image file.

Dropbox is, of course, doing the right thing here. And, so is the rubygem dropbox-api. Rather than writing out a file, even a temporary one, these small thumbnail files can remain in memory and be quickly disposed of after we've sent them on to S3 for storage.

CarrierWave is an excellent gem. It makes uploading, processing, manipulating, and storing images/files quite pleasant. The challenge is to trick CarrierWave into using the string as if it was a file. Happily, this is an easy task.

ThumbnailIO

ThumbnailIO Class

We simply take the string, wrap it up as a StringIO, and give it an original_filename. To assign the image to a CarrierWave handler just pass the name and data to a new instance, like so: image = ThumbnailIO.new(some_filename, entry.thumbnail(format: 'jpeg', size: 's')) and save. That's all there is to it!

Sunspot with Datamapper

2012-11-26T09:01:00-08:00

Expanding search beyond simple queries is not easy. I tend to be lazy. For a long time this meant chaining queries and just letting PostgreSQL sort it all out, adding indexes along the way. This all falls down of course when we need to find one word – or part of one – within a body of text. Even worse is joining across tables all with one query. It can get very ugly, very quickly.

Thankfully, I had read about Sunspot, a well-designed wrapper around the powerful Solr search daemon. To get started, I watched the excellent introductory "Search with Sunspot" Railscast by Ryan Bates (you should really buy a pro account, it's worth every penny).

Unfortunately, out-of-the-box, Sunspot comes with ActiveRecord support and not much mention of other ORM's in the documentation. Here's what's working for me.

Install and Setup

Installation is cake. Simply add gem "sunspot_rails" to your Gemfile as in any other case, and bundle install away.

Thanks to a gist by Dan Kubb, there is an example of how to create an adapter for DataMapper to work with Sunspot. I forked it and added a few more pieces that seem to be required for it to work.

After the adapter is in place, we can generate the Sunspot configuration with script/rails generate sunspot_rails:install. We'll want to be sure to add solr/data to our .gitignore file.

Model Configuration

To get our models set to be indexed, we can simply follow Sunspot's README and configure our models using a searchable block. Here's what I'm using to search a Problem class, though it uses a lot of "text" fields. Many more, better examples can be found in the Sunspot docs.

Searching

For some reason, I was unable to call Problem.search {} and instead I have to call Sunspot.search(Problem) {}. Happily, I like this form better. It makes it clear that I can pass in multiple model class names to search across and that I'm only really searching the Problem in this example.

Sunspot/Solr Tweaks

I've made only a few minor modifications to solr's schema.xml configuration as generated by Sunspot. Under the solr.TextField fieldType I've added just a bit to use PorterStemFilterFactory to stem words in the index. Stemming is the process of removing common endings from words, to normalize when searching. For example, "riding" and "rides" would both be stemmed to "ride". Be careful, each language will have its own stemmer.

Quirks

Without specifying the models you wish to use explicitly, the rake tasks for Sunspot will attempt to load ActiveRecord, which we obviously do not have. The simple solution is to use rake sunspot:index models=Problem+Task+OtherModel to tell the task exactly which models we would like to be indexed.

Testing

I would be remiss if I didn't write about how I'm testing. Stubbing is advisable in most scenarios where you don't want to actually test the functionality within Sunspot.

However, I would also ensure the results you want are coming back from your search, a small, precise set of integration tests should be built.

In Conclusion

I'm happy to report that, in combination, Sunspot and DataMapper get along quite beautifully and I have had no real problems with this arrangement. The declarative nature of both DataMapper and Sunspot make for models that are extremely easy to understand and maintain. Now, my search pains are eased.

Server-Sent-Events with Celluloid and Reel

2012-11-02T14:22:00-07:00

There's a lot of buzz around websockets, and rightly so. They provide very powerful, two-way communication between you and the user's browser. Sadly, the current level of compatibility, along with the Flash-based fallbacks, leave me shuddering at the thought of using them in almost every scenario.

More recently, the half-a-websocket alternative server-sent-events (SSE), has been getting a fair amount of press, too. Aaron Patterson (aka, @tenderlove) showed us how to do it using ActionController::Live in Rails 4. Even better, Tony Arcieri (aka @bascule) has an example of how to use websockets within his brilliant project Celluloid and its offshoot webserver, Reel.

Thanks goes entirely to these two giants of the Ruby community, I've simply patched their work together to show a simplistic example of how to do a SSE broadcast using a Reel webserver and Aaron's basic SSE class.

The Code

SSE with Reel
Raw Code

As you might imagine, SSE probably serves the needs of most everyone that wants to push up events and data to a browser. Thankfully, SSE is based on http and there are a handful of pure-javascript polyfills available. Check out MDN for more information on SSE.

Thanks for reading! Tweet at me with any comments, suggestions, or questions. Check back later or follow me to see when I share how I'm using this with Ember.js.