Sessions is temporarily moving to YouTube, check out all our new videos here.

From Meetup Presentation to Published Book

Paul Jensen speaking at London Node User Group in May, 2017
JustUploaded
 
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

This talk is about Paul's journey from giving a talk on Node Webkit a few years ago, to writing a book on on Electron and NW.js, and the learnings from undertaking the whole project.


Transcript


- Hi, everyone. My name is Paul Jensen. I work and live in London. So my title today is "From LNUG presentation "to published book." This is kind of a little bit of a homecoming. This is the first time I've been here since LNUG moved to these offices. So, basically, there's kind of three parts. How did the book happen, what was it like writing the book, and things I've learnt that I can pass on to anyone who wants to write a book. So I guess, starting with the first part, how did this book happen. Ironically, it happened 'cause I did a talk at LNUG way back, just about three years ago, June 2014. Then it was at the Hixon Village Hall in Hixon Square. We'd used a project called Node Webkit. It was a cross-platform framework for doing desktop applications with html systems, JavaScripts. I really enjoyed using it on the project that we had so I decided to give a talk about it. And then, yeah. It was the talk title. And the app in question was this application for the British Medical Journal. So they have this conference every year and as part of the materials that they often sell, they produce a desktop application that they give to people that wanna buy it. Health organisations around the world. It shows videos from the conference, different session posters, other handouts as well. And I can tell you now, the USB sticks that we used to carry them on and given the retail price, they were probably the most expensive USB sticks I've ever handled in my life. But it was a great app. Originally, it was on Adobe AIR. It used to be the case, you had to make sure that you had Flash installed, you had to make sure that you could find the folder on the USB to load the video it's from and then when we moved to this, we didn't have to do any of that. It was a much nicer experience. So after I gave the talk at LNUG, I put the slides online and I thought, that's nice, I'll put them up on Speaker Deck, which was run by Ordered List who then got acquired by GitHub. Got a couple of views. Well, 580 as of last Saturday so this is about three years time. Compare and contrast that to SlideShare, owned or bought by LinkedIn and then who have since been bought by Microsoft. And a number right down there at the very bottom, 31,141 views. Way more than Speaker Deck. A couple months after I'd given the talk, I'd noticed that a few people on Twitter were posting out the link so now I knew that this wasn't anything to do with my Twitter account 'cause I never make 300 people when I'm on Twitter. So it wasn't really off the back of what I'd done there, it was someone discovering it going, "Hey, this is great, "blah blah blah blah blah." Network effects. I remember checking then that the deck on SlideShare racked up about 20,000 views by about October 2014. So a couple months later, it really, the network effect had kicked in. And I was trying to get on that data for this talk but unfortunately, you can only get up to about a years worth of data on SlideShare that I could access so the data that I looked at from May last year to May this year on that talk, what it shows you is that, basically, the biggest traffic source there is referral traffic. And one of the URLs was being shared the most is a source called Scoop.it, which is like a content marketing platform used both for getting content produced and pushed out there but also for getting funny content going, this is what people want to read about. And in terms of countries, it's predominantly United States, then it's India, Germany, the Russian Federation, and France. And then off the back, I thought that's really good. That's really nice. Then, in December 2014, I received an email from Manning Publications and they said to me, "We're thinking about writing a book "about Node Webkit and we came across you "and we wanted to know if you would like to write the book." And I said, "Yeah, yeah, I'll do it." And then the rest is history. Number Two, writing the book. Now, there's three parts to it. What it takes to write a book, what the process is like, and the challenges of writing a book on both NW.js and Electron and Node.js in general. Now, before I began the process, I had a meeting with various people at Manning on Skype, including one of the co-owners of Manning. And he offered up this really interesting pearl of wisdom. He said to me, "I have worked with Nobel Prize winners "and they will tell you that writing a book "is the hardest thing that they've ever done." And he was kind of going, you still, you still wanna do this? I was like, yeah, yeah, how hard can it be. And I can now tell you, yeah. That is so true. That whole experience of the last two years of trying to write a book has taught me that that is very much grounded in reality. The people at Manning were saying that if you want to write a book, they recommend spending at least 15 hours per week, which is like three hours per workday, trying to work on it. It's a lot of time, it's a huge commitment. Especially if you've got a family or anything like that. And so in my case, my experience, I wasn't so much of a weekday worker, I was more of a weekend worker. So what I ended up doing was I was working weekends, I was working holiday in Iceland, Italy, New York, Amsterdam, on trains, in the car, in lunch breaks at work, every bit of free time I could get. A couple of nice pictures I could show you. So, this Thingvellir Valley in Iceland. It's the largest natural lake in Iceland. It's very beautiful. And I think I was in that car, I was just writing the book so I was like, Oh, the world, it looks nice, uhh. Turns out, those big bridges, that's where they filmed Game of Thrones where they do the sort of Icelandic episodes. So many episodes. Italy as well, very beautiful. Again, I have to write book there. New York, very nice. I gave a talk about SocketStream there at the U.N. Also had to write a book there. And North Amsterdam. Beautiful, picturesque. Also had to write a book and also discovered Strip Off was a Belgian beer, which I'll explain when I post something later. The point is, you cannot underestimate how much time you're gonna need in order to write a book. It really is a huge, huge time-commitment. But anyway, second thing I've learnt is that you've got to identify your core audience early on. You have to write with the mindset of them rather then you. 'Cause you can write and you can go and it makes sense to you. You know, it's a bit like when you write code without code comments and everyone else goes what's this and you kinda go ah, oh yeah. And then you go maybe you should put code comments. But a bit like that. It was sort of like you had to take yourself away from writing for yourself and then think about what do they need to learn, what would they want to learn, what would be useful to them, and then try to condense all of that into a process for writing a book. Thankfully, a team at Manning have lots of people reading it as well so it's not just you writing it and then going, makes sense to me, makes sense to no one. They actually will since check you as well, so that's pretty good. Mind maps are your friends. So this was one of the very, very early mind maps I did. It was, in fact, the first one, about NW.js, how to kind of draw these different themes out about things to cover within NW.js. They kind of help you form threads that you can then expand on and then turn into the backbone that then makes sense for how the chapter's gonna be structured. Also, kind of the material that you want to flesh out in the chapter as well. Really useful process and very essential to kind of writing a book. And then the process. So in terms of what offering tools did I use to write the book? Well, you had two options. You could use an XML format that Manning had or you could use Microsoft Word. And I will now tell you that Microsoft Word is really good. It really is. I was using it on my Mac. As part of writing the book, I bought a Windows laptop so I could test the desktop apps on Windows, it worked seamlessly there. I had it on my iPad, I even had it on my phone. I mean, I was on a train, typing the book on an iPad. It was seamless. A really good experience and also people who have written before with the XML format, whenever they've had to deal with people kind of making, oh, I need to change this bit and change that bit, they found that trying to manage all of that in terms of merging process could be a bit nightmarish. So Microsoft Word is good. Trust me. And then you think, okay, so that's the process. I'm just gonna write some chapters, put them through a spellcheck, and go home to your family. The point is, you gotta write a draught, you give it to your developer editor, she reviews it, in my case, Sophia. She's gonna make some suggestions. She's gonna say this could use a visual, what are you trying to make a point here. Then you basically get this feedback and then she goes, right, let's do another draught. And you go ah. You gotta keep doing that 'til it gets done. I kinda like this phrase that there will be multiple draughts. I think this is what they should hand out to all authors, there will be multiple draughts. You're not gonna get the first draught and it's gonna be like brilliant, done. And then once you've done that, you get a couple of chapters through and you get a couple of people that are reviewing your book during that time and they'll get whole section chapters and they'll read it and they'll make some suggestions and then they'll also feed that back into the process so it does go through a lot of different stages. And then alongside writing the book, you're gonna write some promotional materials such as blog posts and animated visuals. Here's an example on Scotch.io which is a site where you can read loads of tutorials about how to do various bits and bobs. I created this Photo Discovery App with NW.js. Basically, I did it in two parts 'cause there's so much of it. They pay you $250 if you write a big, meaty, chunky thing. And they pay you on PayPal and it's really nice. I did that when I was in Amsterdam. And that was pretty good. And it was a nice way to also promote the book again. By the way, I'm writing a book, that's why I'm doing this. And then the marketing team will take that, they'll push it out to their various channels, get it into the pipeline and then once you're kind of going through that process and it goes on for a good couple months, you go for some technical reviews. And then the technical reviews get into the process and then you realise there will be multiple draughts. There will be multiple draughts. 'Cause they will find things and they'll go, "Well, you haven't tried on this." And you're like ah, okay, go back. And then you get a final sweep of tweaks. So after you've done, gone through the technical reviews and they've said, yep, it's all good, you get a grand person who's gonna look through it, read through it, make loads of sentence changes, and then specifically tailor it to a U.S. audience. So, I tried to use this example of talking about petrol and they went to me, "Oh no, we don't know "what petrol is in America, it's gasoline. "You gotta use gasoline." So it's like funny little things like that where it's like cultural quirks where you're like that won't make sense to an American audience and then kind of finding a better example. And that is, roughly speaking, the process. And now, kind of more towards the technical bits. In terms of the challenges of writing a book on both NW.js and Electron and Node.js in general. The way I can describe it, it's like playing a game of whack-a-mole. You have got to write the book faster than the code can change. And I started the process back in about January 2015. And originally, when I did the presentation it was called Node Webkit. By the time I started to book, it was called NW.js and the reason why is because IO.js happened. So when IO.js happened, which was a community fork of Node.js to get updates into the platform faster, what happened was that had so much momentum going for it that Node Webkit said, okay, we're gonna switch to IO.js. We'll just drop Node. And then Google Chrome switched to Blink, a Webkit fork which was a chance to clean up, do new things. So Node Webkit switched to that and then eventually, there was this GitHub issue that got fielded which was will Node Webkit be renamed? And it's like, you do all this, pushing out all this material about Node Webkit in your presentations, articles, whatever, stuff the SEO, we're gonna rename it. So they renamed Node Webkit to NW.js and this is how the title of the book was initially. That's not the title anymore. And then I decided, okay, I gotta explain what IO.js is because people are gonna be writing about Node they're gonna writing Which one's what, what's this? And I did that and I wrote some material and I put in some chapters and then months later, IO.js merged back into Node.js. All that material was like, okay, let's just go pft. And then, yeah, as I said, there will be multiple draughts and that was one of the reasons why. And then we were getting to around completion of the book around November 2015 and then we were kind of scratching our heads, kind of going well, the book says it's not gonna review, sales aren't necessarily fitting with that. Do you know what's going on out in the market space? And we came across a project called Atom Shell and then it turned out that Atom Shell would become Electron and when we started to dig in to it, we realised that actually, it was kind of like a fork of NW.js. It turned out the guy who wrote it worked on NW.js with Roger Wayne, intel China. He then left, joined GitHub, worked on Atom Shell, and then that became Electron and that's a huge juggernaut. And it was very similar in terms of it's features and it's functionality. You can actually see a lot of similarity in terms of their ecard design, the sort of code that you can run and the guys at Manning just said, hey, how about we write about that too. So rather than writing the book on one framework, I ended up writing a book on two and then the title changed to this. And so we were trying to find the title that kind of fits best with the book which meant that the book took about another year to kind of get done. The other thing I learned, as well, writing a book is you really have to lock down your module dependencies in code examples and never assume that semantic versioning is ever being applied to any of the libraries that you're relying on. So for a good example, originally, when I was writing the book, a lot of it was on Nodes, not Nodes, NW.js 0.10, which was a very stable version. Had been stable, had been pretty much left like that for a year. There was a lot of development that was happening on 0.12, not quite yet into stable and then suddenly, it was like 0.12's here and examples that were working stopped working, had to get them fixed. There weren't tiny changes, there was some significant changes there so the idea of semantic versionings, the concept of whether it's minor or major, doesn't always have the same definition across different projects. So you will find that, actually, you have to lock it down, you really have to lock it down to the bug fix version. And then, in terms of that, learnings. You're gonna need time. And you have to question what you can commit to. So as mentioned earlier on SocketStream, I decided at some point during the book writing, I'm gonna step away from SocketStream. Which was the right thing to do 'cause I'm trying to do an open source project to maintain that at the same time as writing a book at the same time as doing a whole bunch of other things that were going on in my life. It was like, no, can't do that. So you have to cut down, prioritise. And the second one, you will probably gain weight. Now, back in my late twenties, which was a long time ago, I'm actually 38 on Sunday but, I used to be 78 kilos. I remember this. I went to the gym, the weight said you're 78 kilos. And then I went to the gym last week and it said you're 93 kilos now. I hope that the machine's wrong, but it might not be. It might be the actual case. I remember when I was in Amsterdam eating street waffles and drinking Belgian beer and that's probably why. I'm close to that number. And in fact, this is not just applied to me. There's also a fellow Manning author, a guy called Marcus Hammerberg. He's the co-author of Manning's Kanban in Action. He has also gained weight when writing the books that he wrote with his co-author and he talks about how he used to go to cafes a lot and just write it there and so my advice to you is don't write in cafes or make sure that you also don't sit at the desk for hours a day 'cause that's what usually happens. And it is a marathon. But you'll be kind of sprinting at times. So this idea of, people talk about it's not a sprint, it's a marathon. Well actually, there's kind of a third definition. You are going to be doing some continuously and there's gonna be times when you're gonna need to meet the deadlines and you just gotta sprint ahead. Writing is not a linear process where the amount of time equals the amount of output. You may find hours where you don't get anything done, really. And then you find some times when you just speed through and that's why it's so hard because it actually goes against the grain of how we operate as humans. We imagine that effort is kind of continuously producing stuff that you should just, you start to see a picture of what you build overtime and it's not like lots of hours, you go where's, where've they gone. And then you do eventually get there To quote a favourite Chinese proverb of mine, "A man who removes a mountain starts "by removing small stones." It's also quite appropriate 'cause these two frameworks originated in China and there's one guy who's responsible kind of in some ways for both of them. I asked him, can I have your foreware And he said to me, well I'm happy to write it, you might just not grasp it. I said okay, you're the reason that I'm writing these two books. I was gonna write one and it turns out I have to write two now but you know, bam. And that's pretty much it. So here's the book. It's there. I'll put it in case, just to make sure it's tidy. Ta-da. Well actually, it is second prize for the contest today. - [Audience Member] Twitter photo. - Twitter photo. - [Audience Member] Be all on Twitter. - Yep, so my Twitter is @paulbjensen and before I disappear, I just want to quickly plug the company where I work, Starcount, we are hiring. We are a consumer insights company. We have got information on over a billion people, which we use it to help better understand customers and businesses. We have an interesting pipeline of work that we're trying to work on to build a really good way of doing this at massive scale but also much faster. We have a number of roles that we're hiring for. If any of you are interested, come talk to me. I'll be happy to tell you all about it but that's all. I would say, this is a really interesting question because depending on which part of the world, there is a very active NW.js community in China. The WeChatSDK is actually built in NW.js so they seem to have a very, very good grip on that platform and understanding that. But I think here, it's really Electron. Electron has a lot more documentation, a lot more corporate sponsorship through GitHub. One of the apps that we've worked on at Starcount has Electron and that's been good for being able to run on multiple platforms. Our clients are running Windows, really old versions of Windows that allows us to really support Windows 7. XP it doesn't support. If you need XP support, run NW.js but hopefully no one does. 'Cause the last couple of weeks we found out that there's versions of XP running around in places like MRI machines and submarines. That sort of thing. Sorry. So you bought a lot of book, are you on the Manning office programme? How did it influence? So I got quite a few suggestions. Someone said why are you using, I think I tried to use Zepto at one point early on in one of the examples. They said why you using Zepto. You should use jQuery, that's what everyone uses. And I kind of was it's smaller. My decision was because it's a smaller payload in terms of size and then in the end I ended up rewriting it because it's to support both the frameworks with the same code base. I just stripped out the jQuery to pen the seal together. Or Zepto, jQuery dependency. So there were lots of little suggestions like that. There were things where there was some feedback about this example doesn't make sense to me. And then you'd have to revisit it. A few little tweak suggestions. And also sort of just coverage as well. Really, the hardest thing is actually when you are producing, when you get towards the end and you're done and then someone says I want to know more about web view and you have to go I'm really sorry, it's not in the book. But here's a link presentation on that particular API. If you try to cover everything across both those frameworks, I'd still be writing the book and I'd probably have more grey hairs, you know. It'd just be a never-ending story. So you have to make choices in that space I think that's the hard thing, really, when you think you've locked it all down and then you do find that this'll be just a tiny bit more.