Safe from the Losing Fight

For those of you who actually read this blog for the articles (as opposed to the pictures), you’ve probably often wondered: what is it, exactly, that you do? Other than make a fool of yourself? In order to answer that question, and have something to do, I present what my daily schedule is like.

8am – Wake up, scratch self, turn over, fall back to sleep. No respectable software engineer gets up this early.

8:15am – MacBook Pro’s dancing in my head. Unless you’re my girlfriend, in which case, I only dream about you baby.

9am – Wake up and realize I do not own a MacBook Pro. My dreams crushed, I see no reason to remain conscious, so I scratch myself, turn over, and fall back to sleep.

9:30am – Apartment maintenance personnel decide that I have slept long enough and begin pile-driving two feet outside my bedroom window, where in the alley they have apparently decided to construct a large shopping center.

9:31am – Contemplate the needed trajectory of a rock that would injure, but not kill, said maintenance person. I might need my ice maker fixed at some point.

9:35am – Give up on plan to maim maintenance personnel because it would involve moving a part of my body, and, let’s me honest, who doesn’t want an large 24-hour supermarket directly outside their window?

10am – Unsure if I am yet awake, maintenance personnel begin mowing what’s left of the grass outside my bedroom with a bush-hog machine.

10:01am – Stagger the 10 feet from my bedroom to my “office.” Manage to stub my toe on no fewer than seven objects. As required by law, at least three are more dense than depleted Uranium.

10:02am – My now semi-awake brain discovers that the computer/printer combo doesn’t not provide this “food” that the Wizard needs, badly.

10:03am – Stagger over to the refrigerator. My agile feet know the path well, and manage to run into the same seven objects.

10:05am – Think about how good a breakfast with scrambled eggs, bacon, and blueberry pancakes would taste. Unfortunately, I am a bachelor so anything that cannot be made from hot-dogs and month old bread is out of the question.

10:06am – With hot-dog flavored “PopTart” in hand, return to the computer.

10:07am – Digg and Slashdot.

11:03am – Decide to actually “work.”

11:04am – Start pulling down code to work on with Perforce, the Fast Software Configuration Management System. The file set consists of three small text files, one resource file, and a large image file describing how the software system works, assuming they had actually built it that way.

12pm – Lunch, which is a hot dog, stale bread, or some combination thereof.

1pm – Perforce, the Fast Software Configuration Management System, actually completes the synchronize operation, leaving me with three small text files, twenty corrupted resource files, and someone’s half eaten pimento cheese sandwich.

1:01pm – Consult Digg and Slashdot, while contemplating why anyone uses Perforce.

2:00pm – Remember that people use Perforce because the alternatives are worse. For example, Visual SourceSafe is a service by Microsoft in which they send a salesman to your place of business to kick you in the seat of your pants repeatedly. In the Professional version of SourceSafe, the salesman also steals your credit card and purchases a site license for Microsoft Money.

2:01pm – Attempt to log into the client’s bug database, so I know what to work on. Discover that I do not have access to bugbase, which is on the internal network, because I did not file a business case for why I need it, three years in advance.

2:05pm – Call the client’s IT department, explain that I need network access from my Mac. To avoid getting the wrong software, keep mentioning that I am using a Mac during any awkward silences and anyplace in the conversation a normal person might say something like “hello.” Sensing my urgency, IT promptly sends me five copies of the Windows software.

2:10pm – Call IT department back to explain that need Mac software, to which I am promptly told “We do not support Windows 98.”

2:15pm – Finally reach the one Mac IT person, whom they apparently keep locked in a cage in the basement, and feed old PowerTalk documentation. He cannot send the software via email because of the 32 byte email attachment limit, but he is able to smuggle out a CD of the software, on the back of one of the many fruit bats in his cage.

2:30pm – Discover that VPN software does not reliably connect to client’s network, but does, in fact, waste a large amount of space on my hard drive and not uninstall.

2:31pm – Call IT department again to explain VPN software does not work. IT carefully explains that I must either rewire my apartment, reconfigure my router so that it is solely and permanently connected to their network, or move to California and/or India for VPN to ever work. They are not sure which. Smoke signals are suggested in the interim.

2:45pm – Randomly change settings in the VPN configuration until I can actually connect to the internal network. Discover that although I can connect, I have no security access to any servers on their network, including the bug database. Furthermore, IT has decided that, for reasons of productivity, anyone connected through VPN should not be able to access anything outside their network, such as, for example, the computer sitting right in front of me.

