What my PhD would have been on

Last year, in March, I joined the Software Engineering team at LaBRI to start a PhD. In late October, I dropped it. This post will describe what I worked on and the definition of my PhD subject as I left it.

Beginner wanderings

“Design and implementation of mobile applications in a REST ecosystem” was the vague topic I started with. My PhD was funded by a project aiming at studying software engineering practices in the realm of client-side web programming and apply it to a new approach to e-commerce

From REST…

I remember again a project I was involved in three years ago. I was a student and the project was a partnership between my school and a company. Some meetings or discussions involved words like “REST”, “Ajax”, “Drag and Drop”, “an HTML div”… All this jargon was unknown at the beginning and was understood at the end. With the exception of REST for which no one really had a definition I could find satisfying. And the PhD topic I was given had this word. So a first thing I did was reading Roy Fielding’s dissertation.

I recommend this reading to anyone who write web applications. Alongside with this recommendation comes a warning that from now on, I’ll slap in the face anyone talking to me about a “REST API” (call them “Web API”, “URL API”, “HTTP API” if you wish instead) or putting “REST” in a list that already includes “XML, JSON”.

Along the way, I discussed once with my friend Thomas who is a PhD student at UCI (where coincidentally Roy Fielding works) who mentionned CREST (Computational REST). The idea is interesting, but I didn’t find really how I could use it in practice. Worth mentioning, though, especially the first part that studies how REST principles have been misapplied and some nowadays good practices.

… to cookies …

A part of Fielding’s dissertation discusses cookies and how they violate REST:

Cookies also violate REST because they allow data to be passed without sufficiently identifying its semantics, thus becoming a concern for both security and privacy. The combination of cookies with the Referer [sic] header field makes it possible to track a user as they browse between sites.

As a result, cookie-based applications on the Web will never be reliable. The same functionality should have been accomplished via anonymous authentication and true client-side state. A state mechanism that involves preferences can be more efficiently implemented using judicious use of context-setting URI rather than cookies, where judicious means one URI per state rather than an unbounded number of URI due to the embedding of a user-id. Likewise, the use of cookies to identify a user-specific “shopping basket” within a server-side database could be more efficiently implemented by defining the semantics of shopping items within the hypermedia data formats, allowing the user agent to select and store those items within their own client-side shopping basket, complete with a URI to be used for check-out when the client is ready to purchase.

“anonymous authentication” is still to be understood for me. Fortunately, I recently (December, so after leaving the PhD) came across a different idea that could probably help fill the same role.

However, “true client-side state” is a technology that now exists and is well-deployed: local storage

… to client-side storage …

Cookies have been used as local storage for a long time, so I made a brief study of what was available to replace that. Actually, most of the work had already been done by someone else, so it was quite easy.

To be noted is a meeting where I presented this and someone asked me “oh, you know HTML5? Have you heard about canvas?”. It was probably the strongest proof that I was in a different world. Different from what I was used to when talking about the web. Before this PhD, my discussions about the tech side of the web were mostly with people in standard mailing-lists and Mozilla (the overlap between both is big). So yeah, I’ve heard about canvas…

Shift to repository mining and programming languages

While I was working on web architecture, the rest of the software engineering research team was working on… software engineering. They are developing a tool called VPraxis. In a nutshell, this tool allows one to query a repository. For instance questions like “in 2011, who worked on classes that implement the interface X?”. Actual repository (SVN, Git, Mercurial…) is abstracted out and the tool is expected to be language agnostic (and why not cross-language (imagine queries dealing with HTML classes used in CSS)).

Several discussions on this topic with the team and guests who stayed for a couple of days increased my interest. What I consider to be the most interesting part of my work was the definition of the “dependency upgrade problem” and ideas to help solving it.

The Dependency Upgrade Problem

The problem

Initial conditions are as follow: A developer (or a team) has a codebase using a dependency (for now, only one dependency is considered since it’s already enough work). A dependency can be a library (the developer writes an application using jQuery), or a platform (the developer writes a software on top of Linux, or a Firefox add-on). Over time, this dependency changes (bugfixes, performance improvements, API changes…). The developer wants her code to work with the new dependency version. Most of the time, the developer can do that when she wishes, but in the case of Firefox add-on, for instance, you have to adapt to the platform at a pace you do not decide (because “imposed” by the 6 weeks release schedule).

Here is how it works currently to adapt code to a modifying dependency: The dependency author (or team) writes a changelog, the developer reads this changelog, figures out how the described changes affects her code and starts adapting her code.

