Christian Heilmann

Posts Tagged ‘book’

Book idea: The Vanilla Web Diet

Tuesday, October 30th, 2012

I right now feel the itch to write a book again. I see a lot of people buying books and making a living selling them and I feel that there is a space for what I have in mind. I also don’t see how I could cover all the things I want to cover right now in talks or blog posts. It is presumptuous to think you’d follow a series of them so using a book form with code and possibly a series of screencasts seems to be the right format.

vanilla cupcakes

I have a few outstanding offers by publishers but having my first publisher just hand over a second edition of my first book to someone else without waiting for my yay or nay makes it less interesting to me to go through the traditional publishing route. Whilst I am pondering other distribution offers (and if you have some, talk to me) here is what I am planning to write about:

The web needs a diet

Web development as we know it has gone leaps and bounds lately. With HTML5 we have a massive opportunity based on a predictable rendering algorithm across browsers. CSS has evolved from removing the underline of links and re-adding it on hover to a language to define layout, animation and transformations. The JavaScript parts of HTML5 give us a much simpler way to access the DOM and manipulate content than traditional DHTML and DOMScripting allows us to.

Regardless of that, we still clog the web with lots and lots of unnecessary code. The average web site is well beyond a megabyte of data with lots of HTTP requests as our desktop machines and connections allow us to add more and more – in case we need it later.

On mobile the whole thing looks different though and connectivity is more flaky and each byte counts. In any case we should be thinking about slimming down our output as we put more and more code that is not needed out, adding to a landfill or quickly dating solutions that will not get updated and fixed for future environments and browsers. We litter the web right now, and the reasons are:

  • A wrong sense of duty to support outdated technology (yes, OLDIE) without really testing if our support really helps users of it
  • A wrong sense of thinking that everything needs to be extensible and architected on a enterprise level instead of embracing the fleeting nature of web products and using a YAGNI approach.
  • An unwarranted excitement about technology that looks shiny but is not to be trusted to be around for long

Shed those kilobytes with the fat-free vanilla approach

In the book I’d like to outline a pragmatic and backwards compatible way of thinking and developing for the web:

  • We start with standards-compliant code that works without relying on hacks and temporary solutions
  • We improve when and if the environment our code is consumed in supports what we want to do
  • Instead of shoe-horning functionality into outdated environments, we don’t leave promises of functionality when it can not be applied
  • We write the right amount of code to be understandable and maintainable instead of abstracting code to write the least amount without knowing what the final outcome is

The book will be opinionated and challenge a few ideas that we started to love because of their perceived usefulness for developers. In the end though I want to make people aware of our duty to produce the best products for our end users and to write code for the person who will take over from us when we want to move on to other things.

The book will teach you a few things:

  • How to build with instead of just for the web
  • How to use what browsers can do to build without writing much code
  • How to avoid writing code that will fail in the near future
  • How to not make yourself dependent on code you don’t control
  • How to learn to let go of “best practices” that made a lot of sense in the past but are not applicable any longer
  • How to have fun with what we have as web developers these days without repeating mistakes of the past
  • How to embrace the nature of the web – where everybody is invited, regardless of ability, location or technology

What do you think? Tell me on Facebook or Google+.

The book that never was – the why of YQL

Wednesday, October 27th, 2010

YQL is great, it is a technology that turns the web into a database and allows you to mix and match and filter before writing your first line of code. It also allows you to release an API without any infrastructure, knowledge of authentication and access control. In essence you can use Yahoo’s server infrastructure and processing power to unleash the awesome of the web into your products or the awesome of your data on the web.

There is a truckload of documentation, forums and blog posts about YQL on the YDN web site but as it is people love books so I was asked to write a YQL guide for Yahoo Press.

Specifically I was asked to write a demo chapter for the book to pitch to O’Reilly over Christmas, which I did. I then waited for the paperwork to be signed off and so on and time came and went until I was offered to write the YQL Guide for O’Reilly together with my colleague Tom Hughes-Croucher (as he had also sent in a proposal for a YQL book). We agreed on some collaboration and then Tom moved on to write another book.

As I am leaving Yahoo and yet have to see a contract about this book to sign, I announced that I am not going further with this project. Being the techno-hippie that I am though I thought it would be a waste to not give the first chapter to the world, so here it is:

You can read the chapter online, download the PDF or browse the “source” on GitHub in case you want to translate or quote it. I licensed it with Creative Commons so go nuts!

The developer evangelism handbook is now available in print from

Monday, November 9th, 2009

When I released the developer evangelism handbook it was quite a success but a lot of people asked for a print version. I’ve asked a few publishers if they are interested but the common consensus was either “too short” or “too niche”. I’d be happy to prove them wrong so I used for publishing the book myself. So if you are not a fan of the free online version, go over there and get your copy.

The Developer Evangelism Handbook is now available on by  you.

My new book idea – “Don’t do it again”

Monday, March 16th, 2009

I am a massive fan of Steve Krug’s “a common sense to web usability” book called “Don’t make me think” and want to write a book that fills the same gap for developers.

Right now the books available for developers are very technology centric and make you learn a lot about a certain job but nothing about how your delivery meshes with the rest of the team. This makes developers a needed asset but nothing that people listen to a lot when it comes to architecture or future progression. Those books sell well and make us feel good as we have improved our technical skills. However as human beings and professional employees we need to break out and get access to calling the shots where our expertise is needed. Our own navel-gazing and non-interest in matters outside our remit prevents that.

