Efendi Blog

Yesterday, we updated Testing with CoffeeScript, one of our free MiniBooks, with some fixes to URLs and an update to the code.

I got the email from Jack, I pulled down the changes from the GitHub repo and I re-rendered the book. I then uploaded the new book to S3 and swapped out the old file. I tweeted about it and that was that.

A few minutes later, I received an email from Jack:

Maybe you should put a changelog on the Efendi site for the book?

That was a great idea. I’d actually already been thinking about it, but I’ve been so busy it’s just not come to the forefront yet. Jack’s message was the perfect prompt to get me thinking.

Why don’t books have version numbers?

Hold your horses, I’m not talking about editions. Editions are a great format for print books. An edition almost grants the book the right to go out of date. It’s the publishing equivalent of ditching your 1995 Ford Fiesta and swapping it for a supercharged Aston Martin.

But for eBooks? Did yesterday’s updates really warrant a new edition? Nah, that would be foolish. It’s not that much faster than the Fiesta. An edition is a big deal. It’s a new print run kind of deal.

What I mean by version numbers is the software versioning we all know and love. Why can’t we apply the same rules and structure we do to our software to our books about that software?

Think about it.

• Major Releases become editions. New print runs. 2nd edition. An update chockablock full of changes, new content and updates to the book as a whole, conceptually.
• Minor Releases become large sets of updates, and the publicly stable, downloadable eBooks. There might not be enough to warrant re-printing the book, but it’s definitely worth telling people about and encoraging them to download the book.
• Revisions become the odd changes here and there leading up to a minor release. Yesterday’s changes would be a revision. Nothing huge changed, just a few updates and fixes of errata.

We’re software developers, so we understand release numbers. We correlate them to the software tools, libraries and version control systems we use every day. Since we store our books’ code at GitHub, we can even use tags to organise the code and tie each release to its specific code.

I’m sure there’s some self-publishing author somewhere out there whose done this before. If you’re out there, please get in touch and let us know how it went. We’re interested.

How on EARTH are you supposed to chose a to-do application?

I must have tried a million of them. Some web-based, some native apps, some syncing through Dropbox, some fast, some slow, some pretty, some ugly, some small and lightweight, some cumbersome and feature-rich. They all have funky names like “Things”, “Stuff” and “Do”.

And I’ve ended up using none of them.

The only to-do list system that has stuck for me (excuse the pun) are Mac OS X Dashboard’s Sticky Notes.

For non-Mac people, sticky notes are virtual post-its that you can slather across your screen and spew out arbitrary content into. They’ve become an invaluable tool in keeping me organised.

The reasons they’re so great:

• It’s totally arbitrary. Put whatever you want in there. Ideas to follow up later? No problem. A strict list of transactional, sequential to-dos? Easy. People’s contact details? Hell yeah.
• It’s quick. On a MacBook I hold control and press the left arrow key. Guess what? I’m there. I can jump back and forth to my to-do lists throughout the day. I can quickly add something without breaking myself out of the flow.
• It’s limited. The sticky notes are limited to a set amount of characters. I keep the font size reasonably high so that I’m limited to what I can put down. This ensures succinct, clear expression of my agenda.
• It’s flexible. I add things when I’ve got to do them and take them away when I’ve done them. They’re loosely sorted by priority, but that isn’t important for me. Anything more important I’ll transfer to a real-world dead-tree post-it note and stick it to my computer screen.

So go on, give post-it notes a go! They’re a great alternative to the cluttered and cranky to-do systems of yore. No BS, no pomp or ceremony. Just great to-do management.

We are thrilled to announce the first title in our range of MiniBooks—free, useful and short eBooks—by the rising star of the JavaScript community, Jack Franklin.

Testing With CoffeeScript is a short, sweet and pragmatic guide to writing complex web applications using CoffeeScript and Behaviour-driven Development (BDD). We’ll delve into Jasmine, the core concepts of TDD/BDD and how it all integrates with CoffeeScript. We’ll build a simple shopping cart system; showing us how to use CoffeeScript and Jasmine in tandem and how it’ll help us create more robust applications.

Testing with CoffeeScript is totally and utterly free to download, and available on the Efendi site.

Download your copy today!

Hi there, and welcome to the Efendi Books Blog!

Efendi Books is all about publishing interesting, useful, short books for web developers. However, there are going to be a tonne of topics that we want to talk about - from the mundane day-to-day minutia of running a company to the esoteric journeys we find ourselves on - that just don’t fit in with our product line.

That’s what this blog is for.

We’ll be using it for writing about the company, our goals and where we’re going next. We’ll be using it to announce new books and projects. We’ll be getting our authors to write a few in-depth posts about their field of expertise.

We’ll be talking about start-ups, business, work-life balance. We’ll be talking about PHP, JavaScript and all the latest in cool tech stuff.

It won’t always be useful. It won’t always be well written. But, by damn, it’s going to be interesting.

It’s a Tumblr blog, so feel free to follow us with that little button at the top right. Go on. Click it!

If you’re not on Tumblr, you can follow us on Twitter instead to keep up to date with what we’re up to.

We hope to see you soon. Until then…

Hello, World :-)