Mice run faster under Lions

Posted by – July 25, 2011

I’ve been running Mac OS X 10.7 Lion for about two hours now, but it didn’t take me that long to notice that something was seriously off with the mouse acceleration. I found myself overshooting pretty much every small target I tried to hit with my mouse. In fact, I felt like I do when I’m forced to use…Windows!

Now, Apple has been making concessions to switchers from Windows for years. I’m happy to say that they outnumber the longtime faithful (means the platform is getting successful), and mouse acceleration has been a sticking point for switchers, so changing to a more Windows-like curve is probably the right thing to do. This is small consolation to me, since it doesn’t change the fact that right now, I can barely use my mouse.

Confirming the shift

How do I know that mouse acceleration has been a sticking point for switchers? Arguments on the Internet, how else? Because of my participation in said arguments, I happened to have a picture of my old preferred acceleration curve:

Old Acceleration Curve

This screenshot, by the way, comes from the excellent ControllerMate, which you can use to configure any arbitrary acceleration curve you want (among many, many other things.)

Here’s how things look under Lion:

Lion accel curve

Ouch! No wonder I’m overshooting things. That curve is way steeper than what I’m used to.

Fixing the curve

Fortunately for me, I didn’t even have to draw a custom curve, since the old curve is still there. Did you know that every notch in the “Tracking Speed” slider of the “Mouse” preference pane in System Preferences is actually a different acceleration curve? My old curve, which used to reside one notch left of center, is now the second notch from the left. I discovered this, again, because ControllerMate lets you see all the OS standard curves.

So, don’t worry; you’re not crazy; your mouse is actually running faster under Lion. Thank goodness the fix is as simple as turning the speed down.

Made with 100% Pure Height

Posted by – June 23, 2010

It happens to every budding web designer eventually: you need something, usually a div, to stretch to the entire height of its container. So, you quite reasonably use CSS to set the height to 100%. This ought to work—there’s no reason why it shouldn’t—but it doesn’t. Every single web browser in existence will point and laugh at your pathetic attempt at a simple solution to a simple problem, and then they will ignore it.

After a couple hours banging their head against the problem, most nascent web designers give up and change their design. That’s because there is no simple, reasonable way to do this. Oh, you can muck about with absolute positioning, which will work if the element’s container can also be positioned absolutely. Sadly, this isn’t often the case.

I’ve also found claims that simply setting the body’s height to 100% will make the setting work for all other elements as well. However, I’ve found that this is just plain wrong; I can’t make it work. It does work if you give the body a height using a fixed unit, such as pixels, which you will almost never be able to do.

The rationale given for why this works is that, in order to calculate a height that is specified as a percentage, the browser needs an element somewhere higher up the containment hierarchy with a defined height. I am entirely too lazy to verify whether or not this explanation is derived from the CSS spec.

(As an aside, this rationale also explains why width does not suffer from the same percentage dysfunction as height. The height of a page is determined by its content, but its width is specified by the width of the browser window unless overridden by CSS.)

Of course, whether or not the rationale is derived from the spec, it’s still a heaping load of crap. Obviously, the browser must calculate the height of every element before it can render anything. It even exposes these calculated heights to the user through Javascript.

Wait…OH!

Doing the Browser’s Work For It

I said there is no simple, reasonable way to do this, and I meant it. The solution I am about to describe is simple (thanks to the magic of JQuery), but it is in no way reasonable. Using Javascript to fix up your layouts is an obscenely stupid hack that should only be used when all saner options have been exhausted. If you can use the absolute positioning trick, do it. If you can alter your layout to avoid the need for height:100%, then do that. Don’t sully your work with this ridiculousness unless you have no other alternative.

Still reading? Ok, deep breath. Here’s the code; it’s just a few lines:

$(document).ready(height100percent);

function height100percent()  {
    $('.container').each(function()  {
        var h = $(this).height();
        $('.100percentHeightPlz', $(this)).height(h);
    });
}

For those not familiar with JQuery, let me go through this line-by-line.

  1. When the document is loaded and ready for manipulation, run the height100percent function.
  2. Find every element having the CSS class “container” and apply the given function to each of them.
  3. Get the height of the current container element.
  4. Find all objects having the CSS class “100percentHeightPlz” that are children of the current container element. Set their heights to that of their container.

