I’m slowly copying the markdown versions of my posts after my recent move of this blog. It really is tedious, and I don’t think I’ll finish anytime soon, so in the meantime I created a plugin to output the [ code] shortcode that wordpress.com put in my post export in the same way that markdown does. This is the first plugin and shortcode I’ve created in a long while, but it was relatively quick to do working off of my posts on plugins and shortcodes. The biggest time consumer was figuring out how to deal with whitespace issues. Apparently, WordPress sometimes will add <p> and <br /> to shortcode content. Also, there were leading and trailing line breaks adding unnecessary space. My quick solution:
I have always had trouble understanding and even believing the proposition of the Monty Hall problem. It feels like it is proposing that the probability of past events affect the probability of future events, like suggesting that a coin landing on heads will be more likely to land on tails the next time. Rather, it’s about the information provided by the circumstances. I still don’t intuitively understand it, but at least I have now verified for myself that the proposed probability approximates outcomes. I have created a PHP simulation of the game and script to iterate it numerous times.
The code allows testing other numbers of doors and number of doors for the host to reveal. Increasing the numbers shows increasing odds. Even if Monty opens less than all but the remaining door (obviously requires more than three total doors), it still increases odds by switching.
I’ve been spending a lot of time at work recently working on another phone app. Like our other apps, we’re using Phone Gap to build an app with web technologies. Like one previous app, we’re using Backbone, adding Marionette to help this time. Backbone apps are generally SPA‘s that rerender entire pieces of the HTML document when the underlying data changes. This can often be basically the entire content of the document when you change routes.
What happens when hitting the back button varies from browser to browser. Some, like Chrome, try to remember the scroll position for each fragment identifier (how Backbone handles routes by default), while others, such as Safari, do not. When they do not, it can be a usability problem working with lists of items. You might visit the detail page of one item by pressing a link in the list, then go back to the previous page wanting to look at the next one, only to find your place is lost.