Today I went to the Spotify office in Stockholm to test-run a training I’ll give at the MozCamp in Singapore next month. The topic was turning geeks into presenters, how to foster a culture of speaking and presenting in a company and tricks how to become a better speaker.

Slides and screencast

The slides are online and there is a raw screencast (includes some swearing) available on YouTube.

Notes

From geeks to presenters

Why present?

Geek barriers

Presenting is translating, not selling

People listen if you talk to them!

Starting a speaking culture

A few tools

Powerpoint Karaoke

• Download random powerpoints of the interweb
• Pick a random person
• The person should present the deck for 5 minutes

• It teaches you to not be a slave to your deck
• It breaks down the initial barrier – everybody can look the fool for five minutes
• You get to know what to avoid in your own slides
• You start to learn speaking, not just re-iterating (you are not in your subject matter)

Lightning talks

• 15 minutes each week
• 5 minutes: a problem we encountered
• 5 minutes: a solution we found and applied
• 5 minutes: discussion if this is a good solution and should become a best practice

• The speaker knows his stuff
• The speaker talks about a positive experience – fixing something
• A Fixed time and duration means predictability which is less scary
• Everybody gets to have a go

Content repos beat a slide repository

Preliminaries – what to do yourself

Forget about the slide deck

Find excitement

Share pain and excitement

Learn to endure and adore yourself

Speak loud, clear and proud

Record and playback

Projection

Practice your stage voice and manners

An incredibly simple solution

Learn from others

Go to (un)conferences and share afterwards

Do not copy!

Would you like to know more?

• Developer Evangelism Handbook
• Evangelism Reps toolkit
• Great Talks on the Evangelism Reps Wiki

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.

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+.

This morning I gave the keynote at the Eclipsecon Europe in Ludwigsburg, Germany. Around 500 Eclipse and Java fans waited for some information about the latest and greatest in the web and here is what I gave them.

The slides are available online and the screencast is up on YouTube.

I will follow up with a more detailed explanation of the messaging on the Mozilla Hacks blog tomorrow.

In terms of releasing code into the wild we live in terribly exciting times. Products like GitHub, Dropbox, online collaboration tools like JSFiddle, JSBin, Codepen and Dabblet make it very easy to show our code to the outside world. Furthermore, a lot of products are build in a modular manner which means you can simply participate by writing a plugin or add-on instead of coming up with your own solutions. jQuery and WordPress are living proof of that.

Quick release, moving on fast

One of the biggest dangers of a very simple infrastructure is the one of inflation. When it is easy to release something, a lot will be released. This means it becomes much harder to find good quality content and we are tempted to release more rather than releasing a few things we really care about and are ready to also care for in the future. Much like we write shorter, and less thought-out emails than letters we tend to get into a frenzy of releasing smaller, shorter and less documented products.

This is open source – or is it?

This is where we run a current danger of cheapening the term “open source”. Releasing an open source product is much more than making it available for free. It is a process, an ongoing commitment to nurturing something by sharing it with the world. Open source and its merits can actually be a blueprint of a much more democratic world to come as Clay Shirky explains in How the Internet will (one day) transform government.

During the Fronteers conference, David DeSandro gave a talk about monetising jQuery plugins and how to keep your sanity at the same time. His main concerns were that his plugins (mostly Masonry) cost a lot of his time and didn’t bring in enough to make a living off them. Several times during the talk he explained that he does have a job and that he has no time to answer every email. After all, there should be no need to ask questions or get support as the code is available and on Github and people could help each other and be happy that the code was released as open source. How come there was no magical community appearing out of nowhere that took care of all this?

Open Source is more than releasing code

Well, this wasn’t an open source project. The code was released in the open and is available on a repository, but it is not open source. Open source means – at least to me and a lot of people I talked to – that products are produced and maintained in the open.

This encompasses much more than just putting the code on GitHub. It means:

• being ready to take on pull request and patches and communicate to the people who do them when and if they are released
• helping people to get involved
• communicate changes to the outside world
• reacting to security issues and performance issues
• answering feature requests
• dealing with licensing issues
• ensuring that the product evolves and changes as a reaction to new environments and market needs
• encouraging people to contribute and help others
• recognising people for helping out others and sharing the fruits of the labour with them

Open source is a lot of work and needs a community

This means a lot of work and it is the reason why a true open source project is not done by one person but from the very beginning should be planned around a group of people. People who are happy to share ownership and responsibilities as much as the benefits and the income from the project with others. People who are ready to hand over responsibilities should they get tired of them and to train their predecessors with that in mind. To be truly open source you should think about the maintenance and the future of the project before you release it. It is a group effort and the very tricky part is finding the group without hiring them.

A lot of what people call open source these days feels like “Tada-source” or “Pasture-source” to me:

• Ta-da source – products that are released as a final commercial version as-is and get a source release to the world later. Instead of making the world part of the creation process it becomes maintenance staff to fix bugs and add the things they need to the product. This allows you to say you are open without having to deal with people’s needs and to stick to your own agenda when it comes to core functionality.
• Pasture source – this is when products were financially viable and interesting but became a nuisance. Instead of maintaining them they go to the pasture of open source where kind shepherds without pay will ensure the products will live happily ever after. Pasture source happens either because of the workload of communication getting too much or because the business you work for doesn’t see the product as something they should pour resources into. A lot of times this is a PR exercise – “hey this product didn’t do well, but now that it is open it will be the next new cool thing for the open source community”