Now, W3C, was that so hard?

Less Stop and More Go

Posted by – June 19, 2010

This is a post about driving. Yes, one of those.

Last night I got caught in a traffic jam on I-15 southbound somewhere between South Jordan and Thanksgiving Point. At 11:30 PM. That’s Utah for you.

(Okay, it was a Friday night, and, due to construction, the four-lane highway was reduced to a single lane. Still, there were a ton of cars on the road for that hour of night.)

Regardless of how ludicrous it may be to get caught in a traffic jam at 11:30 PM, I am certain that you have been there before. You, a single driver caught in the jam, are currently completely stopped. This is not a pleasant state of affairs for one who is trying to get somewhere. Irritation mounts inside you. Suddenly, a ray of hope! The car in front of you starts to move! You take off after it like a shot.

Because you have the reaction time of a normal human being, a space of pavement opens up between you and the car ahead of you before you are able to punch the accelerator. This space enables you to accelerate to a higher speed than the clogged road can sustain. All too soon you have to slam on your breaks. Oh, and by the way, the person in front of you is doing the same thing. This behavioral pattern creates waves that propagate through the traffic, causing everyone to stop and go.

Stop. Go. Stop. Go. This is giving me a headache.

Beyond driver fatigue, stop and go driving is bad for your car and bad for your wallet. All that accelerating and breaking puts wear and tear on your engine and breaks, and sinks your MPG into the crapper. Fortunately, you can beat this cycle (with a stick, if need be).

The first step is to recognize that, because the road is over capacity, everyone is going to have to slow down. You can’t change that so you might as well accept it.

The second step is to try to find the speed that the road can accommodate. If you can find and travel at this speed, you won’t have to be constantly stopping and going—you’ll just go, like you normally would on the freeway (only slower). The trick is to open up a large gap between you and the car in front of you. When they get too far away, you can go a little faster; if you find yourself gaining on them, ease off the accelerator.

You should see the distance between yourself and the car in front of you fluctuate regularly. This is because they are caught in the waves and are constantly stopping and going. If the distance between you is large enough, it will eat the wave, enabling you to travel at a more-or-less constant speed. Your traffic jam experience will have a lot less stop and a lot more go.

Last night, I had a great opportunity to practice this technique, and I was treated to a sight that, because I am a nerd, I found delightful. The flashing taillights of the cars in front of me created a very visible wave pattern that propagated up and down the line. But behind me, as far as I could see, everyone was traveling at a constant speed. I had erased the waves.

Then I realized that I wasn’t irritated anymore. I was having fun! By making a very simple change to my behavior, I was able to change the behavior of those behind me, saving all of us some gas and reducing our irritation. I, possessed of the power of nerdiness, used that power for tangible good! And now, you have that same power. Go forth, nerd heros, and use your power for good.

These ideas come from William Beaty, electrical engineer and nerd hero. His site, trafficwaves.org, elucidates them in meticulous and eloquent detail. If you don’t have time to read it, at least watch the video that’s linked from the front page.

The Search for Semantic Writing

Posted by – May 29, 2010

I grew up using word processors. By all rights, we should be old friends.

My first word processor was Final Writer on the Amiga. I used it to type all my school assignments all throughout grade school. It was a great tool, and easy enough that even a grade schooler could figure it out. Back then, I was happy just to be able to type instead of hand writing everything. I’d print my documents out on our Epson dot matrix printer, and, later, on our HP inkjet. What I saw on-screen was, more or less, what I got from the printer; I never thought much of this because it seemed like the obvious way things ought to work. Without the web, I likely never would have realized that it’s a fundamentally broken way to work.

From Final Writer to Claris Works to Microsoft Word, somehow the same little frustrations carried over. Make a word bold, clear the bold setting before entering the next word, make a typo, erase, find that the text is bold again. Repetitiously change formatting for headers and other elements, then change it back for regular text. Never, ever figure out the logic behind the little fiddly bits in the ruler that control indentation according to some incomprehensible arcane formula.

Writing for the web is different. On the web, you author pages in plain text, and what you see is most certainly not what you get. Printers have nothing to do with it; content is paged according to its needs instead of the limited physical space of a piece of paper. Most importantly, web designers who know their stuff create semantically structured documents that separate their content from its presentation.