This is hugely error-prone for 2 reasons. First of all, the dependency author (or team) is/are a human being(s), so the changelog (if it exists at all!) may be incomplete or inaccurate. Second of all, the developer needs to match how this changelog describes things that may affect her code. Even if the changelog was perfect, it would still require a lot of work and work that is error prone (because places can be missed, introducing new bugs).

An error-prone process on top of another error prone process, no wonder people avoid as much as they can to upgrade. Another consequence is what has become a good practice in library authoring which is to never (or almost never) break an API. The only reason this is a good practice is because breaking APIs require more (error-prone) work to library clients. The downside is libraries that keep old code around forever, having “deprecated methods” that are never removed and growing in size, making them harder to read and maintain. Size of a library is a particular problem on the web. So that jQuery is considering removing parts of the API.

Towards a partial solution

The potential of mining a repository and extracted fine-grained information about code that is changing gave me two complementary ideas to help solving the aforementioned problem.

First of all, the changelog. Dependency code is in a repository. All changes between a version and another version are stored somewhere in this respository. One idea is to build a tool that reads in a repository all changes that may affect client code and generate a semantic (with information like “such function has a new argument”, “the implementation of such function changed”, “such classes haven’t been touched at all”), machine-understandable (not sentences written in a human language) changelog. First, this changelog would be complete, by definition of reading in the repository. And, the notion of “all changes that affect may client code” is probably undecidable, but conservative assumptions can be made; it would just make the machine-understandable changelog a bit bigger. It has to be noted that closed-source libraries (for which there is no public access to a repository) could release a semantic changelog to their clients without providing access to the repository itself.

The second step is to have another tool that takes the developer code and the semantic changelog (hence the need for the changelog to not be in human sentences form) as input and provides suggestions on how to transition the code as output. Some adaptations could be fully automated (public method rename), but most cannot, so a recommendation engine is probably the best that can be done. Associated with decent UI, it would certainly be a big win.

Of course, the two tools I suggest wouldn’t entirely solve the problem (since it’s certainly undecidable). The human beings would still need to do some work, but I intuit it could be reduced to parts than cannot be done by a human being. On the good sides is the ability for a program to tell you that some parts of your code are not affected by the change. I intuit that having such information would be a powerful motivation to adapt the code. Imagine a tool that would tell you “the 80% of your code base that is in these files are unaffected by the dependency change”.

The end

I planned to work on such two tools for JavaScript (obviously?). I wrote a JavaScript static analysis tool to retrieve an API exposed by a file. This experience taught me that static analysis isn’t enough, so I gave up the static analysis tool. The definition JavaScript API by itself is actually difficult and I’m not sure I’ve been able to find the perfect answer to this question yet. The only thing I’m sure of is that answering it requires some static AND dynamic analysis.

Anyway, I didn’t go further, but thought it was worth sharing where I left my work.

Another way of thinking online payment

I was reading an interesting post about encryption and it made me feel a need to respond on what is said about credit cards.

Capabili-what?

Very soon after I joined es-discuss, I read some messages by Mark S. Miller. Soon enough, I watched his infoQ talk. This talk introduces the notion of object capabilities. This talk and this concept blew my mind. “Modularity increases my security?”. And he also shows the problem (and a solution) of distributed secure currency. Any “smart” idea I’ll write in this post are actually more or less already in this part of the talk.

Unrelatedly, I watched a talk by Douglas Crockford which suggested people to go watch The Lazy Programmer’s Guide to Secure Computing by Marc Stiegler which strongly emphasis POLA. I did and took the same sort of mind-blowing shower. I will learn later that Marc Stiegler and Mark Miller have been working together.

This led me to start reading Mark Miller’s thesis (haven’t finished yet, but still working on it) and to watch some other talks. It also led me to read about petnames, rich sharing, website passwords, web introducer and many other interesting things.

There are years of serious research poorly summurized in the links above. I highly encourage to read and watch all of this, but I admit it takes a lot of time to.

Thousands of credit cards numbers stolen during the Sony Playstation network hack

People have given their credit card number to Sony. Sony got hacked. People were annoyed. Who is to blame? Sony for its flawed security? Let’s take another look at the problem.

I want to pay…

I want to pay online. I want to buy one item once or pay regularly (like in a monthly payment to Sony). What option am I given? Giving my credit card number. And this is a terrible idea!

…but not to give my credit card number!?

When I send my credit card number and any “secret” written on the card, I do not allow for a one-time payment (or regular) to one company for a given amount of money I choose. Rather, I give the authority to anyone reading my info to do a payment of any amount directed to anyone, anytime. And that’s a source of insecurity.