2:56pm – Call IT department to be granted access to the bug database. The IT person that I reach calmly explains that, yes, he can grant me those privileges, but won’t, because he strongly suspects that will allow me to do actual work.

3:03pm – Have my contact within the client company call IT and explain that its OK for me to do work because I do not work in IT.

3:30pm – Feel smug about getting to bill client for all the time IT wasted.

3:31pm – To celebrate victory over IT, Digg and Slashdot.

3:52pm – Examine the first bug I am supposed to fix, which is marked as “severe” and a “crasher.” It states: “When I press Command-Q, the application quits.” I spend the next hour on the phone explain why that is expected behavior. The phone call ends with the quote “Well, that’s stupid and Apple should change it.”

4:52pm – Digg and Slashdot.

5:23pm – Examine the next bug I am supposed to fix. Although it is simply a misspelled word that has been in the software for seven years, it has now become “urgent,” “must fix,” and, “severe.” Oddly enough, the bug was entered by a technical writer.

5:33pm – Open up Xcode, Apple’s integrated development environment, specially designed for the Mac user who has lost the will to live.

5:38pm – Change the resource string to fix the misspelling, which the previous engineer was unable to do, because, apparently, he could not locate the second button on his Macintosh mouse.

5:50pm – UI designer notices that I fixed the misspelling, and suggests other improvements to the wording, such as rewriting the host operating system from scratch to use more color gradients.

6:04pm – While muttering under my breath about out of control UI designers, Digg and Slashdot.

6:45pm – Examine the next bug, which is from a customer, requesting that we add support for XML file formats and the ability to shave an enraged badger. After serious consideration, I decide to defer the bug for next time.

7:02pm – Receive call from marketing demanding to know why XML files/badger-shaving feature was deferred. They cite numerous customer anecdotes in which they needed the portability of an XML file combined with the ability to shave an angry badger. Most cases involve alcohol, in which the badger had consumed prodigious amounts.

7:30pm – Look at code for the first time today.

7:47pm – Marketing calls back saying what the customer probably, really, honestly, truly needed was a way sober up the badger. They swear the badger is a nice guy, but only acts that way when he’s drunk. Plus he has a bad 5 o’clock shadow.

8pm – Receive call from potential client, asking if we could port his Word processor for Windows to the Mac for twenty nine cents and a large portion on his company’s stock, currently held in a gum-ball machine.

8:28pm – Starving, I crawl to the refrigerator, where I discover a veritable treasure trove of food, in the form of Cheerios, underneath the fridge.

9:02pm – Realizing I am spending too much time reading Digg and Slashdot, I go read Dilbert, Get Fuzzy, and Pearls before Swine.

9:18pm – Return to code and marvel at the fact the compiler has not openly mocked the code in iambic pentameter or simply refused to compile it out of principle.

10:07pm – Digg and Slashdot.

10:41pm – iChat with business parter in which we ridicule Xcode’s speed, code quality, and inability to shave an enraged badger who’s had a few too many drinks.

11:11pm – Notice that the auto-complete in Xcode is actually recommending other, more reputable companies I could be working for.

11:38pm – Digg.

12:06pm – Slashdot.

12:49am – Change egregious code “if ( foo ) doFoo();” to the much more sane “if ( foo ) { doFoo(); }”, on the initial thought that I get paid by the character.

1:22am – Discover the entire Xcode help file is one page that recommends using a better IDE, such as MPW.

1:30am – Change the completely erroneous “if ( foo ) { doFoo(); }” to the actually readable “if (foo) {doFoo();}”. Note the bytes saved by the removed whitespace on my accomplishments.

1:40am – In an attempt to find a snippet of code in my project, Xcode inadvertently finds life on Mars. Still unable to search an arbitrary directory in less than ten steps.

1:44am – Change “if (foo) {doFoo();}” to “if ( foo ) doFoo();”, and wonder what fool added the unnecessary braces and removed the spaces.

1:54am – Against doctor’s orders, read old copies of Inside Macintosh, Volume 1 until I fall asleep. He recommended a large mallet to the head, for the reason that it is less likely to cause severe brain trauma.