Arguing Semantics

If you’re not a web designer, the words “semantically structured documents” probably mean bupkis to you. Let me explain.

When you want to create a header in a traditional word processor, what do you do? Font size 16, bold, maybe use a different font? What you’ve done is make the text look like a header without actually calling it a header. Your WYSIWYG document has no structure; it’s just styled text. (Named styles kinda-sorta structure WYSIWYG documents, but they only go halfway. They have the form of semantic structuring, but they deny the power thereof.)

Semantic structuring takes the opposite approach. Instead of applying a style to create a header, you apply a bit of markup that names it a header. Each bit of text is given a name that describes what it is: headers are marked as headers, emphasized text is marked as emphasized, and so on. Writing this way frees you from having to deal with the vagaries of formatting while writing. It’s incredibly liberating.

It’s also deceptively powerful. Write your documents with semantic structure, and you’ll have a source that can be automatically transformed into any sort of output format you desire. Web designers exploit this property to make web sites easier to maintain, but the concept need not be limited to web pages. After drinking the sweet semantic kool-aid, I found myself wanting to write everything using semantic structure.

So, that’s that. We had a good run, WYSIWYG and I, but now I fear we’re breaking up, and I’ll be happy if I never have to use another word processor ever again.

Tools for Semantic Writing

When I went shopping for a semantic writing toolchain, I had a few basic requirements in mind. Whatever I settled on had to have the following four characteristics:

  1. Simple to author, clear to read in source form. As I would mostly be creating simple documents, I didn’t need a lot of advanced features and the complexity they bring.
  2. Works well with Git. I recognize that this is not a common requirement for a writer to have, but I’m also a programmer and am thus addicted to version control.
  3. Has tools to transform into a number of output formats, including pretty PDF and RTF in standard manuscript format.
  4. Elegant to use. Not too much effort to set up if I could help it.

I evaluated HTML, Markdown, LaTeX, and dedicated applications such as Ulysses against these four criteria, and this is what I found.

My First Markup Language: HTML

I’ll be honest: I didn’t spend long thinking I might use HTML for regular writing. While it is a powerful markup language that I know very well, it’s not really designed for writing things other than web pages. It would be unnecessarily cumbersome to write (for example) fiction using HTML, and the tools that convert from HTML to RTF are, from what little I’ve seen, not very good at it.

HTML is still a part of my life. It was my first love in semantic writing, but it couldn’t be my last.

The Mother of All Markup Languages: LaTeX

As far as I know, LaTeX was the first system to separate presentation from content. It consists of a markup language and a toolchain that converts said language into a number of pretty output formats. It’s frequently used in the publishing industry as a basis for typesetting books, and is the standard for writing academic papers and books. These attributes made LaTeX look very promising to me.

That is, until I started to learn it. I quickly discovered that, while I’m sure it’s a great tool for a lot of people, it didn’t fit well with my needs.

  • LaTeX is old. It’s crufty. It has a lot of features that are obsoleted by modern character encodings, for example.
  • LaTeX is complex. It has a lot of features and does a lot of things I didn’t need it to. As a result of this, it was often hard to know which markup construct to use for my specific use case.
  • LaTeX is kind of hard to style. Its style tags are obtuse and complicated.
  • Even after all this time, the toolchain still has that “duct tape and bailing wire” feel common to all too many open source products.

Ultimately, I found LaTeX to be overkill, and not really suited to my needs.

Mark Down, Not Up

Markdown is a simple markup language created by John Gruber of Daring Fireball. It was designed to be natural to read and write, and is typically compiled down to HTML. I love Markdown; it’s great for taking notes and writing simple documents, not to mention its original purpose (blogging). In fact, I’m writing this blog post in Markdown right now.

I’ve been doing most of my (non-coding) schoolwork in Markdown for the past year and a half, and when I take notes, I use Markdown. I’ve even written three short stories using the format. It is very clean, and has a small, focused feature set (if you need more, you can simply drop into HTML). But, it doesn’t scale well to large documents, like novels.

MultiMarkdown is an extension to Markdown created by Fletcher Penny. It was designed to address the large document issue, and also to broaden the range of Markdown’s output formats. I think MultiMarkdown is a great concept, and can recommend it to anyone looking to get into semantic writing. I almost settled on it myself.

