80 stories

Reading the Qur'an

1 Share

A few weeks ago, I read the Qur'an[1] while on vacation. I’m not religious, but I figured it must have some positive qualities if over a billion people believe it to be the greatest book ever written. Also it was a short read, maybe 15 hours total.

It turns out I was wrong about the positive qualities. If I didn’t already have an inkling of the depth and breadth of human irrationality, I would be shocked to discover that billions accept this book as gospel. Its lack of divine inspiration is obvious to anyone who isn’t indoctrinated. For example: After a paragraph-long introduction sura, God apparently told Muhammad to title the second (and longest) sura The Cow. There is nothing in the Qur'an that couldn’t have been written by a 7th-century schizophrenic who knew parts of the Old and New Testament. The entire text contains no references to basic biology, chemistry, or physics. There is no mention of the germ theory of disease, evolution, DNA, or fundamental physical constants. It would take but a few pages to outline these topics. Not only would this be evidence of divine inspiration, it would have saved humanity centuries of suffering in squalor.

It’s bad enough that the Qur'an is scientifically ignorant, but it’s also morally backwards. The Qur'an endorses slavery. It mandates lethal punishments for benign actions. The message is anything but, “Turn the other cheek.” It wholeheartedly approves of violence against unbelievers. In addition, much time is spent gloating over the horrific fates of infidels in the afterlife. Muhammad can’t stop fantasizing about fire. He’s like Claude Frollo from Disney’s Hunchback of Notre-Dame. And there’s sexism. The Qur'an is the most sexist text I’ve read.[2] While it’s possible to twist the text and interpret it more equitably (and Haleem’s footnotes make a valiant attempt), a straightforward reading is unambiguous: A woman is simply worth less than a man.

When it comes to the structure of the text, there’s very little to speak of besides its absence. The author comes across as schizophrenic. Suras veer in random directions with little or no warning. In many ways, it reminds me of Time Cube. The Qur'an repeats certain phrases excessively. It’s as if someone loaded a cannon full of stock phrases and shot them at the text, peppering it randomly with, “God is all-merciful.” “God is fully aware of what you do.” “God is not unaware of what you do.” and so on. Over and over and over. One begins to wonder if God feels insecure.

In short, the Qur'an is a terrible guide for how to live one’s life in the 21st century. It was clearly authored by a 7th-century human. But don’t take my word for it. Read the text yourself and come to your own conclusions.

  1. The specific version was M. A. S. Abdel Haleem’s English translation of the Qur'an, which is widely considered to be the best.
  2. I haven’t read the Bible in its entirety, though I bet it’s similar.
Read the whole story
Share this story

Some Shop Axioms

1 Share


If you don’t know what to do, don’t do anything, then you waste nothing but your time and are not likely to waste any material. It is better to do nothing than to do something wrong. It affects the nerves of the boss less, as well as leaving more money in his purse.

If you do not know what is the right thing to do, and do not find out from those that do know, and thereby do something wrong, the error is yours, and you alone are responsible. It is a poor excuse to say that you weren’t told not to do it the way you blindly went at it. It doesn’t cost near as much to ask questions as it does to do the job a second time.

If you start to do a job without a clear idea of the result you wish to attain you are like a man with his eyes blindfolded going over a rocky road: you will stumble often and make many a start only to fall down again. Whereas if you have planned your job beforehand you will see the rocks in the way and go around them instead of falling over them.

The idea of thinking that you can do the job, as far as it looks plain to you, and then find a way to complete it, is all wrong, because you will often find that when you do part of it another part will conflict with the work already done, and you will have some of it to do a second time.

Did it ever occur to you that every time you do a job over you are paid double for the work you do right? Of course, it is impossible for any man to do every job just right the first time, but it is possible to get the percentage of errors very low. If you knew you were to be paid only for work that was correct how much do you think you could reduce your errors?

When the boss has a contract he only gets paid for the work he does right, unless he is smart (?) enough to make the customer believe it is right in any event. The customer may be fooled once or twice, but he goes to another place for his work later on. The boss gets short of work and you look for another job.

