Stuart Halloway's complete blog can be found at: http://blog.thinkrelevance.com

Items:   1 to 5 of 358   Next »

Sunday, July 25, 2010

As Justin mentioned last week, here at Relevance we spend 20% of our time on non-billable activities. Here's a peek into some of the activities that went on at Relevance HQ this past week.


Sunday, July 18, 2010

Its always a joy to extend a public welcome to our new team members. Today, I'd like to publicly introduce our three newest compadres:

Jared Pace: Jared came to us from Charlotte, NC where he worked for a startup. He dumped PHP for Ruby four years ago and hasn't looked back. Today he can be found shifting between front and backend development or working on the Ruby library PDFKit.

David Liebke: David is a developer and statistician, and the creator of Incanter, a Clojure-based data analysis and visualization environment. He has built systems in domains ranging from bioinformatics to intelligence analysis, and has a B.S. in cognitive science (UC San Diego), M.S. in applied mathematics and statistics (Georgetown), an M.B.A. (UC Irvine).

Alan Dipert: Alan comes from Rochester, NY, where he studied at RIT and cofounded Rochester's first hackerspace. He's passionate about the Web, Clojure, and is an active open source contributor and advocate.

We are very excited to be growing our team, and expanding the reach of our Clojure services as well. Welcome, guys!


Saturday, July 17, 2010

When we founded Relevance in 2003, when it was just the two of us in Stu's garage, we established a rule that we would dedicate 20% of the "normal work week" to open source development. As the years have passed, and Relevance has grown (22 and growing!), the details of how we implement "20% time" and what we spend it on has undergone some gradual shifts, but the core principle remains: our team and our customers benefit when we spend that time on non-billable activities.

Our current version is that we spend our 20% time on Fridays. That means no client standups, no billable time, no deadlines to meet. But we don't just focus on open source (though that is still a major component). Team members can write or patch open source code, perform charitable work (through code or otherwise), focus on personal growth, work on long-term projects for company betterment, and contribute to the community.

Even though we've been doing this for 7 years now, we've been quite lax about collecting what we've done in one place. With that in mind, here's what we've done the past couple of weeks:


Monday, June 14, 2010

Every now and then, a requirement will come up in a project, that will make me second guess my career choice as a programmer. It usually involves making me go through tedious exercises, never knowing if I'll end up where I want to be along the way.

This happened a couple of weeks ago when one of our projects called for generating PDF reports. The reports needed many stylized elements, layouts, and dynamic graphs. If you've ever generated PDFs in Ruby before, you know that it can be both tedious and difficult using the standard go-to PDF libraries out there. Let's face it, we're web developers. Coming from HTML+CSS-based layouts, writing Ruby code for that stuff is a major pain.

To give you an idea of how heavy it can get, here's an example taken from Prawn. The example was ironically called simple_table.rb.

  Prawn::Document.generate("simple_table.pdf") do 

  table([["foo", "bar " * 15, "baz"], 
         ["baz", "bar", "foo " * 15]], :cell_style => {:padding => 12}) do
    cells.borders = []

    # Use the row() and style() methods to select and style a row.
    style row(0), :border_width => 2, :borders => [:bottom]

    # The style method can take a block, allowing you to customize 
    # properties per-cell.
    style(columns(0..1)) { |cell| cell.borders |= [:right] }
  end

  move_down 12

  table([%w[foo bar bazbaz], %w[baz bar foofoo]], 
        :cell_style => { :padding => 12 }, :width => bounds.width)

end

If you're scratching your head at this point, the code above generates a PDF with two simply styled tables. That's it. If you asked me to implement this in an app, I might have something half-way presentable in an hour. But, I could get a monkey, who just drank a whole bottle of scotch—don't ask about his drinking problem—to write two tables using HTML in less than 5 minutes.

A New Hope

Now some of you may be familiar with PrinceXML, which is a command line utility that will take HTML+CSS and give you back a beautiful PDF. It's even CSS2 compatible and passes the ACID2 test. Awesome. The only problem is that a single server license will set you back $3,800—which is prohibitively not awesome.

Being the open source zealots we are here at Relevance, we set out to find another solution. Tucked away in the internets, we stumbled across wkhtmltopdf. I know what you're thinking; awesome name, huh? wkhtmltopdf uses a WebKit rendering engine to make pretty PDFs out of HTML+CSS. Since it's leveraging WebKit, you get all the tasty CSS3 properties it supports. Ugly PDFs are suddenly a thing of the past.

