Foveon invented a better sensor, but then had trouble interesting camera manufacturers in the technology.
Instead of needing to convince camera manufacturers to embed the technology in their cameras, the manufacturers could be circumvented by manufacturing Foveon-based digital camera backs for popular SLRs. This would be considerably simpler than manufacturing entire cameras.
Note: This idea turns out to be moot, because Foveon was acquired by Sigma. A disappointing outcome for a technology that was going to obsolesce all computers, cameras, and cellphones.
Sunday, May 30, 2010
French Press With Lever
Coffee made in a French press is delicious, particularly when the grounds are ground very fine.
But when ground very fine, the grounds make it almost impossible to press down on the piston. The palm of the hand winds up bruised from the pressure.
The effort could be greatly reduced by adding a lever.
One end of the lever would attach to a hinge on one size of the cylinder, the piston would connect to the lever with a rotating pin, and the preparer would press down on the long end of the lever to drive the piston into the cylinder.
The lever and pin would be easy to remove, in order to clean the press.
But when ground very fine, the grounds make it almost impossible to press down on the piston. The palm of the hand winds up bruised from the pressure.
The effort could be greatly reduced by adding a lever.
One end of the lever would attach to a hinge on one size of the cylinder, the piston would connect to the lever with a rotating pin, and the preparer would press down on the long end of the lever to drive the piston into the cylinder.
The lever and pin would be easy to remove, in order to clean the press.
Squirrel-proof Squirrel Feeder
I'm looking at our fourth squirrel feeder.
It is lying on the ground, the squirrels having chewed through the strap that was holding it up on a tree trunk. The top is halfway chewed through--and it's made of tough plastic.
The previous squirrel feeders fared no better. One made from wood was reduced to sawdust, another was knocked down and crushed by a car, and so forth.
It might require titanium-vanadium alloy, but there must be some way to make a squirrel feeder that can't be destroyed by squirrels.
It is lying on the ground, the squirrels having chewed through the strap that was holding it up on a tree trunk. The top is halfway chewed through--and it's made of tough plastic.
The previous squirrel feeders fared no better. One made from wood was reduced to sawdust, another was knocked down and crushed by a car, and so forth.
It might require titanium-vanadium alloy, but there must be some way to make a squirrel feeder that can't be destroyed by squirrels.
Sunday, April 25, 2010
Cat Toys That Work
You come home from the pet store with some new toys for your cat.
The cat is not interested.
Later you hear a racket, and discover that the cat is going nuts batting a button around and pouncing on it.
Why not create a product that consists of toys that cats will actually play with?
The product comes in a cardboard box big enough for a cat to get inside.
That's the first toy in the set.
Open the box, and take out a paper bag with a hole cut in the bottom.
That's the second toy.
Empty the paper bag and dump out:
Note: There is at least one commercial cat toy that works:
http://www.go-cat.com/images/Da_Bird_with_Rod.jpg
It's been described as "cat fishing". Highly recommended.
The Galkie Kitty Tease also works great for this, but it is no longer manufactured.
The cat is not interested.
Later you hear a racket, and discover that the cat is going nuts batting a button around and pouncing on it.
Why not create a product that consists of toys that cats will actually play with?
The product comes in a cardboard box big enough for a cat to get inside.
That's the first toy in the set.
Open the box, and take out a paper bag with a hole cut in the bottom.
That's the second toy.
Empty the paper bag and dump out:
- Roll of toilet paper.
- Pen, used, with cap.
- Tear-off ring from around the bottom of the plastic cap to a one-gallon plastic milk container.
- Crumpled ball of crackly paper.
- Ping-pong ball.
- Walnut.
- Wooden spool from a spool of thread.
- Metal bottlecap, bent across centerline, included angle of 120 degrees.
- Ball of twine.
- Twist tie.
- Medium-sized hard plastic cap from plastic medicine bottle.
- Catnip mouse.
Note: There is at least one commercial cat toy that works:
http://www.go-cat.com/images/Da_Bird_with_Rod.jpg
It's been described as "cat fishing". Highly recommended.
The Galkie Kitty Tease also works great for this, but it is no longer manufactured.
Japanese Beer That Doesn't Taste Like Molson
Once upon a time, Sapporo and Asahi were brewed in Japan.
Then NAFTA passed.
Now Sapporo and Asahi are brewed in Canada, and brought into the United States under the trade agreement.
Which is great for globalization, except that now Sapporo and Asahi taste like Molson instead of tasting like Sapporo and Asahi.
Molson was already widely available in the United States.
What's not widely available in the United States is Japanese beer brewed in Japan.
There is pent-up demand for a solution to this problem: http://chowhound.chow.com/topics/439245.
Then NAFTA passed.
Now Sapporo and Asahi are brewed in Canada, and brought into the United States under the trade agreement.
Which is great for globalization, except that now Sapporo and Asahi taste like Molson instead of tasting like Sapporo and Asahi.
Molson was already widely available in the United States.
What's not widely available in the United States is Japanese beer brewed in Japan.
There is pent-up demand for a solution to this problem: http://chowhound.chow.com/topics/439245.
Sunday, April 18, 2010
Sterile Pop-top Cans
It's hot, and you're on vacation.
You're sitting in a camp chair, feeling pretty darn good.
You reach into the cooler and pull out a can of soda.
You are about to pull the ring to open the can, when you notice that the groove around the rim of the top is smudged with black crud.
Yuck! What is that stuff?!?
That "stuff" is a mixture of rat feces (from the warehouse), road grime and diesel soot (from transportation), and bugs (from the shop at the dock where you bought the soda).
Ugh!
You look around for a solution, but this is a campsite--it doesn't have running water.
You could try to wash off the can in the lake, but who knows what might be swimming in the lake. Didn't you read just last week that hikers are contracting Cryptosporidium from meltwater in the Rockies? Is lakewater safe?
With a sigh, you swirl the can upside down in the meltwater at the bottom of the cooler (hey, at least the ice was made from chlorinated water, or was it?), wipe off the top of the can with your shirt, and hope for the best.
It doesn't have to be this way.
What we need is an improved canning machine. It would do everything current canning machines do, but would add a tough aluminum-foil cover over the top 1" of the sides of the can, and the entire top of the can. As long as the foil was not torn, the surfaces under the foil would be sterile.
To open this improved can, you would tear the foil to expose the pull ring and drinking area, much like tearing the foil on a champagne bottle exposes the wire that holds the cork in place. After tearing the foil, you would fold it away from the drinking area, like the petals of a flower (up, to the sides, and down), exposing the still-sterile interior. Then pull the ring, and drink.
The canning machine would melt the aluminum foil to the side of the can, so the foil and can are a single unit. This would keep the foil from becoming litter, and would make the can/foil unit easy to recycle together.
Canners and bottlers are always jockeying for position. Cans are lighter and easier to recycle. But bottled liquids taste better than canned liquids, and screw-tops on bottles expose sterile drinking surfaces. Adding sterile drinking surfaces to cans could tilt the advantage back to canners, so they should be eager to upgrade to the new canning machines. In addition, if one beverage maker insists on sterile cans, the rest of them will have to do so as well or risk liability.
While working to land the first major contract, the new canning machines could be used to make cans safe for high-risk patients, and for infants.
You're sitting in a camp chair, feeling pretty darn good.
You reach into the cooler and pull out a can of soda.
You are about to pull the ring to open the can, when you notice that the groove around the rim of the top is smudged with black crud.
Yuck! What is that stuff?!?
That "stuff" is a mixture of rat feces (from the warehouse), road grime and diesel soot (from transportation), and bugs (from the shop at the dock where you bought the soda).
Ugh!
You look around for a solution, but this is a campsite--it doesn't have running water.
You could try to wash off the can in the lake, but who knows what might be swimming in the lake. Didn't you read just last week that hikers are contracting Cryptosporidium from meltwater in the Rockies? Is lakewater safe?
With a sigh, you swirl the can upside down in the meltwater at the bottom of the cooler (hey, at least the ice was made from chlorinated water, or was it?), wipe off the top of the can with your shirt, and hope for the best.
It doesn't have to be this way.
What we need is an improved canning machine. It would do everything current canning machines do, but would add a tough aluminum-foil cover over the top 1" of the sides of the can, and the entire top of the can. As long as the foil was not torn, the surfaces under the foil would be sterile.
To open this improved can, you would tear the foil to expose the pull ring and drinking area, much like tearing the foil on a champagne bottle exposes the wire that holds the cork in place. After tearing the foil, you would fold it away from the drinking area, like the petals of a flower (up, to the sides, and down), exposing the still-sterile interior. Then pull the ring, and drink.
The canning machine would melt the aluminum foil to the side of the can, so the foil and can are a single unit. This would keep the foil from becoming litter, and would make the can/foil unit easy to recycle together.
Canners and bottlers are always jockeying for position. Cans are lighter and easier to recycle. But bottled liquids taste better than canned liquids, and screw-tops on bottles expose sterile drinking surfaces. Adding sterile drinking surfaces to cans could tilt the advantage back to canners, so they should be eager to upgrade to the new canning machines. In addition, if one beverage maker insists on sterile cans, the rest of them will have to do so as well or risk liability.
While working to land the first major contract, the new canning machines could be used to make cans safe for high-risk patients, and for infants.
Universal Remote With Programmable Button Labels
When a remote control for a piece of equipment is purpose-built for that device, the remote's buttons have functions that exactly match the functions of the device, with labels that clearly indicate those functions, and in many cases with a shape that represents the function (for example, a forward button in the shape of a right arrow). In addition, the buttons provide tactile feedback.
It's hard to beat those ergonomics, except that the coffee table winds up cluttered with a bunch of dedicated remotes.
To consolidate the remotes into a single remote, users turn to universal remotes.
Universal remotes fall into three categories:
If a universal remote has only hard buttons, then it must have a gazillion of them in order to support every possible function. This degrades the ergonomics of the remote because now it is a giant unwieldy wand cluttered with way too many buttons, only a small subset of which apply to any particular piece of equipment.
In addition, because there are always functions for which no button exists on the remote, manufacturers have to provide generic buttons (F1, Spare2, etc.), but then the user has to remember what functions are assigned to the generic buttons, because the labels are of no help, nor are the button shapes.
If a universal remote has a touchscreen/display, this allows manufacturers to have hard buttons for the most-common functions, with the touchscreen/display handling whatever is missing.
But this also degrades the ergonomics of the remote. Touchscreens don't provide tactile feedback, and they're not as crisp as hard buttons. (Users with touchscreen remotes will tell you they love soft buttons, but what they're really saying is they are willing to put up with soft buttons if it means they only have to have one remote on the coffee table.)
Manufacturers try to perfect universal remotes by varying the ratio of hard buttons to displayed buttons, trying to find the right mix. The problem is, there isn't really a right mix. Something is always a bit off.
But there is a fourth approach. Instead of having a touchscreen/display in order to have a way to define "buttons" that aren't represented by the available hard buttons, make each hard button a little display itself, and use that display to change the label on the button.
There are already keyboards that do this, for example http://www.artlebedev.com/everything/optimus and http://www.unitedkeys.com. There's no reason it wouldn't work for remotes as well.
Another advantage of this approach is that it doesn't need a backlight.
The remote could still have a display for miscellaneous information, but now it could be just a few lines of text, and wouldn't have to be a touchscreen.
This approach doesn't solve the button-shape problem, but perhaps the set of buttons that benefit from having a special shape is small enough that they could be in the set of hard buttons from the start: skip left, rewind, play, forward, skip forward, up, down, left, right, page up, page down, channel up, channel down, volume up, volume down, maybe a few others (jog shuttle--does anyone still use that?).
It's hard to beat those ergonomics, except that the coffee table winds up cluttered with a bunch of dedicated remotes.
To consolidate the remotes into a single remote, users turn to universal remotes.
Universal remotes fall into three categories:
- Assignable hard buttons with permanent labels, and no display.
- Assignable hard buttons with permanent labels, plus a touchscreen/display.
- No hard buttons, just a touchscreen/display.
If a universal remote has only hard buttons, then it must have a gazillion of them in order to support every possible function. This degrades the ergonomics of the remote because now it is a giant unwieldy wand cluttered with way too many buttons, only a small subset of which apply to any particular piece of equipment.
In addition, because there are always functions for which no button exists on the remote, manufacturers have to provide generic buttons (F1, Spare2, etc.), but then the user has to remember what functions are assigned to the generic buttons, because the labels are of no help, nor are the button shapes.
If a universal remote has a touchscreen/display, this allows manufacturers to have hard buttons for the most-common functions, with the touchscreen/display handling whatever is missing.
But this also degrades the ergonomics of the remote. Touchscreens don't provide tactile feedback, and they're not as crisp as hard buttons. (Users with touchscreen remotes will tell you they love soft buttons, but what they're really saying is they are willing to put up with soft buttons if it means they only have to have one remote on the coffee table.)
Manufacturers try to perfect universal remotes by varying the ratio of hard buttons to displayed buttons, trying to find the right mix. The problem is, there isn't really a right mix. Something is always a bit off.
But there is a fourth approach. Instead of having a touchscreen/display in order to have a way to define "buttons" that aren't represented by the available hard buttons, make each hard button a little display itself, and use that display to change the label on the button.
There are already keyboards that do this, for example http://www.artlebedev.com/everything/optimus and http://www.unitedkeys.com. There's no reason it wouldn't work for remotes as well.
Another advantage of this approach is that it doesn't need a backlight.
The remote could still have a display for miscellaneous information, but now it could be just a few lines of text, and wouldn't have to be a touchscreen.
This approach doesn't solve the button-shape problem, but perhaps the set of buttons that benefit from having a special shape is small enough that they could be in the set of hard buttons from the start: skip left, rewind, play, forward, skip forward, up, down, left, right, page up, page down, channel up, channel down, volume up, volume down, maybe a few others (jog shuttle--does anyone still use that?).
Synthetic-tooth Pool Balls
The balls used for billiards, snooker, and pool used to be made from ivory.
With a dwindling supply of elephants, manufacturers turned to plastic as a replacement.
Plastic is superior to ivory in many ways: it isn't as fragile, it doesn't require humidity and temperature control (ivory balls were notorious for cracking if they got too dry), it's less expensive, and it doesn't contribute to the extinction of a species.
But plastic suffers from being too slick.
If you drag a natural pearl gently over the face of one of your front teeth, you will feel a grittiness. That's caused by the surface of the pearl being rough (at microscopic dimensions), and the roughness matching the roughness of your tooth. Similarly, if you drag a piece of ivory over your tooth, it feels rough.
If you drag a plastic pearl over the same spot, it just slides. There is no grip.
Billiards, snooker, and pool require fine cuts--shots where the cue ball and the object ball barely touch. When the balls are slick, there is a limit to how fine a cut can be before the contact patch slips instead of gripping. When the contact patchs slips, spin is not transferred correctly from the cue ball to the object ball, and the shot suffers through no fault of the player.
What we need is balls with a surface that is microscopically rough, like ivory. This surface should not wear off, or wear down. Perhaps it could be implemented by embedding fine particles of something hard and gritty in the plastic.
This seems like the kind of thing 3M could knock out in an afternoon.
With a dwindling supply of elephants, manufacturers turned to plastic as a replacement.
Plastic is superior to ivory in many ways: it isn't as fragile, it doesn't require humidity and temperature control (ivory balls were notorious for cracking if they got too dry), it's less expensive, and it doesn't contribute to the extinction of a species.
But plastic suffers from being too slick.
If you drag a natural pearl gently over the face of one of your front teeth, you will feel a grittiness. That's caused by the surface of the pearl being rough (at microscopic dimensions), and the roughness matching the roughness of your tooth. Similarly, if you drag a piece of ivory over your tooth, it feels rough.
If you drag a plastic pearl over the same spot, it just slides. There is no grip.
Billiards, snooker, and pool require fine cuts--shots where the cue ball and the object ball barely touch. When the balls are slick, there is a limit to how fine a cut can be before the contact patch slips instead of gripping. When the contact patchs slips, spin is not transferred correctly from the cue ball to the object ball, and the shot suffers through no fault of the player.
What we need is balls with a surface that is microscopically rough, like ivory. This surface should not wear off, or wear down. Perhaps it could be implemented by embedding fine particles of something hard and gritty in the plastic.
This seems like the kind of thing 3M could knock out in an afternoon.
Power-outage Power Cutouts For Electronics
We live in the Santa Cruz mountains, and the power up here is bad (overhead lines, trees that fall down, etc.). So we tend to get power outages and brownouts, particularly in the winter.
When the power goes out and comes back on, some of our electronic devices turn back on. In the case of a plasma TV, this is bad, because we might be away from the house when it happens, and an image could be burned into the TV.
We tried to find a power conditioner that would turn off if it encountered an outage, requiring a manual reset to turn it back on. No such conditioner seemed to be available.
A UPS could be used for this, but they are too big to fit in the wall behind a plasma TV, and generally not a good fit for this application.
X10 devices used to fail open on power-off, but now they restore their previous state when powered back up.
We wound up having to make our own with a RIB01P DPDT relay from functionaldevices.com:
a PAC521P from chiefmfg.com:
and a momentary rocker switch typically used for garbage disposals:
We were given superb pre-sales support by the engineers at Functional Devices, including a circuit diagram:
But it really shouldn't have been that difficult.
Power conditioners, both in-wall and rack-mount, should have a mode where they don't restore power unless reset.
For rack-mount, the reset could be done with a pushbutton, IR, RS-232, X10, or Z-Wave.
For in-wall, a button would be difficult to reach, so the reset would have to be done with IR, RS-232, X10, or Z-Wave.
When the power goes out and comes back on, some of our electronic devices turn back on. In the case of a plasma TV, this is bad, because we might be away from the house when it happens, and an image could be burned into the TV.
We tried to find a power conditioner that would turn off if it encountered an outage, requiring a manual reset to turn it back on. No such conditioner seemed to be available.
A UPS could be used for this, but they are too big to fit in the wall behind a plasma TV, and generally not a good fit for this application.
X10 devices used to fail open on power-off, but now they restore their previous state when powered back up.
We wound up having to make our own with a RIB01P DPDT relay from functionaldevices.com:
a PAC521P from chiefmfg.com:
and a momentary rocker switch typically used for garbage disposals:
We were given superb pre-sales support by the engineers at Functional Devices, including a circuit diagram:
But it really shouldn't have been that difficult.Power conditioners, both in-wall and rack-mount, should have a mode where they don't restore power unless reset.
For rack-mount, the reset could be done with a pushbutton, IR, RS-232, X10, or Z-Wave.
For in-wall, a button would be difficult to reach, so the reset would have to be done with IR, RS-232, X10, or Z-Wave.
Legacy Code Conversion Service
Companies that have legacy code often want to convert the code. They want it to conform to modern standards (for example, web services, JEE, etc.). They want it to be easier to work with (structured, layered, Mavenized, etc.). They want it to interoperate better with other internal and external systems.
Companies that have legacy code often have made an effort to replace, rewrite, or refactor the code. Often these efforts were paid for by reducing funding for new-product development. Often those efforts have failed, leaving them with the same legacy code they started with, behind in the market, and frustrated.
A consulting firm could specialize in making legacy-code problems go away for companies, for a handsome fee.
The consulting firm would not need to advertise. Contracts would come to the firm through referrals from CEOs, CIOs, CTOs, and boards of directors of companies that had their legacy-code problems fixed by the consulting firm.
The consulting firm would not need to be big. It could consist of a small team of experts, working remotely. There wouldn't even have to be a central office.
The consulting firm's engineers would use powerful analysis and refactoring tools running on 64-bit machines with huge amounts of memory. Some of the tools could be from open-source projects, and others could be developed internally. The tools would not have to be polished, with nice GUIs. They could be command-line based. They would just need to do the job.
The consulting firm would only need two or three contracts at a time to be making money hand over fist.
Because maintaining source-control history while massively refactoring code is a pain, the consulting firm should charge extra (a lot extra) to do that.
The best thing about this idea is that a consulting firm could describe in public exactly what it plans to do, and how it plans to do it, and nobody would compete with the firm. Even if somebody did compete, there would be more than enough work to go around.
Why is that? Because engineers don't want to work with legacy code. Legacy code is a dead end, they think. Cream-of-the crop engineers especially don't want to work with legacy code. They want to create. They are artists. Maestros.
Competent engineers who are willing to work with legacy code are rare, which leaves the field pretty much wide open.
Which is odd, really. There is a lot more legacy code in the world than new code (and new code has a way of turning into legacy code over time). Most code is legacy code. And it can be quite satisfying to convert troublesome code into good code.
Companies that have legacy code often have made an effort to replace, rewrite, or refactor the code. Often these efforts were paid for by reducing funding for new-product development. Often those efforts have failed, leaving them with the same legacy code they started with, behind in the market, and frustrated.
A consulting firm could specialize in making legacy-code problems go away for companies, for a handsome fee.
The consulting firm would not need to advertise. Contracts would come to the firm through referrals from CEOs, CIOs, CTOs, and boards of directors of companies that had their legacy-code problems fixed by the consulting firm.
The consulting firm would not need to be big. It could consist of a small team of experts, working remotely. There wouldn't even have to be a central office.
The consulting firm's engineers would use powerful analysis and refactoring tools running on 64-bit machines with huge amounts of memory. Some of the tools could be from open-source projects, and others could be developed internally. The tools would not have to be polished, with nice GUIs. They could be command-line based. They would just need to do the job.
The consulting firm would only need two or three contracts at a time to be making money hand over fist.
Because maintaining source-control history while massively refactoring code is a pain, the consulting firm should charge extra (a lot extra) to do that.
The best thing about this idea is that a consulting firm could describe in public exactly what it plans to do, and how it plans to do it, and nobody would compete with the firm. Even if somebody did compete, there would be more than enough work to go around.
Why is that? Because engineers don't want to work with legacy code. Legacy code is a dead end, they think. Cream-of-the crop engineers especially don't want to work with legacy code. They want to create. They are artists. Maestros.
Competent engineers who are willing to work with legacy code are rare, which leaves the field pretty much wide open.
Which is odd, really. There is a lot more legacy code in the world than new code (and new code has a way of turning into legacy code over time). Most code is legacy code. And it can be quite satisfying to convert troublesome code into good code.
Saturday, April 17, 2010
Super-tool For Refactoring
One of our projects at work involves refactoring the code into layers (UI, business logic, data, service, and so forth), and then vertically into components within each layer.
In many cases, the work involves mechanically moving classes to their correct layer, splitting classes, moving methods, and sometimes adding listeners or Spring initialization to remove upward dependencies.
The work is tedious. There's nothing particularly creative about it. It's just a slog through a million-plus lines of code.
Refactoring tools are available, but they are basically tedium reducers. They automate mechanical transformations at the lexical level, but they don't understand anything.
I want more. A lot more.
I want semantics instead of syntax.
Somewhere in the Platonic realm, our program exists in the form of its true, perfect nature. I want refactoring tools that make it easy to move a program towards its ideal form.
Imagine standing in front of a big display like the one in Minority Report, lighting up a long sequence of nested if/then/else/case statements, and selecting "Infer Rules Engine".
Imagine pointing to other sections of the code and being able to select operations such as:
"Infer State Machine"
"Recode Without Side Effects"
"Remove Programming By Exception"
"Replace Static Initialization With Spring"
"Make Stateless"
"Extract Declarative Configuration"
"Replace With Annotation"
"Manage In Cache"
"Substitute Composition For Inheritance"
"Reimplement With [Name of GOF Pattern]"
"Extract To Presentation"
"Canonicalize To JEE"
"Promote To Web Service"
"Internationalize"
"Make Testable"
all while maintaining source-control history.
(Moved from http://jimshowalter.blogspot.com/2010/03/one-of-our-projects-at-work-involves.html.)
In many cases, the work involves mechanically moving classes to their correct layer, splitting classes, moving methods, and sometimes adding listeners or Spring initialization to remove upward dependencies.
The work is tedious. There's nothing particularly creative about it. It's just a slog through a million-plus lines of code.
Refactoring tools are available, but they are basically tedium reducers. They automate mechanical transformations at the lexical level, but they don't understand anything.
I want more. A lot more.
I want semantics instead of syntax.
Somewhere in the Platonic realm, our program exists in the form of its true, perfect nature. I want refactoring tools that make it easy to move a program towards its ideal form.
Imagine standing in front of a big display like the one in Minority Report, lighting up a long sequence of nested if/then/else/case statements, and selecting "Infer Rules Engine".
Imagine pointing to other sections of the code and being able to select operations such as:
"Infer State Machine"
"Recode Without Side Effects"
"Remove Programming By Exception"
"Replace Static Initialization With Spring"
"Make Stateless"
"Extract Declarative Configuration"
"Replace With Annotation"
"Manage In Cache"
"Substitute Composition For Inheritance"
"Reimplement With [Name of GOF Pattern]
"Extract To Presentation"
"Canonicalize To JEE"
"Promote To Web Service"
"Internationalize"
"Make Testable"
all while maintaining source-control history.
(Moved from http://jimshowalter.blogspot.com/2010/03/one-of-our-projects-at-work-involves.html.)
Subscribe to:
Posts (Atom)