Arne Report

Check out The Punch.

These are the sites I'm always coming back to

I like reading a lot, and I read a lot. Most of it on the web. Even though I have around fifty tabs open right now with articles to read, I'm always coming back to a few sites I genuinly enjoy reading.


Happy Notes

Smart technology commentary out of the view of a human being by Andre Torrez.

Bitssplitting

If Daniel Jalkut has something to add to the reporting of the rest to the tech press it goes here. As well as some notes about himself as developer.

Lucian Marin

The first person with three paragrafileph articles that got me to subscribe to his site. Lucian Marin publishes smart stuff on his 2022 website.

Ignore the Code

This is the best blog I know that consistently gets usability right - written by Lukas Mathis.

Next Draft

Dave Pell helps me to get my hands on the most fascinating news of the day - in a daily email newsletter.

Craig Mod

Well written essays about storytelling and the future of publishing by Craig Mod.


I will do my best to keep this list up to date. Also, I'm subscribed to about a hundred feeds - some bulk feeds like Svbtle - via RSS, and get to a lot of other great content via Twitter or Link Blogs. Right now, I'm trying out Feedly as Google Reader replacement, and I'm not too sure if I like it yet.

That Google Blink

Just at the beginning of the last month, the web developers were in shock that Opera anounced to switch to WebKit as rendering engine. WebKit then being the most widely used layout rendering engine, with also Apple's Safari and Google's Chrome using it. Then, just two days ago, Google said that it moved from WebKit to Blink.

So, what is Blink? Blink is a fork of WebKit. Just taken the WebKit source and building on top of it, but as your own project, not for Webkit itself. It is pretty similar to Linux and its distributions. All started with one base, and then have gone their own ways to improve, and one feature won't necessarily make it into another Linux distribution. Same here.

Google argues that they had to do the move, because they were using a different multiprocess architecture than other Webkit browsers, and didn't want to deal with the other architectures Webkit browsers had. That however isn't anyone's fault but Google's. As they were asked to give their multiprocess architecture back to the WebKit project, they simply said no, according to Maciej Stachowiak, Apple's Safari/Webkit team.

So apparently Google has been doing its own thing, even when they were said to be using Webkit rendering engine. Right now with Blink, they are using it as much as before - as base for their own innovations. Just now, they don't have to give anything back to the base ever. And that's with the name Blink official.

And that’s what you’re missing from everything else you’re reading about this announcement today. To make a better platform faster, you must be able to iterate faster. Steps away from that are steps away from a better platform. Today’s WebKit defeats that imperative in ways large and small. It’s not anybody’s fault, but it does need to change. And changing it will allow us to iterate faster, working through the annealing process that takes a good idea from drawing board to API to refined feature. We’ve always enjoyed this freedom in the Chromey bits of Chrome, and unleashing Chrome’s Web Platform team will deliver the same sorts of benefits to the web platform that faster iteration and cycle times have enabled at the application level in Chrome. (Alex Russel, Google)

That sounds like an explanation, but better go and read the whole article. However I still wonder, why Google didn't want anybody to have their multiprocess architecture?


Developers who complain about having to test in another browser, are not right. They don't have to test in another browser. If they've done their work right, they've tested in Chrome and Safari separately, and not just in one Webkit browser. Why? While they both used the Layout rendering engine Webkit, they used different Javascript rendering engines, different CPU & GPU rendering, and different network stacks. (Read more about tha.)

Also, the prefix -webkit remains the same for already existing functions, and does not change to -blink. So no worries, what worked previously in Chrome will still work now. At least it's supposed to.

What is going to happen right away is basically nothing, but making Chrome smaller and faster. Removing some clutter that was there from the Webkit days.


But what about Opera? The browser that was supposed to update on Webkit? Well, it doesn't. They said they'll use Chromium, and they do. Blink will be their new rendering engine. (Hello Blink!)

That's also the end of the Webkit monoculture that many didn't like, but actually wouldn't have been that bad.