Another way of thinking online payment

Here is how payment could happen: I go to my bank website, I have a form where I choose the amount I want to pay, who I want to pay to and to which frequency (one time, once a month, etc.). The two last fields are optional. In exchange, the bank gives me a secret (a URL for instance). I share this secret with who I want to pay. End of story.

Of course, this is just an example crafted in 2 minutes that could probably be improved.

“Oh fuck! Sony is getting hacked again!”

So, In my imaginary world, Sony (or anyone, it’s not about Sony as you’ve understood) does not have access to my credit card number, but only to a secret allowing a payment only to it at a frequency that I chose and to an amount that I chose as well. Sony gets hacked? WHATEVER!

We could imagine extensions where I could tell my bank “such secret has been compromised. Please stop paying through it”, “regenerate a secret for the same parameters”, etc.

Conclusion

As Ben Adida mentions in his blog post, encryption is not the final answer to security. His analysis of how encryption may get in the way of social features is interesting.

I wrote this post to show that security without encryption can exist, even for payments. Object capabilities seems to have a huge misknown and underused potential to achieve this form of security.

In the particular case I described, it’s not here because it requires cooperation from banks. I’m looking forward to see banks implementing this!

A response to “How Google is quietly killing Firefox”

Here is a response to this article

Article summary

The article explains that browsers (all including Firefox and Chrome according to the author) crash more frequently because of a lack of memory since web applications are now more JavaScript intensive. The author explains that it’s not always the browser’s fault to be memory hungry and sometimes is the fault of the web developer. I agree with this part. I would even also add that it is not because JavaScript has a garbage collector that it avoids memory leaks. Some leaks are at the application level and I really think a “WebValgrind” should emerge to tell at the JavaScript level where a web app leaks.

Then starts paranoia:

Mozilla’s greatest revenue source today (accounting for more than 80 percent of annual income) is Google. Mozilla is deeply dependent on Google for operating revenue.

Mozilla is not dependent on Google. Mozilla is dependent on search-related contracts. Asa Doltzer wrote about it 4 years ago. He was right at the time and what he wrote still stands. Mozilla is not dependent on Google.

And it goes on:

If you buy the theory that most people who abandon Firefox do so because it crashes (runs out of memory) unpredictably, it stands to reason that all Google has to do to pick up market share in the browser world is publish AJAX-intensive web pages (Google Search, Gmail, Google Maps, etc.) of a kind that Firefox’s garbage-collection algorithms choke on — and in the meantime, improve Chrome’s own GC algorithms to better handle just those sorts of pages.

Response on different points

Google creates AJAX-intensive web apps that purposefully leak

This is a ridiculous accusation. Imagining that all competitors started to have better garbage collection, what would they be left with?

Google makes AJAX-intensive applications for the purpose of improving the user experience. End of story. Memory leaks are the result of the current software attitude which is to keep adding features without caring long-term performance.

Memory leaks are made to make Firefox crash

This is ridiculous as well. Does anyone really think that Google web devs wake up in the morning thinking “hey, what about I add a few more memory leaks to make a some browser crash?”. If the browser crash with a given service (Google maps, for instance), some people will change of browser, some others will just change of service and this is not in Google interest.

Also, why does Firefox crash in the first place? Maybe Firefox should work toward improving it’s memory management? Oh wait! they are already working on that!! (and these are just a few links). Once we see improvements of these bugs on Firefox, I guess Google web devs will have to work a lot harder to make Firefox crash. Good luck, guys!

On “Google is a uniform corporation with an evil plan to kill Firefox, booo!”

I recently attended JSConf.eu and I’ve had the occasion to chat a few minutes with Erik Corry after his talk on improving V8 garbage collection. Call me naive or stupid, but the image I kept from him was the one of a dedicated (maybe even passionate) engineer working to improve his product. Is he a slave serving an evil Masterplan to control the universe? I don’t think so.

On hyperbolic blog article titles

“How Google is quietly killing Firefox“, “Is Google Chrome the New IE6?“… What is the next title? “Chrome is bringing back Nazis”?

Chris Heilmann already warned us about hyperboles (start at slide 74). I think we really should stop these titles, because they create more confusion that anything. No, Chrome’s plan is not to kill Firefox by purposefully introducing memory leaks in its webapps. No, Chrome is not IE6. There are many differences.

I agree that there are some disturbing informations about Google and its commitment to openness, but it does not make Chrome IE6.

