I wrote “Fast Feedback Using Ruby” using LeanPub. The original version was published back in 2015. Since I’m updating it to cover the most recent (at the time of this writing) Ruby2.7 and RubyGem versions. I figured, it’s a good idea to leave a trace of my workflow and setup. 🙂
My workflow look like this:
Edit Text (or image) file
Save file to local disk
Commit to local Git repository
Push to GitHub
Generate preview PDF on LeanPub using a (post push) web hook
Have Leanpub automatically push files to Dropbox
Have Dropbox synchronise PDF file to local folder
Restart at 1
Writing workflow using LeanPub, GitHub and Dropbox
Whenever I push changes to GitHub, a new preview of the book is generated and sent to my computer. This means I get frequent and fast feedback about how the newly written text looks.
This nicely fits my working preferences and it also matches the topic of this particular book.
At the “London Tester Gathering Workshops 2015” (also see #LTGWorkshops on Twitter) I offer a workshop “Fast Feedback Loops & Fun with Ruby”. For this, I wanted to give attendees a handout, to make applying the stuff covered easier and it was planned to be a list of brief recipes.
Suffice to say that the handout grew (and it’s entirely possible that this is ‘feature creep’ in action). In fact, it grew to the point that I decided to turn it into an ebook. The book is not done yet, there’s some copy editing to do.
My workshop at the London Tester Gathering Workshops 2015 is announced now! They’re offering an early bird rate until the 18th February, by the way. Find the abstract on the conference page or just read ahead. 🙂
Fast Feedback Loops & Fun with Ruby
Ruby is “a Programmer’s best friend”. Let’s use Ruby to get feedback – including getting feedback automatically – when working on projects. Whether it’s about transforming source code into test results (a.k.a. running automated tests) or generating image files from raw data, Ruby can be used to automate these tasks. Furthermore, it can also be used to automate actually running these tasks, e.g. upon saving a file to disk. Does that sound like a good idea? This session is for you.
I regularly bump into tasks that are…
tedious, if done manually
not done often enough, unless automated
still not done often enough, unless running them is automated, too.
In the workshop we’ll combine some Ruby tools to remedy this situation. In particular the workshop will cover:
Writing a simple Ruby program that does something useful, e.g. turn a markdown file into HTML
Wrapping that in a Rake task
Automate running the task
Knowing how to do this is useful, not only for projects using Ruby as their primary language, but can be handy in all projects.
What is expected:
Some Ruby knowledge; you don’t have to be an expert or anything like that.
A notebook (or tablet) with an internet connection & Ruby installed.
Cool if you’re using RVM, rbenv, chruby or similar
Mac OS X, BSD; Linux & friends are fine, Windows may be a bit problematic.
I’m sure we’ll have a couple of exiting days talking about software testing. And not only talking but also some hands-on stuff using Ruby for fun and (fast) feedback.
Before I publish more information about my workshop, I’d like it to…
Sure enough: If your team’s software fails to provide value now (or in the near future), something’s gone badly wrong. You don’t like your software project to end up similar to this, right?
Smoking remainders of a ‘Biikebrennen’ — don’t let your project end like this.
As Alistair Cockburn explained in “Agile Software Development” software development can be seen as a game played in rounds — and most teams prefer to stay in the game for many rounds.
To me it’s interesting (and a bit worrying) that most of the testing techniques and approaches are focussed on whether the current version of our software…
is in fact the right software and
if it works correctly.
In other words, testing focusses on validation and verification, it concentrates on a relatively short period of time: the next release.
In Alistair Cockburn’s description the order is reversed (see Agile Software Development, 2nd edition p. 37 ff), but in my opinion the order isn’t always that important: I am worried that testing doesn’t consider one of the two values of software.
To my experience, essentially all projects focus on current or near-future behaviour of software, but rarely actively work to keep the software ready to deal with future requirements. I understand that YAGNI (You ain’t gonna need it) may play a role here. But mind you: YAGNI mostly applies to actually implemented features that are not needed. It may also be valid in order to prevent going overboard with too much abstraction and flexibility. In the end, you always need to find a balance between following and ignoring the SOLID principles (a good part of the Clean Coders videos covers this in detail).
Concerning the 1st value of software (according to Uncle Bob Martin), I’m convinced that testing needs to answer questions like this:
Is “the ability of software to tolerate and facilitate such ongoing change” a job purely for programmers?
Can software testers contribute to the primary value? Should they?
If yes, is this part of the job or should we keep out of this business?
I personally think testers should get involved: A tester is somebody who knows that things can be different, as Jerry Weinberg says.
Also, I definitely want my clients, as well as their clients, to be happy with the software I help to develop, not only today, but also in the future, even when most original developers of a software system have left the team or company.
When your project (or product life cycle) comes to an end it should stay in your memory not like the smoking remainders of a fire, but with the bright colours of a great sunset.
