If it was iOS, I'd say the provisioning profile expired :-p
Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]
11–20 of 42 posts
Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]
#12Reminds me of one of the nice features of Git: git bisect. Find the breaking commit in the smallest number of steps. Some random blog post about it: http://webchick.net/node/99
Git bisect is awesome. Before I discovered it, I was manually bisecting the codebase, and stubbing out the missing half.
Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]
#13Reminds me of one of the nice features of Git: git bisect. Find the breaking commit in the smallest number of steps. Some random blog post about it: http://webchick.net/node/99
how am I not surprised that this solved a regression that occurred at some point in the past on a Drupal project
I worked on a Drupal project... Once.
Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]
#14Reminds me of one of the nice features of Git: git bisect. Find the breaking commit in the smallest number of steps. Some random blog post about it: http://webchick.net/node/99
This is awesome. Didn't know about it, thanks!
My approach has been to step exponentially. I go back 1 commit, 2 commits, 4 commits... etc. I'll be using bisect from now on though.
Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]
#15Reminds me of one of the nice features of Git: git bisect. Find the breaking commit in the smallest number of steps. Some random blog post about it: http://webchick.net/node/99
The algorithm described in the article, if I'm reading it correctly, is more powerful than git bisect, because it can identify the exact change within a commit that causes the bug. You could for example decide to make each file modification in a commit a different 'Change', and so the algorithm would identify not only which commit breaks something, but which file changes are relevant.
Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]
#16Reminds me of one of the nice features of Git: git bisect. Find the breaking commit in the smallest number of steps. Some random blog post about it: http://webchick.net/node/99
Git bisect is awesome. Before I discovered it, I was manually bisecting the codebase, and stubbing out the missing half.
Not to take away from git bisect (or hg bisect, which is no more broken than the rest of mercurial) -- I don't think it is an alternative to the thing you used to do.
git bisect is "temporal bisection", i.e. you delete half of a time interval. The manual bisect is kinda-sorta "spatial" in the sense that you delete half a region of code. the two things work by similar principles, and their problem domains overlap -- but they are not the same.
Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]
#17We once had a bug that would cause a failure in our test suite, but very rarely. It was so rare that it would just "go away" and not show up for weeks. So we thought it was odd (maybe bad test data, etc) but moved on. When we decided to look into it when we had some downtime, we found out that it was a date bug that only reared its head on the 31st day of the month, hence only happening every two months. I'm not sure…
Thanks for the anecdote, because it gives me a new idea.
We should be monitoring the rate of test failures -- per test -- in a timeseries and looking for periodicities. Just graphing them and seeing regular spikes will help, but having real numerics looking for approximate periodicities will catch this sort of thing (after a few months!).
Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]
#18We once had a bug that would cause a failure in our test suite, but very rarely. It was so rare that it would just "go away" and not show up for weeks. So we thought it was odd (maybe bad test data, etc) but moved on. When we decided to look into it when we had some downtime, we found out that it was a date bug that only reared its head on the 31st day of the month, hence only happening every two months. I'm not sure…
Was this the kind of test that only ran once a day?
It wasn't, but it was the sort of thing where we never modified that test or even a related area, so it just wouldn't make sense that the test would fail.
But the bigger issue was that since it would "fix itself" we never prioritized it and just left it alone.
But looking back, the system (automated tests) was functioning as designed. :) We just changed our "DateTime.now" to concrete dates.
Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]
#19Reminds me of one of the nice features of Git: git bisect. Find the breaking commit in the smallest number of steps. Some random blog post about it: http://webchick.net/node/99
The algorithm described in the article, if I'm reading it correctly, is more powerful than git bisect, because it can identify the exact change within a commit that causes the bug. You could for example decide to make each file modification in a commit a different 'Change', and so the algorithm would identify not only which commit breaks something, but which file changes are relevant.
This would be difficult to determine - as running tests without some changes in non-deterministic way could affect testing or the program's ability to run properly.
Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]
#20Earlier quoted context omitted.
The algorithm described in the article, if I'm reading it correctly, is more powerful than git bisect, because it can identify the exact change within a commit that causes the bug. You could for example decide to make each file modification in a commit a different 'Change', and so the algorithm would identify not only which commit breaks something, but which file changes are relevant.
This would be difficult to determine - as running tests without some changes in non-deterministic way could affect testing or the program's ability to run properly.
The article covers that.