www.flickr.com
|
So many in my team went on this personality profile training (Insights Discovery). As part of it, we got a 22-page personality profile. I thought I'd upload it and let you decide if it's accurate. So here it is; there's at least one thing in there that's absolutely wrong. But in general I thought is was insightful.
Not sure that I learned anything that I didn't know though.
If you haven't heard from me lately, it's because I've been playing too much Civilizations Revolution on my iphone. The game is crashy, but that just makes me start over...
Hopefully the game will wear out on me like field runners did ;)
I was reading this article Programs that Test Themselves in Computer magazine (unfortunately, link requires payment to access... Bertrand Meyer has a different but equally fascinating fascinating article which is now free to access: Seven Principles of Software Testing), and noticed that once again, the testing strategy described doesn't work out of the box for concurrent software.
The article describes an end-to-end scenario for automated+manual testing called AutoTest. It has an automated test generation strategy, a mechanism to run these automatically generated tests, and a way to automatically check the tests (pass/fail). They use the trick of runtime assertion checking of postconditions as an oracle (a technique I also used in my thesis). They paint a very attractive picture of testing that fully integrated automated and manually written unit tests that can check their own correctness. Problem is, it doesn't *quite* work for concurrent software.
Issues include:
The first issue is probably easy to fix, one can imagine a variant of their test generation strategy but on multiple threads. The second can be fixed by running a test multiple times, each with a different thread schedule such as the CHESS tool does. But the last one is quite problematic.
AutoTest relies on the fact that you can evaluate design-by-contract postconditions at runtime to see whether they hold or not. But in concurrent systems, DBC runtime checking is a lot more tricky. Imagine that you have a simple concurrent stack type that had a Push() method: a typical postcondition for a stack would assert that after the Push(), the size of the stack grew by one element. But what if there was a Pop() running concurrently with the Push()--it is now possible that by the time the Push method returns, the stack did not grow at all!
I kind of recall a JML related paper where they try to solve this by putting in safe points--locations inside the code where pre- and postconditions can be checked safely. It wasn't clear to me that this is doable in general. Plus, we now have to muddy the implementation with contract stuff--which isn't very clean at all.
The idea of self-checking software components is certainly very appealing to me, but how do we make it work for concurrency components? Can we make dbc-style runtime checking work? Or do we need something else?
My article with Chris Dern on synchronization coverage is up at MSDN Magazine.
Who could have guessed that someday I'd co-author an article on MSDN Magazine. lol
One good thing about moving to a new neighborhood is the opportunity to explore it. Today, I discovered Taste the Moment restaurant, about a block away from my apartment. It's a real cute place, it feels like you're eating in a dollhouse.
I had brunch there, ordered the eggs benedict, and it was yummy.
You never really realize how much stuff you got until you move.
Most of the boxes are marked "kitchen". The new apartment has a smaller kitchen with fewer storage. Wonder how I'll fare.
Oh well, I guess I'll find out.
Inspired by the movie, I attempted to make an omelette just like Julia Child made it. I ended up with this sorry looking thing. I think the pan wasn't hot enough, and I kept the eggs in too long. Also, I put too much butter that wasn't that fresh anymore. Oh well, maybe I'll attempt it again after I move :)
Here's Julia making an omelette, the right way.
