Tag: automation

Generating a Preview on LeanPub Using Rake

book Ruby Uncategorized No Comments

While working on the e-books I published on LeanPub, I have developed a number of useful approaches to get fast(er) feedback on how the book looks. Two earlier blog posts describe some of this:

While this provides a nice feedback cycle, sometimes I like to generate a new preview without pushing to the GitHub repository I am using to share the book content with LeanPub. This happens, when I change settings on the Leanpub site that affect the generation of the book (the title image, font faces and sizes are set via the book’s pages on LeanPub, not a configuration file in the repository).

While I could click thought the UI and navigate to the page where I can generate a new preview, I prefer using a command line tool from my local machine: Rake

The Setup

A warning: The LeanPub API documentation says: “Using the Leanpub API requires a Pro plan.“

To use the LeanPub API, an API key is needed. The link to the API documentation above has information where to get that key. To easily use this API key, I store it in an environment variable LEANPUB_API_KEY.

The Rake Task Definition

In the repository of my book I have a Rakefile containing the task definitions. Here’s the one to trigger the generation of a preview on Leanpub:

require 'rest-client'

namespace :leanpub do
  LEANPUB_BASE_URL = "https://leanpub.com/<book_id_on_leanpub>"
  namespace :preview do
    desc "Generate new Preview on LeanPub"
    task :generate do |t|
      what_to_generate = t.name.split(':')[1]
      url = "#{LEANPUB_BASE_URL}/#{what_to_generate}.json"
      begin
        RestClient.post url, api_key: ENV['LEANPUB_API_KEY']
      rescue RestClient::Exception => e
        puts "Got error #{e.message} in", caller.first
        exit 1
      end
      puts "Generation of preview was triggered"
    end
  end
end

I can now easily generate a preview, without having to leave the IDE I’m using to write the book (or the command line) using this:

$ rake leanpub:preview:generate
Generation of preview was triggered

The Rakefile will likely change, for example to also support publishing a new version of the current ebook, or to make it more flexible in order to handle different ebooks.

Update (8. Jan 2021): It turns out that this is really useful: LeanPub provides a web hook to generate a _sub set_ of the book that also generates the PDF (but not the ebook and mobi file). This saves some time from pushing to GitHub to being able to review the generated file. I now use this web hook most of the time.

I now only generate for full book in all formats when I want to check that the book looks good enough to be published. Since this happens less regularly than pushing to the repository, I use the Rake task.

Presentation at The Bonn Agile Meetup About Test Automation

Testing 1 Comment

Monday night I presented about “Test Automation” at the Bonn Agile Meetup, a group of now more than 100 people interested in all kinds of topics related to, well, ‘Agile’.

First of all, thank you all for coming! With a bit more than 30 people, I heard that this was the largest number of people joining the Meetup. Second of all a big thanks to the folks at Doo for providing a great location, support, beverages & food. I really enjoyed the hour speaking & coding as well as the great 3 hours of discussion & talking afterwards.

Without further ado, these are the (German only) slides: test-automatisierung_bonn-agile_april-2012.

As the main technical part, I presented my preferences about organising automated test (or checks, if you prefer that term) in Cucumber:

  1. I like to have the scenarios to be as high level and close to the ‘business language’ as possible.
    If a user with certain rights or a given role needs to login, I’d rather note that role/right, not an explicitly given username & password in the scenario file.
  2. I also prefer the step definitions to be as clean as possible. Sure, we likely need to refer to a concrete user name here, and be clear about what steps (on the application level) are done in which order. Assertions (of whatever kind you prefer) is also what I like to see in the step definitions: What is actually done and what the expectations are — that’s what I prefer here.
    Code I don’t like in step definitions: Statements that create a browser (headless or otherwise), HTML or XML parsing code, SQL statements of whatever kind…
    Whenever that appears in the step definitions, I lose track of what I’m about to check.
  3. As the details of dealing with the output of the system under test have to go somewhere, I usually create classes and/or modules wrapping all the details. This code actually implements the interface used to communicate with the tested system.

I didn’t come up with all this, but find it a good way for me to separate technical from business levels. Most of the ideas in fact come from @unclebobmartins Clean Coders videos (and his books about the same topic).

© 2012-2023 Stephan Kämper — Mastodon

MENU

Navigation

%d bloggers like this: