I would bring a kit for embedded + sensors experiments. Mine has a laptop, a Parallax P832A, a solar panel, and a super capacitor. Also a bunch of thermistors, some bread boards, LED's, little steppers, some I2C devices, and assorted other sensors & actuators. Hours of fun. Also can be useful if you need to make a gadget out in the bush. If you bring your smart phone you can use it as an interface to your projects using HC05/HC06 bluetooth. Its a blast.
There is a shortage of science and engineering speciailists that will work for free. There is a glut of unemployed scientists and engineers that wish to be paid.
I use a template asking how to reproduce the bug, and ask the user for the exact steps.
If it can't be reproduced, its marked "invalid".
If it can be reproduced, we check the requirements.
If the behavior violate the requirements, the bug is against the code.
If the behavior does not violate the requirements but is still in need of change, we update the requirements, and check the previous step.
Pretty straight forward, although it takes some work.
"Because you might get more money than anticipated, but not more time."
NONSENSE. When a deadline passes, what happens? Is the whole team actually dead? No? So they just keep woking and release it later? Anybody NOT notice this at your job?
Unless its and actual life or death situation (Medical Emergency, war, natural disater, etc), deadlines are just a guestimate. It takes as long as it takes, regardless of how you stamp your little feet. Pressureing the team to "dance faster" just makes it worse.
The same thing happened when the variable for time on 16 bit systems rolled over in the late 80's. My boss told me to "fix it". I added a second word, with a 32-bit value, the problem was solved. For that system, it should be fine till
A couple weeks later, word came out that big financial companies (TRW, etc) ignored the issue, and lost piles of $$$. The same fools that ignored the issue the first time around were the "experts" warning us of the 2k disaster that never happened.
So simple to fix, so foolish to ignore.
Here's something designed for kids. It supposed to be easy enough so parents can figure it out. Don't know how close it comes.
http://code.google.com/p/propforth/
multicore micro controllers for robots (embedded systems) using FORTH on the parallax propeller
... testable requirements, and executing those tests, are much more important and come first.
This is the big secret that separates the engineers from the hackers
If requirements and tests are in place, then standards are useful, otherwise they are a distraction.
Slashdot Mirror
I would bring a kit for embedded + sensors experiments. Mine has a laptop, a Parallax P832A, a solar panel, and a super capacitor. Also a bunch of thermistors, some bread boards, LED's, little steppers, some I2C devices, and assorted other sensors & actuators. Hours of fun. Also can be useful if you need to make a gadget out in the bush. If you bring your smart phone you can use it as an interface to your projects using HC05/HC06 bluetooth. Its a blast.
There is a shortage of science and engineering speciailists that will work for free. There is a glut of unemployed scientists and engineers that wish to be paid.
I use a template asking how to reproduce the bug, and ask the user for the exact steps. If it can't be reproduced, its marked "invalid". If it can be reproduced, we check the requirements. If the behavior violate the requirements, the bug is against the code. If the behavior does not violate the requirements but is still in need of change, we update the requirements, and check the previous step. Pretty straight forward, although it takes some work.
"Because you might get more money than anticipated, but not more time." NONSENSE. When a deadline passes, what happens? Is the whole team actually dead? No? So they just keep woking and release it later? Anybody NOT notice this at your job? Unless its and actual life or death situation (Medical Emergency, war, natural disater, etc), deadlines are just a guestimate. It takes as long as it takes, regardless of how you stamp your little feet. Pressureing the team to "dance faster" just makes it worse.
The same thing happened when the variable for time on 16 bit systems rolled over in the late 80's. My boss told me to "fix it". I added a second word, with a 32-bit value, the problem was solved. For that system, it should be fine till A couple weeks later, word came out that big financial companies (TRW, etc) ignored the issue, and lost piles of $$$. The same fools that ignored the issue the first time around were the "experts" warning us of the 2k disaster that never happened. So simple to fix, so foolish to ignore.
A lot of folks are addicted, but that don't change that its very damaging. It may be a calming habit, but eventually it causes horrible consequences.
Here's something designed for kids. It supposed to be easy enough so parents can figure it out. Don't know how close it comes. http://code.google.com/p/propforth/ multicore micro controllers for robots (embedded systems) using FORTH on the parallax propeller
... testable requirements, and executing those tests, are much more important and come first. This is the big secret that separates the engineers from the hackers If requirements and tests are in place, then standards are useful, otherwise they are a distraction.