Entry Archives
Introducing node-xml2object
Recently, I’ve been playing around with node.js, because, well, it’s really, really cool. I found myself wanting to parse XML into a Javascript object, but I couldn’t find any existing modules that did what I needed. So, I went ahead and made my own, node-xml2object. It’s dead simple to use, and I hope others find it as useful as I have. For example, imagine you have some XML like this:
<root>
<videos total="2">
<video id="1" length="20">
<title>Video 1</title>
</video>
<video>
<title>Video 2</title>
</video>
</videos>
</root>
Here’s how you would access it as an object, assuming the XML is stored in the variable xml:
var sys = require('sys'),
xml2object = require('./xml2object');
var response = xml2object.parseString(xml);
response.addCallback(function(obj) {
// To output a simple value, just use as an object
// Since there are 2 video elements under <videos>, it's stored as an array
sys.puts(obj.root.videos.video[1].title) // outputs "Video 2"
// attr(key) returns the value for attribute with name "key"
sys.puts(obj.root.videos.attr("total")) // outputs "2"
// attrs() returns an object of all attributes
sys.puts(obj.root.videos.video[0].attrs().id); // outputs "1"
});
Node-xml2object depends on the node-xml module, and the tests use ntest. Right now, I’m embedding them as Git submodules, but I’m planning on changing that in the near future, since it’s pretty messy this way. The source code is licensed under the MIT license, so feel free to use it however you’d like. I’m pretty happy with where it’s at now, but if anyone would like to fork it and improve things, go for it!
iPad Keyboard Fragmentation
As usual, I enjoyed reading John Gruber’s musings on the iPad. I was intrigued most, however, by his thoughts on the iPad’s support for hardware keyboards:
Having used the hardware keyboard yesterday, though, it is clearly a secondary form of input. You cannot even vaguely drive the iPad interface by keyboard alone. […] There are some glaring holes. For example, in iPad Mail, when you start typing in the To: field to address a message, and the iPhone-style autocomplete suggestion list appears under the field, you cannot select from it using the keyboard. You have to touch the screen. […] It just seems like it’s not finished yet.
What struck me as interesting is how similar this is to Android development’s biggest drawback: hardware fragmentation. Due to the vast array of Android devices, app developers have to consciously design their apps to support several different input methods. This may seem fairly trivial, but it is actually a fairly significant problem, especially for games and more complex UIs. In the Android Market, some games and applications just don’t work without a hardware keyboard, likely because the app developer didn’t take the time to consider touchscreen input. Apple seems to now be encountering this problem as well.
Maybe John’s right, and this is a rough edge that will be smoothed over when the device launches. But, there’s more to it than just fixing iPad Mail. What about the 140,000 apps in the App Store? They certainly weren’t built with any considerations of keyboard navigation, so the experience is likely to be sub-par, unless the developer has taken the time to support an input method that he or she might not even have access to (assuming he or she doesn’t own an iPad).
If keyboard support is solely intended for text input, as John suggests, a lot of users will be confused. Standard operations, such as tabbing between fields and navigating via arrow keys, are expected behavior when a user is given a keyboard. It would be frustrating to have that taken away. Certainly, Apple could fix this issue by the time the iPad hits the market, but for a platform that preaches ease-of-development due to the uniformity of its hardware, it’ll be interesting to see how it’s handled.
Three Weeks with Swype
Roughly three weeks ago, I stumbled across the Swype for Android preview. My first impressions were very positive, and over the last three weeks, I’ve been using Swype exclusively on my Droid. If you’re not familiar with Swype, it’s a new method of typing on a touchscreen device, from the inventor of T9. Instead of tapping out each letter, you just drag your finger across the keyboard, hitting each of the letters in the word in sequence. I recorded a short video showing its basic features:
What I Liked
What really surprised me about Swype was how quickly I was able to get the hang of it. When I watched demo videos, it seemed like it was overly-complicated, but once I used it myself, I couldn’t believe how simple it was. For some of the less intuitive features (such as capitalization, which requires you swipe above the keyboard), I had to run through the built-in tutorial, but after that, I could swipe very easily. One big perk with Swype is that it’s actually pretty easy to use without looking, once you get the hang of it. I found that I could type reasonably well without ever looking at my fingers, something I would have no chance of doing with the standard keyboard.
Drawbacks
My biggest gripe with Swype is it’s just nowhere near as polished as the built-in keyboard. For starters, it’s much more difficult to access symbols, and numbers are laid out pretty strangely. Also, there’s a complete lack on auto-completion for text fields that support it. For instance, if you’re typing the name of a contact in landscape view, the regular Android keyboard will have suggestions below the field that will allow you to select the person without typing their whole name. Swype does not seem to support this at all, which is really pretty annoying. In addition, it’s difficult to type out words normally, if they do not exist in the Swype dictionary. When tapping out letters, Swype tends to interpret your taps as swipes, adding unnecessary spaces between letters. Once you type an unknown word the first time, however, you never have to do it again, because it gets added to the dictionary, which is pretty nice.
In addition, I’ve found that the sensitivity of the keyboard can be a little strange when swiping quickly. Many times, it won’t recognize that you’ve stopped a word and started a new one (which is indicated by lifting your finger up), so it won’t recognize what you’re trying to input at all. In the options panel, there are ways to adjust the sensitivity, but I’d rather these settings were hidden away from users, because it seems like a bit of a cop-out. Swype should instead learn how you type, adjusting its algorithm as necessary.
Conclusions
While there certainly are some issues with the Swype build I used for this review, pretty much all of problems are fixable, and I’m excited to see what the final version turns out to be. They’ve got a really great concept that, with tweaking, could become the best way to input text on a touchscreen mobile device, especially for those who aren’t very adept with traditional on-screen keyboards. I’m not sure what Swype’s strategy is going be with regards to pricing: whether it will be a free app, or if you’ll have to pay for it. Personally, if they’re able to fix my issues above, I would be happy to pay $5-6 for it, and maybe even more, because it really is quite incredible. Even if you can type well with the standard keyboard, definitely give Swype a try.
A Geotagged Vacation
Over the holidays, my family and I took a three-day trip to Chicago, and because I had left my charger for my Canon Powershot G9 at home, I was stuck taking pictures with my Droid’s built-in camera. I thought it would turn out to be a disappointing endeavor, but it actually got me really excited about the future of internet connected cameras.
My least favorite part of photography has always been all of the work afterwards to get it online. I have to take out the SD card, copy the files to my computer, edit them, and then post them to Flickr. When I was taking photos with my Droid in Chicago, I loved how easy it was to instantly post photos online. Using Twidroid, I was able to easily upload photos to yFrog, tweet the link, and have it all geotagged, almost instantly. It allowed me to share what I was doing with my friends as I was doing it, something I could never do with my G9.
The quality of the photos certainly isn’t anywhere near what I could accomplish with a better camera, but that really didn’t bother me too much. As the quality of phone cameras improves, this will become less and less of an issue. Since I had a limited amount of time in the city, I was more concerned with sharing snapshots of where I was (like at the “Bean”) than with creating works of art. On a longer trip, where I have the ability to take my time and set up shots, I’m sure I would want to have a nicer camera along, but for a quick 2.5-day trip to Chicago, my phone worked pretty well.
There are certainly areas where this method of taking photos could improve, however. Like I said before, the quality of the camera is a drawback, but it was one I was willing to accept. Beyond that, I was a little disappointed by the geotagging abilities of Twidroid. If I took a picture of something inside (like the Apollo 8 command module, cool!), the coordinates would be way off, since it couldn’t get a good GPS signal. I would have preferred to be able to pick the Museum of Science and Industry as my location, rather than relying on what the GPS picked out for me. This is something that appears it would be relatively simple to fix. The Google Maps 4 Twidroid source code is available online, so I might try and update it myself to use places (using Google’s local search API or something similar), or at the very least it could allow you to check back into a previous location. I am also hoping Twitter releases more features related to geotagging on their site. Right now, coordinates are only visible through the API, so unless you’re viewing my tweets in a geo-enabled Twitter client, you won’t see my location.
I certainly could use a service such as Brightkite to fix some of the issues above, but I really want to stick to just using Twitter. It’s become clear to me that Brightkite really isn’t pushing the envelope any more as a service, and there really is little incentive to post there. I definitely agree with Colin Devroe that their future should be to act as a Twitter client, rather than as their own community, since I really don’t see them being very successful otherwise.
Clearly, the future is bright for geotagging, and I can’t wait for the day when I can have a high-quality camera in my pocket that allows me to do everything my Droid does on vacation. While I’m not someone who likes broadcasting my location constantly, it’s a nice ability to have while travelling, to both share your trip with others, and to be able to look back at what you did. Hopefully the tools will continue to improve, and they’ll be more and more universal, because I think this is something everyone could enjoy.
Easy Deploys to Multiple Environments with Capistrano
At Viddler, we’re switching to using Git and Capistrano for our internal projects, and I was tasked with setting up the system to deploy our code to both staging and production environments. Capistrano doesn’t have built-in environment switching, but it’s dead simple to add it yourself.
The key to getting this to work is to utilize Capistrano’s ability to chain tasks–if you run cap task1 task2, it will run the two commands in the order you listed them. Variables are shared between the tasks, so if you set a variable in task1, task2 will be able to access it. To get multiple environments working, you just create tasks to set environment variables, which you call before the actual task you want to run.
The first step is to figure out which variables you need to change, and then move them into their own tasks. Here’s an example of the tasks we added:
desc "Run on staging server"
task :staging do
server "staging.myserver.com", :app, :web, :db, :primary => true
end
desc "Run on production server"
task :production do
server "myserver.com", :app, :web, :db, :primary => true
end
Now, if you want to deploy to staging, just run cap staging deploy, and for production run cap production deploy. Easy.
The Perfect Git Workflow for a One Person Project
A few months ago, I started investigating Git, and I fell in love with how much easier it made managing my code. I’m managing the source code to this site with Git, and along the way I’ve come up with a pretty good workflow for myself. The basic steps are:
- Branch
- Commit
- Rebase
- Merge
- Deploy
Let’s go through each one to see how it all works together.
Branch
With SVN, I found myself hating branching–it was always a complicated procedure, and I could never remember how to do it. In Git it’s as easy as git checkout -b <branch-name>, and you’re ready to go. Once you have a branch, you can modify it however you want, and you don’t have to worry about interfering with the master branch. In order to keep your master branch bug free, commit only to branches, not to master itself.
In addition to creating new branches for major features, I always have a few branches around that I pop into for certain things:
- “design” - any changes I want to make to the design go here
- “optimize” - optimizations to the site
- “bugfixes” - a place to work on minor bugfixes
Having these branches allows me to make small fixes to the site, and if it turns out it’s more than just a small fix, it doesn’t interfere with anything else.
Commit
In the Subversion world, it’s a pretty common practice to make very large commits, consisting of many changes. With Git, you should constantly be committing. By making many commits, you make it easier to find bugs you may have introduced, and it makes it a lot easier to track your progress. If you don’t like the thought of wading through long lists of commits in your logs, don’t worry–before bringing it over to the master branch, you can consolidate things with interactive rebasing, but while you’re hacking away on a branch, it really is advantageous to have many small commits.
Rebase
Rebasing is one of the harder things to grasp when you’re first learning about Git. For in-depth coverage of the topic, check out the Rebasing page in the Git Community Book. In a nutshell, doing git rebase master takes any commits to master and inserts them into your current branch, so you can then make sure your new code still works, and it’s a lot less hazardous than doing a merge. Rebasing your branch before putting into master is really important because it allows you to deal with any merge issues before the code goes to your main branch. To rebase, just run git rebase master.
Merge
After rebasing the branch, it’s safe to merge it into master. Since I’ve already dealt with any merge issues with the previous step, it’s as simple as checking out the master branch and running git merge <branch-name>
Deploy
I use Capistrano to deploy my code, so I’m constantly typing git push followed by cap deploy to deploy changes to my server. To make it easier, I just put both commands into one git alias:
deploy = !git push && cap deploy
Now I just need to run git deploy and it automatically pushes all of my changes to the remote Git repository and then deploys the site using Capistrano. Here’s some more information about Git aliases.
Useful tools
Though I primarily use Git through the command line, I really like using GitX to visualize branches. To host my repositories on my server, I use Gitosis, though if I had a few more projects, I’d dole out the money for a paid account at GitHub.
Have a great Git workflow? Think mine’s terrible? Let me know in the comments!
4 Easy Frontend Optimizations for Your Site
Over the past few weeks, I’ve been tweaking the site a bit to help speed up page loads. After running YSlow and Page Speed, it seemed like the slowest aspects of my site weren’t necessarily happening behind the scenes with my Ruby code, but rather on the frontend with images, Javascript, and CSS. Below, I’ve listed four ways you can squeeze more speed out of your site without even touching backend code.
Gzip your files
One of the first things I did to speed up my site was to start using mod_deflate to gzip compress data from my site before it’s even sent to the viewer’s browser. Basically what happens is after my Rails app returns the HTML for the page, Apache then compresses it and sends the compressed version to the user. Enabling this brought my front page size down to 6KB from around 22KB, a 73% improvement! You should enable this on all of your plaintext files, such as external CSS and Javascript files, as well as any HTML that’s being sent to the browser–essentially as many files as you can get away with.
For more information, make sure to read Paul Stamatiou’s excellent post on mod_deflate, where he goes through the steps of gzipping your site on Apache.
Set a far future expires header for images, stylesheets, and JS
When your browser wants to fetch a file, it first checks to see if it’s stored in its local cache, and if it has a new enough version of the file, it will display that instead of taking the time to download it from the server. The problem is, how does your browser know if the cached version is “new enough”? The trick is to use the Expires header for any files you know aren’t going to change very often (such as images, stylesheets, and javascript). I did this on all of my photos, and it has made a huge difference–after turning on the header, my bandwidth usage went down by 70%, since browsers were no longer re-requesting images they already had.
For how to set a far future expires header with Apache, check out Christian Johansen’s tutorial on the subject.
Load Javascript Libraries from Google
Nowadays, just about every site is using a javascript library of some sort, whether it’s Prototype, jQuery, or something else. Since the library might not change from site to site, why not leverage that to cut down on download times? Google has done the work for you, with their AJAX Libraries API, which provides you with a CDN-hosted version (what is a CDN?) of popular JS libraries, so they’re super fast, and once your browser downloads the library for the first time, it will be retrieved from cache for any site that uses the same file.
There are 2 ways to use Google’s hosted libraries, via the API listed on their page or just by including the file. For instance, I’m including jQuery 1.3.1 with this code:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>
I’m not sure exactly how much faster this has made my site, but it definitely keeps bandwidth usage down and makes the user experience much quicker.
Defer Loading of Stat-tracking Javascript
I’ve always run two separate stat tracking scripts on this site: Google Analytics and Mint, but recently, I really started to notice they were slowing down page loading time (especially with Mint). To combat this, I decided to defer loading the scripts until after the page has finished, so as to ensure they don’t impact the user experience negatively. To do this, I just used jQuery’s $.getScript() function like this:
$(document).ready(function() {
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
$.getScript(gaJsHost + 'google-analytics.com/ga.js', function() {
var pageTracker = _gat._getTracker("GOOGLE TRACKING CODE");
pageTracker._initData();
pageTracker._trackPageview();
});
$.getScript('http://path/to/mint/?js');
});
Just customize it to point at your stat tracking scripts, and you’re ready to go. One caveat with this–it may impact your stats, because scripts won’t be loaded until the page finishes rendering, meaning if someone clicks off the page before them, it might not register their visit. I haven’t had enough time to see if my decision to defer loading has affected my stats, but I’m guessing it would have at least a minor impact.
Anything else?
Is there anything else you’ve done for your site that’s really lowered your loading times? Let me know in the comments!
Sass Without the Hass(le)
For a recent project, I decided to try out Sass, a “meta-language on top of CSS,” which allows to do all sorts of neat things like use variables, do math, and have mixins. The only problem: since you’re not writing CSS, it has to be compiled whenever you want to view your page, which can be pretty annoying if you’re just working on a static template (which I was).
At first, I was using the standard command: sass input.sass output.css, but that became too tiresome, and I was struck with an idea–what if I just created a server solely for serving the compiled CSS file? Using Sinatra, I was able to make a dead easy way to use Sass while working on a static template. Follow along to see how you can do this yourself.
First, make sure you’ve got the haml and sinatra gems installed:
gem install haml sinatra
Now, in your development directory, create a file called app.rb and paste the following code:
require 'rubygems'
require 'sinatra'
require 'haml'
get '/style.css' do
headers 'Content-Type' => 'text/css; charset=utf-8'
sass :style
end
Now, create a views/ directory in that same folder, and drop a style.sass file in there. This is where you’ll be writing your Sass. Now, you need to start up your Sinatra server, and to do that, just run the following command:
ruby app.rb
Now, if you go to http://localhost:4567/style.css, you’ll see your compiled CSS, and every time you update your Sass file, the code is recompiled. Just change the CSS <link> tag in your HTML template to point to the style.css file, and you’re ready to go!
Improving on Related Entries
A little while back, I posted about how I was determining related entries for my site. That method worked, but once I redid my site and added my 250+ Flickr photos, it started to really slow down when finding related photos, because of the increase in tags and posts. The real issue was that I was doing most of the work in Ruby, when it really should have been done with SQL. So, I decided to rewrite it.
Note: If you haven’t looked at my previous entry on the subject, you might want to take a look at it, just for the general idea of what I’m trying to accomplish. Essentially, I’m trying to find related posts by comparing tags. Here’s my new Post#related code:
def related(limit=5)
return [] if tags.empty?
join_array = tags.collect {|tag| "posts_tags.id = #{tag.id}"}
tags_join = "AND (#{join_array.join(' OR ')})"
self.class.find(:all,
:joins => "INNER JOIN taggings posts_taggings ON posts_taggings.taggable_id = posts.id" +
"INNER JOIN tags posts_tags ON posts_tags.id = posts_taggings.tag_id #{tags_join}",
:conditions => ["posts.id != ?", id], :group => "posts.id",
:order => "COUNT(*) DESC",
:limit => limit)
end
You can see, as I mentioned, that all the work is being done in the SQL now. I first create a list of tags from the current post, which I then feed into the query to search for other posts with similar tags. The SQL instructs the database to search for any posts with any of these tags, and then orders them based on how many tags match between the 2 posts. The SQL ended up being fairly complicated, with a lot of joins, but it’s now a whole lot faster, because I’m not creating a lot of overhead by dealing with the computation in Ruby. If you’re interested, here’s an example related entry query:
SELECT `posts`.* FROM `posts`
INNER JOIN taggings posts_taggings ON posts_taggings.taggable_id = posts.id
INNER JOIN tags posts_tags ON posts_tags.id = posts_taggings.tag_id
AND (posts_tags.id = 695
OR posts_tags.id = 192
OR posts_tags.id = 195)
WHERE (posts.id != 4322) AND ( (`posts`.`type` = 'FlickrPhoto' ) )
GROUP BY posts.id
ORDER BY COUNT(*) DESC
LIMIT 5
How to Take Better Photos
I’ve been into photography for a while now, and while I definitely don’t consider myself an expert on any level, I’ve come across a lot of tips over the years that have really helped to improve my photos. I’ve collected together a few of my favorite ones below, in the hopes they’ll help someone else.
Constrain yourself
Peeling Paint and Window, taken with my 50mm lens
Next time you go out to take some photos, give yourself a constraint. For example, maybe just bring one lens, or choose just one focal length to shoot at (a prime lens works perfectly for this). When I went to Italy, I brought 2 lenses, one of which appeared to be broken when I got there, so I had to spend the week using only my 50mm lens. This actually turned out to be a blessing in disguise, as I ended up with some of my favorite photos I’ve ever taken. Another great exercise in constraints is to place a piece of paper on the ground, and then take 50 photos without taking your feet off the paper. Really, you’re just trying to get yourself to look at the world in a different way.
Take your camera everywhere
A lot of great photos come about because someone was in the right spot at the right time. However, in order to capture the moment, you have to have a camera to do it with. If you’re not carrying your camera with you everywhere, you’re probably missing out on a lot of opportunities. One of the best things I ever did was purchase a point and shoot camera that fit in my pocket–now I can carry it wherever I go, ready for the unexpected.
Stop worrying about equipment
Weeping Lily, taken on a tiny point and shoot!
So many times, I’ve caught myself saying, “I would love to take that photo, but my camera’s not good enough.” This is stupid. Ansel Adams didn’t have a fancy 20 megapixel DSLR, and he took photos better than most people can even dream of. Instead, work with what you have–it’s the thought behind the photo, not the camera, that truly matters. I’ve taken great photos with tiny little point and shoot cameras, and I’ve taken horrible photos with my big DSLR. The sooner you realize your equipment doesn’t matter, the better.
Ask for critique
This photo of my sister became a whole lot better after having it critiqued on Flickr.
Some of the best photography experiences I’ve had were when I’ve had my photos critiqued by others, and when I’ve critiqued others. Having someone else take a look at your work can be incredibly helpful, as they’ll often notice things you never saw yourself, and critiquing other people’s photos can help you find new techniques and approaches to photography. If you have a group of friends that are all into photography, maybe you can meet every so often and swap shots. Or, join a site like Flickr, and start commenting on photos by other users. Soon enough, they’ll be commenting back on yours, and you’ll start seeing your photos in a whole new light.
Take lots of photos
Memory cards are cheap, so why skimp on photos? I’ve found that the more photos I take, the better I become at photography. But it’s not just about taking lots of photos, it’s about going back and seeing what your mistakes were and learning from them. If you aren’t taking a whole bunch of photos, you’re not going to learn from your mistakes, because you won’t be making them.
Don’t think about Photoshop
This photo, Dreaming, was weak from the start, and my attempts to save it really didn’t do much.
For a while, I was really into Photoshop–nearly every photo I took was manipulated in some way to make it better, and I started to even think about how I was going to process an image before I even pressed the shutter button. This is bad. Focus on making your photos as perfect as possible before they get to your computer, and you’ll end up with a much nicer finished product. That’s not to say you shouldn’t tweak photos afterwards, but you just have to remember that taking an amazing photo isn’t about what filters you use, but rather about how you compose the image in the viewfinder.
Hopefully these tips are helpful, and if you have any to share, make sure to leave comments below!
Recalibration
As you may or may not have noticed, I recently redesigned my site, only about six months after my last redesign. I did this for a variety of reasons, the biggest of which was how outdated and restrictive my old design was starting to feel. The new design brings more flexibility and represents a slight change in the focus of my site. It’s perhaps one of the more complete designs I’ve ever done, which is surprising, since I had it done in only about 4 days.
A Little More Personal
Having “web design + development” in my header restricted my post topics.
One issue that always plagued me with my previous design was that I felt compelled to stick to one topic: web development. I remember showing Colin Devroe the design for the first time, and he mentioned that I should take out the “web design + development” from my header. At the time, I brushed the comment aside, thinking it was not much of an issue. As time went on, however, it became more constraining, and, now, with the new design, I’m hoping to make this into more of a personal site. Sure, I’m still going to be posting mostly about the web, since that’s one of my primary interests, but I also hope to have more posts about other things as well. I also imported all of my Flickr photos into a brand new section on the site, which I’m really excited about.
Easier to Navigate
My old archives were painful to browse.
With my old site, it was almost infuriating how difficult it was to discover old posts. The main archive page (pictured above) was just about useless, and it was hard to find related posts once you started browsing. With the new design, I’ve significantly cleaned up my notebook section to make it a whole lot easier to browse. I’ve even found myself browsing my old Flickr photos this way, because it’s so enjoyable. My absolute favorite part is the “filter bar” that appears on each archive page (e.g. the 2008 archives), which allows you to quickly filter out what type of post (entries, links, or photos) you want to see, no matter whether you’re browsing by tag or date. I’ve also improved the related entries algorithm, and it now is more accurate and efficient. (I posted my old algorithm a little while back.)
My New Favorite Font: Calibri
The new archive filter really help to drill down what you’re looking for, and it looks great in Calibri.
When I first started mocking up the new design in Photoshop, I used Calibri, one of the new fonts in Microsoft Office, for the text, expecting to change it later. As I kept working, I eventually fell in love with the font and realized I couldn’t have the site set in anything else. However, this posed a problem, as most people do not have Calibri installed, and, because it’s sized slightly smaller than other fonts, having a fallback of Helvetica or Arial didn’t look very good. To combat that, I put together a simple jQuery plugin to detect if Calibri is installed, which allows me to serve two different versions of the site really easily. If you don’t have Calbri, however, I’d really, really recommend getting it, because it truly is a beautiful font. Check out my about page for info on where you might find it.
Separate Admin Area FTW
Back when I was working on rewriting my site, I toyed with the idea of having all of the site administration inline–that is, instead of having a separate admin area, I would be able to edit a post from the same page everyone else views it, with a sort of WYSIWYG interface. After thinking it over, I ended up keeping the two parts separate, and I’m really glad I did. When I went to put the new design into my Rails project, I didn’t have to worry about making sure my administration functions still worked, because I didn’t even touch that code–I coul d go ahead and change the design completely without breaking the core of the site. I also didn’t have to have the extra hassle of designing to accommodate an administration area as well.
Feedback
Of course, I’m constantly tweaking the site. Right now, I’ve got a list of about 15 things I still need to do, and I’m sure that will keep growing. If you have any thoughts on the new design, please let me know either by commenting on this post or by sending me an email. If you’re reading this through a feed reader, please come and check out my site and see what you’re missing!
The Black Hole War
I recently finished reading The Black Hole War by Leonard Susskind and really enjoyed it. Billed as “the riveting inside account of the battle between Stephen Hawking, Leonard Susskind, and Gerard ‘t Hooft over the true nature of black holes,” I ended up learning a lot from the book about black holes, quantum mechanics, and gravity.
Information Loss
The central issue at stake in the book is the idea, proposed by Stephen Hawking in 1981, that information is lost when an object is devoured by a black hole. That is to say, if you or I happened to get sucked into a black hole, when that black hole evaporated (as all eventually do), there would be no sign that we ever existed. This may seem to make sense, but it violates a central law of physics that information cannot be destroyed. Even if you think of burning a book, you may not be able to read the pages any more, but, if you were able to catch all the light given off from the fire and collect any remaining physical pieces, you could reconstruct the book as it was, so the information contained within it still exists.
Susskind, upon hearing this pronouncement, spent the next 20 years trying to disprove Hawking. Though Susskind initially was in the minority, he eventually was able to convince physicists that information is indeed conserved when an object enters a black hole. While it’s a book about some very complicated physical interactions, Susskind presents it in a way which is very accessible to the average person.
Physics as Thought Experiments and Analogies
One of my favorite aspects of Susskind’s book was how he was able to boil down even the most complex problems to simple thought experiments or analogies. For instance, to explain how gravity can bend light’s path, he used the example of a very fast elevator, and to describe what someone would look like as he or she fell into a black hole, he used an analogy of fish in a pond getting sucked down a hole in the middle. This is one of my favorite parts about studying physics–most complicated problems can be explained through simple thought experiments, which is exactly how Albert Einstein first came up with the special theory of relativity.
As Susskind got into more advanced quantum mechanical topics, I could tell he was having trouble explaining the concepts without mathematics (there were perhaps only 2 equations in the entire book). This is not his fault, as the interactions on a quantum scale are so bizarre that there really are no analogs in the real world. Humans were not made to be able to understand these things, so it requires a lot of “rewiring,” as Susskind puts it, to really understand what is going on, more so than can be done in a 450-page book. That being said, Susskind does an admirable job of giving enough insight into what is going on without having to go into the specifics.
Definitely Recommended
If you have any interest in black holes at all, I’d definitely recommend reading The Black Hole War, as it is definitely a book created so that everyone can have at least some understanding of the complexities of black holes. For me, I wish it had been a bit more on the technical side, but I can definitely understand why Susskind wrote it the way he did. If nothing else, it excited me to learn more about what are some of the strangest objects in our universe, and I’m really looking forward to go more in depth about their properties in my classes at school.