From Apple: 1. 2 SAFETY: USER GENERATED CONTENT

My brother and I have a nifty little app in the iOS app store. It lets you save and share animated gifs. It has a few nice features, like the ability to grab gifs out of tweets, from safari, from most popular reddit client apps, tumblr, or from other apps like imgur. I encourage you to check it out here gif-wallet.com.

That's not really the point of this blog though. For the last 11 releases we've offered a "feed", where we deliver you some of the best gifs we've seen in the last week or so. Some are classics, others are funny, some are cute, some are impressive feats, some are "fail" gifs, but we never include pornography, or even curse words in text. We expect some of our users are children, or sensitive types, even though our app is marked as 17+, as you are free to get gifs from wherever you want.

Now, this week, we got this message from Apple:

Obviously, some moron at Apple doesn't understand our feed, so 4 minutes later, I clarified:

Hoping this would solve it, but having dealt with Apple on these types of issues, as well as reading the horror stories from other developers, we were prepared for the worst. Now, this is just a hobby for us, but it's pretty inconvenient when something like this happens. I really feel sorry for the people who are trying to make a living through the app store.

Their response, ignoring their own policy was the following:

So, we'll do that. Regardless of how stupid it is. Regardless of how almost every app in our competitive space lacks this functionality. Regardless that many, such as the imgur app actually display their own user generated content. Whereas our app only displays a highly curated feed of gifs produced by me. If a user doesn't like the content I'm giving them, they should probably just delete the app.

Apple is slipping.

How many seconds are in 21.25 years?

Apparently Siri and Google disagree over this.

Well, it's pretty clear how Google came up with the answer. They just took 21.25 years multiplied by 365 days multiplied by 60 minutes multiplied by 60 seconds. Clearly, Google doesn't care about leap years, or maybe they just deny their existence like some people do with the moon landing. Anyway, that's a different topic for another day. The real question is what in the actual heck is Siri thinking? Maybe she's really tired, I mean her battery is clearly at zero percent. I mean, if we started today and go forward 21.25 years we'd hit exactly 6 leap years: 2016, 2020, 2024, 2028, 2032, 2036. Well, let's just add 6 days to our answer:

670140000 + 6 * 24 * 60 * 60 = 670658400

Huh, does Siri have you stumped how she does her magical Apple math yet? Or maybe she's drunk?

OK, I'll give you the answer, but first I gotta give you some facts about leap years. You probably know that every four years we have a leap year, including an extra day, but what you may not have known is that every 100 years we break that rule, except every 400 years we break the rule that breaks the rule. 

To put it plainly, 1896 was a leap year, but 1900 was not. 1996 was a leap year, and so was 2000. So, what Siri is doing is taking the average length of a year using the leap year rules and the Gregorian calendar (who's Greg, and why do we use his calendar is a entirely different topic). Following those rules, a year is 365.2425 days long.

21.25 * 365.2425 * 24 * 60 * 60 = 670585230

Now you know the answer to Siri's disagreement with Google. As far as who is right? Well, perhaps the original question isn't specific enough.

2 spaces after a period, or one?

Now, I'm not much of a writer.  If you follow this blog, that much is probably apparent.  Also, I'm pretty old, and us old people usually started typing on typewriters, or something that outputted paper, like a word processor.

Anyway, when I started typing, typewriters just made one size character, whether you were typing "iiiiiiiiiiiiii" or "eeeeeeeeeeeeee" they came out the same width on the paper. Now, in order to make reading easier, and give more weight to sentence termination, we were taught to put two spaces after every period.

Some habits are just hard to break.

XenServer 6.5 fails to install with splashy graphics error

Forget the hard time I had getting a working XenServer 6.5 installer onto a USB drive. Once we finally have the installer happily occupying the entirety of my shiny new 64GiB usb flash drive, even more trouble brews.

Tried the installer on 4 different servers, different varieties of SuperMicro hardware and each one fails with an error like this:

Installation of tmp/splashy-graphics-xenserver-0.3.9-xs1393.x86_64.rpm failed.
ln: creating hard link '/usr/share/splash/background.png' to '/usr/share/splashy/themes/citrix-theme/background.png': File exists
error:
%post(splashy-graphics-xenserver-0.3.9-xs139...

Now, I don't give two turds about what splashy graphics are, and it's unlikely I'll ever need them on this headless server, but it kinda abruptly interrupts the installer process, which I do need...

After much googling, I realize that there are literally dozens of us. We all have this splashy graphics problem, and no one concisely describes the fix. So, here it is:

While the server is installing, but before it gets to 90% or so, simply hit Alt-F2 to drop to a shell.

Then delete the background.png file at /tmp/root/usr/share/splash

# rm /tmp/root/usr/share/splash/background.png

Then hit Alt-F1 to go back to the installation terminal.

Problem solved. Now, I'm off to babysit the rest of these server installs.

The problems with Apple's iOS App Store

This is going to be a rant. If you don't like rants, click away now.

I'm writing this more for me than for you. I just need to vent this frustration, and let's face it, Apple is kind of big now, so my little concerns are easily overlooked.

Now, the core problem here is that we goofed, we messed up, we didn't properly test before releasing a patch. This can happen to anyone, but certainly, it's easier to happen when you only have 2 people and you do everything yourselves.

Long story short, version 1.0.5 of our app was working fine, humming along, selling at least a couple in-app purchases every day. Nothing to quit my day job over, but at least we'll be able to pay for the developer license, and maybe even the domain names. Along comes update 1.0.6 adding a few fixes, and more languages to the list of localized languages. Unfortunately, a bug was introduced that basically breaks the app completely. It will crash right after launch after the user encounters the bug.

Of course we noticed the problem only a few hours after the update went live. We had a patch created and pushed to the store within an hour of that, even with parental duties and it being the weekend and all...

Fast forward 8 days, and we're still waiting on Apple to approve the patch. Now, this wouldn't be so bad, if we could simply pull version 1.0.6 and revert to 1.0.5.  However, that's not even possible. It wouldn't be so bad if there were some way to fast track our patch, to tell Apple, "Hey look, we need this patched urgently, our app is functionally broken". However, that's not possible either.

So, here we are pissing off real customers, and probably losing numerous sales, and generally generating bad will, because our hands are completely tied.

It really is frustrating.

Rant is over.

If you have something constructive like, hey, here's a way to fast track your app update, or hey, you know you could do "this" and disable your bad update, I'd really enjoy that.

Odds of 500,000 heads and 500,000 tails

If you flip a perfect coin* 1 million times, what are the odds that you would get exactly 500,000 heads and 500,000 tails?

A) 0%
B) 0.08%
C) 1%
D) 10%
E) 50%
F) 100%