Side note. It took me some time to understand why my previous post hit 1400 views and I get now that it probably its title was sort of flashy. I regret it.

Free “as in free speech” or why I don’t by Apple’s products

I read the RudeBaguette‘s article about the silence since the Applidium’s hack and it reminded me the core ideals I care about and what I fight for.

The article

Some folks “hacks” Siri, figured a way to use it in a way Apple hasn’t intended it for and advertised it on their blog. It creates a buzz, some people see potential (use Siri as a remote control, to turn off your car and lock it…).

Then, suddenly, no one talks about it anymore. The blog posts with reverse engineering details disappears. And no press cover anymore.

The article suggests a conspiracy as a conclusion.

Apple’s world

Apple Terms Of Services:
“Apple grants you a personal, non-exclusive, non-transferable, limited license to use the Software as provided to you by Apple as a part of the Service and in accordance with these TOS; provided that you do not (and do not permit anyone else to) copy, modify, create a derivative work of, reverse engineer, decompile, or otherwise attempt to discover the source code (unless expressly permitted or required by law), sell, lease, sublicense, assign, grant a security interest in or otherwise transfer any right in the Software.” (emphasis added)

No reverse engineering? No decompiling? No granting of a security interest? That’s a lot of restriction! Probably too restrictive to make Applidium’s reverse-engineering legal by Apple’s terms.

Legal terms and conspiracy

I’m not a legal expert in any fashion, but Stéphane Distinguin declining to comment, the press stopping to cover Applidium’s hack may just be the effect of Apple applying its terms of services, it’s legal rights. A conspiracy? I don’t see any conspiracy. Just a company claiming its rights.

On the right to do whatever the fuck you want with your own device and softwares

So many free software institutions have been claiming this particular right for years. Idealists? Naive? Maybe. But at least, when you deal with them, you don’t need to agree that you restrict your own rights to do whatever you want with the hardware and software you buy unlike with Apple.

Apple does not allow you to do what you want with what you buy. If you buy an Apple device knowing that on purpose, that’s your choice. If you buy an Apple device and think there is a conspiracy whenever they remind you that you’re not allowed to do what you want with you’re device, you’re just fooling yourself.

Some choices of my own

As it turns out, I don’t buy Apple products. Because I want to be in control of my own life. I want to be able to hack my device to use it as a remote control (I don’t have a TV) or to turn my car off and lock it (I don’t have a car) and not being told by the company who I bought it from that I am not allowed to. I believe in Creative Commons content that people will be able to share for the purpose of education. I believe in projects like Mozilla’s Boot2Gecko with which I’m sure I’m never going to be told that I can’t do what I want. I believe in free software so that I don’t get fucked later on and am never in doubt of a conspiracy of any sort.

A day in life

I woke up this morning and during the breakfast, I’ve been told that during the night I had been talking and said “ça arrivera”, which you could translate as “It’s going to happen” or “It will happen eventually”. I don’t remember saying that or a dream related to that, but it probably will.

Morning

I read and watched Mark Surman’s article about Mozila’s 2012 plan. It’s been a while that I’m preparing a blog post trying to explain why I disagree with the goal of “building a generation of web maker”. While I deeply agree with the goal of creating a web literate planet, I believe “a generation of web maker” is just not right. I will write about this very soon.

Afternoon

After my phone gets lost, I arrived half an hour late at someone’s who I’m helping for her website. A friend of her was here. At some point, about the website he said something along the lines of “please spare one or two pages if she wants to add content later to the website”.

I’ll give you, dear reader, very likely to be web literate, a second to digest this quote.

…..

Short after, her 10 year old son comes back from school and has a look for one second at my computer. “You’re operating system looks funny”. I’m using Ubuntu.

A generation of web makers, you said?

Evening

A detour at a phone shop to have my phone blocked later, I decide to go at my favorite Chinese restaurant. I get welcomed by the usual waiter who is apologizing, almost on his knees for last time because he charged me too much. Soon enough will he have brought me seven and a half euros for something I don’t even remember.

The dinner will be followed by showing “Intouchables”, the big movie currently in France. About a rich tetraplegic who gets assistance from a younger guy who’s from a poor suburb (in France, suburbs are usually the poor areas, unlike in the US). If you ever have the occasion to watch it, do it, preferably in French. It’s really worth it.

Night

I’m not sure what next is going to happen. I have no clue what “will happen evetually”. Maybe this blog post after all!

Don’t let human beings do shit work

Introduction

This article is somewhat a heartbeat reaction to Zach Holman‘s article entitled “Don’t Give Your Users Shit Work” and would like to take this occasion to share some thoughts on softwares and why I work to make some.

