Reading List
The most recent articles from a list of feeds I subscribe to.
git commit -m "EVERYTHING"
I was working on a project today, when I realized that I had forgotten to commit for days (local only repo). I switched to my terminal, spent at least five minutes trying to decide on the commit message before settling to the completely uninformative “Another commit”. Embarrassed with myself, I shared my frustration with twitter:
https://twitter.com/LeaVerou/status/187533962283986944
Immediately, I started getting a flood of suggestions of what that commit message could have been. Some of them were hilarious, some clever and some both. So, I decided I wouldn’t be selfish and I’d share them. Enjoy:
https://twitter.com/codepo8/status/187534089937620994
https://twitter.com/vmasto/status/187534173429448704
https://twitter.com/GovertVerschuur/status/187534218790846466
https://twitter.com/upperdog_se/status/187534242182467584
https://twitter.com/brunoscheele/status/187534245437243392
https://twitter.com/idiot/status/187534264265490433
https://twitter.com/LukeMaciak/status/187534411955314688
https://twitter.com/jfgen/status/187534471703175168
https://twitter.com/AlexGraul/status/187534893436256259
https://twitter.com/captcodemonkey/status/187535071627059201
https://twitter.com/BoltClock/status/187535138266165248
https://twitter.com/jwkozel/status/187535407397863425
https://twitter.com/skidding/status/187536889715228672
https://twitter.com/omgmog/status/187537072213598209
https://twitter.com/stevehickeydsgn/status/187538150007123969
https://twitter.com/_dte/status/187538777441452032
https://twitter.com/nathandim/status/187538945305870336
https://twitter.com/jwkozel/status/187539130585063424
https://twitter.com/LukeMaciak/status/187539160851165184
https://twitter.com/croncobaurul/status/187539379428925442
https://twitter.com/MayaPosch/status/187539668793950208
https://twitter.com/OllyHodgson/status/187539827493834752
https://twitter.com/eternicode/status/187540177734991873
https://twitter.com/mrtnrsl/status/187540310094643201
https://twitter.com/kioopi/status/187540668728619008
https://twitter.com/streetpc/status/187541599532744704
https://twitter.com/GNi33/status/187541700091195392
https://twitter.com/jo\_Osiah/status/187541784870666241
https://twitter.com/dalecruse/status/187541971949203460
https://twitter.com/jordanpittman/status/187542101658058753
https://twitter.com/michelegera/status/187542353446313984
git commit -m "EVERYTHING"
I was working on a project today, when I realized that I had forgotten to commit for days (local only repo). I switched to my terminal, spent at least five minutes trying to decide on the commit message before settling to the completely uninformative “Another commit”. Embarrassed with myself, I shared my frustration with twitter:
https://twitter.com/LeaVerou/status/187533962283986944
Immediately, I started getting a flood of suggestions of what that commit message could have been. Some of them were hilarious, some clever and some both. So, I decided I wouldn’t be selfish and I’d share them. Enjoy:
https://twitter.com/codepo8/status/187534089937620994
https://twitter.com/vmasto/status/187534173429448704
https://twitter.com/GovertVerschuur/status/187534218790846466
https://twitter.com/upperdog_se/status/187534242182467584
https://twitter.com/brunoscheele/status/187534245437243392
https://twitter.com/idiot/status/187534264265490433
https://twitter.com/LukeMaciak/status/187534411955314688
https://twitter.com/jfgen/status/187534471703175168
https://twitter.com/AlexGraul/status/187534893436256259
https://twitter.com/captcodemonkey/status/187535071627059201
https://twitter.com/BoltClock/status/187535138266165248
https://twitter.com/jwkozel/status/187535407397863425
https://twitter.com/skidding/status/187536889715228672
https://twitter.com/omgmog/status/187537072213598209
https://twitter.com/stevehickeydsgn/status/187538150007123969
https://twitter.com/_dte/status/187538777441452032
https://twitter.com/nathandim/status/187538945305870336
https://twitter.com/jwkozel/status/187539130585063424
https://twitter.com/LukeMaciak/status/187539160851165184
https://twitter.com/croncobaurul/status/187539379428925442
https://twitter.com/MayaPosch/status/187539668793950208
https://twitter.com/OllyHodgson/status/187539827493834752
https://twitter.com/eternicode/status/187540177734991873
https://twitter.com/mrtnrsl/status/187540310094643201
https://twitter.com/kioopi/status/187540668728619008
https://twitter.com/streetpc/status/187541599532744704
https://twitter.com/GNi33/status/187541700091195392
https://twitter.com/jo\_Osiah/status/187541784870666241
https://twitter.com/dalecruse/status/187541971949203460
https://twitter.com/jordanpittman/status/187542101658058753
https://twitter.com/michelegera/status/187542353446313984
In defense of reinventing wheels
One of the first things a software engineer learns is “don’t reinvent the wheel”. If something is already made, use that instead of writing your own. “Stand on the shoulders of giants, they know what they’re doing better than you”. Writing your own tools and libraries, even when one already exists, is labelled “NIH syndrome” and is considered quite bad. “But what if my version is better?”. Surely, reinventing the wheel can’t be bad when your new wheel improves existing wheel designs, right? Well, not if the software is open source, which is usually the case in our industry. “Just contribute to it” you’ll be told. However, contributing to an open source project is basically teamwork. The success of any team depends on how well its members work together, which is not a given. Sometimes, your vision about the tool might be vastly different from that of the core members and it might be wiser to create your own prototype than to try and change the minds of all these people.
However, Open Source politics is not what I wanted to discuss today. It’s not the biggest potential benefit of reinventing the wheel. Minimizing overhead is. You hardly ever need 100% of a project. Given enough time to study its inner workings, you could always delete quite a large chunk of it and it would still fit your needs perfectly. However, the effort needed to do that or to rewrite the percentage you actually need is big enough that you are willing to add redundant code to your codebase.
Redundant code is bad. It still needs to get parsed and usually at least parts of it still need to be executed. Redundant code hinders performance. The more code, the slower your app. Especially when we are dealing with backend code, when every line might end up being executed hundreds or even thousands of times per second. The slower your app becomes, the bigger the need to seriously address performance. The result of that is even more code (e.g. caching stuff) that could have been saved in the first place, by just running what you need. This is the reason software like Joomla, Drupal or vBulletin is so extremely bloated and brings servers to their knees if a site becomes mildly successful. It’s the cost of code that tries to match everyone’s needs.
Performance is not the only drawback involved in redundant code. A big one is maintainability. This code won’t only need to be parsed by the machine, it will also be parsed by humans, that don’t know what’s actually needed and what isn’t until they understand what every part does. Therefore, even the simplest of changes become hard.
I’m not saying that using existing software or libraries is bad. I’m saying that it’s always a tradeoff between minimizing effort on one side and minimizing redundant code on the other side. I’m saying that you should consider writing your own code when the percentage of features you need from existing libraries is tiny (lets say less than 20%). It might not be worth carrying the extra 80% forever.
For example, in a project I’m currently working on, I needed to make a simple localization system so that the site can be multilingual. I chose to use JSON files to contain the phrases. I didn’t want the phrases to include HTML, since I didn’t want to have to escape certain symbols. However, they had to include simple formatting like bold and links, otherwise the number of phrases would have to be huge. The obvious solution is Markdown.
My first thought was to use an existing library, which for PHP is PHP Markdown. By digging a bit deeper I found that it’s actually considered pretty good and it seems to be well maintained (last update in January 2012) and mature (exists for over 2 years). I should happily use it then, right?
That’s what I was planning to do. And then it struck me: I’m the only person writing these phrases. Even if more people write translations in the future, they will still go through me. So far, the only need for such formatting is links and bold. Everything else (e.g. lists) is handled by the HTML templates. That’s literally two lines of PHP! So, I wrote my own function. It’s a bit bigger, since I also added emphasis, just in case:
function markdown($text) {
// Links
$text = preg\_replace('@\\\\\[(.+?)\\\\\]\\\\((#.+?)\\\\)@', '<a href="$2">$1</a>', $text);
// Bold
$text = preg\_replace('@(?<!\\\\\\\\)\\\\\*(?<!\\\\\\\\)\\\\\*(.+?)(?<!\\\\\\\\)\\\\\*(?<!\\\\\\\\)\\\\\*@', '<strong>$1</strong>', $text);
// Emphasis
$text = preg\_replace('@(?<!\\\\\\\\)\\\\\*(.+?)(?<!\\\\\\\\)\\\\\*@', '<em>$1</em>', $text);
return $text;
}
Since PHP regular expressions also support negative lookbehind, I can even avoid escaped characters, in the same line. Unfortunately, since PHP lacks regular expression literals, backslashes have to be doubled (\\ instead of \ so \\\\ instead of \\, which is pretty horrible).
For comparison, PHP Markdown is about 1.7K lines of code. It’s great, if you need the full power of Markdown (e.g. for a comment system) and I’m glad Michel Fortin wrote it. However, for super simple, controlled use cases, is it really worth the extra code? I say no.
Rachel Andrew recently wrote about something tangentially similar, in her blog post titled “Stop solving problems you don’t yet have”. It’s a great read and I’d advise you to read that too.
In defense of reinventing wheels
One of the first things a software engineer learns is “don’t reinvent the wheel”. If something is already made, use that instead of writing your own. “Stand on the shoulders of giants, they know what they’re doing better than you”. Writing your own tools and libraries, even when one already exists, is labelled “NIH syndrome” and is considered quite bad. “But what if my version is better?”. Surely, reinventing the wheel can’t be bad when your new wheel improves existing wheel designs, right? Well, not if the software is open source, which is usually the case in our industry. “Just contribute to it” you’ll be told. However, contributing to an open source project is basically teamwork. The success of any team depends on how well its members work together, which is not a given. Sometimes, your vision about the tool might be vastly different from that of the core members and it might be wiser to create your own prototype than to try and change the minds of all these people.
However, Open Source politics is not what I wanted to discuss today. It’s not the biggest potential benefit of reinventing the wheel. Minimizing overhead is. You hardly ever need 100% of a project. Given enough time to study its inner workings, you could always delete quite a large chunk of it and it would still fit your needs perfectly. However, the effort needed to do that or to rewrite the percentage you actually need is big enough that you are willing to add redundant code to your codebase.
Redundant code is bad. It still needs to get parsed and usually at least parts of it still need to be executed. Redundant code hinders performance. The more code, the slower your app. Especially when we are dealing with backend code, when every line might end up being executed hundreds or even thousands of times per second. The slower your app becomes, the bigger the need to seriously address performance. The result of that is even more code (e.g. caching stuff) that could have been saved in the first place, by just running what you need. This is the reason software like Joomla, Drupal or vBulletin is so extremely bloated and brings servers to their knees if a site becomes mildly successful. It’s the cost of code that tries to match everyone’s needs.
Performance is not the only drawback involved in redundant code. A big one is maintainability. This code won’t only need to be parsed by the machine, it will also be parsed by humans, that don’t know what’s actually needed and what isn’t until they understand what every part does. Therefore, even the simplest of changes become hard.
I’m not saying that using existing software or libraries is bad. I’m saying that it’s always a tradeoff between minimizing effort on one side and minimizing redundant code on the other side. I’m saying that you should consider writing your own code when the percentage of features you need from existing libraries is tiny (lets say less than 20%). It might not be worth carrying the extra 80% forever.
For example, in a project I’m currently working on, I needed to make a simple localization system so that the site can be multilingual. I chose to use JSON files to contain the phrases. I didn’t want the phrases to include HTML, since I didn’t want to have to escape certain symbols. However, they had to include simple formatting like bold and links, otherwise the number of phrases would have to be huge. The obvious solution is Markdown.
My first thought was to use an existing library, which for PHP is PHP Markdown. By digging a bit deeper I found that it’s actually considered pretty good and it seems to be well maintained (last update in January 2012) and mature (exists for over 2 years). I should happily use it then, right?
That’s what I was planning to do. And then it struck me: I’m the only person writing these phrases. Even if more people write translations in the future, they will still go through me. So far, the only need for such formatting is links and bold. Everything else (e.g. lists) is handled by the HTML templates. That’s literally two lines of PHP! So, I wrote my own function. It’s a bit bigger, since I also added emphasis, just in case:
function markdown($text) {
// Links
$text = preg\_replace('@\\\\\[(.+?)\\\\\]\\\\((#.+?)\\\\)@', '<a href="$2">$1</a>', $text);
// Bold
$text = preg\_replace('@(?<!\\\\\\\\)\\\\\*(?<!\\\\\\\\)\\\\\*(.+?)(?<!\\\\\\\\)\\\\\*(?<!\\\\\\\\)\\\\\*@', '<strong>$1</strong>', $text);
// Emphasis
$text = preg\_replace('@(?<!\\\\\\\\)\\\\\*(.+?)(?<!\\\\\\\\)\\\\\*@', '<em>$1</em>', $text);
return $text;
}
Since PHP regular expressions also support negative lookbehind, I can even avoid escaped characters, in the same line. Unfortunately, since PHP lacks regular expression literals, backslashes have to be doubled (\\ instead of \ so \\\\ instead of \\, which is pretty horrible).
For comparison, PHP Markdown is about 1.7K lines of code. It’s great, if you need the full power of Markdown (e.g. for a comment system) and I’m glad Michel Fortin wrote it. However, for super simple, controlled use cases, is it really worth the extra code? I say no.
Rachel Andrew recently wrote about something tangentially similar, in her blog post titled “Stop solving problems you don’t yet have”. It’s a great read and I’d advise you to read that too.
Flexible multiline definition lists with 2 lines of CSS 2.1
If you’ve used definition lists (<dl>) you’re aware of the problem. By default, <dt>s and <dd>s have display:block. In order to turn them into what we want in most cases (each pair of term and definition on one line) we usually employ a number of different techniques:
- Using a different
<dl>for each pair: Style dictating markup, which is bad - Floats: Not flexible
display: run-in;on the<dt>: Browser support is bad (No Firefox support)- Adding a
<br>after each<dd>and setting both term and definition asdisplay:inline: Invalid markup. Need I say more?
If only adding <br>s was valid… Or, even better, what if we could insert <br>s from CSS? Actually, we can! As you might be aware, the CR and LF characters that comprise a line break are regular unicode characters that can be inserted anywhere just like every unicode character. They have the unicode codes 000D and 000A respectively. This means they can also be inserted as generated content, if escaped properly. Then we can use an appropriate white-space value to make the browser respect line breaks only in that part (the inserted line break). It looks like this:
dd:after { content: ‘\A’; white-space: pre; }
Note that nothing above is CSS3. It’s all good ol’ CSS 2.1.
Of course, if you have multiple <dd>s for every <dt>, you will need to alter the code a bit. But in that case, this formatting probably won’t be what you want anyway.
Edit: As Christian Heilmann pointed out, HTML3 (!) used to have a compact attribute on <dl> elements, which basically did this. It is now obsolete in HTML5, like every other presentational HTML feature.
You can see a live result here:
Tested to work in IE8+, Chrome, Firefox 3+, Opera 10+, Safari 4+.