Being a pilot, I am quite familiar with all of these systems. My concern is not about some hyperbolic remote control scenario but rather that the ability to paint targets on a traffic system is sufficient to greatly decrease the safety of a flight.
Your "at best" scenario is lacking in several ways. It assumes visual conditions and a target at sufficient distance to elicit communication as the first step. If my traffic system paints a target at my 12 o'clock and closing fast I will aviate before I communicate. This is true in any meteorological condition but doubly so in IMC.
High performance collision avoidance maneuvers greatly increase the risks associated with flight. We train for them but that does not make us immune to introducing high wing loads or overcontrolling in an emergency scenarioin the real world.
I really hope you are a developer. I make all of my money salvaging projects after they have been in the hands of people that do not understand the relationship between computer science and quality programming. And business is booming.
No. Web programming should be treated like all other programming, which means your abstraction layer should be properly encapsulated such that it is trivial to replace one implementation with another. If your current implementation of the abstraction layer does not support feature X, build it into the abstraction layer itself. At worst, you will have to find/replace calls to the function to add extra parameters to support the functionality where needed.
If you need to switch your DBMS from MySQL to Oracle, you just create a new implementation of the abstraction layer, from the stock version (yes you should start with a platform nonspecific version), and then add any Oracle specific stuff to the new implementation. The only caveat is that your stock abstraction layer have a standardized API that your client code can call.
The big problem with web programming is that developers are not following the basic tenets of computer science. They are writing tightly coupled code, instead of implementing basic programming paradigms (like OOP). This is not limited to database abstraction. You should always have your technologies properly separated, standards compliant (wherever possible), and your functionality encapsulated. If you do so, even a full platform switch is an achievable goal. And yes, my company spends 99% of their time implementing (and fixing other people's bad implementations) web based systems.
I run a small software company, and I require my people to sign a contract that is as strict, or stricter than this. I have developed techniques and skills that are the prime source of value in my industry, and must impart those skills to my employees. This transfer of knowledge gives my people every tool they need to go out and compete with me if they were free to do so. I have to make them sign such an agreement, or else I am simply paying my competitors for the pleasure of training them.
Of course, I also pay them well above industry standard, give them 10% profit on any idea that they bring to the table and we market (for seven years beyond their term of employment), and allow them to buy stock in the company. That seems an equitable trade to me. Now maybe I am the exception, but if I were presented with this contract I would simply ask my boss why they feel such clauses are necessary. Any good employer will explain the rationale to you. Odds are it has to do with protecting the investment they made in you.
But hey, You shouldn't believe a word I am saying... I am the evil boss who makes people sign "draconian" contracts for the sole purpose of keeping them down.
IATEBWMPSDCFTSPOKTD... That is proof I am a boss... no intelligent human being would even attempt that acronym:).
Slashdot Mirror
Being a pilot, I am quite familiar with all of these systems. My concern is not about some hyperbolic remote control scenario but rather that the ability to paint targets on a traffic system is sufficient to greatly decrease the safety of a flight. Your "at best" scenario is lacking in several ways. It assumes visual conditions and a target at sufficient distance to elicit communication as the first step. If my traffic system paints a target at my 12 o'clock and closing fast I will aviate before I communicate. This is true in any meteorological condition but doubly so in IMC. High performance collision avoidance maneuvers greatly increase the risks associated with flight. We train for them but that does not make us immune to introducing high wing loads or overcontrolling in an emergency scenarioin the real world.
Incorrect. ADS-B has two components, FIS-B for weather and TIS-B for traffic. If you spoof airplanes via ADS-B you can trigger the exact same kinds of collision avoidance alerts and pilot reactions as a spoofed TCAS. http://en.wikipedia.org/wiki/Automatic_dependent_surveillance-broadcast#Traffic_information_services-broadcast_.28TIS-B.29
I really hope you are a developer. I make all of my money salvaging projects after they have been in the hands of people that do not understand the relationship between computer science and quality programming. And business is booming.
No. Web programming should be treated like all other programming, which means your abstraction layer should be properly encapsulated such that it is trivial to replace one implementation with another. If your current implementation of the abstraction layer does not support feature X, build it into the abstraction layer itself. At worst, you will have to find/replace calls to the function to add extra parameters to support the functionality where needed.
If you need to switch your DBMS from MySQL to Oracle, you just create a new implementation of the abstraction layer, from the stock version (yes you should start with a platform nonspecific version), and then add any Oracle specific stuff to the new implementation. The only caveat is that your stock abstraction layer have a standardized API that your client code can call.
The big problem with web programming is that developers are not following the basic tenets of computer science. They are writing tightly coupled code, instead of implementing basic programming paradigms (like OOP). This is not limited to database abstraction. You should always have your technologies properly separated, standards compliant (wherever possible), and your functionality encapsulated. If you do so, even a full platform switch is an achievable goal. And yes, my company spends 99% of their time implementing (and fixing other people's bad implementations) web based systems.
I run a small software company, and I require my people to sign a contract that is as strict, or stricter than this. I have developed techniques and skills that are the prime source of value in my industry, and must impart those skills to my employees. This transfer of knowledge gives my people every tool they need to go out and compete with me if they were free to do so. I have to make them sign such an agreement, or else I am simply paying my competitors for the pleasure of training them.
:).
Of course, I also pay them well above industry standard, give them 10% profit on any idea that they bring to the table and we market (for seven years beyond their term of employment), and allow them to buy stock in the company. That seems an equitable trade to me. Now maybe I am the exception, but if I were presented with this contract I would simply ask my boss why they feel such clauses are necessary. Any good employer will explain the rationale to you. Odds are it has to do with protecting the investment they made in you.
But hey, You shouldn't believe a word I am saying... I am the evil boss who makes people sign "draconian" contracts for the sole purpose of keeping them down.
IATEBWMPSDCFTSPOKTD... That is proof I am a boss... no intelligent human being would even attempt that acronym