Relationship between time and work

We need to get out of this idea that the act of spending time on a project means that you spent your time wisely. Sometimes you’re just wasting your time.

Yes!

I think we inherit from Taylorism the idea that the value of the work done by a person is proportional to the time spent on it. It is probably right in a factory, but is severely wrong in most other jobs I can think of.

The worst point is probably the idea that you can quantify the value of the work of someone, but i’ll pass on that.

The bigger point is the idea that there is a relationship between time spent and work done. And this leads to contracts where you’re being asked to do a certain amount of hours. I was doing a PhD and in my contract was written a number of hours to do annually. What for? Am I proportionally productive to the time I spend? What does “being productive” mean in Research? Should I count the time I spend on es-discuss? And my favorite: since research is mostly an intellectual work, how are you going to prove that I actually did this number of hours?

For an internship, I wrote some piece of software that was used to adjust some prices. It lasted 5 months and I’ve been paid 5000€ overall. By now, the software I wrote helped saving probably a million euros. The software is still running, last I heard. With a constant amount of time, I achieved something that keeps creating value, potentially until the end of the business.

Anyway, one stupid consequence of thinking that work done is proportional to time spent is that people justify that they have been working just because they spent time. I wish one day we move away from Taylorism.

Shit work and progress

Shit work could be defined as something annoying to do for a human being. Relevant specialists may disagree, but I would define progress as the fact for humanity to reduce shit work.

Irrigation was not invented for fun, but because it was freaking annoying to bring water manually from the river close by. That was shit work. We rod horses because long-distance walking was shit work. Electricity is widely used to power many engines that do shit work so we don’t have to do it.

The progress is not in “replacing human beings”, but rather to free human beings from annoying work. This way, human beings can do something fulfilling, maybe creative, maybe social.

What attracts me in software?

The only purpose of computers should be to do shit work for us. This is why I like software. It allows to free people from shit work. Software should save me time. It makes me so sad when people tell me that they are losing time because of a computer. Clearly the people who wrote the software got it wrong.

I agree, Zach Holman, good software is software that saves my time. It’s software that do shit work for me.

On education credentials

Last year, at the Drumbeat Festival, I first heard of badges as a form of education credentials.
The initial assumption of most participants was that current education is broken. So is the diploma model. And badges were presented as one alternative.
It made its way to becoming OpenBadges and the recent launch of the Open Badge Infrastructure.

In plenty of occasions i try to engage people to make them think about education, skills, degrees and I discuss about badges. I would like to take an occasion to write about the common questions and comments I receive on these topics.
In this article, I will try to state the problem that badges are trying to address (focused only on hiring while i’m aware, badges are of interest beyond this single aspect), the current existing solution, its downfalls and try to explain how badges are not worse as some may think.

The problem of hiring

When it comes to hiring, the person who hires has an idea (sometimes not accurate enough, but that’s another issue I won’t go into now) of what the company needs in terms of skill. Before hiring an applicant, the recruiter needs to know whether the person fits the expectations.
The best way would certainly be to spend days, weeks, (months?) with each candidate, but this is unrealistic (in some way, that’s what trial period could be considered as). Recruiters aren’t an army, their time is limited, so choices have to be made. Based on what?
Usually, this falls under 2 categories: education and past professional experiences (other experiences for open minded recruiters). Experience mostly speaks for itself or can be explained through an interview. But for people without or with few experience, only education remains.

What does it mean to hire based on education?

If a recruiter has the time for one interview and has to choose between 2 candidates based on their education, the recruiter makes his choice not based on actual skill, but on expected skill for people having this diploma. Even more accurately, the choice is based on the trust the recruiter has on the institution delivering the degree.
But recruiters don’t know all universities, degrees, they don’t know the exact experience and curriculum someone who graduated from such or such school followed, so most of the time, the trust is not on the institution itself, but rather on the reputation of this institution.

Limitations of a diploma

Relying on reputation and trust has the immediate problem that the reputation could be false. Even if the reputation was right, the trust could be betrayed, because the students may graduate without filling all the requirements. For instance, students may cheat at exams. During team work, they may find teamates who’d do all the work and get the same grade in the end. We’ve also heard in the press of cases of people paying to get a degree, etc.

To be clear, I am not saying that all degrees are worthless, but only reminding that making a decision/judgement based on a degree is based on the trust one has on the delivering institution with the usual problem with trust which is that it may or may not be betrayed.

