Christian Heilmann

You are currently browsing the archives for the General category.

Archive for the ‘General’ Category

First Decoded Chat of the year: Paul Bakaus on AMP

Thursday, January 5th, 2017

Today on the Decoded Blog I published the first ever Decoded Chat I recorded, where I grilled Paul Baukaus in detail about AMP.

This is an hour long Skype call and different to the newer ones – I was still finding the format :). There are quite a few changes that happened to AMP since then and soon there will be an AMP Summit to look forward to. All in all, I do hope though that this will give you some insight into what AMP is and what it could be if the focus were to go away from “Google only” with it.

These are the questions we covered:

  1. What is AMP to you?
  2. The main focus of AMP seems to be mobile, is that fair to say?
  3. Was AMP an answer to Facebooks’ and Apple’s news formats? Does it rely on Google technology and – if so – will it be open to other providers?
  4. It seems that the cache infrastructure of AMP is big and expensive. How can we ensure it will not just go away as an open system as many other open APIs vanished?
  5. Do large corporations have a problem finding contributors to open source projects? Are they too intimidating?
  6. Is there a historical issue of large corporations re-inventing open source solutions to “production quality code”? Is this changing?
  7. Whilst it is easy to get an AMP version of your site with plugins to CMS, some of the content relies on JavaScript. Will this change?
  8. AMP isn’t forgiving. One mistake in the markup and the page won’t show up. Isn’t that XHTML reinvented – which we agreed was a mistake.
  9. AMP seems to be RSS based on best practices in mobile performance. How do we prevent publishers to exclusively create AMP content instead of fixing their broken and slow main sites?
  10. It seems to me that AMP is a solution focused on CMS providers. Is that fair, and how do we reach those to allow people to create AMP without needing to code?
  11. A lot of “best practice” content shown at specialist events seems to be created for those. How can we tell others about this?
  12. AMP seems to be designed to be limiting. For example, images need a height and width, right?
  13. In terms of responsive design, does the AMP cache create differently sized versions of my images?
  14. Are most of the benefits of AMP limited to Chrome on Android or does it have benefits for other browsers, too?
  15. Do the polyfills needed for other browsers slow down AMP?
  16. How backwards compatible is AMP?
  17. One big worry about publishing in AMP is that people are afraid of being fully dependent on Google. Is that so?
  18. Are there any limitations to meta information in AMP pages? Can I add – for example – Twitter specific meta information?
  19. Do AMP compatible devices automatically load that version and – if not – can I force that?
  20. How can I invalidate the AMP cache? How can I quickly remove content that is wrong or dangerous?
  21. Right now you can’t use third party JavaScript in an AMP page. Are you considering white-listing commonly used libraries?
  22. It seems AMP is catered to documents, while most people talk about making everything an App. Is this separation really needed?
  23. What’s the sandbox of AMP and how is this now extended to the larger web as a standard proposal?

Web bloat isn’t a knowledge problem

Monday, January 2nd, 2017

Fat hamster stuck

There is a consensus among all browser makers and lovers of the web: the current state of the web is a mess. The average web page is 2.4 megabyte big and has over 200 requests.

We spend more time waiting for trackers and ads to load than we spend reading content. Our high-powered computers and phones, our excellent mobile devices choke on megabytes of JavaScript and CSS. Code that often isn’t needed in the environments it currently gets delivered to. Code that fixes issues of the past that aren’t a problem anymore these days.

Our reaction to this is a lot of times an assumption that people use libraries and frameworks because they don’t know better. Or that people use them to solve an issue they have that we don’t — like having to support legacy environments.

I’m getting more and more the impression that we are wrong in our approach. This is not about telling people that “you don’t need to use a framework” or that “using XYZ is considered harmful”. It isn’t even about “if you do this now, it will be a maintenance nightmare later”. These are our solutions to our problems.

We’ve done this. Over and over again.

Information is plentiful and tools aren’t a problem

We try to do our best to battle this. We make our browsers evergreen and even accessible as headless versions for automatic testing. We create tools to show you without a doubt what’s wrong about a certain web product. We have simulators that show you how long it takes for your product to become available and responsive to interaction. We allow you to simulate mobile devices on your desktop machine and get a glimpse of what your product will look like for your end users.

