Return to Answer

Official bug reports

In this post, I'll agreegate known bugs in the v1.0 of the app. For education and entertainment, I'll also explain those that I can - what caused them, and why. If you need to report a bug, please either add a comment here or send me an e-mail (adamw at archgrove dot co.uk).

Bugs in v1.1

None known, so far!

Old bugs from version 1.0 (fixed in v1.1)

Tapping a row in the reputation changes section of a user generally shows the wrong post

This is because I violated my cardinal rule - don't change functionality in the hour or two before release. At the last minute, I finally realised I hated the way I was ordering the reputation update lists. I changed the sort ordering for display, but failed to account for it in the UI selection code.

It slipped through my tests because the user I checked against had a very small number of recent rep changes, and didn't trigger the bug. I was also probably not comparing what I tapped too closely against what appeared due to the last minute nature of the change (hence my cardinal rule).

API Advice - don't just test against one or two users, test against several with distinctive user patterns (i.e. include rare/retired users, and Jon Skeet level users - not just your own!).

Posts changed between 1 hour and 3 days ago will claim to be changed "an a hour ago"

This is a flaw in the date calculation code, which I've uploaded to http://sixtoeightapp.com/code/DateExtensions.m for the amusement of all. The inequality for the "an hour ago" conditional has been accidentally set as 60 * 60 * 90, and should be 60 * 90. A simple copy/paste error (still a bit embarrassing, though). Interestingly, this is a fantastic example of the need for better static code analysis. The later inequality (23 * 60 * 60) can never fire, and this should be flagged by the compiler.

API Advice - The reason this snuck through both my tests, and virtually all beta testers and public release testers is that most people use Stack Overflow, which updates faster than than a sysadmin installing Windows XP from an original disc. As such, it's quite plausible that everything you're looking at was updated an hour ago, so noone noticed that the 2 hours -> 3 days date range was simply missing. I advise testing against some quieter sites (meta.superuser.com has a sedate but active update rate, as does here).

The app sometimes crashes when viewing a post (unconfirmed)

I have one report of this bug, but not with repeatable steps. I can't replicate it earlier, but I'm sure it happened to the user. I'm still investigating this one.

The visit support alert doesn't take you to support

Indeed not. No excuse for this one except bone headedness, I'm afraid.

Official bug reports

In this post, I'll agreegate known bugs in the v1.0 of the app. For education and entertainment, I'll also explain those that I can - what caused them, and why. If you need to report a bug, please either add a comment here or send me an e-mail (adamw at archgrove dot co.uk).

Bugs in v1.1

Selecting "Their favorites" in a user view produces a "Site response error"

Not sure how this one occurred, since the code is the same since version 1.0. Either the API response has subtlety changed (unlikely), or when fixing another bug in CoreStack, I accidentally set the wrong response parsing system code for user favourites. It's fixed in my private version already, and will be in the next release.

Old bugs from version 1.0 (fixed in v1.1)

Tapping a row in the reputation changes section of a user generally shows the wrong post

This is because I violated my cardinal rule - don't change functionality in the hour or two before release. At the last minute, I finally realised I hated the way I was ordering the reputation update lists. I changed the sort ordering for display, but failed to account for it in the UI selection code.

It slipped through my tests because the user I checked against had a very small number of recent rep changes, and didn't trigger the bug. I was also probably not comparing what I tapped too closely against what appeared due to the last minute nature of the change (hence my cardinal rule).

API Advice - don't just test against one or two users, test against several with distinctive user patterns (i.e. include rare/retired users, and Jon Skeet level users - not just your own!).

Posts changed between 1 hour and 3 days ago will claim to be changed "an a hour ago"

This is a flaw in the date calculation code, which I've uploaded to http://sixtoeightapp.com/code/DateExtensions.m for the amusement of all. The inequality for the "an hour ago" conditional has been accidentally set as 60 * 60 * 90, and should be 60 * 90. A simple copy/paste error (still a bit embarrassing, though). Interestingly, this is a fantastic example of the need for better static code analysis. The later inequality (23 * 60 * 60) can never fire, and this should be flagged by the compiler.

API Advice - The reason this snuck through both my tests, and virtually all beta testers and public release testers is that most people use Stack Overflow, which updates faster than than a sysadmin installing Windows XP from an original disc. As such, it's quite plausible that everything you're looking at was updated an hour ago, so noone noticed that the 2 hours -> 3 days date range was simply missing. I advise testing against some quieter sites (meta.superuser.com has a sedate but active update rate, as does here).