As you can see, the life of an independent software engineer is not for the faint of heart. No doubt you have more respect for me now than you have ever had before.

Recently I came to the conclusion that I should write about JavaScript menus. Why? Well, the other day I was searching for my name in Google and noticed that the top hits, and most of the hits, were related to mm_menu.js and fw_menu.js. Now I know its bad form to Google for your own name, but trust me, I was provoked. I noticed in my local blog searches people were searching for menu and mm_menu, despite the fact that I have never written about them on this blog. So why were people looking for them here? It turns out the very top of the mm_menu.js file has this:

/**
* mm_menu 20MAR2002 Version 6.0
* Andy Finnell, March 2002
* Copyright © 2000-2002 Macromedia, Inc.

Ah, in those days I was young and foolish. Foolish enough to leave an electronic paper trail back to me. You don’t see me making that mistake again.

I ended up looking at a lot of the sites that referenced mm_menu or fw_menu. They are typically web developer forums. Most the conversations on said forums go like this:

Newbie: I’ve got these mm_menu.js menus, and I want to them to scroll/delay showing/be horizontal/play the harmonica.

Expert (usually Murray): Those menus suck, don’t use them.

Newbie: But I have most of it working already. I don’t want to start over again.

Expert/Murray: Curse you Marcodobia!

The conversation usually goes downhill from there. There’s also the misunderstanding that I own those menus or even created them. One poster suggested that they take up a collection and pay me to add more features. Ha ha! Dude, I like the idea of you giving me money, but not the idea of me coming within ten miles of the menu code.

How did I get involved with this if I’m not the creator of this mess, you ask? *sigh* Well, if you insist on asking me that question, I guess I have answer it.

I was tricked into it, like most things. I had just started on the Fireworks team at Macromedia when they were trying to push out Fireworks 4.0.2, a bugfix release. The JavaScript menu feature had been released in the 4.0 release, and they had a serious bug already. This would have been a warning sign to anyone with experience, but not me. My boss innocently said, “Say Andy, we’ve got this one simple bug in the menus code. Could you take a look at it?” Not realizing that was manager code for “Run! Run like the wind!” I said “Sure” and went to work. It was a bug in Internet Explorer. A bug that started my hate-affair with IE. I managed to get a work around in that didn’t bloat the code too much more than the already 20k it was at. I thought that was the last I’d have to deal with that code. But no. Through the scientific process of “you touched it last, you own it” I now had to maintain it for the rest of my career at Macromedia.

You see, I didn’t even create this mess. It all started with some dude over at Netscape named “Gary.” (Most likely a pseudonym. He probably had enough sense not to leave his real name on anything.) He wrote this JavaScript library that allowed menus to be created on the fly in Netscape 4. Yep. Netscape 4. As the legend goes, towards the end of the Fireworks 4 development cycle, someone decided JavaScript menus would be a great feature for Fireworks, a graphics program, to have. The engineer tasked with this feature didn’t have time to write such a thing himself, so he searched for something to start from. As fate would have it, he found “Gary”‘s JavaScript menus. Noticing that the JavaScript file wasn’t near bloated enough, the engineer added support for Internet Explorer and the then alleged Netscape 6. He managed to get it up to 25 kilobytes. Take that you 14.4kbps modem users.

For reasons now obvious, that engineer quickly fled the company and the state soon after the Fireworks 4 release.

Which left naive little me to deal with them. The next version of Fireworks, MX (Yeah, I know that’s not a version number, but tell it to the marketing guys. They have trouble with numbers vs letters.), was supposed to have many improvements to our hit feature, the JavaScript menus. By “hit feature”, I mean everyone loved them until they figured out how badly they sucked. Fortunately for us, you can’t try out a feature when the CD is still in the box.

Learning how the menus even worked was a huge pain the backside. It was a lot of non-obvious, uncommented code. But I figured it out and added all the features management claimed we needed, and managed to bloat the code by 5k. It was also during this time I realized what a mess it was, and how badly we needed to scrap it and start all over again. I also helped tech support and customers out by telling them how to hack the code to add features we weren’t going to add directly. This was a mistake because, once again, I used my real name.

When we released MX, the customers marveled at how much code I managed to add without really improving anything. The experts complained because the menus were still huge, slow, inaccessible, un-crawlable, and didn’t work if the user had JavaScript turned off. The newbies complained because although all the new features were nice, they just needed one more feature before they were happy.

Al Sparber just laughed his way to the bank. (He sells competing HTML menus.)

For the next release there were murmuring of adding even more features. That’s when I pulled the engineer trump card and told them that new features couldn’t be implemented unless the menus were rewritten. That thoroughly killed menu work for the MX 2004 release. I began internally campaigning to have a new set of HTML/CSS menus created (there were lots of examples of these popping up externally).

There was a lot of internal movement between the MX 2004 and 8 release of Fireworks. I used that time to write a new version of the menus using HTML and CSS with a little bit of JavaScript. I cleverly substituted bloated JavaScript for bloated CSS. heh heh. That’ll show those experts. This was about the time I got moved off to Dreamweaver, and my good friend Mike ended up finishing up the feature (after it was killed, then brought back, then killed again, went on tour with the Stones, then finally revived.).

On the Dreamweaver side, we astutely decided not to support these new fangled menus, but still allowed the old kind to be created. This, of course, was heralded as a “Great Idea” by our advisors. No, just kidding, they hated it and called us names. Being the agile company that we were, we quickly had lots of emergency meetings and promptly decided not to do anything. That’s how Dreamweaver 8 shipped.

After Dreamweaver 8 shipped I left the company, and my involvement with those accursed menus ended.

Of course, none of this helps those of you suckered into using these menus. So for your benefit, I’ll now tell you how to fix the mm_menu.js. Follow these simple instructions:

1. Acquire one (1) shotgun. Loaded, preferably.
2. Acquire one (1) shovel.
3. Pump mm_menu.js full of buckshot until you feel better.
4. Repeat Step 3 as necessary or desired.
5. With the shovel, dig a hole.
6. Dump the remains of mm_menu.js into the hole.

If you’re confused on how to shoot an electronic file, I would suggest printing it out and shooting the printout. Sure, you could shoot the real thing off the hard drive, but you might have trouble determining if you hit the actual sectors the file resides on. Also, there might be economic and/or legal repercussions if you shot the hard drive.

So don’t use mm_menu or fw_menu. Go find one of the many HTML/CSS menus that are out there. Some are even free. You could even go buy one off Al Sparber. Tell him I sent you. For the number of people I’ve driven to his door by agreeing to maintain the JavaScript menus, he ought to give you some sort of discount.

Or perhaps he would just laugh maniacally at you and double the price.

Sorry about the title, I couldn’t resist. All the unnecessary sensationalism makes me feel like a real journalist! Will your porting kit kill you?? Find out at 11 (10 Central)!

Well, theoretically it could. You could be in the middle of a Doom-a-thon when a bug in the porting kit locks up your client, and your ex-best-friend frags you.

Tragic. Just tragic.

Anyway, this new fangled product from TransGaming, Cider, has me interested. From the article over at The Mac Observer it sounds like it uses an “emulation” approach to porting to the Mac.

Its interesting to me because, in my experience, attempting to “emulate” one platform API with another is pretty much the worst way to port anything. The API’s of Mac and Windows aren’t a one to one match, and some comparable technologies have vastly different architectures. That means trying to emulate a Windows API on the Mac might prove to be very difficult (i.e. the Windows model might assume polling, while the Mac model might assume callbacks). It also means trying to emulate certain API’s on another platform might be slow or inefficient. And that’s bad in a game, or so I am told.

Although I have to admit, by limiting the porting kit to games they dodge some of the bullets fired by using the “emulation” approach. Namely, all the UI differences on Mac vs Windows. Games usually have a totally custom UI that is unique to the game, not to the platform. So the porting kit doesn’t have to worry about Windows icons not looking right on the Mac, or controls that exist on one platform, but not the other, or menu items being in the wrong place. Its all custom, so it doesn’t matter.

By limiting the kit to games, it also means they can concentrate on certain API’s. From the Cider FAQ:

TransGaming’s Cider implements common multimedia Windows APIs such as Direct3D, DirectInput, DirectSound and many others by mapping them to Mac equivalents.

Games will probably focus on DirectX and graphics API’s, and probably not so much on, say, CD burning API’s. Which means Cider’s decision to focus on multimedia API’s was a wise one, in a bang for the buck sense.

Of course, if not all the API’s are implemented, what are your options if your product uses one that’s not supported? Well, you could change your Windows’ code to use a different, supported API. But that’s no fun, and may not even be feasible. You could also just switch directly to using Mac API’s and #ifdef your code based on platform. But that means you don’t get one codebase, which is one of the things TransGaming touts. It doesn’t sound like you’ll actually get the source to Cider, so implementing the Windows API on the Mac might not be an option. From the Cider FAQ:

Cider works by directly loading a Windows program into memory on an Intel-Mac and linking it to an optimized version of the Win32 APIs.

It certainly sounds like they’re handing you a DLL you link in, and you pray that they implemented all the right API’s, and in the right way. If you were depending on an obscure side effect (in a Win32 API? Never!), and they didn’t implement it, you’re kind of screwed. Or if, heaven forbid, there was a bug in their implementation. Of course, TransGaming might fix it for you, for the right price.

If they’re handing you a black box DLL, I wonder how big it will be. In my experience, “emulation” porting layers tend to be pretty thick as far as code goes, so it could be a large DLL. If you have the source code you could hand optimize out the functions you don’t need, or even let the linker do that for you. I doubt TransGaming would like to be giving .NET a run for its money in terms of download size.

The other interesting thing about Cider is that it seems to be derived indirectly from WINE. From the Mac Observer article:

Cider shares the same core technology as Cedega, which has its roots in WINE but branched from that technology in 2002.

This is interesting because WINE is covered under the LGPL. I know LGPL isn’t as strict as the regular GPL, but doesn’t it still mean someone should be opening up their source? I also wonder about the legal implications of the ported game. Perhaps I should leave that question to the GPL experts and to the law talking guys.

Although Cider might surprise me, it doesn’t sound like its all its cracked up to be. Emulating an API is a poor way to port an application to a platform, even for a game. I truly wonder if they can pull off the performance they say they can. I also wonder how many games will be ported as easily as they imply:

TransGaming works with the game developers and publishers to optimize the game for Intel Mac but this process takes hours to a mere few days.

That prediction only seems plausible if the game is using the API’s that Cider supports. If not, then things will take a lot longer. They also seem to be forgetting about testing. The Cider porting kit isn’t Windows, even if its trying real hard to be. The game code might be the same, but the OS/porting kit code isn’t. You’ll have to spend time testing on the Mac as well.

Of course, this doesn’t keep their Founder/CTO, Mr. State, from being cocky. From the Mac Observer article:

Mr. State said: “We imagine that they[the traditional porting companies] are re-evaluating their business models. Our technology does revolutionize how games are brought to the Mac, which we believe will result in a paradigm shift in the Mac game publishing landscape.”

I don’t know Mr. State. I’ve used and maintained “emulation” porting kits before, and even with the source they’re very hard to make work, and make work well. I don’t think anyone is re-evaluating their business model until Cider is proven.

Spotlight has to be one of the most unused technologies on my computer. Its not that I don’t need it — I need to search for things all the time. Its not that the idea behind Spotlight isn’t sound, it is. It makes a lot of sense to index files and make them available for a quick search.

The problem is it doesn’t work.

First, its slower than Christmas in Tehran on my machine. I’m not talking about the “indexing” time that I see a lot of people complaining about. I actually rarely see it indexing. However, on the off chance I try to do a search, it brings my machine to its knees, and its a Dual 2 Ghz G5 with a gig of RAM. The Finder locks up until the search is done and sometimes the disk activity it generates is so intense my whole machine locks up temporarily. I would assume its just this machine, but it happens on my PowerBook and my iMac/Intel as well.

I don’t get it. It always works for Steve.

And Lord help you if you use that stupid widget in the top right of your screen. Good grief. You’d better hope that the ten results it happens to show there are what you’re looking for (and they’re not), otherwise you have to open a real Spotlight window to get all the results. That means Spotlight has to run the entire query all over again, disk thrashing and all. Its the model of efficiency, that Spotlight.

The other thing that’s wrong with search in general is it just tells you that your search term is somewhere in a given file. There ought to be a way to then double click on the search result and have the application open up to where the search result is. But perhaps that’s just a distant dream.

Of course, the only reason I even tried Spotlight is because Xcode search sucks so badly. It only wants to search the current project, and even then only the files in the actual project (not included files). Sure, Apple has added all kinds of options to the Find dialog, and maybe one day they’ll add one that makes it useful. Until then, searching an arbitrary folder is one of the most painful experiences within Xcode (and there are a lot). Here’s what you have to do in Xcode:

1. Command-Shift-F to open the Find in Files dialog.
2. Press the “Options” button to get the Find Options dialog. (Why are these in a separate dialog?!?)
3. So you don’t overwrite one of Apple’s precious predefined sets, press the “Add” button.
4. Type in a name for your set and hit enter.
5. Press the + button at the bottom and add the folder you want to search. (Also remove any left over folders from previous sets you don’t want.)
6. Check the “Search in files and folders” box. (Why do I have check this? I just added a folder, isn’t it obvious what I want to do??)
7. Uncheck “Search in open documents” and “Search in open projects.”
8. Close the Find Options dialog and/or go back the Find dialog.
9. Select your new Find set from the set popup.
10. Type in the search term(s) you want to find, and press return.

Yes, in those short ten steps, you too can search for something in an arbitrary folder!

The problem is these stupid find sets that I have to create are there to increase flexibility. Undoubtedly, the engineer who created that whole mess thought “Think of the power and flexibility I’m giving the user! They can search for anything in any way they want! Having them save find sets means all the find options are nicely encapsulated!” But the problem is I don’t want flexibility, I want speed. And I don’t mean raw search speed, I mean speed of entering in my search criteria and having Xcode find it. When I’m looking for something, I’m in a hurry. I don’t have time to create one of your stupid Find sets, as architecturally nice as they might be. I’m sorry, ten steps to do anything is too many.

At the very least Apple should merge all the options into the Find dialog. And don’t force me to create a stupid find set. They could also add a default set that searches $SRC_ROOT.

The truth is I still keep CodeWarrior around, just so I can use its Find in Files dialog. It has a nice popup of all the previously searched in folders, or text field I can type the path into, or a browse button which I can use to go select the folder I want, all from the Find dialog. Apple, if you want to know how to make a decent search, look no further than CodeWarrior.

I hate searching on my Mac. Granted, I don’t have a dog asking me retarded questions, but its always a painful ordeal. It doesn’t have to be. The technology is there, but they need to run it through some usability specialists or at least a couple of real users.

Looking for an easy way to increase traffic to your website? Simply follow one or more of these steps to see a dramatic change in your hits!

1. Pretend that you are expert of some kind, and write a blog entry on how to increase traffic to your blog. The fact that your girlfriend is the only one who reads your blog is immaterial.
2. Find a colorful, festive way to off yourself. In your will, nominate yourself for a Darwin Award. Be sure to include the URL to your blog in your nomination (you won’t believe how many people forget that part).
3. Attempt some sort of criminal activity in which you are embarrassingly foiled by someone who wears diapers. For example, being beaten senseless with dentures wielded by a 93 year old man in a wheelchair, whom you were trying to mug. When being put into the police car, yell out the URL for your blog. Fark will pick the story up immediately.
4. Per Wil Shipley, simply add the phrase “Kyle orton drunk”, and you will be rolling in hits.
5. In the late 90′s start a blog with an obscure, technical name. Post links to technical news, anime, and other geekery. Later, the unemployed and/or students who love Linux and not paying for stuff you might be advertising, will flock to your site and remove any value it might have had.
6. Create a blog with a name that’s a derivative of a curse word. Until you have actual content to put up, use a placeholder that is a picture of a squirrel with a peculiar glandular problem. Later, post links about criminals getting beaten up by 93 year olds in wheelchairs.
7. Read the hundreds of posts on how to increase traffic to your site, and determine that that’s too much work. Instead, write about what your cat, Mittens, threw up this morning. Despite the odds, cat lovers will flock to your site, eager to tell you how cute that is, and what their cat just left in the litter-box.
8. Browse over to Dave Barry’s blog to get ideas. Think, “I could have a much better haircut than that!” Scoff at his writing since he retired. Pretend that its your blog.
9. Find a way to insult Muslims and/or the Koran, such as drawing a cartoon. Have a well-known cleric declare a jihad on you. In a press release, mention your exact location will be posted daily on your blog. Watch the death threats, erm traffic, roll in.
10. Write an article on how this will be “The Year of Linux” and how much better it will be than Windows. Be sure to abbreviate Microsoft as M$ a lot. Post it where the unemployed and/or students can find it. Prepare to be slashdotted.

Some of these might even be legal in your state!