Dr. Hanna's Practice #3: Test for both functional and quality requirements. I would have thought state charts and truth tables were familiar to everyone, but I think the typical Indianapolis tester has a lot less experience than, say, one in San Jose, so there were a lot of people who they weren't familiar to. But Dr. Hanna had some good advice on turning a requirement, written in English, into a model by splitting it up into actions and results. He took a typical requirement statement, teased four predicates and four consequences out of it, and showed the truth table that it resulted in, with the 16 possible states of the predicates and the expected consequences of each. I was a bit itchy here, because I always feel that you can go through and test your application like this, but then go through and test a separate bit of your application which contradicts it. To help my understanding, I went on the second day to a talk on integrations testing, which I thought would more or less cover my confusion. You've got one requirement, you've got another requirement, testing them both is integration testing, right?
Well, no. Integration testing is the actual bit where you take two components of the system and make sure they talk to each other properly. Testing the input/output of one component is mostly a unit test, since they usually are easily testable and verifiable based on the automated testing that should have been written by the developer. But you need integration testing to avoid the "operation was successful but the patient died" phenomenon, where the interface of component A is not clearly understood by the developer of component B, so he writes and tests a very nice component that doesn't do at all what component A expects.
But with that clarification, I guess I see the real issue: the thing that is worrying me are two contradictory requirements. Given a clear requirements document, it is no longer the tester's problem, and it is no longer the developer's problem. It's a business problem, and someone with knowledge of the problem domain is required to clarify the contradictory requirements, which allows us to update the requirements doc, and guess what - now the testers can redesign their test plan and the developers can redo their code.
Here's a list of books recommended at the conference.
Ramblings of a software developer with a degree in bioinformatics. Agile development mixed with DNA sequencing - what could go wrong?
Monday, October 16, 2006
Friday, October 13, 2006
IQAA: Changing Requirements
The whole conference I was at this week for me revolved around the requirements management process. Partly because many companies I've worked at had trouble with this part of the process; that is, they followed the process of creating a requirements document, then they shut it away in a drawer and never look at it again while developers and testers go along their merry way and code up a mishmash of the requirements, what they think the requirements might mean, and any customer requests that aren't too difficult and/or are from important customers.
But I think a main thrust of Dr. Hanna's talk was that the requirements document is very important. I'm used to this very static, dull requirements document, and so I kept wanting to raise my hand and say, "How can you do that when the requirements phase is already complete?" But I have to conclude that he doesn't think it is static at all, and that it has to be dynamic and updated continually. (It was interesting that he said several times that testing is a process, not a step in the process, but he never said requirements were too.)
The typical software company tends to communicate rather informally. Write up a vague requirements document, then have the developers implement it any ol' way that seems right. If they're good, or at least social, developers, they'll talk to customers or managers or somebody that can clarify the requirement. A lot of developers will just guess, though. (Combined with receiving fast feedback from a Customer, this is just fine, of course.) But this is why the developer/customer communications need to be with testers (in a typical software environment ) or part of the process (in a regulated environment or one with traceability requirements. When it is part of the process, the correct process, I think, is to modify the requirements doc based on the customer communication. This gives testing a chance to update their tests. Dr. Hanna came back many times to the diagram:
Requirement -> Test Scenario -> Test Case -> Script
So if the Requirements are up to date, the tests can be up to date as well.
I'm not sure that every attendee thought this was the emphasis, but I also went to a couple of talks on this topic.
But I think a main thrust of Dr. Hanna's talk was that the requirements document is very important. I'm used to this very static, dull requirements document, and so I kept wanting to raise my hand and say, "How can you do that when the requirements phase is already complete?" But I have to conclude that he doesn't think it is static at all, and that it has to be dynamic and updated continually. (It was interesting that he said several times that testing is a process, not a step in the process, but he never said requirements were too.)
The typical software company tends to communicate rather informally. Write up a vague requirements document, then have the developers implement it any ol' way that seems right. If they're good, or at least social, developers, they'll talk to customers or managers or somebody that can clarify the requirement. A lot of developers will just guess, though. (Combined with receiving fast feedback from a Customer, this is just fine, of course.) But this is why the developer/customer communications need to be with testers (in a typical software environment ) or part of the process (in a regulated environment or one with traceability requirements. When it is part of the process, the correct process, I think, is to modify the requirements doc based on the customer communication. This gives testing a chance to update their tests. Dr. Hanna came back many times to the diagram:
Requirement -> Test Scenario -> Test Case -> Script
So if the Requirements are up to date, the tests can be up to date as well.
I'm not sure that every attendee thought this was the emphasis, but I also went to a couple of talks on this topic.
Thursday, October 12, 2006
IQAA: Quality enrichment conference
I've posted about the IQAA before, and I regret that I haven't been able to make it to their talks regularly. There is a bit of a disconnect between the organizers and the members, I think, because the organizers are creating a fair amount of high-quality content, and I'm not sure that the Indy software testing scene really is vibrant enough to appreciate it. Today I'm attending a free seminar given by Dr. Magdy Hanna of the IIST on Software Testing Discipline and Software Testing Management, and it's very good.
The intent was for Dr. Hanna to give two seminars, one in the morning more or less aimed at testers, and one in the afternoon aimed at test managers, but in practice they all sort of collapsed together. The majority of attendees were there for both sessions; which was good, because they ran together pretty much. Dr. Hanna is a good, knowledgable, and confident speaker, and when you have one of those you're guaranteed to run over. We got to hear a little more than half of the practices before lunch, and a couple more afterwards, so what was billed as the "afternoon session" started around 2:00. But it covered basically the remaining practices anyway, and around 3:15 he looked up, said, "How much time do we have left?" and burned through the rest of his slides as if they were a kaleidoscope :) I'll put together a few posts over the next few days on my impressions of the conference and speakers. I'm not going to summarize all of the practices he named; just some of things that made me think. For example,
Practice 1: Requirements are crucial, with the couple of subheaders: You can't test what you don't know, and Users will always change their minds, and this was the point when he went all Steve Yegge on us, and explained how he was opposed to the agile movement. Of course, as is usual in such cases, we find out that he's not actually opposed to the practices of agile, or at least many of them, but only to calling it agile, or something. (I've never been quite clear on what exactly the opposition is to).
I mention this in passing because it seemed to me that those two headers absolutely contradict each other. How do you know what to test, when the users are calling the developers daily with new requirements? But his overall point, I concluded, was that (a) requirements documents should be kept accurate and up-to-date, and (b) they should be your main avenue of communication between developers and testers. I had assumed, when he said he didn't approve of agility, that he wanted nice static requirements docs before testing ever started. This, of course, never happens in the real world. More later.
The intent was for Dr. Hanna to give two seminars, one in the morning more or less aimed at testers, and one in the afternoon aimed at test managers, but in practice they all sort of collapsed together. The majority of attendees were there for both sessions; which was good, because they ran together pretty much. Dr. Hanna is a good, knowledgable, and confident speaker, and when you have one of those you're guaranteed to run over. We got to hear a little more than half of the practices before lunch, and a couple more afterwards, so what was billed as the "afternoon session" started around 2:00. But it covered basically the remaining practices anyway, and around 3:15 he looked up, said, "How much time do we have left?" and burned through the rest of his slides as if they were a kaleidoscope :) I'll put together a few posts over the next few days on my impressions of the conference and speakers. I'm not going to summarize all of the practices he named; just some of things that made me think. For example,
Practice 1: Requirements are crucial, with the couple of subheaders: You can't test what you don't know, and Users will always change their minds, and this was the point when he went all Steve Yegge on us, and explained how he was opposed to the agile movement. Of course, as is usual in such cases, we find out that he's not actually opposed to the practices of agile, or at least many of them, but only to calling it agile, or something. (I've never been quite clear on what exactly the opposition is to).
I mention this in passing because it seemed to me that those two headers absolutely contradict each other. How do you know what to test, when the users are calling the developers daily with new requirements? But his overall point, I concluded, was that (a) requirements documents should be kept accurate and up-to-date, and (b) they should be your main avenue of communication between developers and testers. I had assumed, when he said he didn't approve of agility, that he wanted nice static requirements docs before testing ever started. This, of course, never happens in the real world. More later.
Thursday, October 05, 2006
WIX, IIS, and CPPUnit Nano
Shoutouts to a couple of pages that have made my life easier in the last few days. We use CPPUnit to run unit tests on some of our VC6 applications, but now it's time to start compiling those applications, and their tests, in Visual Studio 2005 . I messed around with trying to get CPPUnit to compile and link in in VS2005 for a while, but was unsuccessful; and in any case CPPUnit isn't getting any love from anywhere any more. So what's a unit tester to do? Enter Nano CPP Unit, a little unit testing page with all of the source right there on the page. Copy it in to the correct files, change a few other lines, and a bunch of tests were running right off. Very handy.
Second, trying to configure IIS through an installer built with WIX. The docs explain more or less clearly how to set up the custom actions, so I did that using the codes below, ran the installer, and...nothing.
I ran across this Strange Blog entry detailing more or less how to do the same thing, but a comment in the post also mentioned the bit I hadn't seen before: Link in the provided object file sca.wixlib to set up all the custom action scheduling the way you need it. Thanks to that commenter, the Strange Blog author, and the author of Nano CPP Unit for their help!
Second, trying to configure IIS through an installer built with WIX. The docs explain more or less clearly how to set up the custom actions, so I did that using the codes below, ran the installer, and...nothing.
<WebSite Id="MyWebServer"
Description="My Web Server"
Directory="MyLicenseServer">
<WebAddress Id="LicenseManagerWebAddress"
Port="80"/>
<WebVirtualDir Id="LicenseManagerVirtualDirectory"
Directory="MyLicenseServer"
Alias="LicenseServer">
<WebApplication Id="MyLicenseServer"
Name="MyLicenseServer" />
</WebVirtualDir>
</WebSite>
I ran across this Strange Blog entry detailing more or less how to do the same thing, but a comment in the post also mentioned the bit I hadn't seen before: Link in the provided object file sca.wixlib to set up all the custom action scheduling the way you need it. Thanks to that commenter, the Strange Blog author, and the author of Nano CPP Unit for their help!
Friday, August 04, 2006
Evidence open source project
I got a CodePlex project approved, whee. I'm pretty sure I must have grandfathered in since I submitted my request a couple of weeks ago - it's just an idea in my mind, not an actual project, and therefore it probably doesn't come under the latest requirements:
Most project requests that we approve have two or more project admins, two or more committed developers, and a recent history of active check ins, opened and closed work items, and at least one release. We sometimes make exceptions for individual project applicants (with or without code) who have a proven history of success in creating successful online development projects, or startups.
Uh, yeah, that's me all right. But, my project idea has to do with genealogy and collaboration; it's an attempt at raising the standards of online genealogical research. As I wrote on the project wiki:
The typical Internet genealogical researcher today works as follows:
Most project requests that we approve have two or more project admins, two or more committed developers, and a recent history of active check ins, opened and closed work items, and at least one release. We sometimes make exceptions for individual project applicants (with or without code) who have a proven history of success in creating successful online development projects, or startups.
Uh, yeah, that's me all right. But, my project idea has to do with genealogy and collaboration; it's an attempt at raising the standards of online genealogical research. As I wrote on the project wiki:
The typical Internet genealogical researcher today works as follows:
- Search on genealogy sites for published databases that have matches for someone already in their database
- Copy the information to their database
- Publish the database
So there's a lot of room for improvement. I'll write more about my ideas soon - right now I have to go figure out how one checks in code using Team System...
Drop me a line if you're interested in the project!
Wednesday, August 02, 2006
Credit card frauded
Crud! I got a call from MBNA to verify some "suspicious activity" on my credit card, and sure enough someone managed to get to their online banking site, use my account number to log in, change my address to somewhere in Maryland, and buy an $11,000 dollar computer from Dell.
Luckily Dell was on the ball and asked MBNA to verify the purchase, so the account will be closed immediately. Still, I wonder how they came up with the number? A little scary; but changing that account number is something I should have done years ago, as I use it for way too much stuff. (Which is exactly why I haven't changed it.)
When I called MBNA they asked for my mother's maiden name as verification. I bet that's easy to find - wonder if the online banking site used that same security?
Hopefully changing the account number is the end of it. Then I need to start splitting up my accounts: one credit card for online purchases, one for monthly charges, one for gas, etc. Be careful out there!
Luckily Dell was on the ball and asked MBNA to verify the purchase, so the account will be closed immediately. Still, I wonder how they came up with the number? A little scary; but changing that account number is something I should have done years ago, as I use it for way too much stuff. (Which is exactly why I haven't changed it.)
When I called MBNA they asked for my mother's maiden name as verification. I bet that's easy to find - wonder if the online banking site used that same security?
Hopefully changing the account number is the end of it. Then I need to start splitting up my accounts: one credit card for online purchases, one for monthly charges, one for gas, etc. Be careful out there!
Monday, July 31, 2006
Death of NDOC
I caught the news first from Bill Wagner's blog that NDoc 2.0, the documentation tool for .Net developers, was losing its main developer and motivating force, Kevin Downs. (And incidentally, I never saw anything useful on either Digg or Technorati about it. Simple Google is still the best place to look.) Here's what Kevin had to say in an email that was quoted in dozens of blogs:
As some of you are aware, there are some in the community who believe that a .Net 2.0 compatible release was theirs by-right and that I should be moving faster – despite the fact that I am but one man working in his spare time...
This came to head in the last week; I have been subjected to an automated mail-bomb attack on both my public mail addresses and the ndoc2 mailing list address. These mails have been extremely offensive and resulted in my ISP temporarily suspending my account because of the traffic volume.
The standard line of bloggers has been, more or less: What a shame, what a loss to the community, why aren't these mailbombers contributing, that's what happens to open source projects.
It certainly is a big loss. But to be honest, I don't see it as a huge deal. Bill sees it as a problem with the whole open source software model, which I disagree with - I think the Asterisk project is one counterexample. The email, to me, has a bit of a defensive tone, like the writer's lost all his enthusiasm for the project and is looking for an excuse to get out of it. (I've sure been in that position, and it's got nothing to do with open source!) Is NDoc really that heavily used? Doxygen has the advantage of working with more languages, so it's my preferred tool, but I would think if there are that many people interested in using it, surely someone can step up as a new administrator, even if the project languishes for a while. And a mailbomb attack? Do those really still work? I would have thought any administrator would have been able to block some IP's and stop it. I guess it was the product of someone's bot army; but that brings up another point: anyone can launch a mailbomb or DOS attack. You can make one person mad online, even for a perceived rather than an actual insult, and the attack can come. If you're a small organization, you just have to weather the storm and move on.
I'm not saying Mr. Downs made the wrong decision; far from it. It's his life and his work and we should be grateful for whatever he is willing to donate to the community. But let's accept it and move on without getting huffy about it.
Oh, and maybe I better see if Doxygen could use any extra coders...
As some of you are aware, there are some in the community who believe that a .Net 2.0 compatible release was theirs by-right and that I should be moving faster – despite the fact that I am but one man working in his spare time...
This came to head in the last week; I have been subjected to an automated mail-bomb attack on both my public mail addresses and the ndoc2 mailing list address. These mails have been extremely offensive and resulted in my ISP temporarily suspending my account because of the traffic volume.
The standard line of bloggers has been, more or less: What a shame, what a loss to the community, why aren't these mailbombers contributing, that's what happens to open source projects.
It certainly is a big loss. But to be honest, I don't see it as a huge deal. Bill sees it as a problem with the whole open source software model, which I disagree with - I think the Asterisk project is one counterexample. The email, to me, has a bit of a defensive tone, like the writer's lost all his enthusiasm for the project and is looking for an excuse to get out of it. (I've sure been in that position, and it's got nothing to do with open source!) Is NDoc really that heavily used? Doxygen has the advantage of working with more languages, so it's my preferred tool, but I would think if there are that many people interested in using it, surely someone can step up as a new administrator, even if the project languishes for a while. And a mailbomb attack? Do those really still work? I would have thought any administrator would have been able to block some IP's and stop it. I guess it was the product of someone's bot army; but that brings up another point: anyone can launch a mailbomb or DOS attack. You can make one person mad online, even for a perceived rather than an actual insult, and the attack can come. If you're a small organization, you just have to weather the storm and move on.
I'm not saying Mr. Downs made the wrong decision; far from it. It's his life and his work and we should be grateful for whatever he is willing to donate to the community. But let's accept it and move on without getting huffy about it.
Oh, and maybe I better see if Doxygen could use any extra coders...
Customer Affinity and UI design
Martin Fowler discusses the importance of being attuned to the business side of software development. I especially liked this quote:
I've often heard it said that enterprise software is boring, just shuffling data around, that people of talent will do "real" software that requires fancy algorithms, hardware hacks, or plenty of math. I feel that this usually happens due to a lack of customer affinity.
I've heard this too, in spirit at least. and one of the reasons is that those people of talent don't believe that UI design is "real" software. Of course, the place you have the most opportunity to affect how the customers work and whether they enjoy your software is in the user interface. In the last few years, UI design has started to gain a little more respect in the community, but the fact remains that it is one of the areas of software design that really remains an art, rather than a science. What are your favorite sites for discussing UI design?
I've often heard it said that enterprise software is boring, just shuffling data around, that people of talent will do "real" software that requires fancy algorithms, hardware hacks, or plenty of math. I feel that this usually happens due to a lack of customer affinity.
I've heard this too, in spirit at least. and one of the reasons is that those people of talent don't believe that UI design is "real" software. Of course, the place you have the most opportunity to affect how the customers work and whether they enjoy your software is in the user interface. In the last few years, UI design has started to gain a little more respect in the community, but the fact remains that it is one of the areas of software design that really remains an art, rather than a science. What are your favorite sites for discussing UI design?
Tuesday, July 18, 2006
Finding holes in the process
Ever done a process review? It's one of those things that gets done, formally or informally, when a software company is trying to grow from small to large. In my experience, the most likely way it happens is, a manager or two or three get together and decide on some tool that they like, or have used before, and that they think would be useful for source control, or bug tracking, or building, and then they pass the edict down to the programmers: "Okay guys, from now on we use OnTime for all bug reports." The programmers nod politely and get on with the business at hand, and may even enter a few things into OnTime if they remember.
Ina few months, the managers realize that nobody's paying much attention to OnTime, and they go and bug the programmers. "Hey guys, let's use this bug tracker, ok? We paid a lot of money for it." The programmers start entering a few more things into OnTime, if they remember, but they grumble about it. Why waste time on this busywork, they think? The programmers aren't happy, the managers aren't happy, and communication is breaking down badly.
How do you avoid this? Don't just nod politely when the tool is introduced; attack it. Of course, if it's a tool you've not used before, you won't be able to see what any weaknesses are. But try to understand the workflow. Bug the manager until he makes it clear for you. He'll probably end up saying something like "Each bug goes from Entered to Accepted to Fixed to Tested to Released".
That's a pretty standard workflow. But now you can start to poke holes in it. Has anyone thought through the failure steps?
"Okay, so what if it's a bogus bug? I'm not going to accept it then."
"Hmm, that's true. Maybe we should add a Rejected state."
"Sounds good. What if Testing fails?"
"Umm, the test group should just set it back to Entered, and it can cycle through again."
"Okay, but what if that happens the week before the release? Do we need to put off the release until the bug gets fixed? Or can we hold off on it until the next release?"
"Ummm..."
Processes tend to break down around the failure points. If every bug took the path Find/Fix/Test/Release, software development would be very simple, and the workflow would be completely linear. But on every step of the line, it needs to be clear what will happen on a failure. Does it go back to previous step? Farther? Can we ignore it? A clear workflow with known failure paths will go a long way towards making any software project smoother.
Ina few months, the managers realize that nobody's paying much attention to OnTime, and they go and bug the programmers. "Hey guys, let's use this bug tracker, ok? We paid a lot of money for it." The programmers start entering a few more things into OnTime, if they remember, but they grumble about it. Why waste time on this busywork, they think? The programmers aren't happy, the managers aren't happy, and communication is breaking down badly.
How do you avoid this? Don't just nod politely when the tool is introduced; attack it. Of course, if it's a tool you've not used before, you won't be able to see what any weaknesses are. But try to understand the workflow. Bug the manager until he makes it clear for you. He'll probably end up saying something like "Each bug goes from Entered to Accepted to Fixed to Tested to Released".
That's a pretty standard workflow. But now you can start to poke holes in it. Has anyone thought through the failure steps?
"Okay, so what if it's a bogus bug? I'm not going to accept it then."
"Hmm, that's true. Maybe we should add a Rejected state."
"Sounds good. What if Testing fails?"
"Umm, the test group should just set it back to Entered, and it can cycle through again."
"Okay, but what if that happens the week before the release? Do we need to put off the release until the bug gets fixed? Or can we hold off on it until the next release?"
"Ummm..."
Processes tend to break down around the failure points. If every bug took the path Find/Fix/Test/Release, software development would be very simple, and the workflow would be completely linear. But on every step of the line, it needs to be clear what will happen on a failure. Does it go back to previous step? Farther? Can we ignore it? A clear workflow with known failure paths will go a long way towards making any software project smoother.
Thursday, July 13, 2006
Build part 3
Looks like the build is finally up and running, and we've completed a few builds that testing seems to approve of. I finally moved the virtual machine over to a machine with a decent amount of power behind it and that got things to pick up a little; but certainly we were far from the James Shore ideal of being able to download and build immediately...at least not after I implemented my idea of moving source code to a different drive so the C drive could be more easily restored if needed. It took quite a bit of time to finally dig out all the references to c:\Prosolv\build and replace them with environment variables!
But our mishmash of Ruby scripts is going again. We have our summer intern working on a new build process: he's evaluated various tools and chosen one called Visual Build, which we'll move to at some point, when he's declared it ready.
My friends Andy and Sushil have both just had babies. Congratulations, you guys!
But our mishmash of Ruby scripts is going again. We have our summer intern working on a new build process: he's evaluated various tools and chosen one called Visual Build, which we'll move to at some point, when he's declared it ready.
My friends Andy and Sushil have both just had babies. Congratulations, you guys!
Thursday, June 29, 2006
Build machine still dragging
(Backstory here.) Came in the next morning; VS2005 is still installing. Curse. The bright side was, as I watched it, it switched from actually installing VS2005 to installing one of the CE framework packages that I really didn't care about. So, I spent some time unsuccessfully trying to get it to cancel out at that point, and eventually was able to get the machine to start shutdown, which allowed me to kill the VS install. How will that affect the machine, I'm not sure. So, around 9AM the machine started shutdown - then, the automatic updates kicked in. Thirty of them. Curse. So here it is, about three hours later, and just about half the updates are complete.
This is not a good circumstance when trying to get a release out.
This is not a good circumstance when trying to get a release out.
Wednesday, June 28, 2006
The perils of slow build machines
We had a hard drive die on our build machine. Not to worry; as we learned from the rubber chicken source code should be buildable and shippable anywhere, anytime. But then, I don't have a great deal of trust in that ideal concept, so we decided to take advantage of the situation to create a virtual build machine instead of a real one. Here are roughly the steps I followed:
Install Virtual PC
Grab an existing hard drive image with Windows XP SP2 and copy it.
Install a couple of things on it; then attempt to install Visual Studio 2005.
It blows up with an error. Huh?
Try it again, same error.
Realize that the image is limited to 4 gigs, and VPC doesn't allow modifying the existing size of a virtual disk, as far as I can tell.
Curse.
Create a brand new image, and install XP SP2 on it. This process takes plenty of rebooting, and "Press Enter to continue" style dialogs; not to mention several hours just to copy all the files.
Install Visual Studio 6; hopefully it will be quicker and we'll need it for some legacy stuff anyway. Many more reboots, but eventually it's installed.
My boss comes by and asks how much longer it will be until the next build.
Curse.
Attempt to install VS2005 again. Many more reboots.
My boss comes by again and tells me he's arranged for a much faster machine with more memory. Cheer.
It's around 5:00 that day, so I decide to leave the VS2005 install running overnight, then I can transfer the virtual machine to the new machine in the morning.
Come back the next morning. VS2005 is still installing.
Curse.
It looks like it's nearly done, though. Hopefully it's within an hour or two of finishing and I can move it over to the faster machine.
Wait eight hours. VS2005 is still installing.
Curse.
I'll leave soon. Hopefully VS2005 won't take 48 hours to install, and I'll be able to get back to it in the morning. We're now at eight days without a new build. Curse.
Install Virtual PC
Grab an existing hard drive image with Windows XP SP2 and copy it.
Install a couple of things on it; then attempt to install Visual Studio 2005.
It blows up with an error. Huh?
Try it again, same error.
Realize that the image is limited to 4 gigs, and VPC doesn't allow modifying the existing size of a virtual disk, as far as I can tell.
Curse.
Create a brand new image, and install XP SP2 on it. This process takes plenty of rebooting, and "Press Enter to continue" style dialogs; not to mention several hours just to copy all the files.
Install Visual Studio 6; hopefully it will be quicker and we'll need it for some legacy stuff anyway. Many more reboots, but eventually it's installed.
My boss comes by and asks how much longer it will be until the next build.
Curse.
Attempt to install VS2005 again. Many more reboots.
My boss comes by again and tells me he's arranged for a much faster machine with more memory. Cheer.
It's around 5:00 that day, so I decide to leave the VS2005 install running overnight, then I can transfer the virtual machine to the new machine in the morning.
Come back the next morning. VS2005 is still installing.
Curse.
It looks like it's nearly done, though. Hopefully it's within an hour or two of finishing and I can move it over to the faster machine.
Wait eight hours. VS2005 is still installing.
Curse.
I'll leave soon. Hopefully VS2005 won't take 48 hours to install, and I'll be able to get back to it in the morning. We're now at eight days without a new build. Curse.
Monday, June 26, 2006
Death of Agile
Jonathan Kohl writes on the value of pragmatism, as opposed to process zealotry, and asks what we think. Jonathan, I think you should enable comments on your blog :) But I'll do a quick post here instead. I'm not sure whether I agree or disagree. Absolutely you should use whatever works for your project; I have no issue with that. But I have a lot of trouble imagining a project where I would say, "In this situation, writing unit tests would be a very bad idea" or "It's clear that we should not have a daily build for this project. One a month, absolute max."
In other words, the point of agile processes are that they are good processes. You use them because they are unquestionably an advantage to your project. Maybe I'm a zealot. Is there an argument to be made against unit tests? To me, the whole zealotry issue comes across like saying, "Sure, I really like transistors, but hey, if vacuum tubes are what your stereo requires, you go right ahead and use them!"
In other words, the point of agile processes are that they are good processes. You use them because they are unquestionably an advantage to your project. Maybe I'm a zealot. Is there an argument to be made against unit tests? To me, the whole zealotry issue comes across like saying, "Sure, I really like transistors, but hey, if vacuum tubes are what your stereo requires, you go right ahead and use them!"
Friday, May 12, 2006
Internship available
If you are a student in a computer-related field at an Indiana college and looking for a summer internship, drop me a line with a resume and I'll see that it gets to the right place. Prosolv is a medical software company in Indianapolis.
Wednesday, April 05, 2006
Podcast list
With basketball season finally over, I plan on updating this blog more often. I have a couple of series ideas in mind: first, I'm looking into presentation systems for 3D medical graphics; ultrasounds, for example, and I'm very interested in the Visual Toolkit (VTK). I've not been successful in importing any of our own sample DICOM sets yet, though, so I need to poke around and try to find some online that will work.
Second, I want to do a podcast review of the nine or ten podcasts I listen to regularly. I have a long commute, and I typically go to the gym over lunch, so I have a good three hours to listen to podcasts per day if I want.
I use Juice as my podcatcher, and an iRiver attached to the auxiliary input to the sound system in my car to listen to the podcasts. Here's an OPML of my subscriptions. In no particular order, they include:
Academic.net
HanselMinutes Mp3 Direct
QA Podcast
Polymorphic Podcast
Perlcast
Chris Pirillo Show
Software As She's Developed
Security Now!
Major Nelson
Channel 9
this WEEK in TECH
Congressman John Hostettler -- Capitol Update
Second, I want to do a podcast review of the nine or ten podcasts I listen to regularly. I have a long commute, and I typically go to the gym over lunch, so I have a good three hours to listen to podcasts per day if I want.
I use Juice as my podcatcher, and an iRiver attached to the auxiliary input to the sound system in my car to listen to the podcasts. Here's an OPML of my subscriptions. In no particular order, they include:
Academic.net
HanselMinutes Mp3 Direct
QA Podcast
Polymorphic Podcast
Perlcast
Chris Pirillo Show
Software As She's Developed
Security Now!
Major Nelson
Channel 9
this WEEK in TECH
Congressman John Hostettler -- Capitol Update
Thursday, March 16, 2006
Continuous Integration and Testing Conference
I'm planning on attending this free-form conference, Chicago, April 7th and 8th. Drop me a line if you'll be there!
Wednesday, March 15, 2006
Friday, March 10, 2006
Team Foundation Server
So Dave Bost gave a presentation on Team Server last night. It was pretty interesting; it was the first time I had really seen a Team System presentation that didn't focus on the different clients. He made it clear that he didn't want to discuss licensing, so I didn't ask the question that really was blazing through my head: why the heck do I and the thirty people in my company give a rip? Team System is for big people.
Anyway, Dave is the new developer evangelist for Indiana. It used to be Chris Mayo, but I guess he's moved on the other things. Dave, are you going to the Continuous Integration conference? Maybe I'll see you there!
There was also a semi-organizational meeting for a C# special interest group. I think that might be interesting, and we'll probably pull out the computers for the next one. A guy from the Advanced Visualization Lab was there too; their work might be relevant to some of the new 3D ultrasound machines that we're examining at Prosolv. Should be very interesting!
Anyway, Dave is the new developer evangelist for Indiana. It used to be Chris Mayo, but I guess he's moved on the other things. Dave, are you going to the Continuous Integration conference? Maybe I'll see you there!
There was also a semi-organizational meeting for a C# special interest group. I think that might be interesting, and we'll probably pull out the computers for the next one. A guy from the Advanced Visualization Lab was there too; their work might be relevant to some of the new 3D ultrasound machines that we're examining at Prosolv. Should be very interesting!
Wednesday, March 08, 2006
Volume texture DDS files
I had reason to try to create a Direct3D volume texture this week. This article gave instructions on how to do it, but I think it must have been out of date, because running the code they gave did not result in a DDS file that was loadable by the texture viewer. (I messed around with modifying the article, but then I had to register on the site, and blah blah blah) So I studied the header that was generated by the texture viewer, and eventually wrote this code:
To be a really useful sample, I need to replace the flag values with constants...I need to figure out what they are, first, though!
#include <ddraw.h>
#include <fstream>
#include <D3d8types.h>
int main( int argc, char * argv[] ) {
if( !argv[1] || !strstr( argv[1], ".dds" ) ) {
fprintf( stderr, "Usage: noise output.dds\n" );
return 1;
}
DDSURFACEDESC2 desc;
memset( &desc, 0, sizeof(desc) );
desc.dwFlags = 0x00801007;
desc.dwSize = 124;
desc.dwDepth = 64;
desc.dwWidth = 128;
desc.dwHeight = 128;
desc.dwBackBufferCount = 64;
desc.ddsCaps.dwCaps = 0x00001002;
desc.ddsCaps.dwCaps2 = 0x00200000;
desc.dwFVF = 32;
desc.ddpfPixelFormat.dwSize = 0x20;
desc.ddpfPixelFormat.dwFlags = 0x41;
desc.ddpfPixelFormat.dwRGBBitCount = 0x20;
desc.ddpfPixelFormat.dwLuminanceBitCount = 0x20;
desc.ddpfPixelFormat.dwBumpBitCount = 0x20;
desc.ddpfPixelFormat.
dwPrivateFormatBitCount = 0x20;
desc.ddpfPixelFormat.dwRBitMask = 0x00ff0000;
desc.ddpfPixelFormat.dwGBitMask = 0x0000ff00;
desc.ddpfPixelFormat.dwBBitMask = 0x000000ff;
desc.ddpfPixelFormat.
dwRGBAlphaBitMask = 0xff000000;
unsigned int cnt =
desc.dwWidth*desc.dwHeight*desc.dwDepth*4;
unsigned char * buf = new unsigned char[ cnt ];
while( cnt-- ) {
buf[cnt] = rand()>>7;
}
std::ofstream ofst( argv[1] );
ofst << "DDS ";
ofst.write( (const char *)&desc, 124 );
ofst.write( (const char *)buf,
desc.dwWidth*desc.dwHeight*desc.dwDepth*4 );
return 0;
}
To be a really useful sample, I need to replace the flag values with constants...I need to figure out what they are, first, though!
Tuesday, February 28, 2006
Honestly Subjective Performance Reviews
(Thanks Lasse.) Corporate performance reviews are for the most part a waste of time. At my last job, I worked with the same set of peers for around four years, and we did peer reviews on their anniversaries. The first year, I tried to provide constructive feedback on how I thought people were doing, what they could do better, etc. The second, third, and fourth years, I had no idea what to write. Reiterate what I wrote the year before? Try to comment on what they were doing better than they did last year? I didn't have a clue. Once (with a really cool boss) I wrote my evaluation as a limerick.
This article discusses what's wrong with reviews, and how they can be better. First of all, just bail on the idea that reviews can ever be objective, any more than journalists can. Then focus on the future, not the past. It's a very agile idea. I'm excited about the future of work. I think corporations of the 21st century can work so much better. But how many companies are willing to give it a shot?
This article discusses what's wrong with reviews, and how they can be better. First of all, just bail on the idea that reviews can ever be objective, any more than journalists can. Then focus on the future, not the past. It's a very agile idea. I'm excited about the future of work. I think corporations of the 21st century can work so much better. But how many companies are willing to give it a shot?
Subscribe to:
Posts (Atom)