We create toolchains that undo the worst offenses when it comes to performance. We concatenate and minify scripts and CSS, we automatically optimise images and we flag up issues in a build process before they go live.

We give talks and record training videos on how to build a great, responsive product using modern browsers whilst supporting old browsers. We release all of this for free and openly available — even as handy collections and checklists.

And yet, the web is a mess. And I’m not even talking about products that bloat because of maintenance issues or age. Brand new, celebrated and beautiful products get even the basics of performance wrong. Why?

One reason for bloat — a lack of suffering the same problems

One of the biggest reasons is that developers in general don’t suffer the same issues end users do. We check our products on fast, well equipped devices on fast and steady connections. We use ad blockers. We don’t test our products on a mobile device with a flaky connection. We don’t test them on outdated setups that may well still be in use out there. We don’t even test them on other operating systems than ours. If it isn’t broken on our machine, it is good enough to release.

This is not malice on our behalf, it is at the worst indifference to other people’s needs. But most likely something else is the real problem.

The main reason for bloat

I think it is much more likely that the code quality of the end product and its performance isn’t even on the radar of many companies. We live in a market that moves at breakneck speed. Being first to market is paramount.

Companies that are funded to create hype and get millions of users posting random stuff, liking and adding emoji or commenting and sharing don’t care if they send a lot of unused JavaScript down the wire. They want to be the first to roll out a new feature that also can be turned off a month later when people don’t want it any more. They want to be the first to have the feature or be fast to add it when a competitor has success with it.

A lot of our messaging is the total opposite of that. With good reason. This is not a healthy way to work, this is not how you build a quality product. This is how you build an un-maintainable mess full of security holes and bloat. But this is how you make investors and prospective buyers happy.

We live in a market of hype and quick turnaround and we preach about longevity and quality thinking that takes time and effort and will yield results in the long run. We are right, we have proven over and over that we are, but the business model of our quick success poster child web companies is utterly and totally not about that.

I am not saying that this is good. At all. This constant push for innovation for the sake of showing something new and getting people even more addicted to using our products is killing the web. And it is killing our community and leads to an overly competitive work environment that favours 10x developers who have time and the drive to work 20 hours a day for a few months on a product that is destined to be scrapped a few weeks after the pivot.

Our job is to battle this.

Our job is to shine a bright light on all the bullshit cinderella stories of the unknown startup that made millions in a month by moving fast and breaking things.

Our job is to push back as developers when project managers want us to deliver fast and fix later — that never happens.

Our job is to give sensible estimates as to what we can deliver in a certain time and be proud of what we delivered.

And our job is to work closely with library and framework creators to ensure that products based on things that promise “deliver more by writing less” result in quality code instead of overly generic bloat.

People don’t bloat products because they don’t know better. They do it because they want to be seen as incredibly productive and faster than others. And that comes at a cost that is not immediately evident and seems not important in comparison.

The biggest problem we need to solve is that we celebrate re-inventing our way of working every few months. Instead of dealing with our jobs asking us to deliver too much in not enough time we started falling into the same trap. We want to be seen using the newest and coolest and follow patterns and ways of working of the fast companies out there. Quality and working with the platform isn’t sexy. Inventing new things and discarding them quickly is.

No, I am not against innovating and I’d be the last to pretend that the web stack is perfect. But I am also tired of seeing talented developers being burned out. We have a 1–2 year average retention span of developers in companies. This is not sustainable. This is not how we can have a career. This is not how we can become more diverse. The ugly brogrammer is only in part our own biases and faults. It is a result of an unhealthy work environment based on “release fast and break things”. We broke a lot. Let’s try to fix it by fixing what people use, not telling them what they should be using.

Enjoying the silence…

Tuesday, December 27th, 2016

It is a strange love I have for the web. Ever since I used the web for the first time it felt like taking a ride with a best friend.

I knew I had to start working on it to never let it down again. Many people who started with the web when I did have the same idea: I feel behind the wheel and I keep wanting to show the people the world in my eyes.

