They've been saying this for years. Even gave me a t-shirt emblazoned with "DOS Is Dead" in about 1995 or 1996. This was around the time of DOS-based Win95 (DOS Ain't Dead, just hiding), which was followed by DOS-based Win98 (DOS Ain't Dead, just sleeping), which was followed by DOS-based Win ME (DOS Ain't Dead, just comatose).
I guess with the home version of XP they really do mean it this time?
Click the link in my signature if you're interseted in a free program that lets you design and play with virtual radio-controlled toys. I hesitate to use the word 'robot' as the control system language isn't expressive enough for much more than joystick control of walking critters, but it's kinda fun.
An open-source multiuser "arena" runtime is only a matter of time.
If they want to get this done in ten years, they will need to collect over 270 CDs per day, every day, for the next ten years. AOL may send out far more than that, but they will have a hard time getting that many people to play this game.
I'll wager AOL gives up the CD campaign before they reach their mark, leaving these guys with a really big pile of CDs, and no campaign to protest.
Don't get me wrong, I do think it's a neat idea, I just think they set their sights a couple orders of magnitude higher than is practical.
I had a similar thought, but sans Wiki only because I haven't used it much (seems interesting though).
I think that guy might be well served by viewing his need as a bug tracking system that he can use for requirements management, rather than a requirements management system that he can use for bug tracking.
I was on a project a while back where the QA lead entered the requirements doc point-by-point into the defect tracking system with each functional requirement tracked as a missing feature.
Sounds awkward, and at first it even ticked a few of us off to have a bunch of bugs logged against us when we hadn't even begun coding yet... but it actually worked pretty well.
Not ideal for a few reasons, most notably because moving information between the requirements doc and the bug tracking system is a tedious manual process, and because the mapping between them can be ambiguous and the source of some contention. But, if you can't find just what you want, and can't justify investing the time to build just what you want, it's another option.
Who said anything about monolithic software design?
You did: designing the UI and a class hierarchy almost always leads to that.
Not if you design it to be modular.
Either the developer needs to throw away a couple of designs and implementation attempts, or he needs to design and implement multiple, small, loosely coupled programs.
Or loosely coupled modules, e.g. the plug-ins the questioner was talking about. And as I said, I don't claim to have a way around rewrites and throwaways. However, I've seen a lot more time wasted writing thrown-away code than writing thrown-away design docs.
The only way to learn how to write software is by writing software. [...] It's silly to expect that planning can replace experience.
Agreed on both counts. Someone once said that if you want to write a great piece of software, write two and throw the first one away. (Donald Knuth?)
That's common among professionals (when they get the time to write the second one, anyhow) and it's inevitable with a novice developer. He's gonna have some false starts, and they will be a key part of the learning process, and there's no way around that.
He's gonna throw away code, that's a given. IHe'll be even better off if he throws away some design docs as well. It's neither necessary nor sufficient, but it's still valuable.
Yes, and you will end up with software that looks like it was coded by a semi-talented high school student.
Yep. Don't get me wrong - I'm not advocating that approach.:-)
And what you will get out of that process is a professional Windows-style application--a big, monolithic piece of software with lots of buttons.
Who said anything about monolithic software design? I'm suggesting he do the design up front. Whether he chooses to go with a monolith or a suite it entirely up to him.
[...] those ideas are usually not backed by a lot of practical experience.
True, but if he's willing to separate wheat and chaff, there's probably enough people here who know what they're talking about that asking here will not have been a waste of his time.
Especially if he's not discouraged by the e-holes ridiculing him for thinking big. While it's true that he probably won't realize all of his goals, before he's done he will have learned a lot and had a lot of fun. What else matters?
First, not coding yet is a good idea, and one that's lost on a lot of people. Think first, design, plan, write down your designs and plans (the very act of writing forces you to think about them more), and re-read them to think about them some more. Better yet, find some like-minded people to critique your designs and plans. They'll see things you won't.
Changing designs is easy and painless when you've only invested a couple paragraphs. It's a huge pain in the ass when you've invested hours or weeks or months.
I used to work for a manager who believed that with a good design document, you could hire a semi-talented high school student to do the coding. I think that's design documentation beyond the point where diminishing returns sets in, but on the other hand, you I also believe that if you know what it is you're going to create, you can't write too much design documentation. XP and "agile programming" are great for situations in which the client changes the requirements regularly, but if you have a clear picture of what you're creating, it's worth spending lots of time on documentation. In my experience it saves far more time than it costs.
Design the user interface, and write that down, in detail.
Do a high-level design of the whole system - what are the objects, what are their responsibilities, and how to they communicate?
For each class, do a detailed design. How does it carry out its responsibilities?
Then re-read the whole thing and look for issues that you didn't see when you started. Have a teammate reread the whole thing and look for issues. Look for assumptions you didn't know you had. Look for objects that have been tasked with doing things that they can't do with the information or interfaces they have available.
Then figure out a game plan, a timeline, that will get you a minimal application with at least some usable functionality. That gives you a gratifying achievable goal to shoot for, and it gives you something functional to (hopefully) help keep you inspired.
Three weeks ago I would have laughed at this suggestion. But, three weeks ago I'd never messed with C# and the.Net API. I figured they were a necessary evil though, and set about learning them.
Today I have a nifty little directed-graph editor with cut/copy/paste, a palette of nodes to be drag-dropped onto the graph, a property window for selected objects, and multi-level undo/redo. I've written 4-5 such things in the past using C++ (I have this digraph fetish, you see) but I never got near as much done in three weeks. The timeline really impressed me.
Other environments may be just as effective, of course. I've only dabbled with java and smalltalk, so I'm not in a position to compare. I just know C# and.Net make for a pretty productive platform.
And no, I don't work for MS. In fact I've loathed them since bundled their email application to their (monopoly-holding) operating system, thus both tying and dumping, and thus putting a previous employer of mine out of business. That's a pervasive rant though, so I'll stop here.:-)
Anyhow, in spite of its birthplace, C# and.Net will be the foundation for my next couple of personal projects, and possible for many more, until something better comes along. I really like what I've seen so far.
No multiple-inheritance ( before you cry: having 20 level inheritance trees from 3 different objects SUCKS in any language, but occasionally deriving from more than one object comes handy once in a while)
Oh quit your bitching. Want to reuse the same few functions across a set of classes? That's what the clipboard is for. You know, copy and paste. Just paste that useful code into every class that needs it.
Want to change, extend, or trim back that code that cut-pasted code that should have been a base class? That's what search-and-replace is for. You've got a lovely IDE, learn to use it.
Me? Bitter?
Seriously though, I've been thinking about creating a language called D. D is a half-step above C#. D will look just like C#, but it will add a new keyword: derivesfrom. Then you can write code like this:
public class BaseClass
{
// implementation and stuff goes here
}
public class Widget derivesfrom BaseClass, OtherBaseClass : IWhatever, ISomethingElse
{
// you know
}
The D "compiler" will read such things and emit perfectly compilable C# code, sparing you the cut-paste madness known as "code reuse" in the C# world. The only question is whether D should be implemented as a perl script (because I have a sense of humor) or as a D application (because geeks (like me) are fond of self-reference).
As a friendly gesture to those who oppose MI, the D compiler will spit out an error message if you attempt to derive from two classes that share a common base class. This one pathological example seems to have scared the bejeezus out of language designers everywhere. Other abuses of MI might be handled with stern warnings.
I submitted the project to the good people at SourceForge a few minutes ago. In the meantime, contact me directly if you're interested in bringing D to fruition.
FWIW, C++ and other languages have long has this ability thanks to Doxygen and similar tools. It's cool stuff. Doxygen doesn't use XML, but the syntax is pretty straightforward.
I ran into something like this on an application I'm writing... when I first made an MPEG recording of my 3D output, there were no textures. About 3 seconds and one forehead-slap later I realized that the video card's memory (where the rendering happens) isn't on the CPU's bus (where the recording happens).
It seems the lesson here is that proper captures from video RAM are slow. Yeah, it'd be nice to change that. But how many people really care? Given how long it took anyone to notice, I can't help but think that very very few people really care - and with good reason. Unless you're into making rendered movies, it's irrelevant.
Lets just say the microsoft simulator won't save you lots of time learning how to fly a real helicopter.
I know nothing about full-size helis, but the PC simulators available for RC heli practice are spectacularly useful. I pity people who learn without them. It's possible of course, but simulators make it so much easier it's almost like cheating. Even all the way into complex aerobatics... I still practice stuff on the simulator all the time before I do it out at the field.
Most of the commercial RC heli simulators cost $200ish, but it's money well spent. That's the cost of a couple crashes with the model, and a sim will save you from way more than just two crashes. I highly recommend a sim to anyone getting into RC helis.
Weight: I have alchohol powered helis that weigh roughly 2, 6.5, 9.5, and 10.25 pounds. The light one (2 pounds or so) kinda sucks. The other three are fully aerobatic and tons of fun.
Flight times: They all get about 10-15 minutes on a tank of fuel, as the other fellow said. The control system battery needs to be recharged every 4-6 flights. Eletrics typically fly 4-6 minutes on a charge, but flight times and performance are getting better all the time for those things (I'm hoping to switch to electric when they can make good power for 10 minute flights, but it will probably be a couple years at least). Gasoline powered helis (only available in the larger size, around 12 pounds) run for 25-45 minutes on a tank of fuel, but they don't have quite the same power-to-weight ratio as alcohol burners. Alcohol helis are more popular for aerobatics. Gassers are popular for aerial photography because they have almost no exhaust trail, and for everyday flyers who aren't as concerned with aerobatics and who enjoy cheap fuel (alcohol is $12-25/gallon depending on various factors including the nitro content).
Cameras: I put a video camera and wireless video transmitter on a couple of mine, with the intention of recording aerobatics from the 'pilots' point of view. There are small cameras that work pretty well for this, the handling of the helicopter was unchanged. Unfortunately, the video range you get with FCC-license-free video transmitters is not very good. It works well for upright flight, but the signal drops out a lot during aerobatics.
Click here for one of my videos. I made this one to demonstrate the video drop-out problem, so it's pretty bad. I had a couple others that (by pure luck) had better reception, but unfortunately I don't have copies online on a server that can take a slashdotting.
I got a ham license a couple summers ago specifically so I could get some more powerful transmitters for wireless video, but I haven't upgraded the video transmitter yet. It's still something I want to do, though. I'll get around to it eventually.
A helicopter has a tail fin that helps orient it nose-to-the-wind in flight. This craft needs something like that before it can fly figure eights with the same ease.
I added a vertical stabilizer to my Roswell (Draganflyer = Roswell Flyer v2.0, same electronics on a more robust chassis). The fin did help keep it pointed forward, but then the problem is the pitch & roll response. It turns out that a platform with four flybarless rotors fly just as bad as a heli with a single flybarless rotor. It's really hard to describe, but if you've flown a flybarless heli, you know what I'm talking about.
These are OK for indoor flying where you never build up much speed, but beyond that they're a real handful.
Trust me, I have one of these things. They hover about the same as a regular heli, but once you get the thing moving, it's like flying a flybarless single-rotor RC heli: it sucks.
Some friends and I put gyros on a flybarless heli once, just to see what would happen, and while they tame down the bad behaviors, they don't help nearly as much as a flybar. The Draganflyer (fak Roswell Flyer) feels about as bad as a flybarless heli, and probably for the same reasons (no flybar on the Roswell, just wacky rotor flapping due to disymmetry of list). I'd prefer a flybar-equipped rotor over flybarless any day, and the (flybarless) Roswell Flyer / Draganflyer is no exception.
In short, it seems you just haven't yet understood what the Draganflyer does.
Seems to me he knows exactly what the score is. I've flown one. Have you?
I have been flying fuel-powered helis for years, and bought one of these quad-rotor contraptions when they first came out in 1999 (it was called the "Roswell Flyer" back then). It's kinda fun, but it's no easier to control than a regular (single-rotor) RC heli. In fact, it's a lot harder if you want to fly it with any speed.
Piezo gyros are almost standard now for yaw stability on regular helis, but the ones now available for regular helis to better than the ones on the Draganflyer. Regular helis use a "flybar" in the rotor head that does the same thing the as the other two piezo elements on the Draganflyer - but, again, they do it better. The Draganflyer hovers with about the same difficulty as a regular heli - the feel isn't even much different - but once you get moving faster than a crawl, it becomes a real handful. Regular helis are actually much easier to control when flying with any speed. Regular RC helis also have aerobatic potential that fixed-pitch machines like the Draganflyer can't even come close to.
It's not a bad way to get the hand-eye coordination for hovering, but if (when) you want to get it flying around or get into aerobatics, you'll need something else entirely. And if you're looking for a way to get started with RC helis, a PC simulator is a much better investment.
If I recall correctly, once upon a time, Apple had a project codenamed Sagan. Codenamed, mind you, not actually released under that name. Even so, a certain famous astronomer complained. The project was renamed "Butthead Astronomer."
(I believe he complained again, and the name was changed yet again, but I'm not sure...)
I believe that's the root of the Mozilla thing. I also strongly suspect that whoever coined the term Mozilla probably knew about that the word Godzilla, and intended (however innocently - remember, this was basically a student project) to bring Godzilla to mind with the mention of Mozilla. I also strongly suspect that this person knew, or had reason to believe, that Godzilla is someone else's trademark.
I also strongly suspect that this person just slapped his/her forehead upon reading about the case in question. It was probably an innocent mistake by a person with a sense of humor and no idea that anyone outside their little comp-sci community would see it... Oooops. Don't you just hate it when pet project get out of control and take a life of their own?
One could argue that Mozilla now has a widely-understood meaning separate to Godzilla (especially considering that Microsoft sends a Mozilla string with every HTTP request), but it would take a lawyer to tell whether that's a meaningful defense. IANAL; I dunno.
On the extremely rare occasion that I want mass mail, I add the 'from' address to the whitelist manually.
I assuming that spammers will not take the trouble to figure out what email addresses are in my whitelist, nor would they take the trouble to send messages customized for each of their recipients. Technically possible, sure, but I figure that's an intractable problem, considering the sizes of the lists spammers use. First, finding a suitable 'from' address to use for each of a million customers would be tedious. Second, such addresses would be removed from the whitelist as soon as it became clear that a spammer was using it to get through the filter. Third, SMTP works well for mass mailings with a single 'from' address, but the bandwidth requirements go way up if you want a different 'from' address for each recipient.
There are potential problem with this approach, but none are nearly as big as the problem of widespread enhacment or duplication of the existing email infrastructure. I do agree that the ultimate solution is to augment or replace SMTP, but in the meantime, this works and it works very well.
First there's the fact that most 'mail this address to be unsubscribed' addresses just don't work. No such mailbox. Then there's the fact that those that do work fall into three categories: those that are utterly ignored (that's most of them), those that are used to collect valid email addresses, and the remainging (very) few that are actually honored.
Then there's the fact that most spamming operations are one-time operations. The next time that spammer spams, it'll be a different product, and you didn't unsubscribe from THAT product's list. You'll have to unsubscribe again.
Then there's the fact that unsubscribing from opt-out lists one at a time - assuming that you've encountered the rare situation where the spammer actually honors the unsubscribe requests - does nothing to discourage spammers from sending more spam. Yanking their accounts causes them a bit of trouble, and often costs them a bit of money, since such cancellations do not include refunds. Keeping abuse departments busy makes ISPs less likely to take contracts from spammers.
But it's your mailbox, so go ahead and reply to the unsubscribe addresses. That action (read: confirming that your email address actually works) will get you a net increase in the amount of incoming spam. But, if it makes you feel better, who am I to advise against it?
If you want to do something, get the spammers' accounts terminated.
If you want to do something really useful, write your legislators. Ask for a junk email law modeled on the junk-fax law: No unsolicited contact without a pre-existing business relationship.
If you're just tired of the whole game, get a whitelist-based filter with automated confirmat. It will eliminate virtually all of your incoming spam. It works for me.
1) receiving mail server compares 'from' address with a list of known correspondents (a whitelist) 2a) if the 'from' address is in the whitelist, the message is delivered 2b) if the 'from' address is unknow, the message is MD5-hashed, copied to a holding pen, and then bounced with a note that says, in effect, "please confirm your email address by replying to this message with the subject line intact." The subject line of course contains the MD5 hash.
Meanwhile, if a message is received with an MD5 hash that matches something in the holding pen, the sender's address is added to the whitelist and the message in the holding pen is delivered.
This does eliminate spoofed spam, with no need to modify anyone else's email infrastructure - it's all done with procmail on my own server. I've received exactly two pieces of spam in the last six months. Both were from Nigerian bank scammers. Apparently they are the last spammers in the world to figure out forged from addresses. When they catch on, they'll disappear too.
I use this filter on email addresses that have been exposed to the public. Email to my 'private' addresses, which give only to trusted individuals, is delivered straight to my inbox.
Slashdot Mirror
I guess with the home version of XP they really do mean it this time?
Oh well. At least I can be still the first to say:
This brings a whole new meaning to the term "pipe dream" doesn't it? (heh, heh)
Oh, I slay myself.
An open-source multiuser "arena" runtime is only a matter of time.
I'll wager AOL gives up the CD campaign before they reach their mark, leaving these guys with a really big pile of CDs, and no campaign to protest.
Don't get me wrong, I do think it's a neat idea, I just think they set their sights a couple orders of magnitude higher than is practical.
I think that guy might be well served by viewing his need as a bug tracking system that he can use for requirements management, rather than a requirements management system that he can use for bug tracking.
I was on a project a while back where the QA lead entered the requirements doc point-by-point into the defect tracking system with each functional requirement tracked as a missing feature.
Sounds awkward, and at first it even ticked a few of us off to have a bunch of bugs logged against us when we hadn't even begun coding yet... but it actually worked pretty well.
Not ideal for a few reasons, most notably because moving information between the requirements doc and the bug tracking system is a tedious manual process, and because the mapping between them can be ambiguous and the source of some contention. But, if you can't find just what you want, and can't justify investing the time to build just what you want, it's another option.
You did: designing the UI and a class hierarchy almost always leads to that.
Not if you design it to be modular.
Either the developer needs to throw away a couple of designs and implementation attempts, or he needs to design and implement multiple, small, loosely coupled programs.
Or loosely coupled modules, e.g. the plug-ins the questioner was talking about. And as I said, I don't claim to have a way around rewrites and throwaways. However, I've seen a lot more time wasted writing thrown-away code than writing thrown-away design docs.
Agreed.
I cannot begin to think of the number of times I have gone back and rewrote something over just because it was just not right enough.
But then again I am not a professional software developer and don't have a due date to meet.
What, like that would make a difference? :-)
Agreed on both counts. Someone once said that if you want to write a great piece of software, write two and throw the first one away. (Donald Knuth?)
That's common among professionals (when they get the time to write the second one, anyhow) and it's inevitable with a novice developer. He's gonna have some false starts, and they will be a key part of the learning process, and there's no way around that.
He's gonna throw away code, that's a given. IHe'll be even better off if he throws away some design docs as well. It's neither necessary nor sufficient, but it's still valuable.
Yep. Don't get me wrong - I'm not advocating that approach. :-)
And what you will get out of that process is a professional Windows-style application--a big, monolithic piece of software with lots of buttons.
Who said anything about monolithic software design? I'm suggesting he do the design up front. Whether he chooses to go with a monolith or a suite it entirely up to him.
True, but if he's willing to separate wheat and chaff, there's probably enough people here who know what they're talking about that asking here will not have been a waste of his time.
Especially if he's not discouraged by the e-holes ridiculing him for thinking big. While it's true that he probably won't realize all of his goals, before he's done he will have learned a lot and had a lot of fun. What else matters?
Anyhow, I have a bit of experience (and some of it with a not-completely-unrelated project), so I thought I'd chime in.
First, not coding yet is a good idea, and one that's lost on a lot of people. Think first, design, plan, write down your designs and plans (the very act of writing forces you to think about them more), and re-read them to think about them some more. Better yet, find some like-minded people to critique your designs and plans. They'll see things you won't.
Changing designs is easy and painless when you've only invested a couple paragraphs. It's a huge pain in the ass when you've invested hours or weeks or months.
I used to work for a manager who believed that with a good design document, you could hire a semi-talented high school student to do the coding. I think that's design documentation beyond the point where diminishing returns sets in, but on the other hand, you I also believe that if you know what it is you're going to create, you can't write too much design documentation. XP and "agile programming" are great for situations in which the client changes the requirements regularly, but if you have a clear picture of what you're creating, it's worth spending lots of time on documentation. In my experience it saves far more time than it costs.
Design the user interface, and write that down, in detail.
Do a high-level design of the whole system - what are the objects, what are their responsibilities, and how to they communicate?
For each class, do a detailed design. How does it carry out its responsibilities?
Then re-read the whole thing and look for issues that you didn't see when you started. Have a teammate reread the whole thing and look for issues. Look for assumptions you didn't know you had. Look for objects that have been tasked with doing things that they can't do with the information or interfaces they have available.
Then figure out a game plan, a timeline, that will get you a minimal application with at least some usable functionality. That gives you a gratifying achievable goal to shoot for, and it gives you something functional to (hopefully) help keep you inspired.
Good luck.
Today I have a nifty little directed-graph editor with cut/copy/paste, a palette of nodes to be drag-dropped onto the graph, a property window for selected objects, and multi-level undo/redo. I've written 4-5 such things in the past using C++ (I have this digraph fetish, you see) but I never got near as much done in three weeks. The timeline really impressed me.
Other environments may be just as effective, of course. I've only dabbled with java and smalltalk, so I'm not in a position to compare. I just know C# and .Net make for a pretty productive platform.
And no, I don't work for MS. In fact I've loathed them since bundled their email application to their (monopoly-holding) operating system, thus both tying and dumping, and thus putting a previous employer of mine out of business. That's a pervasive rant though, so I'll stop here. :-)
Anyhow, in spite of its birthplace, C# and .Net will be the foundation for my next couple of personal projects, and possible for many more, until something better comes along. I really like what I've seen so far.
The lack of multiple inheritance bugs me, but it's less of a problem than I'd expected, and it also presents an interesting challenge.
Oh quit your bitching. Want to reuse the same few functions across a set of classes? That's what the clipboard is for. You know, copy and paste. Just paste that useful code into every class that needs it.
Want to change, extend, or trim back that code that cut-pasted code that should have been a base class? That's what search-and-replace is for. You've got a lovely IDE, learn to use it.
Me? Bitter?
Seriously though, I've been thinking about creating a language called D. D is a half-step above C#. D will look just like C#, but it will add a new keyword: derivesfrom. Then you can write code like this:
public class BaseClass
// you know
{
// implementation and stuff goes here
}
public class Widget derivesfrom BaseClass, OtherBaseClass : IWhatever, ISomethingElse
{
}
The D "compiler" will read such things and emit perfectly compilable C# code, sparing you the cut-paste madness known as "code reuse" in the C# world. The only question is whether D should be implemented as a perl script (because I have a sense of humor) or as a D application (because geeks (like me) are fond of self-reference).
As a friendly gesture to those who oppose MI, the D compiler will spit out an error message if you attempt to derive from two classes that share a common base class. This one pathological example seems to have scared the bejeezus out of language designers everywhere. Other abuses of MI might be handled with stern warnings.
I submitted the project to the good people at SourceForge a few minutes ago. In the meantime, contact me directly if you're interested in bringing D to fruition.
FWIW, C++ and other languages have long has this ability thanks to Doxygen and similar tools. It's cool stuff. Doxygen doesn't use XML, but the syntax is pretty straightforward.
It seems the lesson here is that proper captures from video RAM are slow. Yeah, it'd be nice to change that. But how many people really care? Given how long it took anyone to notice, I can't help but think that very very few people really care - and with good reason. Unless you're into making rendered movies, it's irrelevant.
I know nothing about full-size helis, but the PC simulators available for RC heli practice are spectacularly useful. I pity people who learn without them. It's possible of course, but simulators make it so much easier it's almost like cheating. Even all the way into complex aerobatics... I still practice stuff on the simulator all the time before I do it out at the field.
Most of the commercial RC heli simulators cost $200ish, but it's money well spent. That's the cost of a couple crashes with the model, and a sim will save you from way more than just two crashes. I highly recommend a sim to anyone getting into RC helis.
Flight times: They all get about 10-15 minutes on a tank of fuel, as the other fellow said. The control system battery needs to be recharged every 4-6 flights. Eletrics typically fly 4-6 minutes on a charge, but flight times and performance are getting better all the time for those things (I'm hoping to switch to electric when they can make good power for 10 minute flights, but it will probably be a couple years at least). Gasoline powered helis (only available in the larger size, around 12 pounds) run for 25-45 minutes on a tank of fuel, but they don't have quite the same power-to-weight ratio as alcohol burners. Alcohol helis are more popular for aerobatics. Gassers are popular for aerial photography because they have almost no exhaust trail, and for everyday flyers who aren't as concerned with aerobatics and who enjoy cheap fuel (alcohol is $12-25/gallon depending on various factors including the nitro content).
Cameras: I put a video camera and wireless video transmitter on a couple of mine, with the intention of recording aerobatics from the 'pilots' point of view. There are small cameras that work pretty well for this, the handling of the helicopter was unchanged. Unfortunately, the video range you get with FCC-license-free video transmitters is not very good. It works well for upright flight, but the signal drops out a lot during aerobatics.
Click here for one of my videos. I made this one to demonstrate the video drop-out problem, so it's pretty bad. I had a couple others that (by pure luck) had better reception, but unfortunately I don't have copies online on a server that can take a slashdotting.
I got a ham license a couple summers ago specifically so I could get some more powerful transmitters for wireless video, but I haven't upgraded the video transmitter yet. It's still something I want to do, though. I'll get around to it eventually.
I added a vertical stabilizer to my Roswell (Draganflyer = Roswell Flyer v2.0, same electronics on a more robust chassis). The fin did help keep it pointed forward, but then the problem is the pitch & roll response. It turns out that a platform with four flybarless rotors fly just as bad as a heli with a single flybarless rotor. It's really hard to describe, but if you've flown a flybarless heli, you know what I'm talking about.
These are OK for indoor flying where you never build up much speed, but beyond that they're a real handful.
Some friends and I put gyros on a flybarless heli once, just to see what would happen, and while they tame down the bad behaviors, they don't help nearly as much as a flybar. The Draganflyer (fak Roswell Flyer) feels about as bad as a flybarless heli, and probably for the same reasons (no flybar on the Roswell, just wacky rotor flapping due to disymmetry of list). I'd prefer a flybar-equipped rotor over flybarless any day, and the (flybarless) Roswell Flyer / Draganflyer is no exception.
In short, it seems you just haven't yet understood what the Draganflyer does.
Seems to me he knows exactly what the score is. I've flown one. Have you?
Piezo gyros are almost standard now for yaw stability on regular helis, but the ones now available for regular helis to better than the ones on the Draganflyer. Regular helis use a "flybar" in the rotor head that does the same thing the as the other two piezo elements on the Draganflyer - but, again, they do it better. The Draganflyer hovers with about the same difficulty as a regular heli - the feel isn't even much different - but once you get moving faster than a crawl, it becomes a real handful. Regular helis are actually much easier to control when flying with any speed. Regular RC helis also have aerobatic potential that fixed-pitch machines like the Draganflyer can't even come close to.
It's not a bad way to get the hand-eye coordination for hovering, but if (when) you want to get it flying around or get into aerobatics, you'll need something else entirely. And if you're looking for a way to get started with RC helis, a PC simulator is a much better investment.
I bought one in early 1999.
(I believe he complained again, and the name was changed yet again, but I'm not sure...)
I also strongly suspect that this person just slapped his/her forehead upon reading about the case in question. It was probably an innocent mistake by a person with a sense of humor and no idea that anyone outside their little comp-sci community would see it... Oooops. Don't you just hate it when pet project get out of control and take a life of their own?
One could argue that Mozilla now has a widely-understood meaning separate to Godzilla (especially considering that Microsoft sends a Mozilla string with every HTTP request), but it would take a lawyer to tell whether that's a meaningful defense. IANAL; I dunno.
I assuming that spammers will not take the trouble to figure out what email addresses are in my whitelist, nor would they take the trouble to send messages customized for each of their recipients. Technically possible, sure, but I figure that's an intractable problem, considering the sizes of the lists spammers use. First, finding a suitable 'from' address to use for each of a million customers would be tedious. Second, such addresses would be removed from the whitelist as soon as it became clear that a spammer was using it to get through the filter. Third, SMTP works well for mass mailings with a single 'from' address, but the bandwidth requirements go way up if you want a different 'from' address for each recipient.
There are potential problem with this approach, but none are nearly as big as the problem of widespread enhacment or duplication of the existing email infrastructure. I do agree that the ultimate solution is to augment or replace SMTP, but in the meantime, this works and it works very well.
Reneen Reneen Stoltegi
Then there's the fact that most spamming operations are one-time operations. The next time that spammer spams, it'll be a different product, and you didn't unsubscribe from THAT product's list. You'll have to unsubscribe again.
Then there's the fact that unsubscribing from opt-out lists one at a time - assuming that you've encountered the rare situation where the spammer actually honors the unsubscribe requests - does nothing to discourage spammers from sending more spam. Yanking their accounts causes them a bit of trouble, and often costs them a bit of money, since such cancellations do not include refunds. Keeping abuse departments busy makes ISPs less likely to take contracts from spammers.
But it's your mailbox, so go ahead and reply to the unsubscribe addresses. That action (read: confirming that your email address actually works) will get you a net increase in the amount of incoming spam. But, if it makes you feel better, who am I to advise against it?
If you want to do something, get the spammers' accounts terminated.
If you want to do something really useful, write your legislators. Ask for a junk email law modeled on the junk-fax law: No unsolicited contact without a pre-existing business relationship.
If you're just tired of the whole game, get a whitelist-based filter with automated confirmat. It will eliminate virtually all of your incoming spam. It works for me.
2a) if the 'from' address is in the whitelist, the message is delivered
2b) if the 'from' address is unknow, the message is MD5-hashed, copied to a holding pen, and then bounced with a note that says, in effect, "please confirm your email address by replying to this message with the subject line intact." The subject line of course contains the MD5 hash.
Meanwhile, if a message is received with an MD5 hash that matches something in the holding pen, the sender's address is added to the whitelist and the message in the holding pen is delivered.
This does eliminate spoofed spam, with no need to modify anyone else's email infrastructure - it's all done with procmail on my own server. I've received exactly two pieces of spam in the last six months. Both were from Nigerian bank scammers. Apparently they are the last spammers in the world to figure out forged from addresses. When they catch on, they'll disappear too.
I use this filter on email addresses that have been exposed to the public. Email to my 'private' addresses, which give only to trusted individuals, is delivered straight to my inbox.
Procmail recipies available here.