WebKit fills a similar role. Thanks to WebKit, anyone who needs a world-class web rendering engine can get one—for free. And the products built with WebKit are as varied as those built with Linux. Even products in the same category vary wildly. Chrome and Safari, for example, have different features, different extension mechanisms, different JavaScript engines, different process models, and very different user interfaces. Opera adds yet more variation. And these are all just standalone web browsers. Consider all the embedded applications of WebKit, from game consoles to theme-park kiosks, and the idea of a homogenous, stagnating WebKit monoculture seems even more unlikely. (John Siracusa)


In short, DON'T PANIC. It sounds like a huge change, but in terms of day-to-day development, the internet will still be the internet. Just as WebKit grew out of KHTML, Blink grows out of WebKit. It's interesting! (Jake Archibald, Google)


In the short term, Blink will bring little change for web developers. The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. For example, we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat. Over the long term a healthier codebase leads to more stability and fewer bugs.

Throughout this transition, we’ll collaborate closely with other browser vendors to move the web forward and preserve the compatibility that made it a successful ecosystem. In that spirit, we’ve set strong guidelines for new features that emphasize standards, interoperability, conformance testing and transparency. (Google)

Facebook's Vision

At one level, [Facebook Home] is just the next mobile version of Facebook. At a deeper level, I think this can start to be a change in the relationship that we have with how we use computing devices. For more than thirty years, computers have mostly just been about tasks, and they had to be - they were too expensive and clunky and hard to use, so you wouldn't really want to use them for anything else. But the modern computing device has a very different place in our lives. It's not just for productivity and business, although it's great for that too. It's for making us more connected, more social, more aware.

Home, by putting people first, and then apps - by just flipping the order - is one of many small but meaningful changes in our relationship with technology over time.

When I think about the world today, what amazes me most is the number of people who are getting on the internet every day and how it's improving their lives as they join this modern knowledge economy. I grew up with the internet, and I can't really imagine a world without sharing, and messaging, and searching, but actually only about a third of the world is on the internet today - a little more than two billion people. So we're really very close to the beginning of this. If you look out, maybe five or ten years, when all five billion people who have feature phones are going to have smart phones, we're soon going to be living in a world where the majority of people who have a smart phone - a modern computing device - will have never seen in their lives what you and I call a "computer."

So, just think about that for a moment.

The very definition of what a computer is and what our relationship with it should be hasn't been set for the majority of the world. And when it is, I think a lot of that definition is going to be around people first. We're about to see the most empowered generation of people in history, and it's really an honor to be able to work on these problems.

This is a deeply technical problem and it's also a deeply social problem. This is the kind of problem that Facebook, our culture and our community, are uniquely built to work on. And we look forward to continuing to do it and to sharing what we come up with with all of you. Thank you.

- Mark Zuckerberg, CEO Facebook

Email advice: Quote, not copy the whole thing


I hear you complain about email all the time, how bad it is, but you're just waiting for it to get better. But I tell you, without doing something to make it better, email is unlikely to change anytime soon. While switching the system might be a problem, tweaking it could make a huge difference.

So called email replacements are shooting themselves in the foot, by requiring an email adress to sign up. Yeah, I totally get it. Replacing email by requiring email is as logic as 1+1, isn't it? Well, maybe - but doesn't seem right to me.

Here is an easy, time-efficient way of replying to emails you get. Easier for you to write, and easier for them to read. A poor email style would be quoting the whole history of sent messages at the bottom of the mail. Nobody wants to dig through all that, even if he has forgotten what exactly the topic was. Taking the last email and either putting it to the top or the bottom, wouldn't solve the problem, and is poor form as well.

Writing an email is more like talking to someone about a certain topic or arguing on your blog why this article is wrong/right. What you do is, quote the important parts and then work with them - extend them, argue with them, correct them, whatever. So, why do you do this? For the other person to understand what you're talking about. And by that you're making it easier for yourself too, because you don't have to explain your poorly explanation again. By not having to explain something again, makes the explanation given at first much, much stronger.

This is exactly what you do in an email as well. Quote the questions for example and answer them right underneath - one after another.

Chrome affecting eyesight?

David Darnes today posted that Chrome is affecting his eyesight. I use the browser day in and day out and have the same problem, and if I use it for a longer period it all gets blurry and I can't seem to focus. Tell me if you are having the same problem, or if it is just us.