What stopped me were the tools. They felt immature and cobbled together. Yes, they are usable, but they simply can’t compete with the elegance and ease of use provided by a dedicated application. If said applications didn’t exist, this is where this post would end, but since they do, we soldier on.

Ulysses the Epic

Yes, there is more than one dedicated semantic writing app for the Mac, but since Ulysses is the one I settled on and most heartily recommend, I will omit mention of the others.

Ulysses brings semantic writing, powerful exporting, and project management together in a capable, more-or-less elegant package. Its simple markup is designed specifically for the needs of fiction writers, and is customizable. It outputs a large number of formats, including RTF, LaTeX, PDF, and (soon) HTML. It provides fine-grained control over styling of output. It is a focused, purpose-built tool, and it is very good at what it does.

Within a project, the actual writing is saved in any number of documents, which can be tagged, reordered, annotated with notes, and otherwise managed. This setup is great for writing really big projects, like novels. (Yes, I’m crazy enough to have started writing a novel. Yes, this fact is what prompted me to really nail down my semantic writing toolchain. And yes, I know my novel is going to suck. Shut up. It’s a first try, and I’m writing it for fun.)

That said, Ulysses is not perfect. Its interface is not the best-designed in the world. In particular, I find its implementation of document groups and filters unusually removed from the documents that they group and filter. There may be a good reason for this that I’ve yet to discover. And do we really need three different types of notes?

Also, of all the tools I’ve explored, Ulysses is the only one that costs money. In fact, it’s a bit on the pricy side, though the educational discount helps. Still, at 35EUR (around 45USD at time of purchase) for an educational license, I had to think long and hard about whether it was worth the money, or if I should just stick with MultiMarkdown. That I opted to spend the money shows that I’m a sucker for good tools.

Lastly, some notes about version control. Those not interested in using a programmer’s tools for writing can skip this.

Ulysses projects are standard Mac OS bundles. Inside, they contain a few plists that manage mundane stuff like UI state and preferences, and a series of folders that contain each individual document in the project. Each document has an Info.plist, a folder for notes, a text file that stores an excerpt (not sure what I’d use that feature for), and triply-redundant storage for the document text itself. There is a plain text file, an RTF file, and a binary .textarchive, each of which contains the full text of the document. I have absolutely no idea why they chose to store documents this way.

The bad news is that the binary textarchive is the “canonical” file. It’s the one that gets loaded when a document is opened, and if the text/rtf files don’t agree with the textarchive, they are simply replaced. The good news is that the only information about the documents that is managed in the central plist is a list of all documents in the project. Furthermore, this list uses folder names (a monotonically increasing numerical index), and not the names you assign the documents through Ulysses’ UI.

This means that you can use version control to manage Ulysses projects, but you do have to step carefully. First, if you always add all new files and commit all changes, even to the plists, you should be able to switch between versions of the entire project with impunity. Second, you can revert individual documents to previous revisions as long as you, again, make sure your commits include the entire contents of the document’s subfolder.

Lastly, absolutely no merging of any kind. I’m not too concerned about that, anyway; I don’t anticipate needing it for my fiction.

Oh, and Ulysses keeps a redundant copy of each open document within the project. These open document folders are prefixed with an “o”, and persist even when the project is closed. From the perspective of version control, these are transient noise that need not be versioned. However, if you remove them without also editing the plist, Ulysses will make you save your project to a different file when you open it again, which could get annoying. At the moment, I think the best way to deal with this is simply to close all open documents before making a commit.

Conclusion

Semantic writing has made my writing life easier in a multitude of ways. If you like me find yourself dissatisfied with your word processor, you should give semantic writing a try. It might just sour you on WYSIWYG forever.

Learning to Do Things the Hard Way

Posted by – March 14, 2010

I’m a little stuck on this game called VVVVVV. It doesn’t look like much on paper: it was made with Flash, and the graphics might have been at home on a Commodore 64. However, the music is great, the quirky little humorous storyline is fun, and, despite multiple playthroughs, I’m still not sick of it.

But this is not a review of the game. No, this is me sharing yon pictograph. But first, some background. (Feel free to skip it if you’re familiar with the game.)

