My kneejerk response is to tell you not to worry your pretty little head about these questions, since unless you're working on aerospace, medical or government contract code (written in Ada?), this obsession with CMMI will soon put your small company out of business and you'll be able to get a real job at a company that's focused on making products instead of "deliverables".
Anyway - the answer to "what is the most important part" is - usability BY THE PEOPLE WHO HAVE TO USE IT. I am involved with some groups who are CMMI level [x], reluctantly and for absolutely no useful purpose (by the time they finish these paperwork deliverables, their product is obsolete). The first step is for requirements to be entered, and this requires cooperation from non-engineers who are used to drafting a free-form Word document, and who frequently work offsite and/or with no live Internet connection, e.g. while on a plane. Note the implication here - for usability by the target people, it should be possible to export, edit offline and reimport data with no loss of audit trail.
Further, all of these systems that I've evaluated - I'm most familiar with Contour - impose a structure on the input, and it's usually configurable by means of templates. MAKE SURE your entry template is designed/approved by the [typically marketing] folks who are expected to kick the project off, otherwise you'll wind up with a spec containing everything in the first category box and everything else left blank. I've never seen a CMMI template that was properly structured for non-engineers, btw; they're all designed by CS majors or, worse, documentation control specialists. And without buy-in from those people at the start, you're immediately screwed (unless this is purely a for-show exercise, where auditors, if any, are only looking for some text in every field - in which case go ahead and paste in lorem ipsum and get on with your actual work).
I also suggest you hire someone whose sole job is to create and update this paperwork, because it is a spiraling black hole of unproductivity for any project that operates on modern development cycles (it only works with the waterfall model; too bad if you're doing a large consumer electronics project that needs to be released before your chipset goes obsolete and the world moves on) and by having a specific person (persons) assigned to it, you can very easily put a numerical value on exactly how much it is costing you, which might help to kill it before it sinks you.
May flights of angels sing thee to thy rest...
The allowed distance is not a function of base station Tx power, it's a function of signal propagation time. You can easily reprogram all the towers not to permit connections to phones > (x) meters away by simply saying "if the phone requires a timebase correction of more than (y) microseconds, hand over to a neighboring tower". (All GSM towers already have such a limit implicitly - there are so many TDMA slots, and no more). This works better on CDMA systems than TDMA because "audible but not in-range" cells just become part of the noise floor.
But anyway - Nobody has done anything with the analog TV spectrum yet. This is where we'll see an expansion of available bandwidth. And there are other non-cellular technologies that would deliver the data people crave; a system for handing over seamlessly between cellular and WiFi for instance.
For the internal case, a bulletin board style web-based system's PM facility will provide you with delivery and confirmation of receipt. Or you could go the whole hog and install PDM software like Agile... but I doubt you want to do that;)
For the external case, I suggest using fillable PDF documents, with a secure signature generated by the addressee (this is instant and free in Adobe Reader).
At my Very Large Corporation our developers need admin rights because we are constantly tinkering with special hardware, updating drivers, running software that's not supported by anyone (obsolete compilers and debugging tools in particular), etc. So we have admin rights.
However there are some corners of the org where this is not the case (mostly not in the US). The devs in these corners get their testing done by running unrestricted private installs of Windows inside VirtualBox. We have ready-to-run disk images on our servers for restore if something gets hosed in one of the virtual environments.
Exactly my point, that wasn't a typo. Take two meaningless datapoints and interpolate a third in between them and it doesn't matter what crazy math you use, because you're using magic to calculate fantasies.
This article, and the guy who wrote it, is a useless waste of space. Anyone can prove anything if they make unfounded assumptions. Hey, I'm going to assume that in 2010 I'll either earn $100,000 or $100,000,000. Let's take the average and call it $550,000. Look, I *CAN* afford a ten-million-dollar mortgage, on those assumptions!
PETA doesn't have a good track record of thinking these things through - look at their mink release efforts, which result in 75% of the minks being flattened on highways, eaten by each other, shot by farmers who don't want minks stealing their chickens, etc.
Given the short lifespan of meat animals, though, it would be a very temporary problem. The only animals left would be pets.
The real question is - how long will it be until you can mail a hair sample into Omaha Steaks and get yourself a box of custom-made meat cloned from your own body? I think that's a product and a half, right there! Celebrities could sell their own line of meats - Ron Jeremy salami, Pamela Anderson breast meat, mmm-mmm good.
Don't you remember that X.com *WAS* PayPal until about 2000? I would be surprised if they paid more than a four-figure sum for the domain; real estate wasn't as valuable back then. X.com was originally an online bank of sorts.
I'm younger than you, and I spent most of my adolescent life with the keyboard (Fidonet - age clue:) as my primary mode of communication, more so even than speech, so I would expect to show the same symptoms to a larger extent, ceteris paribus.
However, I have no problem with either spelling or grammar [not to say I never break the rules of grammar, though], and my first act when installing a word processor is generally to disable the automatic spelling and grammar correction. (I also use a lot of technical words in everyday writing, and things like variable names that not infrequently start with two capital letters, so automatic spellchecking/case-correction software is a big annoyance to me).
OP, I would hazard a guess that you don't read as much printed literature as you once did, and that is part of the reason why your MAD L33T SKILLZ are atrophying. It's not just the lack of pen-to-paper work, but also a lack of the other things you also used to do in the Age of Ink. Additionally, prominent content-generating people around you (newspaper reporters, for instance) are atrophying as well as the language homogenizes and words die, so the bar is constantly being lowered.
I keep myself in mental shape by reading real books (sometimes electronically, I must say, but by real books I mean not saccharine, anti-intellectual content that was developed specifically for the Internet generation - I prefer English, American and French literature of the nineteenth and early twentieth century). I also keep a couple of manual typewriters in working order, and use them to write correspondence to politicians and keep my memoirs. When I write (in my engineering notebooks or the pocket notebook I carry with me) it's with a nice fountain pen that gives pleasure in the act of laying ink on the page. All of those things, and others I've forgotten to mention, help to keep your language skills in shape.
Note that using a manual typewriter also keeps your typing accuracy up, as there's no invisible way to fix a typographical error made with an impact printing technology:)
Eek. Maybe they were originally using NiCd or NiMH and just never bothered to change the charger design since "it kinda worked". I never feel 100% safe plugging one of those cheapies into my USB port, and I certainly never leave them charging overnight or when I'm out of the house.
But just adding a smart charger chip isn't a magic bullet anyway; I was involved in a project where a [big name] Chinese OEM basically needed to add a battery charger to an existing non-battery-powered product I'd designed. Well, it never actually exploded, but several people had damaged furniture from melting appliances!
Depends on the device's mechanical design, and how it lands. The most likely failure mode (I would think, from inspection of such equipment) is that the battery will deform under impact, and try to conform to the shape of some internal sharp pointy bit, or a tall component on the PCB underneath, and it will put just that little bit too much pressure on the battery's internal separator layers. But you will see in most cases this is not going to happen - the battery sits in a compartment with no sharp ribs, components, screw bosses or heads, etc. At least that is the case in Apple devices. In Chinese $1.50 MP3 players the battery is usually just stuck to some convenient surface with a bit of double-stick tape, and all bets are off;) That was really the type of device I was talking about in my original comment, those engineers work on the "life is cheap" principle.
Another possible failure mode would be if the case itself was cracked and a sharp fragment went into the battery, or if the battery compartment was so severely deformed that the battery's shape was compromised.
All in all I think unlikely a simple drop/throw would cause this to happen. If the whole device got severely bent or crushed, though...
Well, I have enough complication in my life without a DHS investigation, but I'm sure somewhere out there, some hacker is publishing a "HOWTO - make portable electronics into incendiary that will breeze through airport security".
I don't fly any more. It's no longer worth the trouble.
Really. Li-poly batteries in these applications have no housing except the housing of the device; they're a metallized plastic bag full of gelled chemistry goodness, basically. Crunch it the wrong way and you get an internal short and a runaway reaction, which produces a lot of gas - and the whole battery acts like one of those "popping bags" you can get at 7-11 and toystores.
I am working on some similar projects for 11-12th graders though my budget is more in the $10 per student range. There are challenges with doing this without (a) soldering - and the risks, and (b) lead exposure. Anything intended for kids younger than 13 needs to be Pb-free to meet CPSC guidelines and avoid liability issues. For 9th graders you might need to check ASTM regs also regarding choking, entanglement, etc. It's a bit of a bear and it becomes harder the younger the kids get.
I am using largely recycled components from junk cellphones and other sources (TDMA cellphones in particular are available dirt cheap and have lots of interesting projects) - http://www.larwe.com/technical/2260lcd.html documents some of my reverse-engineering though it doesn't explain why I'm doing it).
A couple of interesting projects that can be made without soldering (just twisting wires)
- Use a Hall effect sensor or reed switch, in combination with a light (LED, bulb, whatever) and a handful of small magnets to demonstrate making a "recording". Glue the magnets onto a strip of paper, or just use a piece of tape sticky-side up. Pull the tape past the sensor and watch the bits as they're read out on the bulb. Works best if you color say all the north poles red, so they can work out what is 0 and what is 1.
- Make a light-following robot with two pager motors. There are a load of designs around, this one is not the simplest but is illustrative http://www.geocities.com/SouthBeach/6897/photovore.html
If you want to liaise further, feel free to contact me using that website.
Chuckle (yes, I am Lewin A.R.W. Edwards). In fact I work in a small team in a very specialized corner of the aforementioned F50 company. I work almost exclusively on the firmware in radio receivers and short-range transceivers.
Anyway, trust me: our QA people, regulatory agency testing and beta testers are a lot more diligent than IBM's graphics guys:)
Hi,
I'm the author of this article series, and I was steered here by my publication contact at IBM (I don't get much time to read/. - right now I'm working at a day job, this article series, my third book and some contract embedded systems engineering).
Anyway, I swear to you (and can email you the original PNG!) that *I* got the arrows the right way around. Unfortunately, someone in IBM's graphics department was apparently DUI operating Adobe Illustrator. I don't always get a chance to proof the graphics before an article gets published; and that was the case for this one. I got a bite at the text, but didn't see the massaged graphics until the article hit the web. I've already poked my end of the chain to get that fixed.
To people who find the article boring, I've got two comments:
a) It's part of a series. I can't assume much about my readership, so I had to spend essentially the entire first three articles doing groundwork to explain what's happening in the system and why, and how to get a functional development environment working on the box. Article #4 starts giving some actual code, and article #5 will start giving some actual circuits. Unfortunately, IBM sets the release schedule, and that means you have to wait a month between episodes. They also set the article length limits, which means I can only put so much in each instalment.
b) Not everything in those three articles is obvious to the lay person. Although I didn't have enough space to go into great detail, I tried to communicate some useful information I've learned in practical 32-bit systems implementation (for commercial purposes). Remember that the target audience is primarily people who are accustomed to building x86-based embedded Linux apps, and many of these people will not know or care about much of the infrastructure under their app.
Slashdot Mirror
My kneejerk response is to tell you not to worry your pretty little head about these questions, since unless you're working on aerospace, medical or government contract code (written in Ada?), this obsession with CMMI will soon put your small company out of business and you'll be able to get a real job at a company that's focused on making products instead of "deliverables". Anyway - the answer to "what is the most important part" is - usability BY THE PEOPLE WHO HAVE TO USE IT. I am involved with some groups who are CMMI level [x], reluctantly and for absolutely no useful purpose (by the time they finish these paperwork deliverables, their product is obsolete). The first step is for requirements to be entered, and this requires cooperation from non-engineers who are used to drafting a free-form Word document, and who frequently work offsite and/or with no live Internet connection, e.g. while on a plane. Note the implication here - for usability by the target people, it should be possible to export, edit offline and reimport data with no loss of audit trail. Further, all of these systems that I've evaluated - I'm most familiar with Contour - impose a structure on the input, and it's usually configurable by means of templates. MAKE SURE your entry template is designed/approved by the [typically marketing] folks who are expected to kick the project off, otherwise you'll wind up with a spec containing everything in the first category box and everything else left blank. I've never seen a CMMI template that was properly structured for non-engineers, btw; they're all designed by CS majors or, worse, documentation control specialists. And without buy-in from those people at the start, you're immediately screwed (unless this is purely a for-show exercise, where auditors, if any, are only looking for some text in every field - in which case go ahead and paste in lorem ipsum and get on with your actual work). I also suggest you hire someone whose sole job is to create and update this paperwork, because it is a spiraling black hole of unproductivity for any project that operates on modern development cycles (it only works with the waterfall model; too bad if you're doing a large consumer electronics project that needs to be released before your chipset goes obsolete and the world moves on) and by having a specific person (persons) assigned to it, you can very easily put a numerical value on exactly how much it is costing you, which might help to kill it before it sinks you. May flights of angels sing thee to thy rest...
The allowed distance is not a function of base station Tx power, it's a function of signal propagation time. You can easily reprogram all the towers not to permit connections to phones > (x) meters away by simply saying "if the phone requires a timebase correction of more than (y) microseconds, hand over to a neighboring tower". (All GSM towers already have such a limit implicitly - there are so many TDMA slots, and no more). This works better on CDMA systems than TDMA because "audible but not in-range" cells just become part of the noise floor. But anyway - Nobody has done anything with the analog TV spectrum yet. This is where we'll see an expansion of available bandwidth. And there are other non-cellular technologies that would deliver the data people crave; a system for handing over seamlessly between cellular and WiFi for instance.
What about a USB recording device? They [potentially] have less noise, and they're pluggable anywhere.
For the internal case, a bulletin board style web-based system's PM facility will provide you with delivery and confirmation of receipt. Or you could go the whole hog and install PDM software like Agile... but I doubt you want to do that ;)
For the external case, I suggest using fillable PDF documents, with a secure signature generated by the addressee (this is instant and free in Adobe Reader).
At my Very Large Corporation our developers need admin rights because we are constantly tinkering with special hardware, updating drivers, running software that's not supported by anyone (obsolete compilers and debugging tools in particular), etc. So we have admin rights. However there are some corners of the org where this is not the case (mostly not in the US). The devs in these corners get their testing done by running unrestricted private installs of Windows inside VirtualBox. We have ready-to-run disk images on our servers for restore if something gets hosed in one of the virtual environments.
Exactly my point, that wasn't a typo. Take two meaningless datapoints and interpolate a third in between them and it doesn't matter what crazy math you use, because you're using magic to calculate fantasies.
This article, and the guy who wrote it, is a useless waste of space. Anyone can prove anything if they make unfounded assumptions. Hey, I'm going to assume that in 2010 I'll either earn $100,000 or $100,000,000. Let's take the average and call it $550,000. Look, I *CAN* afford a ten-million-dollar mortgage, on those assumptions!
PETA doesn't have a good track record of thinking these things through - look at their mink release efforts, which result in 75% of the minks being flattened on highways, eaten by each other, shot by farmers who don't want minks stealing their chickens, etc. Given the short lifespan of meat animals, though, it would be a very temporary problem. The only animals left would be pets.
The real question is - how long will it be until you can mail a hair sample into Omaha Steaks and get yourself a box of custom-made meat cloned from your own body? I think that's a product and a half, right there! Celebrities could sell their own line of meats - Ron Jeremy salami, Pamela Anderson breast meat, mmm-mmm good.
Don't you remember that X.com *WAS* PayPal until about 2000? I would be surprised if they paid more than a four-figure sum for the domain; real estate wasn't as valuable back then. X.com was originally an online bank of sorts.
I'm younger than you, and I spent most of my adolescent life with the keyboard (Fidonet - age clue :) as my primary mode of communication, more so even than speech, so I would expect to show the same symptoms to a larger extent, ceteris paribus.
However, I have no problem with either spelling or grammar [not to say I never break the rules of grammar, though], and my first act when installing a word processor is generally to disable the automatic spelling and grammar correction. (I also use a lot of technical words in everyday writing, and things like variable names that not infrequently start with two capital letters, so automatic spellchecking/case-correction software is a big annoyance to me).
OP, I would hazard a guess that you don't read as much printed literature as you once did, and that is part of the reason why your MAD L33T SKILLZ are atrophying. It's not just the lack of pen-to-paper work, but also a lack of the other things you also used to do in the Age of Ink. Additionally, prominent content-generating people around you (newspaper reporters, for instance) are atrophying as well as the language homogenizes and words die, so the bar is constantly being lowered.
I keep myself in mental shape by reading real books (sometimes electronically, I must say, but by real books I mean not saccharine, anti-intellectual content that was developed specifically for the Internet generation - I prefer English, American and French literature of the nineteenth and early twentieth century). I also keep a couple of manual typewriters in working order, and use them to write correspondence to politicians and keep my memoirs. When I write (in my engineering notebooks or the pocket notebook I carry with me) it's with a nice fountain pen that gives pleasure in the act of laying ink on the page. All of those things, and others I've forgotten to mention, help to keep your language skills in shape.
Note that using a manual typewriter also keeps your typing accuracy up, as there's no invisible way to fix a typographical error made with an impact printing technology :)
Eek. Maybe they were originally using NiCd or NiMH and just never bothered to change the charger design since "it kinda worked". I never feel 100% safe plugging one of those cheapies into my USB port, and I certainly never leave them charging overnight or when I'm out of the house. But just adding a smart charger chip isn't a magic bullet anyway; I was involved in a project where a [big name] Chinese OEM basically needed to add a battery charger to an existing non-battery-powered product I'd designed. Well, it never actually exploded, but several people had damaged furniture from melting appliances!
Depends on the device's mechanical design, and how it lands. The most likely failure mode (I would think, from inspection of such equipment) is that the battery will deform under impact, and try to conform to the shape of some internal sharp pointy bit, or a tall component on the PCB underneath, and it will put just that little bit too much pressure on the battery's internal separator layers. But you will see in most cases this is not going to happen - the battery sits in a compartment with no sharp ribs, components, screw bosses or heads, etc. At least that is the case in Apple devices. In Chinese $1.50 MP3 players the battery is usually just stuck to some convenient surface with a bit of double-stick tape, and all bets are off ;) That was really the type of device I was talking about in my original comment, those engineers work on the "life is cheap" principle.
Another possible failure mode would be if the case itself was cracked and a sharp fragment went into the battery, or if the battery compartment was so severely deformed that the battery's shape was compromised.
All in all I think unlikely a simple drop/throw would cause this to happen. If the whole device got severely bent or crushed, though...
Well, I have enough complication in my life without a DHS investigation, but I'm sure somewhere out there, some hacker is publishing a "HOWTO - make portable electronics into incendiary that will breeze through airport security". I don't fly any more. It's no longer worth the trouble.
Suffice for what? Gets it out of your house, sure :)
Really. Li-poly batteries in these applications have no housing except the housing of the device; they're a metallized plastic bag full of gelled chemistry goodness, basically. Crunch it the wrong way and you get an internal short and a runaway reaction, which produces a lot of gas - and the whole battery acts like one of those "popping bags" you can get at 7-11 and toystores.
I plead mental incapacity due to lack of sleep.
Latency issues have been an important factor for a long time. Here's an example article about some of the details:
I am working on some similar projects for 11-12th graders though my budget is more in the $10 per student range. There are challenges with doing this without (a) soldering - and the risks, and (b) lead exposure. Anything intended for kids younger than 13 needs to be Pb-free to meet CPSC guidelines and avoid liability issues. For 9th graders you might need to check ASTM regs also regarding choking, entanglement, etc. It's a bit of a bear and it becomes harder the younger the kids get. I am using largely recycled components from junk cellphones and other sources (TDMA cellphones in particular are available dirt cheap and have lots of interesting projects) - http://www.larwe.com/technical/2260lcd.html documents some of my reverse-engineering though it doesn't explain why I'm doing it). A couple of interesting projects that can be made without soldering (just twisting wires) - Use a Hall effect sensor or reed switch, in combination with a light (LED, bulb, whatever) and a handful of small magnets to demonstrate making a "recording". Glue the magnets onto a strip of paper, or just use a piece of tape sticky-side up. Pull the tape past the sensor and watch the bits as they're read out on the bulb. Works best if you color say all the north poles red, so they can work out what is 0 and what is 1. - Make a light-following robot with two pager motors. There are a load of designs around, this one is not the simplest but is illustrative http://www.geocities.com/SouthBeach/6897/photovore.html If you want to liaise further, feel free to contact me using that website.
Chuckle (yes, I am Lewin A.R.W. Edwards). In fact I work in a small team in a very specialized corner of the aforementioned F50 company. I work almost exclusively on the firmware in radio receivers and short-range transceivers. Anyway, trust me: our QA people, regulatory agency testing and beta testers are a lot more diligent than IBM's graphics guys :)
Hi, I'm the author of this article series, and I was steered here by my publication contact at IBM (I don't get much time to read /. - right now I'm working at a day job, this article series, my third book and some contract embedded systems engineering).
Anyway, I swear to you (and can email you the original PNG!) that *I* got the arrows the right way around. Unfortunately, someone in IBM's graphics department was apparently DUI operating Adobe Illustrator. I don't always get a chance to proof the graphics before an article gets published; and that was the case for this one. I got a bite at the text, but didn't see the massaged graphics until the article hit the web. I've already poked my end of the chain to get that fixed.
To people who find the article boring, I've got two comments:
a) It's part of a series. I can't assume much about my readership, so I had to spend essentially the entire first three articles doing groundwork to explain what's happening in the system and why, and how to get a functional development environment working on the box. Article #4 starts giving some actual code, and article #5 will start giving some actual circuits. Unfortunately, IBM sets the release schedule, and that means you have to wait a month between episodes. They also set the article length limits, which means I can only put so much in each instalment.
b) Not everything in those three articles is obvious to the lay person. Although I didn't have enough space to go into great detail, I tried to communicate some useful information I've learned in practical 32-bit systems implementation (for commercial purposes). Remember that the target audience is primarily people who are accustomed to building x86-based embedded Linux apps, and many of these people will not know or care about much of the infrastructure under their app.