The man that tries to do the right thing will have few troubles. When you are wrong be honest about it. Don’t equivocate and try to crawl out of it—there is no half way point. A thing is either right or it is wrong. The honest man that accepts the responsibility for his deeds will command respect everywhere.

Do your work right as best you know. Do right with those associated with you. Don’t impose or be imposed upon. If you work an hour on a job you can do in a half hour, you are not honest with your employer. If you must put an hour on a half-hour job, do the job in a half hour and rest the other half.

The man that makes a job last when work gets short will likely have it last just till he completes that one job. A man that stretches a job is not a safe man to have about, because he doesn’t do what he is paid for doing. Men that shirk never become very well known. I often think the bees are wiser than we humans, they kill off the drones.

A man that only does just what he is paid for does just that much and gets the same pay year after year. The one that does more than is required of him and doesn’t need to be told to do it, is found to attract attention to himself, and when he does that he is on the road to success. One never gets a thing until he shows that he is entitled to it, unless he steals it. If you want to rise above your present position work and think.

J.L. Gard

The Patternmaker – February, 1905

—Jeff Burks

Filed under: Historical Images
Read the whole story
Share this story

Songs from the Workbench: Guy Clark

1 Share

Singer and songwriter Guy Clark builds both melodies and guitars in the woodshop of his Nashville home. by Megan Fitzpatrick Songwriter, singer and luthier Guy Clark doesn’t like technology. “I put away all my recording stuff, built this workbench, ordered some wood and started building stuff,” he says. The most high-tech machines on display in his workshop are a Delta band saw, a Craftsman drill press, a stereo receiver and […]

The post Songs from the Workbench: Guy Clark appeared first on Popular Woodworking Magazine.

Read the whole story
Share this story

Change is bad unless it’s great: Lessons from user revolts against Foursquare’s Swarm and the new Skype for iPhone

1 Share

As I write this the latest version of Skype for the iPhone has a 2 star rating as does Swarm by Foursquare. What these apps have in common is that they are both part of bold attempts to redesign a well-known and popular app which are being rejected by its core constituency. A consequence of my time working on Windows 8 is that I now obsess quite a bit about redesigning apps and determining what warning signs indicate that you are either going to greatly please or strongly offend your best users.

When I worked on Windows 8, there were a number of slogans that the team used to ensure the principles behind the work we were doing were understood by all. Some of them such as “content over chrome” were counterproductive in that slavish devotion to them led to ignoring decades of usability research by eschewing affordances and hiding navigation/controls within apps. However there were other principles from the Windows 8 era which I wish app developers took more to heart such as “win as one” which encouraged consistency with the overall platform’s UI model & working with other apps and “change is bad unless it's great” which encouraged respecting the past and only making changes that provided a noticeably better user experience. 

In addition to these two principles, I’ll add one more for app developer to keep in mind whenever the time calls for a redesign; “minimize the impacts of loss aversion”. For those who aren’t familiar with the term, loss aversion (aka the endowment effect) is the tendency for humans to strongly prefer avoiding losses to making gains. What this means for developers is that end users will react more strongly to losing a feature than they would to gaining that same feature. There are numerous studies that show how absurd humans can be in the face of loss aversion no matter how minor. My favorite example is how much people overreact to loss aversion when it comes to grocery shopping as taken from this blog post by Jon Geeting

There was a law set up last month in D.C. (passed unanimously by city council) to place a five-cent tax on paper and plastic bags at grocery stores, pharmacies and other food-service providers. So, basically, if I went shopping, my total came to $35.20, and I needed one bag to put it in, my total would then become $35.25. Similarly, if I needed two bags, my total would become $35.30, and so on — while if I simply bought reusable bags, I would be subject to no tax.

From what I hear from people in D.C., they absolutely hate it. Even though it’s just an extra five cents, they want absolutely nothing to do with it. They really want that nickel. So many people use less bags, bring their own, or just try to balance everything without one on their trip home. Think about how much less waste and pollution there is in D.C. now, because of a measly five-cent fee.