VVVVVV has collectibles (what game doesn’t?) called “shiny trinkets”. Collecting them is the key to accessing the secret bonus level, but some of them are really hard to get. The hardest is appropriately titled “Doing Things the Hard Way”. This trinket is so epic that it took me three minutes to get…the fifth time through. The first time…well, let’s not dwell on that.

The following is a pictographic representation of my fifth time collecting the “Doing Things the Hard Way” trinket. Click it to see it in it’s original-sized glory.

Learning-to-Do-Things-the-Hard-Way-Small.png

As you can see, it’s quite an endeavor. I feel like I have to retrain my reflexes every time I try it.

Here’s how I made it:

  1. Turn off the backgrounds before palying as they’ll mess up the compositing process.
  2. Obtain the trinket. Record the attempt using a screen recorder (in my case, Snapz Pro) at 15 FPS, which makes good motion trails. Save the resulting movie using lossless compression (I used PNG).
  3. Export the movie to a sequence of still images. I used Quicktime 7 Pro for this (with Snow Leopard, this must be specially installed from the Snow Leopard DVD).
  4. Sort the over 3000 resulting images by room. This doesn’t take all that long but is very tedious and boring since there’s really no way to automate it. I listened to podcasts while I did it.
  5. Copy one of the images and erase the little blue man. This is our base.
  6. Create a Photoshop action that composites the images by:
    1. Copy the base onto the target image (into a new layer).
    2. Set the blend mode of this new layer to “Difference’. This erases everything but the little blue man, leaving him on a black field.
    3. Copy this onto the base (into a new layer).
    4. Use the Select > Color Range… command to select all black.
    5. Delete the black. Now you’ve got the little blue man isolated in his own layer on top of the room base.
    6. Set the little blue man’s transparency to 17%.
  7. Batch-run this action on every image file for every room.
  8. Combine the resulting individual room composites into one very tall image.

Sadly, by the time I actually got the trinket, the timing had drifted enough so the motion trail depicting Captain Viridian (that’s the little blue man’s name) swooping down to collect his prize looks a bit strange.

I thought this was an interesting sight. Perhaps more interesting would be a recording of someone learning to do things the hard way for the first time…but, then again, such a beast would probably be impossibly thick with little blue men. Most first-timers (myself included) die literally hundreds of times on their first attempt at this.

We Will Be Victorious

Posted by – December 8, 2009

Believe it or not, I drew this for a computer science class. The assignment was to do something right-brained that dealt with the subjects of the course. Well, we watched Robert X. Cringely’s Triumph of the Nerds videos during the semester, and I’m an ambigram nerd. These two facts conspired to bring you the image below:

It says 'Triumph of the Nerds', in case you couldn't tell

In case you couldn’t tell, this says “Triumph of the Nerds”. It’s rotationally symmetric; that is, if you rotate it 180 degrees it will still say the same thing.

I’m not wholly satisfied with the design. For one thing, there is no spacing between “the” and “nerds”; I didn’t have enough time to experiment with ways to separate them without compromising the “m” in “triumph”. That notwithstanding, I feel it’s good enough to share, and certainly good enough to make the grade.

Addicted to the Mostly Harmless

Posted by – December 1, 2009

Note to readers who are not my CS404 TA: this post is an echo of the last, not by my choice, but because the topics were assigned by my CS404 class, which requires me to post its writing assignments on my blog.

I have looked into the abyss. I have dabbled in online games, dipped my toes in the text-based precursor to MMORPGs; I have wiled away hours in pointless chat rooms. I have stared into the grasping maw of the MMORPG, and said, “There but for the grace of God go I.”

I am only grateful that World of Warcraft emerged after my vulnerable formative years were through, so that I could recognize what they would do to me if I tried them. I have avoided them like the drug they would to me become, and advise all others to do the same. You may not know how deep that abyss goes for you, and the potential enjoyment you might glean from the game is not worth the risk of it ensnaring you in life-destroying addiction.

Addicted to the Harmless

Posted by – November 19, 2009

Talking to people online. Reading, keeping current, increasing your knowledge. Working on hobby projects. Enjoying a good book. Writing for your blog. Tweeting and (more often) reading others’ tweets.