Brackets – a positive surprise

When Adobe said they’ll release their editor Brackets as Open Source and have it as Edge Code in their new set of tools for web developers I was not alone in being wary about this. It sounded like a closed source company trying to play with the rebel kids. Technically this is not new, as Adobe already did a lot of open releases with Air and even released the books under Creative Commons but it still felt “well, let’s see what is coming there”.

When seeing Adam Lehman talk about Brackets and their approach at the Adobe event in London I was very impressed to see how the project is run as an open source project. The code, of course, is available on Github, but that is not all. The project is following an Agile process using Scrum, pull requests are being reviewed every day, it has a 2.5 week release cycle and external contributions take priority. A detailed blog with release notes of each sprint is also available.

The project is managed in the open on Trello and a very clever way to get new contributers is to triage simple bugs as “quick wins” for new contributors rather than having more advanced developers spend their time on fixing them.

This is a great example of approaching an open source release of a product with the right tools and the right mindset. Yes, it is a lot of work, but I am quite confident that this means Brackets will be around for a long time, even if the Edge suite failed.

Don’t stop releasing

I am not saying that we should stop releasing things and making them available on GitHub and others. I am simply saying that open source means much more than that and that we shouldn’t be surprised if we get less contributors than we think if all we do is throw some code out and wait for magic to happen. Open Source means we get people’s time to build with us, not for us.

So when you release things, don’t call it an open source project, unless you are ready to go the full distance. Just put it out there and tell people that it is free and available, and that it is up to them what happens with it.

Currently my better half Kasia is working on a JavaScript training course and wanted to explain the concepts of JavaScript with a game. So we sat down and did a simple game example whilst she was fretting over the structure of the course. As she wanted to explain how to interact with the DOM in JavaScript rather than using Canvas we had some fun using CSS animation in conjunction with simple keyboard controls. More on the game in due time, but here is a quick thing we found to be extremely useful and not really used enough in the wild – the interplay of data attributes, CSS and changing states.

Defining a player element

We wanted to make the game hackable, people playing with HTML could change it. That was more a request by me as Mozilla has the Webmaker project and there will be a lot of game hacking at Mozfest in November.

In order to define a player element the semantic fan in me would do something like this:

<div id="player">
	<ul>
		<li class="name">Joe</li>
		<li class="score">100</li>
	</ul>
</div>

This makes sense in terms of HTML, and is accessible, too. However, in terms of accessing this in JavaScript, it is quite annoying as you need three element matches. Also in terms of maintenance it means three elements. In JS you’d need to do something like:

var player = document.querySelector('#player'),
    name   = document.querySelector('#player .name'),
    score  = document.querySelector('#player .score');

In order to change the score value, you’d need to change the innerHTML of the score reference.

score.innerHTML = 10;

Aside: yes I know there are lots of HTML templating solutions and I am sure dozens of jQuery solutions for that, but let’s stick to vanilla JS as this was about teaching that.

A HTML5 player element

Instead of going through these pains, we found it to be much easier to go with data attributes:

<div id="dataplayer" data-name="Joe" data-score="100">
</div>

The clever thing here is that HTML5 already gives us an API to change this data:

var player = document.querySelector('#dataplayer');
 
// read
alert('Score:' + player.dataset.score);
alert('Name:' + player.dataset.name);
 
// write
player.dataset.score = 10;
 
// read again
alert('Score:' + player.dataset.score);

Re-using attribute values

Another benefit of using data attributes is that CSS gets them. Say for example you want to show the colour of the score value in red when it reaches 10. In the first HTML using a list you’d need to do the testing in JavaScript and add a class to have a different display. You could of course also change the colour directly with the style collection but that is awful in terms of maintenance. It can cause reflows in your rendering and also means another thing to explain to maintainers.

function changescore(newscore) {
	if (newscore === 10) {
		score.classList.add('low');
	} else {
		score.classList.remove('low');
	}
}

#player .low {
	color: #c00;
}

Aside: jQuery has contains(‘foo’) to match elements with the text in their node content in the selector engine, but it has been deprecated as a CSS standard, so that is not the way to go.

When using data attributes you don’t need that – all you need is an attribute selector in CSS:

#dataplayer[data-score='10'] {
	color: #c00;
}

To display the scores you can use generated content in CSS:

#dataplayer::after {
	content: attr(data-name);
	position: absolute; 
	left: -50px;
}
#dataplayer::before {
	opacity: 0;
	content: attr(data-score);
	position: absolute; 
	left: 100px;
}

Check out the following fiddle to see all in action: http://jsfiddle.net/codepo8/BMY6H/

The only downside I can think of is that only Firefox allows for transitions and animations on generated content. All in all we found data attributes incredibly useful though.

Comments? Here are the threads on Google+ or Facebook.