All electronic devices, with few exceptions, decrease in value over time. With Apple products, this is notoriously accelerated because Apple tends to release products on a yearly basis across most of their product line. Take for example iPhone and the five releases thus far from 2007 to 2011.
Model | Release Date |
iPhone |
June 2007 |
iPhone 3G |
June 2008 |
iPhone 3GS |
June 2009 |
iPhone 4 |
June 2010 |
iPhone 4S |
Sept 2011 |
Apple traditionally upgrades the specifications of their products while keeping the pricing the same. So a new iMac 27" may still be $1699, however this year's model has a much more powerful video card and larger capacity hard drive. Apple rarely, only once that I can recall, adjusts their price prior to a new model announcement -- and when they did this, with the original iPhone, it created an uproar in complaints from early adopters despite the price being reduced.
Since Apple normally doesn't adjust the price on their products and is almost guaranteed to have a new model 12 months later, one could argue you get the best bang for the buck buying the product as soon as it's released. Buying it 6 months later or near the next release sets one up to either delay the purchase again for the next release while at the same time remorse the previous purchase under the pressure of desiring the latest innovation. It is true there are times where one doesn't want the new one because it is not incrementally more valuable to justify. I for example didn't move up to the iPhone 4S having the iPhone 4. Yes, I desire Siri, but I decided to hold off. In doing so, I went ahead and purchased the Apple care warranty and guess what? Since i purchased it on launch day, my warranty expired roughly around the time as the iPhone 4S ( arrived and the extended warranty will cover me through a whole year until the next model arrives. The warranty purchase couldn't have been more efficiently calculated -- and it was only possible because I purchased as soon as the product was released.
In summary, you'll get the best bang for the buck and the best options when buying right away. |
|
90bb5a6e-ba3d-4dbf-9e6c-4400e357c395|0|.0
When deleting a file using FileInfo.Delete() method, the .NET framework sometimes throws an exception as shown below:

Yet, when you delete the file manually through explorer its removed fine from the filesystem. At first I though this was a glitch of some type because the program runs with my login credentials much like the local logged in user credentials applies to windows explorer. It turns out if the file is marked as ReadOnly it also throws this exception. Changing the attributes prior to deleting will automatically resolve this problem.
An additional note, since this program was working with a directory where files were continually being created and removed, there was an additional observation with the File.CreationTime. In very few cases when iterating through the files in the directory, the CreationTime would show a date time value of 1/1/1600 despite the file already existing. I attribute this to simply a race condition where the FileInfo.CreationTime of my program gets to the file just before the actual creation date of the file is set by the operating system. This would need to be validated as I would expect the creation time of the file to be set in an atomic way along with the file creation. |
|
29616cd8-90c8-481a-a18d-3f7adad7044d|0|.0