Goodbye Prawn, Hello PDFKit

We were surprised that none of us had ever heard of wkhtmltopdf, considering how useful it is. When we looked for a Ruby library that leveraged it, we realized it didn't exist. Apparently not a whole lot of other people had heard of it either. That couldn't stand. A couple of open-source Fridays and several gallons of Mountain Dew later, we're excited to announce PDFKit, an open source library that makes working with wkhtmltopdf a snap.

Usage

Inline HTML+CSS => PDF

  kit = PDFKit.new("<h1>Oh Hai!</h1>")
  kit.stylesheets << '/path/to/pdf.css'
  kit.to_pdf # inline PDF
  kit.to_file('/path/to/save/pdf')

HTML file => PDF

  html_file = File.new('/path/to/html')
  kit = PDFKit.new(html_file)
  kit.to_pdf # inline PDF

Remote HTML => PDF

  kit = PDFKit.new("http://google.com")
  kit.to_pdf # inline PDF

What's the big deal?

If this hasn't sunk in yet, let's go over a quick list of wins this buys us:

  1. HTML+CSS - Assuming you're a web developer, there's a good chance that you already know HTML and can work with it efficiently.
  2. CSS3 - We get WebKit's CSS3 support for free. This means effects like drop shadows, rounded borders, transformations and others are super-easy. (Note: effects requiring blur radius do not work.)
  3. Testing - We have tools built into our normal workflow for testing HTML. You can even use Cucumber to drive the development of a PDF with PDFKit.

To give you an idea of how well this fits into our normal workflow here at Relevance, this is how we built out our PDF reports:

  1. Our designer mocked up a sample PDF and converted it to HTML+CSS.
  2. Using Cucumber to drive development, we created a controller action to generate this HTML view of the PDF. (It was just another URL in our app.)
  3. We added a screen-only stylesheet to the HTML that mimics the look of a PDF reader. This allowed us to get a feel of how it would look as a PDF.
  4. Using a bit of Rack Middleware that ships with PDFKit, we can get the PDF version of that web page by simply appending '.pdf' to the url.
  5. We're done. No crazy extra class to handle PDF rendering. No need to spend all day reading through docs to learn the obscure code and magic incantations required to generate your PDF.

Samples

  • PDF of google.com - PDF rendered from http://google.com
  • CSS3 Examples - Sample rendering of common CSS3 effects including border-radius, text-shadow, box-shadow, and border-image. Notice the lack of a blur radius on text-shadow and box-shadow.
  • Sample HTML page with PDF viewer CSS - Example of using a single HTML source to render both a screen version and a PDF version. Uses a media="screen" and media="all" to mark relevant CSS.
  • PDF generated from PDF viewer HTML - PDF generated from sample HTML above. You must tell PDFKit to only use print stylesheets in order to achieve this effect (PDFKit.new(html, :print_media_type => true)).

Go Forth and PDF

I encourage you to take PDFKit for a spin, let us know what you think, and even submit some patches.

If you are pumped about the possibility of using PDFKit on a future project, then I've achieved my goal. If not, I'd ask you to think about what is missing, find out if it's already out there, and let us know how to make PDFKit even better.


Sunday, May 9, 2010

This Friday, May 14, Relevance Inc. is hosting a local bug mash in preparation for the Rails 3 BugMash May 15 & 16 organized by RailsBridge. We tip our hats to this worthy cause and hope to set a modest bar for the participants over the weekend.

Dan Pickett, who is coordinating the Rails 3 BugMash, recently challenged users to give back to the platform that has provided so much win for so many. At Relevance we certainly hear that message. Rails supports a significant portion of our work. It has been and continues to be one of the most progressive and dynamic platforms for programmers today. On top of that, it is fundamentally open source and thrives in a community of mutual collaboration.

In this spirit, we at Relevance pledge to donate our entire Friday to kick-starting the mashing festivities. Those bugs we target will be crushed not for prizes or glory, but out of gratitude to the platform and community. We are eager to see the magic that Rails 3 will produce and we hope to do our part to make that release the best it can be. If you will be in the area this Friday please feel free to stop by our office where there will be food, fun, and lots and lots of coffee.

You can find us at:
200 North Mangum St., Suite 204
Durham, NC, 27701

For more information, please contact us via email at info@thinkrelevance.com or by phone at 919-442-3030.


Items:   1 to 5 of 358   Next »