In light of this it's looking more like an intimidation tactic:
Routers have to report their connection lag to other routers when establishing a connection, and the other routers will in the end decide if to go through them or around them.
A business model where ISPs would charge some providers more would rely on them paying; not doing so would make the ISP's routers be avoided automatically since they would bottleneck the connection.
I think for this scheme to work they would have to hack into the infrastructure at router level (or they'd get themselves out of business)
One of the best things things to do for getting rid of overload is to dump the decision on the head of your manager.
When he brings you an extra task (that would require you to work overtime) put him in an or-or situation and make him decide on something to leave behind;
Say
I'm currently working on blabla, due this evening; If I start on the new task I won't finish blabla in time. Which one should I defer?
It is an elegant way of enforcing to your manager the fact that you won't work overtime (or that at least you don't expect to do it on a regular basis).
We had to maintain a big repository of C and C++ code that was cross-platform; that meant that you opened the same file with visual studio and it looked ok, changed a like and when you opened it under solaris the indentation got all wrong because VS inserted tabs instead of spaces.
One of our rules was to set all editors to put 4 spaces for tab length and never use tabs.
Make sure naming conventions are allways followed. The best way to do this is to have an approver/reviewer of all changes (we had senior developers do that).
If using hungarian notation use the Apps Hungarian notation instead of the Systems notation. The reason for this is that while systems documents code functionality Apps documents code purpose. And make sure to have your coding conventions well documented and used consistently.
Make sure to fix changes where code is wrong and where feasible, don't use work-arounds. When using workarounds the project becomes un-maintainable and developers get to hate it.
Also, never leave in code blocks that never get executed; We have an old project around here that is full of code like:
if(0)
do_something
else
do_something
It's a nightmare to maintain: you have to go through lots of useless garbage because some nameless programmer in the past was affraid of deleting the wrong code.
Make a practice of enforcing the rules: i've seen an office where the people breaking the build had to buy the team some snacks the next day:).
Forbid spagetti code constructs (like goto) and enforce consistency of look and feel (for example we had all if statements being followed by braces even when there was a single statement under it, and all 'case's in a switch had to have a break statement).
Make sure every change is well documented and as speciffically as possible; create a standard for documenting changes in your version control system that should describe the purpose of the change and the contents of the change; For example:
Purpose: fix defect ID12345
Description: Added new function int Foo(int); centralized ID length to local constant ID_LENGTH;
Make sure every change is clean: If you diff two revisions of the same file with any file diffs utility you should be able to see only the semantically different code; Like this it's easy to follow when the code causing you problems was added and for what purpose. This is a dream come true when maintaining code: then you can see what defect/enhancement it was introduced for and you can follow that by ID to some external documentation.
Enforce refactoring: If a change requires the same two lines of code used elsewhere add a new function for them.
Slashdot Mirror
What are the chances of Vista coming with preinstalled Duke Nukem Forever?
Mod parent up.
In light of this it's looking more like an intimidation tactic:
Routers have to report their connection lag to other routers when establishing a connection, and the other routers will in the end decide if to go through them or around them.
A business model where ISPs would charge some providers more would rely on them paying; not doing so would make the ISP's routers be avoided automatically since they would bottleneck the connection.
I think for this scheme to work they would have to hack into the infrastructure at router level (or they'd get themselves out of business)
Actually, I think we can all agree that this would be a big improvement.
Mod parent up!
When you put it like that it starts sounding like a "protection" tax. Sort of like:
I'm the boss in the neighbourhood! If you want to keep your grocery open, you'd better pay for local protection!
just forward them to the proffessionals.
"But how does it *taste*?"
It's hard to say: they gave it to some test subjects but none of them said much after tasting it; They're still looking into the matter.
...and having sex with as many people as possible too... Yes please! :)
I am throwing away my keyboard and replacing it with a new device called the Keyboard!
One of the best things things to do for getting rid of overload is to dump the decision on the head of your manager.
When he brings you an extra task (that would require you to work overtime) put him in an or-or situation and make him decide on something to leave behind;
SayIt is an elegant way of enforcing to your manager the fact that you won't work overtime (or that at least you don't expect to do it on a regular basis).
" ... and the second must include links to competitors."
... after a while 'links to competitors' just pop up on your screen.
Isn't that a given if you use IExplorer? I mean
We had to maintain a big repository of C and C++ code that was cross-platform; that meant that you opened the same file with visual studio and it looked ok, changed a like and when you opened it under solaris the indentation got all wrong because VS inserted tabs instead of spaces.
One of our rules was to set all editors to put 4 spaces for tab length and never use tabs.
Make sure naming conventions are allways followed. The best way to do this is to have an approver/reviewer of all changes (we had senior developers do that).
If using hungarian notation use the Apps Hungarian notation instead of the Systems notation. The reason for this is that while systems documents code functionality Apps documents code purpose. And make sure to have your coding conventions well documented and used consistently.
Make sure to fix changes where code is wrong and where feasible, don't use work-arounds. When using workarounds the project becomes un-maintainable and developers get to hate it. Also, never leave in code blocks that never get executed; We have an old project around here that is full of code like:
if(0)
do_something
else
do_something
It's a nightmare to maintain: you have to go through lots of useless garbage because some nameless programmer in the past was affraid of deleting the wrong code.
Make a practice of enforcing the rules: i've seen an office where the people breaking the build had to buy the team some snacks the next day :).
Forbid spagetti code constructs (like goto) and enforce consistency of look and feel (for example we had all if statements being followed by braces even when there was a single statement under it, and all 'case's in a switch had to have a break statement).
Make sure every change is well documented and as speciffically as possible; create a standard for documenting changes in your version control system that should describe the purpose of the change and the contents of the change; For example:
Purpose: fix defect ID12345
Description: Added new function int Foo(int); centralized ID length to local constant ID_LENGTH;
Make sure every change is clean: If you diff two revisions of the same file with any file diffs utility you should be able to see only the semantically different code; Like this it's easy to follow when the code causing you problems was added and for what purpose. This is a dream come true when maintaining code: then you can see what defect/enhancement it was introduced for and you can follow that by ID to some external documentation.
Enforce refactoring: If a change requires the same two lines of code used elsewhere add a new function for them.