mileszs blahg

Wicked PDF Plugin

2009-06-17T19:33:11-04:00

A bit of background, in the hopes that it will help you save some time:

At The Job, I need PDF generation. We want to generate various documents in PDF form that are professional looking without requiring our users print a particular web page to some PDF printer. I’d prefer it be really easy for me to write, of course, but if it’s something I can do once and never again, I can probably live with a convoluted DSL of some sort. So, once upon a Google, my search began.

… and it was frustrating.

Princely

I started with Princely, a Rails plugin that uses the PrinceXML library to generate PDFs from Rails views. It’s super-simple. It’s almost everything I wanted in a PDF generation plugin. It allows you to do all your layout and prettifying with CSS and HTML, which is sweet because — damn — I already know HTML and CSS. Hell yes.

Except that it watermarks all your PDFs with a blue square containing a white ‘P’. You can get rid of it if you’ve got $3800. Verdict? Not worth it.

Prawn

I moved to playing with Prawn, which is essentially a Ruby-ish DSL for laying out and generating PDFs. It was a nightmare. Check out this gist to get an idea of what I mean. It can’t be printed here. It’s too big and cumbersome. It’ll break my blog. … Here’s a taste:

 1  2  3  4  
  5  6  7  8  9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26

I appreciate what def info_table
tags :blue => { :color => ‘blue’ },
:green => { :color => ‘green’ }
bounding_box [235, 700], :width => 300 do
font "Times-Roman"
fill_color(‘999999’)
text "TERM SHEET", :size => 24, :align => :right
fill_color(‘000000’)
0 font "Helvetica"
text "<blue>Keep IT Safe,</blue> <green>Keep IT Simple</green>", :size => 12, :align => :right
end
bounding_box [260, 650] do
table [[ticket</span>, <span class="iv">sales_rep, doc_no</span>, <span class="iv">project, @date]],
:headers => [‘TICKET’, ‘SALES REP’, ‘DOC. NO.’, ‘PROJECT NO.’, ‘DATE’],
:header_color => ‘000000’,
:header_text_color => ‘ffffff’,
:align_headers => :center,
:vertical_padding => 2,
0 :horizontal_padding => 2,
:font_size => 8,
:width => 272,
:border_width => 0.2,
:align => { 0 => :center, 1 => :center, 2 => :center, 3 => :center, 4 => :center, 5 => :center, 6 => :left }
end
end
the Prawn library can do. I appreciate all the hard work that has been put into it. It’s just not for me. So not worth it.

Wicked PDF

