Long after DARPA's research, commercial entities such as AOL, Prodigy, and CompuServe had their own ideas about how computer networks should function. If a commercial entity had invented the Internet it would have functioned like the AOL of 1993 where all content has to be approved by a single corporation. That corporation would collect a tax on all transactions. It would kick out anyone it did not agree with. It would be far, far different than the Internet we have today and it would have undoubtedly happened much later.
Use a square bull pen arrangement with work surfaces around the inside of the square. Put a single round table in the middle for collaborative meeting/discussions.
If programmers have to share an office, this would be the ideal arrangement. Its very space efficient (more so than sitting opposite each other), and its easy to collaborate by simply turning around and talking to your teammates. Furthermore, theres plenty of space behind each team members computer for everybody to stand or sit around and work on something together.
It must be said that distractions are hell though. Sartre said, "Lenfer, cest lest autres." Damn right he was.
We've been doing Scrum for a while now at my company, and one of the conclusions we've reached is that you should never make the tech gurus the scrum masters. And that conclusion is totally independent from who you *do* want to make scrum masters, just don't pick the technical guru. The reason? Tech gurus tend to be the technical core of the team, everbody asks them deep technical questions all day long, they also have the responsibility of building the most complex technical features that nobody else can really do, which means that they spend their days entrenched in the core technical stuff of the project *which is exactly the opposite of where the scrum master should be*. The scrum master should, ideally:
1. Be able to keep some distance, what we call a "helicopter view". (Note how being entrenched in technical details doesn't fit well here?)
2. Consider the progress of items and tell people when they have unrealistic estimates of whether their items are likely to be "done" at the end of the Sprint, according to the Definition of Done that was agreed on with the Product Owner. (Again, something that requires not being entrenched in the details of technical stuff.)
3. Be able to talk to management about items on a functional level, and be able to think along with them about prioritization. (This is again something that requires more of a functional view on things.)
4. Understand enough about the technical parts to be part of the team -- the scrum master should only need half a word from his team members to understand why something is a problem. You don't want a scrum master who is to be "massaged" by team members in order to get something done, like you would have to do with a PHB.
Point 1-3 disqualifies techies, point 4 disqualifies professional project manages. Ideally, you would find somebody on the team who is not a tech guru, but also not a tech dummy; and you would find somebody who takes an interest in procedural and functional issues.
Just to state the obvious: the most important thing about Agile is that you do retrospectives: you have to think about what works and what doesn't, and fix up your process. We've been continually fixing up our process over the past couple of years, and there's *always* things that still need improvement. If the poster has to go here in order to discuss this, his team doesn't have this very basic and über important part of Agile down.
The problem with this comparison between bank robbery, theft etc. is that the police do not allocate resources to bank robbery, theft etc. because these things hurt financially. This is not the issue at all, and trying to compare these acts based solely on monetary damages is a misrepresentation of reality.
The moment that copyright infringement starts taking place at gunpoint, you can be quite sure that the police will reallocate its resources. But nobody is robbing record stores here! No innocent civilians are having to go to a shrink for years on end, simply to get rid of the nightmares of the day that somebody pointed a gun at them and forced them to hand over their entire CD collection.
Or has the 'steampunk' genre evolved into anything goes in a Victorian-era setting?
AFAICT the 'steampunk' label basically applies to anything that you could have seen in the movie Wild Wild West or in Back To The Future III. But IIRC the guns in WWW were normal guns, so this has to have been from BTTF3. But that used regular guns too. So: no steampunk. Period.
What the fsck is "retrofurist"? It's even in TFA. I'm guessing they meant to say "retrofuturist", but being lysdectics they had an excuse to use this abbrevion...
Yeah, buttons will be pressed. The key lock on my Sony Ericsson W810i walkman phone doesn't disable the "play/pause" button on the side of the phone, which manages to start music playing even if you don't have the music player app open. This is immensely useful if you want to put the phone in your pocket while listening to music, but OTOH a while ago I found myself in the middle of a concert a while ago when I found out that my phone was providing some... eh... bonus content to the concert. And the thing was even set to quiet mode. With no headphones plugged in. Go figure.
Well, that's not entirely true. Many servers do spend a lot of time idle. Take for instance company internal servers -- they spend HUGE amounts of time idle, about 24 - 8 = 16 hours of each day. OK, subtract one hour for backups. Still, that's a huge amount of power being wasted on an idle machine. Also, there are a lot of web servers that serve country-specific sites. These machines may not be idle enough to spin down their hard drives, but they sure are idle enough to save some serious CPU power. They would probably benefit from shutting down entire CPUs during these "idle periods".
In fact, this functionality is pretty darn useless. (I should know, I got it into 2.6.:-) ) For read I/O it's okay, but for write I/O it sucks. The thing is, what's logged is the actual I/Os, which are generally done by pdflush (if the modifying process doesn't use fsync, which it usually doesn't), and kjournald if you're using ext3. The only thing that's logged otherwise is that a process dirties an inode, but that doesn't tell you how many pages it's modified. You get something like
process syslogd dirtied inode daemon.log process Y dirtied inode some_other_file1 process Z dirtied inode some_other_file2
followed by 300 writes by pdflush, which only specify a device and a block number, not a file name. There's no way you can find out for each of the 300 writes whether it was caused by the "syslogd", X or Z process. So there's no way you can count the amount of write I/O that a process has done.
Dutch blog "Retecool" tried it out and calls it a hoax. Translation of highlights:
I still need to install a ceiling lamp in the bedroom. There's no current flowing there now. The electricity company therefore doesn't charge me anything for the power being hooked up there. If there's no current, no magnet will vibrate, because it is the current (in Amperes) that causes the magnetic fields. But the electricity company does deliver me the required power for the lamp. Therefore, the connection has countless electrons waiting charged with anticipation before I poke a screwdriver into the hole. Without telling my magnet that they are so charged with anticipation, they wait for the moment that they can jump onto my well-conducting finger, to run to earth through my body. Free at last!
One slight drawback remains to be mentioned. My iBook has a magnetic detector on the right of the keyboard which detects when the screen is closed. I now have to press "Enter" with my left hand, because approaching the magnet with my right hand puts my iBook to sleep. So while my bionic magnetic finger doesn't detect anything, my iBook does detect it.
This is exactly why C++ sucks. Everything is so abstracted you can't follow what the hell was going on in codemonkey's head so maintenance is a nightmare.
It's easy to write the wrong abstractions in any language. With the proper abstractions, no problem. Things get better than without the abstractions. Languages like VB are built around good abstractions -- just don't expect the VB programmer to design these abstractions. My main problem with most C++ code that I get to maintain is that it's not abstracted enough. Copy-paste coding. Programmers don't even know when to abstract seven lines of repeated code with very mild variations into a function, let alone think about exception safety...
It requires tons of reading etc to be productive. Who will pay for the downtime?
Not true. In C++ it requires tons of writing to be productive. To write boilerplate library code that should've been in the standard library, or in a proper framework library. Reading is not the difference -- just like VB programmers need an MCSD to grasp the importance of always using Option Explicit, and to know which library is where, C++ programmers need some experience and time to understand best practice. The difference is that C++ programmers then have to write or otherwise find their own libraries. And that's where languages that come with a standard library shine.
Hmmm, this sounds kind of related to things like planar graphs (i.e., graphs that you can paint on a flat surface without edges crossing eachother). I think the idea was that the a graph is planar if and only if it does not contain a subgraph that is homeomorphic to either the fully-connected five-node graph or the fully-connected 3/3-bipartite, 6-node graph. Whoa!
Because C++ sucks when you put it in the hands of the VB crowd. It not only gives you enough rope to hang yourself with, it then proceeds to give you another mile. The language allows programming in about twenty different paradigms, the base support of which are usually per-project custom-implemented (own framework) or crappy (MFC), and because of this and the lack of a large standard library (I mean, one that the VB crowd can grasp), abilities that you gained on one C++ project do _not_ transfer well to other C++ projects.
Now don't get me wrong, I work with C++ every day and I love it because of the sheer power it gives me. You can basically abstract away any management chores using smart pointers and other objects. And you can write the most obscenely decoupled functionality using traits classes and such. But put this same stuff in the hands of a VB coder, and you'll get C++ code using VB idiom. And that's NOT GOOD. VB coding idiom is not exception safe AND does not deal with memory management, so you'll have memory leaks all over the place, and even if they bother to put in the deletes in the proper places, you're one exception away from leaking a whole bunch of stuff. Teach them to use smart pointers to fix this? In an average C++ project "done right", you'll have to write a lot of smart pointers/auto objects yourself, and people who are used to VB are _not_ capable of writing proper smart pointers in C++. That requires reading and understanding all of Scott Meyers' books, and they won't do that. They'll think they grasp the language when they have their first MFC-generated dialog on-screen. It'll only get worse from there.
...this story has impeccable timing for me. Last week I was contacted by a recruiter from a big-name company that I would *really* like to work for, but working for them would require relocating, which is not an option at the moment -- my wife can't leave this place because she's working on a PhD at the local university. The other option would be to go there by air every week (it's a 1.5 hour flight, plus another 1.5 hours of travel), which is doable but which would mean I'd be away from home for most of the week. I probably wouldn't mind doing that if I could eventually telecommute for one or two days a week, but still, the idea is terribly frightening!
Fortunately I've talked about it with the wife, and she doesn't really mind me being away for 3 or 4 nights a week. There are no kids (at the moment) so that makes it easier. And I could set up a webcam on the other side so that we can chat, and we can spend some of the evenings that I'm away play games together online. That counts as spending time together, right? And if you have broadband on both sides, you can probably even watch online TV together. You could keep a voice channel open at the same time and talk about the stuff that's on TV.:-)
They might choose to edit certain articles because they have knowledge in the area. Unless you are saying that having knowledge is a bias.
Having knowledge does not necessarily mean having a bias, no. But to want to volunteer one's knowledge for a Wikipedia article does mean that one attaches some kind of value to one's knowledge, enough to want to share it with others. And the greater one's bias in a subject, the greater the value that one attaches to one's knowledge in that subject. Simply put, zealots attach lots of value to their beliefs, and they are therefore more likely to want to volunteer their knowledge. I'm not saying that people who choose to edit certain Wikipedia articles are by definition zealots w.r.t. the subject they write about. What I am saying is that zealots have more motivation to edit certain Wikipedia articles. In fact, the number of zealots editing a Wikipedia article is probably positively correlated with the controversiality of the subject. And if the number of disinterested writers does not grow as much with the subject's controversiality (which is probably the case, as disinterested writers by definition have no special interest in the subject and therefore no increased motivation to choose this particular subject), it is easy to see that in very controversial subjects, the zealots will outnumber the disinterested writers!
You are confusing "disinterested" for "uninterested". If a judge hears a case, being only concerned with rendering justice, then she is disinterested. On the other hand, if she wants the proceedings to end so that she can make her 3 o'clock appointment, then she is uninterested.
No, disinterested is exactly what I meant. Encyclopedia writers are supposed to be objective, i.e., disinterested w.r.t. the subject at hand. Like judges are supposed to be disinterested w.r.t. the outcome of the cases they handle -- their interest is supposed to be justice, just like the interest of encyclopedia writers is supposed to be objectivity. Wikipedia writers are by definition not disinterested because they chose themselves as writers for the particular subject, which usually means they have some personal interest (read: bias) in the subject.
His denunciations spoke for many, who question how something built by the wisdom of crowds can become anything other than mob rule.
It's obvious that an entry created and commented on by many disinterested people is less biased than an entry created and commented on by few. Traditional encylopedias fall in the latter category, Wikipedia falls in the former. But people are not always disinterested, and that's where the problems lie. So the real problem is: are all the participants disinterested? With traditional encylopedias, the chances are that most writers are semi-disinterested observers, as they are ordered to write about subjects, they don't select them themselves. With Wikipedia, people self-select themselves, which means they cannot be disinterested, by definition. And that's the reason that some kind of community control is required for projects like this.
First of all, work out regularly. This increases the blood flow everywhere, which has a lot of benefits besides preventing RSI. Working out encourages your body to increase the efficiency and capacity of your blood vessels, leading to better endurance when you're sitting behind a desk. Basically, it will allow your hands and arms to recover more during work, because the material supplies required for the recovery are transported there in larger quantities. Also, increased blood flow will decrease recovery time outside working hours. Before, I would come home with pain in my hands and I would go to work the next day still with pain in my hands. After I started working out, I would come home with tired (but not painful) hands, and everything would have recovered completely by the time I got up the next morning. An added advantage of working out is that you're less tired after a day's work, which means that you'll have more energy on weekday evenings.
Secondly, make sure your upper arms are hanging straight down along the side of your body while you're working. Most typing-related RSI problems, although you feel them in your wrists, actually originate in the outward-facing muscles of your upper arms, which extend into (or at least are strongly connected to the muscles in) your shoulders and into your neck. Even when your elbows are only 15 cm away from your body, the tension in all those muscles will be considerable, and their stress levels will decrease the blood flow to the lower parts of your arm. I've seen many surprised faces of RSI sufferers when I massaged the outward-facing side of their upper arms, which (unexpectedly for them) caused a tingling feeling in their hands (the sign that they were suddenly getting enough blood flow again), followed by the disappearance of the pain in their wrists, lower arms and hands.:-)
Well, I guess the best filesystem for this kind of stuff is ISO9660. Very optimized for WORM access, no file fragmentation, and anything new you write will not destroy any existing data. Guaranteed.
In my experience decoupling and automatic restarting is a recipe for failure. You set yourself up for all sorts of race conditions. For instance, if a module is unresponsive for a while but not crashing, do you restart it? And if you do, what if the original module finishes its grand execution plan and comes back up after a minute?
No, I'd go for: * A "monolithic" application with module separation provided by OO design. At least you know that either your whole application is there, or it isn't. No inconsistencies between modules because of individual module re-starts, and if the app breaks, restart the whole thing. Starting the app is the code path you've tested, restarting separate modules usually isn't (and even if it were, there's usually 2^27324 different situations to test, i.e., all possible combinations of modules failing in any sort of way). * Use smart pointers exclusively, preferably Boost's shared_ptr. Use weak pointers (Boost provides an implementation for that as well) to automatically break reference cycles. * For error handling, use exception handling exclusively. Incredibly many bugs are caused by ignored return codes. * Use "auto" objects for all resources that you acquire and that need to be released at the end of a code section. Cleanup that doesn't happen when a code path encounters an exception can cause resource leakage, instability and hangups (locks, anyone?). In my programming practice, when I allocate a resource (memory, refcount, open/close a recordset, etc.), I always wrap it in an auto object immediately, so that I can forget about managing it through all the code paths that follow. * Use the correctness features that the language provides: write const-correct code from the start. * Use automated testing right from the start, both unit testing and integration testing. If you don't do this, you will be forever tied to whatever bad design decisions you make in the first months of the project. Automated testing allows you to always make large implementation changes, giving you confidence that it will not break existing behaviour.
1. As for code comments, rely on "Use The Source, Luke" as much as possible. Force people to write readable code, so that this actually works. Logical variable names, no unnamed magic numbers, no cryptic constructs. No loop bodies consisting of only a semicolon, e.g. "for(...;...;...);". Comment only on the things that aren't obvious. Any extraneous comments are bound to be outdated by the code, and will confuse more than help.
2. Write down the design in comments in the source files, as a readable piece of prose containing all of the design considerations and decisions. Design of an algorithm goes in the function body, design of a class goes above the class definition. Programmers are aware that designs are often outdated, so when they read them this is not a problem. Having the design in the code has the advantage that you can actually *find* the design for the code you're looking at. There have been too many times where I've been looking for a design document that was "somewhere on the network". Or that I've been looking at a design document on the network that had been superseded three years ago. Having your design under source control fixes that.
3. Build at least every day, or even better: continuously.
4. Automated testing. Run automated tests on every build, if possible.
5. Code reviews. Sit together once a week with one other team member who then reviews all your code for the last week (all of it, based on reports from source control). That shouldn't cost more than an hour or something, it's a good way of keeping the knowledge going around, it works as a very good "desensitization therapy" for those programmers who can't handle criticism, it increases communication within the team because people get to understand each other's work better. The only downside is that there is usually a lot of opposition against this -- I know a *lot* of programmers who don't like to have their code criticized. And there's a very clear risk that people will get into endless discussions about very small details of style ("should there be a space between the if and the parenthesis?") or other inconsequential things. To prevent these issues hogging the review, there should be a formal "escalation procedure", where the issue is passed on to an arbiter (team lead) with arguments from both parties. If a disucssion on an issue seems to go in this direction, either party *or* somebody else in the room whom the discussion irritates the hell out of should be able to cut off the discussion and "escalate" it.:) The team lead can then decide on a policy, e.g. "there will be no discussion on this point, everybody can do it how he/she pleases", "everybody will do it *this* way", something like that.
Note that I'm currently working in an environment where we have (1) to (4) implemented. I'd like to have (5), because there is too many crap code being committed, and there's no check on that. It's been all too often that we've had to replace the *entire* work of a team member after he/she left, because the team member had been able to commit crap code without check during all the time (s)he was on the team.
This is brilliant: if the humidity is increasing, that means that there is less water in fluid state -- the water vapor has to come from somewhere, right? That might just compensate for the rising sea levels caused by melting polar ice!
Slashdot Mirror
Long after DARPA's research, commercial entities such as AOL, Prodigy, and CompuServe had their own ideas about how computer networks should function. If a commercial entity had invented the Internet it would have functioned like the AOL of 1993 where all content has to be approved by a single corporation. That corporation would collect a tax on all transactions. It would kick out anyone it did not agree with. It would be far, far different than the Internet we have today and it would have undoubtedly happened much later.
It has.
Use a square bull pen arrangement with work surfaces around the inside of the square. Put a single round table in the middle for collaborative meeting/discussions.
If programmers have to share an office, this would be the ideal arrangement. Its very space efficient (more so than sitting opposite each other), and its easy to collaborate by simply turning around and talking to your teammates. Furthermore, theres plenty of space behind each team members computer for everybody to stand or sit around and work on something together. It must be said that distractions are hell though. Sartre said, "Lenfer, cest lest autres." Damn right he was.
We've been doing Scrum for a while now at my company, and one of the conclusions we've reached is that you should never make the tech gurus the scrum masters. And that conclusion is totally independent from who you *do* want to make scrum masters, just don't pick the technical guru. The reason? Tech gurus tend to be the technical core of the team, everbody asks them deep technical questions all day long, they also have the responsibility of building the most complex technical features that nobody else can really do, which means that they spend their days entrenched in the core technical stuff of the project *which is exactly the opposite of where the scrum master should be*. The scrum master should, ideally:
1. Be able to keep some distance, what we call a "helicopter view". (Note how being entrenched in technical details doesn't fit well here?)
2. Consider the progress of items and tell people when they have unrealistic estimates of whether their items are likely to be "done" at the end of the Sprint, according to the Definition of Done that was agreed on with the Product Owner. (Again, something that requires not being entrenched in the details of technical stuff.)
3. Be able to talk to management about items on a functional level, and be able to think along with them about prioritization. (This is again something that requires more of a functional view on things.)
4. Understand enough about the technical parts to be part of the team -- the scrum master should only need half a word from his team members to understand why something is a problem. You don't want a scrum master who is to be "massaged" by team members in order to get something done, like you would have to do with a PHB.
Point 1-3 disqualifies techies, point 4 disqualifies professional project manages. Ideally, you would find somebody on the team who is not a tech guru, but also not a tech dummy; and you would find somebody who takes an interest in procedural and functional issues.
Just to state the obvious: the most important thing about Agile is that you do retrospectives: you have to think about what works and what doesn't, and fix up your process. We've been continually fixing up our process over the past couple of years, and there's *always* things that still need improvement. If the poster has to go here in order to discuss this, his team doesn't have this very basic and über important part of Agile down.
The problem with this comparison between bank robbery, theft etc. is that the police do not allocate resources to bank robbery, theft etc. because these things hurt financially. This is not the issue at all, and trying to compare these acts based solely on monetary damages is a misrepresentation of reality.
The moment that copyright infringement starts taking place at gunpoint, you can be quite sure that the police will reallocate its resources. But nobody is robbing record stores here! No innocent civilians are having to go to a shrink for years on end, simply to get rid of the nightmares of the day that somebody pointed a gun at them and forced them to hand over their entire CD collection.
Or has the 'steampunk' genre evolved into anything goes in a Victorian-era setting?
AFAICT the 'steampunk' label basically applies to anything that you could have seen in the movie Wild Wild West or in Back To The Future III. But IIRC the guns in WWW were normal guns, so this has to have been from BTTF3. But that used regular guns too. So: no steampunk. Period.What the fsck is "retrofurist"? It's even in TFA. I'm guessing they meant to say "retrofuturist", but being lysdectics they had an excuse to use this abbrevion...
Yeah, buttons will be pressed. The key lock on my Sony Ericsson W810i walkman phone doesn't disable the "play/pause" button on the side of the phone, which manages to start music playing even if you don't have the music player app open. This is immensely useful if you want to put the phone in your pocket while listening to music, but OTOH a while ago I found myself in the middle of a concert a while ago when I found out that my phone was providing some... eh... bonus content to the concert. And the thing was even set to quiet mode. With no headphones plugged in. Go figure.
Well, that's not entirely true. Many servers do spend a lot of time idle. Take for instance company internal servers -- they spend HUGE amounts of time idle, about 24 - 8 = 16 hours of each day. OK, subtract one hour for backups. Still, that's a huge amount of power being wasted on an idle machine. Also, there are a lot of web servers that serve country-specific sites. These machines may not be idle enough to spin down their hard drives, but they sure are idle enough to save some serious CPU power. They would probably benefit from shutting down entire CPUs during these "idle periods".
More gems:
...if I'm connected to SourceForge.net, then the version of nome that I'm pulling over is the most recent nome, because...
And if it did try distributing trackers, you'd be in the Nutella world, where...
Wow, some great subtitling here. The guy programs in oc and apparently speaks about item potent data packets...
In fact, this functionality is pretty darn useless. (I should know, I got it into 2.6. :-) ) For read I/O it's okay, but for write I/O it sucks. The thing is, what's logged is the actual I/Os, which are generally done by pdflush (if the modifying process doesn't use fsync, which it usually doesn't), and kjournald if you're using ext3. The only thing that's logged otherwise is that a process dirties an inode, but that doesn't tell you how many pages it's modified. You get something like
process syslogd dirtied inode daemon.log
process Y dirtied inode some_other_file1
process Z dirtied inode some_other_file2
followed by 300 writes by pdflush, which only specify a device and a block number, not a file name. There's no way you can find out for each of the 300 writes whether it was caused by the "syslogd", X or Z process. So there's no way you can count the amount of write I/O that a process has done.
Dutch blog "Retecool" tried it out and calls it a hoax. Translation of highlights:
I still need to install a ceiling lamp in the bedroom. There's no current flowing there now. The electricity company therefore doesn't charge me anything for the power being hooked up there. If there's no current, no magnet will vibrate, because it is the current (in Amperes) that causes the magnetic fields. But the electricity company does deliver me the required power for the lamp. Therefore, the connection has countless electrons waiting charged with anticipation before I poke a screwdriver into the hole. Without telling my magnet that they are so charged with anticipation, they wait for the moment that they can jump onto my well-conducting finger, to run to earth through my body. Free at last!
One slight drawback remains to be mentioned. My iBook has a magnetic detector on the right of the keyboard which detects when the screen is closed. I now have to press "Enter" with my left hand, because approaching the magnet with my right hand puts my iBook to sleep. So while my bionic magnetic finger doesn't detect anything, my iBook does detect it.
It's easy to write the wrong abstractions in any language. With the proper abstractions, no problem. Things get better than without the abstractions. Languages like VB are built around good abstractions -- just don't expect the VB programmer to design these abstractions. My main problem with most C++ code that I get to maintain is that it's not abstracted enough. Copy-paste coding. Programmers don't even know when to abstract seven lines of repeated code with very mild variations into a function, let alone think about exception safety...
Not true. In C++ it requires tons of writing to be productive. To write boilerplate library code that should've been in the standard library, or in a proper framework library. Reading is not the difference -- just like VB programmers need an MCSD to grasp the importance of always using Option Explicit, and to know which library is where, C++ programmers need some experience and time to understand best practice. The difference is that C++ programmers then have to write or otherwise find their own libraries. And that's where languages that come with a standard library shine.
Hmmm, this sounds kind of related to things like planar graphs (i.e., graphs that you can paint on a flat surface without edges crossing eachother). I think the idea was that the a graph is planar if and only if it does not contain a subgraph that is homeomorphic to either the fully-connected five-node graph or the fully-connected 3/3-bipartite, 6-node graph. Whoa!
Unfortunately, you don't have to be an idiot to write bad code in C++. I've seen plenty of very bad C++ come from otherwise very smart people.
Because C++ sucks when you put it in the hands of the VB crowd. It not only gives you enough rope to hang yourself with, it then proceeds to give you another mile. The language allows programming in about twenty different paradigms, the base support of which are usually per-project custom-implemented (own framework) or crappy (MFC), and because of this and the lack of a large standard library (I mean, one that the VB crowd can grasp), abilities that you gained on one C++ project do _not_ transfer well to other C++ projects.
Now don't get me wrong, I work with C++ every day and I love it because of the sheer power it gives me. You can basically abstract away any management chores using smart pointers and other objects. And you can write the most obscenely decoupled functionality using traits classes and such. But put this same stuff in the hands of a VB coder, and you'll get C++ code using VB idiom. And that's NOT GOOD. VB coding idiom is not exception safe AND does not deal with memory management, so you'll have memory leaks all over the place, and even if they bother to put in the deletes in the proper places, you're one exception away from leaking a whole bunch of stuff. Teach them to use smart pointers to fix this? In an average C++ project "done right", you'll have to write a lot of smart pointers/auto objects yourself, and people who are used to VB are _not_ capable of writing proper smart pointers in C++. That requires reading and understanding all of Scott Meyers' books, and they won't do that. They'll think they grasp the language when they have their first MFC-generated dialog on-screen. It'll only get worse from there.
...this story has impeccable timing for me. Last week I was contacted by a recruiter from a big-name company that I would *really* like to work for, but working for them would require relocating, which is not an option at the moment -- my wife can't leave this place because she's working on a PhD at the local university. The other option would be to go there by air every week (it's a 1.5 hour flight, plus another 1.5 hours of travel), which is doable but which would mean I'd be away from home for most of the week. I probably wouldn't mind doing that if I could eventually telecommute for one or two days a week, but still, the idea is terribly frightening!
:-)
Fortunately I've talked about it with the wife, and she doesn't really mind me being away for 3 or 4 nights a week. There are no kids (at the moment) so that makes it easier. And I could set up a webcam on the other side so that we can chat, and we can spend some of the evenings that I'm away play games together online. That counts as spending time together, right? And if you have broadband on both sides, you can probably even watch online TV together. You could keep a voice channel open at the same time and talk about the stuff that's on TV.
Having knowledge does not necessarily mean having a bias, no. But to want to volunteer one's knowledge for a Wikipedia article does mean that one attaches some kind of value to one's knowledge, enough to want to share it with others. And the greater one's bias in a subject, the greater the value that one attaches to one's knowledge in that subject. Simply put, zealots attach lots of value to their beliefs, and they are therefore more likely to want to volunteer their knowledge. I'm not saying that people who choose to edit certain Wikipedia articles are by definition zealots w.r.t. the subject they write about. What I am saying is that zealots have more motivation to edit certain Wikipedia articles. In fact, the number of zealots editing a Wikipedia article is probably positively correlated with the controversiality of the subject. And if the number of disinterested writers does not grow as much with the subject's controversiality (which is probably the case, as disinterested writers by definition have no special interest in the subject and therefore no increased motivation to choose this particular subject), it is easy to see that in very controversial subjects, the zealots will outnumber the disinterested writers!
No, disinterested is exactly what I meant. Encyclopedia writers are supposed to be objective, i.e., disinterested w.r.t. the subject at hand. Like judges are supposed to be disinterested w.r.t. the outcome of the cases they handle -- their interest is supposed to be justice, just like the interest of encyclopedia writers is supposed to be objectivity. Wikipedia writers are by definition not disinterested because they chose themselves as writers for the particular subject, which usually means they have some personal interest (read: bias) in the subject.
It's obvious that an entry created and commented on by many disinterested people is less biased than an entry created and commented on by few. Traditional encylopedias fall in the latter category, Wikipedia falls in the former. But people are not always disinterested, and that's where the problems lie. So the real problem is: are all the participants disinterested? With traditional encylopedias, the chances are that most writers are semi-disinterested observers, as they are ordered to write about subjects, they don't select them themselves. With Wikipedia, people self-select themselves, which means they cannot be disinterested, by definition. And that's the reason that some kind of community control is required for projects like this.
First of all, work out regularly. This increases the blood flow everywhere, which has a lot of benefits besides preventing RSI. Working out encourages your body to increase the efficiency and capacity of your blood vessels, leading to better endurance when you're sitting behind a desk. Basically, it will allow your hands and arms to recover more during work, because the material supplies required for the recovery are transported there in larger quantities. Also, increased blood flow will decrease recovery time outside working hours. Before, I would come home with pain in my hands and I would go to work the next day still with pain in my hands. After I started working out, I would come home with tired (but not painful) hands, and everything would have recovered completely by the time I got up the next morning. An added advantage of working out is that you're less tired after a day's work, which means that you'll have more energy on weekday evenings.
:-)
Secondly, make sure your upper arms are hanging straight down along the side of your body while you're working. Most typing-related RSI problems, although you feel them in your wrists, actually originate in the outward-facing muscles of your upper arms, which extend into (or at least are strongly connected to the muscles in) your shoulders and into your neck. Even when your elbows are only 15 cm away from your body, the tension in all those muscles will be considerable, and their stress levels will decrease the blood flow to the lower parts of your arm. I've seen many surprised faces of RSI sufferers when I massaged the outward-facing side of their upper arms, which (unexpectedly for them) caused a tingling feeling in their hands (the sign that they were suddenly getting enough blood flow again), followed by the disappearance of the pain in their wrists, lower arms and hands.
Well, I guess the best filesystem for this kind of stuff is ISO9660. Very optimized for WORM access, no file fragmentation, and anything new you write will not destroy any existing data. Guaranteed.
In my experience decoupling and automatic restarting is a recipe for failure. You set yourself up for all sorts of race conditions. For instance, if a module is unresponsive for a while but not crashing, do you restart it? And if you do, what if the original module finishes its grand execution plan and comes back up after a minute?
No, I'd go for:
* A "monolithic" application with module separation provided by OO design. At least you know that either your whole application is there, or it isn't. No inconsistencies between modules because of individual module re-starts, and if the app breaks, restart the whole thing. Starting the app is the code path you've tested, restarting separate modules usually isn't (and even if it were, there's usually 2^27324 different situations to test, i.e., all possible combinations of modules failing in any sort of way).
* Use smart pointers exclusively, preferably Boost's shared_ptr. Use weak pointers (Boost provides an implementation for that as well) to automatically break reference cycles.
* For error handling, use exception handling exclusively. Incredibly many bugs are caused by ignored return codes.
* Use "auto" objects for all resources that you acquire and that need to be released at the end of a code section. Cleanup that doesn't happen when a code path encounters an exception can cause resource leakage, instability and hangups (locks, anyone?). In my programming practice, when I allocate a resource (memory, refcount, open/close a recordset, etc.), I always wrap it in an auto object immediately, so that I can forget about managing it through all the code paths that follow.
* Use the correctness features that the language provides: write const-correct code from the start.
* Use automated testing right from the start, both unit testing and integration testing. If you don't do this, you will be forever tied to whatever bad design decisions you make in the first months of the project. Automated testing allows you to always make large implementation changes, giving you confidence that it will not break existing behaviour.
Here's what I like:
:) The team lead can then decide on a policy, e.g. "there will be no discussion on this point, everybody can do it how he/she pleases", "everybody will do it *this* way", something like that.
1. As for code comments, rely on "Use The Source, Luke" as much as possible. Force people to write readable code, so that this actually works. Logical variable names, no unnamed magic numbers, no cryptic constructs. No loop bodies consisting of only a semicolon, e.g. "for(...;...;...);". Comment only on the things that aren't obvious. Any extraneous comments are bound to be outdated by the code, and will confuse more than help.
2. Write down the design in comments in the source files, as a readable piece of prose containing all of the design considerations and decisions. Design of an algorithm goes in the function body, design of a class goes above the class definition. Programmers are aware that designs are often outdated, so when they read them this is not a problem. Having the design in the code has the advantage that you can actually *find* the design for the code you're looking at. There have been too many times where I've been looking for a design document that was "somewhere on the network". Or that I've been looking at a design document on the network that had been superseded three years ago. Having your design under source control fixes that.
3. Build at least every day, or even better: continuously.
4. Automated testing. Run automated tests on every build, if possible.
5. Code reviews. Sit together once a week with one other team member who then reviews all your code for the last week (all of it, based on reports from source control). That shouldn't cost more than an hour or something, it's a good way of keeping the knowledge going around, it works as a very good "desensitization therapy" for those programmers who can't handle criticism, it increases communication within the team because people get to understand each other's work better. The only downside is that there is usually a lot of opposition against this -- I know a *lot* of programmers who don't like to have their code criticized. And there's a very clear risk that people will get into endless discussions about very small details of style ("should there be a space between the if and the parenthesis?") or other inconsequential things. To prevent these issues hogging the review, there should be a formal "escalation procedure", where the issue is passed on to an arbiter (team lead) with arguments from both parties. If a disucssion on an issue seems to go in this direction, either party *or* somebody else in the room whom the discussion irritates the hell out of should be able to cut off the discussion and "escalate" it.
Note that I'm currently working in an environment where we have (1) to (4) implemented. I'd like to have (5), because there is too many crap code being committed, and there's no check on that. It's been all too often that we've had to replace the *entire* work of a team member after he/she left, because the team member had been able to commit crap code without check during all the time (s)he was on the team.
This is brilliant: if the humidity is increasing, that means that there is less water in fluid state -- the water vapor has to come from somewhere, right? That might just compensate for the rising sea levels caused by melting polar ice!