Yup, you're right. In Saudi Arabia for example, you have to have your "Iqama" (a.k.a residence permit) with you at all times. Failure to do so is an offence which can see you locked up in a local jail overnight until you get someone to produce your papers. If you want Arizona to be up there with K of SA, go right ahead.
Seriously, petrol heads in Saudi Arabia are going to be pissed off. These people buy Japanese cars manufactured in the US only because they make them bigger.
I want an eBook device that can read the eBooks I already bought and own.
They are in PDF and some on CHM format.
If I am going to spend $300 or more for an eBook device I might as well buy a Netbook that can use PDF and CHM formats for the same price.
That is if you are happy to read on a back-lit LCD screen. This is the main advantage of these devices.
I love my electronic ink reader. It's also got a Mobibook and PDF support, so I can read pretty much anything on it...
First of all, don't panic, you're not alone! I have done this a few times already. Here's my approach: 1. Identify "enduring business themes" in the code. This means basically a group of code that can be predictably tested by feeding certain input and expecting certain output. For example, you know that if you order two pens, a purchase order for two pens will come out the other end. 2. Once you establish a few of these scenarios you can write a few high-level unit tests. These will help you acertain whether or not this code works ok. 3. Once you have this, you're on your way to having test driven development in place. When any code changes have been done, quickly run your unit test to ensure results are still ok. If not, it means code change broke something (test driven quality assurance). 4. Now you can dig deeper and make more detailer fine grained unit tests.
Most times the best you'll be able to do is to lock in existing code base with a handful of solid high level unit tests and ensure that any new code is tested properly.
Slashdot Mirror
Yup, you're right. In Saudi Arabia for example, you have to have your "Iqama" (a.k.a residence permit) with you at all times. Failure to do so is an offence which can see you locked up in a local jail overnight until you get someone to produce your papers.
If you want Arizona to be up there with K of SA, go right ahead.
Seriously, petrol heads in Saudi Arabia are going to be pissed off.
These people buy Japanese cars manufactured in the US only because they make them bigger.
I want an eBook device that can read the eBooks I already bought and own.
They are in PDF and some on CHM format.
If I am going to spend $300 or more for an eBook device I might as well buy a Netbook that can use PDF and CHM formats for the same price.
That is if you are happy to read on a back-lit LCD screen. This is the main advantage of these devices. I love my electronic ink reader. It's also got a Mobibook and PDF support, so I can read pretty much anything on it ...
First of all, don't panic, you're not alone! I have done this a few times already. Here's my approach:
1. Identify "enduring business themes" in the code. This means basically a group of code that can be predictably tested by feeding certain input and expecting certain output. For example, you know that if you order two pens, a purchase order for two pens will come out the other end.
2. Once you establish a few of these scenarios you can write a few high-level unit tests. These will help you acertain whether or not this code works ok.
3. Once you have this, you're on your way to having test driven development in place. When any code changes have been done, quickly run your unit test to ensure results are still ok. If not, it means code change broke something (test driven quality assurance).
4. Now you can dig deeper and make more detailer fine grained unit tests.
Most times the best you'll be able to do is to lock in existing code base with a handful of solid high level unit tests and ensure that any new code is tested properly.