I second this.
Make up a QR code with embedded information about the title of the book, who you lent it to, and when.
Print up a sticker and affix it to the spine of the book. You can also place a traditional Ex Libris sticker on the inside cover.
Then, when you see the book in your ex-friend's library, you can scan the QR code with any smartphone camera.
I've been using JS Pager Virtual Desktop since the 1990's.
It's a lightweight app which leverages existing windows capabilities to provide multiple "panes" in a grid.
There's no support, but it has been working through multiple versions of Windows from 98 through 7.
The next step is direct cochlear implantation, bypassing the mechanical subsystems for truly dynamic fidelity. A fortunate byproduct would be hearing implants for the deaf.
1) ! (K&R braces)// 'nuff said
2) when formatting expressions, put multiple spaces in parens () - depending on nesting level
ie. if ( ( exp1 || (exp2 & something) ) && (something-else) )
3) about variable names - no hungarian notation, please. If the type of the variable is not apparent from context, I can da*m well look up the definition, thank you.
A roommate of mine was working on a big project for a major telecommunications company, in a variation of Pascal. Their standard was to encode everything into the variable name - scope, persistance, type, and finally some sort of actual name. The names tended to be over 80 chars in length - making it impossible to simply scan the code. I heard they spent a lot of time in code reviews. I'm suprised they actually got the system to work.
I wonder if they are using GPS techniques to encode the laser pulse with a pseudo-random sequence. By synchronizing the return pulse train with the predicted sequence, they can significally increase the signal-to-noise ratio (a million-fold). Once the signal is locked-in, it should be fairly easy (but not trivial) to further refine the tracking of both the transmitter and receiver.
I used to believe that design was the most important thing about software development, but as I've grown older (and greyer), I've come to the realization that good requirements are critical.
I've even gotten to the point where I've developed my own requirements tracking system (MRAP - not a very imaginative acronym:).
When a client asks me to implement a new feature, I ask a few pointed questions to narrow down exactly what he wants. I have a template of over 100 topics in a dozen categories to draw upon. If he can't clarify his expectations, then chances are what he wants is unimplementable.
I record all the requirements in a database, organized hierarchically. I can keep all sorts of info such as create dates, authors, update history, authorities, design elements, unit tests, etc. attached to each requirement.
The client signs off on each requirement before development proceeds. (I don't tell him that I've already completed most of the design process by that time.:) On the rare occasions that there is a dispute, I can point directly at the requirement and convince him that it was under-specified, or mis-interpreted. Usually, by that time, he is educated enough that his expectations are in-line with reality.
It's hard to get the client to buy-into the requirements process. He wants development to start immediately, and is chomping at the bit to get something tangible right off the bat. I usually whip up a proof-of-concept prototype to keep him occupied (distracted?) with the proviso that this IS NOT THE FINAL PRODUCT! and will be thrown away in a week.
When development starts, the client is often amazed at the rate of progress.
The requirements database is dynamic, always being updated as new information becomes available. It is the source/sink for project feedback. Every little detail gets recorded - emails, test results, bugs.
It gets reviewed constantly. Completed items get checked off (and hidden if desired)
Now, to get back to estimation. As the requirements get more detailed, the uncertanties get whittled away, and it becomes easier to estimate - if only based on past experience. Each pass through the requirements allows you and the client to set priorities and define more precise schedules. Those areas that are not fully defined yet can be respecified, bulk-estimated, deferred or deprecated.
A very important part of the requirements is the project completion section. The project is complete when all the items have been marked completed, the deliverables have been delivered and the money is in the bank.
If the client doesn't seem happy at this point, it is time to reopen negotiations - perhaps to start a whole new project, or to abandon the whole idea, take your marbles, and leave the playing field.
Slashdot Mirror
We welcome our SkyNet Overlords!!!
I second this. Make up a QR code with embedded information about the title of the book, who you lent it to, and when. Print up a sticker and affix it to the spine of the book. You can also place a traditional Ex Libris sticker on the inside cover. Then, when you see the book in your ex-friend's library, you can scan the QR code with any smartphone camera.
Ominous.
I've been using JS Pager Virtual Desktop since the 1990's. It's a lightweight app which leverages existing windows capabilities to provide multiple "panes" in a grid. There's no support, but it has been working through multiple versions of Windows from 98 through 7.
The next step is direct cochlear implantation, bypassing the mechanical subsystems for truly dynamic fidelity. A fortunate byproduct would be hearing implants for the deaf.
1) ! (K&R braces) // 'nuff said
2) when formatting expressions, put multiple spaces in parens () - depending on nesting level
ie. if ( ( exp1 || (exp2 & something) ) && (something-else) )
3) about variable names - no hungarian notation, please. If the type of the variable is not apparent from context, I can da*m well look up the definition, thank you.
A roommate of mine was working on a big project for a major telecommunications company, in a variation of Pascal. Their standard was to encode everything into the variable name - scope, persistance, type, and finally some sort of actual name. The names tended to be over 80 chars in length - making it impossible to simply scan the code. I heard they spent a lot of time in code reviews. I'm suprised they actually got the system to work.
I wonder if they are using GPS techniques to encode the laser pulse with a pseudo-random sequence. By synchronizing the return pulse train with the predicted sequence, they can significally increase the signal-to-noise ratio (a million-fold). Once the signal is locked-in, it should be fairly easy (but not trivial) to further refine the tracking of both the transmitter and receiver.
I used to believe that design was the most important thing about software development, but as I've grown older (and greyer), I've come to the realization that good requirements are critical.
I've even gotten to the point where I've developed my own requirements tracking system (MRAP - not a very imaginative acronym:).
When a client asks me to implement a new feature, I ask a few pointed questions to narrow down exactly what he wants. I have a template of over 100 topics in a dozen categories to draw upon. If he can't clarify his expectations, then chances are what he wants is unimplementable.
I record all the requirements in a database, organized hierarchically. I can keep all sorts of info such as create dates, authors, update history, authorities, design elements, unit tests, etc. attached to each requirement.
The client signs off on each requirement before development proceeds. (I don't tell him that I've already completed most of the design process by that time.:) On the rare occasions that there is a dispute, I can point directly at the requirement and convince him that it was under-specified, or mis-interpreted. Usually, by that time, he is educated enough that his expectations are in-line with reality.
It's hard to get the client to buy-into the requirements process. He wants development to start immediately, and is chomping at the bit to get something tangible right off the bat. I usually whip up a proof-of-concept prototype to keep him occupied (distracted?) with the proviso that this IS NOT THE FINAL PRODUCT! and will be thrown away in a week. When development starts, the client is often amazed at the rate of progress.
The requirements database is dynamic, always being updated as new information becomes available. It is the source/sink for project feedback. Every little detail gets recorded - emails, test results, bugs. It gets reviewed constantly. Completed items get checked off (and hidden if desired)
Now, to get back to estimation. As the requirements get more detailed, the uncertanties get whittled away, and it becomes easier to estimate - if only based on past experience. Each pass through the requirements allows you and the client to set priorities and define more precise schedules. Those areas that are not fully defined yet can be respecified, bulk-estimated, deferred or deprecated.
A very important part of the requirements is the project completion section. The project is complete when all the items have been marked completed, the deliverables have been delivered and the money is in the bank.
If the client doesn't seem happy at this point, it is time to reopen negotiations - perhaps to start a whole new project, or to abandon the whole idea, take your marbles, and leave the playing field.
regards,
Dar7yl