So, with a little help from Elijah Miller and the Indy.rb IRC channel (#indyrb on Freenode), the shell utility wkhtmltopdf landed in my lap. It uses the WebKit engine via QT 4.4 to render HTML and CSS and convert it to PDF. It’s free. It’s exactly what I needed. Based upon wkhtmltopdf, the Wicked PDF plugin was born to make PDF generation in your Rails app easier and cheaper than it was previously.

First of all, it’s wicked-easy to get started. After you’ve visited wkhtmltopdf and installed wkhtmltopdf, simply:

script/plugin install git://github.com/mileszs/wicked_pdf.git

In your controller:

 1 class ThingsController < ApplicationController

 2   def show

 3     respond_to do |format|

 4       format.html

 5       format.pdf do

 6         render :pdf => "file_name",

 7                :template => "things/show.pdf.erb",

 8                :layout => "pdf.html"

 9       end

10     end

11   end

12 end

You don’t have to specify a template, as it will choose the template for the current controller and action by default. Also, by default, layout is set to false, so you may want to keep that around.

I hope this helps others who have travelled the long, lonely, crufty, potentially expensive route of finding a sufficiently powerful and simple PDF generator. If you find it lacking, or if you find a bug, please report it to Wicked PDF’s Issues page so I can make it do right.

Look:

You know the Wicked Witch likes it.

Vim, Screen, &
The Awesomest IDE Ever

2009-06-05T17:19:25-04:00

When I’m writing code, I am always using two classic tools, common on many UNIX-based systems: Vim, and GNU Screen. I’ll show you how I use them, as I don’t think any two programmers use them the same way. Some programmers may prefer to use a big, fancy ‘IDE’. There is no need. Vim and Screen can combine to be The Awesomest IDE Ever

Note: My day job primarily consists of writing Ruby for Ruby on Rails applications, so the following outline is focused on that type of environment. What am I saying? Most of the programming I do outside of work involves Ruby or Rails, too.

GNU Screen

I’ll start with GNU Screen, as it’s the lesser-known of the two subjects of this post. (I’ll call it simply ‘screen’ from here on — but if you’re Googling, you’ll want to include ‘GNU’.) Screen is often described as a ‘terminal multiplexor’. GNU likes to call it a full-screen window manager. A clearer description would be “screen takes the concept of tab support in a terminal, and pumps it full of steroids”. At its core, screen allows you to create multiple terminal windows within a single terminal — like, say, Gnome terminal’s tabs. It does so much more than that, though. From GNU:

… at any time, you can create new (full-screen) windows with other programs in them (including more shells), kill the current window, view a list of the active windows, turn output logging on and off, copy text between windows, view the scrollback history, switch between windows, etc. All windows run their programs completely independent of each other. Programs continue to run when their window is currently not visible and even when the whole screen session is detached from the users terminal.

The latter feature, detaching from the terminal, is perhaps the most ~~important~~ awesome feature. A number of people use screen for that feature alone. For instance, I often SSH into my home desktop machine and re-attach to a screen session that has a window for IRC, a window with an open SSH session for each of the servers I administer, and a window open for miscellaneous commands I may want or need to run on my home machine. I can detach from this set of terminal ‘windows’ or ‘tabs’ at any time, and reattach at any time. It’s fantastic if you like to never miss a word of your local Ruby group’s IRC chatter. That’s a completely practical application of that feature. Right?

These aren’t all of the features of screen, but I’m long-winded without getting worked up about discussing every feature of GNU screen. You can clearly see how screen provides the infrastructure for The Awesomest IDE Ever. Let’s just move on.

Vim

Vi IMproved. It’s often called a programmer’s editor, although I use it for anything and everything, when I can get away with it. (I used it to write this rambling, incoherant post. The rambling and the incoherance have nothing to do with Vim, I swear.) Vim uses different modes (e.g. ‘Insert’ mode, ‘Visual’ mode, ‘Normal’ mode) as a powerful and efficient way to traverse and edit text files. It’s highly configurable and extendable. It’s great. If you’ve never used it, and you think it’s going to be impossible to learn, it’s not! If you have Vim installed, and you want to give it a shot, just type ‘vimtutor’ at a command prompt, and follow the tutorial.

Vim + Screen

By combining Vim + Screen, you can get your own IDE that doesn’t completely suck. Resources. Suck resources. I’m not saying that any other ‘IDE’ things that I have ever used are each a horribly twisted orgy of unnecessary features and mouse-slam-inducing bugs, possessing the customization possibilities of a straight-jacket. They aren’t basically a large pile of naked, over-weight, pasty, inept middle-aged men, necessarily. No, I’m just saying that the filthy bastards hog a lot of resources. Vim, Screen, and the few other processes I run along side them, when working on a Rails app, do not.

Let’s look at a pretty picture:

The two most interesting features are the split screen, and the pretty little window list at the bottom of my terminal window. Both features are made possible by screen. Let’s focus on the window list first:

Screen Details

Sweet. We’ve got a nice little list of windows, one for each thing I want out of my development environment, but in a fairly simple, unobtrusive format: ‘dev’, my primary development window, ‘test’, where my tests get run (in this case, using ‘autotest’, they are run any time I save a file), ‘console’, for my Ruby REPL (script/console from Rails), ‘server’ for the app server, ‘tail’ for printing whatever log I feel like following, and ‘misc’ for one-off commands and the like. I can cycle through the windows by typing Ctrl+a, then ‘n’ for next, or ‘p’ for previous, or the number of the window. In just a few pixels of space, I know where everything is, and I don’t have to grab my mouse to get there. Suck it, Mammoth IDE Software.

Note: The window list at the bottom doesn’t come for free. You’re welcome to use my configuration file for screen, ‘screenrc’. This file is exactly the screenrc used in this article’s screenshots.

As you can see, screen also allows you to split your terminal window so that you can view two (or three, or four — go crazy!) screen windows at the same time. For me, this is killer. I am able to code in Vim while watching my test output in the smaller pane on the bottom. No pop-up messages to distract you. No sound effects. (Hmm. Perhaps I’m too easily distracted. And too easily annoyed.) It’s also trivial to focus on the bottom window (Ctrl+a, then j or tab), at which point I can scroll the output, or I can switch to, say, the console window to try some stuff out there before I throw it in the actual code. Screen can also split vertically, if you dig that. With a widescreen monitor, why wouldn’t you? I prefer to use Vim’s vertical split screen ability (in my top pane) to edit, for example, a class and its tests at the same time. However, It does seem like I’m wasting a lot of space in that bottom pane. Let’s try a vertical split down there:

Sweet! I’m glad you talked me into trying that. That’s Vim split vertically on top, and screen split vertically on the bottom (tests on the left, REPL on the right).

Vim Details

You can find fantastic information about Vim all over the place. I don’t want to bury you under finger-gymnast technique for both screen and vim, if I can help it.

A good place to start look for information is Vim.org, of course. I maintain a page of what I believe to be useful vim links on my GitHub Page page. If you’re jonein’ for small tidbits of vim awesomeness once per day, check out my @vimtips account on Twitter. Okay. On to live action…

If you’re ever programming within the Rails framework, then you should be using rails.vim. It is the most essential plugin in my vim plugin arsenal. It has a ton of features. Incredibly helpful shortcuts to opening project files, integration with vim’s tabs, as well as vim split screens (more on that in a sec), enhanced syntax highlighting, shortcuts for the various script/* scripts… I could go on, but I won’t. (Type the command :help rails to browse the extensive help pages.)

As for splitting, and the way I typically use splits in vim: You may already know that you can type the command :vsplit to get a vertical split in Vim. With rails.vim, you can simply type :AV from a model or controller, and its corresponding test file will open up on the left-hand side of a vertical split. The ‘A’ in the command stands for ‘alternate’, and the ‘V’ stands for vertical split, of course. You can open other files into a vertical split using several of the other rails.vim commands. For instance, :Rcontroller would become :RVcontroller, at which point whatever file you currently have open would move to the right, and the related controller file would open on the left.

The vim way is the way I want to edit text. Always. It’s incredibly efficient. Thus, it is the perfect text editor for The Awesomest IDE Ever.

This is my “IDE”

After some initial configuration, what you see above can be up and running in just a few seconds. In fact, all I do is type Meta-t (the windows button, or command when I’m using the incomparable Apple keyboard) to open a terminal, cd devel/project-name, and then enter the command scrails. Really, scrails is just an alias for screen -c ~/.rails.screen. (It sounds cool, though. Right?) That rails.screen file looks like this:



#


# Initiate a screen session with my


# preferred dev environment


#




source /home/mileszs/.screenrc




screen -t dev 0


split


resize 40


focus down


screen -t test 1 autotest -f


split -v


focus down


screen -t console 2 script/console


focus top


screen -t server 3 script/server thin


screen -t tail 4 tail -f log/development.log


screen -t misc 5


select 0

I’ll explain:

First, sort of a ‘step 0’, read in our screenrc file. Simple enough.

1. Create a new window, give it the title (See? -t for title!) ‘dev’, and let it be window number 0.
2. Create a horizontal split
3. Resize the upper window
4. Focus down to the split we created in step 2
5. Create a window with a title of ‘test’, and run the command autotest -f
6. …

You get the idea. The command split -v creates our vertical split, which screen thinks of as ‘down’ in the list of splits. At the end, we select window 0 as the window in which we want our cursor when this has finished.

Easy. Right?

I don’t know if this ultimately came across as easy. It really is. I encourage you to install GNU screen and install Vim. Give them a shot. Use all of my config files to start, and then beat those files to hell to see what you end up with. Vim is great; a great deal of programmers already know that. With screen, you can take the greatness of vim and create The Awesomest IDE Ever. Good luck!

A Git Hook to Push to Integrity

2009-03-03T20:14:53-05:00

If you’re using GitHub with Integrity, “the easy and fun automated continuous integration server”, then you probably know how stupid-simple it is to integrate the two. Seriously. You just tell GitHub to what URL you wish it to send stuff, and it’ll do it. It takes more time for most computers to power up than it takes to get that setup running. Great, isn’t it?

If you’re hosting your own centralized git repository on your own server, you need to set up your own post-receive hook. There is a short thread about doing just that at Integrity’s Google Group. In fact, that is where our journey begins…

Could someone spell lazy for me?

I knew that I needed a post-receive hook that sent the right information to my installation of Integrity, but I really didn’t want to have to write one myself. Sure, it might be fun. It also might be a frustrating waste of time. So, I went to the Integrity Google Group, searched for “post receive”, and came across this thread s.google.com/group/integrityapp/browse_thread/thread/895f3b6198275f6e (the same one to which I linked above). Cool! That led to this Gist by whatcould:

Watch out for that wayward ‘0’ on line 33 in the Gist.

#!/usr/bin/ruby



# Replace the following by the url given to you in your project’s edit page

POST_RECEIVE_URL = ‘http://localhost:4567/my_fancy_project/push’



#######################################################################

## ##

## == DON’T EDIT ANYTHING BELOW UNLESS YOU KNOW WHAT YOU’RE DOING == ##

## ##

#######################################################################



require ‘net/http’

require ‘uri’



old_head, new_head, ref = STDIN.gets.split



# on solaris, ruby is choking on various shell commands, the quotes in format.

# maybe it’s running sh? (though it seems to report bash)?

# the `bash -c …` gets around it, anyhow:





revisions = %x{bash -c "git-rev-list —pretty=format:‘%H %ai’ #{new_head} ^#{old_head}"}.split("\n")



rev_list = revisions.inject([]) do |list,line|

  if line[0..5] == ‘commit’

    list

  else

    list << %Q({"id":"#{line[0..40]}","timestamp":"#{line[41..66]}"})

  end

end



Net::HTTP.post_form(URI.parse(POST_RECEIVE_URL), {

 :payload => %Q({"ref":"#{ref}", "commits":[#{rev_list.join(‘,’)}]})

})

Hurry Up!

You can just copy and paste that script to GIT_REPO_ROOT/hooks/post-receive, chmod +x GIT_REPO_ROOT/hooks/post-receive, and you should be good to go. The next time that you git push, it’ll push the necessary information to Integrity. Eventually. It takes a while. The waiting was driving me nuts. One of the great things about git is how freakin’ fast everything is. This script was killing me. Perhaps I’m just really impatient. Maybe I’m doing something wrong. I have a solution, though.

And Then There Was Awesome

We’re going to use the “Daemons” gem to make this freakin’ fast. OK, technically, it doesn’t speed anything up. It just gets out of the way. Whatever. Do this:

  sudo gem install daemons

Now we just have to add a couple lines to the post-receive hook:

This version is available as a gist here.

#!/usr/bin/ruby



# Replace the following by the url given to you in your project’s edit page

POST_RECEIVE_URL = ‘http://localhost:4567/my_fancy_project/push’



#######################################################################

## ##

## == DON’T EDIT ANYTHING BELOW UNLESS YOU KNOW WHAT YOU’RE DOING == ##

## ##

#######################################################################



require ‘net/http’

require ‘uri’

require ‘rubygems’

require ‘daemons’



old_head, new_head, ref = STDIN.gets.split



# on solaris, ruby is choking on various shell commands, the quotes in format.

# maybe it’s running sh? (though it seems to report bash)?

# the `bash -c …` gets around it, anyhow:





revisions = %x{bash -c "git-rev-list —pretty=format:‘%H %ai’ #{new_head} ^#{old_head}"}.split("\n")



rev_list = revisions.inject([]) do |list,line|

  if line[0..5] == ‘commit’

    list

  else

    list << %Q({"id":"#{line[0..40]}","timestamp":"#{line[41..66]}"})

  end

end



Daemons.daemonize



Net::HTTP.post_form(URI.parse(POST_RECEIVE_URL), {

 :payload => %Q({"ref":"#{ref}", "commits":[#{rev_list.join(‘,’)}]})

})

Daemons.daemonize will shove our currently-running script to the background and let git get on with gittin’. It’s simple. It’s fast. Now, it’s legendary!

Image borrowed from SoutherDesigner at DeviantArt

My New Home

2009-02-07T23:54:29-05:00

I finally did it. I switched to a static blog, powered by Webby. I have been talking about doing this since July of 2008. Hey, I came in under a year! Sweet!

Git and Webby, Sitting in a Tree

Essentially, Webby and Git power this blahg. I tell Webby I want to post a new entry. When finished, I commit it and push it to the “central” repository on my server. A post-recieve hook pulls the update into the web-accessible directory. BAM! It’s like magic.

So, basically, this:

webby blog:post my-new-home

# my-new-home.txt is opened in my $EDITOR (VIM!),

# with the proper meta-data already filled in

# according to Webby rules.

#

# After I finish writing:

webby build

git commit -a -m "POST: My New Home"

git push origin master

It’s that simple.

Well, it could be, anyway. In reality, I’m still tweaking design aspects, and I am still tweaking some content. From time to time, in the midst of working on a post, I will find that some other aspect of the site needs tweaked. I like to see what my post looks like after nearly every paragraph because I have some sort of mild OCD or something. Thankfully, I can simply run webby autobuild in the background. This launches an instance of WEBrick, opens your browser, and points it at localhost:4331. Whenever a page is saved, it updates the relevant output, and serves it up. This has the added benefit of not needing to run webby build before committing. It’s fan-freakin’-tastic.

JS-Kit Comments

The Good

I went with JS-Kit Comments over Disqus (or Intense Debate, etc.). Look at the feature list yourself. There are a ton of features: OpenID integration (and Facebook Connect), Akismet SPAM protection, full custimization…. The list is lengthy. Check it out.

The first thing that struck me about JS-Kit was their site. While perhaps not as pretty as the Disqus site, the site proved a lot easier to find the exact information for which I was looking.

It also helps that I have gotten helpful replies on Twitter from JSKitSupport. There are several people from JS-Kit on Twitter, and they are pretty active. I know, Disqus does this, too. They never contacted me, though.

JS-Kit has several other widgets to go with their Comments system.

The Not-So-Good

Honestly, the name ‘JS-Kit Comments’ sucks. It sounds like some half-assed javascript library from 2001. Their logo isn’t great. Disqus is a YCombinator company, and people freakin’ love them some YC.

Give me a couple months, and I will probably be able to produce more bad aspects of JS-Kit with validity.

The Other

I have not gotten my comments from soyunperdedor.com transferred yet. Sorry.

New Domain(s)

I’ve decided to use a more obvious domain ‘mileszs.com’. (I do also own mileszs.org, and mileszs.net, which both hit soyunperdedor.com at the time of this writing. They won’t always.) While the domain soyunperdedor.com still makes me giggle a bit, it wasn’t very practical. It was difficult for some to remember, cumbersome for some to spell, and made no sense unless you either 1) know Spanish, or 2) know Beck.

“You know, like in that Beck song, ‘Loser’.”
“Excuse me?! Screw you, too, buddy.”

Soon enough, soyunperdedor.com will redirect to mileszs.com.

The Design

Not much to talk about with regards to the design. The most interesting aspect probably is that I am using the 960 Grid System. I will admit that I never dove in and used Blueprint CSS. I did use YUI Grids CSS a bit. I found 960 to be easier with which to work compared to YUI, and I liked the grid and naming philosophies better than Blueprint. I think it’s a matter of opinion.

The End

That’s it. I get to blog like a hacker, although not using Mr. Preston-Werner’s Jekyll. (Webby is a bit more powerful, and supports Sass and Haml, which is huge. Jekyll is good, though. I use it for Vim Links of Worth and Valor, my GitHub Pages page.) I really love doing everything from the command line, instead of copying and pasting into a web form, or something equally as lame. Of course, there’s the added benefit of it not doing a single database request. So, it’s fast. It scales. It brings all the boys to the yard. Damn right, it’s better than yours.

Shoulda Macros for Common Plugins

2008-09-21T04:12:35Z

If you haven't looked into Shoulda, maybe you should. It's a plugin (and now gem) that works "on top of" Test::Unit. It truly does make it "easy to write elegant, understandable, and maintainable tests".

The following are a few Shoulda macros that I use for the plugins acts_as_ferret, acts_as_taggable_on_steroids, and acts_as_list. I recommend creating a file 'test/shoulda_macros/plugins.rb', and placing these macros in there. For example:

class Test::Unit::TestCase

# Shoulda macros here

end

Acts As Ferret

  def self.should_act_as_ferret(*fields)
    klass = self.name.gsub(/Test$/, '').constantize

    should "include ActsAsFerret methods" do
      assert klass.extended_by.include?(ActsAsFerret::ClassMethods)
      assert klass.include?(ActsAsFerret::InstanceMethods)
      assert klass.include?(ActsAsFerret::MoreLikeThis::InstanceMethods)
      assert klass.include?(ActsAsFerret::ResultAttributes)
    end

    fields.each do |f|
      should "create an index for field named #{f}" do
        assert klass.aaf_configuration[:fields].include?(f)
      end
    end
  end

Use it like:

should_act_as_ferret :any, :fields, :i_may, :have, :specified

Acts As Taggable On Steroids

  def self.should_act_as_taggable_on_steroids
    klass = self.name.gsub(/Test$/, '').constantize

    should "include ActsAsTaggableOnSteroids methods" do
      assert klass.extended_by.include?(ActiveRecord::Acts::Taggable::ClassMethods)
      assert klass.extended_by.include?(ActiveRecord::Acts::Taggable::SingletonMethods)
      assert klass.include?(ActiveRecord::Acts::Taggable::InstanceMethods)
    end

    should_have_many :taggings, :tags
  end

Acts As List

  def self.should_act_as_list
    klass = self.name.gsub(/Test$/, '').constantize

    context "To support acts_as_list" do
      should_have_db_column('position', :type => :integer)
    end

    should "include ActsAsList methods" do
      assert klass.include?(ActiveRecord::Acts::List::InstanceMethods)
    end

    should_have_instance_methods :acts_as_list_class, :position_column, :scope_condition
  end

Note: These tests are quite basic. Except for checking the fields on acts_as_ferret, there isn't any testing of each plugin's options.

These macros are available at http://github.com/mileszs/shoulda_macros. You can find more macros at the Shoulda wiki on GitHub, http://github.com/thoughtbot/shoulda/wikis/example-macros. If you write some of your own shoulda macros, you should link to them on the wiki as well.

From class_eval to Modules

2008-09-14T14:52:14Z

Once in a while, it's nice to actually go back and look at old code. Not because that old code makes you feel good about yourself at all -- quite the opposite -- but because you feel good about yourself after you clean it up a little bit.

Ola Bini's Evil Hook Methods? got me thinking about how I extend classes in a dusty Rails application. It reminded me of Jay Fields' Ruby: Underuse of Modules. Of course, Jay also weighed in on Ola's concerns. All of these articles have led me to take a look at some simple extensions I had made to Time for this particular Dusty Rails App (DRA, from now on). First, this is what I had before:

Time.class_eval do 
  def self.next_sunday
    t = Time.local(Time.now.year, Time.now.month, Time.now.day, 0) # Today at midnight
    t += 60*60*24 until t.wday == 0
    t # Should now be next Sunday at midnight
  end

  def self.nth_wday(n, wday, month, year)
    if (!n.between? 1,5) ||
       (!wday.between? 0,6) ||
       (!month.between? 1,12)
      raise ArgumentError
    end
    t = Time.local year, month, 1
    first = t.wday
    if first == wday
      fwd = 1
    elsif first < wday
      fwd = wday - first + 1
    elsif first > wday
      fwd = (wday+7) - first + 1
    end
    target = fwd + (n-1)*7
    begin
      t2 = Time.local year, month, target
    rescue ArgumentError
      return nil
    end
    if t2.mday == target
      t2
    else
      nil
    end
  end

  def after_hours?
    result = true
    # M-F, 8am to 6pm are business hours
    if (1..5).include?(self.wday) && (8..18).include?(self.hour) 
      result = false
    end
    # unless it's a holiday!
    if self.holiday?
      result = true
    end
    result
  end

  def holiday?
    unless new_years_day? || 
       mlk_jr_day? ||
       memorial_day? ||
       independence_day? ||
       labor_day? ||
       thanksgiving? ||
       christmas_day?
      return false
    end
    true
  end

  def new_years_day?
    return false unless self.yday == 1
    true
  end

  def mlk_jr_day?
    return false unless self.yday == Time.nth_wday(3,1,1,self.year)
    true
  end

  def memorial_day?
    last_day_of_month = Time.local(self.year, 5, 31)
    d = last_day_of_month.mday - last_day_of_month.wday + 1
    return false unless Time.now.yday == Time.local(self.year, 5, d)
    true
  end

  def indepence_day?
    return false unless self.month == 7 && self.mday == 4
    true
  end

  def labor_day?
    return false unless self.yday == Time.nth_wday(1,1,9,self.year).yday
    true
  end

  def thanksgiving?
    return false unless self.yday == self.class.nth_wday(4,4,11,self.year).yday 
    true
  end

  def christmas_day?
    return false unless self.month == 12 && self.mday == 25
    true
  end
end

I see only trees. Where is the forest?

What we're worried about is how Time was extended. It was a simple class_eval -- just open the class up and insert these methods. The file is simply required in config/environment.rb. In this case, I am adding functionality that didn't exist, so it could be left alone. It's not that big of a deal. As long as you're looking at the file that contains this code, understanding what is happening is pretty simple.

I would like to move these methods to a module. Time could then include/extend them. I do like to have modules in the lib/ directory while using initializers to pull them into DRA. That method of organization seems much cleaner to me. Plus, I can't very well end this article by telling you that I'm just going to leave DRA alone. Not now that we've come this far.

Modularize It Already!

module NframeTimeExtensions
  module ClassMethods
    def next_sunday
      t = Time.local(Time.now.year, Time.now.month, Time.now.day, 0) # Today at midnight
      t += 60*60*24 until t.wday == 0
      t # Should now be next Sunday at midnight
    end

    def nth_wday(n, wday, month, year)
      if (!n.between? 1,5) ||
         (!wday.between? 0,6) ||
         (!month.between? 1,12)
        raise ArgumentError
      end
      t = Time.local year, month, 1
      first = t.wday
      if first == wday
        fwd = 1
      elsif first < wday
        fwd = wday - first + 1
      elsif first > wday
        fwd = (wday+7) - first + 1
      end
      target = fwd + (n-1)*7
      begin
        t2 = Time.local year, month, target
      rescue ArgumentError
        return nil
      end
      if t2.mday == target
        t2
      else
        nil
      end
    end
  end

  def after_hours?
    result = true
    # M-F, 8am to 6pm are business hours
    if (1..5).include?(self.wday) && (8..18).include?(self.hour) 
      result = false
    end
    # unless it's a holiday!
    if self.holiday?
      result = true
    end
    result
  end

  def holiday?
    unless new_years_day? || 
       mlk_jr_day? ||
       memorial_day? ||
       independence_day? ||
       labor_day? ||
       thanksgiving? ||
       christmas_day?
      return false
    end
    true
  end

  def new_years_day?
    return false unless self.yday == 1
    true
  end

  def mlk_jr_day?
    return false unless self.yday == Time.nth_wday(3,1,1,self.year)
    true
  end

  def memorial_day?
    last_day_of_month = Time.local(self.year, 5, 31)
    d = last_day_of_month.mday - last_day_of_month.wday + 1
    return false unless Time.now.yday == Time.local(self.year, 5, d)
    true
  end

  def indepence_day?
    return false unless self.month == 7 && self.mday == 4
    true
  end

  def labor_day?
    return false unless self.yday == Time.nth_wday(1,1,9,self.year).yday
    true
  end

  def thanksgiving?
    return false unless self.yday == self.class.nth_wday(4,4,11,self.year).yday 
    true
  end

  def christmas_day?
    return false unless self.month == 12 && self.mday == 25
    true
  end
end

Ah, there. The module ClassMethods pattern is used throughout Rails, so you've likely seen it before. Other than that, it's pretty straight-forward. I hope.

Now I need to get it into DRA. So, in RAILSROOT/config/initializers/heyletsincludethosestupidtime_extensions.rb:

require 'nframe_time_extensions'

Time.class_eval do
  include NframeTimeExtensions
  extend NframeTimeExtensions::ClassMethods
end

That smells better to me.

Whoa. Way More Code.

Yeah, this does take more code, and an extra file. I don't mind writing a bit of extra code when I believe that it will make the code clearer. As I said before, this method of organization seems much clearer to me.

It was also a fun little exercise in extending via modules instead of directly adding to classes. That is not a bad thing to practice.

Re-Thinking Hack-Svn && Ship-Svn

2008-09-09T17:22:39Z

In a comment to Hack-svn && Ship-svn, Yossef Mendelssohn of OG Consulting, suggested that my chosen workflow may not be ideal. He probably knows much better than I. Here's the (relevent portion of the) comment:

Also, about your git-svn scripts. Kevin (the third OG) was working on the same thing, even going so far as to make 'hack' and 'ship' DTRT based on whether you're in a git-svn repo or a regular git repo. In my experience, however, there's more difference between vanilla git and git-svn than just whether you git pull or git svn rebase. I've had enough troubles that I no longer dcommit from master. I always keep master as the state of the svn repo and dcommit from branches. Much fewer headaches that way.

(Note that the three OGs are Yossef Mendelssohn, Rick Bradley, and Kevin Barnes.)

I had previously seen a similar idea suggested by a commentor to Andy Delcambre's 'Git SVN Workflow' by the name of Chris McGrath:

That workflow is very similar to how I use git-svn. Something I don’t do that I’ve seen in nearly every article like this is the merge back to master. I just git-svn rebase my topic branch to svn HEAD, fix any conflicts there and git-svn dcommit that, possibly doing a rebase -i beforehand to clean up the commit(s). Then I switch to master, rebase again to get the committed changes and delete the topic branch. My reasons for this aren’t really biggies imho, more that this is the way I’ve always done it. They are:

Master will always contain only changes that are in svn, so easy to make a quick bugfix branch without having to work out which rev to branch from. 2. The git-svn man page doesn’t recommend doing git merges, but using dcommit or format patch to move changes between git branches. 3. It’s one less place to get conflicts, as they will only happen on the topic branch rebase. ...

Fair enough.

So, that means what?

Well, following the basics of Yossef's suggestion would make ship-svn really, really boring. (That's not to say it is incorrect, or ineffective.)

#!/bin/sh -x
CURRENT=`git name-rev HEAD --name-only`
git svn dcommit

Right? Should we also checkout master and 'git svn rebase' again? That step would get done the next time you run 'hack-svn' anyway. Hmm. Maybe there is another, better workflow of which I am unaware?

Mr. McGrath is suggesting something like:

#!/bin/sh -x
CURRENT=`git name-rev HEAD --name-only`
git svn rebase
git svn dcommit
git checkout master
git svn rebase
git branch -D ${CURRENT}

I don't really like that. However, I do have a nasty habit of working out of the same 'topic' branch constantly, rather than naming a new one with each new feature. Sometimes I do feel the need to have a few different branches active, if I am unsure of the best path, and I intend to discover it through experimentation. Most of the time, I just work out of 'devel'. That approach makes the adaptation of the original Hack && Ship method pleasing, to me.

Again, that probably means I'm wrong. I will likely adopt my interpretation of Yossef's method soon, while sticking with the original for now. I'd like to think about it for a bit. I would also enjoy hearing what others think.

Hack-Svn && Ship-Svn

2008-08-28T21:16:18Z

I was inspired today by Rein's Hack && Ship post to write something similar for those of us stuck in the Dark Ages of Git-SVN. It took very little work on my part. Honestly, the originals did most of the work. I changed two lines.

What I'm trying to say is: All praise be to the original author, Rick Bradley, and to Rein for exposing them to the Rest of Us. Edit:Thanks also to Yossef Mendelssohn for the idea and his tips in the comments section, and to Kevin Barnes, because he's part of that crew surely had a hand in it -- and he's working on a sweet related script. Again, see Yossef's comment.

Hack-svn && Ship-svn: The Scripts

Hack-svn:

#!/bin/sh -x
CURRENT=`git name-rev HEAD --name-only`
git checkout master
git svn rebase
git checkout ${CURRENT}
git rebase master

Ship-svn:

#!/bin/sh -x
CURRENT=`git name-rev HEAD --name-only`
git checkout master
git merge ${CURRENT}
git svn dcommit
git checkout ${CURRENT}

You really are un perdedor

As you can see, I indeed only changed two lines to make them work for me. The names 'hack-svn' and 'ship-svn' are not nearly as fun as 'hack' and 'ship', whether reading them aloud, or typing them after completing a feature. However, I want to also have vanilla-git hack and ship available for vanilla-git projects. The name at least makes their function semi-obvious, if you know about hack && ship. I thought about just calling them 'hacks' and 'ships', giving them a bit of a Paris Hilton feel. Loves it?

Yes, I obsess over what to call scripts I write. It's a disease. When I recover, I'll start some sort of rehab clinic bearing my name.

So, have at it, my fellow git-svn-ers. You might also write a local alias for git svn rebase and git svn dcommit to make you feel like you aren't really using subversion. It's therepeutic.

Rails 2.1 Time Zone Trouble

2008-08-10T21:41:47Z

Making an app deal with multiple time zones is easy in Rails 2.1. Right? Just include a default time zone your environment.rb:

Rails::Initializer.run do |config|
# ...
  config.time_zone = "Eastern Time (US & Canada)"
# ...
end

Rails will store time stamps in UTC in the database. They will be converted to the default time zone when they are requested. I thought that sounded great! Although, at work, we don't currently need to support any other time zone than Eastern, there are a few reasons we suspect we may need to do so sooner than later. We welcomed the time zone support in Rails 2.1. Unfortunately, it didn't work out all that well for us, and we don't know why.

Basically, Rails isn't converting the times correctly. System time on the server is correct, so there has to be something wrong withour Rails config(s). The best way to illustrate the problem is with irb:

# A newly created object
$>script/console
>> t = Ticket.last
>> t.created_at
=> Tue, 05 Aug 2008 13:24:56 EDT -04:00 # NOT correct -- it should be 9:24 EDT -04:00
>> t.created_at_before_type_cast
=> Tue, 05 Aug 2008 13:24:56 +0000 # Correct -- UTC
>> Time.now
=> Tue Aug 05 09:25:34 -0400 2008 # Correct
>> Time.zone.now
=> Tue, 05 Aug 2008 09:26:11 EDT -04:00 # Correct

So, the only thing that is not correct is the conversion from UTC in the database to local time. It seems to think that local time and UTC should be the same, and only changes the offset, and not the actual time. I posed this issue to #rubyonrails. Possibly the most accurate response was, "Something is f'd up."

So, would you like to see what happens when we tell Rails we want to default to Pacific Time (US & Canada), just for fun?

# If config.time_zone is set to "Pacific Time (US & Canada)"
>> t.created_at
=> Tue, 05 Aug 2008 10:38:55 PDT -07:00 # NOT correct -- it's 6:38 PDT -07:00
>> t.created_at_before_type_cast
=> Tue, 05 Aug 2008 13:38:55 +0000 # Correct -- UTC
>> Time.now
=> Tue Aug 05 09:40:02 -0400 2008 # Correct for my local time
>> Time.zone.now
=> Tue, 05 Aug 2008 06:39:57 PDT -07:00 # Correct

What!? Rails thinks that EDT == UTC, and the difference between EDT and PDT is 3 hours, so just subtract 3 hours from whatever we get back from the database.
F'd up indeed!

I gave up. I may have given up too early. Perhaps I could have figured it out. Frankly, there were better things to do. We just store everything in local time. For now, it won't hurt anything. In the future, it could be quite a hindrance.

Do you have any idea what is wrong? I'll buy you a beer if you find a solution.

Too Many Choices

2008-07-10T01:54:10Z

Photo By Tomotaka

I have spent a silly amount of time lately contemplating what I want in a
blogging engine/system/platform/thing. I know one thing: Drupal, the system I
am currently using, is not it. It's a fine content management system. In
fact, I use it as a content management system for another site, and I am quite
happy with it. However, it's much more than what I need. I mean,
honestly, I inconsistently publish a few thoughts with some code. I do NOT
need a content management system. So, what do I need?

WordPress ... ?

Woo! WordPress! It's awesome, isn't it? Everyone uses it, so it must be
good. I have been inside of it, and it seemed nice. It was pretty. It has a
plugin for everything, I hear. I know that a lot of people use it as their
content management system. Wow!

Therein lies the problem. WordPress is just big enough to be used as a
content management system. It does just enough to allow some smaller sites to
utlitize it to manage their whole site. When I look at WordPress, it still
seems bigger than my needs. It does too much. It's got a great community.
I'm sure I could make it do less, or make it do more. It would probably work
satisfactorily. I don't want to be satisfied, though. I want to be stoked!
So, forget WordPress.

Static Blogging Engines

I am a huge freakin' nerd. You know what I want? I want to generate all
of my blog posts via the command line. I think I'd like to run rake blog:post FILE=some_file.mkd to post a new article. I think I
would like my blog to be completely managed from the command line... or, at
least, mostly managed from the command line.

I am progressing to this end already. I write my posts in Vim using Markdown
syntax. Next, I run markdown blog_post_file_name.mkd.
I copy the output, and paste it into the text box in the administration portion
of my blog. I really would be happy doing it all from the command line. On
top of all this command-line geekery, the static XHTML pages -- generated from
such a system -- tend to be fast. Although I don't expect me to ever say
anything so spectacular, were I to ever get SlashDotted or Digged or Reddited
or even HackerNewsed, I would not need worry. That is comforting.

Note:Having not used the following options extensively to create an actual
blog, it feels a bit dirty to criticize, but I'm going to do it anyway. You've
been warned!

Hobix is sort of the big name in static blogging, as far as
Ruby-based systems go. Hobix was initially written by Why the Luck Stiff, and
powers RedHanded (his abandoned Ruby coding website). Hobix is not too heavily
developed any longer, from what I can tell. Following the instructions on
hobix.com for installing Hobix and getting started resulted in an error. It is
recommended to try the latest development version. I will.

Then there's Rassmalog, which has actually been updated recently.
(As of this writing, it was last updated June 8th, 2008. The user guide was
updated on June 22nd, 2008. Wow! Code and documentation updates!
Very nice!) It seems to be a well planned solution, and the comprehensive user
guide is impressive. It offers, initially, email based comments. However,
Rassmalog's site also describes how to use the JS-Kit comment system. I am
sure one could use Disqus as well. More on comments and third party comment
systems later. One final thing to note is that Rassmalog source is available
via a darcs repository.

Last, but not least, the engine called Webby. Not to be confused
with the Webby awards. Note that the name makes searching for obscure blogs
that use Webby difficult, as so many people enjoy blogging about the Webby
awards. In any case, Webby has a few features, it appears, that Rassmalog
doesn't have, such as LaTeX support, and something about Graphviz. These
features are also things that I probably wouldn't use. However, I would
potentially use HAML & SASS, as well as Textile, or maybe Markdown, or maybe
something else. I'm saying it wouldn't be a bad thing to have all of these
options. (Did I not just get done saying I wanted less options? I'm all over
the place here.) Webby does not have a built in comment system of any sort, but
people have used Disqus successfully. I'm sure other systems would work fine
as well. Worth mentioning is that Webby is on GitHub.

Update:
Oh! I just stumbled upon git-blog. It's so
geeky, I certainly can't resist at least trying it, right? Simple posting.
Automatic versioning. Git. It is definitely worth a look, for geekery's sake.

Comments and Comment Systems

I have heard some people question whether comments on blogs are necessary. In
fact, I can think of at least one well-respected card-carrying Ruby community
member who eschews blog comments completely. (I am looking at you, Rein
Henrich.) Why? Perhaps spam became unbearable. Maybe he just
didn't want to deal with comments potentially spiraling out of control and
becoming a 4chan-like dehumanized zone of ridiculousness. Maybe he gets plenty
of feedback via IRC, Twitter, et al. There's nothing wrong with it. I do,
however, disagree strongly.

Blog comments are, often enough, the best part of a blog post. How many times
have you placed a search engine request, visited a blog that seemed to fit your
keywords well, and found that, indeed, the answer you wanted was actually
contained in the comments to the original post, rather than in the post itself?
I love that. It restores one Link-heart worth of faith in humanity and
community. In addition to that, I often learn something from people commenting
on my blog posts. I mean, sure, sometimes what I learn is that there's a new
cream that is guaranteed to make my nights more exciting, but that is
something. What about this comment on one of my blog
posts? Useful. Comments are necessary.

Now that we have established the indispensability of comments, how should they
be posted? Disqus has become a popular solution to comments. Disqus takes
much of the burden of dealing with spam, and the other responsibilities of
managing or writing your own comment system. In exchange? They have your
data. Oh, and your comments are not going to get indexed by, say, the GOOG,
because they are dynamically placed in your page via some Javascript. The same
goes for JS-Kit, and probably others in that niche. I want that data, and I
want it indexed. How are people to find the helpful comments? I am sure you
have a retort readily prepared, dying to flow from your fingertips. Please,
feel free to leave a comment. However, the bottom line is that it doesn't sit
well with me. So, man-in-the-middle comment system? Just say no!

(A couple interesting links related to blogs and comments from people I respect: Tim Bray just before he had a commenting system, and Sam Ruby's advice to Tim Bray on a commenting system. Enjoy.)

I will figure out a way to manage my own comments. This will probably mean comment content ultimately ending up in my inbox before they are made public. I will decide how spammy they are, and then I'll
post them. (Hopefully by typing 'rake comment --FILE=some_file' or something.) There will need to be some initial filters in place, of course. Anyway, we'll see.

So...

I'm looking at Rassmalog and Webby, mostly. I think I might end up going with
Webby, and gluing some sort of hacked together comment script on to the bottom
of the thing. It should last for a while. Maybe a PHP script. Or, a Ruby
script maybe? Will I need a little Rack-based app?

Is this what you would do? Are you perfectly happy with WordPress, and you
think I'm insane (unsurprised, on both counts)? Let me know. Comment.
Please?