Besides the trust problem, a diploma, like a coin, is a symbol. A symbol of some skill set. One unfortunate aspect is that this symbol is a strong reduction of the set of skills it represents. Indeed, a diploma is a binary entity, either you have it or you don’t. Diploma lacks of information on what they represent exactly, but also lack of granularity.
Regarding this topic, I can’t help quoting Laura Hilliger’s excellent article

I have a BA in Digital Graphics and am earning a MA in Media and Education. What do you know about those degrees? Did you know that I took Statistics and did well? Or that I have taken 6 different Art History classes? Or what about that I won a debate on Human Sexuality in Primitive Cultures?

Problem of the “diploma-only” culture

Worse than the problem inherent to diplomas themselves is the culture around them which is that they are expected to be sufficient to know someone and make a decision based on it. This is problematic, because it forgets that learning happens outside of schools, outside of places where diplomas are delivered. This cultural problem gives the impression that people without degree are ignorant and stupid and that two people with the same degree are alike. Both are completely false.
As I mentioned, this problem is cultural and not inherent to diploma. It may reproduce with badges.

Where badges come in

Badges aren’t a perfect one-fits-all solution. However, they try to address the different aforementioned problems.

Trust

In order to strengthen the trust a badge viewer can have on the badge, Mozilla’s open badges contain a link to how the badge was earned. This doesn’t solve the trust problem. This proof could be faked. If not fake, the person claiming the proof may not be the one who created it, etc. Since, like a diploma a badge is a symbol, there is a trust issue. But trying to provide a proof is a start to enforce the trust.

Badges offer a trust VS cost trade-off. In a blink you can see all badges but not verify that they’ve properly been earned. Or you can check the proof of each badge at the expense of spending time understanding how the badge got earned. In case the badge issuer is considered as trustworthy, trust can be delegated. This delegation is almost compulsory with diplomas, badges offer the choice.

It has to be noted that neither badges nor diploma are inherently more trustworthy. They just address the trust issue differently.

Granularity

Since they are defined by the issuer, badges are of arbitrary granularity. With the downside that work has to be done in order to determine the proper granularity and skills for each domain. In domains where badges would be too numerous, having “meta-badges” could be a good idea.
Once again, choice is offered by badges and come with a cost.

Questionning what is taken for granted

My take on “the current education system is broken” is more moderate than what I can be read in the open education community. But I’m glad an alternative exists. I’m glad my assumptions about education have been questionned. Badges, just by existsing as an alternative form of credentials force the questionning of the current system and everyone’s assumption on diploma and what they really mean.

Final thought on my own diploma

At the end of November, I will receive a diploma. A piece of paper I do not really care about to be honest. I remember the experiences, people I have met, discussions in or outside of class and it was a good experience, all what I’ve learned, technical or not. In a way, it’s unfortunate the piece of paper i’ll receive won’t represent any of that.

Conclusion

Despite the common belief, there is no reason to put more trust in diplomas delivered by universities than badges delivered by anyone else. Moreover, badges offer very pragramtic solutions to the issue of enforcing trust by showing a proof as well as a potentially better granularity. Of course, none of these benefits are free and will come with an additional effort on the badge issuers side and on the people who want to verify the trust they have on the badge. Like in many cases, badges and diploma aren’t better or worse but rather offer the potential of a trade-off and it is to the people who have to make the choice to carefully decide where they put their cursor.

Proclaiming myself King of the MDN JavaScript Documentation

Dear JavaScript Community,

About two years ago, a very wise man told me that power is not something you’re handed, it’s something that you take. Despite how absurd this sentence may sound, i have noticed it to be true in many occasions.
And I think that time has come that i decide to take responsibility for the MDN JavaScript documentation, so today, now, i’m proclaiming myself King of the MDN JavaScript Documentation.

JavaScript documentation

Need for documentation

JavaScript has been around for more than 15 years now. And i can’t name one website that has up-to-date and complete enough documentation for it. I have recently written a page that i consider of good enough quality for the this keyword. More than 15 years after the invention of JavaScript! …and i am not 100% confident that this page is complete.

Of course, I can find one hundred good blog posts out there to get this documentation. But how can i edit it if there is a mistake? Tell in a comment and wait for the author to fix the article? How can i improve this blog post to mention a bug in some version of IE? Blog posts are not sustainable for documentation. So are not static websites like W3Schools, especially when specialists of the community need to set up another website to fix the former.

Moreover, with initiatives and platforms like Node.js, Windows 8, MangoDB which use (or will use) JavaScript in non-browser environments, we need more than ever before to better advertise good JavaScript patterns, to better explain the fundamentals of the language, with accurate wording and phrasing.