These things are harmless; they’re good, healthy activities; but they do not a full life make, and they are all addictive. The Internet is a great connection machine; there are always more people to talk to and more things to read. You could spend your entire life on the Internet and never reach the bottom. Some days, I want to; wrapped up in reading (for example) articles about Cocoa, it’s very easy to forget the homework that’s due tomorrow. These harmless and positive activities then become as detrimental as any imbalance-creating addiction.

That said, the wonderful thing about addiction to the harmless is that you don’t have to give it up to get better. Once moderated, these addictions become an important and wholesome contribution to a healthy and balanced life. If I can do it, and I can, then you can, too.

Third World Think Tank

Posted by – November 14, 2009

This is a story about a shirt.

When I was 19, I served a mission for the Church of Jesus Christ of Latter-Day Saints to Nicaragua. This is a country with few natural resources, a literacy rate of 68%, a government steeped in nigh inescapable corruption, and an economy that has yet to recover from the regime of the Sandinistas (to say nothing of the earthquake that leveled the capital 30-odd years ago). Poverty doesn’t begin to describe it—if one who lives as well as I still lives beneath the poverty threshold, then a new word must be found to describe how the poorest live in Nicaragua.

In Nicaragua, I met a woman who studied industrial engineering in Russia. There was no work for her; she sold tomatoes in the market. I’ve heard that most college graduates do not work in their field of study, but, really, tomatoes?

By complete random chance, the shirts that I bought (in Provo, UT) for my mission were made in Nicaragua. By a chance somewhat less random, I spent six months of that mission in Tipitapa, where those shirts were made. I taught a woman who worked in the factory that made the shirts; when I told her they were made in Nicaragua, she peered at them for a moment, nodded her head, and said that she remembered those shirts.

Hours in the factory are long; 12- to 16-hour days are the norm. A factory worker cannot choose her shift; rather, her hours are dictated to her. If the factory has a deadline to meet, well, it works overtime, whatever the wishes of its workers. Fortunately, the pay is good; it starts at $80/month, with the most skilled and dedicated making $150/month or more.

Some may read a degree of sarcasm in that last sentence; I assure you, I mean it precisely as written. If you can manage to earn $80/month in Nicaragua, you are above the average GDP per capita. At $80/month, you can even afford certain luxuries, like sending your kids to school.

Nicaragua is a country in which one may subsist with very little. Electricity is nice, but hardly needed; the temperature never drops below 80 ºF in most of the country, and nearly everyone cooks over wood fires. If you can’t pay for running water, you can dig a well (though only the truly destitute take this route). Food is cheaper—a small family can subsist on less than a dollar a day. And if you don’t own the land on which you reside, well, nobody cares enough to kick you off.

You think they have poor factory workers in China? At least one of those clothes factories was owned by a man from China.

I don’t feel guilty (well, not very guilty, anyway) that most of what I own was made in a third world country. I can honestly say, from what I witnessed with my own eyes, that those who work at that particular lousy, exploitative sweatshop are the fortunate ones. Because businesses in the developed world realized that a third-world living wage amounts to a comparative pittance, and because the world is flat, literally thousands of Nicaraguans have secure jobs at a competitive wage.

That said, my hope is that our first world free ride will not last forever. My hope is that circumstances in Nicaragua will one day improve to the point where no one would stoop to work for a mere $80/month. Surely the poverty of the developing world cannot last forever; in a flat world, even the Nicas can participate in the same global economic machine that turned America into a nation where poverty is a joke.

It may mean paying more for my shirts, but it would also mean less chance of my job going to India, or China, or Russia. And, you know, it would be pretty great for the people in third world countries, too.

The Cathedral is Still Prettier than the Bazaar

Posted by – November 10, 2009

The open source software model—Eric Steven Raymond’s “Bazaar“—may tend to produce technically solid, stable software systems; it may, as Raymond says, offer many efficiencies over the proprietary software model (the “Cathedral”); it may even be the best way to write certain types of applications. Be that as it may, and with notable exceptions, most FOSS user interfaces are ugly, convoluted, barely-usable dreck. There does not seem to be much market pressure in the Bazaar to make the stall pretty, and in the critical but oft-neglected area of User Experience, the Cathedral continues to dominate.