The app sometimes crashes when viewing a post (unconfirmed)

I have one report of this bug, but not with repeatable steps. I can't replicate it earlier, but I'm sure it happened to the user. I'm still investigating this one.

The visit support alert doesn't take you to support

Indeed not. No excuse for this one except bone headedness, I'm afraid.

Official bug reports

In this post, I'll agreegate known bugs in the v1.0 of the app. For education and entertainment, I'll also explain those that I can - what caused them, and why. If you need to report a bug, please either add a comment here or send me an e-mail (adamw at archgrove dot co.uk).

Tapping a row in the reputation changes section of a user generally shows the wrong post

This is because I violated my cardinal rule - don't change functionality in the hour or two before release. At the last minute, I finally realised I hated the way I was ordering the reputation update lists. I changed the sort ordering for display, but failed to account for it in the UI selection code.

It slipped through my tests because the user I checked against had a very small number of recent rep changes, and didn't trigger the bug. I was also probably not comparing what I tapped too closely against what appeared due to the last minute nature of the change (hence my cardinal rule).

API Advice - don't just test against one or two users, test against several with distinctive user patterns (i.e. include rare/retired users, and Jon Skeet level users - not just your own!).

Posts changed between 1 hour and 3 days ago will claim to be changed "an a hour ago"

This is a flaw in the date calculation code, which I've uploaded to http://sixtoeightapp.com/code/DateExtensions.m for the amusement of all. The inequality for the "an hour ago" conditional has been accidentally set as 60 * 60 * 90, and should be 60 * 90. A simple copy/paste error (still a bit embarrassing, though). Interestingly, this is a fantastic example of the need for better static code analysis. The later inequality (23 * 60 * 60) can never fire, and this should be flagged by the compiler.

API Advice - The reason this snuck through both my tests, and virtually all beta testers and public release testers is that most people use Stack Overflow, which updates faster than than a sysadmin installing Windows XP from an original disc. As such, it's quite plausible that everything you're looking at was updated an hour ago, so noone noticed that the 2 hours -> 3 days date range was simply missing. I advise testing against some quieter sites (meta.superuser.com has a sedate but active update rate, as does here).

The app sometimes crashes when viewing a post (unconfirmed)

I have one report of this bug, but not with repeatable steps. I can't replicate it earlier, but I'm sure it happened to the user. I'm still investigating this one.

The visit support alert doesn't take you to support

Indeed not. No excuse for this one except bone headedness, I'm afraid.

Official bug reports

In this post, I'll agreegate known bugs in the v1.0 of the app. For education and entertainment, I'll also explain those that I can - what caused them, and why. If you need to report a bug, please either add a comment here or send me an e-mail (adamw at archgrove dot co.uk).

Bugs in v1.1

None known, so far!

Old bugs from version 1.0 (fixed in v1.1)

Tapping a row in the reputation changes section of a user generally shows the wrong post

This is because I violated my cardinal rule - don't change functionality in the hour or two before release. At the last minute, I finally realised I hated the way I was ordering the reputation update lists. I changed the sort ordering for display, but failed to account for it in the UI selection code.

It slipped through my tests because the user I checked against had a very small number of recent rep changes, and didn't trigger the bug. I was also probably not comparing what I tapped too closely against what appeared due to the last minute nature of the change (hence my cardinal rule).

API Advice - don't just test against one or two users, test against several with distinctive user patterns (i.e. include rare/retired users, and Jon Skeet level users - not just your own!).

Posts changed between 1 hour and 3 days ago will claim to be changed "an a hour ago"

This is a flaw in the date calculation code, which I've uploaded to http://sixtoeightapp.com/code/DateExtensions.m for the amusement of all. The inequality for the "an hour ago" conditional has been accidentally set as 60 * 60 * 90, and should be 60 * 90. A simple copy/paste error (still a bit embarrassing, though). Interestingly, this is a fantastic example of the need for better static code analysis. The later inequality (23 * 60 * 60) can never fire, and this should be flagged by the compiler.

API Advice - The reason this snuck through both my tests, and virtually all beta testers and public release testers is that most people use Stack Overflow, which updates faster than than a sysadmin installing Windows XP from an original disc. As such, it's quite plausible that everything you're looking at was updated an hour ago, so noone noticed that the 2 hours -> 3 days date range was simply missing. I advise testing against some quieter sites (meta.superuser.com has a sedate but active update rate, as does here).

