Johnny Mnemonic writes: "My company has the opportunity to contribute to a children's museum in our area. We are a technology company, so I'd like the exhibit to be computer/networking related, and to raise the awareness and understanding of how the internet, networking, and computers work. However, Children's Museums cater to a pretty young age group of 3-8 year olds, so the the exhibit needs to be highly interactive, durable, tactile, and yet instructive of the concepts. Google fails to turn up any turn-key options, and, although the concepts are computer related, a computer-based exhibit tends to be too fragile and susceptible to withstand the rigors of 250 preschoolers/day. How would you design a display that meets those requirements and is still fun and educational?"
Johnny Mnemonic writes: "I help Sys Admin a Linux setup. It has a several hundred end users, spread out in many locations and time zones. Our users often write their own bash/python/perl scripts to help with their daily duties, and other users often invoke those scripts directly from the author's home directory when they have proven interesting and useful. Also, we have perhaps a dozen directories in which reviewed scripts can be located. Some of the scripts can be quite sophisticated, and grow to multiple hundreds of lines.
We have found that when a script is useful, our users expect it to work all of the time--regardless if the original author of the tool has quit, if the code breaks, or it doesn't scale up to being used by hundreds of users due to poor design. When that happens, we are put in the awkward and frustrating position of supporting a script that was poorly designed and/or poorly documented--and often the first time we are even made aware of it is via the trouble ticket for the tool breaking. So we are in mad scramble to understand the tool, and understand why it broke--and the users that have come to depend on it are breathing down our back.
The Sys Admin team would like to know all of the scripts that these users might be using. We care less about executables that have been written but aren't actually being used--so it's not really useful to just look for files which are +x. Our users are a clever bunch, and the utilities that they build themselves serve their needs well--we generally encourage this tool creation process. We encourage this kind of self-help, so we can't simply disable the ability to run arbitrary executables altogether. We just want to know about them when they build those tools, so we can better support them should they become popular with other users and useful to the business.
How are you aware of all of the scripts and tools that your users build for each other? How and when do you accept support responsibilities for home grown tools? How do you require users who just want to get the job done to accept coding conventions and best-practices? We have tried to mandate that the user base accept these from the outset of their development--but have found that strictly enforcing good code hygiene from the outset actually results in them talking to us less, not more--and makes the problem worse, not better.
Johnny Mnemonic writes: "OS X, with some modifications, has been made to run fully on an Apple TV. Now you can have a OS X dev box, with 1Ghz CPU and 256MB of ram, for $299. Bring your own (HDMI) monitor, keyboard, and mouse. Boy, that was quick!"