A statically typed language provides a little bit of value: The compiler does a small bit of the testing you should be doing anyhow. In return, static typing extract a huge cost in language complexity (templates, anyone?). Many of the patterns in the GOF book are only there to let you get the job done when the type checking system is trying to stop you.
This language may appeal to those who don't like C++ but think that the particulars of the language is the problem. It's not the particulars that are the problem. It's the static typing, the separate compile step, and all the complexity that supports these basic language decisions.
Re:Why reimplement Ruby?
on
RAD with Ruby
·
· Score: 3, Informative
That's a good summary of some of Ruby's shortcomings.
You can step through a string character by character, though. It's just not obvious how, and that's a bit of a flaw. There should probably be an obvious method like "each_char".
If you don't mind getting your characters as numeric codes, you can use String.each_byte. It's easy to turn each byte back into a character using Integer.chr:
"abc".each_byte do |b| puts b.chr end
Or use String.scan:
"abc".scan(/./) do |c| puts c end
Ruby being Ruby, there are probably another dozen ways to do it. And, for those who wish Ruby did have a String.each_char method, just add it:
class String def each_char scan(/./) do |c| yield(c) end end end
And now...
"abc".each_char do |c| puts c end
(Please excuse the lack of indenting./. and I can't seem to agree on how to make indenting work.)
I think I've got it right. I checked the Lisp code (my doc says I can Lisp, but dad says the other kids may make fun of me). I'd post the exerpt here, but/. thinks that Lisp is pretty lame. Look for method update-robot.
If a stone is hit, the speed vectors are devided by 2 (integer devision without fraction) as long as no stone is hit (which can result in a speed vector of (0, 0)). Hitting a stone is calulated by checking if one or more of the four corners of the robot lies within a stone. Moving to coordinates = the size of the map counts as a hit.
That made me scratch my head, too. Here's what I think they mean:
Calculate vector
While position + vector is inside a stone or out of bounds, divide the vector (both x and y parts) by 2, discarding any remainder
position = position + vector.
Essentially, hitting something causes your ship to slow down as much as it takes to keep from hitting it, even to the point of stopping completely. Assuming my interpretation is correct.
I could check the reference implementation, but my doctor says I've got to lay off of the Java.
Russia wants in not because Mother Earth will weep if they don't sign, but because the treaty allows countries to sell their carbon credits for cash, and they stand to make a bundle.
Russia being Russia, my bet is that they will both sell their carbon credits and use them.
It's a bad idea to have the people directly elect the president. The electoral college was designed the thwart democracy. Think I'm a nut case? So were the founding fathers. Check out this little piece that Hamilton wrote in the Federalist papers:
Hamilton makes it clear that the electoral college was designed to prevent just the sort of elections we have today:
The choice of SEVERAL, to form an intermediate body of electors, will be much less apt to convulse the community with any extraordinary or violent movements, than the choice of ONE who was himself to be the final object of the public wishes. And as the electors, chosen in each State, are to assemble and vote in the State in which they are chosen, this detached and divided situation will expose them much less to heats and ferments, which might be communicated from them to the people, than if they were all to be convened at one time, in one place.
Unfortunately, the founding fathers did not foresee either the ffects of political parties upon the electoral collage, or of states passing laws binding the electors to vote a certain way.
Democracy is bad. Republic is good. Restore the great republic and liberty may reign again. We don't need to change the constitution nearly as much as we need to follow it.
Re:It's easier to test for incompetency
on
IT Literacy Test
·
· Score: 1
Sure. We're not pedantic.
Re:It's easier to test for incompetency
on
IT Literacy Test
·
· Score: 1
You can have the programmer job (although it's for a company that was long ago assimilated, so you'll need to do some time travel). We will ask you why you prefer != to <, though. You don't have to have the same answer as we'd have; we just prefer (well, preferred) that you had a reason. We like programmers who think about what why they do things a certain way.
You can't have the EE job, though. E=IR, I=E/R, and R=E/I are all acceptable answers.
Anyone who rolls their eyes because the questions are too easy gets extra credit.
It's easier to test for incompetency
on
IT Literacy Test
·
· Score: 4, Interesting
It's easier to test for incompetency than for competency.
A company I worked for got so many liars applying for jobs that we made these rediculous little tests to give people. Here's a sample question from our C test:
Write a loop that executes its body 10 times.
Or for electrical engineers:
What is the equation for Ohm's law?
I thought these tests were a waste of time. I think I said something like, "If someone is breathing they'll pass it." Then I saw how many people who claimed "expert" on their resume failed the liar's test. Weeding out the liars left us with a much smaller pool of candidates.
I'd much rather my tax dollars were spent with Burt Rutan and Scaled Composites...
I'd rather my tax dollars weren't spent except where absolutely necessary (say, for defense). Everything else, leave to industry. A free market economy can make far better decisions about how to spend money than can politicans.
"How should the government spend my money" is the wrong question. How little of my money can we get away with the government getting is the right question.
This is an automated version of an idea that's been around awhile. When I was doing a computer installation for a water plant in Yuma, Arizona, maybe 8 years ago, I saw a fish tank in the control room. They fed a continuous supply of the plant's water through that tank. If the fish started acting funny or floated upside down, they would know to issue an alert and start testing water quality right now. It wasn't a substitute for laboratory testing of the water, but an adjunct to it. You can only do lab tests every so often, but fish are testing the water all the time.
Even if they won't detect everything, fish are cheap, and that's important to the smaller water plants. Besides, the fish give the plant operator something to look at in between doing preventative maintenance and studying for the certification. Running a water plant is boring.
Admittedly, this is slightly (only slightly) off topic, but how does one do that with the ssh tunnel, so you can go back in from outside the computer that started the ssh session?
Here's one way. I'll ssh from mercury to ceres so that ceres can ssh back to mercury.
First ssh from mercury to ceres:
wconrad@mercury:~$ ssh -R 5555:127.0.0.1:22 ceres Linux ceres 2.4.20-1-k6 #1 Sat Mar 22 14:38:19 EST 2003 i586 GNU/Linux
Last login: Sat May 8 08:11:00 2004 from mercury.galaxy wconrad@ceres:~$
The "-R 5555:127.0.0.1:22" switch means, "on the remote end (ceres), please make port 5555 connect to 127.0.0.1 (mercury), port 22 (ssh)."
Now, on ceres:
wconrad@ceres:~$ ssh -p 5555 127.0.0.1 Password: Linux mercury 2.4.23-1-k7 #1 Mon Dec 1 00:05:09 EST 2003 i686 GNU/Linux
Last login: Sat May 8 08:11:47 2004 from localhost wconrad@mercury:~$
This says to ssh to port 5555 on ceres, which is really the ssh tunnel established by the ssh we did into ceres from mercury.
Faceit, it's very easy to end up working a 14 hour day when you spent 4 hours of that day chasing each other with Nerf guns or taking 2 hour lunches.
Indeed. And conversely: It's very easy to spend 4 hours of the day chasing each other with Nerf guns or taking 2 hour lunches when you're working 14 hour days.
When workdays get longer, so do breaks, and people still need to do their chores: Get the car worked on, go to the bank, pick up the dry cleaning, and whatnot. And they do, only it's now a protracted interruption in their 14 hour day rather than something they do after work.
A disciplined worker's focused 8 hours can best the productivity of the tired, frazzled worker working 14 hours, but nobody wants their manager to not see them pulling with the team. It takes a strong manager and a disciplined worker to keep the work day from consuming one's life.
In Ruby, is there an analagous operation? How do you use it?
I don't remember seeing the transfer-of-ownership idiom used in Ruby. We make an object to handle a resource, and then just let everyone who needs the resource have a reference to the object. Garbage collection takes care of the rest (I suppose the garbage collector owns the resource; everyone else is just leasing it). That solves a big OO problem: Keeping track of who owns what. It gives us a different problem, which is losing control of when an object deallocates its resource, but that problems rears its head less often than the ownership problem so it seems to be a good tradeoff.
GC takes over memory management, but leaves the other scarce resources -- file descriptors, sockets, mutexes, database connections -- to be managed manually, as in C.
Ruby has an interesting approach using closures to handle manual resource allocation. One calls the function that allocates a resource, passing it a closure. The function allocates the resource, calls the closure, and then deallocates the resource (even if an exception occurs). Here's how you might write to a file the manual way (I apologize for the lousy formatting; I don't know how to trick/. into indenting):
file = File.new("foo") file.puts "My mistress's eyes are nothing like the sun" file.close
That's the usual way, easy to get wrong: What if an exception occurs? What if I forget to call close? Here's the better way, calling File.open and passing it a closure:
File.open("foo") do |file| file.puts "My mistress's eyes are nothing like the sun" end
File.open might use this common idiom:
def File.open(filename) file = File.open(filename) begin yield(file) ensure file.close end end
The "yield" calls the closure that was passed in, passing it the file object. The "begin...ensure" is like Java's "try...finally" construct, used here to make sure that the file gets closed whether the closure terminates normally or raises an exception.
This idiom doesn't solve all manual resource allocation/cleanup problems, but it's a pretty way to solve some of them.
I don't think Ruby invented this idiom, but I don't know where it came from. Perhaps Lisp: Everything seems to have come from Lisp.
When I started my current job, my boss gave me his box and built himself a much faster one:) I put up with the fans in his old box for only a day before I decided I had to do something. I moved the box into the server room and brought in my laptop to use as a terminal. No more fan noise!
Pretty quickly I discovered that if I run all of my terminals in a screen session, I had much better control of them than if I ran separate xterms. You can only fit so many xterms on an X screen before you have to start using virtual screens, but you can easily fit dozens of terms into a screen session (I recompiled screen so I can have a hundred: I ran into the Debian version's maximum of 40 a few times). The best thing is, I can switch between them without using the goshdarned mouse. By giving them names, I can call them up with just a few keystrokes. Oh, it's nice. No more hunting. I want the screen I'm using to tail the apache log? It's ctrl-A ' log and I'm there.
When I go home at the end of the day, I just disconnect my screen session. When I ssh in from home to do some work, or when I come in the next day, I just run "screen -r" and I'm back where I left off. Exactly where I left off. No time wasted starting up xterms and getting them moved around. The log term is still tailing the log, the edit term is still in emacs, the test term is still waiting for me to run the tests again.
When I ssh into the noisy workstation, I use -X so I can run X applications if I want to... now and then the Gimp or feh or gv or some other GUIish thing, but running lots of terms in a screen session does lend itself to text mode applications. My email program is Pine, all text driven, and I like it just fine. Emacs in text mode, of course (no button bars for me!): Usually an emacs for each active project. When I switch from one task to another, I don't have to do anything but switch to the right screen session and start typing.
Text-mode programs and screen are all I need to rule the world (or at least the part of it that sits on my workstation).
How long until a virtual terrorist hijacks the uplink and "lands" this automated plane in a building?
I'll bet that nobody thought of that. We know that aviation people just don't give a darn for safety. And people just don't worry about protecting themselves from terrible things that have already happened.
There's probably not a pilot on the plane who can take over any time he wants.
The whole system is probably connected to the internet, too.
Heck, the uplink is probably unencrypted tones on a CB channel that any kid could generate by whistling into his walkie talkie.
In other words, the problem is not having a concrete set of requirements to begin with.
It's worse than that. The problem is that, for all but the most trivial of problems, you can't have a concrete set of requirements.
If you could have a concrete set of requirements that would unambiguously result in code that met the customer's needs, then you could automate the process of turning the requirements into code. In other words, the requirements would be code.
As much as management would love to be able to automate the process of turning requirments into code, they can't. Nor can they even create a process that someone can follow to turn requirements into code (if you could, you could automate following the process and not need the programmer).
The bottom line is, you can't ever have a complete set of requirements. The best thing to do is to get over it and not work under fictional processes that assume you can ("If only we could get the requirements frozen, then we could ship on time"). Requirements change because writing code teaches the programmers and the business that the requirements were unimplementable in the time required, or that they don't actually meet the needs of the business. That's ok. It better be, because that's reality.
Why shouldn't someone make a style guide for everyone? Because Unix doesn't work that way. Let me explain.
The Unix culture loves standards. Standards are yummy. Unix eats standards for between-meal snacks. But what the Unix culture abhores is standards created from whole cloth and handed down from on high.
Why? Is it just because we're just cranky? Well, we can be cranky, but it's not just that.
It's because standards created from whole cloth and handed down from on high are invariably awful. When someone sits down to write a standard, they have the luxury of ignoring vast tracts of difficult territory, of hand-waving away little details like implementation.
That's why the Unix culture prefers its standards to evolve from existing, successful practice. That's why successful RFC's don't create a standard out of nothing, but rather codify something that's already been done. They turn research into production, but the research has to be there first. It has to be something that people see is good, something that with a few tweaks could be a good standard for wider use.
If Unix were to somehow get a unified style guide, it would happen because one of the many excellent existing styles gained the acceptance of the community in general. Then and only then would that style guide be turned into a standard.
I'm trying to compare these to the other types of batteries I might want to use on my next electric RC plane.
A Farad is is when a coulomb of charge causes a potential difference of 1V.
A coulomb is 1 Amp-second.
So 450 Farads is 450 Amp-seconds @ 1V, which is 450 W-seconds, which is 125 mAh.
Have I got that right? If so gives these batteries, which weigh 60g, a density of 2 Wh/kg, which doesn't make them that good for RC planes. Lithium ion's density is 150-200 Wh/kg; NiHM's density is 60 Wh/kg.
1. Ground power. The airplane can plug into ground power when it's on the ramp to avoid drawing on the storage batteries when neither the APU nor the engines are generating electricity.
2. Storage batteries. For emergencies and for use during preflight until the APU gets going.
3. APU. A small turbine that drives a generator to provide electricity during preflight or in emergencies. Can also provides bleed air for starting engines.
4. Generators or alternators driven off of the engines. There is a gearbox attached to the engine that takes power off of the shaft and delivers it to things like generators and hydraulic pumps.
Their article hadn't shown up yet when I posted. I thought I had FP for sure. Oh well. Sometimes you're the fly, sometimes you're the windshield. Go ahead and mark me redundant.
I don't trust the CDs for sale in the stores, after
all, who regulates that industry and ensures there actually is a
message on them, and if so, what is the message?
Slashdot Mirror
Yet another statically typed language?
A statically typed language provides a little bit of value: The compiler does a small bit of the testing you should be doing anyhow. In return, static typing extract a huge cost in language complexity (templates, anyone?). Many of the patterns in the GOF book are only there to let you get the job done when the type checking system is trying to stop you.
This language may appeal to those who don't like C++ but think that the particulars of the language is the problem. It's not the particulars that are the problem. It's the static typing, the separate compile step, and all the complexity that supports these basic language decisions.
That's a good summary of some of Ruby's shortcomings.
You can step through a string character by character, though. It's just not obvious how, and that's a bit of a flaw. There should probably be an obvious method like "each_char".
If you don't mind getting your characters as numeric codes, you can use String.each_byte. It's easy to turn each byte back into a character using Integer.chr:
Or use String.scan:
Ruby being Ruby, there are probably another dozen ways to do it. And, for those who wish Ruby did have a String.each_char method, just add it:
And now...
(Please excuse the lack of indenting. /. and I can't seem to agree on how to make indenting work.)
I think I've got it right. I checked the Lisp code (my doc says I can Lisp, but dad says the other kids may make fun of me). I'd post the exerpt here, but /. thinks that Lisp is pretty lame. Look for method update-robot.
That made me scratch my head, too. Here's what I think they mean:
Essentially, hitting something causes your ship to slow down as much as it takes to keep from hitting it, even to the point of stopping completely. Assuming my interpretation is correct.
I could check the reference implementation, but my doctor says I've got to lay off of the Java.
Russia wants in not because Mother Earth will weep if they don't sign, but because the treaty allows countries to sell their carbon credits for cash, and they stand to make a bundle.
Russia being Russia, my bet is that they will both sell their carbon credits and use them.
It's a bad idea to have the people directly elect the president. The electoral college was designed the thwart democracy. Think I'm a nut case? So were the founding fathers. Check out this little piece that Hamilton wrote in the Federalist papers:
The Federalist Papers : No. 68, The Mode of Electing the President
Hamilton makes it clear that the electoral college was designed to prevent just the sort of elections we have today:
Unfortunately, the founding fathers did not foresee either the ffects of political parties upon the electoral collage, or of states passing laws binding the electors to vote a certain way.
Democracy is bad. Republic is good. Restore the great republic and liberty may reign again. We don't need to change the constitution nearly as much as we need to follow it.
Sure. We're not pedantic.
You can have the programmer job (although it's for a company that was long ago assimilated, so you'll need to do some time travel). We will ask you why you prefer != to <, though. You don't have to have the same answer as we'd have; we just prefer (well, preferred) that you had a reason. We like programmers who think about what why they do things a certain way.
You can't have the EE job, though. E=IR, I=E/R, and R=E/I are all acceptable answers.
Anyone who rolls their eyes because the questions are too easy gets extra credit.
It's easier to test for incompetency than for competency.
A company I worked for got so many liars applying for jobs that we made these rediculous little tests to give people. Here's a sample question from our C test:
Or for electrical engineers:
I thought these tests were a waste of time. I think I said something like, "If someone is breathing they'll pass it." Then I saw how many people who claimed "expert" on their resume failed the liar's test. Weeding out the liars left us with a much smaller pool of candidates.
I'd rather my tax dollars weren't spent except where absolutely necessary (say, for defense). Everything else, leave to industry. A free market economy can make far better decisions about how to spend money than can politicans.
"How should the government spend my money" is the wrong question. How little of my money can we get away with the government getting is the right question.
This is an automated version of an idea that's been around awhile. When I was doing a computer installation for a water plant in Yuma, Arizona, maybe 8 years ago, I saw a fish tank in the control room. They fed a continuous supply of the plant's water through that tank. If the fish started acting funny or floated upside down, they would know to issue an alert and start testing water quality right now. It wasn't a substitute for laboratory testing of the water, but an adjunct to it. You can only do lab tests every so often, but fish are testing the water all the time.
Even if they won't detect everything, fish are cheap, and that's important to the smaller water plants. Besides, the fish give the plant operator something to look at in between doing preventative maintenance and studying for the certification. Running a water plant is boring.
Admittedly, this is slightly (only slightly) off topic, but how does one do that with the ssh tunnel, so you can go back in from outside the computer that started the ssh session?
Here's one way. I'll ssh from mercury to ceres so that ceres can ssh back to mercury.
First ssh from mercury to ceres:
The "-R 5555:127.0.0.1:22" switch means, "on the remote end (ceres), please make port 5555 connect to 127.0.0.1 (mercury), port 22 (ssh)."
Now, on ceres:
This says to ssh to port 5555 on ceres, which is really the ssh tunnel established by the ssh we did into ceres from mercury.
SSH tunneling is a many-splendered thing.
Faceit, it's very easy to end up working a 14 hour day when you spent 4 hours of that day chasing each other with Nerf guns or taking 2 hour lunches.
Indeed. And conversely: It's very easy to spend 4 hours of the day chasing each other with Nerf guns or taking 2 hour lunches when you're working 14 hour days.
When workdays get longer, so do breaks, and people still need to do their chores: Get the car worked on, go to the bank, pick up the dry cleaning, and whatnot. And they do, only it's now a protracted interruption in their 14 hour day rather than something they do after work.
A disciplined worker's focused 8 hours can best the productivity of the tired, frazzled worker working 14 hours, but nobody wants their manager to not see them pulling with the team. It takes a strong manager and a disciplined worker to keep the work day from consuming one's life.
In Ruby, is there an analagous operation? How do you use it?
I don't remember seeing the transfer-of-ownership idiom used in Ruby. We make an object to handle a resource, and then just let everyone who needs the resource have a reference to the object. Garbage collection takes care of the rest (I suppose the garbage collector owns the resource; everyone else is just leasing it). That solves a big OO problem: Keeping track of who owns what. It gives us a different problem, which is losing control of when an object deallocates its resource, but that problems rears its head less often than the ownership problem so it seems to be a good tradeoff.
GC takes over memory management, but leaves the other scarce resources -- file descriptors, sockets, mutexes, database connections -- to be managed manually, as in C.
Ruby has an interesting approach using closures to handle manual resource allocation. One calls the function that allocates a resource, passing it a closure. The function allocates the resource, calls the closure, and then deallocates the resource (even if an exception occurs). Here's how you might write to a file the manual way (I apologize for the lousy formatting; I don't know how to trick /. into indenting):
That's the usual way, easy to get wrong: What if an exception occurs? What if I forget to call close? Here's the better way, calling File.open and passing it a closure:
File.open might use this common idiom:
The "yield" calls the closure that was passed in, passing it the file object. The "begin...ensure" is like Java's "try...finally" construct, used here to make sure that the file gets closed whether the closure terminates normally or raises an exception.
This idiom doesn't solve all manual resource allocation/cleanup problems, but it's a pretty way to solve some of them.
I don't think Ruby invented this idiom, but I don't know where it came from. Perhaps Lisp: Everything seems to have come from Lisp.
When I started my current job, my boss gave me his box and built himself a much faster one :) I put up with the fans in his old box for only a day before I decided I had to do something. I moved the box into the server room and brought in my laptop to use as a terminal. No more fan noise!
Pretty quickly I discovered that if I run all of my terminals in a screen session, I had much better control of them than if I ran separate xterms. You can only fit so many xterms on an X screen before you have to start using virtual screens, but you can easily fit dozens of terms into a screen session (I recompiled screen so I can have a hundred: I ran into the Debian version's maximum of 40 a few times). The best thing is, I can switch between them without using the goshdarned mouse. By giving them names, I can call them up with just a few keystrokes. Oh, it's nice. No more hunting. I want the screen I'm using to tail the apache log? It's ctrl-A ' log and I'm there.
When I go home at the end of the day, I just disconnect my screen session. When I ssh in from home to do some work, or when I come in the next day, I just run "screen -r" and I'm back where I left off. Exactly where I left off. No time wasted starting up xterms and getting them moved around. The log term is still tailing the log, the edit term is still in emacs, the test term is still waiting for me to run the tests again.
When I ssh into the noisy workstation, I use -X so I can run X applications if I want to... now and then the Gimp or feh or gv or some other GUIish thing, but running lots of terms in a screen session does lend itself to text mode applications. My email program is Pine, all text driven, and I like it just fine. Emacs in text mode, of course (no button bars for me!): Usually an emacs for each active project. When I switch from one task to another, I don't have to do anything but switch to the right screen session and start typing.
Text-mode programs and screen are all I need to rule the world (or at least the part of it that sits on my workstation).
A chiropractor which who I'm assuming you saw is the best person to ask
Or you could see a real physician. Be sceptical of chiropractic care. It's flimflammery.
For more comments, see this article from the 11th.
How long until a virtual terrorist hijacks the uplink and "lands" this automated plane in a building?
I'll bet that nobody thought of that. We know that aviation people just don't give a darn for safety. And people just don't worry about protecting themselves from terrible things that have already happened.
There's probably not a pilot on the plane who can take over any time he wants.
The whole system is probably connected to the internet, too.
Heck, the uplink is probably unencrypted tones on a CB channel that any kid could generate by whistling into his walkie talkie.
Yes, we should be scared.
In other words, the problem is not having a concrete set of requirements to begin with.
It's worse than that. The problem is that, for all but the most trivial of problems, you can't have a concrete set of requirements.
If you could have a concrete set of requirements that would unambiguously result in code that met the customer's needs, then you could automate the process of turning the requirements into code. In other words, the requirements would be code.
As much as management would love to be able to automate the process of turning requirments into code, they can't. Nor can they even create a process that someone can follow to turn requirements into code (if you could, you could automate following the process and not need the programmer).
The bottom line is, you can't ever have a complete set of requirements. The best thing to do is to get over it and not work under fictional processes that assume you can ("If only we could get the requirements frozen, then we could ship on time"). Requirements change because writing code teaches the programmers and the business that the requirements were unimplementable in the time required, or that they don't actually meet the needs of the business. That's ok. It better be, because that's reality.
Why shouldn't someone make a style guide for everyone? Because Unix doesn't work that way. Let me explain.
The Unix culture loves standards. Standards are yummy. Unix eats standards for between-meal snacks. But what the Unix culture abhores is standards created from whole cloth and handed down from on high.
Why? Is it just because we're just cranky? Well, we can be cranky, but it's not just that.
It's because standards created from whole cloth and handed down from on high are invariably awful. When someone sits down to write a standard, they have the luxury of ignoring vast tracts of difficult territory, of hand-waving away little details like implementation.
That's why the Unix culture prefers its standards to evolve from existing, successful practice. That's why successful RFC's don't create a standard out of nothing, but rather codify something that's already been done. They turn research into production, but the research has to be there first. It has to be something that people see is good, something that with a few tweaks could be a good standard for wider use.
If Unix were to somehow get a unified style guide, it would happen because one of the many excellent existing styles gained the acceptance of the community in general. Then and only then would that style guide be turned into a standard.
I'm trying to compare these to the other types of batteries I might want to use on my next electric RC plane.
A Farad is is when a coulomb of charge causes a potential difference of 1V.
A coulomb is 1 Amp-second.
So 450 Farads is 450 Amp-seconds @ 1V,
which is 450 W-seconds, which is 125 mAh.
Have I got that right? If so gives these batteries, which weigh 60g, a density of 2 Wh/kg, which doesn't make them that good for RC planes. Lithium ion's density is 150-200 Wh/kg; NiHM's density is 60 Wh/kg.
1. Ground power. The airplane can plug into ground power when it's on the ramp to avoid drawing on the storage batteries when neither the APU nor the engines are generating electricity.
2. Storage batteries. For emergencies and for use during preflight until the APU gets going.
3. APU. A small turbine that drives a generator to provide electricity during preflight or in emergencies. Can also provides bleed air for starting engines.
4. Generators or alternators driven off of the engines. There is a gearbox attached to the engine that takes power off of the shaft and delivers it to things like generators and hydraulic pumps.
Their article hadn't shown up yet when I posted. I thought I had FP for sure. Oh well. Sometimes you're the fly, sometimes you're the windshield. Go ahead and mark me redundant.
You have nothing to worry about, because subliminal advertising is not effective.