Go ahead and try and explain your answer.

*perfect coin: A coin that has exactly a 50% chance of landing on either heads or tails.

Think of the simplest case. 2 coin flips. There are 4 possible outcomes, both heads, both tails, or 1 of each.

Wait, I just said 4 possible outcomes, then described 3?  Why?

Well, think of it like this:

HH, TT, HT, TH

Getting heads then tails is a different outcome than tails then heads, but both result in 1 of each. So, judging from that, you say, well 2 of 4, that's 50%, I knew the answer was E! Hah, not so fast...

Now, let's look at the next simplest case.  4 coin flips. Here are the possible outcomes:

HHHH, HHHT, HHTH, [HHTT], HTHH, [HTHT], [HTTH], HTTT, THHH, [THHT], [THTH], THTT, [TTHH], TTHT, TTTH, TTTT

So, there's 16 possibilities, and only 6 have equal numbers of heads and tails, I surrounded them in square brackets.  Uh Oh, that's 37.5% and it's probably going to get worse as we increase the flips towards 1 million. So maybe you're leaning towards answer C or D now, right?

From here I could go into the topics of binomial coefficients, pascal's triangle and other worthwhile, interesting topics, but I'll skip the heavy math and just show you dude's triangle.

     1
    1 1
  1 (2) 1   summed = (4)
 1 3   3 1
1 4 (6) 4 1 summed = (16)

Hopefully you recognize Pascal's triangle, but if you don't there's always Wikipedia.

We only care about every other case, as you need an even number of flips to obtain a perfectly even split of heads and tails.  You might recognize the numbers I put in parentheses. Those are the results we saw for 2 and 4 flips. So, now we just have to draw the next 999,996 lines of the triangle.

Don't worry, I did this on a separate sheet of paper, and the result was roughly 0.08%.

If you don't believe me, you can ask WolframAlpha

nosetests: error: no such option: --with-xunit

Sometimes, nosetest is a liar.

For some reason, we were seeing this error in the Jenkins console output:

    nosetests: error: no such option: --with-xunit

Of course, the first thing to do is to google the problem.  Why doesn't nose like this parameter any more?  Maybe we updated versions, and now it's no longer accepted.

Well, unfortunately, that's not the case.

    nosetests --help

Tells me:

    --with-xunit Enable plugin Xunit: This plugin provides test results 
in the standard XUnit XML format. [NOSE_WITH_XUNIT]

Doh, that's not it.  However, scrolling up a few lines in the jenkins console output, I see that one of our 

    python setup.py develop 

commands was failing miserably, but the error wasn't being caught.  

I saw this in the console output:

    Couldn't find index page for 'our_thing' (maybe misspelled?)
    No local packages or download links found for our-thing
    error: Could not find suitable distribution for Requirement.parse('our-thing')

Fixed that problem, and nosetest were back in business.  Of course, we had lots of broken tests, because the nosetests error wasn't being caught as a failure by Jenkins.  Stupidity on top of idiocy.

<sigh>