Along with the new site, I took the opportunity to release a new public key for 2011. If you need to encrypt anything for me, you know what to do.
gpg --recv-keys FBD864B8 gpg --fingerprint [my-email-address] # Ensure printed fingerprint matches what's at http://www.vicfryzel.com/public-key/ gpg --output somefile.gpg --encrypt --recipient [my-email-address] somefile # Email me somefile.gpg
I followed up on my previous post and wrote some blog software that doesn't suck. I'm surprised how little time it took me. It was less than 12 hours from start to finish. I saved a ton of time by not rewriting the whole plethora of individual services that go with a blog.
The back-end is written on top of Django. I actually didn't write a single form handler in the entire application, which gives me a happy feeling! The admin was generated for me (possibly Django's best feature.) Django also quickly afforded me a lot of other features I'll discuss later.
I was able to avoid writing yet another commenting system by just using Disqus, which worked out pretty well. I've heard mixed reviews of Disqus, but my experience was pretty nice. Everything was surprisingly skinnable, I'd expected that portion to be locked down somehow, but it wasn't. The only downside to this is that I lost my existing comment data. I'm checking if I can write a program to import my old comments into Disqus.
For search, I of course used Google Custom Search. This is a given, I think :D It's already 100% better than the search of my previous blog software.
I implemented Markdown support, with Pygments integration and syntax highlighting for code samples I post. The syntax highlighting support is now so much better, because Markdown automatically escapes HTML entities in code samples, which saves me a ton of < > crap that makes things unreadable on my end.
Full page caching (assuming I'm ever popular enough to need such a thing, heh.) Along with this, there are full sets of cache headers sent, so that subsequent requests only happen if needed.
HTML5 & CSS3 for everything UI related. This was one of the easiest parts. I have to thank my colleague, Paul Irish for creating the HTML5 Boilerplate. He made it drop dead easy to start a new set of UI templates. He saved me hours. If you're not using the boilerplate, you should be.
Along with the HTML5 came a new site layout and design, which appeals to my minimalist tastes. Everything scales much better now, with percentage sizes used everywhere with the exception of the fixed width center column.
You'll always see the same font, because I used the Google Fonts API to ensure everyone gets Droid Sans and Droid Mono. It's nice to know that everyone will now see the same fonts, which I think is really the first time this has been able to happen on the web.
I relicensed my content from all rights reserved to Creative Commons Attribution-ShareAlike 3.0 Unported License which is an effort on my part to ensure people realize the stuff I post here is for common use.
File uploads suck. I wasn't really willing to deal with image uploads, while concurrently editing an article. Instead, I've decided to just use a Picasa Web Album for photo uploads. This is actually spectacular for one little known reason: thumbnail generation. See, when you click Link to this photo from an image in Picasa, you can get an embed code that looks like this:
<a href="http://picasaweb.google.com/lh/photo/qQwGxcQvLZ-xZC2CKJ2MumKqv694TzBB3MR4gOkeEvI?feat=embedwebsite"> <img src="http://lh6.ggpht.com/_qaM_hTDX9xA/TSQUVuY7GjI/AAAAAAAABP4/l_BqPPzTKfY/s144/2010-06-23-001231_838x1048_scrot.png" height="144" width="101" /> </a>
But in the img tag, notice the s144 in the URL. If you modify that 144, you actually change the width of the generated image on the fly. This allows you to have instant, dynamically sized thumbnails for your needs. That's not a documented feature or guaranteed to stick around, but it's really useful.
Migrating my old posts out of Typo was kind of a pain. I had posts in mixed formats (Textile, Markdown, raw HTML.) I had to rewrite some things, but everything is Markdown now. Also, I use DreamHost, and setting up a Python application on Passenger is a pretty poor experience. There was a 500 in my application, but it took me an hour to find it, because if your application dies, there's no simple way to get a stack trace out of Passenger. Things seem to be fine now, but if something goes wrong I'll have a hell of a time figuring out what's going on.
Django also needs to fix their interface surrounding get_absolute_url() in models. Seriously. The URL that you must return from that method is not absolute, meaning you're left to add the scheme and hostname yourself to all of your URLs. That leads to another problem with very poor Django sites integration, it's just a huge mess. Luckily, long ago, I wrote a Django snippet that I think solves this problem quite elegantly. I'd forgotten about it, until I ran into this exact problem again.
If you're interested in the source code, let me know. I'm debating whether or not to release the code for this, simply because I don't want to add to the graveyard of dead blog code bodies in the world. Plus, the application here isn't as advanced. I've pushed Django to its limits and extended it before to serve high traffic media sites, and by no means is this blog nearly as advanced.
In my last blog post I used an image. This, apparently, is a big deal for a lot of blogging software. I currently use Typo. It gets things done, but not without jumping through hoops. I have lots of editing issues, like mixed HTML and textile syntax, a preview function that doesn't work, and I can't easily insert an image into the post. I thought that when I upgraded to Typo, I was actually upgrading.
I uploaded an image, and Typo was unable to generate a thumbnail for it, which in turn broke the editor UI. I can't believe modern blogging software has been around for more than a decade, and still, I have trouble dropping an image into a post. It is so damned frustrating. I remember having these issues in 2002/2003 with MoveableType and b2. Textpattern had the same issue when I used it. And my CMS before that had the same issue. What the hell is so difficult about this?
I've considered switching to Posterous, but at the moment I don't like the toolbar branding that that entails. At least if I did switch, it seems I could easily post non-textual content, which after all of this makes it seem like the best thing ever.
I think there's a void in the open source blogging software market for a tool that, without any hassle, allows engineers to write posts about code and occasionally use an image without losing their mind in the process. I've sat down to "fix" this problem on maybe 7 or 8 different occasions in my life, and have yet to pursue it enough to get something going.
The reason for this is that the amount of shit that would have to go into such a product to make it usable for everyone is just a nuisance. There's a whole install process, database population, theme support, plugin system, WYSIWYG editor, working image uploader, etc. I don't need or want any of that stuff (save the image uploader.) I just want something that is easy enough to use so that I don't spend the majority of my time in meta fixing stupid issues with the system, as opposed to just writing what I want to say.
Maybe Posterous will just release something premium so that I can hand them $5 and move on with life.
At the NCSU Apps Script Hackathon, a bunch of people were trying to do things in Google Apps Script with Google Maps. There were tons of great use cases for this. One developer wanted to pull a feed of all Groupon deals, and display their locations on a map so that the user could quickly and easily browse the closest ones.
Although the documentation is a bit on the sparse side, the maps API in Apps Script is pretty capable. It essentially generates a static image of a map, with various features you give it. But there are some nice things you can do prior to generating the image.
Here is a quick function to generate and show a map with two markers, and then display that map in a dialog to the user.
function generateMap() { var address = "111 8 Ave., New York, NY 10011"; var mapUrl = Maps.newStaticMap() .setMarkerStyle(Maps.StaticMap.MarkerSize.MID, Maps.StaticMap.Color.RED, "A") .addMarker(address) .setMarkerStyle(Maps.StaticMap.MarkerSize.MID, Maps.StaticMap.Color.RED, "B") .addMarker("17 st and 8 ave, new york, ny") .setCenter(address) .setSize(500, 500) .getMapUrl(); var ui = UiApp.createApplication(); ui.setTitle("Map"); var panel = ui.createFlowPanel() .setSize("500px", "500px"); panel.add(ui.createImage(mapUrl)); ui.add(panel); ui.setHeight(500); ui.setWidth(500); SpreadsheetApp.getActiveSpreadsheet().show(ui); }
This is nice because you could populate those markers in a variety of ways. If you have a spreadsheet full of location information (do you work for a real estate or delivery company?) then this would make a great feature to add to your company's spreadsheets. You also get some pretty powerful address matching from Google Maps, in case you don't have a complete address each time.
If you run the above function, you get this:
Another problem some developers tried to solve was determining the timezone of an address based on the latitude and longitude of the address. This is also something the maps API can give you, but again the documentation is a little sparse.
Taking the previous example, here we get the latitude and longitude in two lines of code:
function getLatitudeLongitude() { var geocode = Maps.newGeocoder() .geocode("111 8 ave, new york, ny 10011"); // See http://goo.gl/5mr1N for reference Logger.log(geocode.results[0].geometry.location); }
There you can see that we created a geocoder from the maps API, and pulled the latitude and longitude for the given address.
There is a lot more you can do, and the Maps portion of Apps Script is documented in the reference guide.
I just read Brett Hoerner's blog post entitled "On Emacs" and it yielded a response from me!
Let me start by saying that I love vim for numerous reasons, but here are the major ones:
I used to use Emacs. I've got nothing really against it. Emacs gets things done. It's just that in my opinion, vim gets things done faster.
I'm in love with not taking my hands off the home row. In Xmonad, all of the key bindings are based on Alt, meaning my thumb can tap Alt, while my other fingers rest on the home row. That means I can transition between editors and windows and make changes while usually never having to leave the home row. Examples of this include a key sequences like dd, Alt+k, etc. I've even got the key sequence 'jj' bound to be ESC, so that I don't have to reach for the escape key.
This can be contrasted with Emacs using an example: text search. Search for the word "cat". Emacs: C-x-s cat. Vim: /cat. No reaching for Control, which puts your fingers in an awkward position and off the home row, no key sequence, full regex support off the bat, and so on.
Brett makes a great point in his post, stating that step 1 of using Emacs is to customize it. Unfortunately, when I learned Emacs in the mid-90s, my step 1 was learning to navigate, learning to copy/paste, etc. That time period made it especially hard to get information on how to customize it. And despite the advent of good search engines, I think this still holds: users coming into Emacs are overwhelmed just trying to get things done and don't "have time" to customize things they don't like. Customization comes later.
Brett makes another excellent point in stating that editing a vimrc is difficult. I feel Emacs/Elisp are equally at fault here. I've found that one's ability to customize their Emacs or Vim config is directly correlated to the size of their beard. I have a small beard, and assuming that correlation is causation, I thus limiting my ability to edit my vimrc with changes that I'd really find useful (example: some-key-combo => auto-format all source code in file; Eclipse, I'm looking at you!) And don't newbs find more sense in vimrc speak? Assuming you don't learn Lisp prior to your Emacs years, Emacs configuration can be pretty daunting. But, I bet 99.9% of all vim users can read a vimrc file with some semblance of understanding. Moreover, I bet those same people can copy/paste portions from other vimrc files and get up and going a bit more quickly.
Besides all of these efficiency things, one must also consider the breadth of the vi/m install base. I can go to any *NIX terminal booted after I was born and find some flavor of vi. This isn't the case for Emacs.
Lastly, we've got modal editing. This is where vim really shines, in my opinion. Insert mode is for inserting. There are tons of little conveniences for popping into insert mode in vim, often only differing by how they place the cursor. And those conveniences are available for every command mode command I'm aware of. Add visual mode onto this, and you've got the complete package for navigating while editing quickly. The part that turns people off is switching between modes quickly. They don't know all the nuance shortcuts that make going from visual mode to insert mode to command mode extremely fast. People tend not to learn these because modal editing confuses them, so I think there's a wall that people hit when they want to advance beyond i => ESC => hjkl => i => ESC => repeat. 0, $, ^, d$, d0, yy, dd, p, P, {, }, n, N, v, etc. These are all important basic commands that are really what add productivity. If a user fires up vim and exclusively uses i, h, j, k, l, the experience is going to suck. It's the commands that move between modes that make vim sparkle. Also, as I said, binding 'jj' to ESC helps a lot. In Emacs, since there are no such modes (there are modes, but the term mode means something different in the Emacs context) performing all of these operations must be a much more complicated key sequence. By simply wrapping a context around a key, we avoid long key sequences and command keys altogether.
Just my two cents :D