On the flip side, if you told people you’d give them 5 cents for each bag they brought from home they’d laugh in your face. Nobody is going to do an extra bit of work to be paid five cents even though they would do that work to avoid paying 5 cents. That’s loss aversion at work.

To recap, if you are redesigning an app you need to keep these three rules in mind

  1. Win as one: Whatever changes you make must feel like a consistent whole both within the app and with the platform your app resides on. Swarm and Foursquare have completely different aesthetics and integrate in a fairly disjointed manner often with no way to easily jump back and forth between both apps. Skype for iPhone is pretty much a Windows Phone app in look and feel complete with pivot controls and cut off title text. This is a very jarring experience compared to everything else on iOS.

  2. Change is bad unless it’s great: App developers need to be honest with themselves about whether a redesign is about solving a customer problem in a better way or is part of a corporate strategy. Facebook news feed is an example of a redesign which was actually driven by a need to solve customer problems which is why although it met with a massive user revolt at first, once people used it they loved it and the anger died down. Swarm exists because FourSquare now wants to compete with Yelp and needs to shed its history as a social check-in app which it sees as baggage as it evolves into a social discovery engine of things to do in your city. From an end user perspective, Skype for iPhone’s redesign is about making the app look and feel like a Microsoft metro-style app. Given these primary goals, it is no surprise that end users can tell that solving their problems came in second place as they review these apps.

  3. Minimize the impacts of loss aversion: Coupling a redesign with taking away features means people will focus on the missing features instead of whatever benefits you have provided with the redesign. Foursquare took away badges, mayorships, social feed of your friends check-ins and points as part of the split that created Swarm. There are a large number of one star reviews of the Swarm app complaining about these missing features. Skype for iPhone’s initial release took away deleting & editing messages while making others harder to find. Even features that are used once in a blue moon seem mission critical once people find out they are gone. Taking away features will always sting more than the actual value of those features. Taking multiple features away as part of a redesign means any benefits of the redesign will be lost in the ensuing outrage about the missing features.

Note Now Playing: Rick RossThe Devil is a Lie (featuring Jay-Z)Note

Read the whole story
Share this story

The Dangers of Stopping Event Propagation

1 Comment and 3 Shares

The following is a guest post by Philip Walton (@philwalton). He is going to explain why stopping event propagation isn't something you should do lightly, and probably something you should avoid altogether.

If you're a front end developer, at some point in your career you've probably had to build a popup or dialog that dismissed itself after the user clicked anywhere else on the page. If you searched online to figure out the best way to do this, chances are you came across this Stack Overflow question: How to detect a click outside an element?.

Here's what the highest rated answer recommends:

