A few weeks ago, I received a shiny new iPad 2 as a gift. I promptly resolved to set my beloved Kindle aside for at least two full weeks and do all my reading on the iPad so I could get a solid feel for how it works as an ebook reader. In the following, keep in mind that if I say "iPad", I really mean "iPad 2" and likewise "Kindle" means "Kindle 2".
Physically, my iPad 2 is a fair bit bigger than my Kindle 2. It's big enough that you can't comfortably hold it one handed like you would a paperback. I end up wanting to prop it up somehow instead. I got a smart cover, and use that to prop it up. This works, but doesn't quite get to the optimum angle. The Kindle is just small enough that I can wield it one handed.
Page turns go much much faster on the iPad 2. They're quick and easy. This also means that shopping Amazon on the iPad is very comfortable. Buying books via the Kindle is kind of a last resort, but it's just fine on the iPad. The faster screen also makes it a lot easier to jump around to different locations in a book.
The iPad does beautifully on technical books that have code samples and diagrams that just don't fit on a kindle screen. The Kindle 2 is just not useful for programming books, but the iPad is great. The larger screen is really important - there's a reason they don't sell programming books in a mass-market paperback format.
Battery life is drastically different. If I get up in the morning and start reading, the iPad 2 will run down before the end of the day. When I first got it, my Kindle 2 would go several days in a row (even with wifi on) without running down. The battery on my Kindle is dying now, so it only lasts about 1 day with wifi on, but it's still longer than the iPad 2 with its brand new battery.
Finally, the iPad 2 tires my eyes out faster than reading on the Kindle. I'm not sure if it's the lower DPI screen or the backlit vs reflective nature of the screen, but I feel a little eye strain after reading for long periods. This never happens with the Kindle.
One thing that's really surprised me is that I haven't run into a situation where I couldn't read the iPad's display. This includes lying on a hammock in full sun on a hot summer day. The trick is that you angle the screen so that it's reflecting the darkest thing possible - a tree, a silhouette, etc. It's still fairly uncomfortable, though. You squint and strain a little bit. It's a lot better than my macbook pro with anti-glare screen, because I CAN read in the bright light. The kindle, on the other hand, takes bright light in stride and doesn't have any trouble.
At the other end of the spectrum, the backlit screen means that reading in a dark room or outdoors after dark is a breeze. No need for a book light. Both the Kindle app and iBooks allow you to adjust the brightness of the screen from right there in the app, which is very convenient. I find myself doing this continuously as ambient lighting conditions change.
Calibre integration on the iPad just isn't as good as it is with the Kindle. I use Calibre to manage my ebooks because the built-in tools suck (more on this in the future). Managing what books are on my Kindle is a simple process of plugging in the Kindle and starting Calibre. Doing the same with the iPad requires an intermediate step where you load the books into iTunes and then have iTunes sync with the iPad.
Reading on the Kindle is much more focused. I find myself flipping over to check my email, twitter and RSS feeds when I use the iPad. That's never an issue on Kindle. On the other hand, I haven't played any video games or watched Netflix on my Kindle. Surfing the web on the Kindle is an emergency-only option.
All in all, the Kindle is a better tool for reading fiction and other books that don't have a lot of graphics or code samples. The iPad is better for books with graphical needs. Like the iPhone, which is at best a mediocre phone, the iPad shines as a multi-function device while the Kindle is a better reading device.
This might seem like old hat to those of you who are consultants, but it was a big shift in my thinking.
I don't have a work laptop.
At about this time last year, I left the video game industry. For a lot of different reasons, the game industry is focused on MS products. Game developers work on Windows workstations, and when they start talking about databases they want to use MS SQL. I like having good tools, so I never wanted to buy a Windows laptop for personal use. For a while I kept a Mac or Linux desktop that would dual-boot into Windows for gaming, but it's been years since I rebooted for a game.
It was really awesome when I went to work for a true web company that did everything in the cloud. You could run everything you needed on a Macbook Pro. Work provided a great laptop. I could install the tools I liked. Life was good.
The only downside was my arms were getting longer from dragging around a nearly matched pair of 15" Macbook Pros. Eventually, I just set up a work development environment on my personal laptop and left the company laptop in the office.
Now that I'm at Moxiesoft, I don't even have a company laptop.
Here's my thinking:
- I will always want to have my own personal programming projects. This is essential for professional development, and I just like to program. I can't use the company laptop to work on them because (like every other company) I had to sign a work for hire agreement that says my employer owns anything I write on their time or using their equipment. I've got to use my own computer if I want to retain the rights to what I write in my spare time.
- I want to have a reasonably recent laptop. A 2-3 year upgrade cycle seems pretty reasonable these days, but Apple hardware is expensive. It's easier to justify upgrades if it's a computer for both personal and professional use. Plus, upgrading my personal laptop is my decision and doesn't require approval from above. If I hate my laptop, I can do something about it without begging for approval. Less stress for me, less stress for my boss. Everybody wins.
- I don't have to try talking my employer into buying licenses for expensive tools I've already bought for myself. I've got Photoshop, Office, OmniGraffle, Balsamiq and lots of other useful tools and I didn't have to beg for them.
- With only one laptop, I always have all my tools with me. I don't have to switch laptops if I need photoshop. I don't have to worry about whether my .emacs files are out of sync. Managing my dev environment is a lot simpler. I no longer feel "tool envy" when I'm on one laptop or another.
- As long as I have my laptop with me, I've got what I need to work on my own projects AND my work projects. I don't have to decide what I'm going to work on before I leave the house. Programming is programming. Again, everybody wins.
- Setting cool things up on two laptops was a pain - less of that friction means I'm spending more time doing things to make my life better. I'm happier and more productive both at work and at home. Everybody wins.
So I'm happier. Everything's happier, right? Well, there are a couple downsides.
- I left my backpack at a friend's house the other day and about had a panic attack. It had EVERYTHING in it. Work computer, personal computer, even my kindle. Having to wait a day would have been really really bad. I'm actually thinking about making some chef scripts that will build out a work dev environment on EC2 in case it (or hardware failure, which is more likely) happens again.
- At jobs past, I've been able to stay away from work in the evenings either by just not opening the work laptop or refusing to install invasive VPN software on my personal computer. One place actually had a VPN client that would audit all the other software installed on your computer and could do really nasty stuff to you. No way I was going to install that. Now there isn't much enforced separation. I close my tabs and windows, then run 'ssh_identity personal' to swap keys. So far, this hasn't been a problem.
- I'm going to wear out this laptop faster than I might otherwise. It's a unibody macbook pro, so I think that'll take a little while, but I do need to plan for replacing it every few years.
- Maintenance and upgrades are my responsibility. The flip side of not having to convince my boss to pay for things is that I have to pay for them.
I'm definitely happy with this arrangement. I think it's a big win for me, and a win for Moxiesoft. I doubt that it makes sense for everyone though. The whole thing is predicated on the notion that I'd be buying most if not all of this stuff for myself anyway, so asking my employer to buy me duplicates is just wasted spending.
This wouldn't work if I was some place that insisted on a development environment I didn't like - but why would I work somewhere like that?
Have you noticed that Rubygems.org has become a really nice cross-platform application distribution system? We think of Rails as a dev framework, but it ships with a command line app for bootstrapping a project. Capistrano is all about the command line app. Lunchy is new and cool.
Backup is the same way. It's a tool for backing up databases and directories, that happens to be written in ruby and distributed via Rubygems.org. It recently hit 3.0 and I figured it was a good choice for backing up my personal stuff.
First off, I was delighted to find the excellent documentation on how to set it up. The Getting Started doc was great for my photoblog (a PHP app), but I have a bunch of personal Rails apps and I wanted to take things a step further for them.
DRY up the config
The stock instructions have you duplicating your database credentials. You use the handy app to generate a config file with the options you want. Plug in some credentials and backups just work. You can even point it at S3 and save having to come up with a second server to send the backups to. This is really awesome, but the notion of having credentials in both my database.yml and another backup config file bothered me.
Further, because all backup jobs (or "triggers" in backup-speak) share the same DB credentials, you either have to have the same db username and password for backups on all your databases or you need a separate backup config file for each app.
So I'm doing something different. I've got a config/backup.rb in each Rails app. It looks something like this:
# # Backup # Generated Template # # For more information: # # View the Git repository at https://github.com/meskyanichi/backup # View the Wiki/Documentation at https://github.com/meskyanichi/backup/wiki # View the issue log at https://github.com/meskyanichi/backup/issues # # When you're finished configuring this configuration file, # you can run it from the command line by issuing the following command: # # $ backup -t my_backup [-c <path_to_configuration_file>] database_yml = File.expand_path('../config/database.yml', __FILE__) RAILS_ENV = ENV['RAILS_ENV'] || 'development' require 'yaml' config = YAML.load_file(database_yml) Backup::Model.new(:db_backup, 'Database Backup to S3') do database PostgreSQL do |db| db.name = config[RAILS_ENV]["database"] db.username = config[RAILS_ENV]["username"] db.password = config[RAILS_ENV]["password"] db.host = config[RAILS_ENV]["host"] db.port = config[RAILS_ENV]["port"] db.skip_tables =  end store_with S3 do |s3| s3.access_key_id = '<SECRET>' s3.secret_access_key = '<SECRET>' s3.region = 'us-east-1' s3.bucket = '<BUCKET NAME>' s3.path = config[RAILS_ENV]["database"] s3.keep = 10 end compress_with Gzip do |compression| compression.best = true compression.fast = false end end
Because there are so many options when building a backup config file (database, storage and sync engines, not to mention encryption, compression and notification) you'll want to make your own using the generator.
Since the backup config file is just a ruby script with a bit of a DSL, you can hook your database.yml and avoid having to repeat your credentials. I'm tempted to add an S3.yml and do the same with that. Notice that I can even automate what path to put the backup in - either naming it after the environment or (in this case) the database name.
Don't Make Me Remember The Command
When I think of backing up my rails app, I don't think of a command line with a bunch of options. I think of something like 'rake db:backup'.
I've created the backup-task gem to take care of that under Rails 3. It's really simple - it just adds the following task:
namespace :db do desc "Back up the database" task :backup do sh "backup perform --trigger db_backup --config_file config/backup.rb --data-path db --log-path log --tmp-path tmp" end end
This performs a backup of the 'db_backup' trigger, using the config/backup.rb file. It manually sets the data-path, log-path and tmp-path settings so that they'll all end up being relative to this Rails app. By default, they end up in standard locations that are either shared by all users on the system or all backups done by this user. Doing it this way avoids problems caused by having all my backups use the same trigger name.
The final step (after manually running it once or twice to make sure my config trickery works) is to set this up to run without having to think about it. A line like the following in your crontab will take care of that.
1 1 * * * bash -l -c "rvm use ruby-1.9.2-p0 && cd ~/sites/waiter && RAILS_ENV=production rake db:backup"
That was not especially obvious to me. I mean, the cron scheduling is easy, but there was some experimenting and googling to get the command line working with rvm. Explicitly calling bash and passing it the -l -c options did the trick.
This all rocks. It was really easy to set up, but there's still something missing. As things stand, it's entirely possible that my backups will crap out and I won't know. Maybe the notification options would handle that, but I'd kind of prefer something that watched my S3 bucket and complained at me if it didn't see a reasonably sized backup dated to some time in the last 24 hours. That'll have to be a future project.