A while back, a friend of mine -- a very experienced software development manager -- was running a development team, and was planning to hire a developer who was in his early 40s. One of the team members openly objected to the candidate because of his age, saying something like, "How could he possibly be up to date on current technology or keep up with the rest of the team? He's so old!" My friend eventually hired him anyway, and the "old" developer turned out to be a superstar, one of the best on the team.
That was about eight years ago. The guy who raised the objection is now about the same age as the candidate he had wanted to reject. I wonder if he's facing the same kind of age discrimination, now that he's "so old."
A system like this shouldn't have too much trouble identifying pedestrian "walk/don't walk" traffic signals and giving an audio signal when they turn red or green. GPS locations of known traffic lights should make this even easier. That would make navigating through a city much easier for the visually impaired. There's some research in this area (link, link) already, but having a system like this in place makes it much more likely for a real, usable production system to eventually end up in the hands of the people who need it.
Clearly, Roger Ebert hasn't played Ico or Shadow of the Collossus. They are easily covered by any definition of "art" I can think of. I've seen very few movies that have as wide a range of emotion and give such an emotional connection as those two games.
(I went to Performing Arts for high school and I've been a musician all my life, so I feel like I can speak with at least a little authority on this.)
Reading through a lot of the replies, I think it would help a lot of people to understand the two most prevalent kinds of political and social infrastructure for open source projects: benevolent dictator and consensus-based democracy. Karl Fogel, in his excellent book, Producing Open Source Software (O'Reilly) -- which itself is open source and available for free download -- summarizes them extremely well. Reading TFA and replies, it seems to me that this is a really good case study in how an open source project is managed. I highly recommend reading Karl's section on Political and Social Infrastructure. I'll include two relevant excerpts, because I think they shine light on exactly this situation.
The benevolent dictator model is exactly what it sounds like: final decision-making authority rests with one person, who, by virtue of personality and experience, is expected to use it wisely.
Although "benevolent dictator" (or BD)is the standard term for this role, it would be better to think of it as "community-approved arbitrator" or "judge". Generally, benevolent dictators do not actually make all the decisions, or even most of the decisions. It's unlikely that one person could have enough expertise to make consistently good decisions across all areas of the project, and anyway, quality developers won't stay around unless they have some influence on the project's direction. Therefore, benevolent dictators commonly do not dictate much. Instead, they let things work themselves out through discussion and experimentation whenever possible. They participate in those discussions themselves, but as regular developers, often deferring to an area maintainer who has more expertise. Only when it is clear that no consensus can be reached, and that most of the group wants someone to guide the decision so that development can move on, do they put their foot down and say "This is the way it's going to be." Reluctance to make decisions by fiat is a trait shared by virtually all successful benevolent dictators; it is one of the reasons they manage to keep the role.
As projects get older, they tend to move away from the benevolent dictatorship model and toward more openly democratic systems. This is not necessarily out of dissatisfaction with a particular BD. It's simply that group-based governance is more "evolutionarily stable", to borrow a biological metaphor. Whenever a benevolent dictator steps down, or attempts to spread decision-making responsibility more evenly, it is an opportunity for the group to settle on a new, non-dictatorial system—establish a constitution, as it were. The group may not take this opportunity the first time, or the second, but eventually they will; once they do, the decision is unlikely ever to be reversed. Common sense explains why: if a group of N people were to vest one person with special power, it would mean that N - 1 people were each agreeing to decrease their individual influence. People usually don't want to do that. Even if they did, the resulting dictatorship would still be conditional: the group anointed the BD, clearly the group could depose the BD. Therefore, once a project has moved from leadership by a charismatic individual to a more formal, group-based system, it rarely moves back.
The details of how these systems work vary widely, but there are two common elements: one, the group works by consensus most of the time; two, there is a formal voting mechanism to fall back on when consensus cannot be reached.
It's a neat trick, albeit an old one. But it's not quite a real measurement of C. The problem is that you're given the frequency to start with, and a smart high school student will tell you that means you also know the wavelength. So if you trust the frequency rating of the microwave then the only thing you're really doing is verifying that the ruler you're using is accurate.
It's pretty well known that religious epiphanies and other feelings of religiosity, spirituality, or sensations of a "presence" can sometimes be linked to neurological events such as some temporal lobe seizures. (Wasn't this the plot for an episode of House?) It's common enough that there's a section on religious and paranormal experiences in the temporal lobe epilepsy Wikipedia page. There was a good BBC documentary a few years ago on this called "God on the Brain" (here's a transcript).
I've spent a lot of time working with many different teams and trying lots of different estimation techniques, and I've had the best success with the ones that let the team work together to come up with an estimate they all believe in. My best results came with Wideband Delphi, which I've been able to use in both Agile and non-Agile projects. I've actually got a chapter on estimation in one of my books -- you can download the PDF of it.
Also, Mike Cohn has a lot to say about planning Agile projects on his blog -- definitely highly recommended reading if you're trying to plan projects.
Whenever I help teams improve the way they estimate their projects, one of the things I've really concentrated on is that planning is about more than estimation. I've got a blog post about it (The Perils of a Schedule) -- a big part of planning is making commitments, and estimation is the way to make those commitments easier to stick to (or less likely to break).
I would go further than just publishing the code used in scientific research. I would build the code by running it a real open source project. In fact, I've done exactly that, and it worked out incredibly well. I believe our open source approach lead to better science, and also better software.
I worked with researchers from MIT and Columbia on a research project that involved gathering and analyzing a large amount of publication data. The results of the study are about to be published (you can read the working paper at the lead researcher's website).
We intended the code for this project to be released from the beginning, so we ran it as an open source project. I followed the basic formula from Karl Fogel's excellent (and free to download) book, Producing Open Source Software: set up a website for the project, created lots of documentation, tried to make it as easy as possible for someone to get up and running, made the source available via Subversion, and made it easy to contact us.
Quality was really important for us, so we put a lot of effort into testing. I definitely believe that the fact that we intended the project to be open source from the beginning helped with that. We weren't treating the code as some piece of throwaway or replaceable lab equipment. I'm convinced that treating it as a real product of the research caused us to take the development and the quality much more seriously than a lot of researchers. I've since heard from other researchers who are starting to use the software as well, and everyone who sees it feels that it came out really well.
There was another scientific benefit that should definitely appeal to anyone who lives in the publish-or-perish world of science research. We published a paper specifically on the project (Azoulay P, Stellman A, Zivin JG. PublicationHarvester. An open-source software tool for science policy research. Research Policy 35 (2006) 970-974. -- there's a link to the PDF on the lead researcher's website.)
It's funny -- I wrote an article a few years ago with Jennifer Greene for O'Reilly ONLamp called What Corporate Projects Should Learn from Open Source. I'm now convinced that science research projects can also learn a great deal from open source as well.
There are a few pretty big gaps in this article's reasoning.
If the content was what they were selling, why has the price of books or music or movies always depended mostly on the format?
The price of books or music or movies doesn't depend on the format. If it did, all MP3s and DVDs would cost the same, and books would be priced based on their print quality, number of pages and binding. And last time I checked, not all MP3s, books or DVDs cost the same. Books that cost the same to print often have wildly different retail prices. And MP3s -- well, there, the medium cost is nothing. The production costs certainly vary, but it's rarely the production cost that contributes to the price.
I happen to make part of my living writing books. And I have two books, for example, that are almost identical in format (printing, length, etc.), but with over 50% difference in price because of the content of the books.
Second, the article talks about better content, but "better" is highly subjective. Here's an example right from the beginning of the article:
A copy of Time costs $5 for 58 pages, or 8.6 cents a page. The Economist costs $7 for 86 pages, or 8.1 cents a page. Better journalism is actually slightly cheaper.
Personally, I happen to prefer the Economist to Time. But there are a lot of people who prefer Time. Who's right? Who knows?
I think pricing is an odd, and probably not all that useful, way to look at this. While one reaction might be to let the market determine what's "better," I think markets are very good at determining a price for, say, an album, but notoriously bad at determining what's "better." To butcher an Oscar Wilde quote, markets know the price of everything and the value of nothing. Personally, I would throw you average Celine Dion album in a bargain bin, but there are clearly many people (and not just French Canadians!) who would disagree. And price is not necessarily indicative of anything at all. Is Radiohead's In Rainbows "worse" because they gave it away for whatever price you happened to feel like paying?
One last thing strikes me about the article:
[3] I never watch movies in theaters anymore. The tipping point for me was the ads they show first.
That's a great example of a point I thought the article only tangentially made. People go to a movie theater to meet up with friends, take out the family, go on a date, etc. The $7 tub of popcorn isn't worth $7 because of the corn in it is somehow "better." It's worth $7 to the people who get it because it's part of the experience. The "content" there is the movie, but it's the real purpose of going to a theater is only partially to experience the movie. (I'm not quite sure exactly how that impacts the point of the article, but it definitely paints a murkier picture than the article suggests.)
A lot of people -- like the author of Talking Back to Prozac -- claim that some drug trials (especially for popular antidepressants) are compromised to the point that getting drugs like Prozac approved required requires a surprising amount of massaging of the data from drug trials just to get to the point where the drug seems to perform better than placebo. This New Scientist article from last year about how antidepressants' effects may have been exaggerated, has a good definition of a particular form of publication bias that is apparently common:
It's called the "file-drawer problem". A study fails to produce interesting results, so is filed away and forgotten - a practice that might mean antidepressants don't work as well as doctors think.
If that's true, then it's a gambit that would get less and less effective over time. Certainly, drug companies have a very large commercial interest in boosting the apparent effectiveness of their drugs by "enhancing" the results of their trials through selectively ignoring results they don't like. It does sound somewhat conspiracy theory-ish, but it seems like there's increasing evidence. Plus, if it's true that antidepressants are less effective than many doctors believed in the past, that's more evidence that the trials drew incorrect conclusions.
If this is the first time you've run across Benford's law, you might thought to yourself, "Wow, I can use that to predict large prime numbers! I'll just convert numbers to base X, where X is really big, and only check numbers that start with 1."
It's worth actually trying this, if you get a minute. You'll find that as X gets large, the number of primes that start with 2 gets closer to the number of primes tat start with 1. As X approaches infinity, your distribution approaches a smooth logarithmic curve.
It's neat to see it yourself. This gives you an easy way to experiment with an infinite, easily generated set of numbers that follows Benford's law. It turns out that math actually works, oddly enough.
When Jenny Greene and I were working on Applied Software Project Management, we put a lot of effort into coming up with a way to document the practices that we wrote about. We wanted to make them really easy to understand, because we didn't people to have to learn to read something heavyweight or cumbersome.
We ended up using "scripts" (think scripts that an actor uses, not scripts that a shell script uses) that just explain each process or practice step by step. We got a lot of mileage out of adapting the format that we used for use cases -- you can see an example here -- it's a pretty standard way of writing down use cases, but we'd never seen it used for practices. But it actually ended up making a lot of sense.
I recently interviewed security researcher Michael Collins for Beautiful Teams (a book I'm finishing for O'Reilly) about work he'd done at CERT working on SiLK, a collection of traffic analysis tools. From talking to him, it sounds like this is an enormously difficult problem to solve. His work involved modeling "normalcy" as a baseline to detect anomalies using an enormous amount of data spit out of edge routers. When I asked, "So your goal was to look at the data from routers, and just by looking at the gigabytes of daily data from router logs you can detect successful and unsuccessful attempts at intrusion?", he said, "That's the Holy Grail." (We'll be printing the whole interview, if you're curious to see it.) TFA was light on details -- if they managed to make some headway towards solving this problem, that would be amazing. But from what we talked about, it sounds like simply finding anomalies after the fact using a huge amount of data turns out to be enormously difficult. Doing it in real time seems... well, let's just say that I'm skeptical.
Take a cue from this post and write a script that uses vmstat and top to alter the scrolling speed and scroll something useful that shows the health of your box. You can cut one of the numbers pumped out by vmstat to set the scroll speed, and maybe grep, head, etc. something useful out of top to show on the screen. I'd write a little suggested script for you right here, but I have no idea what format your device wants its config file.
This turns out to be a problem space with some really interesting conclusions. I spent some time over the last few years working with researchers from MIT, UCSD and NBER to come up with ways to analyze this sort of problem. They were focused specifically on medical publications and researchers in the roster of the Association of American Medical Colleges. They identified a set of well-known "superstar" researchers, and traced the network of their colleagues, as well as the second-degree social network of their colleagues' colleagues among other "superstars".
I built a bunch of software to help them analyze this data, which we released as GPL'd open source projects (Publication Harvester and SC/Gen and SocialNetworking). I've gotten e-mail from a few other bibliometric researchers who have also used it. Basically, the software automatically downloads publication citations from PubMed for a set of "superstar" researchers, looks for their colleagues, and then downloads their colleagues' publication citations, generating reports that can be fed into a statistical package.
They ended up coming up with some interesting results. Here's a Google Scholar search that shows some of the papers that came out of the study. They did end up weighting their results using journal impact factors, but the actual network of colleague publications served as an important way to remove the extraneous data.
As far as tools go, my coauthor, Jenny, and I wrote our first book using Microsoft Word, but could just as easily have been using OpenOffice, Pages or any other word processor. One thing that was enormously useful was EndNote for managing the bibliography. Our next two books were in O'Reilly's Head First series (PMP and C#), and we wrote them entirely in Adobe InDesign. (People think that there's a whole team of people designing and laying out Head First books -- it was just us, our editor, and an awesome but overworked graphic designer, Lou, who helped improve our layouts once we had them in reasonable shape.) InDesign isn't exactly the easiest tool for a book author, but it was sufficient. But it made me really appreciate word processors!
A few things that really became clear to me over the course of working on these books:
a) Pay attention to what you're delivering to your editor, and what they'll do with it. Publishers have their own set of templates and production stuff to get camera-ready copy together. Head First was a very interesting lesson in that, because Jenny and I actually produced a lot of camera-ready copy ourselves. But for most books, whatever you turn over to your publisher will get transmogrified into their own internal format.
b) The production editor people I've worked with and talked to (not just at O'Reilly, but at other publishers, too) have been extremely competent, and it's their job to take whatever it is you give them and make it work. It needs to be copyedited, typeset, and reviewed, and sent to a printer. I highly recommend getting to know them, and being as flexible and agreeable as possible (they generally won't ask you to compromise your vision for the book -- it's generally about technical stuff, like how to deal with footnotes, references, images, etc.)
c) You asked about version control. One of the best authors I've ever worked with, Karl Fogel -- he's a contributor to Beautiful Teams, and also just a great guy -- wrote a fantastic book called Producing Open Source Software, which you can buy from O'Reilly or download for free from the website. (Anyone who's interested in starting or contributing to an open source project absolutely needs to read that book. Disclosure: I was a technical reviewer for it.) In true open source fashion, Karl made his version control repository for the book available, and that's a good model to copy. Jenny and I didn't do anything quite so formalized; we just shared folders, and that was sufficient for us (even with hundreds and hundreds of image files for each Head First book).
d) This is the most important thing: make sure you have a clear idea of what it is you want to write! It's easy to get started on a project, only to have it trail off because you don't really have a whole book's worth of material. The more you can outline, the more research you do, and the more you prepare, the better the book will be.
Now, that's all assuming that you have a publisher lined up and a contract signed. If you don't, I highly recommend reading through the excellent Writing for O'Reilly section on their website. They walk you through all of the steps of proposing a book and the mechanics of actually working with a publisher -- and from everyone I've talked to, it's very similar
We get this question on the Head First C# forum every now and then from people who read the book, finish it, and want to know what to do next to get a programming career. Here's the post I usually send people to. One thing I think new developers should think about is working on a team -- that's a skill that takes practice, and doesn't always come easy to developers. The better you are at it, the more successful you'll be in your career. (I've got a few tips in that post for getting that kind of experience. Contributing to an open source project is definitely a good start. Karl Fogel's excellent book, Producing Open Source Software, is a great way to learn about how to do that effectively.)
Here's a link to Memepool's search page that will turn up the 1/22 post where the poster most likely got this. The Memepool post is more informative -- it has several other links, including a page where someone will build one of these clocks for you at what look like reasonable prices for anyone who really wants one of these but isn't a hardware hacker, and where to buy Nixie tubes (and other old displays) for someone who is.
And personally, I think the combination of 30-year old Nixie tubes and modern PIC16F84 microcontrolers is simultaneously creepy and wonderful.
Slashdot Mirror
It worked really well in Brooklyn.
A while back, a friend of mine -- a very experienced software development manager -- was running a development team, and was planning to hire a developer who was in his early 40s. One of the team members openly objected to the candidate because of his age, saying something like, "How could he possibly be up to date on current technology or keep up with the rest of the team? He's so old!" My friend eventually hired him anyway, and the "old" developer turned out to be a superstar, one of the best on the team.
That was about eight years ago. The guy who raised the objection is now about the same age as the candidate he had wanted to reject. I wonder if he's facing the same kind of age discrimination, now that he's "so old."
Meh -- it's only a flesh wound.
It shouldn't be too hard to charge a small battery through induction. We already saw an example of this when Richard Box used induction for his fluorescent light art, and it's not an uncommon subject for questions on underaduate E&M exams.
A system like this shouldn't have too much trouble identifying pedestrian "walk/don't walk" traffic signals and giving an audio signal when they turn red or green. GPS locations of known traffic lights should make this even easier. That would make navigating through a city much easier for the visually impaired. There's some research in this area (link, link) already, but having a system like this in place makes it much more likely for a real, usable production system to eventually end up in the hands of the people who need it.
Clearly, Roger Ebert hasn't played Ico or Shadow of the Collossus. They are easily covered by any definition of "art" I can think of. I've seen very few movies that have as wide a range of emotion and give such an emotional connection as those two games.
(I went to Performing Arts for high school and I've been a musician all my life, so I feel like I can speak with at least a little authority on this.)
Reading through a lot of the replies, I think it would help a lot of people to understand the two most prevalent kinds of political and social infrastructure for open source projects: benevolent dictator and consensus-based democracy. Karl Fogel, in his excellent book, Producing Open Source Software (O'Reilly) -- which itself is open source and available for free download -- summarizes them extremely well. Reading TFA and replies, it seems to me that this is a really good case study in how an open source project is managed. I highly recommend reading Karl's section on Political and Social Infrastructure. I'll include two relevant excerpts, because I think they shine light on exactly this situation.
From his section on benevolent dictators:
and on consensus-based democracy:
It's a neat trick, albeit an old one. But it's not quite a real measurement of C. The problem is that you're given the frequency to start with, and a smart high school student will tell you that means you also know the wavelength. So if you trust the frequency rating of the microwave then the only thing you're really doing is verifying that the ruler you're using is accurate.
It's pretty well known that religious epiphanies and other feelings of religiosity, spirituality, or sensations of a "presence" can sometimes be linked to neurological events such as some temporal lobe seizures. (Wasn't this the plot for an episode of House?) It's common enough that there's a section on religious and paranormal experiences in the temporal lobe epilepsy Wikipedia page. There was a good BBC documentary a few years ago on this called "God on the Brain" (here's a transcript).
I've spent a lot of time working with many different teams and trying lots of different estimation techniques, and I've had the best success with the ones that let the team work together to come up with an estimate they all believe in. My best results came with Wideband Delphi, which I've been able to use in both Agile and non-Agile projects. I've actually got a chapter on estimation in one of my books -- you can download the PDF of it.
Also, Mike Cohn has a lot to say about planning Agile projects on his blog -- definitely highly recommended reading if you're trying to plan projects.
Whenever I help teams improve the way they estimate their projects, one of the things I've really concentrated on is that planning is about more than estimation. I've got a blog post about it (The Perils of a Schedule) -- a big part of planning is making commitments, and estimation is the way to make those commitments easier to stick to (or less likely to break).
I would go further than just publishing the code used in scientific research. I would build the code by running it a real open source project. In fact, I've done exactly that, and it worked out incredibly well. I believe our open source approach lead to better science, and also better software.
I worked with researchers from MIT and Columbia on a research project that involved gathering and analyzing a large amount of publication data. The results of the study are about to be published (you can read the working paper at the lead researcher's website).
We intended the code for this project to be released from the beginning, so we ran it as an open source project. I followed the basic formula from Karl Fogel's excellent (and free to download) book, Producing Open Source Software: set up a website for the project, created lots of documentation, tried to make it as easy as possible for someone to get up and running, made the source available via Subversion, and made it easy to contact us.
Quality was really important for us, so we put a lot of effort into testing. I definitely believe that the fact that we intended the project to be open source from the beginning helped with that. We weren't treating the code as some piece of throwaway or replaceable lab equipment. I'm convinced that treating it as a real product of the research caused us to take the development and the quality much more seriously than a lot of researchers. I've since heard from other researchers who are starting to use the software as well, and everyone who sees it feels that it came out really well.
There was another scientific benefit that should definitely appeal to anyone who lives in the publish-or-perish world of science research. We published a paper specifically on the project (Azoulay P, Stellman A, Zivin JG. PublicationHarvester. An open-source software tool for science policy research. Research Policy 35 (2006) 970-974. -- there's a link to the PDF on the lead researcher's website.)
It's funny -- I wrote an article a few years ago with Jennifer Greene for O'Reilly ONLamp called What Corporate Projects Should Learn from Open Source. I'm now convinced that science research projects can also learn a great deal from open source as well.
There are a few pretty big gaps in this article's reasoning.
The price of books or music or movies doesn't depend on the format. If it did, all MP3s and DVDs would cost the same, and books would be priced based on their print quality, number of pages and binding. And last time I checked, not all MP3s, books or DVDs cost the same. Books that cost the same to print often have wildly different retail prices. And MP3s -- well, there, the medium cost is nothing. The production costs certainly vary, but it's rarely the production cost that contributes to the price.
I happen to make part of my living writing books. And I have two books, for example, that are almost identical in format (printing, length, etc.), but with over 50% difference in price because of the content of the books.
Second, the article talks about better content, but "better" is highly subjective. Here's an example right from the beginning of the article:
Personally, I happen to prefer the Economist to Time. But there are a lot of people who prefer Time. Who's right? Who knows?
I think pricing is an odd, and probably not all that useful, way to look at this. While one reaction might be to let the market determine what's "better," I think markets are very good at determining a price for, say, an album, but notoriously bad at determining what's "better." To butcher an Oscar Wilde quote, markets know the price of everything and the value of nothing. Personally, I would throw you average Celine Dion album in a bargain bin, but there are clearly many people (and not just French Canadians!) who would disagree. And price is not necessarily indicative of anything at all. Is Radiohead's In Rainbows "worse" because they gave it away for whatever price you happened to feel like paying?
One last thing strikes me about the article:
That's a great example of a point I thought the article only tangentially made. People go to a movie theater to meet up with friends, take out the family, go on a date, etc. The $7 tub of popcorn isn't worth $7 because of the corn in it is somehow "better." It's worth $7 to the people who get it because it's part of the experience. The "content" there is the movie, but it's the real purpose of going to a theater is only partially to experience the movie. (I'm not quite sure exactly how that impacts the point of the article, but it definitely paints a murkier picture than the article suggests.)
A lot of people -- like the author of Talking Back to Prozac -- claim that some drug trials (especially for popular antidepressants) are compromised to the point that getting drugs like Prozac approved required requires a surprising amount of massaging of the data from drug trials just to get to the point where the drug seems to perform better than placebo. This New Scientist article from last year about how antidepressants' effects may have been exaggerated, has a good definition of a particular form of publication bias that is apparently common:
If that's true, then it's a gambit that would get less and less effective over time. Certainly, drug companies have a very large commercial interest in boosting the apparent effectiveness of their drugs by "enhancing" the results of their trials through selectively ignoring results they don't like. It does sound somewhat conspiracy theory-ish, but it seems like there's increasing evidence. Plus, if it's true that antidepressants are less effective than many doctors believed in the past, that's more evidence that the trials drew incorrect conclusions.
If this is the first time you've run across Benford's law, you might thought to yourself, "Wow, I can use that to predict large prime numbers! I'll just convert numbers to base X, where X is really big, and only check numbers that start with 1."
It's worth actually trying this, if you get a minute. You'll find that as X gets large, the number of primes that start with 2 gets closer to the number of primes tat start with 1. As X approaches infinity, your distribution approaches a smooth logarithmic curve.
It's neat to see it yourself. This gives you an easy way to experiment with an infinite, easily generated set of numbers that follows Benford's law. It turns out that math actually works, oddly enough.
When Jenny Greene and I were working on Applied Software Project Management, we put a lot of effort into coming up with a way to document the practices that we wrote about. We wanted to make them really easy to understand, because we didn't people to have to learn to read something heavyweight or cumbersome.
We ended up using "scripts" (think scripts that an actor uses, not scripts that a shell script uses) that just explain each process or practice step by step. We got a lot of mileage out of adapting the format that we used for use cases -- you can see an example here -- it's a pretty standard way of writing down use cases, but we'd never seen it used for practices. But it actually ended up making a lot of sense.
That format worked really well for us: we used it for estimation (using Wideband Delphi), inspections and code reviews, developing specs, planning for risks, and a bunch of other practices. You might get some mileage out of it too.
I recently interviewed security researcher Michael Collins for Beautiful Teams (a book I'm finishing for O'Reilly) about work he'd done at CERT working on SiLK, a collection of traffic analysis tools. From talking to him, it sounds like this is an enormously difficult problem to solve. His work involved modeling "normalcy" as a baseline to detect anomalies using an enormous amount of data spit out of edge routers. When I asked, "So your goal was to look at the data from routers, and just by looking at the gigabytes of daily data from router logs you can detect successful and unsuccessful attempts at intrusion?", he said, "That's the Holy Grail." (We'll be printing the whole interview, if you're curious to see it.) TFA was light on details -- if they managed to make some headway towards solving this problem, that would be amazing. But from what we talked about, it sounds like simply finding anomalies after the fact using a huge amount of data turns out to be enormously difficult. Doing it in real time seems ... well, let's just say that I'm skeptical.
Take a cue from this post and write a script that uses vmstat and top to alter the scrolling speed and scroll something useful that shows the health of your box. You can cut one of the numbers pumped out by vmstat to set the scroll speed, and maybe grep, head, etc. something useful out of top to show on the screen. I'd write a little suggested script for you right here, but I have no idea what format your device wants its config file.
This turns out to be a problem space with some really interesting conclusions. I spent some time over the last few years working with researchers from MIT, UCSD and NBER to come up with ways to analyze this sort of problem. They were focused specifically on medical publications and researchers in the roster of the Association of American Medical Colleges. They identified a set of well-known "superstar" researchers, and traced the network of their colleagues, as well as the second-degree social network of their colleagues' colleagues among other "superstars".
I built a bunch of software to help them analyze this data, which we released as GPL'd open source projects (Publication Harvester and SC/Gen and SocialNetworking). I've gotten e-mail from a few other bibliometric researchers who have also used it. Basically, the software automatically downloads publication citations from PubMed for a set of "superstar" researchers, looks for their colleagues, and then downloads their colleagues' publication citations, generating reports that can be fed into a statistical package.
They ended up coming up with some interesting results. Here's a Google Scholar search that shows some of the papers that came out of the study. They did end up weighting their results using journal impact factors, but the actual network of colleague publications served as an important way to remove the extraneous data.
I'm about to finish my fourth book for O'Reilly, Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders (which should be out in stores by March).
As far as tools go, my coauthor, Jenny, and I wrote our first book using Microsoft Word, but could just as easily have been using OpenOffice, Pages or any other word processor. One thing that was enormously useful was EndNote for managing the bibliography. Our next two books were in O'Reilly's Head First series (PMP and C#), and we wrote them entirely in Adobe InDesign. (People think that there's a whole team of people designing and laying out Head First books -- it was just us, our editor, and an awesome but overworked graphic designer, Lou, who helped improve our layouts once we had them in reasonable shape.) InDesign isn't exactly the easiest tool for a book author, but it was sufficient. But it made me really appreciate word processors!
A few things that really became clear to me over the course of working on these books:
a) Pay attention to what you're delivering to your editor, and what they'll do with it. Publishers have their own set of templates and production stuff to get camera-ready copy together. Head First was a very interesting lesson in that, because Jenny and I actually produced a lot of camera-ready copy ourselves. But for most books, whatever you turn over to your publisher will get transmogrified into their own internal format.
b) The production editor people I've worked with and talked to (not just at O'Reilly, but at other publishers, too) have been extremely competent, and it's their job to take whatever it is you give them and make it work. It needs to be copyedited, typeset, and reviewed, and sent to a printer. I highly recommend getting to know them, and being as flexible and agreeable as possible (they generally won't ask you to compromise your vision for the book -- it's generally about technical stuff, like how to deal with footnotes, references, images, etc.)
c) You asked about version control. One of the best authors I've ever worked with, Karl Fogel -- he's a contributor to Beautiful Teams, and also just a great guy -- wrote a fantastic book called Producing Open Source Software, which you can buy from O'Reilly or download for free from the website. (Anyone who's interested in starting or contributing to an open source project absolutely needs to read that book. Disclosure: I was a technical reviewer for it.) In true open source fashion, Karl made his version control repository for the book available, and that's a good model to copy. Jenny and I didn't do anything quite so formalized; we just shared folders, and that was sufficient for us (even with hundreds and hundreds of image files for each Head First book).
d) This is the most important thing: make sure you have a clear idea of what it is you want to write! It's easy to get started on a project, only to have it trail off because you don't really have a whole book's worth of material. The more you can outline, the more research you do, and the more you prepare, the better the book will be.
Now, that's all assuming that you have a publisher lined up and a contract signed. If you don't, I highly recommend reading through the excellent Writing for O'Reilly section on their website. They walk you through all of the steps of proposing a book and the mechanics of actually working with a publisher -- and from everyone I've talked to, it's very similar
$ grep -i "^a*b*c*d*e*f*g*h*i*j*k*l*m*n*o*p*q*r*s*t*u*v*w*x*y*z*$" /usr/share/dict/words | perl -ne 's/\n//; print length($_); print " $_\n";' | sort | tail -10
6 ghosty
6 glossy
6 knoppy
6 knotty
7 Adelops
7 alloquy
7 beefily
7 begorry
7 billowy
7 egilops
Guess my dictionary doesn't have "aegilops".
We get this question on the Head First C# forum every now and then from people who read the book, finish it, and want to know what to do next to get a programming career. Here's the post I usually send people to. One thing I think new developers should think about is working on a team -- that's a skill that takes practice, and doesn't always come easy to developers. The better you are at it, the more successful you'll be in your career. (I've got a few tips in that post for getting that kind of experience. Contributing to an open source project is definitely a good start. Karl Fogel's excellent book, Producing Open Source Software, is a great way to learn about how to do that effectively.)
It's very easy to turn sample files into ringtones for free. For Sprint PCS users, the Xingtone software just creates a GCD file (more info) and hosts is on a website for your phone to download. It converts the WAV file to Qualcomm PureVoice (.QCP) format (which you can do using Qualcomm's free converter for Windows and Linux). There's more info here.
Slashdot's posting of an old nemepool post came early this month! This was posted to memepool.com over a week ago.
This was posted on memepool yesterday with an interesting link. This seems to be happening more and more.
And personally, I think the combination of 30-year old Nixie tubes and modern PIC16F84 microcontrolers is simultaneously creepy and wonderful.