After about three years of waiting for Amazon to polish up their Kindle e-book reader I finally decided to drop some money and buy one. I bought the 3G + WiFi Kindle and received it at the beginning of this month shortly after they went on sale. Now, let me first say that I have used Amazon for purchasing for years – I use them so much that being an Amazon Prime member actually pays off for me – so I figured the quality of the Kindle experience would be amazing. After ordering it at the beginning of August my gut feeling started to tell me it may have been a bad idea.
I put in an order for the Kindle at the beginning of August because I knew it was going to be a hot product. I purchased the two year extended warranty from one of the third-parties that issues them (off Amazon’s website) and, at first, I purchased a case that did not contain the built-in book light.
Every couple of days I was checking on the delivery estimate for the Kindle, which originally was for the end of August, and finally they completely removed the actual date estimate from the page all together. At this point I called Amazon customer service, and they assured me that it would arrived no later than the middle of September, but that was the best estimate that they could give at the time. After receiving the Kindle UPS decided to continually deny my request to leave the Kindle’s case at my apartment door because it “required a signature.” Due to this, the Kindle’s case got sent back to Amazon and I was refunded – after using the Kindle I decided to spend a little more money to get the case with the reading light.
I received the case a few days later and noticed that the bottom hook was not stitched completely straight, therefore the Kindle did not seat perfectly vertical, but I tried to push it around and it seemed quite stable so I did not think anything of it. This morning I open up the Kindle to read on my morning commute and it is frozen at the screen saver, refusing to manually restart (or even hard reset), thus leaving me with a brick. A few minutes later while on my way to the train station my trusty Amazon branded case decides to let my Kindle slide on out and hit the ground. At this point I was livid.
Luckily there is nothing more than a few cosmetic bumps and scratches on the device, but I decided then and there that I (a) wanted a new case and (b) wanted an answer to why my Kindle was freezing. I searched a few pages on the Internet and found that, apparently, the Kindle freezing is a more common occurrence and Amazon is addressing it with a firmware update. While browsing my Kindle’s page on Amazon’s site I found that despite the fact that I paid for my two year warranty, it was not being shown on the “My Kindle” page.
I brought the case issue to the attention of Amazon and they are now rush shipping me a replacement case. I decided to wait on the warranty issue as well as the actual device issue because I read several places that merely plugging the device into a computer should solve the freezing problem. It is now about an hour and a half since I plugged my Kindle into my Mac, and it is still sitting there, frozen and unusable.
At this point I am debating on why I should not just send this device back to Amazon and wait another year for them to “perfect” the reading experience. I would go to a competitor, but unfortunately, they in a much more shitty situation than Amazon. So my advice to all of you book loving people out there drooling over the Kindle – wait another year, maybe they’ll take the boat loads of money they are making and actually put some of it towards fixing the bugs.
For the past couple of months I have been running Mac OS X Snow Leopard (10.6) on my custom built desktop. I recently purchased a brand new MacBook Pro for use as a portable computer. All the while I have not been using Apple’s automatic backup daemon, Time Machine, and basically relying on the RAID drives on my desktop for keeping all of my data safe and secure. The desktop has been having some RAID troubles that I have not been able to diagnose yet and that got me to thinking: I should really spend some time and get this backup thing working.
I have had a NAS appliance, the D-Link DNS 323, lying around now for a couple of months collecting dust. There are many tutorials on the Internet that make this process much harder than it actually is, attempt to explain what might go wrong and finally offer no real explanation about why it is going wrong. Now, the very first thing to remember is to run this command as your user privileges. Inside of the Terminal application, execute the following command and restart your Mac.
defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1
What you need to do now is create a special disc image called a sparsebundle, which ideally, should be twice the size of the hard-drive that you are looking to backup. Unfortunately I do not have enough disk space available on my network for this.
First let’s go over Mac OS X Snow Leopard, where the filename of the sparsebundle needs to merely be the hostname.sparsebundle. A special XML file needs to be saved into the root directory of the sparsebundle package. If you are using Mac OS X Leopard (10.5) then the name of the image file needs to include the MAC address of the en0 ethernet interface. This is in a hexadecimal format. You can run the following commands to build the filename. The second command gets the username of the system. The format of the sparsebundle should be hostname_macaddress.sparsebundle.
ifconfig en0 | grep ether | cut -d' ' -f 2 | tr -d ':' hostname -s
The following command creates the sparsebundle package. You can create any size that you wish. Remember the last argument of the command needs to be the proper filename depending on which version of OS X you have (see above). The first command is for Leopard and the second for Snow Leopard.
hdiutil create -size 200g -fs HFS+J -volname "Backup of xavior" xavior_58b035fdf8f3.sparsebundle hdiutil create -size 200g -fs HFS+J -volname "Backup of xavior" xavior.sparsebundle
This step only needs to be done for Snow Leopard. You need to run the first command to get the UUID, and place it inside of the XML file. You should save the XML file in the root directory of the sparse bundle as the following xavior.sparsebundle/com.apple.TimeMachine.MachineID.plist.
ioreg -rd1 -c IOPlatformExpertDevice | awk '/IOPlatformUUID/ { split($0, line, "\""); printf("%s\n", line[4]); }'Now place the string inside of the XML file and save it accordingly.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.backupd.HostUUID</key> <string>UUID_STRING</string> </dict> </plist>
Finally, mount the location via Samba (or any other network protocol) and copy the file over into the mounted folder. Inside of Time Machine select the mount point as the disk and let er rip.
Mount selection for Time Machine
For awhile now my pet project has been running on top of the “noSQL” document database technology, MongoDB, that the folks over at 10Gen have developed. After testing the tech and going to a couple of the New York City meetups, I immediately decided to push myself to utilize this in Type Aloud. But, along with the Rails 3.0 release and Mongoid 2 (the Active Record wrapper that I am using for Mongo) I have had a hard time finding accurate up-to-date information on some less used features. One particular problem has been referencial (foreign) associations and the use of composite keys.
Because the user’s poems and stories in Type Aloud and only unique on the user level I have been unable to use a simple uniqueness validation on the document identifier which up until this point was just the default hash provided by the database. I need the composite, the user identifier and the story identifier, to be unique; I only want the user to only have one story named “Winnie the Pooh.” It may be easier to understand some code.
A standard Story model in Rails (using Mongoid) might look something like this. Notice how I do not need to explicitly provide the key because it is assumed, by default, we will use the database standard hash provided as our primary key for the document. As you see I explicitly specify the slug field as being an index as this is what will most commonly be queried. In this case, the “id” field may contain something along the lines of 4c897698cd44a10f8b000006.
class Story include Mongoid::Document include Mongoid::Timestamps include Mongoid::Paranoia include Mongoid::Versioning # Document fields field :title, :type => String field :slug, :type => String field :description, :type => String field :disabled, :type => Boolean, :default => true # Document associations embeds_many :chapters referenced_in :user # Document indicies and keys index :slug, :background => true, :unique => false # Document validators validates_presence_of :title, :description end
The problem here, and the exact reason why I merely cannot validate uniqueness on the title, is because multiple users can have the same title for a story or poem. The submissions will be presented in a vanity URL format, e.g. http://typealoud.com/johnbellone/the-darwin-prospect/chapter/1, and thus will almost always be queried with the user’s name. My solution to making this unique is quite simple. So now the story identifier will be in the format of the-darwin-prospect-4c892963cd44a108a2000008 where that hash at the end is the user’s identifier.
class Story include Mongoid::Document include Mongoid::Timestamps include Mongoid::Paranoia include Mongoid::Versioning # Document fields field :title, :type => String field :slug, :type => String field :description, :type => String field :disabled, :type => Boolean, :default => true # Document associations embeds_many :chapters referenced_in :user # Document indicies and keys key :title, :user_id # Document validators validates_presence_of :title, :description end
This works as expected and I no longer get duplicate documents. The only issue that I am having right now is Mongoid does not seem to be correctly throwing for a second save which seemingly just creates another version with a timestamp in the future. Merely adding an explicit validator does not seem to help either. Other than that this solution seems to be up to snuff, but as always, I am sure there may be a more elegant way to handle this. Any thoughts?