Some projects I like:
ZFS chromium Closure
Tools xmonad Vim Sabbath
Manifesto DuckDuckGo youtube‑dl Solarized Canto FreeBSD LaTeX Rockbox Perfect
Health
Diet EFF Go Erowid mplayer
Send email to bt@brandonthomson.com.
In an era where many (most?) people have broadband and high-speed high-latency satellite Internet is becoming more common, I'm not sure it makes sense for small personal sites like this one to have multiple "pages" anymore. Browser vendors are gradually hacking around the inefficiencies of the HTTP protocol with prefetching and pipelining, but while we're waiting, this site aims to be as fast as possible without sacrificing usability or backwards-compatability.
Serving all your content as a single HTML file has some interesting advantages. For starters, anyone who wants an offline copy of the entire site can create one instantly using the "Save as..." feature in every browser. Modern browsers and computers can handle enormous HTML documents (especially when no complex style rules are used), so document size isn't a big issue.
Another benefit: content is more "discoverable" than on a traditional multi-page site since users can just scroll down to find it all rather than having to step through a hierarchy of links. Of course we still have links here, but they mostly scroll the page or go offsite. Zero-latency local link handling should be refreshing for satellite Internet users!
Getting the links right is a little tricky. If you want users to see the content they expect quickly, inbound hash links are a no-no. An inbound hash link to content half way down the page requires people to wait for a mountain of content they don't care about to finish loading before they can see what they were interested in, a situation which is especially problematic for dial-up users.
The URL hash isn't sent to the server so there's no way to rearrange desired content to the top if you rely on inbound hash links, either.
The solution is to use hybrid links: plan for incoming links to be normal URLs so the server can put the requested content at the top of the page. Use hash links in the served HTML for clients that don't support Javascript, but replace them with normal URLs in Javascript for advanced clients so that "Copy Link Location" gets a proper inbound link instead of a hash link. Finally, use javascript onclick handlers to do local navigation using hashes, but also replace the text in the location bar with an external URL using the HTML5 History API so that it has a correct external URL if it is copied.
I know, it's a bit confusing and I didn't do a great job of explaining it. But if you look at the HTML source of this site and observe how the links behave it should be pretty easy to figure out what's going on.
This solution works pretty well. Browsers pre-emptively render while content is streaming so low-bandwidth users who load the site without a fragment link still see what they were expecting quickly even though the total content size is very large. If they leave before the whole site is finished loading, oh well, no harm done.
Mobile browsers are another issue entirely: users of such browsers often have small bandwidth caps and would probably appreciate having their bandwidth conserved. I never use such devices so I admit being a bit biased against them.
There are some disadvantages, to be sure: non-technical people won't necessarily understand what permalink means and can inadvertently share links that load the wrong part of your page. Technical users usually get the idea but can get confused at first since the technique is uncommon.
If you care about "SEO" or are trying to maximize ad revenue you obviously shouldn't touch this technique with a ten-foot pole. But those sorts of sites usually aren't all that user-friendly anyway. We're trying to maximize user-friendliness here.
I'm not sure whether or how much search engines punish sites that design pages this way. I'll keep an eye on it.
Anyway, those are some of the reasons this site has been constructed as a single "page." If you're a technical person thinking about setting up a site I recommend giving it a try.
Give feedback on 'Single-Page Sites'
Read more thoughts like this one
These are the same projects listed above, but in long format (for search engines and people who don't like HTML trickery):
I provide these links because I generally like these projects and want to promote them; I don't mean to imply that I am affiliated with any of them.
My favorite part of college, besides learning about Unix, was getting to use LaTeX and all the neat packages like PGF/TikZ. For whatever reason I enjoyed that a lot more than the actual content of all the assignments and papers I worked on.
Some selected work:
Legend has it that the QWERTY layout we all know and love was designed to slow typists down so they wouldn’t jam up the keys on old typewriters with long levers. True? Who knows. To the rescue is the Dvorak layout, an alternative developed in 1936 by a guy named (you guessed it) Dvorak. Supposedly he studied common English texts and assigned keys proper positions based on their frequency, thus saving us all many many miles of finger travel, if only we would use it.
Sounds reasonable, right? I certainly thought so.
I used a Dvorak keyboard layout for more than seven years. It was fun and liberating in the beginning. Not only was there the sense that I was cooler than everyone else, but I invariably got to enjoy a humorous little moment whenever someone tried to type something on my machine (alternate keyboard layouts are very rare in this country and almost always elict confusion). “Having a little trouble there? Oh, ha ha, let me help you with that.” That was always fun.
Truth is, though, I never typed any faster with Dvorak. I’ve always been around a 60wpm typist when I’m trying, and it was generally the same after a month or two of full-time dvorak use.
The biggest difference with dvorak was how comfortable it was for normal English sentences. It’s hard to explain how a keyboard could be more “comfortable” to someone who’s never tried an alternative layout, but basically there’s less stress on your fingers because they don’t have to move as far. Typing feels very fluid with Dvorak; QWERTY is just frenetic by comparison.
You’re probably wondering why I switched back after seven years. It’s true that it was annoying to need to learn how to change a keyboard layout every time I used a new operating system (Windows, Mac Classic, Mac OS X, FreeBSD, linux, I knew how to do it everywhere), but it was certainly doable.
But no, the real problem is that if you do not control the machine, you cannot change the layout.
Back when I was attending a university I was embarrased to look like a computer novice in front of the other students whenever I needed to use a public terminal. I had to revert to hunt-and-peck because the keyboard layout was not changable (and for good reason, I suppose). I don’t much mind looking stupid, but it does get old explaining to people why you cannot in fact type on a standard keyboard.
The issue became more serious when I needed to use locked-down Windows and Solaris systems to take exams. Typing speed was essential and it just wasn’t possible for a mere user to change the keyboard layout. You could say the school deserves blame for failing to allow this, but didn’t I deserve more blame for being a weirdo? Anyone who considers using dvorak should know that any time you take a computerized test like the GRE, you can bet you won’t be able to change the layout.
The other big problem with Dvorak is that programming languages and keyboard shortcuts are almost invariably designed around a QWERTY layout. Ctrl-C and Ctrl-V? Not exactly convenient in a Dvorak layout. Linux commands like ‘ls’ which are easy to type in QWERTY are more painful in Dvorak. These things are more important and annoying than you might imagine unless you have used Dvorak for a long time. It also wasn’t uncommon to find software, especially full-screen games, which ignored the system keyboard layout and assumed I wanted QWERTY. Flash games that used the keyboard were usually pretty awful too.
I wasn’t a vim user at the time, but I doubt vim with dvorak is as nice as vim with QWERTY. Sure, some users have written little hacks that change the keys around to make it more usable, but I bet there are plugin incompatiblities, problems, and stupid annoyances that come because it’s just not a popular configuration.
I loved Dvorak for all its merits, but I've also learned the value of adhering to a standard. I probably won't be switching back.
Give feedback on 'Dvorak, or Why I Learned to Love the Status Quo'
Commercial interests would prefer that you buy a new portable audio player every couple of years but there's no good reason to do so as the technology has been more or less perfected at this point. It would be better for everyone if we could step off the hype train for just a minute and start building hardware to last for the long haul instead of planning in advance to send it to the landfill every 36 months, but I digress.
The ideal player runs Rockbox, has an SDHC card slot (some players which only support SD in the stock firmware support SDHC in Rockbox), and uses standard AA or AAA rechargable cells. An old-school monochrome reflective LCD display should be preferred since it can be read in most conditions without wasting the energy for a backlight. (Rockbox can be configured to use tiny fonts so that you can get a lot of mileage out of a few pixels; commercial audio players often use gigantic unconfigurable fonts which make it annoying to navigate.)
Factors besides these aren't nearly as important.
Unfortunately as of early 2012 I think you can only find any 2 out of 3 of these features in new products (some discontinued models have all 3, but you'd have to buy one used).
A portable charger/powersource which accepts AA cells and outputs regulated USB 5V may help you get more life out of an old player with a dying custom-fit lithium ion battery (don't buy a "new" one since you're likely to get old stock that's been sitting on a shelf for years). You may even be able to remove the internal battery and run the player directly from the external power source to help avoid charging losses. These devices can be had for less than $20 although finding a quality one can be challenging.
If your player lives on a shelf, efficient switch-mode power supplies with a USB connector are pretty cheap these days and handy because they are compatible with lots of devices. Be careful, though: more cheap junk than ever is being sold online and you should always verify UL certification on anything plugged into your mains if you want to avoid nasty surprises.
Give feedback on 'Why You Should Use Rockbox'
I waste a lot of time mucking about with various software systems, so I feel entitled to a short rant about programming languages.
These days I usually reach for Go whenever I need something more complex than a few lines of sh. It is relatively simple, fast enough for most tasks, comes with a good library, and has an engineering-oriented design philosophy (in other words, it is concerned almost entirely with practical matters for programmers and is of very little interest to academics). I've found Go code to be very maintainable even as the language evolves. This site is served by Appengine Go.
Go's relative obscurity means it might be hard to find a job where you can use it right now. For that, I'd recommend Python instead, which is also easy to learn. Go has replaced Python as my first-choice language for new projects, though.
I know enough Haskell to keep my xmonad.hs up to date (read: not much). Haskell is a bit too unusual for my taste. It feels more like a fun language to make interesting toys than a language to be used for serious work (not to imply you can't use such a language for serious work, just that it might not be optimal).
I admit to using Makefiles for lots of weird things, not just builds. Make is great if you stick to the simple parts and it makes it easy to run complex data transform processes in parallel.
I use Javascript because I have to, but I'm not a big fan of it. Closure makes it bearable, sortof. Maybe Dart will be better. Maybe not.
Give feedback on 'Computer Languages'
I've given up on Blogger, but here are some notable posts from an old blog:
This site does not have a built-in commenting system but please let me know about any errors, omissions, or similar problems by email: bt@brandonthomson.com. By default I assume that people who send corrections want to be credited, so please say something if you don't want the name associated with your email to appear on this site (your email address will not be included in either case).
This content is copyright 2010, 2011, 2012 Brandon Thomson. Feel free to duplicate and distribute for non-commercial purposes. You can take excerpts of unlimited size for use in review, criticism, or commentary. Please do not make changes to the text or misrepresent the authorship. Links back are always appreciated. Thanks :)