$('html').click(function() {
  // Hide the menus if visible.


In case it's not clear what this code is doing, here's a quick rundown: If a click event propagates to the <html> element, hide the menus. If the click event originated from inside #menucontainer, stop that event so it will never reach the <html> element, thus only clicks outside of #menucontainer will hide the menus.

The above code is simple, elegant, and clever all at the same time. Yet, unfortunately, it's absolutely terrible advice.

This solution is roughly equivalent to fixing a leaky shower by turning off the water to the bathroom. It works, but it completely ignores the possibility that any other code on the page might need to know about that event.

Still, it's the most upvoted answer to this question, so people assume it's sound advice.

What Can Go Wrong?

You might be thinking to yourself: who even writes code like this themselves anymore? I use a well-tested library like Bootstrap, so I don't need to worry, right?

Unfortunately, no. Stopping event propagation is not just something recommended by bad Stack Overflow answers; it's also found in some of the most popular libraries in use today.

To prove this, let me show you how easy it is to create a bug by using Bootstrap in a Ruby on Rails app. Rails ships with a JavaScript library called jquery-ujs that allows developers to declaratively add remote AJAX calls to links via the data-remote attribute.

In the following example, if you open the dropdown and click anywhere else in the frame, the dropdown should close itself. However, if you open the dropdown and then click on "Remote Link", it doesn't work.

See the Pen Stop Propagation Demo by Philip Walton (@philipwalton) on CodePen.

This bug happens because the Bootstrap code responsible for closing the dropdown menu is listening for click events on the document. But since jquery-ujs stops event propagation in its data-remote link handlers, those clicks never reach the document, and thus the Bootstrap code never runs.

The worst part about this bug is that there's absolutely nothing that Bootstrap (or any other library) can do to prevent it. If you're dealing with the DOM, you're always at the mercy of whatever other poorly-written code is running on the page.

The Problem with Events

Like a lot of things in JavaScript, DOM events are global. And as most people know, global variables can lead to messy, coupled code.

Modifying a single, fleeting event might seem harmless at first, but it comes with risks. When you alter the behavior that people expect and that other code depends on, you're going to have bugs. It's just a matter of time.

And in my experience, these sorts of bugs are some of the hardest to track down.

Why Do People Stop Event Propagation?

We know there's bad advice on the Internet promoting the unnecessary use of stopPropagation, but that isn't the only reason people do it.

Frequently, developers stop event propagation without even realizing it.

Return false

There's a lot of confusion around what happens when you return false from an event handler. Consider the following three cases:

<!-- An inline event handler. -->
<a href="http://google.com" onclick="return false">Google</a>
// A jQuery event handler.
$('a').on('click', function() {
  return false;
// A native event handler.
var link = document.querySelector('a');

link.addEventListener('click', function() {
  return false;

These three examples all appear to be doing the exact same thing (just returning false), `false`), but in reality the results are quite different. Here's what actually happens in each of the above cases:

  1. Returning false from an inline event handler prevents the browser from navigating to the link address, but it doesn't stop the event from propagating through the DOM.
  2. Returning false from a jQuery event handler prevents the browser from navigating to the link address and it stops the event from propagating through the DOM.
  3. Returning false from a regular DOM event handler does absolutely nothing.

When you expect something to happen and it doesn't, it's confusing, but you usually catch it right away. A much bigger problem is when you expect something to happen and it does but with unanticipated and unnoticed side-effects. That's where nightmare bugs come from.

In the jQuery example, it's not at all clear that returning false would behave any differently than the other two event handlers, but it does. Under the hood, jQuery is actually invoking the following two statements:


Because of the confusion around return false, and the fact that it stops event propagation in jQuery handlers, I'd recommend never using it. It's much better to be explicit with your intentions and call those event methods directly.

Note: If you use jQuery with CoffeeScript (which automatically returns the last expression of a function) make sure you don't end your event handlers with anything that evaluates to the Boolean false or you'll have the same problem.


Every so often you'll read some advice (usually written a while ago) that recommends stopping propagation for performance reasons.

Back in the days of IE6 and even older browsers, a complicated DOM could really slow down your site. And since events travel through the entire DOM, the more nodes you had, the slower everything got.

Peter Paul Koch of quirksmode.org recommended this practice in an old article on the subject:

If your document structure is very complex (lots of nested tables and such) you may save system resources by turning off bubbling. The browser has to go through every single ancestor element of the event target to see if it has an event handler. Even if none are found, the search still takes time.

With today's modern browsers, however, any performance gains you get from stopping event propagation will likely go unnoticed by your users. It's a micro-optimization and certainly not your performance bottleneck.

I recommend not worrying about the fact that events propagate through the entire DOM. After all, it's part of the specification, and browsers have gotten very good at doing it.

What To Do Instead

As a general rule, stopping event propagation should never be a solution to a problem. If you have a site with several event handlers that sometimes interfere with each other, and you discover that stopping propagation makes everything work, that's a bad thing. It might fix your immediate problem, but it's probably creating another one you're not aware of.

Stopping propagation should be thought of like canceling an event, and it should only be used with that intent. Perhaps you want to prevent a form submission or disallow focus to an area of the page. In these cases you're stopping propagation because you don't want an event to happen, not because you have an unwanted event handler registered higher up in the DOM.

In the "How to detect a click outside of an element?" example above, the purpose of calling stopPropagation isn't to get rid of the click event altogether, it's to avoid running some other code on the page.

In addition to this being a bad idea because it alters global behavior, it's a bad idea because it puts the menu hiding logic in two different and unrelated places, making it far more fragile than necessary.

A much better solution is to have a single event handler whose logic is fully encapsulated and whose sole responsibility is to determine whether or not the menu should be hidden for the given event.

As it turns out, this better option also ends up requiring less code:

$(document).on('click', function(event) {
  if (!$(event.target).closest('#menucontainer').length) {
    // Hide the menus.

The above handler listens for clicks on the document and checks to see if the event target is #menucontainer or has #menucontainer as a parent. If it doesn't, you know the click originated from outside of #menucontainer, and thus you can hide the menus if they're visible.

Default Prevented?

About a year ago I start writing an event handling library to help deal with this problem. Instead of stopping event propagation, you would simply mark an event as "handled". This would allow event listeners registered farther up the DOM to inspect an event and, based on whether or not it had been "handled", determine if any further action was needed. The idea was that you could "stop event propagation" without actually stopping it.

As it turned out, I never ended up needing this library. In 100% of the cases where I found myself wanting to check if an event hand been "handled", I noticed that a previous listener had called preventDefault. And the DOM API already provides a way to inspect this: the defaultPrevented property.

To help clarify this, let me offer an example.

Imagine you're adding an event listener to the document that will use Google Analytics to track when users click on links to external domains. It might look something like this:

$(document).on('click', 'a', function(event) function() {
  if (this.hostname != 'css-tricks.com') {
    ga('send', 'event', 'Outbound Link', this.href);

The problem with this code is that not all link clicks take you to other pages. Sometimes JavaScript will intercept the click, call preventDefault and do something else. The data-remote links described above are a prime example of this. Another example is a Twitter share button that opens a popup instead of going to twitter.com.

To avoid tracking these kinds of clicks, it might be tempting to stop event propagation, but inspecting the event for defaultPrevented is a much better way.

$(document).on('click', 'a', function(event) function() {

  // Ignore this event if preventDefault has been called.
  if (event.defaultPrevented) return;

  if (this.hostname != 'css-tricks.com') {
    ga('send', 'event', 'Outbound Link', this.href);

Since calling preventDefault in a click handler will always prevent the browser from navigating to a link's address, you can be 100% confident that if defaultPrevented is true, the user did not go anywhere. In other words, this technique is both more reliable than stopPropagation, and it won't have any side effects.


Hopefully this article has helped you think about DOM events in a new light. They're not isolated pieces that can be modified without consequence. They're global, interconnected objects that often affect far more code than you initially realize.

To avoid bugs, it's almost always best to leave events alone and let them propagate as the browser intended.

If you're ever unsure about what to do, just ask yourself the following question: is it possible that some other code, either now or in the future, might want to know that this event happened? The answer is usually yes. Whether it be for something as trivial as a Bootstrap modal or as critical as event tracking analytics, having access to event objects is important. When in doubt, don't stop propagation.

The Dangers of Stopping Event Propagation is a post from CSS-Tricks

Read the whole story
Share this story
1 public comment
3688 days ago
Stop stopProp'ing
Saratoga Springs, New York

Battlefield 4 player stats

1 Share

Just finished another game visualization project, graphs of stats for the top 5000 BF4 players. It makes scatterplots for the player population of statistics like skill score vs time played, win/loss ratio vs. skill, and kill/death vs. win/loss. Lots of details in this Reddit post.

Another fun D3 project; scrape a bunch of data, cook it into a 2 megabyte CSV file, then do custom visualizations. I like the way the scatterplot came out and may re-mix it as a generic data exploration tool, a sort of GGobi lite in your web browser. Drop a CSV file into your browser window and get a simple tool for exploring it for correlations.

It’s frustrating trying to get attention for projects like this. All I know to do is post it to the relevant subreddit and hope for the up-votes, but that’s pretty random. My Reddit attempt for the LoL lag tool failed, and a site I worked about 50 hours on has had a total of a few hundred visitors after a week. Discouraging.

Read the whole story
Share this story
Next Page of Stories