The same people who made the DvortyBoard also make the keyboard I use, the EZR2030 - see my sig for a full review. I had a DvortyBoard and the EZR2030 is much better IMHO.
I recently finished work on a "validated" application for a company regulated by the FDA. The validation process (which includes 21 CFR Part 11, covering electronic security) is intended to ensure that the software, as installed, meets the requirements and performs as expected. It tries to do this by requiring documentation of what are considered steps in good development methodology: requirements gathering, design elements, test cases, etc. It also covers things like installation - you have to take screen shots of the install process and show that they match what's in the install guide. The goal is provide traceability - that the design elements address the requirements, that the test cases cover the design, that the test cases were run and passed, and that the application was installed and configured correctly. I would imagine that the OCTAVE approach is similar, but focused on security.
You can argue whether these things actually improve or get in the way of effective software development. I found the process time-consuming and fairly tedious, but it did force me to do things I might rationalize away otherwise... so I did a better job. Even so, I think gaining the desired level of certainty about a complex application requires an end-to-end effort to achieve, and that it's a difficult task under the best of circumstances.
I wrote a little Java app (actually three apps) that allow me to stream audio over the network. The cool part (well, I think it's cool, anyway) is that it's in three pieces: a server, player, and controller. The server serves the files, the player plays it out to audio, and the controller (you guessed it) lets you set up playlists and jobs from a central location (there's little point in streaming audio to another room if you have to walk there to start it up). You can play multiple jobs to different rooms at the same time.
My wife uses this to stream music (in ogg and mp3 format) from my server downstairs to a Linux box in the living room I built for this purpose. She controls it from a GUI on a Windows box on the kitchen counter. I've tested it over wireless and it works fine.
I was thinking of putting this up on SourceForge - if anyone's interested let me know (msimpson at abel solutions dot com).
Funny, looking at the graph, it seems like the law has had no effect on spam. It was on an upward trend before the law took effect, and it has continued at more or less the same rate since.
Even if there were a change, I'd hesitate to assign causality until I was reasonably sure there weren't other factors that might have caused the change.
I guess I didn't make it clear that I don't advocate learning 'classical' strategies by rote just because they have that name. I'm with you that it all comes down to performance. But although I think labels like 'classical' are pretty much meaningless except in conversation, I also think it's fair to say that conventional strategies represent the 'low-hanging fruit' - things like controlling the center in a chess game are part of conventional strategy because they make practical sense. More unconventional strategies, like 'hypermodern' strategy in chess, represent the corner cases, and I think it's difficult to understand them without grokking the conventional stuff too. For that reason learning conventional strategy is good advice.
I'm definitely not saying you should limit yourself to that though, or that you should memorize it without understanding it, or (worst) that you should be complacent because you've memorized or understand it. I advocate understanding the underlying principles. Rejecting conventional wisdom because it's conventional is at least as bad as rejecting an unconventional strategy because it's unconventional; it's just stupid. But it's still very common to encounter this behavior. 'Elitist snobbery' has little to do with it, although I agree that speculating about somebody's motivation in pursuing a nonconventional strategy in a chess game is probably a waste of time (play the position, not the player).
I think I would go one step farther and say in a generic sense that kids want to be known for something. Some kids excel at math (and other subjects) because of natural aptitude and/or pressure from teachers and parents; but I think there's a threshold below which they feel they have no chance of distinguishing themselves relative to their peers. When a kid is below this threshold they don't even want to try, because they know they will fail. The next step for them is to compensate by acting as if, or convincing themselves that, their non-performance is intentional.
Hence the 'cool' factor. Cool is all about being in control of yourself and your environment. Trying and succeeding is cool if you treat it like just another thing. Not trying is cool by this definition because you're guaranteed of the intended result (it's a safe choice). Trying and failing shows you're not in control - not cool.
In some cases these kids find a niche to excel in, and sometimes that niche becomes non-performance itself. In any case, I think only certain kids are motivated by competition, and others shrink from it - it all depends on whether a kid thinks the game is fair and they have a chance of winning. These others might learn more in a system that was more non-competitive, but at least here in the U.S. a system like that wouldn't necessarily prepare the kid for "real life". In the end, you can't win if you don't play, and it's better to try, fail, try again, and win than to avoid playing because of fear of losing.
As a chess teacher once told me, "People who play classical openings generally do so because the ideas in them work. People who play oddball openings generally do so because they're unprepared and don't think they can compete, and want to change the battlefield to give themselves an unfair advantage. If you see an oddball opening, ask yourself, 'what is my opponent afraid of?'". While I think it's obviously presumptuous to apply this logic to everybody who does unconventional things, I do think it's applicable in many cases.
Anyway, back to the topic. The upshot of all this is that if you want kids to try, they need to feel 1) that the material is relevant to them, and 2) that they have a chance of competing, or that competition isn't the goal. Most kids aren't masochists and don't want to be forced to try if they think they will fail and suffer embarrassment (a big deal to most kids).
I agree. I prefer to use Enlightenment (btw, DR17 is now in CVS!), and one problem I've run into is that if I try to fire up Nautilus, it stomps all over the E desktop and pulls up the Gnome desktop instead... well, actually it's a kind of weird fusion, with the Gnome background and icons but E stuff there as well.
I do like E's eye candy, but am sympathetic to the parent poster's argument for a leaner, cleaner desktop/WM. Many of E's themes are over-the-top, but at least it's flexible and fast enough to support a lean environment. E runs at least twice as fast on my machine as either Gnome or KDE.
Who cares? My point is that bias proves nothing. Just about everybody is biased, and one can be biased and be right. It's more productive to focus on the issue in question - open-minded people listen to the argument, not the arguer, no matter who the arguer is.
The bias claim is often used by parties that don't have a real leg to stand on, and know it. The intended effect is to stifle real discussion of the issue.
Of course it's possible to have discussions about the bias (or lack thereof) itself, in which case the bias IS the issue; but that's a different story.
I interview candidates regularly for our (admittedly small) company, and the qualities I look for are 1) a good attitude and 2) interest in CS for its own sake. Experience comes next, followed by schooling. I think smart employers will hire for traits as opposed to specific knowledge, except possibly large employers with highly specialized jobs. I want to hire people who will go buy and read Godel, Escher, Bach on their own time, because they're interested in it; in other words, geeks with a lab at home and plenty of curiosity. I think there's some correlation between these people and students of colleges like MIT, but that's incidental and not something I can depend on.
It's about time somebody jumped on all these "liberal bias" claims. The "bias" argument is a distraction, and an excuse to avoid actually having to prove what you're saying.
I wrote a little system that does some of what he's looking for, but not all. Mine doesn't rip CDs (plenty of better tools for that), and mine has a GUI for setting up playlists and starting jobs. It's written in Java and uses an SWT interface, and supports MP3 and Ogg. Of course it won't run on ancient hardware, but that's fine with me.
None of that is especially interesting, but the cool part (to me) is that I wrote it as three separate apps - a server, player, and controller. The server runs wherever the music is stored. The player resides on a machine connected to a stereo or speakers. The controller can be on a third machine, and is what the user interacts with. One controller can set up multiple jobs streaming different music to different players, and you can shut down the controller once the jobs are running. All three pieces discover each other on the local network via broadcast.
In my house, I have the server on a Windows machine downstairs in my office, the player on a Linux box in my living room connected to the stereo, and the controller on both my Linux laptop and my wife's Windows XP box in the kitchen.
I'm thinking of open-sourcing the app (it's basically alpha/beta quality right now - usable, but needs more features and a little rework)... if anyone's interested in looking at it, let me know (msimpson at abelsolutions dot com).
Polymorphism addresses the strict need, but makes you write extra code. In cases where you need to pass varying numbers of parameters of the same type, let's say from 1 to 10 strings, polymorphism does work, because you know before compiling how many parameters you need. But it's cleaner to write a single method to handle them, than to write one real method and 9 overloads; or to bundle the strings into a collection or array before passing them.
In cases where you don't know how many arguments you need to pass until runtime, both approaches are useless and you need to use a collection of some sort.
We're talking about some fairly specific cases here, but this enhancement does have the potential to clean up the code (and docs). Simplifying APIs is good all around.
I think "exposure" in this sense is a measure of the consequences of an accident, not how often you're exposed to the danger - think of it as "damage". Your exposure with an airplane is higher than with a car, because a plane crash will more likely kill the plane's passengers than a car crash kill the car's passengers. However the probability of a plane crashing is much lower than a car crashing, hence the lower overall risk.
The safety record achieved by the major airlines is simply amazing when compared to most other industries, considering the size and complexity of the airline industry. That said, it's taken over half a century to get there, and although it may not take as long for the space industry, it will still be a while.
This is an interesting approach... I work for a small company currently doing software work in both the pharma (including FDA 21 CFR Part 11) space and the banking space. Though I don't think these standards currently address in what format the documentation must be captured, if they did, the impact would be significant.
This would not just force Microsoft to start supporting these open standards, but it would have the same effect on a bunch of other companies, for example Seagate (maker of Crystal Reports). Not to mention the myriad producers of custom software for pharma and banking companies.
I got the impression the profs were always looking for the next F. L. Wright (or Corbu or Gaudi) and wouldn't give us any insight into their (or any "real") design thought process, for fear of influencing our creative development.
I'm also much happier in the tech world... have gone back to study business now and am enjoying it. Like you, my only regret is that I didn't switch majors after one year instead of quitting in disgust after four.
As one of those whiny former architorture students (studied it for four years), these contest submissions remind me of everything I hated about the subject. Namely: lots of pseudo-intellectual babble, and a propensity to design buildings based on arbitrary objects with no eye towards function. For example, my classmates used to do things like base the building design on a "found object" (piece of junk) from the site, or maybe on some random patterns generated by a pet with a marker. The fact that this rewarded is incredibly frustrating to someone who demands any kind of rational justification for their own design ideas.
I should state that I don't have these objections to the profession of architecture itself (I have other ones); just the way it's taught. My wife is a licensed architect, and she suffers from the scars inflicted by a typical architecture school, but from few of the goofy delusions enjoyed by its students.
Is there any practical reason why, when I run Nautilus, it stomps all over my Enlightenment desktop? I'd love to be able to use Nautilus, but it replaces my background and displays Gnome's desktop icons and task bar without asking me. Pretty obnoxious IMHO... this is why, until E17 comes out, when I want a graphical file manager, I will continue to run Konqueror.
Slashdot Mirror
The same people who made the DvortyBoard also make the keyboard I use, the EZR2030 - see my sig for a full review. I had a DvortyBoard and the EZR2030 is much better IMHO.
I am a Dvorak typist. Check out my sig for a review of the keyboard I use - it's pretty slick in my opinion.
I recently finished work on a "validated" application for a company regulated by the FDA. The validation process (which includes 21 CFR Part 11, covering electronic security) is intended to ensure that the software, as installed, meets the requirements and performs as expected. It tries to do this by requiring documentation of what are considered steps in good development methodology: requirements gathering, design elements, test cases, etc. It also covers things like installation - you have to take screen shots of the install process and show that they match what's in the install guide. The goal is provide traceability - that the design elements address the requirements, that the test cases cover the design, that the test cases were run and passed, and that the application was installed and configured correctly. I would imagine that the OCTAVE approach is similar, but focused on security.
You can argue whether these things actually improve or get in the way of effective software development. I found the process time-consuming and fairly tedious, but it did force me to do things I might rationalize away otherwise... so I did a better job. Even so, I think gaining the desired level of certainty about a complex application requires an end-to-end effort to achieve, and that it's a difficult task under the best of circumstances.
I've put the system up on my site here. There are screenshots there too. Enjoy!
I wrote a little Java app (actually three apps) that allow me to stream audio over the network. The cool part (well, I think it's cool, anyway) is that it's in three pieces: a server, player, and controller. The server serves the files, the player plays it out to audio, and the controller (you guessed it) lets you set up playlists and jobs from a central location (there's little point in streaming audio to another room if you have to walk there to start it up). You can play multiple jobs to different rooms at the same time.
My wife uses this to stream music (in ogg and mp3 format) from my server downstairs to a Linux box in the living room I built for this purpose. She controls it from a GUI on a Windows box on the kitchen counter. I've tested it over wireless and it works fine.
I was thinking of putting this up on SourceForge - if anyone's interested let me know (msimpson at abel solutions dot com).
Funny, looking at the graph, it seems like the law has had no effect on spam. It was on an upward trend before the law took effect, and it has continued at more or less the same rate since.
Even if there were a change, I'd hesitate to assign causality until I was reasonably sure there weren't other factors that might have caused the change.
I guess I didn't make it clear that I don't advocate learning 'classical' strategies by rote just because they have that name. I'm with you that it all comes down to performance. But although I think labels like 'classical' are pretty much meaningless except in conversation, I also think it's fair to say that conventional strategies represent the 'low-hanging fruit' - things like controlling the center in a chess game are part of conventional strategy because they make practical sense. More unconventional strategies, like 'hypermodern' strategy in chess, represent the corner cases, and I think it's difficult to understand them without grokking the conventional stuff too. For that reason learning conventional strategy is good advice.
I'm definitely not saying you should limit yourself to that though, or that you should memorize it without understanding it, or (worst) that you should be complacent because you've memorized or understand it. I advocate understanding the underlying principles. Rejecting conventional wisdom because it's conventional is at least as bad as rejecting an unconventional strategy because it's unconventional; it's just stupid. But it's still very common to encounter this behavior. 'Elitist snobbery' has little to do with it, although I agree that speculating about somebody's motivation in pursuing a nonconventional strategy in a chess game is probably a waste of time (play the position, not the player).
I think I would go one step farther and say in a generic sense that kids want to be known for something. Some kids excel at math (and other subjects) because of natural aptitude and/or pressure from teachers and parents; but I think there's a threshold below which they feel they have no chance of distinguishing themselves relative to their peers. When a kid is below this threshold they don't even want to try, because they know they will fail. The next step for them is to compensate by acting as if, or convincing themselves that, their non-performance is intentional.
Hence the 'cool' factor. Cool is all about being in control of yourself and your environment. Trying and succeeding is cool if you treat it like just another thing. Not trying is cool by this definition because you're guaranteed of the intended result (it's a safe choice). Trying and failing shows you're not in control - not cool.
In some cases these kids find a niche to excel in, and sometimes that niche becomes non-performance itself. In any case, I think only certain kids are motivated by competition, and others shrink from it - it all depends on whether a kid thinks the game is fair and they have a chance of winning. These others might learn more in a system that was more non-competitive, but at least here in the U.S. a system like that wouldn't necessarily prepare the kid for "real life". In the end, you can't win if you don't play, and it's better to try, fail, try again, and win than to avoid playing because of fear of losing.
As a chess teacher once told me, "People who play classical openings generally do so because the ideas in them work. People who play oddball openings generally do so because they're unprepared and don't think they can compete, and want to change the battlefield to give themselves an unfair advantage. If you see an oddball opening, ask yourself, 'what is my opponent afraid of?'". While I think it's obviously presumptuous to apply this logic to everybody who does unconventional things, I do think it's applicable in many cases.
Anyway, back to the topic. The upshot of all this is that if you want kids to try, they need to feel 1) that the material is relevant to them, and 2) that they have a chance of competing, or that competition isn't the goal. Most kids aren't masochists and don't want to be forced to try if they think they will fail and suffer embarrassment (a big deal to most kids).
Will try that - thanks!
I agree. I prefer to use Enlightenment (btw, DR17 is now in CVS!), and one problem I've run into is that if I try to fire up Nautilus, it stomps all over the E desktop and pulls up the Gnome desktop instead... well, actually it's a kind of weird fusion, with the Gnome background and icons but E stuff there as well.
I do like E's eye candy, but am sympathetic to the parent poster's argument for a leaner, cleaner desktop/WM. Many of E's themes are over-the-top, but at least it's flexible and fast enough to support a lean environment. E runs at least twice as fast on my machine as either Gnome or KDE.
Who cares? My point is that bias proves nothing. Just about everybody is biased, and one can be biased and be right. It's more productive to focus on the issue in question - open-minded people listen to the argument, not the arguer, no matter who the arguer is.
The bias claim is often used by parties that don't have a real leg to stand on, and know it. The intended effect is to stifle real discussion of the issue.
Of course it's possible to have discussions about the bias (or lack thereof) itself, in which case the bias IS the issue; but that's a different story.
I'm going to name mine Bob :-)
Mike
I interview candidates regularly for our (admittedly small) company, and the qualities I look for are 1) a good attitude and 2) interest in CS for its own sake. Experience comes next, followed by schooling. I think smart employers will hire for traits as opposed to specific knowledge, except possibly large employers with highly specialized jobs. I want to hire people who will go buy and read Godel, Escher, Bach on their own time, because they're interested in it; in other words, geeks with a lab at home and plenty of curiosity. I think there's some correlation between these people and students of colleges like MIT, but that's incidental and not something I can depend on.
It's about time somebody jumped on all these "liberal bias" claims. The "bias" argument is a distraction, and an excuse to avoid actually having to prove what you're saying.
See Carl Sagan's Baloney Detection Kit for a good description of logical fallacies, including the one mentioned in the parent post.
I'd only consider this "spyware" if it sent confidential information back to Google without telling me. There's no indication that it does that.
As for security against other local users, I agree with the vast majority of posters that this is a non-issue.
I wrote a little system that does some of what he's looking for, but not all. Mine doesn't rip CDs (plenty of better tools for that), and mine has a GUI for setting up playlists and starting jobs. It's written in Java and uses an SWT interface, and supports MP3 and Ogg. Of course it won't run on ancient hardware, but that's fine with me.
None of that is especially interesting, but the cool part (to me) is that I wrote it as three separate apps - a server, player, and controller. The server runs wherever the music is stored. The player resides on a machine connected to a stereo or speakers. The controller can be on a third machine, and is what the user interacts with. One controller can set up multiple jobs streaming different music to different players, and you can shut down the controller once the jobs are running. All three pieces discover each other on the local network via broadcast.
In my house, I have the server on a Windows machine downstairs in my office, the player on a Linux box in my living room connected to the stereo, and the controller on both my Linux laptop and my wife's Windows XP box in the kitchen.
I'm thinking of open-sourcing the app (it's basically alpha/beta quality right now - usable, but needs more features and a little rework)... if anyone's interested in looking at it, let me know (msimpson at abelsolutions dot com).
Polymorphism addresses the strict need, but makes you write extra code. In cases where you need to pass varying numbers of parameters of the same type, let's say from 1 to 10 strings, polymorphism does work, because you know before compiling how many parameters you need. But it's cleaner to write a single method to handle them, than to write one real method and 9 overloads; or to bundle the strings into a collection or array before passing them.
In cases where you don't know how many arguments you need to pass until runtime, both approaches are useless and you need to use a collection of some sort.
We're talking about some fairly specific cases here, but this enhancement does have the potential to clean up the code (and docs). Simplifying APIs is good all around.
Maybe I'll finally have a chance at winning a match in UT 2004 now that all the ringers are offline playing in a tournament :-)
"Monster Kill", here I come!
I think "exposure" in this sense is a measure of the consequences of an accident, not how often you're exposed to the danger - think of it as "damage". Your exposure with an airplane is higher than with a car, because a plane crash will more likely kill the plane's passengers than a car crash kill the car's passengers. However the probability of a plane crashing is much lower than a car crashing, hence the lower overall risk.
The safety record achieved by the major airlines is simply amazing when compared to most other industries, considering the size and complexity of the airline industry. That said, it's taken over half a century to get there, and although it may not take as long for the space industry, it will still be a while.
This is an interesting approach... I work for a small company currently doing software work in both the pharma (including FDA 21 CFR Part 11) space and the banking space. Though I don't think these standards currently address in what format the documentation must be captured, if they did, the impact would be significant.
This would not just force Microsoft to start supporting these open standards, but it would have the same effect on a bunch of other companies, for example Seagate (maker of Crystal Reports). Not to mention the myriad producers of custom software for pharma and banking companies.
Studied it for four years and still cant spell it?
Archi-torture. Get it? And I also know how and when to use apostrophes.
I got the impression the profs were always looking for the next F. L. Wright (or Corbu or Gaudi) and wouldn't give us any insight into their (or any "real") design thought process, for fear of influencing our creative development.
I'm also much happier in the tech world... have gone back to study business now and am enjoying it. Like you, my only regret is that I didn't switch majors after one year instead of quitting in disgust after four.
As one of those whiny former architorture students (studied it for four years), these contest submissions remind me of everything I hated about the subject. Namely: lots of pseudo-intellectual babble, and a propensity to design buildings based on arbitrary objects with no eye towards function. For example, my classmates used to do things like base the building design on a "found object" (piece of junk) from the site, or maybe on some random patterns generated by a pet with a marker. The fact that this rewarded is incredibly frustrating to someone who demands any kind of rational justification for their own design ideas.
I should state that I don't have these objections to the profession of architecture itself (I have other ones); just the way it's taught. My wife is a licensed architect, and she suffers from the scars inflicted by a typical architecture school, but from few of the goofy delusions enjoyed by its students.
Is there any practical reason why, when I run Nautilus, it stomps all over my Enlightenment desktop? I'd love to be able to use Nautilus, but it replaces my background and displays Gnome's desktop icons and task bar without asking me. Pretty obnoxious IMHO... this is why, until E17 comes out, when I want a graphical file manager, I will continue to run Konqueror.
That's why I recommended the book ;-)