We do not need documentation since the documentation exists. We need a CC-licenced, user-editable resource. This is the only way we can reach the goal of a good AND sustainable documentation.

Writing the doc ourself

JavaScript is an open technology. It’s not a library or a software with a team dedicated to writing documentation. It’s an open technology. It’s no one’s task to write the doc. Consequently, it’s everyone’s job to do it.

Less than a year ago, Chris Williams encouraged us, Community.js to educate (among other things) people who learn the JavaScript language:

We have made it almost impossible to learn proper JS, a language with both beauty and warts. Some will say it is not our fault, that browser vendors should provide the API documentation for the implementation or that the standards committee should publish and market it. I am calling bullshit on that. I say that it is up to us to invite, welcome, and most importantly properly educate people looking to learn JS. We, the best and brightest of the field, have an obligation to help those who are trying to learn and understand the complexities of the language. We are the ones that benefit from it most, since those now entering the language will be either extending, morphing, or taking over the very projects we are just now starting. Regardless of library, framework, and even language — if everyone knows how to program proper JS a little better, we all win. Period.

And as it turns out, we already write the doc. I see you, pirates of all seas, creating gists, tweeting, writing blog posts to document JavaScript quircks, oddities, bugs, little known facts, best performance patterns. But after these informations have been shared among the hundreds of people in our community, they unfortunately get lost down our timelines, fragmented across the web and our memory. We need to sustain them.

A word on the Mozilla Developer Network ambiguity

I have discussed several times with friends, members of the JS community and one recurrent concern about MDN is that it’s “governed” by Mozilla. To this concern, I have two answers. The first one is that, the people who “govern” the documentation at Mozilla, namely Sheppy and Janet are committed to make the open web technologies (HTML, CSS, JS, SVG, etc.) documentation vendor-neutral. I know for a fact that they are working on creating partenership with other vendors or organizations to have them document their specific features on MDN. That’s one of the things Kevin Lim from Google worked on during the last doc sprint. My second answer is that i am now the King of the JavaScript documentation and i am committed to make this documentation valuable for any web developer regardless of browser preference.

My vision and Mozilla’s on what the JavaScript documentation should be are aligned. If they ever happened to be strongly different, the content is CC-licenced and I could take action to restart fresh somewhere else. But we are currently not in such a situation and am currently confident we won’t be in the foreseeable future.

Does documentation need a King?

Per se, no, no documentation need a king. But like all wiki, it needs some people to take care of overall style consistency, that conventions are respected, that tags and “draft” banners are removed when not needed anymore.

What about Sheppy and Janet?

Yes, there are only 2 persons at Mozilla officially taking care of the MDN documentation. That’s not enough. They do not have enough time to spend on making the JavaScript documentation as good as i wish it was. So, I’m taking the responsability (and they will learn it through this blog post. Hi guys ).

Kingdom scope and priorities

I am not claiming to be the King of all MDN. That’s way too wide for one person. I will take care of all technologies that are part of this JavaScript overview which includes ECMAScript, the DOM (it’s JavaScript binding at least) and all the JavaScript APIs that are described in the HTML5 specification. Having first-class documentation for these things is my first priority.

I wish to document IE8 (and later, of course) and by this is I mean documenting every JavaScript bug that a developer can come across on IE8. Ideally, i woud love to have the same thing on IE6/7, but i think that by the time the previous priorities are accomplished, these won’t have enough market share anymore for us to care about taking the immense amount of time necessary to document these browsers. Of course, contributions on IE6/7 are more than welcome, they are just not on my priorities.

As said above, the JavaScript community is always digging good practices, patterns, best performances. I declare that MDN is a suitable place to sustain these informations!

I also declare that the CommonJS community is welcome to document the mature and widely adopted specifications on MDN. The work done by the CommonJS community needs more visibility, to be widely known by the web dev community, especially all the work on modules which is a recurring issue in JavaScript.

Some APIs like the console API are increasingly becoming de facto standards and have the same need of compatibility tables even though they are not part of the web platform per se. They’ll need to be documented.

Opening the kingdom

What i am going to say in this section was true before, but i am going to say it explictely and out loud. Dear JavaScript Community, you are welcome in my kingdom. This place is yours as well as it is mine. If you believe in a CC-licenced user contributed documentation, my kingdom is open to your participation.

You, JavaScript Pirates of all seas, you are welcome to stop by and share your knowledge. Your thoughts on performance, browser compatibility, good practices, JavaScript patterns as well as shims, tutorials, examples are more than welcome.

