Per usual, a line of thinking which struck me as somewhat original, did so only because of my ignorance. Dealing with bills of materials is called logistics, if you start with the stuff and are tasked with putting it to use, that's Reverse logistics.
The definition talks about surplus and returns, the footnotes do include a link to Waste management concepts, but the primary concern is with pre-consumer supply chain issues. The challenge, and prize, is post-consumer.
2014-02-17
IBOM - Inverted Bill Of Materials
I'm forever trying to describe my fixation on the waste stream. I can't get away from the core issue: most all our resources go into stuff, most all stuff ends up in the waste stream. So, after a brief interlude of use, the stuff and energy we extract from the earth is returned to earth, air and water in noxious forms.
Extract -> consume -> discard
Engineering and design which follow that pattern bring us closer to the point where there is not enough left to extract.
We convert the treasures of the earth into stuff, only to use the stuff to degrade the earth.
===============================
A better way to design would look to for materials and resources post-consume, so instead of depleting the earth, it is diverting the stream which degrades the earth.
When I've tried to frame what this might look like, I've ended up with the phrase 'solutions looking for problems', which implies an inversion. The waste stream is where our resources are, the materials we've invested engineering in. We need to extract from there.
===============================
I see a parallel to search technology. An index of a document identifies where words are. An inverted index identifies the documents containing a word. An index is easy; an author can index a book, it takes Google to tell us where all the documents are containing the word we are interested in.
A bill of materials tells us what resources we need to gather.
An inverted bill of materials would tell us what we can build with these resources.
A bill of materials is easy, the limited problem domain of the project defines the materials required. It's indexing a book.
An inverted bill of materials requests familiarity with all projects and processes, and the resources required by them. It's Google scale.
Extract -> consume -> discard
Engineering and design which follow that pattern bring us closer to the point where there is not enough left to extract.
We convert the treasures of the earth into stuff, only to use the stuff to degrade the earth.
===============================
A better way to design would look to for materials and resources post-consume, so instead of depleting the earth, it is diverting the stream which degrades the earth.
When I've tried to frame what this might look like, I've ended up with the phrase 'solutions looking for problems', which implies an inversion. The waste stream is where our resources are, the materials we've invested engineering in. We need to extract from there.
===============================
I see a parallel to search technology. An index of a document identifies where words are. An inverted index identifies the documents containing a word. An index is easy; an author can index a book, it takes Google to tell us where all the documents are containing the word we are interested in.
A bill of materials tells us what resources we need to gather.
An inverted bill of materials would tell us what we can build with these resources.
A bill of materials is easy, the limited problem domain of the project defines the materials required. It's indexing a book.
An inverted bill of materials requests familiarity with all projects and processes, and the resources required by them. It's Google scale.
2012-11-13
Where should I put this stuff?
I just figured out a couple tedious little niggles:
Why doesn't my samba mount line in /etc/fstab work in 12.10 like it did in 12.04?
Why isn't git responding correctly to entries in .gitignore?
They both are annoying to track down, and I won't need either one again for a long time. They are arbitrary bits, don't fit into a visualized construct which would aid memory, so I need to store them outside my little head.
How can I minimize the effort required to retrieve the bits next time they are required?
"Don't bother, that's what google is for" I hear.
Well, it took a good 15 minutes of googling and testing to resolve, it could easily take longer next time ... boring ... and, exactly this problem is one I'm most interested in addressing.
Things I've tried:
- my 'docubi' gmail account using plus addressing: docubi+git at ...
- A Leo node
- bookmarking (doesn't work here, it took trials and errors on top of found info)
- Zotero: powerful, can create local copy of info page, associate notes or files
- Stackoverflow
and many others over the years.
How best to combine ease of entry and retrieval with stability and flexibility?
I think using this here blog dealy is a step in the right direction, got your googleability, ownership with shareability, API for eventual automation of CRUD ...
So, as is my habit, next step is branding for differentiation. (try searching for info on the 'Processing' language, 'Go' makes a bit of sense given the convention of 'golang' but ... puh-leeze)
So, what cutesy invention is called for?
SAQ: Seldom Asked Questions (frequent ones are the ones I need to commit to memory) about 9,710,000 results
INFRAQ: INFRequently Asked Questions: about 40,000 hits
RARAQ: RARely Asked Questions: about 7.950 results
eight thousand results can be rounded to 0
google images RARAQ: about 1,480 mostly people, a guitar, anim, a white mouse that doesn't appear until the blank thumbnail is clicked ...
raraq dot com not registered ... resist ... urge ... to ... squat ...
They both are annoying to track down, and I won't need either one again for a long time. They are arbitrary bits, don't fit into a visualized construct which would aid memory, so I need to store them outside my little head.
How can I minimize the effort required to retrieve the bits next time they are required?
"Don't bother, that's what google is for" I hear.
Well, it took a good 15 minutes of googling and testing to resolve, it could easily take longer next time ... boring ... and, exactly this problem is one I'm most interested in addressing.
Things I've tried:
- my 'docubi' gmail account using plus addressing: docubi+git at ...
- A Leo node
- bookmarking (doesn't work here, it took trials and errors on top of found info)
- Zotero: powerful, can create local copy of info page, associate notes or files
- Stackoverflow
and many others over the years.
How best to combine ease of entry and retrieval with stability and flexibility?
I think using this here blog dealy is a step in the right direction, got your googleability, ownership with shareability, API for eventual automation of CRUD ...
So, as is my habit, next step is branding for differentiation. (try searching for info on the 'Processing' language, 'Go' makes a bit of sense given the convention of 'golang' but ... puh-leeze)
So, what cutesy invention is called for?
SAQ: Seldom Asked Questions (frequent ones are the ones I need to commit to memory) about 9,710,000 results
INFRAQ: INFRequently Asked Questions: about 40,000 hits
RARAQ: RARely Asked Questions: about 7.950 results
eight thousand results can be rounded to 0
google images RARAQ: about 1,480 mostly people, a guitar, anim, a white mouse that doesn't appear until the blank thumbnail is clicked ...
raraq dot com not registered ... resist ... urge ... to ... squat ...
2012-02-14
Woohoo, getting published
One of the Gumpagraphs
will be on the 'Working class consciousness' card
of the Public Sphere 'Pattern Language' project,
http://publicsphereproject.org/drupal/node/211
It's available from wikimedia.org
http://commons.wikimedia.org/wiki/File:Well_repair.JPG
I'm tickled they picked it.
will be on the 'Working class consciousness' card
of the Public Sphere 'Pattern Language' project,
http://publicsphereproject.org/drupal/node/211
It's available from wikimedia.org
http://commons.wikimedia.org/wiki/File:Well_repair.JPG
I'm tickled they picked it.
2010-09-08
Before there were maps
Back then, I would describe the place I traveled to with a linear narrative. I would describe what I saw as I walked along ... a grove of trees to my left, further along a cliff to my right ...
Frustration with communicating via linear narrative resulted in picking up a stick and making marks representing a visual model of the landscape in my head. These scratches evolved into the world of cartography and GIS we now enjoy.
We deal with a lot of complexity today, cognitive complexity, complexity rooted in relationships between concepts. We explain these complex relationships via linear narrative, describing a journey along a path, pointing out the landmarks. The audience must build this cognitive landscape, registering each component and they way each connects to each other. Given the difficulty of this exercise, many get lost along the way.
We need maps, visualizations which place the concepts in space such their relation to each other is understood at a glance.
This is a fairly well known concept, and currently implemented as marks with a stick. My conviction is that it will evolve into tools which spatialize knowledge such that more is more quickly understood by more of us.
Frustration with communicating via linear narrative resulted in picking up a stick and making marks representing a visual model of the landscape in my head. These scratches evolved into the world of cartography and GIS we now enjoy.
We deal with a lot of complexity today, cognitive complexity, complexity rooted in relationships between concepts. We explain these complex relationships via linear narrative, describing a journey along a path, pointing out the landmarks. The audience must build this cognitive landscape, registering each component and they way each connects to each other. Given the difficulty of this exercise, many get lost along the way.
We need maps, visualizations which place the concepts in space such their relation to each other is understood at a glance.
This is a fairly well known concept, and currently implemented as marks with a stick. My conviction is that it will evolve into tools which spatialize knowledge such that more is more quickly understood by more of us.
2010-04-24
On linking
The Unix filesystem concept of ``links`` is quite wonderful. I remember a couple conversations with my father which touched on the question "is anything possible". For some reason my example to prove that, in fact, not all things are possible, was to state that I can't be both here, downstairs, and upstairs at the same time. It seemed irrefutable that a thing can only be in one place at one time.
That may or may not be true, but filesystem links offer cool magic.
However, the quality of explanans offered by Unix could be improved, and
the Python equivilent is flat out confusing.
$ man ln
...
SYNOPSIS
ln [OPTION]... [-T] TARGET LINK_NAME (1st form)
ln [OPTION]... TARGET (2nd form)
ln [OPTION]... TARGET... DIRECTORY (3rd form)
ln [OPTION]... -t DIRECTORY TARGET... (4th form)
...
Target and link_name are reasonable names, although a bit of a mixed metaphor, target implies an arrow or bullet, not link name. I also don't like the order, I approach the link and arrive at the target, why put the target first?
Python is much worse:
>>> help (os.symlink)
symlink(...) symlink(src, dst)
Create a symbolic link pointing to src named dst.
Huh? the destination points to the source? Just Plain Nuts, Don't Make Sense, Oh Puh Leaze.
***********************************************************
I've been for some time futzing with code to wrap link management, eventually want a buildout recipe which describes link wrangling, particularly the ``gather`` idiom, which moves a file to a managed location, replacing it with a link. Useful for versioning configuration.
I like the following spelling to describe links and files:
['ln1', 'thefile'] or ['ln3', 'ln2', 'ln1', 'thefile'] which could also look like: "ln3 -> ln2 -> ln1 -> thefile"
I think it would make me happy to specify links this way, both in arguments and and reports.
That may or may not be true, but filesystem links offer cool magic.
However, the quality of explanans offered by Unix could be improved, and
the Python equivilent is flat out confusing.
$ man ln
...
SYNOPSIS
ln [OPTION]... [-T] TARGET LINK_NAME (1st form)
ln [OPTION]... TARGET (2nd form)
ln [OPTION]... TARGET... DIRECTORY (3rd form)
ln [OPTION]... -t DIRECTORY TARGET... (4th form)
...
Target and link_name are reasonable names, although a bit of a mixed metaphor, target implies an arrow or bullet, not link name. I also don't like the order, I approach the link and arrive at the target, why put the target first?
Python is much worse:
>>> help (os.symlink)
symlink(...) symlink(src, dst)
Create a symbolic link pointing to src named dst.
Huh? the destination points to the source? Just Plain Nuts, Don't Make Sense, Oh Puh Leaze.
***********************************************************
I've been for some time futzing with code to wrap link management, eventually want a buildout recipe which describes link wrangling, particularly the ``gather`` idiom, which moves a file to a managed location, replacing it with a link. Useful for versioning configuration.
I like the following spelling to describe links and files:
['ln1', 'thefile'] or ['ln3', 'ln2', 'ln1', 'thefile'] which could also look like: "ln3 -> ln2 -> ln1 -> thefile"
I think it would make me happy to specify links this way, both in arguments and and reports.
2010-01-01
That is so wrong!
Since I seem to be settling on 'Gumpa' as my primary brand* it seems only right to act my age and channel some codger energy. Hey you kids, GET OFF MY LAWN. This is my first post which will be tagged TISW.
The metaphors used to discuss hierarchal data organization are SO wrong.
Take the file system.
It's often described as a tree, a tree with the root at the top, you descend to the files, which I've seen analagized as leaves.
Im my world trees don't have roots at the top and leaves at the bottom, in my world 'to descend' is to go down.
No wonder I've always felt somewhat slow in understanding explanations of file hierarchies, a small matter of their up being my down and visa-versa. Not to mention that file systems are not tree-like, they are container-like. Files are 'in' directories, not 'attached to' as leaves are to a branch.
I don't currently have suggestions for improvements, but it seems like it should be possible to provide a mental image that doesn't require hanging upside down to resolve the cognitive dischord.
Maybe the original work on this was done by bat-geeks at night, when they are upside down. No, they tend to be in caves, no trees in caves. I Know! it was the sloths. Of course, sloths live in trees, upside down, trees with roots at the top would make perfect sense to them.
Darn you sloths, TISW
* TODO acronymize gumpa
The metaphors used to discuss hierarchal data organization are SO wrong.
Take the file system.
It's often described as a tree, a tree with the root at the top, you descend to the files, which I've seen analagized as leaves.
Im my world trees don't have roots at the top and leaves at the bottom, in my world 'to descend' is to go down.
No wonder I've always felt somewhat slow in understanding explanations of file hierarchies, a small matter of their up being my down and visa-versa. Not to mention that file systems are not tree-like, they are container-like. Files are 'in' directories, not 'attached to' as leaves are to a branch.
I don't currently have suggestions for improvements, but it seems like it should be possible to provide a mental image that doesn't require hanging upside down to resolve the cognitive dischord.
Maybe the original work on this was done by bat-geeks at night, when they are upside down. No, they tend to be in caves, no trees in caves. I Know! it was the sloths. Of course, sloths live in trees, upside down, trees with roots at the top would make perfect sense to them.
Darn you sloths, TISW
* TODO acronymize gumpa
Subscribe to:
Posts (Atom)