But sometimes I get the feeling that we’re flying high and we’re watching the world pass us by. Every new dress the web wears comes with technical challenges showing the limits of web technology. I don’t think that is broken, it is a pain I am used to. I show people how to work around limits, how stripped down solutions will perform better in the long run, and how walking in my shoes can give them a long lasting career with some great reward.

That said, I don’t think we get the balance right. It happens all the time that things don’t go as perfect as we want them to be. Of course we can tell people that they shouldn’t have done that, and follow a sacred policy of truth about the need for, for example, ubiquituous accessibility. But people are people and in many cases it is not always easy. When the boys in the higher up departments say go and it is a question of time in the project, shortcuts are taken. You stare down the barrel of a gun of delivery and you don’t have time for sweetest perfection. And – even worse – our whole market is constantly asked to innovate and create new things. We who are telling quality stories of old don’t suffer that well.

The landscape is changing all the time and the sinner in me is OK to spread some blasphemous rumours. The bottom line is that in your room you have a lot more insight than in a cut-throat delivery cycle. When products are faulty and become hard to maintain, we shouldn’t tell people “told you so”, that’s wrong.

We should be more flexible and whilst we have and hold the web we love, we should also remember that everything counts in large amounts. So our advice should yield fast and maybe dirty results, as much as the promise of sweetest perfection and a great reward in the future.

Instead of saying it’s no good, let’s say I feel you and try to fix the fragile tension between constant growth, innovation and quality.

Taking a look behind the scenes before publicly dismissing something

Saturday, December 3rd, 2016

Lately I started a new thing: watching “behind the scenes” features of movies I didn’t like. At first this happened by chance (YouTube autoplay, to be precise), but now I do it deliberately and it is fascinating.

Van Helsing to me bordered on the unwatchable, but as you can see there are a lot of reasons for that.

When doing that, one thing becomes clear: even if you don’t like something — *it was done by people*. People who had fun doing it. People who put a lot of work into it. People who — for a short period of time at least — thought they were part of something great.

That the end product us flawed or lamentable might not even be their fault. Many a good movie was ruined in the cutting room or hindered by censorship.
Hitchcock’s masterpiece Psycho almost didn’t make it to the screen because you see the flushing of a toilet. Other movies are watered down to get a rating that is more suitable for those who spend the most in cinemas: teenagers. Sometimes it is about keeping the running time of the movie to one that allows for just the right amount of ads to be shown when aired on television.

Take for example Halle Berry as Storm in X-Men. Her “What happens to a toad when it gets struck by lightning? The same thing that happens to everything else.” in her battle with Toad is generally seen as one of the cheesiest and most pointless lines:

This was a problem with cutting. Originally this is a comeback for Toad using this as his tagline throughout the movie:

However, as it turns out, that was meant to be the punch line to a running joke in the movie. Apparently, Toad had this thing that multiple times throughout the movie, he would use the line ‘Do you know what happens when a Toad…’ and whatever was relevant at the time. It was meant to happen several times throughout the movie and Storm using the line against him would have actually seemed really witty. If only we had been granted the context.

In many cases this extra knowledge doesn’t change the fact that I don’t like the movie. But it makes me feel different about it. It makes my criticism more nuanced. It makes me realise that a final product is a result of many changes and voices and power being yielded and it isn’t the fault of the actors or sometimes even the director.

And it is arrogant and hurtful of me to viciously criticise a product without knowing what went into it. It is easy to do. It is sometimes fun to do. It makes you look like someone who knows their stuff and is berating bad quality products. But it is prudent to remember that people are behind things you criticise.

Let’s take this back to the web for a moment. Yesterday I had a quick exchange on Twitter that reminded me of this approach of mine.

  • Somebody said people write native apps because a certain part of the web stack is broken.
  • Somebody else answered that if you want to write apps that work you shouldn’t even bother with JavaScript in the first place
  • I replied that this makes no sense and is not helping the conversation about the broken technology. And that it is overly dismissive and hurtful
  • The person then admitted knowing nothing about app creation, but was pretty taken aback by me saying what he did was hurtful instead of just dismissive.