Over my career as a developer I found that most improvements of products don’t happen because of top-down decisions but because of geeks on the ground putting things in that will make their lives easier in the future changes that will inevitably come. Our work environment changes constantly and the only way to really build products that are good for us and the people we want to reach is by doing things right the first time and not un-do what we’ve done beforehand or tack extras on in a second step.

I want this book to be a helper to read through in a short period of time before starting a new job or project. I don’t want to give truths or examples that are outdated by the time the book is out but instead want to make developers aware of the power that they have if they work smart instead of delivering only what is needed.

Proposed book outline

1) One of your best assets is your laziness

This chapter will talk about being cleverly lazy – working in the right way upfront to make sure your workload will become less and less the longer the product will be under way. It will cover using the right tools, finding the right resources and organizing your time the way you feel most comfortable and become the most effective.

2) Don’t build for yourself but for those taking over from you

This chapter is all about clever developers aiming for making themselves redundant to the process over time. As a clever developer you want to improve and deliver demanding products and not get stuck in doing the same work over and over again and get stuck in maintenance of products you don’t feel enthusiastic about any longer.

3) Clever recycling is the key

One of the biggest obstacles you find as a developer is to fight your urge to deliver everything yourself. This keeps us from improving as a professional group. All of us have a clever idea to contribute but instead of merging them and finding consensus we all take our small idea and blow it up and stick some feathers on it to make it appear as the best thing since sliced bread. This chapter will talk about how using and building on top of existing solutions will make you a better developer and profit your profession as a whole making it easier to earn more money in the future.

4) Build what is needed and keep it modular

As developers we tend to think in finished products, not in smaller, re-usable components. When we develop something we are very much inclined to put in feature after feature and considering edge cases instead of delivering a solid foundation and add edge-case extensions when and if they are needed. The danger with this is that we deliver products over and over again that over-deliver on the feature front but lack the one single feature an implementer needs – the basics are not covered. This chapter will explain how to avoid this.

5) Aim for excellence

One thing that makes us stop progressing is that over time people are so disillusioned about what they can achieve in a professional environment that “making things work” is the main goal. This is terrible and the only way out is to challenge ourselves to deliver the best product out there and aim for excellence. Only if we challenge both ourselves and the people we work with we’ll be able to deliver products that change people’s lives. This includes planning bigger from the beginning. A product that is built with bad accessibility and no internationalization options might as well not be built.

6) Your product is defined by your users

This is a very important chapter for me and overlaps a bit with the feature-fetish of the previous chapter. The main ingredient of a successful product is how it fares with the audience it is intended for. Our users – regardless of ability, location or sophistication are what make and break our products. We need to know who uses our product and how they want it to work. A great example is Twitter. The use of Twitter has changed massively since its conception and its success is largely based in looking at its users and enabling them to do things they want to do.

7) Your biggest challenge is communication

This chapter will deal with how you communicate best with others, how you get seen, heard and listened to in a world as disconnected as IT is right now. Developers are considered the doers, implementers, not the ones with the overall plan. As developers however we feel exactly the other way around and many a time find ourselves saying that if we had had the chance to stop a decision before it happened the product we build would be much better. There is truth to that, but also a lot of prejudice. The right communication is built on consensus and knowing the deliveries of each of the people involved in the product.

8) Your biggest weapon is enthusiasm

The main point about being a good developer is being enthusiastic about what you do. If you build something you have no connection to you won’t be delivering an excellent job – no matter what you do. Enthusiasm is one of the most contagious things on the planet – if you do it right. This chapter gives you ideas and explains ways how I got myself enthusiastic about products even when on first glance they looked like a drag to do.

This is the main idea for the outline. I am planning to write a small book that can be handed over to new developers, heads of department and consulted at the beginning of a new project.

Delivery considerations

I have a few publishers interested and I am thinking about the format right now. One crazy idea I am having – and considering my very full agenda this year is a very good idea is to deliver the chapters as a series of talks and write the chapters as a follow-up after feedback from the audience. These talks could become part of a download package with the book.

What do you think?

The Art and Science of JavaScript arrived

Thursday, January 24th, 2008

My chapter in The Art and Science of JavaScript

My latest contribution to the ink-on-dead-tree media is a chapter for Sitepoint’s new book
The Art and Science of JavaScript. I’ve been giving details about the history and the contents of the book in detail in a blog post on the Yahoo Developer Blog and while it has been out for a while I just got my free copies today, hence the delay.

My chapter in detail covers how you can build a badge to display information you stored on another site in yours without having to resort to a server side solution or slow down your site. All the magic happens after the page has been loaded and if there is no JavaScript available, visitors will still see a link to the same online resource.

It is a detailed explanation of the rationale and script that feeds my plugin for wordpress shown below:

[delicious:My links about JavaScript,codepo8,10,javascript]

Whilst not the flashiest of the chapters I hope that people can learn something about APIs, REST and dynamic script node generation from it.

The art and science of JavaScript

I was personally very positively surprised by the quality of the book itself: the full colour print, typography and iconography are very nice. The only thing that is missing is an author name or short bio on the chapter start page, it is a bit tricky to know who did what. Well done Sitepoint!