On Markdown and how to fork a project

Markdown and its syntax specification were developed by John Gruber as a text-to-HTML conversion tool for webwriters. Over the years, it has been widely adopted by sites likes GitHub and StackExchange. Most programming languages have some kind of Markdown library available, always developed not by Gruber but by some third party.

The syntax for Markdown hasn’t been updated in years. Different implementations implement Markdown different… and output different HTML code for the same markdown. Jeff Atwood (Coding Horror), John MacFarlane and others have launched an initiative to work around the limits of the current Markdown specification. Jeff Atwood explains their motivations in his post standard flavored markdown.

The ‘problem’ is they chose to name their project Standard Markdown. After a mail from John Gruber stating that he found the name inappropiate, they renamed it to Common Markdown, which doesn’t seem adequate either.

I think standarizing Markdown is the correct thing to do. But if the initiative does not come from the project owner, the way to standarize an open source project is to fork it and change its name to whatever you want.

Tags: markdown

Marco Arment on Overcast

Just finished listening to Episode 43 of Debug, where Guy English and Rene Ritchie interview Marco Arment about the recent launch of Overcast, his podcasting app for iPhone.

The episode is great. It is around three hours long but worth the time if you are interested in iOS development and the app ecosystem. Marco explains some of the problems he found while implementing the app and how he solved them, and his product design decisions.

Link: Debug Episode 43.

Tags: ios

Link: glFlush(); goto Metal;

Nice piece from Guy English about Metal, Apple’s new API for lower level access to the GPU than is afforded by OpenGL ES.

Tags: metal, opengl, api

Don’t be afraid to take risks

A quote from _why about experimenting and taking risks, before his disapparition.

I do not write tests for my code. I do not write very many comments. I change styles very frequently. And most of all, I shun the predominant styles of coding, because that would go against the very essence of experimentation. In short: all I do is muck around.

So, my way of measuring a great programmer is different from some prevailing thought on the subject. I would like to hear what Matz would say about this. You should ask him, seriously.

I admire programmers who take risks. They aren’t afraid to write dangerous or “crappy” code. If you worry too much about being clean and tidy, you can’t push the boundaries (I don’t think!). I also admire programmers who refuse to stick with one idea about the “way the world is.” These programmers ignore protocol and procedure. I really like Autrijus Tang because he embraces all languages and all procedures. There is no wrong way in his world.

Anyway, you say you want to become better. I mean that’s really all you need. You feel driven, so stick with it. I would also start writing short scripts to share with people on the Web. Little Ruby scripts or Rails programs or MouseHole scripts to show off. Twenty lines here and there, and soon people will be beating you up and you’ll be scrambling to build on those scripts and figure out your style and newer innovations and so on.

— _why

Tags: risks, _why

Infocom’s The Hitchhiker’s Guide to the Galaxy original ad

I spend hours playing this game…

The Hitchhiker's Guide to the Galaxy original ad{: style=’padding: 0; margin: 5px 10px 5px 0;’ }

Tags: games

Link: Time interviews Jonathan Ive

Interviews to Apple’s Senior VP of Design are unfrequent. Worth reading.

Objects and their manufacture are inseparable. You understand a product if you understand how it’s made. I want to know what things are for, how they work, what they can or should be made of, before I even begin to think what they should look like. More and more people do. There is a resurgence of the idea of craft.

How the Heartbleed works, by xkcd

Tags: heartbleed, openssl, ssl, security

Link: Debug 31: Miguel de Icaza on Mono

Guy English and Rene Ritchie interview Miguel de Icaza in Episode 31 of Debug. I liked the interview very much, specially from minute 20 on when Miguel talks about functionality and implementation details of the Mono runtime, async calls, garbage collection…

Tags: Mono, F#, garbage collection

Link: Science is about what is. Engineering is about what can be

Science is about what is. Engineering is about what CAN be.” (via PhD Comics)

Link: Write the code. Change the world (WWDC 2014)

« Page 2 / 5 »