Conclusion

Well, I’m the king now! I’m looking forward to see the JavaScript documentation awesome! As it turns out, I will be at the JS Conf EU hanging out at the Hacker lounge. Come by to discuss how to improve the JavaScript doc or report errors/mistakes, learn how to contribute to MDN!

A couple of things learned from the August Doc Sprint

This week-end was a MDN doc sprint. I haven’t had the time to do a lot, but some of the interactions have been really useful and i’d like to share a couple of things i’ve learned.

setImmediate

On the Doc Sprint Etherpad, I have noticed that Jonathan Wilsson (McGurk) added pages for setImmediate and clearImmediate. These not-yet-specified functions aim at being an efficient replacement to setTimeout(0) (which is clamped to 4ms for historical reasons) and its hack-ish postMessage based replacement.

In a way, this is a good news, but it’s a bit overlapping with what TC39 has in mind for concurrency. In an es-discuss e-mail, Mark Miller sounded enthusiastic with the idea of making Q.delay part of the default upcoming concurrency API. This would make 2 features for the same purpose. As stated in the es-discuss quoted thread i started, it would make more sense to bring setTimeout to ECMAScript rather than letting it be part of a web standard since timing issue aren’t really specific to the web. As a matter of fact Node.js uses the same API.

textContent VS innerText

I have improved the style for Node.textContent and have read with great interest the notes which state some difference with Microsoft’s innerText. One being that innerText cannot retrieve the text from <script> and <style> elements. Well… That is the explanation of why Selectivizr explains that “Styles defined in <style> tags won’t be parsed.” (in old IE, of course).

innerHTML counter-intuitive performance

I’ve added a security consideration section to the innerHTML page. It was the occasion to re-read the page and re-find Quircksmode performance test. And even in modern Firefoxes and Chrome, innerHTML keeps being (2-3 times) faster than creating DOM elements in memory and appending them. I have to admit that this is counter-intuitive for me (innerHTML requires parsing and creation of a document fragment while DOM elements manipulation doesn’t require the parsing). The best explanation i can come up with is that innerHTML is one line of JavaScript while the several creations and appending required to do the same operations require roundtrips between native code and JavaScript code. I’m looking forward to see dom.js being finished and hopefully integrated in browsers to re-test its performance against a native innerHTML.

Open e-mail to my lazy friend, Marc Stiegler

Dear Marc,

I guess I should start by apologizing. I know we have never met and it is weird of a thing to do to start a conversation with someone with a blog post. I also apologize to call you “friend”, because not having discussed at all cannot really make us friend. But I feel that there is some sort of connexion, some way of thinking that we share for which we certainly are already “lazy friends” and I thought I should explain it and share with other people.

The most I have seen of you is your incredible talk entitled The Lazy Programmer’s Guide to Secure Computing. And it blew my mind. See, my blog is entitled “long term laziness” and your talk clearly showed that we’re on the same page when it comes to laziness.

A lot of people are lazy in this word, but very few understand that there are different ways to be lazy and you captured it perfectly by distinguishing what you called “amateur lazy programmer” and “professional lazy programmer”. You describe the state of mind of the latter as:

I know that if I don’t do this right the first time. I can spend an extra half hour now or spend a week of agony tomorrow.

And this is a way of life as far as I’m concerned. We apparently use different terminology. I say “long term”, you say “professional”, but I know we’re on the same page.

Overall, it was very fascinating to see how good practices of object-oriented programming turn out to be security features. I had never thought about object-oriented programming this way.

I have showed your talk to a very good friend of mine and the envelope metaphor blew his mind as much as it did to me the first time I saw it. Then, I thought “oh well, that was the big time of his talk, I won’t learn much from now on.”. And I did kept learning, until the last minute.

I really loved the part when you explain what to say to brainwash programmers so that they’d make programs easier to write viruses against. I wouldn’t have expected “Use C or C++” as the very first rule, but your explanation makes a lot of sense.
Also, I have programmed in CakePHP once and at the time, seeing that they had a security class really did leave me a bad taste in the mouth. I’m glad I was not crazy on this one and that having a “security module” in a program is an aberration to a security guru.

Also, the Buffy Summers quote at the end was brilliant!

When I think about it, it makes a lot of sense that you did this talk. Educating people to do less mistakes is so much more lazy than fixing all of these mistakes! I do thank you to have taught me so much in this one-hour video. I certainly be even more careful than I was before when writing programs.

Keep being lazy and inspire people to be so too!

Lazily,

David