Whole-heartily agree... Even back during the first space shuttle disasters the jokes were circulating all the local Florida schools the SAME day. I still remember around 10 of them.
The jokes, while tasteless, were still funny. The thing is when I remember one of those jokes, it immediately gives way to pause as I reflect back to that day, looking up and seeing the orange flash on my way to school. That moment wasn't funny to anyone, and it will forever be burned into my history.
I know you often hear more complaints than compliments so I just want to say thanks!!!.
The whole staff is doing a bang up job and if I could buy you all a round I would.
I'm there as well, with Doors, Epic TeamCenter and a hodgepodge of 'homebrew' tools. Do yourself a favor and do a serious evaluation of Seapines suite. Their Surround SCM is a great repository that has a lot of more modern features. The defect tracking tool is very easy to modify to suit my needs at past employers. And now I hear they have a fairly decent requirements management tool.
I can't speak for the requirements tool, but the others integrate with each other VERY well. All their products has web based versions, and all there products cost about 1/10th of Rationals.
I'm currently, slowly, trying to push my current employer over on the software side of the house and see if it doesn't work it's way up.
No matter what you do, do and extremely DETAILED evaluation of the combination you want. Once your decide on a toolset you likely locked in for a long time due to corporate politics.
Just a heads up, the registration site won't send you an email if your running Firefox 3.x. I tried all morning waiting for my serial number. After getting anxious, I logged into my VmWare account using IE, and clicked resend key. This time, I actually got the email.
I too work in embedded systems, more specifically aircraft controls. In most of our design documents we tend to keep the design to the interface level of each software component (CSC), and the interaction between them. Drawing this is usually down using more simple drawing elements than that of UML. Draw a couple of boxes to show your major components, and label the interfaces of those. In subsequent sections, show only one of the components at a time, with a drawing of its sub-components if applicable. Only go about 3 levels deep if at all possible here. The attention span of most reviews will get lost after that. Besides, your requirements already specify WHAT has to happen, your only job here is to specify WHERE those requirements happen.
While UML is nice, I have found that most of the reviewers of these types of documents are not UML savvy. The one drawing mechanism of UML that I do find invaluable in this line of work is the sequence diagrams. Large amounts of requirements can often be shown more precisely by a sequence diagram, detailing the interactions between a handful of component interfaces at a time.
I've been through it as well, and I can tell you the most painless solution is to choose a standard software development process, like IEEE 12207. A lot of companies are using the IEEE as of the last 10 years or so. We adopteded it about 5 years back, and it's actually quite nice, and completly tailorable per project.
But no matter which process you use, I HIGHLY recommend that you invenst in tools that will help you follow the process. One such tool is Seapines TestTrack which we've also been using for the past 3 years. You can make it follow your process, and it tracks all the artifacts for you. You can even tie into source control, and have it handle that process as well.
also, the JSF project is 100% C++. Even had Bjarne help establish the guidelines. I myself am starting a safety-critical train control project, in C++.
1) A lot of clients in the embedded aviation world that still use C, like to follow SaferC and MISRA guidlines. SaferC basically says, dynamic memory allocation can be bad, but not using it when needed is worse. The point was that a lot of modern algorithms and designs rely on dynamic allocation. If this applies to you, then you will have more problems as a result of trying to fit them into a static allocation methodology than you would of had by using dynamic memory in the first place.
2) Lockheed Martin is using C++ for all the code on JSF (F-35). Not C, not JOVIAL, not Ada. All embedded flight software will be coded in C++. Granted, they contracted Bjourne Stroustrup to define a subset of C++ that was considered safe for safety-critical systems. And yes, dynamic allocation is in the subset:)
You know, I'd hope by know that game makers (or console makers) would fix some of the most annoying parts playing a console first person shooter. We don't all use the controller the same, so why the heck only provide one configuration for the controller. I would think the very first, most basic thing to do when creating a game, is add the ability to configure the controller.
There are numerous console games, Batman Begins and Prince of Persia WW, that have zero controller configuration.
For that reason, I hope Microsoft has done their homework, and provide a transparent means of configuring the controller. Maybe a simple utility from the dashboard that lets the user reassign the "default" keys, possibly even storing person configurations, so that I can switch when I want. Or, maybe require that all games provide controller configuration in order to sport the XBOX360 logo?
Sad to say, but the examples you cited weren't lives lost in the pursuit of knowledge.
So if their lives were not lost in the pursuit of knowledge, then how would you like them to be remembered?
They were lives lost to managerial short-sightedness and corner-cutting.
It's stupid thinking like that, that leads us nowhere. Sh*t happens, especially dealing with something as complicated as space exploration.
I'd wager that if we persued every possible avenue, and every possible outcome, and didn't cut a single corner anywhere, that we wouldn't have layed a foot on the moon yet! We'd still be debating it.
Space exporation is very risky, and every single person who has put their lives on the line to pursue the dreams of Human Kind... They are nothing short of Hero's.
There has to be some level of acceptable risk, in the hardware, software, and by God yes the management.
It sure seems easy for you to point fingers when risky things go bad, and you don't have any real clue do you. Go back to the basement, your grounded.
While I agree with most of your arguement, you fail to miss one certain aspect of corporate life within NASA. Every single meeting at NASA dealing with a mission launch is recorded, either via meeting minutes or audio recording. There isn't a single engineer that will give a thumbs up to any launch without expressing at least one concern.
This leads to a very bad situation, where the bosses have to filter out what they think is legit, and what they think the engineers are just saying to covers there arses.
Every single shuttle flight in the history of the program probably had a handfull of engineers saying they should abort.
NASA really needs to step back, realize what they are doing is dangerous, and accept some risk. To do that, they also have to stand behind the engineers such that they aren't always trying to cover their arse and only feel the need to speak up during real concerns.
Don't immediately jump to blaming upper management, unless you've experienced the NASA lifestyle.
I think your missing the point slightly. It is not so much that the library would be used to detect hits, and under which conditions; that is and should be still up to the developer.
The real use is to releive the developer from the HOW to process the hit. The developer could simply code that object X collided with Y with this component vector, and I want this type of reaction.
My company just is now switching back to Delphi for our tools development, after a year or so stint of using C#. I personally love C#, but I've been using Delphi since version 1, on Win 3.11.
Just for kicks, I compiled our latest C# development project, weighing in at less that 10K lines. 30 seconds on my 750MHz. Our last Delphi project, about 70K lines, build in 3 seconds.
Microsofts C# is over an order of magnitude slower. Between that, and the relatively lacking availability of components for.net, it was an easy decision for us to switch back.
Possibly, but work is underway to create a dual-mode, and even tri-mode hypersonic engine. The dual-mode will be a scramjet/solid-fuel engine already under development by the air-force. The during scramjet operation the cowl flaps are open to mix oxygen with cracked JP7, then ignited. Once your far enough out, the cowl flap will close and the engine, or engine bypass, will be used as a solid fuel booster.
The weight of a scramjet engine is much greater than the weight of the oxygen that would normally have to be caried.
The tri-mode engine, still under "consideration", would be to take a standard jet turbine, and surround it on the outside (bypass) with the scramjet.
You obviously have not been paying attention to NASA history, nor ever witnessed a NASA meeting.
NASA DOES listen to it's engineers, and that is their biggest issue IMHO. Sitting in on a NASA project teaches you one thing, and one thing only. Cry wolf, and cry often. Not one single NASA engineer will tell you that something is a "go". Why? To cover their butts.
NASA has lost its original policy, that space is research, and research can be risky. So much so that they encourage its engineers to point out every possible issue. Now, take 1,000 engineers, each of which is saying "I don't know, lets recheck to make sure" and try to filter out what is a legitimate concern, and what is just noise.
Every time something at NASA goes wrong, there is an Engineer who says "I warned you that this might happen!".
NASA is way to focused on perfection, that the engineers all feel required to cover their asses. They should just stand up and say "Hey, this space sh*t is dangerous. Sometimes bads things happen, and when they do we will try to learn from it. But our primary focus is research, and there is a level of risk we are willing to take."
The whole facility is likely to be up to the challange. I got a tour of the facility from the director of the project 3 days before it first when online. The idea from the beginning was to be able to support a 50% increase in G5's. So unless each Xserve uses 50% more power and creates 50% more heat there isn't a problem.
Whoops... The software we used back then was Toast 1.0 for Macintosh.
It only burned at 1X. You could only burn a directory that was completly defragmented. The coaster rate was about 60% or higher, and the blanks were $30 a peice.
Slashdot Mirror
Whole-heartily agree... Even back during the first space shuttle disasters the jokes were circulating all the local Florida schools the SAME day. I still remember around 10 of them.
The jokes, while tasteless, were still funny. The thing is when I remember one of those jokes, it immediately gives way to pause as I reflect back to that day, looking up and seeing the orange flash on my way to school. That moment wasn't funny to anyone, and it will forever be burned into my history.
I know you often hear more complaints than compliments so I just want to say thanks!!!. The whole staff is doing a bang up job and if I could buy you all a round I would.
Except this is Commerical Access To Space, so shouldn't it be CATS?
I for one am all for exporting CATS into space.
I'm there as well, with Doors, Epic TeamCenter and a hodgepodge of 'homebrew' tools. Do yourself a favor and do a serious evaluation of Seapines suite. Their Surround SCM is a great repository that has a lot of more modern features. The defect tracking tool is very easy to modify to suit my needs at past employers. And now I hear they have a fairly decent requirements management tool.
I can't speak for the requirements tool, but the others integrate with each other VERY well. All their products has web based versions, and all there products cost about 1/10th of Rationals.
I'm currently, slowly, trying to push my current employer over on the software side of the house and see if it doesn't work it's way up.
No matter what you do, do and extremely DETAILED evaluation of the combination you want. Once your decide on a toolset you likely locked in for a long time due to corporate politics.
I also noted that the number is a palindrome, reads the same forwards and backwords. Pretty cool eh!
But most likely just a pattern of nothingness.
Sounds like it would make a great game too... Maybe we could call it Boulder Dash?
Just a heads up, the registration site won't send you an email if your running Firefox 3.x. I tried all morning waiting for my serial number. After getting anxious, I logged into my VmWare account using IE, and clicked resend key. This time, I actually got the email.
Lame :(
Are you saying Microsoft can't get much better than CowboyNeal?
They ARE doomed.
I too work in embedded systems, more specifically aircraft controls. In most of our design documents we tend to keep the design to the interface level of each software component (CSC), and the interaction between them. Drawing this is usually down using more simple drawing elements than that of UML. Draw a couple of boxes to show your major components, and label the interfaces of those. In subsequent sections, show only one of the components at a time, with a drawing of its sub-components if applicable. Only go about 3 levels deep if at all possible here. The attention span of most reviews will get lost after that. Besides, your requirements already specify WHAT has to happen, your only job here is to specify WHERE those requirements happen.
While UML is nice, I have found that most of the reviewers of these types of documents are not UML savvy. The one drawing mechanism of UML that I do find invaluable in this line of work is the sequence diagrams. Large amounts of requirements can often be shown more precisely by a sequence diagram, detailing the interactions between a handful of component interfaces at a time.
I've been through it as well, and I can tell you the most painless solution is to choose a standard software development process, like IEEE 12207. A lot of companies are using the IEEE as of the last 10 years or so. We adopteded it about 5 years back, and it's actually quite nice, and completly tailorable per project.
But no matter which process you use, I HIGHLY recommend that you invenst in tools that will help you follow the process. One such tool is Seapines TestTrack which we've also been using for the past 3 years. You can make it follow your process, and it tracks all the artifacts for you. You can even tie into source control, and have it handle that process as well.
also, the JSF project is 100% C++. Even had Bjarne help establish the guidelines. I myself am starting a safety-critical train control project, in C++.
2 Points:
:)
1) A lot of clients in the embedded aviation world that still use C, like to follow SaferC and MISRA guidlines. SaferC basically says, dynamic memory allocation can be bad, but not using it when needed is worse. The point was that a lot of modern algorithms and designs rely on dynamic allocation. If this applies to you, then you will have more problems as a result of trying to fit them into a static allocation methodology than you would of had by using dynamic memory in the first place.
2) Lockheed Martin is using C++ for all the code on JSF (F-35). Not C, not JOVIAL, not Ada. All embedded flight software will be coded in C++. Granted, they contracted Bjourne Stroustrup to define a subset of C++ that was considered safe for safety-critical systems. And yes, dynamic allocation is in the subset
You know, I'd hope by know that game makers (or console makers) would fix some of the most annoying parts playing a console first person shooter. We don't all use the controller the same, so why the heck only provide one configuration for the controller. I would think the very first, most basic thing to do when creating a game, is add the ability to configure the controller.
There are numerous console games, Batman Begins and Prince of Persia WW, that have zero controller configuration.
For that reason, I hope Microsoft has done their homework, and provide a transparent means of configuring the controller. Maybe a simple utility from the dashboard that lets the user reassign the "default" keys, possibly even storing person configurations, so that I can switch when I want. Or, maybe require that all games provide controller configuration in order to sport the XBOX360 logo?
Try Finale at http://www.finalemusic.com/ from Code software.
It will let you enter music note by note, or from a midi keyboard. Best of all, it will let you import sheet music with your scanner, very slick.
I know that at my local college I can pick up the student edition for next to nothing.
Sad to say, but the examples you cited weren't lives lost in the pursuit of knowledge.
So if their lives were not lost in the pursuit of knowledge, then how would you like them to be remembered?
They were lives lost to managerial short-sightedness and corner-cutting.
It's stupid thinking like that, that leads us nowhere. Sh*t happens, especially dealing with something as complicated as space exploration.
I'd wager that if we persued every possible avenue, and every possible outcome, and didn't cut a single corner anywhere, that we wouldn't have layed a foot on the moon yet! We'd still be debating it.
Space exporation is very risky, and every single person who has put their lives on the line to pursue the dreams of Human Kind... They are nothing short of Hero's.
There has to be some level of acceptable risk, in the hardware, software, and by God yes the management.
It sure seems easy for you to point fingers when risky things go bad, and you don't have any real clue do you. Go back to the basement, your grounded.
While I agree with most of your arguement, you fail to miss one certain aspect of corporate life within NASA. Every single meeting at NASA dealing with a mission launch is recorded, either via meeting minutes or audio recording. There isn't a single engineer that will give a thumbs up to any launch without expressing at least one concern.
This leads to a very bad situation, where the bosses have to filter out what they think is legit, and what they think the engineers are just saying to covers there arses.
Every single shuttle flight in the history of the program probably had a handfull of engineers saying they should abort.
NASA really needs to step back, realize what they are doing is dangerous, and accept some risk. To do that, they also have to stand behind the engineers such that they aren't always trying to cover their arse and only feel the need to speak up during real concerns.
Don't immediately jump to blaming upper management, unless you've experienced the NASA lifestyle.
>A person breaks the law and you offer kudos?
Got to give her something to eat in the slammer.
I think your missing the point slightly. It is not so much that the library would be used to detect hits, and under which conditions; that is and should be still up to the developer.
The real use is to releive the developer from the HOW to process the hit. The developer could simply code that object X collided with Y with this component vector, and I want this type of reaction.
That is the physics part, the reaction.
My company just is now switching back to Delphi for our tools development, after a year or so stint of using C#. I personally love C#, but I've been using Delphi since version 1, on Win 3.11.
.net, it was an easy decision for us to switch back.
Just for kicks, I compiled our latest C# development project, weighing in at less that 10K lines. 30 seconds on my 750MHz. Our last Delphi project, about 70K lines, build in 3 seconds.
Microsofts C# is over an order of magnitude slower. Between that, and the relatively lacking availability of components for
Actually, your not quite correct. Your example is of a system that is safety-critical.
Safety-critical systems mean potential loss of life.
Mission-critical systems mean loss of mission, not loss of life.
The space shuttle bay door not opening is a mission-critical failure. The space shuttle flying itself into the Gulf is a safety-critical failure.
"I'll dig up the listening test article later"
Translation:
I want to get some karma, and later I want to get some more.
Possibly, but work is underway to create a dual-mode, and even tri-mode hypersonic engine. The dual-mode will be a scramjet/solid-fuel engine already under development by the air-force. The during scramjet operation the cowl flaps are open to mix oxygen with cracked JP7, then ignited. Once your far enough out, the cowl flap will close and the engine, or engine bypass, will be used as a solid fuel booster.
The weight of a scramjet engine is much greater than the weight of the oxygen that would normally have to be caried.
The tri-mode engine, still under "consideration", would be to take a standard jet turbine, and surround it on the outside (bypass) with the scramjet.
You obviously have not been paying attention to NASA history, nor ever witnessed a NASA meeting.
NASA DOES listen to it's engineers, and that is their biggest issue IMHO. Sitting in on a NASA project teaches you one thing, and one thing only. Cry wolf, and cry often. Not one single NASA engineer will tell you that something is a "go". Why? To cover their butts.
NASA has lost its original policy, that space is research, and research can be risky. So much so that they encourage its engineers to point out every possible issue. Now, take 1,000 engineers, each of which is saying "I don't know, lets recheck to make sure" and try to filter out what is a legitimate concern, and what is just noise.
Every time something at NASA goes wrong, there is an Engineer who says "I warned you that this might happen!".
NASA is way to focused on perfection, that the engineers all feel required to cover their asses. They should just stand up and say "Hey, this space sh*t is dangerous. Sometimes bads things happen, and when they do we will try to learn from it. But our primary focus is research, and there is a level of risk we are willing to take."
The whole facility is likely to be up to the challange. I got a tour of the facility from the director of the project 3 days before it first when online. The idea from the beginning was to be able to support a 50% increase in G5's. So unless each Xserve uses 50% more power and creates 50% more heat there isn't a problem.
Whoops... The software we used back then was Toast 1.0 for Macintosh.
It only burned at 1X. You could only burn a directory that was completly defragmented. The coaster rate was about 60% or higher, and the blanks were $30 a peice.