I’ve been fortunate enough to appear on a podcast with the excellent Coding Over Cocktails team from Toro Cloud. we got to talk about some of the ideas discussed in my Logging In Action book. You can check the podcast out via their website which includes all the episode details and links to all the platforms that host the podcast. There have been some great previous guests such as Luis Weir (my old boss), Chris Richardson of Microservices.io, Matthew Reinbold from Postman, Sam Newman to name just a few.
So why is worth snagging a download? Well, WebAssembly (Wasm) is the new way to deliver browser-based solutions to a client without having to develop with JavaScript. As a result, you have the chance to reuse more of your existing code. It also has the benefit of having been precompiled to a binary form, offering code security and compact download. But Wasm also has been seeing adoption in back-end server solutions as well, particularly for feature extensions, etc.
Christian Posta and Rinor Maloku’s book with Manning, Istio In Action has just been published. I’ve previously said it’s a good book, and that’s not surprising given Christian’s role at solo.io. When the final chapters became available I started to go through it in more detail and built a mind map (As with the recent review of Kubernetes best practices). The map can be seen below.
As you can see the map is very substantial reflecting on the depth and value of the book. For those who look at the maps, may notice there are a couple of chapters not fully mapped. I will update the map to fill those gaps in, but given they focus on monitoring and observability, I was less concerned about those areas given my own writing. The book’s exercises are very much built around using Docker Desktop making it very easy to spin up the examples and exercises. If you want to know about Istio Service Mesh on K8s then I’d recommend it.
Reading through the book, I’ve learned details that I was not entirely aware of, for example the integration of non K8s workloads into the mesh. The tuning of Istio to keep it highly performant with a lot of workloads.
The final leg of getting the book published has taken a lot longer than had been expected. But we’ve just been told that the book has been sent to the printers. This means:
final eBook will be available from Manning in about 1 week
Preordered print copies of the book will be dispatched in about 2 weeks
The alternative ebook formats for mobile readers e.g. kindle etc available in about 3 weeks
The book will become available to purchase from other book stores such as Amazon in 3-4 weeks
Safari Books Online and Apple stores will have the ebook in 4-5 weeks
It also means the project from a writing perspective is complete. But we’re starting to look at the additional examples we’ll add to the GitHub repo. These will be dependent upon the book.
Through my day job at Capgemini UK I have regular dealings with Flexagon as we use their FlexDeploy product with a number of customers (as we do recommend the product). Recently I was invited to contribute to a paper being developed by the Flexagon team. The fruits of the collaboration are now available at https://info.flexagon.com/ebook/devops-for-developers. The Flexagon team have done a nice job with it, and we’d recommend taking a look if you’re wanting to know more about DevOps and CI/CD.
The paper is completely free of sales pitch – completely devoid of product references which makes for a good read.
We’ve got the peer review comments back on the completed 1st draft back of the book. So I’d like to take this opportunity to thanks those who have been involved as peer reviewers, particularly those involved in the previous review cycles. I hope the reviewers found it satisfying to see between iterations that their suggestions and feedback have been taken on board and where we can.
The feed back is really exciting to read. Some tweaks and refinements to do to address the suggestions made.
The work on the Kubernetes and Docker elements and the chapter which has become available on MEAP has helped round that aspect off. But importantly, the final chapters help address the wider challenges of logging, and some of the feedback positively reflects this.
To paraphrase the comments, we’ve addressed the issues of logging which don’t get the attention that they deserve. Which for me is a success.
Last night saw the final chapter of Logging in Action with Fluentd go back to my editor. The next step is that Chapter (and others I hope) will go to MEAP, so early readers not only get the final chapter, but also the raft of improvements we’ve made. Along with that, the manuscript goes for a full peers review. Once that’s back, its time for a round of edits as I address the feedback then into copy editing and Manning sign off review.
As you might have guessed, we’ve kept busy with an article in the 25th edition of OraWorld. This follows Part 1 talking about GraphQL with a look at considerations for API Security.
In addition to that we’re working on a piece around automation of OCI management activities such as setting up developers, allowing them a level of freedom to experiment without accidentally burning through all your credits by spinning up Exadata servers or 500 node Kubernetes clusters.
We might even have some time to write more about APIs and integration.
I wrote a blog after completing my first book with Robert van Mölken about what was involved. That post can be seen here. It focussed on the processes with Packt and how Robert and I worked to try to ensure the book felt consistent despite the two of us writing.
Writing Logging In Action was a solo project for a different publisher. It seems like an opportunity to share some fresh insights.
Time and Effort
Surprisingly the time between signing the contract and the manuscript being completed ready to go through the final production process didn’t vary hugely roughly 15-18 months. The final steps of preparing to go to print did take longer, in part down to the number of extra steps taken by Manning to ensure the book was polished. Upon reflection, I think that is at least partly down to the fact you need the chapters to need to flow, particularly when one chapter leads directly to the next. So you do get periods of respite until your co-author has got sufficiently far enough with their writing to enable you to start the next part. Writing solo, as soon as one chapter is completed you’re into the next, so no periods of respite.
When it comes to the amount of actual time involved. That is different, I didn’t keep track exactly. But knowing what I typically did each week and roughly how many quiet periods I had I think it works out to be 300 hours give or take 50 hours. That sounds a lot, but then if you look at it as 1 hour per page it doesn’t seem too significant.
Using Time and Self Discipline
The way time is used has been a little different, when co-authoring you have to allow time for coordinating and supporting each other, peer-reviewing writing pushing each other along in terms of keeping to plan. The Manning development team are pretty good at keeping you moving without it feeling like you’re being chased, and will provide constructive and supportive feedback. But your co-authors will know the subject matter very well and know what your best work is like, so are able to challenge you when peer-reviewing the work. When we wrote the API book, I remember one of my colleagues reviewing a chapter and coming back saying it was a solid chapter, but I know you have explained these ideas more clearly. When I went back over the chapter, I could see what they meant. As a result a better book.
The bottom line is it can be difficult to bring a critical eye to your own work, particularly soon after have written it. But you do need that self-discipline when working on your own. This is where the Manning editorial team really stood out.
The book is published, that’s the end?
It is easy to think that’s the end of things, and certainly in terms of solid writing it is. But after all the invested effort in writing it. You might as well help promote the book and take advantage of the reputation of being a published author. This means presenting on the subject of your book. The book will provide a level of credentials & credibility to the subject you’ve written about. Despite being an introvert (which is why I take pleasure in the writing process) getting through the pre-presentation nerves, feelings of imposter syndrome once on stage and talking about your subject can be a rush, particularly as you finish. The personal payoff from presenting can come after the event, when someone who has seen your presentation says to you afterwards, that really helped me, or they really enjoyed or found the presentation thought-provoking.
If presenting is too much then these days there are other paths available, such as writing articles for journals, participating in podcasts. Having participated in several podcasts if you have a good host, this can be good fun.
What do I get out of writing?
The benefit of royalties certainly won’t replace a typical developer’s salary, unless you’re really lucky. Even with mainstream publications, only a small proportion of authors are successful enough for it to become their day job. But, there are indirect benefits. If you want something to put your CV above many others – then a book will really help. This is often why a lot of freelancers write books – it helps provide credibility over others. There is no doubt that my writing has made a difference to a change in job. I suspect that joining Capgemini and my next move has been a lot easier because of it. Not to mention, I’ve known clients like the idea that within the team they’ve engaged are people with credibility beyond just the supplier. Depending upon your employer, the marketing value for them to employ you (or me) as an author (and by implication an SME) add differentiation as well.
Writing solo again?
I’ve heard technical book authors say, never again once they’ve been published. A few I know have written multiple books. Given the experience, I think co-authoring is easier. But the gratification of completing a solo effort is so much greater.
The technical book landscape is shifting, technology cycles seem to be accelerating (or is it that I’ve reached an age where time seems to go by so much quicker) which is impacting a book’s shelf life. The ability to provide, receive and expect more interactive engagement is evolving – LiveBooks, Katacoda etc. The need to consume smaller pieces across multiple sources is growing as we need to build new skills, but don’t want to start from scratch (as I described here for example).
There is no doubt I’ll get involved in another book project. But a solo writing project will probably be smaller so we can shorten that development cycle.
The book has had a title change as Manning found that links the book was clashing with other solutions using the term ‘Unified Logging’. With the name change it helps bring the book inline with the Manning naming with their In action series. This means the book website is now https://www.manning.com/books/logging-in-action.
With the name change we’ve agreed that there should an additional chapter added. As I’d written the book with a view that everything we cover applies to both modern solutions such as Microservices coming from the CNCF camp but equally relevant to more traditional IT landscapes. Within the book we have explianed how things are positioned and can be used in Kubernetes, but it was agreed with our editorial team that not tackling the configuration of Fluentd with Kubernetes and Docker was to an extent ignoring a key community that will be using Fluentd. So the new chapter will be introduced to address this aspect.
In terms of progress we’re into the 1’s – 1 Chapter to start (the new one), 1 Chapter back from the Technical Editor (Logging Best Practises) – some edits to be done, 1 Chapter now with the editor (How To Create Custom Plugins), 1 Chapter being finished (Logging Frameworks) and finally 1 peer review cycle to go.
Given the lovely review comments that have been quoted on the book’s page. I can only recommend if you have an interest in logging and monitoring then check it out through Manning Early Access Programme (MEAP).
My blogging is way down compared with only a post about OKit – OCI Design (on Windows). It largely comes down to lots of work on our Fluentd book. Chapter 6 is now available in the MEAP. As the promo info says …
Last chapter, we touched on the use of the Filter directive. But that was just the tip of the iceberg! In Chapter 6, we’ll plunge below the surface, exploring the when, why, and how of applying filters to give us more insight and precise control over events.
Promo Email from Manning
Earlier chapters have been tweaked, with some additional improvements which will make the live reading experience better.
Another chapter and an appendix should be finding their way to MEAP very soon as it was handed over by our project editor. That will make it seven chapters available, and all the appendices.
Whilst the peer review is taking place the chapter covering plugin development is progressing. The development work has got the basics of the output plugin with log events being stored in Redis and the input being worked on as well. If you want a peak, keep an eye on my GitHub repository (here).
But is isn’t all writing…
I presented on Twitch – you can catch that at https://m.twitch.tv/videos/809295979 I’ve been offered the opportunity to present again, so keep an eye out for something next year.
We recorded a podcast with the excellent guys over at Adventures In DevOps. We don’t have the exact date for the podcast to be released, but I imagine it will sometime during Jan 2021. I’d recommend checking out the podcasts. I’ve been dipping into their back catalogue of recordings and the team ask some really thought provoking questions.
If that wasn’t enough, we’ve been fortunate enough to have some time to talk with leading members of the Fluentd and Fluent Bit projects which was a real pleasure. Hopefully, as we leave this horrendous year behind we’ll get to talk and possibly collaborate some more.
You must be logged in to post a comment.