First published here.

Emma Barnes taught herself to code after founding her own independent publisher, Snowbooks. She went on to build Bibliocloud, the next-generation publishing system. Now she’s on a mission to promote tech skills within the publishing industry and beyond. Emma is also on the newly-formed BookMachine Editorial Board.

6.50am

Wake up, wonder what day it is and remember – great! It’s the one day this week that I can dedicate to programming. I’m the MD of the indie publisher Snowbooks, and I’m CEO of Bibliocloud, responsible for sales, finance, and customer success, so each day is very different. But I reserve at least one day a week for slipping the needle in and luxuriating in single-minded programming. It so happens that it’s a Saturday, but that’s when the emails stop… context switching is my biggest foe.

8am First coffee, and a read through the opening chapters of the new Sandi Metz book about object-oriented programming in Ruby. It’s great when you find a book that directly addresses the real-world problems you’re facing. I click through to a podcast that she’s on to hear more.

11am: Tests.

Yesterday I discussed a piece of code that needs some attention with my colleague, Andy. The code is a method which returns a collection of external URLs that gets displayed in Bibliocloud. The URLs take you to a book’s Amazon.co.uk page, or Amazon.com page, or Wordery page, or British Library page, and so on — a handy and quick way to check what data is out there in the wild. The method doesn’t have automatic test coverage yet, so I’m going to start by documenting current behaviour. I do this using an integration test which mirrors what a user would do. We use Cucumber which gives us a common language between non-technical team members and programmers. I start by creating a new branch of the code based on our master branch, and create a Cucumber feature which literally reads “When I visit the ‘Autodrome’ page in Bibliocloud, and I click on the Amazon.com link, then I should be taken to the ‘Autodrome’ page on Amazon.com”. I then write some code to translate that into automatic test steps.

1pm: The grand refactor.

The Sandi Metz book has given me a couple more clues as to how this method could be improved, and I’m trying to hold all the concepts in my head so I can look at the problem squarely. Sandi Metz talks about finding the right level of abstraction, so I’m trying to think about which objects this problem is actually concerned with. Is it the validity of the ISBN that is key? Or the destinations themselves? Or the structure of the URLs? Some are built using the ISBN10, others with the ISBN13. Will there be a future case where the URL is built using an ISSN, or a DOI, or an ASIN, or an ISTC, or an ISNI, or an ORCiD iD? If a book belongs to a series, can we say that the book has an ISSN? If its authors have ORCiD IDs, can we use those to create external links for the book? What about linking to the client’s own website?

Or is this a case of YAGNI (‘you ain’t gonna need it’)? All this matters because I want to put the code in the right place, named properly, so that we can find, and change it easily, later. Maintainability, in a large, active system such as Bibliocloud, is probably the most important thing. I start by working with David to sketch out the problem (see the picture), then create a new Ruby class by adding a text file to my local code repository called external_links.rb.

Emma 2

Sketching out the problem

Like the common language provided by Cucumber, the challenge so far has been approached not with code, but with language, reading, grammar, discussion, and story. I reflect — not for the first time — on how relevant publishers’ skills are for programming.

2pm: Lunch

And back to the other Sandi Metz book I’m reading: Practical Object-Oriented Design in Ruby. There’s a good bit on page 93 where she talks about duck typing, which I wonder might be relevant. The idea about duck typing is that “if it looks like a duck and quacks like a duck, it’s a duck”. So my ExternalLinks class doesn’t need to actually be handed an actual book object in order to build the URL. It only expects to be able to get an answer when it asks “what’s your ISBN?” (even if it’s “nope, I don’t have one”). I could similarly give ExternalLinks a display spinner, or a CD, or a cassette audiobook: just so long as it can say what its ISBN is. I’m going to use this idea to write ExternalLinks so that it’s not tightly coupled to the Book class itself – though I’m a bit worried that this is another case of YAGNI. I commit this code to my local branch, glad that I’ve named it “spike/externalurlrefactor” so that I can discuss this approach with my colleagues before considering it for a merge into our production system.

3pm: Iteration.

I run the test that was passing earlier and it fails. Huh. I abandon the integration test and start unit testing at a deeper level of the code. I realise that there’s a requirement I hadn’t understood: some of the destinations are dependent on format, as well as ISBN type. Writing the tests illuminate some of the nuances of the domain and I jump between revising the tests and revising the code (avoiding doing both at the same time which is a recipe for misery).

4pm

Leave to pick up my son, as I do every day of the week. Programming allows for flexible hours. It’s the sort of job that benefits from a bit of percolation, and fitting it around family makes me happy that I can experience life and motherhood as it happens, rather than only working hard for some imaginary future.

8pm

Share today’s programming. Bedtime is done, and I look at the code again, but I think I’ve got as far as my brain will take me today, so I push the code to a branch on Bitbucket, our remote code repository, and raise a pull request with my colleagues. I’ll look forward to discussing this approach with them on Monday and seeing if they notice any glaring or subtle errors, and suggest better ways to structure the code. [Postscript from the future: on Monday, we found no errors as such, but we improved the test suite and I got a lot of clarity about separation of concerns from my code review with Andy.]

10pm

Bit more of that Sandi Metz book. It really is very moreish. Emma 1 Practical Object Oriented Design in Ruby by Sandi Metz 978-0-321-72133-4

Archives

    Most popular

  1. Ruby code and why you should care
  2. A quick look at data visualisation and analysis
  3. Learning how to code, the long way around
  4. It's us in the industry who need to be able to code
  5. Menial publishing jobs are destroying our future
  6. A manifesto for skills
  7. Company news

  8. New website
  9. 2018 Customer survey report
  10. 2017 in review
  11. Prizes galore
  12. And now we are five
  13. Sara O'Connor to join the team!
  14. Product news

  15. 'Continuing to solve real problems': Futurebook 40, London Book Fair 2018 and the Works page
  16. How many authors is too many?
  17. Better ONIX fragments
  18. Advanced advance information!
  19. Schedules page
  20. Publishers hack their own bibliographic data
  21. Case studies

  22. Burleigh Dodds Science Publishing
  23. Zed Books
  24. IOP Publishing
  25. Code

  26. What publishers need to know about Ruby on Rails
  27. A publisher’s guide to APIs
  28. A day in the life of a programmer
  29. How APIs can make publishing more efficient
  30. eCommerce

  31. To go direct, publishers must mean business
  32. Why publishers must use direct sales
  33. Inbound marketing
  34. Don’t outsource your publishing business away
  35. Who has the balance of power over data?
  36. The business case for going direct
  37. ONIX

  38. A hidden benefit
  39. Thema Subject Codes Update November 2017
  40. ONIX. Not very standard
  41. Three ways to do more with ONIX
  42. A non-technical, beginners’ guide to ONIX for Books
  43. How to create a catalogue automatically using ONIX and InDesign
  44. ONIX Changes
  45. BIC, Thema and artificial intelligence...
  46. Skills

  47. Publishers can learn a few things from programmers
  48. Mechanical sympathy
  49. A taste of code
  50. Embrace the code
  51. Strategy

  52. The right tool for the job
  53. The search for publishing's holy grails
  54. Decisions, decisions
  55. Rejuvenation
  56. No computer system can fix a broken publisher
  57. Responsibility, Authority, Capability
  58. Start with Why – How to refine your publishing mission
  59. Creative industries and the division of labour
  60. The real price of a strategy shift
  61. Technical debt
  62. Why ‘easy’ publishing solutions hardly ever are
  63. Five things I've learned since moving into enterprise product management
  64. Managing expectations
  65. A company of one's own.
  66. Sometimes, size matters