The app sometimes crashes when viewing a post (unconfirmed)

I have one report of this bug, but not with repeatable steps. I can't replicate it earlier, but I'm sure it happened to the user. I'm still investigating this one.

The visit support alert doesn't take you to support

Indeed not. No excuse for this one except bone headedness, I'm afraid.

Official bug reports

In this post, I'll agreegate known bugs in the v1.0 of the app. For education and entertainment, I'll also explain those that I can - what caused them, and why. If you need to report a bug, please either add a comment here or send me an e-mail (adamw at archgrove dot co.uk).

Tapping a row in the reputation changes section of a user generally shows the wrong post

This is because I violated my cardinal rule - don't change functionality in the hour or two before release. At the last minute, I finally realised I hated the way I was ordering the reputation update lists. I changed the sort ordering for display, but failed to account for it in the UI selection code.

It slipped through my tests because the user I checked against had a very small number of recent rep changes, and didn't trigger the bug. I was also probably not comparing what I tapped too closely against what appeared due to the last minute nature of the change (hence my cardinal rule).

API Advice - don't just test against one or two users, test against several with distinctive user patterns (i.e. include rare/retired users, and Jon Skeet level users - not just your own!).

Posts changed between 1 hour and 3 days ago will claim to be changed "an a hour ago"

This is a flaw in the date calculation code, which I've uploaded to http://sixtoeightapp.com/code/DateExtensions.m for the amusement of all. The inequality for the "an hour ago" conditional has been accidentally set as 60 * 60 * 90, and should be 60 * 90. A simple copy/paste error (still a bit embarrassing, though). Interestingly, this is a fantastic example of the need for better static code analysis. The later inequality (23 * 60 * 60) can never fire, and this should be flagged by the compiler.

API Advice - The reason this snuck through both my tests, and virtually all beta testers and public release testers is that most people use Stack Overflow, which updates faster than than a sysadmin installing Windows XP from an original disc. As such, it's quite plausible that everything you're looking at was updated an hour ago, so noone noticed that the 2 hours -> 3 days date range was simply missing. I advise testing against some quieter sites (meta.superuser.com has a sedate but active update rate, as does here).

The app sometimes crashes when viewing a post (unconfirmed)

I have one report of this bug, but not with repeatable steps. I can't replicate it earlier, but I'm sure it happened to the user. I'm still investigating this one.

Official bug reports

In this post, I'll agreegate known bugs in the v1.0 of the app. For education and entertainment, I'll also explain those that I can - what caused them, and why. If you need to report a bug, please either add a comment here or send me an e-mail (adamw at archgrove dot co.uk).

Tapping a row in the reputation changes section of a user generally shows the wrong post

This is because I violated my cardinal rule - don't change functionality in the hour or two before release. At the last minute, I finally realised I hated the way I was ordering the reputation update lists. I changed the sort ordering for display, but failed to account for it in the UI selection code.

It slipped through my tests because the user I checked against had a very small number of recent rep changes, and didn't trigger the bug. I was also probably not comparing what I tapped too closely against what appeared due to the last minute nature of the change (hence my cardinal rule).

API Advice - don't just test against one or two users, test against several with distinctive user patterns (i.e. include rare/retired users, and Jon Skeet level users - not just your own!).

Posts changed between 1 hour and 3 days ago will claim to be changed "an a hour ago"

This is a flaw in the date calculation code, which I've uploaded to http://sixtoeightapp.com/code/DateExtensions.m for the amusement of all. The inequality for the "an hour ago" conditional has been accidentally set as 60 * 60 * 90, and should be 60 * 90. A simple copy/paste error (still a bit embarrassing, though). Interestingly, this is a fantastic example of the need for better static code analysis. The later inequality (23 * 60 * 60) can never fire, and this should be flagged by the compiler.

API Advice - The reason this snuck through both my tests, and virtually all beta testers and public release testers is that most people use Stack Overflow, which updates faster than than a sysadmin installing Windows XP from an original disc. As such, it's quite plausible that everything you're looking at was updated an hour ago, so noone noticed that the 2 hours -> 3 days date range was simply missing. I advise testing against some quieter sites (meta.superuser.com has a sedate but active update rate, as does here).

The app sometimes crashes when viewing a post (unconfirmed)

I have one report of this bug, but not with repeatable steps. I can't replicate it earlier, but I'm sure it happened to the user. I'm still investigating this one.

The visit support alert doesn't take you to support

Indeed not. No excuse for this one except bone headedness, I'm afraid.