But it was. And it is hurtful. Right now JavaScript is hot. JavaScript is relatively easy to learn and the development environment you need for it is free and in many cases a browser is enough. This makes it a great opportunity for someone new to enter our market. Matter of fact, I know people who do exactly that right now and get paid JavaScript courses by the unemployment office to up their value in the market and find a job.

Now imagine this person seeing this exchange. Hearing a developer relations person who worked for the largest and coolest companies flat out stating that what you’re trying to get your head around right now is shit. Do you think you’ll feel empowered? I wouldn’t.

I’m not saying we can’t and shouldn’t criticise. I’m just saying knowing the context helps. And realising that being dismissive is always hurtful, especially when you have no idea how much work went into a product or an idea that you just don’t like.

There is a simple way to make this better. Ask questions. Ask why somebody did something the way they did it. And if you see that it is lack of experience or flat out wrong use of something, help them. It is pretty exciting. Often you will find that your first gut feeling of “this person is so wrong” is not correct, but that there are much more interesting problems behind the outcome. So go and look behind the scenes. Ask for context before telling people they’re doing it wrong.

Pixels, Politics and P2P – Internet Days Stockholm 2016

Friday, December 2nd, 2016

Internet Days Logo

I just got back from the Internet Days conference in Stockholm, Sweden. I was flattered when I was asked to speak at this prestigious event, but I had no idea until I arrived just how much fun it would be.

lanyard

I loved the branding of he conference as it was all about pixels and love. Things we now need more of – the latter more than the former. As a presenter, I felt incredibly pampered. I had a driver pick me up at the airport (which I didn’t know, so I took the train) and I was put up in the pretty amazing Waterfront hotel connected to the convention centre of the conference.

chris loves internet

This was the first time I heard about the internet days and for those who haven’t either, I can only recommend it. Imagine a mixture of a deep technical conference on all matters internet – connectivity, technologies and programming – mixed with a TED event on current political matters.

The technology setup was breathtaking. The stage tech was flawless and all the talks were streamed and live edited (mixed with slides). Thus they became available on YouTube about an hour after you delivered them. Wonderful work, and very rewarding as a presenter.

I talked in detail about my keynote in another post, so here are the others I enjoyed:

Juliana Rotich of BRCK and Ushahidi fame talked about connectivity for the world and how this is far from being a normal thing.

Erika Baker gave a heartfelt talk about how she doesn’t feel safe about anything that is happening in the web world right now and how we need to stop seeing each other as accounts but care more about us as people.

Incidentally, this reminded me a lot of my TEDx talk in Linz about making social media more social again:

The big bang to end the first day of the conference was of course the live skype interview with Edward Snowden. In the one hour interview he covered a lot of truths about security, privacy and surveillance and he had many calls to action anyone of us can do now.

What I liked most about him was how humble he was. His whole presentation was about how it doesn’t matter what will happen to him, how it is important to remember the others that went down with him, and how he wishes for us to use the information we have now to make sure our future is not one of silence and fear.

In addition to my keynote I also took part in a panel discussion on how to inspire creativity.

The whole conference was about activism of sorts. I had lots of conversations with privacy experts of all levels: developers, network engineers, journalists and lawyers. The only thing that is a bit of an issue is that most talks outside the keynotes were in Swedish, but having lots of people to chat with about important issues made up for this.

The speaker present was a certificate that all the CO2 our travel created was off-set by the conference and an Arduino-powered robot used to teach kids. In general, the conference was about preservation and donating to good courses. There was a place where you can touch your conference pass and coins will fall into a hat describing that your check-in just meant that the organisers donated a Euro to doctors without frontiers.

Foodrobotwater

The catering was stunning and with the omission of meat CO2 friendly. Instead of giving out water bottles the drinks were glasses of water, which in Stockholm is in some cases better quality than bottled water.

I am humbled and happy that I could play my part in this great event. It gave me hope that the web isn’t just run over by trolls, privileged complainers and people who don’t care if this great gift of information exchange is being taken from us bit by bit.

Make sure to check out all the talks, it is really worth your time. Thank you to everyone involved in this wonderful event!