UTC everywhere. jonstjohn's dream is realised, in 2052, after decades of work. In a world unifying moment, religion, country divergence and politics aside, the entire planet falls into the gentle embrace of UTC.
We'd still have to have time zones (except maybe it be more sensible to call them something else), and we'd still have to deal with the amount of daylight exhibiting significant seasonal variations at places that aren't close to the equator.
The fact that we live on an approximately spherical world whose rotation is not tidal locked to the star it orbits, that world rotates on an axis that is not perpendicular to its orbital plane around said star, we have a biology that uses local sunrise to synchronize its internal clocks to the planet's rotation, and we have spread to occupy regions of the world that are not near its equator imposes a lower limit on the complexity of our timekeeping.
I landed in Australia this morning and as soon as my phone updated to Dec 2 on the new network my phone started locking up immediately. It would go to the loading screen (spinner in middle of screen) every 8-12 seconds then reset to lock screen after 4-5 more, making it nearly impossible to even access settings for more than a few seconds. I was able to disable local notifications for the apps that I know use them after 3 or 4 tries (required some quick navigation to get to the right screen before it locked up). I captured the logs on a number of occasions but and saw a few anomalies in the logs including this one:
It’s a calendar bug. Local notifications are/can be scheduled 30 days in advance, so on Dec 2nd they can be scheduled on Jan 1st. I saw crash logs on Twitter mentioning “month 13”, so it looks like there’s an off by one bug in that calendar handling code
That makes it all the more unusual, because I have not heard of Apple devices having problems on Dec 2 before now; unless they're rewriting everything frequently, which may also explain a few of the other severe bugs they've produced recently... yet another argument for not replacing things entirely just because they're "old" --- software needs time to mature and stabilise, and have its bugs fixed. Something as simple as a date addition should've been perfected by now.
Anonyome Labs | iOS Developer, Web Developer | Salt Lake City, UT | Onsite | Full-time
Anonyome Labs is a well-funded startup building a full-featured safety and privacy app called Sudo.
Sudo is a powerful new way to protect your safety, privacy and personal data when you’re socializing and connecting online and off. Sudo automatically generates private personas — complete with email addresses and real working phone numbers. And, they’re all securely and privately linked to your iPhone or iPad.
Thanks! I'll have to check that out. I really love the CircleCI service - incredible time saver in getting continuous integration setup and so many features out of the box. Would definitely recommend it to anybody looking for a hosted CI solution (good price, too!).
Agreed about the conventional wisdom. Unfortunately, I think many companies aren't 'doing it right' and end up with somewhat bloated systems. From what I'm hearing, most companies roll their own solution to that problem and don't use any specific tools to address it. I'm seen some rudimentary statistics in Sauce Labs, as well as built into Jenkins.
Great tips - thanks! In addition to some slow-running tests, we do have a lot of test duplication. It's probably time to step back and evaluate what tests are overlapping functionality.
Do you use any tools to facilitate your workflow on fixing tests? Typically, we run a regression build on a branch and may find a half dozen failures. With 4-5 developers on a distributed team, we've built a utility for 'checking out' and marking a test as fixed (to be verified on the next build) but haven't seen any similar functionality in the CI systems we use.
Nothing slows down a test suite like test duplication! I would definitely suggest a refactor, it will help. But remember you don't eat an elephant all at once, take it one bite at a time. A small amount but consistent level of test refactoring will go a long well.
It sounds like you have a good workflow to me but obviously you feel you have a problem or you wouldn't be posting here. I've working in environments where the failing tests are assigned out on an individual basis, where there was a bouncer who took on all broken tests, and where each individual engineer would run the tests often enough that they would just fix what they broke. The latter method is my favorite. But it is not always feasible.
I guess the answer really depends on your environment. I would be very happy to give my advise (for what it's worth). If you would like you may email me. My address is my Hacker News username at googles very large and famous free email service.
I actually have a similar problem with UPS. Last year we had a dyson vacuum delivered to our house that was left on the front porch, about 10 feet from the sidewalk. The box was the manufacturer's box with pictures of the vacuum and the brand written in big letters. We weren't home but when we did get there, there was no package.
It was ordered from Costco and their service was fantastic. We had a replacement within a few days. The problem was UPS. After that incident, every single package had to not only be signed for, but actually have a person present to receive the package. I'm not sure if this was retribution on behalf of the delivery person, who probably got into some kind of trouble, but it is what it is. It is very difficult for us to get packages at home now.
I love prime, but it would be fantastic if I had the option to choose a shipper, even if I had to pay a couple dollars extra. USPS is actually much better about leaving packages, which are by far usually under $20 and small.
My problem is that I tend to wear out card before I get a replacement. For example, my debit card currently requires 3-4 swipes to get it to work. I'd probably keep a backup card in my wallet if I decided to get Coin, just in case, but really like this idea.
For most self-swipe checkouts, it seems like this card would work well (coffee shop, grocery store, etc). But, it isn't too uncommon to have a merchant request to see the card, and some larger retailers (e.g., Lowes) have to input numbers off the front of the card, as well.
