In my case, the paper is already mostly gone. Most documents that I work with are on the computer. Most of the info I read is now online. And I hardly ever print anything anymore - there's just no need for it.
- -
But going beyond that, the way mobile devices are trending, and with just a little more acceptance from society with regards to telecommuting, I don't see why many people would even need to go in to the office most days. Even face to face meetings could be done in some temporary venue, like a nice coffee shop.
Once businesses realize that they don't have to spend all that money just to rent office space so they can stuff their employees into cubicle farms, well then...
So are you only vulnerable if you use ISAPI ? It does look like that module is enabled by default though. I wonder why ?
Actually, according to the advisory, it seems you are only vulnerable if you actually load an ISAPI.dll module.
"it is possible to trigger a vulnerability in Apache mod_isapi that will unload the target ISAPI module from memory. However function pointers still remain in memory"
Even so, it's probably a good idea to comment out mod_isapi if you're not actively using it.
There's nothing two-factor about this solution.
Someone just has to steal (or take) the plastic thingie from you and now they can get in but you can't.
If you first had to login normally (using a memorized password) and second hold the plastic up to see the one time pad
then you could say it was two-factor.
A two-factor key cannot be allowed to have just a single point of failure.
Then there is the recovery problem afterward. At least after a stolen housekey you can just bust in and then fix your door.
What do you do when the plastic thingie goes missing?
Do you need a back door? And how secure would that be?
Or can you get another plastic thingie exactly the same? Only to use it once to get in so you can then register another (uncompromised) one.
Not to mention that if you can get a replacement plastic thingie exactly the same, then maybe somebody else can too.
Rocketship Galileo-Heinlein Space Cadet-Heinlein Have Spacesuit Will Travel-Heinlein Storm Over Warlock-Andre Norton Star Rangers-Andre Norton Slan-A.E. Van Vogt The City and the Stars-Isaac Asimov I Robot-Isaac Asimov Lucky Starr series-Isaac Asimov Childhood's End-Arthur C. Clarke Expedition to Earth-Arthur C. Clarke Brightsuit McBear-L. Neil Smith Raiders From The Rings-Alan E. Nourse Rocket to Limbo-Alan E. Nourse Star Surgeon-Alan E. Nourse The Counterfeit Man-Alan E. Nourse Hospital Station-James White Star Surgeon-James White Hestia-C.J. Cherryh Dragonflight-Anne McCaffrey Dragon's Egg-Robert L Forward Mission of Gravity-Hal Clement Spacepaw-Gordon R. Dickson Blackcollar-Timothy Zahn Enemy Mine-Barry B. Longyear And of course pretty much anything by E.E. Doc Smith, but specially the Lensman series.
I also consider Starship Troopers somewhere in there, but you have to consider that young boys won't really get the political side of it until they get older and re-read it.
I am assuming you want to improve your coding for maintainability and such. However it is also reasonable to reserve your best coding efforts for code that will be used heavily by others, and spend less time on throwaway code.
Remember that the more code you put in, the fancier your coding structures get, the more comments that go unmaintained, the more difficult your code will be to follow.
Here are some rules you can follow that will help you no matter what language you use:
Rule #1: since the more code you put in, the worse it will be, it follows that putting in less code, or even removing some is always a good idea. Refactor your code mercilessly.
Rule #2: reduce your function/method argument counts where possible. You can group arguments together into a stucture, or hold some in member attributes as object state, but _only_ if it makes sense to do so. Passing _unrelated_ arguments through member variables can lead to a yo-yo coding style that is more difficult to follow and induce unwanted state on an object (ie. unnecessary coupling). Sometimes, to reduce argument count, it is easier to break up the method into multiple ones. Anything above 4 arguments should be reviewed. Anything above 6, you should make a serious attempt to reduce.
Rule #3: use proper english. Methods should start with a proper verb and be followed by adjectives and nouns. Proper spelling should be used. Avoid made up acronyms (Microsoft code is the worst for this) The effect you are trying to achieve is to make your code literate (not quite so much as in Knuth)
Rule #4: make variable/argument/method names meaningful. The variable name should describe what it contains. eg. index, count, accumulator. Don't use short forms or single letters. If you can't come up with a good description, and it is a trivial variable, then you can do the Smalltalk trick of calling it after the type. e.g. aString, theNumber, anElement. If a method name is hard to understand, then someone trying to follow the code may have to do a lookup of some sort such as looking at the method comments if they are visible (or perhaps even calling the original coder) and it will break their focus. If you are in doubt about what to name something, go find a dictionary or a thesaurus. Don't just name it something junky and meaningless.
Rule #5: make the code obvious. No fancy coding tricks that lead newbies astray. Unless it can't be avoided.
Rule #6: comment only when not obvious. If the code is the least bit non-obvious (because it can't be avoided), then add a small comment above it or beside it. Otherwise, let the code speak for itself. Too many comments that just repeat what is obvious make the code look like gibberish. And that volume of commenting usually gets out of sync with the code as it gets maintained by people passing through. Just comment the important and non-obvious stuff, and maintainers may be willing to update the comments too.
Rule #7: keep your functions/methods small. A good size to aim for is 5 lines of code. 30 lines can be OK if an algorithm warrants it. More than that and you need to consider splitting it apart. Try to make the finer methods still meaningful/useful by themselves. Ideally, each function/method should be independent of the others. Make it obvious when they are not e.g. private adjustAmountHelper()
Practice the above rules faithfully and you will already see an amazing improvement.
If you want more rules than that, and you are on-side with your boss, you can try looking at a coding standard, such as
C++ Programming Guidelines, Plum and Saks
Despite the C++ in the name, the concepts in the book are fairly applicable to other languages as well.
I have had bosses that wouldn't endorse any coding style guidelines at all until I presented them with the Plum and Saks book. Some bosses just need to know they are not following your arbitrary standard, and presenting them with an actual book or website is all you need
Each product team, taken in context (the services and support from the rest of the company), must be capable of providing skills to handle the whole picture.
Bigger companies provide more support skills for each team. Bigger product teams provide more internal skills. The required but missing skills form a hole that must be filled.
The development manager is the one that needs to plug this hole, either by directly providing innate skills, by asking someone to train or by hiring someone where necessary. For a manager to hire/fire and manage someone, they should have at least some knowledge of the skill topic, so they are able to evaluate performance.
If you describe the capabilities of the existing team, and of the available support (including the responsibilities handled by the product manager), then a good manager should be able to spit back a list of the missing capabilities, and a suggestion of how to approach filling the gap. The specially creative ones, will be able to suggest more cost-effective solutions. You should be able to ask the manager candidate to describe each of the skills/capabilities they mentioned in more detail with examples, and to rough estimate (in time and money) of their approach.
The usual holes to consider (depending on the size and organization of the company) are Q/A, documentation, build/release/configuration management/engineering, project management, customer delivery and customer support.
One thing the development manager must specially have a handle on is the development process, its state of affairs, what the missing parts are, and how it should/could be improved.
In a small (10 man) product oriented team, usually the development manager should also act as the technical lead, and should be responsible for the technical (i.e. non-functional) requirements. Ask them to describe some of these potential requirements.
Like any other manager, a development manager should be able to lead their team and negotiate with other teams. And beyond that, they should be able to present technical explanations. So look for leadership, negotiation and presentation abilities, as well as the ability to assess and apply motivation.
Other than this, a development manager should, (again like any other manager) be a good cog in the reporting hierarchy. They need to be able to conform to and enforce company policy as it trickles down, and they need to be able to report issues/status/budget regularly upwards. They also need to contribute their bit to the overall budget planning. Check for communication, writing, budgeting and planning skills. Look in their past history for ability to work within the organization.
In particular, a development manager should be aware not to download too much of their reporting burden to their developers. eg. daily 2 hour status meetings + individual developer reports. Ask them their policy on what developers should be reporting and how often.
Lastly, whether their team already has the capability or not, a good development manager should be able to contribute something to the overall design discussion. They should be aware of other solutions out in the market, and of where to find answers. Check for ability to design and ability to research (specially on the internet)
A lithium battery has very little lithium in it. Some of the lithium is already converted to lithium oxide.
Just remember that any fire needs 3 things: oxygen, fuel and heat. Remove any one and you kill the fire. Also consider that the most important thing about a fire is how quickly it will expand. You can expect a fire to double in size roughly every 20 to 30 seconds if it has material available to burn.
1st - get someone else (if there is someone else) to call the fire department. If you fail to contain the fire, you need professionals help ASAP. If you are alone and you think you can handle it without taking chances, you can call the fire department after first trying to handle it. Use your judgement and stay calm.
If the fire is still small, just grab the device containing it and toss it into a empty (empty it out if necessary) metal trash can (or a clear area of concrete floor if available) and wait until the fire burns out. Do protect your eyes by avoiding looking at it as much as possible while you are holding it. If you have some sort of rubber or sufficiently thick cotton mat (like a fire blanket), you can use that to cover the fire and contain it until you can put it in the trash can. The mat may catch fire eventually, but it will be more resistant than most other things. Do not use a plastic sheet as plastic melts and if it gets on your skin it can cause some bad blistering. Once it is in the trash can do not cover it with something unless you are sure it is not flammable and will resist high heat - a fire is harder to fight if you cannot see it. Do monitor the fire in the garbage can to see that it does not grow.
Otherwise, if the fire is too big for you to carry the device containing the battery, the fuel for the fire is now overwhelmingly whatever it is sitting on or surrounded by, so fight that type of fire instead. The lithium left in the battery is irrelevant.
In any case, a large volume of water will cool any type of fire sufficiently to a more manageable level, and make most surrounding combustibles harder to ignite. The important thing to remember about using water is to turn off A/C power from wall sockets etc. first.
If at any point you feel you can't manage to handle the fire, just get out of the building in a calm manner and wait for the fire department. Make sure everyone gets out and keep people from returning inside.
Seriously. The database sucked. If I wanted to find a problem to tackle, just finding a good one is problem enough.
How about getting the problems -listed by multiple tags -filterable by area of interest, and skillset required -prioritized by relevance to science, to humanity, to marketability -sorted by difficulty, number of extant participants
If you can't communicate why something is a problem, then you have two problems.
After I gave up on it, I ripped it out and went with Mantis.
Whenever I installed Trac, I did install the distribution binaries, made sure all the libraries were compatible, and the database, binaries, etc. were set up as per the install instructions (possibly even correctly).
Maybe I could have chased down the problem eventually. However, they didn't seem to have the time, and my time is fully committed to my own project. So I had to give up and find something else.
Maybe Trac will get better someday. I sure hope they do. (they do have an interesting approach, and a good looking UI) And if you it works for you. That's great. Go for it.
But until they do get better, people like me, (who just need to get work done, without risking their data) should avoid it and use something a little more stable.
I use Jira at work, and like it, but Jira is a bit expensive for a one man personal project. So after looking around a bit on the net, I chose Trac and installed it on my home system to try it out.
Trac looked good. Had an interesting UI. The buzz on the net was favourable. Took a little bit of effort to install, but then so did most other issue tracking systems. So far so good.
I entered a few test issues. Still so far so good.
Then I tried to correct those issues. Change the issue type. Even delete an issue.
All of these failed with the usual vague error messages and python stack traces. So fine. I reported it. Trac obviously wasn't ready to be used in a real situation.
No response to my issue for weeks.
In fact, several releases were made without my issue adressed. Hmm, must have bigger fish to fry; time to look at their changelog. Wow, lots of bugs in the changelog relating to stability. In fact, they changed some of the underlying libraries and according to their roadmap, were still scheduled to change even more.
Ok. So Trac really isn't ready for prime time, they're still tinkering with architecture. It's OK for people to play with, but not OK to rely on.
So I gave up on it and tried Mantis. It installed reasonably well, and so far it handles most of the basics. Not as pretty as Trac, but it gets the job done. So far so good.
>I have met a lot of Sr.developers and very few of them have skills I would call 'Rock solid'.
Hmmm, I wasn't suggesting that other senior developers were not incompetent.
However, those types of senior developers usually get there by hanging on long enough or by happy accident or even by knowing somebody.
I just assumed that the poster did not want to follow those avenues, since he did not know anyone, had not yet had a happy accident, and didn't want to wait it out.
In any case, to avoid those avenues, which result in chancey dead end jobs at best, and which are subject to being cleared out by the next "broom that sweeps clean" change in management, then you need to be sufficiently competent.
The point is that those types of senior developers are not marketable outside their current jobs. And they also have no real outward or upward mobility (except by hanging on to somebody else) They are just the usual deadwood and mostly fade into the backrgound (incompetence likes to hide).
Sr. Developer is just a stepping stone to higher (developer) positions which is what you want if you want to stay in development past a certain age.
However, since many companies refuse to promote staff from within at all, sometimes you can only move up the ladder by moving to other companies. Which is why I put such a big emphasis on marketabilty.
>The point is ageism, which is very serious issue in the software development industry. >Just 2 years ago I was looking for work, and I experienced it very visibly.
Just 5 years ago and just 3 years ago I was also looking for work and both times I got hired immediately. I am definitely no spring chicken, having 20+ years as a developer (and having started late in life at that). I am certainly more than a fair target for what ageism lies out there.
My point is that ageism can be overwhelmed with competence, I have done it repeatedly, I have also seen others do it, and have interviewed others needing to do it. I was offering advice based on how it works for me when I do it, and what works with me when I interview others.
It is just a matter of making them focus on what you bring to the table rather than how many wrinkles you may or may not have.
If you walk into an interview believing you are too old, or not skilled enough, then you are already defeated, and the interviewers will be able to tell.
And as for your issue with ageism existing in the industry. I too have seen it everywhere, and not just for developers. However, a lot (not all) of the times, you might be mistaking it for something else.
For example, if a developer with 12 years experience presents with no time spent in a senior developer role (whatever the actual titles are), then I seriously question their ability to grow and suspect a lack of motivation. Lack of ability or willingness to grow is a big factor when I get "almost there" resumes that are lacking a few of the items necessary to fill the position.
Personally, I never consider position titles in resumes until the interview. At that point, I then dig into the matter to find out why.
Sometimes the title was not given even though the individual actually performed the role. I usually go over their responsibilities so I can reverse engineer their effective (as opposed to nominal) roles.
However, I can see where other overwhelmed interviewers might not bother to give the applicant a chance. Specially after the usual truck full of "not even close" and "did they even bother to read the ad" resumes.
>"I'm a programmer with more than twelve years of experience.
Ah. Very good. You're just getting started. This next part is where the fun begins.
>In all that time, I've never been a 'senior' developer.
Maybe you should try it. Being a senior developer implies you know skills beyond just coding. (Of course, as a senior developer, your coding skills must already be rock solid)
At the very least you should be able to design your own modules (major feature sets) and come up with additional requirements (that you can help deliver) when someone describes what they want. You also need to be able to see the work through the full development lifecycle to the bitter end and beyond into maintenance. (the full Monty)
For brownie points. Becoming the "go to" person is always a plus. (Goto may be considered harmful in programming but it's really good for your career)
Mentoring others is a plus. Being able to contribute to design discussions is a plus.
>I'm competent and I work hard, but I don't think I am quite a senior developer in terms of technical or people skills.
Programming is not all that developers do. Working hard is not enough. Work smart instead. Older developers can't compete on volume, we have to do it on efficiency and quality.
You need to be able to consistently show good results, and ideally with as little wasted effort as possible. If you're always working hard then you have no time to take on additional tasks. You can't be the goto guy (or girl) if you're always up to your neck.
>More and more I feel that I'm aging myself out a job.
If you feel old then you will be old. Developing software is a game of the mind. The more you learn, the more you realize there is still to learn, and the younger your mind. A "young" mind can live in an old body, and vice versa. Being young in mind means you are still able to learn.
Managers that equate physical to mental age are best avoided anyways. If their their judgment is bad in that regard, it will likely be bad in others.
When I get involved in hiring people, I always look for those who show a consistent ability and interest in learning new things. People who are young may get a temporary free pass, since they have no real history to be examined, and since the basic assumption is that they are still capable of learning. But if they show a decided lack of capacity to learn, that free pass evaporates quickly.
In any case, the more experience you have, the more you can compete. Not by coding; coding inexpertly applied is only wasted effort.
You have to know where to apply the effort. If you leave this up to your managers, who do less programming than you, and if you don't suggest anything, then what does this say about your competence as a developer?
>By this time, employers expect someone with my experience to have advanced some, >and they may not be willing to even talk to me now, thinking that my pay requirements have grown while I have not.
You need to deliver enough skills that what they assume your pay requirement to be will be considered a bargain. If you deliver additional skills that they can't do without (new something-or-other must-have technology) then you will be able to ask for more money than they expect from your age based requirements.
>Even if I did get hired someplace new, my peers would likely be much younger than me.
So what? Don't you like to work with young people too? Some are good looking. Others are pleasant to work with. Some are quite smart.
Just like some older folk.
In any case, unless you are in management. All your non-management co-workers are peers. If you want to work as a non-manager as you get older, you will need to deal with some and eventually all of your peers being physically younger.
Time is a one way street (so far). You have to deal with its effects.
Software going into production systems belongs to IT. End of story.
IT should treat Development just like any other software vendor. If vendor representatives are there at the production site, it is only to offer help at the behest of the customer (which in this case is IT). Nothing goes into the systems directly from the vendor without being vetted by the IT guys.
If the product has bugs, it needs to be treated by development at least as seriously as with any other important customer.
What this means therefore, is that IT has to have enough people on staff that can understand and maintain the deployed system.
The usual problems here are that
1) a lot of IT staff don't want to learn a new system (specially one that is in-house and doesn't give transferable skills) -> The answer here is to suck it up and replace them with someone more willing to learn the required systems.
2) development doesn't treat IT as a real customer (it's only IT) and releases shoddy code that needs frequent updating -> The answer here is for IT to do a formal acceptance test and reject the software if it is not ready for prime time (with high visibility to upper management). Ideally, these formal acceptance tests should not be scheduled too often, so that deployments can be better spaced out to force development to actually plan and design what is going to be in each release before they toss it over the wall.
3) IT doesn't see itself as having a stake in the deployed software. Since the software comes from development, and IT had no choice in its selection, any success makes development look good and does nothing to make IT look good. IT treats the situation as forced babysitting. -> the answer here is for IT to treat it like any other deployed system upon which they are dependent for success. Any bugs, or problems in the system should be reported to the "vendor". Anything which IT thinks could be done better should be sent back to the vendor as a requirement (to be assessed by the product manager to be sure).
If the company is too small to have very many people, then you can dual-role some people with the required skills, but the job roles have got to be kept separate even if in the same person. You need people who can change hats and role-play effectively here so that oversight boundaries are not erased.
In software, as in so many other venues, good fences do make good neighbours.
The premise of Planetes (a.k.a. Trashmen in Space) is that so much garbage will be put into orbit around Earth that it becomes dangerous to space traffic and we will need a dedicated "Space Debris" division to control it.
Maybe they're a couple of Fourth Imperium battle planetoids in parking orbit. Now we just need to figure out how to get over there and hotwire those babies.
I haven't been involved in hardware since 1991 (I do exclusively software now), so my info is quite dated. I was involved in doing the purchasing and kitting (I dealt with all the suppliers), the hardware/software testing, and some of the software development (we were a startup, and in those days everybody had more than one role). I'm not sure that the small electronics industry has survived in the form I remember.
Back in 1991, one of our (electronics) hardware guys also had a talent for doing enclosure design. But even so, our needs were not as extensive as yours (we were not producing a handheld device)
If you mockup a general drawing of the device, most machine shops won't have the expertise on board to think the rest of it through (unfortunately)... although you might luck out.
It would be better to subcontract to somebody who could do the mechanical design (who was familiar with electronic devices). Meeting the required dimensions and mechanical support requirements is only part of the work. You also need to deal with styling and ergonomics. There are companies out there that specialize in the styling (as your case "look" is one of the components of brand identity)
Unfortunately, I can't really guide you very well on how to go about finding the right sort of person for this. You would probably need at least some face time, to include gestures along with pictures:-) so they should be relatively local.
If you live in the US (I do not), you may want to try some company similar to those listed here (I have no idea if these are any good or if they are capable of delivering the full Monty, they just seem to be in the general ballpark) http://www.mfgquote.com/profiles/Electronics-Enclo sures-United-States.html
If they are very good (and plugged into the industry), they would also be aware of local fabs that could do the actual work. (be careful if they have their own fab - they will plug it shamelessly and will not mention any serious competitors)
Don't hesitate to ask everyone you come in contact with (in the industry) to let you know who the other players are that they deal with, or have heard of, and what their reputations are.
In any case (pardon the pun) I wish you well in your quest. Hardware is a grand adventure (OK quite a few grand).
I don't know if by "I have the basics for what I need such as what OS, and platform I will base it on (motherboard" you mean to say that you already have selected/designed/tested/certified the actual motherboard.
Assuming you haven't done that (since it implies the case size will be constrained by your already selected board), you need to do some serious electronics work to get the circut board to a suitable shape and size for your handheld.
Once you have it working on your desk, you need to do the following to make it suitable for hand held operation.
Standard disclaimer: IANAEE
1) reduce the size and weight
Select smaller components (like the ones that go into wave solder machines), change the layout, consider a multilayer board (more layers = more mfg cost and more difficulty in layout design) Smaller board = smaller case
Note: remember that anything at the edge of the board can get dinged by the installer as they put the board into the case.
It is good to establish beforehand your desired/target size and weight even if you don't quite achieve it right away.
2) determine the battery/power source that you are going to use with it.
If it is re-chargeable, determine if the charger is ouside or inside the handheld case. Some power sources require additional shielding for safety if the battery contents should leak. You need to be able to provide sufficient operating time and standby time (baterries leak current slowly even when off). Standby time must be at least 1 day or more (ideally 4 days - a long weekend). Standby power needs to account for anything that must remain powered up - such as memory, always on components etc.
3) reduce the power draw
You may need to select low power versions of the components and if you have too many discretes, you may want to push them into a PAL or an ASIC (note: ASIC design/prototyping can cost quite a bit, so you may want to defer it to version 2.0)
It is good to establish beforehand your desired/target power draw even if you don't quite achieve it right away.
4) design your circuit layouts carefully
You need to account for timing issues due to signal lag, power up issues due to the timing of what power lines come on first (which depends on the load for each line) And you need to measure and reduce signal noise enough to prevent signal interference. You have to account also for any parts that may get hot (nearby parts may not like it) You also need to confirm with you board manufacturer that your layout meets their specifications. And you need to check with the board assembly guys that they can assemble the parts in (by robot) and wave solder the board - otherwise you will need manual assembly or manual soldering (very bad).
5) account for heat dissipation from the case and from the hot parts
Should not too much of a problem for something that should be handheld. However, if it is warm enough to notice by touch, you may need to insulate the handgrip. If you need to stimulate a part to get it hot, you may need to create a signal gererator or write some testing software to generate the signal to heat up the part. If you can, test the heating of the part until you see its failure mode. Ideally, it should just stop working until it cools down again. A worse outcome is that it lets out the magic smoke or even starts a fire. If this is an issue, you may need to add in some thermal monitoring and regulation (usually, you just select better parts).
6) make sure the circuit board has holes drilled for support
The holes should allow for firm support without twisting or pulling. Rubber gaskets/grommets can reduce the transmission of shock. You need to do a drop test (from waist height at least) The positioning of the supports must allow the circuit board to be inserted into the case without stressing the board or pinching the installer's fingers. It must also be possible to remove the board.
As a telecommuter, you're not consuming any services from the other state.
If they get really sticky about it, just describe your home as a branch office (in which you are based) with all your office space and equipment being leased by you to the company in question.
Sorry, my opinion is if you are faster finding a bug with printf style then you never have learned how to use a debugger effectively.
I never suggested not learning a debugger at all. In fact I have learned and used many. I merely suggested that you should first learn to do without, so you don't cripple yourself in situations where debuggers are not available (such as new platform environments, or in debugging compiler optimization problems with released code) or not as useful (such as event driven, or heavily multi-threaded code). Using a debugger is only one possible tool. The most important one is the meat processor sitting between your ears.
Besides, these are students. Why does finding a bug faster really matter so much? From my experience it is only important when you are firefighting code most of the time, and you have to get it out the door because your customer and your manager are yelling. Shops that code this way are the worst sort of places to work.
A more important lesson is to create better code, so that your overall project has fewer bugs and can be delivered sooner by avoiding all that debugging of sloppy code. Not to mention giving a break to the poor overworked Q/A that has to test your code, or to the angry customer that ends up reporting the uncaught bugs. It also has the side benefit of reducing the cost of maintenance.
How should using printf teach you how to avoid bugs? Thats a very silly statement, either you LEARN how to avoid bugs or not. And basically you learn it by MAKINg the bugs and by fixing then later and finally by learning a bit about testing and design for testability .
By making it not so easy to debug through bad code,
your code quality will have to improve as a defensive measure.
Everyone is more willing to learn (or look for) advice when it will get them out of pain. Everyone is more willing to use good techniques when it will help avoid re-experiencing remembered pain. Think of it as accelerated learning. Using a debugger, will only defer the pain, and allow people to avoid fixing things. Sometimes, such code will only be discovered after someone leaves the team and the pain ends up being transferred to another. I don't know too many programmers willing to be that other. I've had to be that other too many times, I would love to be able to avoid a repeat.
These lessons are also better taught the sooner the better, when they don't have as much to unlearn, and the code they work with is relatively small and simple, and the consequences of not doing it right are relatively small. Plus, it helps teach them to look on their own for advice or solutions, communicating with others and doing research. In my experience, you can't have too much of that either.
If you use "for example" Visual Studio, yes the creation of the solution file is "sort of" automated (except for all the values that you have to put in through various dialog boxes). However try and add the solution file to a nightly build engine, the sort that a build engineer would use.
It's doable, but the component of the build which the solution file encompasses is not really visible to the rest of the automation script (the outer one controlling the overall build process). Ideally, for an automated build, you want to detect an error, report it and stop the build immediately (try building multiple branches using the continous build approach). This is not so easy with Visual Studio, that's why VS2005 has MSBuild. However, MSBuild suport was not added to the Visual C++ tools (the team was apparently busy fixing something else).
The only real alternative is to replace the automatically generated crap with a build script designed to be plugged in to something bigger.
At which point, you begin the awful game of keep-up with what the developers are putting into the "automated" script.
Personally, I like distinguish automatically generated scripts from automation enabling scripts by calling the first "automatic" and the second "automated".
IDE's are a crutch, and the make/build files they create
are not amenable to automation.
If you are teaching on Windows, Notepad is OK,
but Notepad++ is a good open source editor
with color syntax highlighting for various languages.
Unfortunately on Linux, the Editor should be vi (maybe not as a first editor).
It is available on almost any Unix like platform (even Windows)
I would also suggest not letting them use a debugger at first.
Use printf, System.out.prinln, Logging, Trace macro, whatever..
It improves the ability to deal with finding and fixing bugs,
as well as promoting a personal coding style that avoids bugs.
Test early, test often. Code a little, test a litle.
Write literate code, etc.
Using a debugger all the time is a crutch that makes it too easy to
not bother with working on your code quality.
And when they get to systems that don't have a debugger, they are clueless.
Slashdot Mirror
- -
But going beyond that, the way mobile devices are trending, and with just a little more acceptance from society with regards to telecommuting, I don't see why many people would even need to go in to the office most days. Even face to face meetings could be done in some temporary venue, like a nice coffee shop.
Once businesses realize that they don't have to spend all that money just to rent office space so they can stuff their employees into cubicle farms, well then ...
So are you only vulnerable if you use ISAPI ? It does look like that module is enabled by default though. I wonder why ?
Actually, according to the advisory, it seems you are only vulnerable if you actually load an ISAPI .dll module.
"it is possible to trigger a vulnerability in Apache mod_isapi that will unload the target ISAPI module from memory. However function pointers still remain in memory"
Even so, it's probably a good idea to comment out mod_isapi if you're not actively using it.
There's nothing two-factor about this solution.
Someone just has to steal (or take) the plastic thingie from you and now they can get in but you can't.
If you first had to login normally (using a memorized password) and second hold the plastic up to see the one time pad then you could say it was two-factor.
A two-factor key cannot be allowed to have just a single point of failure.
Then there is the recovery problem afterward. At least after a stolen housekey you can just bust in and then fix your door.
What do you do when the plastic thingie goes missing?
Do you need a back door? And how secure would that be?
Or can you get another plastic thingie exactly the same? Only to use it once to get in so you can then register another (uncompromised) one.
Not to mention that if you can get a replacement plastic thingie exactly the same, then maybe somebody else can too.
Rocketship Galileo-Heinlein
Space Cadet-Heinlein
Have Spacesuit Will Travel-Heinlein
Storm Over Warlock-Andre Norton
Star Rangers-Andre Norton
Slan-A.E. Van Vogt
The City and the Stars-Isaac Asimov
I Robot-Isaac Asimov
Lucky Starr series-Isaac Asimov
Childhood's End-Arthur C. Clarke
Expedition to Earth-Arthur C. Clarke
Brightsuit McBear-L. Neil Smith
Raiders From The Rings-Alan E. Nourse
Rocket to Limbo-Alan E. Nourse
Star Surgeon-Alan E. Nourse
The Counterfeit Man-Alan E. Nourse
Hospital Station-James White
Star Surgeon-James White
Hestia-C.J. Cherryh
Dragonflight-Anne McCaffrey
Dragon's Egg-Robert L Forward
Mission of Gravity-Hal Clement
Spacepaw-Gordon R. Dickson
Blackcollar-Timothy Zahn
Enemy Mine-Barry B. Longyear
And of course pretty much anything by E.E. Doc Smith, but specially the Lensman series.
I also consider Starship Troopers somewhere in there, but you have to consider that young boys won't really get the political side of it until they get older and re-read it.
I am assuming you want to improve your coding for maintainability and such.
However it is also reasonable to reserve your best coding efforts for code that will be used heavily by others, and spend less time on throwaway code.
Remember that the more code you put in, the fancier your coding structures get, the more comments that go unmaintained, the more difficult your code will be to follow.
Here are some rules you can follow that will help you no matter what language you use:
Rule #1: since the more code you put in, the worse it will be, it follows that putting in less code, or even removing some is always a good idea. Refactor your code mercilessly.
Rule #2: reduce your function/method argument counts where possible. You can group arguments together into a stucture, or hold some in member attributes as object state, but _only_ if it makes sense to do so. Passing _unrelated_ arguments through member variables can lead to a yo-yo coding style that is more difficult to follow and induce unwanted state on an object (ie. unnecessary coupling). Sometimes, to reduce argument count, it is easier to break up the method into multiple ones. Anything above 4 arguments should be reviewed. Anything above 6, you should make a serious attempt to reduce.
Rule #3: use proper english. Methods should start with a proper verb and be followed by adjectives and nouns. Proper spelling should be used. Avoid made up acronyms (Microsoft code is the worst for this)
The effect you are trying to achieve is to make your code literate (not quite so much as in Knuth)
Rule #4: make variable/argument/method names meaningful. The variable name should describe what it contains. eg. index, count, accumulator. Don't use short forms or single letters. If you can't come up with a good description, and it is a trivial variable, then you can do the Smalltalk trick of calling it after the type. e.g. aString, theNumber, anElement. If a method name is hard to understand, then someone trying to follow the code may have to do a lookup of some sort such as looking at the method comments if they are visible (or perhaps even calling the original coder) and it will break their focus. If you are in doubt about what to name something, go find a dictionary or a thesaurus. Don't just name it something junky and meaningless.
Rule #5: make the code obvious. No fancy coding tricks that lead newbies astray. Unless it can't be avoided.
Rule #6: comment only when not obvious. If the code is the least bit non-obvious (because it can't be avoided), then add a small comment above it or beside it. Otherwise, let the code speak for itself.
Too many comments that just repeat what is obvious make the code look like gibberish. And that volume of commenting usually gets out of sync with the code as it gets maintained by people passing through. Just comment the important and non-obvious stuff, and maintainers may be willing to update the comments too.
Rule #7: keep your functions/methods small. A good size to aim for is 5 lines of code. 30 lines can be OK if an algorithm warrants it. More than that and you need to consider splitting it apart.
Try to make the finer methods still meaningful/useful by themselves. Ideally, each function/method should be independent of the others. Make it obvious when they are not e.g. private adjustAmountHelper()
Practice the above rules faithfully and you will already see an amazing improvement.
If you want more rules than that, and you are on-side with your boss, you can try looking at a coding standard, such as
C++ Programming Guidelines, Plum and Saks
Despite the C++ in the name, the concepts in the book are fairly applicable to other languages as well.
I have had bosses that wouldn't endorse any coding style guidelines at all until I presented them with the Plum and Saks book. Some bosses just need to know they are not following your arbitrary standard, and presenting them with an actual book or website is all you need
No I didn't misspell "hole", I actually meant it.
Each product team, taken in context (the services and support from the rest of the company),
must be capable of providing skills to handle the whole picture.
Bigger companies provide more support skills for each team.
Bigger product teams provide more internal skills.
The required but missing skills form a hole that must be filled.
The development manager is the one that needs to plug this hole,
either by directly providing innate skills, by asking someone to train or by hiring someone where necessary.
For a manager to hire/fire and manage someone, they should have at least some knowledge of the skill topic,
so they are able to evaluate performance.
If you describe the capabilities of the existing team,
and of the available support (including the responsibilities handled by the product manager),
then a good manager should be able to spit back a list of the missing capabilities,
and a suggestion of how to approach filling the gap.
The specially creative ones, will be able to suggest more cost-effective solutions.
You should be able to ask the manager candidate to describe each of the skills/capabilities they mentioned
in more detail with examples, and to rough estimate (in time and money) of their approach.
The usual holes to consider (depending on the size and organization of the company)
are Q/A, documentation, build/release/configuration management/engineering,
project management, customer delivery and customer support.
One thing the development manager must specially have a handle on is the development process,
its state of affairs, what the missing parts are, and how it should/could be improved.
In a small (10 man) product oriented team, usually the development manager should also act as the technical lead,
and should be responsible for the technical (i.e. non-functional) requirements.
Ask them to describe some of these potential requirements.
Like any other manager, a development manager should
be able to lead their team and negotiate with other teams.
And beyond that, they should be able to present technical explanations.
So look for leadership, negotiation and presentation abilities,
as well as the ability to assess and apply motivation.
Other than this, a development manager should,
(again like any other manager) be a good cog in the reporting hierarchy.
They need to be able to conform to and enforce company policy as it trickles down,
and they need to be able to report issues/status/budget regularly upwards.
They also need to contribute their bit to the overall budget planning.
Check for communication, writing, budgeting and planning skills.
Look in their past history for ability to work within the organization.
In particular, a development manager should be aware
not to download too much of their reporting burden to their developers.
eg. daily 2 hour status meetings + individual developer reports.
Ask them their policy on what developers should be reporting and how often.
Lastly, whether their team already has the capability or not,
a good development manager should be able to contribute something to the overall design discussion.
They should be aware of other solutions out in the market, and of where to find answers.
Check for ability to design and ability to research (specially on the internet)
A lithium battery has very little lithium in it. Some of the lithium is already converted to lithium oxide.
Just remember that any fire needs 3 things: oxygen, fuel and heat. Remove any one and you kill the fire.
Also consider that the most important thing about a fire is how quickly it will expand. You can expect a fire to double in size roughly every 20 to 30 seconds if it has material available to burn.
1st - get someone else (if there is someone else) to call the fire department. If you fail to contain the fire, you need professionals help ASAP. If you are alone and you think you can handle it without taking chances, you can call the fire department after first trying to handle it. Use your judgement and stay calm.
If the fire is still small, just grab the device containing it and toss it into a empty (empty it out if necessary) metal trash can (or a clear area of concrete floor if available) and wait until the fire burns out. Do protect your eyes by avoiding looking at it as much as possible while you are holding it. If you have some sort of rubber or sufficiently thick cotton mat (like a fire blanket), you can use that to cover the fire and contain it until you can put it in the trash can. The mat may catch fire eventually, but it will be more resistant than most other things. Do not use a plastic sheet as plastic melts and if it gets on your skin it can cause some bad blistering. Once it is in the trash can do not cover it with something unless you are sure it is not flammable and will resist high heat - a fire is harder to fight if you cannot see it. Do monitor the fire in the garbage can to see that it does not grow.
Otherwise, if the fire is too big for you to carry the device containing the battery, the fuel for the fire is now overwhelmingly whatever it is sitting on or surrounded by, so fight that type of fire instead. The lithium left in the battery is irrelevant.
In any case, a large volume of water will cool any type of fire sufficiently to a more manageable level, and make most surrounding combustibles harder to ignite. The important thing to remember about using water is to turn off A/C power from wall sockets etc. first.
If at any point you feel you can't manage to handle the fire, just get out of the building in a calm manner and wait for the fire department. Make sure everyone gets out and keep people from returning inside.
how to list the world's problems.
Seriously. The database sucked.
If I wanted to find a problem to tackle, just finding a good one is problem enough.
How about getting the problems
-listed by multiple tags
-filterable by area of interest, and skillset required
-prioritized by relevance to science, to humanity, to marketability
-sorted by difficulty, number of extant participants
If you can't communicate why something is a problem, then you have two problems.
Sorry, too late by a couple of months.
After I gave up on it, I ripped it out and went with Mantis.
Whenever I installed Trac, I did install the distribution binaries, made sure all the libraries were compatible, and the database, binaries, etc. were set up as per the install instructions (possibly even correctly).
Maybe I could have chased down the problem eventually. However, they didn't seem to have the time,
and my time is fully committed to my own project. So I had to give up and find something else.
Maybe Trac will get better someday. I sure hope they do.
(they do have an interesting approach, and a good looking UI)
And if you it works for you. That's great. Go for it.
But until they do get better, people like me,
(who just need to get work done, without risking their data)
should avoid it and use something a little more stable.
I use Jira at work, and like it, but Jira is a bit expensive for a one man personal project.
So after looking around a bit on the net, I chose Trac and installed it on my home system to try it out.
Trac looked good. Had an interesting UI. The buzz on the net was favourable.
Took a little bit of effort to install, but then so did most other issue tracking systems.
So far so good.
I entered a few test issues. Still so far so good.
Then I tried to correct those issues. Change the issue type.
Even delete an issue.
All of these failed with the usual vague error messages and python stack traces.
So fine. I reported it.
Trac obviously wasn't ready to be used in a real situation.
No response to my issue for weeks.
In fact, several releases were made without my issue adressed.
Hmm, must have bigger fish to fry; time to look at their changelog.
Wow, lots of bugs in the changelog relating to stability.
In fact, they changed some of the underlying libraries and
according to their roadmap, were still scheduled to change even more.
Ok. So Trac really isn't ready for prime time,
they're still tinkering with architecture.
It's OK for people to play with, but not OK to rely on.
So I gave up on it and tried Mantis.
It installed reasonably well, and so far it handles most of the basics.
Not as pretty as Trac, but it gets the job done.
So far so good.
>I have met a lot of Sr.developers and very few of them have skills I would call 'Rock solid'.
Hmmm, I wasn't suggesting that other senior developers were not incompetent.
However, those types of senior developers usually get there by hanging on long enough
or by happy accident or even by knowing somebody.
I just assumed that the poster did not want to follow those avenues, since he did not know anyone,
had not yet had a happy accident, and didn't want to wait it out.
In any case, to avoid those avenues, which result in chancey dead end jobs at best,
and which are subject to being cleared out by the next "broom that sweeps clean" change in management,
then you need to be sufficiently competent.
The point is that those types of senior developers are not marketable outside their current jobs.
And they also have no real outward or upward mobility (except by hanging on to somebody else)
They are just the usual deadwood and mostly fade into the backrgound (incompetence likes to hide).
Sr. Developer is just a stepping stone to higher (developer) positions
which is what you want if you want to stay in development past a certain age.
However, since many companies refuse to promote staff from within at all,
sometimes you can only move up the ladder by moving to other companies.
Which is why I put such a big emphasis on marketabilty.
>The point is ageism, which is very serious issue in the software development industry.
>Just 2 years ago I was looking for work, and I experienced it very visibly.
Just 5 years ago and just 3 years ago I was also looking for work and both times I got hired immediately.
I am definitely no spring chicken, having 20+ years as a developer (and having started late in life at that).
I am certainly more than a fair target for what ageism lies out there.
My point is that ageism can be overwhelmed with competence,
I have done it repeatedly, I have also seen others do it, and have interviewed others needing to do it.
I was offering advice based on how it works for me when I do it,
and what works with me when I interview others.
It is just a matter of making them focus on what you bring to the table
rather than how many wrinkles you may or may not have.
If you walk into an interview believing you are too old, or not skilled enough,
then you are already defeated, and the interviewers will be able to tell.
And as for your issue with ageism existing in the industry.
I too have seen it everywhere, and not just for developers.
However, a lot (not all) of the times, you might be mistaking it for something else.
For example, if a developer with 12 years experience presents
with no time spent in a senior developer role (whatever the actual titles are),
then I seriously question their ability to grow and suspect a lack of motivation.
Lack of ability or willingness to grow is a big factor when I get "almost there" resumes
that are lacking a few of the items necessary to fill the position.
Personally, I never consider position titles in resumes until the interview.
At that point, I then dig into the matter to find out why.
Sometimes the title was not given even though the individual actually performed the role.
I usually go over their responsibilities so I can reverse engineer their effective (as opposed to nominal) roles.
However, I can see where other overwhelmed interviewers might not bother to give the applicant a chance.
Specially after the usual truck full of "not even close" and "did they even bother to read the ad" resumes.
>"I'm a programmer with more than twelve years of experience.
Ah. Very good. You're just getting started. This next part is where the fun begins.
>In all that time, I've never been a 'senior' developer.
Maybe you should try it. Being a senior developer implies you know skills beyond just coding.
(Of course, as a senior developer, your coding skills must already be rock solid)
At the very least you should be able to design your own modules (major feature sets)
and come up with additional requirements (that you can help deliver) when someone describes what they want.
You also need to be able to see the work through the full development lifecycle
to the bitter end and beyond into maintenance. (the full Monty)
For brownie points. Becoming the "go to" person is always a plus.
(Goto may be considered harmful in programming but it's really good for your career)
Mentoring others is a plus. Being able to contribute to design discussions is a plus.
>I'm competent and I work hard, but I don't think I am quite a senior developer in terms of technical or people skills.
Programming is not all that developers do. Working hard is not enough. Work smart instead.
Older developers can't compete on volume, we have to do it on efficiency and quality.
You need to be able to consistently show good results, and ideally with as little wasted effort as possible.
If you're always working hard then you have no time to take on additional tasks.
You can't be the goto guy (or girl) if you're always up to your neck.
>More and more I feel that I'm aging myself out a job.
If you feel old then you will be old. Developing software is a game of the mind.
The more you learn, the more you realize there is still to learn, and the younger your mind.
A "young" mind can live in an old body, and vice versa.
Being young in mind means you are still able to learn.
Managers that equate physical to mental age are best avoided anyways.
If their their judgment is bad in that regard, it will likely be bad in others.
When I get involved in hiring people, I always look for those
who show a consistent ability and interest in learning new things.
People who are young may get a temporary free pass, since they have no real history to be examined,
and since the basic assumption is that they are still capable of learning.
But if they show a decided lack of capacity to learn, that free pass evaporates quickly.
In any case, the more experience you have, the more you can compete.
Not by coding; coding inexpertly applied is only wasted effort.
You have to know where to apply the effort.
If you leave this up to your managers, who do less programming than you,
and if you don't suggest anything, then what does this say about your competence as a developer?
>By this time, employers expect someone with my experience to have advanced some,
>and they may not be willing to even talk to me now, thinking that my pay requirements have grown while I have not.
You need to deliver enough skills that what they assume your pay requirement to be will be considered a bargain.
If you deliver additional skills that they can't do without (new something-or-other must-have technology)
then you will be able to ask for more money than they expect from your age based requirements.
>Even if I did get hired someplace new, my peers would likely be much younger than me.
So what? Don't you like to work with young people too?
Some are good looking. Others are pleasant to work with. Some are quite smart.
Just like some older folk.
In any case, unless you are in management. All your non-management co-workers are peers.
If you want to work as a non-manager as you get older,
you will need to deal with some and eventually all of your peers being physically younger.
Time is a one way street (so far). You have to deal with its effects.
>What do you do when
Software going into production systems belongs to IT. End of story.
IT should treat Development just like any other software vendor.
If vendor representatives are there at the production site, it is only to offer help at the behest of the customer
(which in this case is IT). Nothing goes into the systems directly from the vendor without being vetted by the IT guys.
If the product has bugs, it needs to be treated by development at least as seriously as with any other important customer.
What this means therefore, is that IT has to have enough people on staff that can understand and maintain the deployed system.
The usual problems here are that
1) a lot of IT staff don't want to learn a new system (specially one that is in-house and doesn't give transferable skills) -> The answer here is to suck it up and replace them with someone more willing to learn the required systems.
2) development doesn't treat IT as a real customer (it's only IT) and releases shoddy code that needs frequent updating -> The answer here is for IT to do a formal acceptance test and reject the software if it is not ready for prime time (with high visibility to upper management). Ideally, these formal acceptance tests should not be scheduled too often, so that deployments can be better spaced out to force development to actually plan and design what is going to be in each release before they toss it over the wall.
3) IT doesn't see itself as having a stake in the deployed software. Since the software comes from development, and IT had no choice in its selection, any success makes development look good and does nothing to make IT look good. IT treats the situation as forced babysitting. -> the answer here is for IT to treat it like any other deployed system upon which they are dependent for success. Any bugs, or problems in the system should be reported to the "vendor". Anything which IT thinks could be done better should be sent back to the vendor as a requirement (to be assessed by the product manager to be sure).
If the company is too small to have very many people, then you can dual-role some people with the required skills,
but the job roles have got to be kept separate even if in the same person. You need people who can change hats and role-play effectively here so that oversight boundaries are not erased.
In software, as in so many other venues, good fences do make good neighbours.
The premise of Planetes (a.k.a. Trashmen in Space) is that so much garbage will be put into orbit around Earth that it becomes dangerous to space traffic and we will need a dedicated "Space Debris" division to control it.
http://en.wikipedia.org/wiki/Planetes
And so, it begins.
Maybe they're a couple of Fourth Imperium battle planetoids in parking orbit.
Now we just need to figure out how to get over there and hotwire those babies.
I haven't been involved in hardware since 1991 (I do exclusively software now), so my info is quite dated. I was involved in doing the purchasing and kitting (I dealt with all the suppliers), the hardware/software testing, and some of the software development (we were a startup, and in those days everybody had more than one role). I'm not sure that the small electronics industry has survived in the form I remember.
:-) so they should be relatively local.
o sures-United-States.html
Back in 1991, one of our (electronics) hardware guys also had a talent for doing enclosure design. But even so, our needs were not as extensive as yours (we were not producing a handheld device)
If you mockup a general drawing of the device, most machine shops won't have the expertise on board to think the rest of it through (unfortunately)... although you might luck out.
It would be better to subcontract to somebody who could do the mechanical design (who was familiar with electronic devices). Meeting the required dimensions and mechanical support requirements is only part of the work. You also need to deal with styling and ergonomics. There are companies out there that specialize in the styling (as your case "look" is one of the components of brand identity)
Unfortunately, I can't really guide you very well on how to go about finding the right sort of person for this. You would probably need at least some face time, to include gestures along with pictures
If you live in the US (I do not), you may want to try some company similar to those listed here (I have no idea if these are any good or if they are capable of delivering the full Monty, they just seem to be in the general ballpark)
http://www.mfgquote.com/profiles/Electronics-Encl
If they are very good (and plugged into the industry), they would also be aware of local fabs that could do the actual work. (be careful if they have their own fab - they will plug it shamelessly and will not mention any serious competitors)
Don't hesitate to ask everyone you come in contact with (in the industry) to let you know who the other players are that they deal with, or have heard of, and what their reputations are.
In any case (pardon the pun) I wish you well in your quest. Hardware is a grand adventure (OK quite a few grand).
Illegitimi non-carborundum.
I don't know if by "I have the basics for what I need such as what OS, and platform I will base it on (motherboard" you mean to say that you already have selected/designed/tested/certified the actual motherboard.
Assuming you haven't done that (since it implies the case size will be constrained by your already selected board), you need to do some serious electronics work to get the circut board to a suitable shape and size for your handheld.
Once you have it working on your desk, you need to do the following to make it suitable for hand held operation.
Standard disclaimer: IANAEE
1) reduce the size and weight
Select smaller components (like the ones that go into wave solder machines), change the layout, consider a multilayer board (more layers = more mfg cost and more difficulty in layout design) Smaller board = smaller case
Note: remember that anything at the edge of the board can get dinged by the installer as they put the board into the case.
It is good to establish beforehand your desired/target size and weight even if you don't quite achieve it right away.
2) determine the battery/power source that you are going to use with it.
If it is re-chargeable, determine if the charger is ouside or inside the handheld case. Some power sources require additional shielding for safety if the battery contents should leak. You need to be able to provide sufficient operating time and standby time (baterries leak current slowly even when off). Standby time must be at least 1 day or more (ideally 4 days - a long weekend). Standby power needs to account for anything that must remain powered up - such as memory, always on components etc.
3) reduce the power draw
You may need to select low power versions of the components and if you have too many discretes, you may want to push them into a PAL or an ASIC
(note: ASIC design/prototyping can cost quite a bit, so you may want to defer it to version 2.0)
It is good to establish beforehand your desired/target power draw even if you don't quite achieve it right away.
4) design your circuit layouts carefully
You need to account for timing issues due to signal lag, power up issues due to the timing of what power lines come on first (which depends on the load for each line) And you need to measure and reduce signal noise enough to prevent signal interference. You have to account also for any parts that may get hot (nearby parts may not like it) You also need to confirm with you board manufacturer that your layout meets their specifications. And you need to check with the board assembly guys that they can assemble the parts in (by robot) and wave solder the board - otherwise you will need manual assembly or manual soldering (very bad).
5) account for heat dissipation from the case and from the hot parts
Should not too much of a problem for something that should be handheld.
However, if it is warm enough to notice by touch, you may need to insulate the handgrip. If you need to stimulate a part to get it hot, you may need to create a signal gererator or write some testing software to generate the signal to heat up the part. If you can, test the heating of the part until you see its failure mode. Ideally, it should just stop working until it cools down again. A worse outcome is that it lets out the magic smoke or even starts a fire. If this is an issue, you may need to add in some thermal monitoring and regulation (usually, you just select better parts).
6) make sure the circuit board has holes drilled for support
The holes should allow for firm support without twisting or pulling.
Rubber gaskets/grommets can reduce the transmission of shock.
You need to do a drop test (from waist height at least)
The positioning of the supports must allow the circuit board to be inserted into the case without stressing the board or pinching the installer's fingers.
It must also be possible to remove the board.
7) design the case case layout carefully
First enbugging (typing, coding, a.k.a. putting bugs into code), then debugging (finding them to take them out).
Perfectly circular, like Yin and Yang.
Since the action of coding the bugfixes falls on to the enbugging side, there is a strong possibility of achieving perpetual programming :-)
Job security... of a sort.
As a telecommuter, you're not consuming any services from the other state.
If they get really sticky about it, just describe your home as a branch office (in which you are based) with all your office space and equipment being leased by you to the company in question.
I never suggested not learning a debugger at all. In fact I have learned and used many. I merely suggested that you should first learn to do without, so you don't cripple yourself in situations where debuggers are not available (such as new platform environments, or in debugging compiler optimization problems with released code) or not as useful (such as event driven, or heavily multi-threaded code). Using a debugger is only one possible tool. The most important one is the meat processor sitting between your ears.
Besides, these are students. Why does finding a bug faster really matter so much? From my experience it is only important when you are firefighting code most of the time, and you have to get it out the door because your customer and your manager are yelling. Shops that code this way are the worst sort of places to work.
A more important lesson is to create better code, so that your overall project has fewer bugs and can be delivered sooner by avoiding all that debugging of sloppy code. Not to mention giving a break to the poor overworked Q/A that has to test your code, or to the angry customer that ends up reporting the uncaught bugs. It also has the side benefit of reducing the cost of maintenance.
How should using printf teach you how to avoid bugs? Thats a very silly statement, either you LEARN how to avoid bugs or not. And basically you learn it by MAKINg the bugs and by fixing then later and finally by learning a bit about testing and design for testability .
By making it not so easy to debug through bad code, your code quality will have to improve as a defensive measure. Everyone is more willing to learn (or look for) advice when it will get them out of pain. Everyone is more willing to use good techniques when it will help avoid re-experiencing remembered pain. Think of it as accelerated learning. Using a debugger, will only defer the pain, and allow people to avoid fixing things. Sometimes, such code will only be discovered after someone leaves the team and the pain ends up being transferred to another. I don't know too many programmers willing to be that other. I've had to be that other too many times, I would love to be able to avoid a repeat.
These lessons are also better taught the sooner the better, when they don't have as much to unlearn, and the code they work with is relatively small and simple, and the consequences of not doing it right are relatively small. Plus, it helps teach them to look on their own for advice or solutions, communicating with others and doing research. In my experience, you can't have too much of that either.
It's doable, but the component of the build which the solution file encompasses is not really visible to the rest of the automation script (the outer one controlling the overall build process). Ideally, for an automated build, you want to detect an error, report it and stop the build immediately (try building multiple branches using the continous build approach). This is not so easy with Visual Studio, that's why VS2005 has MSBuild. However, MSBuild suport was not added to the Visual C++ tools (the team was apparently busy fixing something else).
The only real alternative is to replace the automatically generated crap with a build script designed to be plugged in to something bigger. At which point, you begin the awful game of keep-up with what the developers are putting into the "automated" script.
Personally, I like distinguish automatically generated scripts from automation enabling scripts by calling the first "automatic" and the second "automated".
IDE's are a crutch, and the make/build files they create are not amenable to automation.
If you are teaching on Windows, Notepad is OK, but Notepad++ is a good open source editor with color syntax highlighting for various languages.
Unfortunately on Linux, the Editor should be vi (maybe not as a first editor). It is available on almost any Unix like platform (even Windows)
I would also suggest not letting them use a debugger at first.
Use printf, System.out.prinln, Logging, Trace macro, whatever.. It improves the ability to deal with finding and fixing bugs, as well as promoting a personal coding style that avoids bugs. Test early, test often. Code a little, test a litle. Write literate code, etc.
Using a debugger all the time is a crutch that makes it too easy to not bother with working on your code quality. And when they get to systems that don't have a debugger, they are clueless.
Not only that, but they can stop hiring all those pesky techies and turn the USPTO into a patent lawyer's club. No subject matter expertise necessary.
Hmm, I believe you are confusing "nonsense" with "malice" and possibly even "greed".
Unfortunately, they don't go away as easily as "nonsense".
---
I don't think that word means what you think it means.
So what I want to know is... how many Sunday Sermon TV jockeys are on the list? Now _there's_ one for Conan O'Brien.