1 - be cautious about testing debug mode - there's an awful lot the compiler tosses in to enable debugging which may impact how the code actually executes. 2 - use logging extensively. I'd recommend using log4net or something like that. 3 - use an integration model for your unit testing. Start with the smallest unit tests and build upwards. This will allow you to gradually build "correct" code and focus on the messages/events between components. 4 - build a simulator (someone mentioned that before), they are truly invaluable. Keep it as simple as possible. 5 - check, double check, and triple check variable access. It's easy to run into a race condition between reads and writes. Study and understand lock(...), reader-writer-locks, semaphores, and mutexes. 6 - when testing, don't forget to test expected conditions, unexpected conditions, boundary conditions (null objects, empty strings, negative values, 0's, positive values, and overflows), errors (like zombie conditions where a response is _never_ generated, dropped connections, garbage results), etc. 7 - learn Debug.Assert and check your pre- and post-conditions 8 - if you use strings, make sure you understand how strings and stringbuilder operate - they can have dramatic differences in efficiency/memory utilization/and GC. 9 - events can be static, and don't forget to encapsulate your event accessors (they look like properties, but instead of get/set, they're add/remove) 10 - if you plan on using compiler optimization switches, use them last during testing - after you can prove the app works correctly. Optimization switches can dramatically reorder things which is definitely not good if you're trying to determine correctness. 11 - set the compiler to give the maximum warning level. Your app should generate no warnings or errors while compiling. 12 - walk through the code with someone to double check your logic and field access. If you can convey it to someone else either through comments, design, etc., and can justify all field accesses as well as access control, you'll be in good shape. Yes, this is peer review. It's even useful to haul in a project manager that knows nothing about coding and nods like a chicken. Listen to yourself as you talk and if you stumble or have a hard time explaining something, that's a hint that a redesign might be in order. 13 - you might want to put in some profiling counters so you can capture metrics on it. This way, as you change the code over time, you can almost quantifiably determine if the code is truly improving with respect to throughput, responses, etc. or not.
Quoth Opera's PR page
"It was cold and wet and horrible and I was really, really scared," says Eskil Sivertsen, Opera's PR Manager who operated the raft. "The night had been crisp and starlit, and we had fallen asleep in the raft to the gentle movement of the waves. In the morning, I gave Jon two chocolate bars and some of those mini carrots he likes so much before he..."
Is there something going on between Silvertsen and von Tetzchner?
I'm half expecting some sort of talk about them laying on their beds, feet kicking in the air, as they talk on their princess phones to each other while listening to NSync.
Yes, Co-Ops are short term. They typically last 3 months or so at a stretch. It takes more time to become completely involved in a single company. If you've co-op'd at the same company for 7 semesters, consider yourself lucky. You're on your way to understand the policies, processes, and procedures within that company, and making yourself a significant hire for them when you graduate.
What I'm trying to convey is the co-op is, of itself, not necessarily bad - it's just not deep enough. A co-op to a multi-year project is like your semester project is to your co-op - a different order of magnitude. I doubt you co-op'd at a single company for 7 semesters in a row - if you did, you'd understand the difference.
Also consider this - as a student, are you aware of the duties a typical technical lead has? How about a project manager? Quality Assurance (hint-QA in terms of the CMM has nothing to do with how "good" a software product is, that's the job of quality control)? If not, how do you know if you want to become one? If you do, why in the world would you want one of those thankless jobs?
One point I disagree with is "...projects a company can provide that can be completed in 12 weeks.." If you break an overall project into discrete tasks, each task can be considered an "independent" project which can be completed in that timeframe. Overall, the individual mini-projects can be integrated into the final deliverable project. This is done all the time through a work breakdown structure. Give tangible milestones, appropriate overight, and it can be done.
Yes, the company would have significant risk in project completion, however there would be little financial risk - staff time in relaying the requirements, status reports, etc. You get what you pay for. It would clearly mean a donating company would have to be careful in what kind of project idea to donate. Overall, I'd consider the project risks worth it. I'd suggest that the IP issues involved would be much more cumbersome.
I am a lead, and I do hire grads. I'm merely extremely frustrated that I have to train people to recognize what a function is (yes, over the years I've run across at least two folks with Master's degrees that didn't know what one is) and that development is more than clicking on buttons (you actually should know what's going on in the background). I'm looking for folks that are curious about it, have a willingness to explore and understand, and are self motivated to continue to learn in our vast field.
I'm not really lowering internships. Internships are really useful; they can be, however, extremely resource draining on a company. It takes a lot of care and feeding to get an intern up to speed on a project, up to speed on the corporate policies, processes, procedures, standards, auditable artifacts, automation systems, etc. Once an intern shows promise and has successfully integrated into the team, THAT'S where the benefit is - an already trained (in real world stuff) and inducted new employee.
A long term project is one that is multi-year, full time project with a full team compliment. They're very different than a one year project, particularly so if the multi-year project is running under CMM/I/ISO compliance.
You have got to be kidding. Where in the world are these Geniuses? I'm having a hard time finding someone that knows what a foreign key is. Heaven forbid I ask a question about the difference between an interface and a class and when you'd choose one over the other. They're about to flee when I ask how.Net garbage collection works.
The only kinds of developers I run across are the kind that "know what button to click" and who are snippet programmers - that being someone who either grabs some code from somewhere and randomly changes it, clicks the compile button like a rabid dog, and hopes it works.
Version control is a foreign concept to them, unit testing is, too. Each young guy I get invariably think they're God's gift to development and haven't a clue about what development really is.
Part of the problem, I'd guess, is the unrealistic crap that's fed to them in college. How about instead of writing a new crappy shopping cart, run the classroom like a major project. Hell, there's plenty of work to do and I'm sure some company that needs a new app would be willing to outsource it to a college for development. That'll give some level of experience in requirements elicitation/management/tracing, project management/tracking/oversight, all the testing, not to mention deployment experience. That'd be useful stuff, especially if actually run under a CMM/I/ISO structure.
I'm not talking about an intership, CO-OP or other short term thing. A full fledged project with real, tangible consequences.
Another thing that really should be in there is a listing of tradeoff criteria for the design. If they're documented, reviewers/developers can have a better appreciation for how the design evolved and what thought processes were followed and why particular constructs were chosen.
The 1st Ammendment doesn't protect a citizen from being responsible for what they say - there still is accountability. It only prevents the creation of a law.
Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances."
It helps to actually read the Ammendments beforehand.
What happens if you toss out/donate/give away a printer to a "bad guy"? The original owner gets nailed if that printer is "misused"? I got it - the FBI tracks printers just like firearms (they do it and supposedly illegally keep the records).
I never knew my HP5L was such a dangerous thing....
Lesson Learned: Don't get a beige colored computer. Drunk roommates tend to get lost on their way to the bathroom and pee on them. Yes, it actually happened.
Slashdot Mirror
For what it's worth:
1 - be cautious about testing debug mode - there's an awful lot the compiler tosses in to enable debugging which may impact how the code actually executes.
2 - use logging extensively. I'd recommend using log4net or something like that.
3 - use an integration model for your unit testing. Start with the smallest unit tests and build upwards. This will allow you to gradually build "correct" code and focus on the messages/events between components.
4 - build a simulator (someone mentioned that before), they are truly invaluable. Keep it as simple as possible.
5 - check, double check, and triple check variable access. It's easy to run into a race condition between reads and writes. Study and understand lock(...), reader-writer-locks, semaphores, and mutexes.
6 - when testing, don't forget to test expected conditions, unexpected conditions, boundary conditions (null objects, empty strings, negative values, 0's, positive values, and overflows), errors (like zombie conditions where a response is _never_ generated, dropped connections, garbage results), etc.
7 - learn Debug.Assert and check your pre- and post-conditions
8 - if you use strings, make sure you understand how strings and stringbuilder operate - they can have dramatic differences in efficiency/memory utilization/and GC.
9 - events can be static, and don't forget to encapsulate your event accessors (they look like properties, but instead of get/set, they're add/remove)
10 - if you plan on using compiler optimization switches, use them last during testing - after you can prove the app works correctly. Optimization switches can dramatically reorder things which is definitely not good if you're trying to determine correctness.
11 - set the compiler to give the maximum warning level. Your app should generate no warnings or errors while compiling.
12 - walk through the code with someone to double check your logic and field access. If you can convey it to someone else either through comments, design, etc., and can justify all field accesses as well as access control, you'll be in good shape. Yes, this is peer review. It's even useful to haul in a project manager that knows nothing about coding and nods like a chicken. Listen to yourself as you talk and if you stumble or have a hard time explaining something, that's a hint that a redesign might be in order.
13 - you might want to put in some profiling counters so you can capture metrics on it. This way, as you change the code over time, you can almost quantifiably determine if the code is truly improving with respect to throughput, responses, etc. or not.
That's all I can think of off the top of my head.
Good luck, it's a fun journey.
they are Unisys mainframe systems often running Java.
this post will get a +4 funny.
Don't forget the 4th here
CLGFreeBSD?
Quoth Opera's PR page "It was cold and wet and horrible and I was really, really scared," says Eskil Sivertsen, Opera's PR Manager who operated the raft. "The night had been crisp and starlit, and we had fallen asleep in the raft to the gentle movement of the waves. In the morning, I gave Jon two chocolate bars and some of those mini carrots he likes so much before he..." Is there something going on between Silvertsen and von Tetzchner? I'm half expecting some sort of talk about them laying on their beds, feet kicking in the air, as they talk on their princess phones to each other while listening to NSync.
Yes, Co-Ops are short term. They typically last 3 months or so at a stretch. It takes more time to become completely involved in a single company. If you've co-op'd at the same company for 7 semesters, consider yourself lucky. You're on your way to understand the policies, processes, and procedures within that company, and making yourself a significant hire for them when you graduate.
What I'm trying to convey is the co-op is, of itself, not necessarily bad - it's just not deep enough. A co-op to a multi-year project is like your semester project is to your co-op - a different order of magnitude. I doubt you co-op'd at a single company for 7 semesters in a row - if you did, you'd understand the difference.
Also consider this - as a student, are you aware of the duties a typical technical lead has? How about a project manager? Quality Assurance (hint-QA in terms of the CMM has nothing to do with how "good" a software product is, that's the job of quality control)? If not, how do you know if you want to become one? If you do, why in the world would you want one of those thankless jobs?
I understand several of your points.
One point I disagree with is "...projects a company can provide that can be completed in 12 weeks.." If you break an overall project into discrete tasks, each task can be considered an "independent" project which can be completed in that timeframe. Overall, the individual mini-projects can be integrated into the final deliverable project. This is done all the time through a work breakdown structure. Give tangible milestones, appropriate overight, and it can be done.
Yes, the company would have significant risk in project completion, however there would be little financial risk - staff time in relaying the requirements, status reports, etc. You get what you pay for. It would clearly mean a donating company would have to be careful in what kind of project idea to donate. Overall, I'd consider the project risks worth it. I'd suggest that the IP issues involved would be much more cumbersome.
I am a lead, and I do hire grads. I'm merely extremely frustrated that I have to train people to recognize what a function is (yes, over the years I've run across at least two folks with Master's degrees that didn't know what one is) and that development is more than clicking on buttons (you actually should know what's going on in the background). I'm looking for folks that are curious about it, have a willingness to explore and understand, and are self motivated to continue to learn in our vast field.
I'm not really lowering internships. Internships are really useful; they can be, however, extremely resource draining on a company. It takes a lot of care and feeding to get an intern up to speed on a project, up to speed on the corporate policies, processes, procedures, standards, auditable artifacts, automation systems, etc. Once an intern shows promise and has successfully integrated into the team, THAT'S where the benefit is - an already trained (in real world stuff) and inducted new employee.
A long term project is one that is multi-year, full time project with a full team compliment. They're very different than a one year project, particularly so if the multi-year project is running under CMM/I/ISO compliance.
You have got to be kidding. Where in the world are these Geniuses? I'm having a hard time finding someone that knows what a foreign key is. Heaven forbid I ask a question about the difference between an interface and a class and when you'd choose one over the other. They're about to flee when I ask how .Net garbage collection works.
The only kinds of developers I run across are the kind that "know what button to click" and who are snippet programmers - that being someone who either grabs some code from somewhere and randomly changes it, clicks the compile button like a rabid dog, and hopes it works.
Version control is a foreign concept to them, unit testing is, too. Each young guy I get invariably think they're God's gift to development and haven't a clue about what development really is.
Part of the problem, I'd guess, is the unrealistic crap that's fed to them in college. How about instead of writing a new crappy shopping cart, run the classroom like a major project. Hell, there's plenty of work to do and I'm sure some company that needs a new app would be willing to outsource it to a college for development. That'll give some level of experience in requirements elicitation/management/tracing, project management/tracking/oversight, all the testing, not to mention deployment experience. That'd be useful stuff, especially if actually run under a CMM/I/ISO structure.
I'm not talking about an intership, CO-OP or other short term thing. A full fledged project with real, tangible consequences.
Another thing that really should be in there is a listing of tradeoff criteria for the design. If they're documented, reviewers/developers can have a better appreciation for how the design evolved and what thought processes were followed and why particular constructs were chosen.
But I'm a colorblind pilot, you insensitive clod!
The artist would call that an apartment complex.
Maybe they're out getting stoned on legalized marajuana?
It didn't even take a day
"...can do remote massages with Asterisk!" Remote massages? Sounds like it could be better than this. I'll have to look into both feature lists.
The 1st Ammendment doesn't protect a citizen from being responsible for what they say - there still is accountability. It only prevents the creation of a law.
Quoted from The Reporters Committee for Freedom of the Press:
"The First Amendment
Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances."
It helps to actually read the Ammendments beforehand.
NPR already covered it.
What happens if you toss out/donate/give away a printer to a "bad guy"? The original owner gets nailed if that printer is "misused"? I got it - the FBI tracks printers just like firearms (they do it and supposedly illegally keep the records).
I never knew my HP5L was such a dangerous thing....
Being an IT manager, I don't see the difference - it's still crap.
Wix
and
WTL
- 15 open defects
- 13 assigned (pretty good, eh?) to 3 developers
- 11 of those 15 open for more than 30 days.
I wonder what the incentive is for a MS employee to work on these projects?> a super-anal type who nitpicks over everything
Yes? You needed something from me? Btw, it's called being anal retentive .
Lesson Learned: Don't get a beige colored computer. Drunk roommates tend to get lost on their way to the bathroom and pee on them. Yes, it actually happened.
I've never heard of it until it was reported on National Public Radio two days ago on All Things Considered
(cool! They're running Apache/PHP on Linux)
No! THIS is comparing apples and oranges!