The #juliabook is dead, long live the #juliabook!

If you are reading this, chances are you have been following my work on Julia in Action, formerly known as Learn Julia and affectionately referred to by me as the #juliabook, developed with Manning and currently in pre-publication access (MEAP). You might have been a reader of Learn Julia the Hard Way, which is the Github repository from which the book has emerged. Or you may even have bought the MEAP.

In the latter case, you might also know that Manning has decided no longer to pursue the publishing of Julia in Action. This was their decision following their assessment of the Julia market, the language, the community and the books on the market about Julia. I believe this was an incorrect decision, as incorrect as it was when it was first brought up at the end of last year. Back then, I fought for the book, and I managed to save it, or at least give it a stay of execution. We agreed that Julia in Action would be targeted to be published at Julia v0.8, and delivered at this slower pace. But when a few weeks ago, the publisher has informed me that they are once again thinking of cancelling the book, I could no longer save it.

Coming full circle

It is important to recall the origins of this project, and where it all began.

When a few years ago, I put together some of my own notes about learning the fledgling Julia programming language on Github, I couldn’t possibly have imagined the wild ride that would eventually take me full circle to the same Github repository where it all begun.

In the two years since I started that repository, it’s been starred over 330 times, making it – according to my brief calculation – the seventh most popular Julia related repo. Not bad for something that began its life as notes I typed up as I was playing around with Julia between two jobs. Before I knew, I had a book deal from Manning to develop Learn Julia the Hard Way into Julia in Action.

A lot has happened in those two years. As the Julia language kept finding its sea-legs among technical programming languages, some of the initial enthusiasm for it waned. There are still basically no exclusively Julia jobs. There isn’t a single major application or system that runs Julia. It hasn’t replaced or supplanted Python and R to the extent many have hoped. But in what matters much more to me, it flourished: it created a great community, full of kind and supportive people and enthusiastic developers.

In those two years, I also marked my official five-year survival from HLH, making me statistically a ‘survivor’. I’ve gone from strength to strength, when I had a less than 10% chance to make it to that point without a relapse. I have also been in the meantime diagnosed with multiple sclerosis. What I thought I’d shake off (after all, have I not survived much worse before?) was actually a bigger physical and emotional struggle than I thought it would be. In the meantime, I also changed jobs and moved to a foreign country. Amidst all this, working on the #juliabook was one of the few fixed points in my life, a source of consistency and a constant ‘thing to do’.

At risk of sounding emotional, this book is my baby. And I am not going to let it disappear into nothingness.

Future Present

I have negotiated a settlement with Manning that would allow me to retain a range of rights in the text, including copyright in the manuscript and the visuals. I could, at this point, look for another publisher or knock on the door of a large publisher I know who are struggling with their Julia book and their authors. But the fact is that this has been the Community’s book all along. It would have been dedicated to the two greatest sources of impetus for me to write about Julia: the Julia community, and my wonderful wife Katie. I intend to take this dedication to the community seriously.

For this reason, I have resolved to gradually merge the contents of the #juliabook and LJtHW, creating a much more extensive, well-illustrated, colourful and comprehensive online textbook on Julia that will be free to everyone (under the Creative Commons BY-NC-SA 4.0 license).

I believe this is not only the right thing to do towards the community, whose help has meant so much for me throughout, but also to those who invested into the book by buying the MEAP edition. While you should be receiving a refund from Manning, I would like to acknowledge your help in making this book happen. For this reason, if you would like to be publicly acknowledged, please send me a message with proof of purchase of the MEAP, and I will make sure you are acknowledged for your support of this book.


I have spent much of the last few days working out the logistical details of making this happen. I have devised a plan that would involve integrating what is currently written in both sources, revising it and then amending it with actionable examples in Jupyter notebooks.

Completion schedule for the #juliabook, with an estimated completion date on 15 March 2018.


The Community’s book

I believe very strongly in the freedom of information and in access to information about the technologies that run our lives – to everyone. The more I think about it, the more I see what an opportunity Manning’s decision to abandon the #juliabook has given to the Julia community itself. What we need is not another $50 book reflecting one guy’s perspective on the language, but rather a way for the community at large to co-create a tool that will be out there and available for all who wish to get started with Julia.

Many have recently commented on Julia’s doldrums. Some even went so far as to give up on it. And it’s true. Dan Luu is spot on in his criticism of Julia, so spot on that even John Myles White, the guy whose writings on Julia got me really interested in the language, agrees with him:

A small team of highly talented developers who can basically hold all of the code in their collective heads can make great progress while eschewing anything that isn’t just straight coding at the cost of making it more difficult for other people to contribute. Is that worth it? It’s hard to say. If you have to slow down Jeff, Keno, and the other super productive core contributors and all you get out of it is a couple of bums like me, that’s probably not worth it. If you get a thousand people like me, that’s probably worth it. The reality is in the ambiguous region in the middle, where it might or might not be worth it.

What if we could make that a thousand people? What if we could get more people involved who would not have to piece together what’s what in Julia? What if we could dramatically reduce the barriers to entry to Julia, and do so without the $50 price tag? If Manning abandoning my book means that I can be just a tiny part of that, then that e-mail I got the other day from my editor might just have been the best news I’ve received in a long, long time.

cookiecutter-flask-ask: a quick(er) start to Alexa skills!

If you develop for Amazon’s Alexa-powered devices, you must at some point have come across Flask-Ask, a project by John Wheeler that lets you quickly and easily build Python-based Skills for Alexa. It’s so easy, in fact, that John’s quickstart video, showing the creation of a Flask-Ask based Skill from zero to hero, takes less than five minutes! How awesome is that? Very awesome.

Bootstrapping a Flask-Ask project is not difficult – in fact, it’s pretty easy, but also pretty repetitive. And so, being the ingenious lazy developer I am, I’ve come up with a (somewhat opinionated) cookiecutter template for Flask-Ask.


Using the Flask-Ask cookiecutter should be trivial.  Make sure you have cookiecutter installed, either in a virtualenv that you have activated or your system installation of Python. Then, simply use  cookiecutter gh:chrisvoncsefalvay/cookiecutter-flask-ask to get started. Answer the friendly assistant’s questions, and voila! You have the basics of a Flask-Ask project all scaffolded.

Once you have scaffolded your project, you will have to create a virtualenv for your project and install dependencies by invoking pip install -r requirements.txt. You will also need ngrok to test your skill from your local device.

What’s in the box?

The cookiecutter has been configured with my Flask-Ask development preferences in mind, which in turn borrow heavily from John Wheeler‘s. The cookiecutter provides a scaffold of a Flask application, including not only session start handlers and an example intention but also a number of handlers for built-in Alexa intents, such as Yes, No and Help.

There is also a folder structure you might find useful, including an intent schema for some basic Amazon intents and a corresponding empty sample_utterances.txt file, as well as a gitkeep’d folder for custom slot types. Because I’m a huge fan of Sphinx documentation and strongly believe that voice apps need to be assiduously documented to live up to their potential, there is also a docs/ folder with a Makefile and an opinionated configuration file.

Is that all?!

Blissfully, yes, it is. Thanks to John’s extremely efficient and easy-to-use Flask-Ask project, you can discourse with your very own skill less than twenty minutes after starting the scaffolding!

You can find the cookiecutter-flask-ask project here. Issues, bugs and other woes are welcome, as are contributions (simply raise a pull request). For help and advice, you can find me on the Flask-Ask Gitter a lot during daytime CET.

cookiecutter-flask-ask is, of course, Swabware.