How to replace 30 laptops (and $10,000) with 150 sheets of paper
ruk.ca
ruk.ca
You have a cabin in the woods, with electricity and a freezer. You go hunting and bag a deer with much more meat than can be used in one visit, so you freeze it for use on a future visit. But you want to know while you are away if the electricity fails for any length of time so that the meat may have thawed and spoiled.
After the class spent most of a period arguing over remote monitoring systems and temperature sensors and the like, the professor revealed the simple answer. Freeze a block of ice in the freezer and mark its height. If it is shorter when you return, the power was out so some of it melted.
Your computer has a setting on whether or not it should turn back on after power loss, build a low cost circuit that does the same(turns off in case of power loss) and you are done.
Ice evaporates, but a large block will take quite a while.
I was thinking of some sort of canary that would trip if power turned off, but that would only tell you if the power ever went off, not how long it was off. No sense wasting a fridge full of meat if the power was off for a few seconds.
A clock that requires electricity but displays the time mechanically with a date on it would also suffice, as you could measure the delta between what it displays and what the time really is (accounting for normal inaccuracies).
If the battery has run out, then there has been enough long power outages that the meat is probably spoiled. If the battery hasn't run out, you have a nice log of what happened when.
Not that I think its better than the ice solution, but theres certainly techie options that you could build for $10 or so.
Actually, ice sublimates
1) A block of ice will occupy room that could've been used for more deer meat(I suppose the size wouldn't matter, of course)
2) A temperature sensor would let you know right away if the power failed, instead of finding out after the fact and forcing you to clean out a freezer full of rotting meat
3) The sensor may also act as a silent alarm system. If the temperature changes suddenly then goes back to normal, it's possible that an intruder opened it up looking for money / food / valuables.
I realize that misses the point of the discussion since the professor was going for the easiest possible solution, but we're hackers here :)
"During the space race back in the 1960's, NASA was faced with a major problem. The astronaut needed a pen that would write in the vacuum of space. NASA went to work. At a cost of $1.5 million they developed the "Astronaut Pen". Some of you may remember. It enjoyed minor success on the commercial market.
The Russians were faced with the same dilemma.
They used a pencil."
The idea is to show outcome-oriented thinking. The desired outcome wasn't to use a pen, but rather, to simply write or record.
I've read a book from a former astronaut though, that tend to prove there's some truth to the legend; it was about the vacuum cleaner used in Mir. The NASA devised a sophisticated way to clean up the Space Shuttle; the Russians simply used an ordinary vacuum cleaner from the nearest supermarket.
If it only costs a buck to launch a commercial vacuum cleaner into space, I will eat a hat of your choosing.
Speaking of pedantic, a flight's outcome is not really safety, nor was space flight what the folklore mentions. It was addressing the requirement to write/record in space.
One person felt long ago(can't find the exact quote) that there was once a world market for maybe five computers, and others thought that lasers and x-rays would be nothing more than a sham.
To put it another way: http://www.smbc-comics.com/index.php?db=comics&id=2088#c...
For that matter it took a long time for computers to have an impact on productivity. For a while people wondered whether personal computers actually made business sense. Now, in the era of mass global computerized communications the advantages are hard to ignore.
Cover the deer with crushed ice. If it is still covered when you get back, the meat is still good. Even if the power was out for a while and some of the ice melted. (A large freezer filled with meat and ice will stay cold for quite a while. Even if some of the ice melts and refreezes, the temperature stayed freezing.)
Probably just as well, you won't want it with the putrified carcass in it.
(I keep a ziploc baggie of icecubes in my freezer. It lets me know if my food is going to kill me, and I can use it as ice if I run low!)
Assuming you took a truck hunting, get rid of the problem altogether. Stick the meat in the freezer and stick the freezer in your truck and take it home with you where you can not only monitor it personally, but still enjoy the meat whenever you want. The only concerns then are keeping the freezer interior cold enough for the trip back (pretty easy) and the space at your place.
Long story short, there's a couple of buildings in Addison, TX that might still have "The Guild of Calamitous Intent" working out of a non-existent penthouse.
Her group's suggestion was that I build a simple system that maintains an electronic catalog of all the Master labels for all the production jobs, and before each job is run, a production employee would scan in a sample of the printed box labels. Then my system could do its magic and let the employee know if the Master label matches the printed label. If so, they can continue with production.
As I listened to their request, cogs were already starting to turn in my brain: CRUD system to manage Master labels, versioning for each label, preassigning Masters to specific jobs based on customer approval, scanning labels from the manufacturing area, graphical diff. with auto-orientation matching, and documenting/validating this entire system. Hmm. Let's see if there is an easier way.
Me: Why can't the production employees compare the labels by just looking at them?
Her: Because sometimes it's just a few sentences or design elements that change. It's easy to miss and has happened a few times.
Me: Who provides us the Master labels?
Her: The customer. And we make it a part of the production paperwork well-in-advance and get it approved by the customer so there is never a mixup on the Master itself.
Me: Sounds logical. How are the sticky labels printed?
Her: Depends. We may print them ourselves if it's just a few hundred or get them printed by label vendors for large quantities. We may reuse them in multiple jobs and so may warehouse them for future use.
Me: So before every production job, someone goes to the warehouse, looks for a stack of printed labels in the racks by Item# / Bin#, and brings them back to the production room?
Her: Yes. And that's when errors happen. They might bring back the wrong version of the label and not realize it. Or people in the previous shift might have returned unused labels into the wrong bin etc.
Me: OK. So just to recap, our production team can get the correct Master label every time because it is part of the paperwork already approved by the customer, but errors happen because there could be 10 very similar versions of the same label in the warehouse and the employee might pick the wrong one.
Her: Correct.
Me: One way to prevent such errors would be to add Version# to every lot of every label item we have in the warehouse and have the barcode scanners block movement of incorrect versions, however that requires a tremendous effort of data-entry, programming, and training.
Her: Absolutely. That's why we just want to compare the Master with the printed samples automatically.
Me: What size are these Master labels in?
Her: Centered on regular 8.5x11.
Me: And the printed labels are also centered on 8.5x11 and same size as the Master labels?
Her: Yes.
Me: What if the prodution employee photocopies the Master label to a transparency sheet and overlays it on the printed labels? I know we have copiers in the area.
silence
everyone looks at each other and nods in agreement
Her: That'll work. Thanks everyone. Let's get some lunch.
What WMS were you using?
An example: I was asked to build a system to keep track of daily tasks of one of our teams, and to make sure all scheduled tasks were assigned to someone. As I was listening to them, I suddenly realized that the magnetic white-board on the meeting room wall was all they needed. I drew a table with team-members names and weekdays and used the magnets as tasks.
After some silence the team supervisor said it would work, but would not be used because: a) it looks 'unprofessional'; b) it's 'insecure' because someone could mess up the magnets by accident
After some emails between my manager and them my colleague was ordered to build the system, he ended up spending about 3 weeks on it :)
All too often we "listen" to a customer and implement a suggestion, not realizing it's a horrible solution to a problem they haven't fully realized.
The world needs better listeners.
http://www.lixo.org/archives/2008/07/21/networks-are-smart-a...
A toothpaste factory had a problem: they sometimes shipped empty boxes, without the tube inside. This was due to the way the production line was set up, and people with experience in designing production lines will tell you how difficult it is to have everything happen with timings so precise that every single unit coming out of it is perfect 100% of the time. Small variations in the environment (which can’t be controlled in a cost-effective fashion) mean you must have quality assurance checks smartly distributed across the line so that customers all the way down the supermarket don’t get pissed off and buy someone else’s product instead.
Understanding how important that was, the CEO of the toothpaste factory got the top people in the company together and they decided to start a new project, in which they would hire an external engineering company to solve their empty boxes problem, as their engineering department was already too stretched to take on any extra effort.
The project followed the usual process: budget and project sponsor allocated, RFP, third-parties selected, and six months (and $8 million) later they had a fantastic solution — on time, on budget, high quality and everyone in the project had a great time. They solved the problem by using some high-tech precision scales that would sound a bell and flash lights whenever a toothpaste box weighing less than it should. The line would stop, and someone had to walk over and yank the defective box out of it, pressing another button when done.
A while later, the CEO decides to have a look at the ROI of the project: amazing results! No empty boxes ever shipped out of the factory after the scales were put in place. Very few customer complaints, and they were gaining market share. “That’s some money well spent!” – he says, before looking closely at the other statistics in the report.
It turns out, the number of defects picked up by the scales was 0 after three weeks of production use. It should’ve been picking up at least a dozen a day, so maybe there was something wrong with the report. He filed a bug against it, and after some investigation, the engineers come back saying the report was actually correct. The scales really weren’t picking up any defects, because all boxes that got to that point in the conveyor belt were good.
Puzzled, the CEO travels down to the factory, and walks up to the part of the line where the precision scales were installed. A few feet before it, there was a $20 desk fan, blowing the empty boxes out of the belt and into a bin. “Oh, that — one of the guys put it there ’cause he was tired of walking over every time the bell rang”, says one of the workers.
$8 million versus $20.
I used to build inspection systems for manufacturing lines and we'd frequently build expensive (not $8M, though) vision systems, E-Testers, etc. just to uninstall them a year or two later when the process or automation guys had found a way to prevent problems from happening in the first place.
Here's another problem mentioned in the article, in fact it's maybe the real problem: the engineers "who were already stretched too thin" probably didn't talk to their operators and technicians often enough. When I was a manufacturing engineer I noticed how much I learned about the stuff I was building by simply hanging around the operators for significant amounts of time. Not only did I get a lot of information about the subtle ways my systems were failing, I also learned that the operators generally felt engineering was ignoring their concerns. Just listening and trying to make the operators' life better earned me so much cooperation from the floor I later had no problems getting them to try out new things for me and providing me feedback on "improvements".
I think this is the reason to build prototypes that you can play with - you really will see things differently. And (hold the hate) obviousness in patent law takes this into account, by evaluating it with respect to the publicly known state of the art - but if you have iterated a few prototypes then you have private information. You got data that no way else has; in addition, new ideas came to you for the next prototype. Each step may have been pretty obvious to you - but from the perspective of someone who had not yet even seen the first prototype in chain, you can seem like a magical genius.
Wind meter on the other side of the conveyer belt and an air horn whenever it drops below a certain level...
I'd have thought a couple of fans checked once a day would provide less failures than are significant.
This doesn't seem like a reason not to propose the system, the alternate proposed solution would have similar failure modes too.
They threw all the resources at it and it was their job to throw those resources and to think long and hard analyzing the problem. And came up with something complex and budgetable and that others would support.
But the guy directly affected probably spent no time thinking about it. Potential solutions probably just popped into his head and he tried them.
Which is probably why extremely decentralized companies like Semco in Brazil (run by Richard Semler, as he wrote about in the book Maverick) do so well. Workers own the processes and share in 39% of the profits. Workers actually create new products and businesses.
The question isn't whether or not to use technology. The question is which technology to use.
An example he gave was designing a timer for a clothes dryer. The user needs to be able to specify how long to try the clothes. The dryer should run for that long and stop.
The standard solution was a mechanical timer. It had a dial. The consumer turned the dial to the appropriate time, the dryer started, and when the timer ticked down the dryer stopped.
Engineers were starting to replace these with digital solutions. The digital solution was a lot more fun for the engineer. He'd get to design some circuitry, maybe use a microprocessor. He'd need a power supply for the electronics. He could have buttons and a nifty LED display. Maybe have preprogrammed drying times.
That's a hell of a lot more fun for the engineer than to just specify sticking some commodity mechanical timer in there like his father and grandfather would have done.
However, the mechanical timer is cheaper, easier to build into the dryer, more reliable, and easier to use for the consumer. There is no advantage whatsoever to the consumer or the dryer company in using the custom digital solution--it serves no purpose other than the entertain the engineer who designs it.
Analog does not scale with complexity nearly as well as digital.
It's only 150 sheets of paper too it's not like it's reams of the stuff (it's just about 1/4 of a ream) otherwise people would be tempted to use a laptop to be 'green'.
Local guy makes it to HN. And I'll be voting in October.
We'd just learned about OO principles and extending classes the week before. After reading the task for the practical I nervously raised my hand, "Would it be acceptable to just extend array list and create methods just named as described but using the existing methods?" The teacher kind of looked at me blankly and said yes.
I was the first person finished, no one else apparently thought of that approach. I'm not a programmer, but given that we'd just discussed this days before it seemed like an obvious solution...
I have a friend in a Python intro whose assignment was to make a program encrypting user input with the Caesar Cipher and (optionally) decrypting, and optionally supporting ROT13 as well. I'm pretty sure the teacher wanted them using ord(), chr(), for loops, etc., but the solution I suggested after my friend tried that way is much simpler:
import string
normal = 'abcd...ABCD...'
caesar = 'defg...DEFG...'
caesar_table = string.maketrans(normal, caesar)
reverse_caesar_table = string.maketrans(caesar, normal)
msg.translate(caesar_table) # for encryption
msg.translate(reverse_caesar_table) # for decryption
Add in string.ascii_letters, string.ascii_uppercase, string.ascii_lowercase, and collections.deque (for string rotation) to generalize the alphabet sets, it was all very simple. And used a completely different 'algorithm' of a translation table that's done in C and performs super-fast, easily handles non-ascii characters (since the translation just leaves them alone), easily generalizable to whatever simple encryption scheme, etc.Of course my friend doesn't want to learn programming therefore everything's complicated and she doesn't remember anything and even after 6 months which ends in a couple weeks I doubt she could do FizzBuzz. :(
cheapo paper notebook: $1
Moleskine: $10
iOS device: $200 - $700 plus opt $30-100/mo (forget cur rates)
Yes, I know you can do more with an iPad/iPhone, obvious, but there is some overlap and paper is arguably better in certain common use cases. Always use the best tool for the job. And I have way greater confidence that the content of my Moleskines will be around in 10 years, than the content of my iPhone/iPad/PC/Mac. And no company can shut me out of it.I have cheapo paper notebooks from ten years ago. I don't understand how Moleskines are better.
That being said, there's nothing better than paper & pencil for note taking.
1. vi (+ opt Dropbox or GitHub for share/synch/ver)
or
2. Moleskine or bulk blank white printer paper (depending on needing quality or cheapness)
With sometimes taking photos of notes or hand-drawn diagrams, as a transitional state before preserving/translating in computer form. But this is rare.I haven't had a use case where LiveScribe would be a net-win and worth it. Teaching? Live virtual classroom?
Unfortunately, it's often the case that no one thinks about it until the "default" way of solving the problem becomes pretty much impossible to use.
(editing this comment after downvoting to add content, and my apologies for being sarcastic and content-free): Effective data presentation, graphic design and such are technology. Showing all the data at once is often much more effective than hiding it in an invisible database.
At least, AFAIK, they work this way in the UK.
Public terminals could be provided for citizens without computers/smart phones/netbooks/tablets/implants/whatever.
And the point of the article was that more technology may not always be the best solution...