Re:Great now im going to lose my job
on
Flying By Brain
·
· Score: 4, Funny
Reminds me of a classic aviation joke one of my commerical pilot friends told me once:
Back in the day, a big plane took a crew of 5 - pilot, copilot, navigator, flight engineer, and radio operator.
Then radio technology improved, and they eliminated the radio operator, so it was down to 4.
Next to go was the navigator, as long range navigation beacons became prevalent. So we're down to 3 crew members.
And even those days are numbered - as planes have become more computerized, flight engineers have become unnecessary, and many newer planes don't require them. So in a lot of cases we're down to just 2 crew members, pilot and copilot.
My friend truly believes that the next step in aviation automation is to eliminate the copilot. Instead, the crew will consist of a pilot, and a dog. The pilot is there to feed the dog...
...and the dog is there to bite the pilot if he touches anything in the cockpit.;)
Unfortunately not:( I don't particularly want to live in Guildford. But I admire their work a lot, mostly because they've done a lot of things that I think should have been done a long time ago. And having worked in the space industry in the US I am very well aware of just how scared of SSTL some of the folks there are.
I'm as ticked off about the crap that Lockheed (and others) have failed on, but they're nowhere near being replaced in the next decade.
You may want to take a look at Surrey Satellite Technology Ltd before you make that assertion. SSTL has loads of experience, a knack for keeping costs low, and a reputation for innovation. They are already trying to move out of the pure smallsat market, and are also making a push into the US market.
The current incarnation of the NASA/AFRL sponsored University Nanosat competition, which recently completed its Critical Design Review, has 12 or 13 universities involved. This is the 3rd time around for the program. Previous incarnations produced satellites from Stanford, Arizona State, CU Boulder, and New Mexico State, and several other schools. Plus the Cubesat program is letting even high-schools get involved in building small but functional satellites.
Having said all that, what Lockheed really needs to look out for is Surrey Satellite Technology Ltd in the UK. They started as a university program about 20 years ago, but they're now a full-fledged company that is well-known for innovative designs and cost-cutting measures. They have launched about 25 satellites so far, have the contract for the Galileo constellation prototypes, and are pushing into the US market (they've already done several projects for the USAF). Definitely a company to keep an eye on.
Heh. I meant to include the line "we appear to be in violent agreement" to my last comment, but somehow forgot in my haste to submit. So, I agree that we agree.:)
Just as I didn't say "Don't compile/test periodically".
I agree that compile/test cycles help to break the problem down into manageable chunks. I'd go a step further and say that defining tests helps to focus a developer's thoughts on what solving that particular chunk of the problem involves.
Design is a hierarchical, fractal process: define problem at macro level (define preliminarysystem level tests - preliminary because they may change some by the time you're done), design at macro level, based on macro level design define at problem (s) at sublevel 1 (define tests at this level), design at sublevel 1,....
Whether you do this breadth first or depth first is a matter of taste, and may also depend on what type of problem you are dealing with at the macro level. And it's always an iterative process, traversing up and down the design hierarchy, because design is about learning the problem - otherwise it wouldn't be design it'd just be following a recipe to solve a known problem in a known way (which can work so long as you have correctly identified the problem in the first place).
If you're not compiling and testing, how are you figuring out what the code you're writing is meant to be doing?
That would be the part where you sit down and define the problem first, then create a design for a solution. Then you start coding. Note that I'm not saying that you shouldn't compile and test regularly. But you should be doing that to catch bugs incrementally, and to refine your design (and in some cases the definition of the problem). If you have no idea what the code is meant to be doing how can you write any code in the first place (or define tests for that matter)?
The point is not so much to write a heuristic reader (that's simply be asking for trouble and lawsuits over interpretations), as it is to have some standardized tags, symbols, or other machine-readable data that identifies particular pre-defined elements of a license agreement. A specific EULA would then be constructed by assembling the desired elements into a license. The robolawyer would simply read and interpret these predefined codes, and check to see whether or not the license matches your EULA acceptance criteria.
Note that this is exactly how the Creative Commons folks do things: here's a human readable version of a license, here's the equivalent legalese, and here's what the machine-readable version looks like:
I'm not sure if there is any "robolawyer" software out there designed to parse and pass judgement on the Creative Commons machine-readable format, but I can't imagine it'd be too hard to build one.
Part of the problem is that we're still somehow tied to the notion that domain names have anything at all to do with the content. Which, to me at least, seems silly in the age of Google. How many people actually type http://www.johnkerry2004.com (or whatever his website is) into the location bar of their browser? Most people who want to find a politician's website will just type the appropriate name into Google - which makes more sense, since it shouldn't matter where the info is, just what it is. Not surprisingly, a Google search for Van Hollen's name yields the congressman's website as the number one hit (and the news link at the top contains a WP story about the current website fiasco:)
Uh... what do you write if you don't have any requirements? There are always requirements - otherwise there'd be no need to write anything. It's just a question of how firm and formalized those requirements are. Writing tests first (i.e. writing some initial requirements) is a first pass at defining what the code to be written must do. Sure, you can just keep that idea of the purpose of the code in your head as some vague, amorphous concept. But it's better to write it down somewhere, since it helps clarify your thinking.
Actually, to give credit where credit is due, I believe that the map in question was produced by the DMSP, i.e. the Defense Meteorological Satellite Program. Hardly a NASA effort.
Well, let's see, javax.xml.parsers and the related packages that are part of the Java API for XML have been standard since Java 1.4. Meanwhile, javax.crypto (which includes a Message Authentication Code class that supports MD5 hashing) has also been standard since Java 1.4. Java 1.4 is the major release that preceded the one the current article is talking about, and has been out since around 2002.
So, were you trolling, or did you just not bother to keep up with Java?
You need a workable piece of software before you can expand into the unknown.
More importantly, you need an adequate definition of what constitutes "workable". That definition is the requirements.
I think that the mistake that people make is that they assume requirements should be set in stone. That's not necessarily true. Ok, admittedly it'd be nice. But realistically it never happens. Requirements do evolve during the design/development process. What the requirements provide is an instantaneous snapshot of what everyone agrees the system is supposed to do when it is finished - they are the agreed upon criteria for a successful system.
More importantly, write the tests FIRST. Then write the code, updating the tests for anything that is identified during the coding.
Which fundamentally boils down to "write the requirements first". After all, what are tests if not an expression of what the software must do (i.e. requirements), albeit precisely expressed in terms of executable code rather than vague natural language "shall" statements. The mantra of "writing tests first" is just a cunning way to get developers to actually think about requirements before they code, and better yet provides a framework for thinking about the problem that actually leads to useful requirements instead of useless "shall"s. Your comment about "updating the tests for anything that is identified during the coding" equates to the iteration of requirements that one expects in any good development process.
Note that I'm not saying that the "write the tests first" approach is bad. It just amuses me that people somehow see it as being different than the requirements first approach that has been preached for years. Although the fact that they do see it as different is eprhaps a good indication that the "requirements first" crowd did a very poor job of actually explaining how and why to write requirements.
Uh... a "drain on the earth's resources" how exactly? What is being "drained"?
...at the same time producing absolutely nothing to benefit society...
And of course everything that you do is a "benefit to society". Right. Since when did we mandate that every little thing that everyone does must provide some nebulous "benefit to society"? And what's the point of benefiting society if not to beneift the individuals that make up that society?
Part of the problem is that no one is really trained (or more correctly, educated) in how to develop requirements. Good requirements define a problem to be solved, rather than specifying a solution. Which makes sense, since adequately defining a problem is the first step towards solving it. But people son't want to think about the problme they are trying to solve, or spend time exploring the "problem space", they want to jump straight to a solution. Often their "definition" of the problem consists of a statement of the desired solution.
One approach to minimizing the tendency to state soltuions that I've seen promulgated in a few places is to tackle requirements definition from a different perspective. Rather than expressing requirements in terms of "things the system must do", write them in terms of "problem symptoms that must be suppressed" (i.e. "what do I want to chnage about the current system). This isn't a panacaea, but it does seem to help get people thinking in the right direction.
The fundamental problem, of course, is that problem-definition is just one component of the larger skill of problem-solving, which just doesn't seem to be taught at all any more. Most schools seem to focus on "training" and cookbook solutions (which is what most students seem to want too), rather than on "education" and problem-solving skills. It's particularly annoying that problem-solving skills aren't taught to management types, since (to me at least) a large portion of their job is supposed to about identifying problems (in resource allocation, scheduling, market strategy, inter-personal dynamics, etc), and solving those problems.
Excuse me, I meant to say "getting into interplanetary space" (must remember to preview:). India has, through ISRO, had an active space program for a long time.
And just to make things clear: my gripe is with the submitter of the article (and the way they portrayed the costs) not with the Indian lunar mission.
$88 milion isn't even that good. The highly successful Lunar Prospector mission (built by Lockheed Martin, run by NASA - neither well known for their ability to cut costs) cost around $60 million. And a good chunk of that was the launch vehicle. Surrey Satellites in the UK has designs for lunar missions that could cost in the low $20M's.
Don't get me wrong, I think it's great that India is getting into space. But to trumpet this as a "low cost" mission is disingenuous in the extreme, and ignores the hard work of folks like Surrey and AeroAstro to bring costs down to a reasonable level.
Not quite. The plot is that the arcade video games were intentionally placed on Earth, and being as a recruiting test by an unscrupulous "businessman" looking to make a quick buck by finding good Starfighters on Earth, even though Earth was (IIRC) by Star League rules not supposed to be interfered with. Still very geeky though - get a high score on the videogame, and you might just find yourself kidnapped to take part in a real live interstellar war...
Now, do you want a government with no stake in the elevator watchdogging the process, or one that does have a serious financial stake?
Stipulating that governments will be involved (although I'd prefer if they weren't), I'd much rather have a government that wasn't financially involved in the process. That way they'd be more like an impartial referee that makes sure "Things Are Done Right". Without a financial stake there'd be no incentive to cover up problems (don't tell me the government doesn't do that - I've worked in the space industry), and less likelihood that internal politicking aimed at steering all that pork^H^H^H^H uh... government money to someone's favorite state or company will take place. Not to say that there won't be political pressures - that's apparently inevitable whenever there're large sums of money involved. But at least keeping the government out of the financial side would reduce the political pressures some.
Slashdot Mirror
Unfortunately not :( I don't particularly want to live in Guildford. But I admire their work a lot, mostly because they've done a lot of things that I think should have been done a long time ago. And having worked in the space industry in the US I am very well aware of just how scared of SSTL some of the folks there are.
You may want to take a look at Surrey Satellite Technology Ltd before you make that assertion. SSTL has loads of experience, a knack for keeping costs low, and a reputation for innovation. They are already trying to move out of the pure smallsat market, and are also making a push into the US market.
Having said all that, what Lockheed really needs to look out for is Surrey Satellite Technology Ltd in the UK. They started as a university program about 20 years ago, but they're now a full-fledged company that is well-known for innovative designs and cost-cutting measures. They have launched about 25 satellites so far, have the contract for the Galileo constellation prototypes, and are pushing into the US market (they've already done several projects for the USAF). Definitely a company to keep an eye on.
Heh. I meant to include the line "we appear to be in violent agreement" to my last comment, but somehow forgot in my haste to submit. So, I agree that we agree. :)
Just as I didn't say "Don't compile/test periodically".
I agree that compile/test cycles help to break the problem down into manageable chunks. I'd go a step further and say that defining tests helps to focus a developer's thoughts on what solving that particular chunk of the problem involves.
Design is a hierarchical, fractal process: define problem at macro level (define preliminarysystem level tests - preliminary because they may change some by the time you're done), design at macro level, based on macro level design define at problem (s) at sublevel 1 (define tests at this level), design at sublevel 1, ....
Whether you do this breadth first or depth first is a matter of taste, and may also depend on what type of problem you are dealing with at the macro level. And it's always an iterative process, traversing up and down the design hierarchy, because design is about learning the problem - otherwise it wouldn't be design it'd just be following a recipe to solve a known problem in a known way (which can work so long as you have correctly identified the problem in the first place).
That would be the part where you sit down and define the problem first, then create a design for a solution. Then you start coding. Note that I'm not saying that you shouldn't compile and test regularly. But you should be doing that to catch bugs incrementally, and to refine your design (and in some cases the definition of the problem). If you have no idea what the code is meant to be doing how can you write any code in the first place (or define tests for that matter)?
Note that this is exactly how the Creative Commons folks do things: here's a human readable version of a license, here's the equivalent legalese, and here's what the machine-readable version looks like:
I'm not sure if there is any "robolawyer" software out there designed to parse and pass judgement on the Creative Commons machine-readable format, but I can't imagine it'd be too hard to build one.
Well yeah, except that MSNBC has a habit of carrying stories that aren't exactly pro-MS. I can't imagine we'll see that on proSCO.net.
Part of the problem is that we're still somehow tied to the notion that domain names have anything at all to do with the content. Which, to me at least, seems silly in the age of Google. How many people actually type http://www.johnkerry2004.com (or whatever his website is) into the location bar of their browser? Most people who want to find a politician's website will just type the appropriate name into Google - which makes more sense, since it shouldn't matter where the info is, just what it is. Not surprisingly, a Google search for Van Hollen's name yields the congressman's website as the number one hit (and the news link at the top contains a WP story about the current website fiasco :)
Uh... what do you write if you don't have any requirements? There are always requirements - otherwise there'd be no need to write anything. It's just a question of how firm and formalized those requirements are. Writing tests first (i.e. writing some initial requirements) is a first pass at defining what the code to be written must do. Sure, you can just keep that idea of the purpose of the code in your head as some vague, amorphous concept. But it's better to write it down somewhere, since it helps clarify your thinking.
Actually, to give credit where credit is due, I believe that the map in question was produced by the DMSP, i.e. the Defense Meteorological Satellite Program. Hardly a NASA effort.
So, were you trolling, or did you just not bother to keep up with Java?
More importantly, you need an adequate definition of what constitutes "workable". That definition is the requirements.
I think that the mistake that people make is that they assume requirements should be set in stone. That's not necessarily true. Ok, admittedly it'd be nice. But realistically it never happens. Requirements do evolve during the design/development process. What the requirements provide is an instantaneous snapshot of what everyone agrees the system is supposed to do when it is finished - they are the agreed upon criteria for a successful system.
Which fundamentally boils down to "write the requirements first". After all, what are tests if not an expression of what the software must do (i.e. requirements), albeit precisely expressed in terms of executable code rather than vague natural language "shall" statements. The mantra of "writing tests first" is just a cunning way to get developers to actually think about requirements before they code, and better yet provides a framework for thinking about the problem that actually leads to useful requirements instead of useless "shall"s. Your comment about "updating the tests for anything that is identified during the coding" equates to the iteration of requirements that one expects in any good development process.
Note that I'm not saying that the "write the tests first" approach is bad. It just amuses me that people somehow see it as being different than the requirements first approach that has been preached for years. Although the fact that they do see it as different is eprhaps a good indication that the "requirements first" crowd did a very poor job of actually explaining how and why to write requirements.
That seems a little hyperbolic. I'm not sure the US even has 7 carriers at sea at one time, let alone deciding to send all of them to Taiwan.
And of course everything that you do is a "benefit to society". Right. Since when did we mandate that every little thing that everyone does must provide some nebulous "benefit to society"? And what's the point of benefiting society if not to beneift the individuals that make up that society?
One approach to minimizing the tendency to state soltuions that I've seen promulgated in a few places is to tackle requirements definition from a different perspective. Rather than expressing requirements in terms of "things the system must do", write them in terms of "problem symptoms that must be suppressed" (i.e. "what do I want to chnage about the current system). This isn't a panacaea, but it does seem to help get people thinking in the right direction.
The fundamental problem, of course, is that problem-definition is just one component of the larger skill of problem-solving, which just doesn't seem to be taught at all any more. Most schools seem to focus on "training" and cookbook solutions (which is what most students seem to want too), rather than on "education" and problem-solving skills. It's particularly annoying that problem-solving skills aren't taught to management types, since (to me at least) a large portion of their job is supposed to about identifying problems (in resource allocation, scheduling, market strategy, inter-personal dynamics, etc), and solving those problems.
The Mountain Sun brewery in Boulder, CO makes an excellent "Java Porter" that is probably similar to the Red Hook/Starbucks brew you mentioned.
And just to make things clear: my gripe is with the submitter of the article (and the way they portrayed the costs) not with the Indian lunar mission.
Don't get me wrong, I think it's great that India is getting into space. But to trumpet this as a "low cost" mission is disingenuous in the extreme, and ignores the hard work of folks like Surrey and AeroAstro to bring costs down to a reasonable level.
It works fine for me... maybe the problem's at your end
Not quite. The plot is that the arcade video games were intentionally placed on Earth, and being as a recruiting test by an unscrupulous "businessman" looking to make a quick buck by finding good Starfighters on Earth, even though Earth was (IIRC) by Star League rules not supposed to be interfered with. Still very geeky though - get a high score on the videogame, and you might just find yourself kidnapped to take part in a real live interstellar war...
I think that you might have been right the first time. IIRC (and it's been a while) the maneuver was known as the "Death Blossom".
Stipulating that governments will be involved (although I'd prefer if they weren't), I'd much rather have a government that wasn't financially involved in the process. That way they'd be more like an impartial referee that makes sure "Things Are Done Right". Without a financial stake there'd be no incentive to cover up problems (don't tell me the government doesn't do that - I've worked in the space industry), and less likelihood that internal politicking aimed at steering all that pork^H^H^H^H uh... government money to someone's favorite state or company will take place. Not to say that there won't be political pressures - that's apparently inevitable whenever there're large sums of money involved. But at least keeping the government out of the financial side would reduce the political pressures some.