I have the unfortunate experience of supporting a rather large application in a rather large bank. This application is on a pair of load-shared Windows Terminal Servers 2003. We've been fighting problems with trying to get SIMPLE PRINTING to work for the entire time. If printing is your big issue, I don't see how moving to WTS is going to help you at all.
If anyone can prove me wrong and that it's just some sort of configuration issue, PLEASE LET ME KNOW! If you can make it work for us, I'll be overjoyed and send you something nice. (I mean it--if you can solve my biggest pain in the tookas, I'll find something nice and send it to you!)
Our specific printing problems are (1) The application and/or WTS gets confused and spits out partial printouts (yep, we're using WTS-approved printer drivers!) (2) The print spooler(s) periodically hang for no good reason (3) There's a "ring of pain" where OPS points to the network, the networking support points to the application team, the application team doesn't have permissions to look at anything to find any answers...
Uh, sorry, I didn't mean to start off on a rant. Let me just say: If I could remove any one application from our site. It would be THAT one.
I think the problem is mostly that it's frequent enough to be EXTREMELY frustrating, yet rare enough to be impossible to reproduce on demand, and there are enough parties involved that you can never get enough brains focused on the problem long enough to get the damn thing fixed!
Back in the day, we used to see articles for homebrew touch screens that were basically picture frames with a few infrared LEDs on one side, and some phototransistors on the other with a bit of circuitry. Your finger would break a beam and get detected.
For a tiny production run, this might be an acceptable method. (For a *real* product, you'll want something better.)
Another thought: If you can get a conductive transparent plastic sheet, then you could make a sandwich where one sheet is against the screen, and the other is floating a small distance away. Then you can just detect the conductivity change when someone pokes the top sheet enough to make it touch the bottom sheet.
I don't recall the EPA sticker figures on my car, but I have a '98 Saturn, and I get 31-35mpg.
Of course, I drive like a little old lady from Pasadena (not the one of the Beach Boys fame, though). I usually skip breakfast (perhaps it saves weight?), and my neighbors cats are grey...
The client is paying you for your time in developing an application.
Not always. In my experience, there are several types of customers for contract programming:
one who wants a tool
one who wants a new product
Those interested in a tool aren't normally interested in the source code, other than as a form of support. Normally, they're not paying you for your time or for ownership of the source code. They want a tool to do a job and are willing to pay for it.
Many of them know enough to ask for the source code so they can get bugfixes if you happen to be run over by a doughnut wagon. Even in this case they usually don't want ownership of the source code--they just want a license to it.
Normally the people who want you to create (part of) a product are the ones who want you to relenquish the rights to the code. If so, make sure you charge them accordingly. After all, for my customers who buy a tool, I can use significant chunks of code I've used in many other projects. I can't use my subroutines for customers wanting exclusive rights, so not only do they pay for the extra time in reinventing wheels (or the purchase of third-party libraries to do tasks), they also get to pay for the exclusivity.
As an (admittedly ridiculous) example, suppose a secretary wanted a word processing program, but no word processing software exists yet. She could pay you to write one for her. She doesn't really want to sell word processors or anything, she just wants one to help her business. You could write one for her, and she could write you a check.
For that money, they should get at least:
1) The binaries
2) documentation
3) support
No argument there...
If you can't give them support, the ethical thing to do would be to let them know, and give them the source code so that they can have someone else maintain it.
Giving them support can come in many forms, one of which is making available the source code so they can get someone to fix it if you're unavailable. But THEY should choose whether to open source the code or not. They paid for it. It's their decision, not yours.
People who want a 'smart home' don't really care about the underlying technology. They care about the capabilities offered. So while you might be implementing a neural system for your own amusement, you'll want to focus more on the capabilities of the system rather than the techie details.
Of course, I think it would be cool. (I've worked on fuzzy systems, and there's a bit of amusement to be found in them....) But your average guy or gal knows of 'fuzzy' only as a market-droid buzzword adjective....
cyber_spaz (formerly robospaz who forgot his password...)
Slashdot Mirror
Yeah, but I've moved on to the CK722 and HEP-1 and GE-1! Go Germanium!
Dysfnctnl85--
I have the unfortunate experience of supporting a rather large application in a rather large bank. This application is on a pair of load-shared Windows Terminal Servers 2003. We've been fighting problems with trying to get SIMPLE PRINTING to work for the entire time. If printing is your big issue, I don't see how moving to WTS is going to help you at all.
If anyone can prove me wrong and that it's just some sort of configuration issue, PLEASE LET ME KNOW! If you can make it work for us, I'll be overjoyed and send you something nice. (I mean it--if you can solve my biggest pain in the tookas, I'll find something nice and send it to you!)
Our specific printing problems are (1) The application and/or WTS gets confused and spits out partial printouts (yep, we're using WTS-approved printer drivers!) (2) The print spooler(s) periodically hang for no good reason (3) There's a "ring of pain" where OPS points to the network, the networking support points to the application team, the application team doesn't have permissions to look at anything to find any answers...
Uh, sorry, I didn't mean to start off on a rant. Let me just say: If I could remove any one application from our site. It would be THAT one.
I think the problem is mostly that it's frequent enough to be EXTREMELY frustrating, yet rare enough to be impossible to reproduce on demand, and there are enough parties involved that you can never get enough brains focused on the problem long enough to get the damn thing fixed!
I wish you better luck than I have had so far...
--cyber_spaz
Back in the day, we used to see articles for homebrew touch screens that were basically picture frames with a few infrared LEDs on one side, and some phototransistors on the other with a bit of circuitry. Your finger would break a beam and get detected.
For a tiny production run, this might be an acceptable method. (For a *real* product, you'll want something better.)
Another thought: If you can get a conductive transparent plastic sheet, then you could make a sandwich where one sheet is against the screen, and the other is floating a small distance away. Then you can just detect the conductivity change when someone pokes the top sheet enough to make it touch the bottom sheet.
I don't recall the EPA sticker figures on my car, but I have a '98 Saturn, and I get 31-35mpg.
Of course, I drive like a little old lady from Pasadena (not the one of the Beach Boys fame, though). I usually skip breakfast (perhaps it saves weight?), and my neighbors cats are grey...
Yep, it's funny. But I tried using Microsoft PowerPoint, and couldn't read it. KPresenter was good enough for me to read it though.
(Of course, using an ancient version of PowerPoint (from Office 95) didn't help. But I quit buying MS products some time ago...)
The client is paying you for your time in developing an application.
Not always. In my experience, there are several types of customers for contract programming:
one who wants a tool
one who wants a new product
Those interested in a tool aren't normally interested in the source code, other than as a form of support. Normally, they're not paying you for your time or for ownership of the source code. They want a tool to do a job and are willing to pay for it.
Many of them know enough to ask for the source code so they can get bugfixes if you happen to be run over by a doughnut wagon. Even in this case they usually don't want ownership of the source code--they just want a license to it.
Normally the people who want you to create (part of) a product are the ones who want you to relenquish the rights to the code. If so, make sure you charge them accordingly. After all, for my customers who buy a tool, I can use significant chunks of code I've used in many other projects. I can't use my subroutines for customers wanting exclusive rights, so not only do they pay for the extra time in reinventing wheels (or the purchase of third-party libraries to do tasks), they also get to pay for the exclusivity.
As an (admittedly ridiculous) example, suppose a secretary wanted a word processing program, but no word processing software exists yet. She could pay you to write one for her. She doesn't really want to sell word processors or anything, she just wants one to help her business. You could write one for her, and she could write you a check.
For that money, they should get at least:
1) The binaries
2) documentation
3) support
No argument there...
If you can't give them support, the ethical thing to do would be to let them know, and give them the source code so that they can have someone else maintain it.
Giving them support can come in many forms, one of which is making available the source code so they can get someone to fix it if you're unavailable.
But THEY should choose whether to open source the code or not. They paid for it. It's their decision, not yours.
cyber_spaz
Of course, I think it would be cool. (I've worked on fuzzy systems, and there's a bit of amusement to be found in them....) But your average guy or gal knows of 'fuzzy' only as a market-droid buzzword adjective....
cyber_spaz (formerly robospaz who forgot his password...)