I don't know if you have experienced this or not, but lately, I have been hammered with so many updates to Apple's iTunes product. Funny how all of these updates coincided with the release of the iPhone. My thought is that they are using these releases of iTunes in order to patch the iPhone. I don't have an iPhone, nor do I plan on getting one. I use iTunes and Quicktime for it's original intent, playing music and watching video.
Is Apple trying to accomplish too much with iTunes? Is it time for them to develop a more modular product that will offer consumers exactly what they need and ignore the rest? If I was at Apple, I would definitely suggest a move like this in their product development. The alternative is to have disgruntle consumers who through the countless number of patches will either lose faith in the product's stability, or simply become annoyed to the point of considering alternatives. Speaking of alternatives, does anyone have any?
Tuesday, August 21, 2007
Thursday, August 9, 2007
SpringFramework Nugget...
Recently we were dealing with an issue in a Spring based application that was causing us some real problems. We had an integration test that we were using to perform some black box testing. Unfortunately, we were getting test failures because the unexpected state of the springletons (not true singletons, but through the use of spring, they act as singletons). When running a subset of our tests individually, they had no problem. However, when ran in a suite, those same tests that succeeded on their own, now failed.
After some digging, we found that a test that was running earlier was putting the springletons, in an unexpected state, affecting the remaining tests. In order to resolve this issue, we used the setDirty() (See section 8.3.1) on our integration tests to make sure that Spring would reload the objects anew.
I hope this little nugget of information helps someone else out there...
After some digging, we found that a test that was running earlier was putting the springletons, in an unexpected state, affecting the remaining tests. In order to resolve this issue, we used the setDirty() (See section 8.3.1) on our integration tests to make sure that Spring would reload the objects anew.
I hope this little nugget of information helps someone else out there...
Subscribe to:
Posts (Atom)