As many others have mentioned, the serial console is the way to go. Even if there's no DB9/DB25 serial port out the back, there's likely at least one serial port header on the motherboard. The header/pinout is generally standard, so go digging in that 'really old parts' box that we all have and see if you can dig up a DB9 port mounted on a plate to mount where a card would normally go. It will have a ribbon cable to attach it to the motherboard...
This issue has been argued to death, but I feel I need to step in here. If you change an object's api in a dynamic language such as Ruby, you should have a solid unit test suite that will catch all the breaks. Statically typed languages let you typecast things to no end, so really they can quickly identify some problems based on type/method signatures, but completely miss others.
Rails is _not_ a code generation framework. Note the period on that sentence.
Rails may provide the some simple scaffold generation, but that's only there if you _want_ to use it, and it happens to fit the way you'd like a particular part of your app to work. The code produced is concise, easy-to-follow, and thus easy-to-maintain.
For my own applications, I barely ever use scaffolding. It works well for simple admin screens where I just want 'something' that works for now, then will spend some effort on designing it a little better, later.
Rails is as maintainable as you make it. If you're a poor programmer, you're likely to write unmaintainable code, no matter what language or framework you have to help you. Rails helps point you in the right direction, but in the end, it's up to the _developer_ how maintainable his/her code is.
If you work around a problem, it hides from the user that the problem exists. The demand to have it fixed, therefore, dissipates and developers accept the onus to repeat work-arounds everytime they deploy something. Ultimately, the browser fails to improve, and the costs of errors are passed from the vendor (Microsoft) who never fixes the problem to the public (developers that waste time with work-arounds).
The problem with that is that most Joe Users out there will think that your website is the one crashing their computer, NOT IE. Most people will be complaining that your website is broken, and will not be complaining on any MS forums about how Internet Explorer is leaking memory...
Slashdot Mirror
As many others have mentioned, the serial console is the way to go. Even if there's no DB9/DB25 serial port out the back, there's likely at least one serial port header on the motherboard. The header/pinout is generally standard, so go digging in that 'really old parts' box that we all have and see if you can dig up a DB9 port mounted on a plate to mount where a card would normally go. It will have a ribbon cable to attach it to the motherboard...
This issue has been argued to death, but I feel I need to step in here. If you change an object's api in a dynamic language such as Ruby, you should have a solid unit test suite that will catch all the breaks. Statically typed languages let you typecast things to no end, so really they can quickly identify some problems based on type/method signatures, but completely miss others.
Rails is _not_ a code generation framework. Note the period on that sentence.
Rails may provide the some simple scaffold generation, but that's only there if you _want_ to use it, and it happens to fit the way you'd like a particular part of your app to work. The code produced is concise, easy-to-follow, and thus easy-to-maintain.
For my own applications, I barely ever use scaffolding. It works well for simple admin screens where I just want 'something' that works for now, then will spend some effort on designing it a little better, later.
Rails is as maintainable as you make it. If you're a poor programmer, you're likely to write unmaintainable code, no matter what language or framework you have to help you. Rails helps point you in the right direction, but in the end, it's up to the _developer_ how maintainable his/her code is.
If you work around a problem, it hides from the user that the problem exists. The demand to have it fixed, therefore, dissipates and developers accept the onus to repeat work-arounds everytime they deploy something. Ultimately, the browser fails to improve, and the costs of errors are passed from the vendor (Microsoft) who never fixes the problem to the public (developers that waste time with work-arounds).
The problem with that is that most Joe Users out there will think that your website is the one crashing their computer, NOT IE. Most people will be complaining that your website is broken, and will not be complaining on any MS forums about how Internet Explorer is leaking memory...