Stevi’s Tech Journal

So far jEdit seems like a nice little open source app, but I’m finding the documentation less then useful. I’m going to try to document the little tricks I had to find through searching the various boards and whatnot that turn out to be critical “You must do this” things to make it work.

Thing the first: getting the Plugin Manager to work.

When I first downloaded jEdit and tried to use the Plugin Manager, it would say it was downloading the plugins, then say it couldn’t open the zip files. After poking around I finally discovered the source of the problem. You’re supposed to know that before you can use Plugin Manager, you must select your preferred download mirror. From the Plugin Manager window, click “Download Options,” Select “Plugin Manager” from the jEdit tree, then click “Update Mirror List.” Select a mirror, then click “Apply” or “OK.” After doing this, I was able to download my Plugins with no problem.

Next necessary piece of configuration involves using JCompiler. From the “Manage” tab on the Plugin Manager window, click “Plugin Options.” Select the “Java Core” node on the Plugins directory on the left. The first option should be “Preferred service for classpath and sourcepath:” , select “JCompiler” from the dropdown. Once you do this, you should be able to use JCompiler to compile your apps from jEdit.

it occurred to me this would be a nice place for me to put all the stuff i have recently learned and/or have to look up every time i have to use it. so today’s topic is types of tree traversals and why i care.

there are three by-depth orders in which to walk a tree: preorder, postorder, and inorder. all three rely on recursive algorithms to implement.

in preorder, each node is visited before any children. a simple example of why you would do this is to create a graphical representation of the tree itself.

in postorder, each node is visited after all of its children. an example would be deleting all empty folders from a directory. if a directory contains only empty directories, you would want to remove those empty directories first before deciding it was empty. postorder allows you to do this more efficiently.

in inorder, you visit each node after traversing its left subtree and before its right subtree. this is the common way of traversing a binary search tree or any other application where you have an ordered tree that you want to search or display in order.

we have a corporate “spam firewall” that occasionally sends messages letting us know what files got caught so we can confirm or deny.

in today’s message, i note it helpfully shielded me from all the critical system down notifications from yesterday and an account notice from the company we outsourced our stock purchase plan to about my benefit.

i clicked the link to “whitelist” these emails, only to have Outlook tell me it has identified the message as a security risk and has helpfully turned off all the links to protect me from myself.

if only outlook had identified the message from the spam blocker as spam - that would have really made me happy.

i find myself tasked with creating my team’s exception handling strategy.

in doing some research, i’ve had one of those “you mean i’ve been doing it wrong all these years?” type epiphanies.

i’ve always been the sort who writes the most rock solid, fault tolerant code i can. i check parameters obsessively, even in private methods. i make business owners crazy with my questions of “what if this obscure possible event happens” (and then they thank me when it does, thankyewverymuch, or are surprised when someone else’s code didn’t predict the future the way mine always seemed to.).

most of the other developers on my team come from the other side - if it compiles and works the first time, it’s fine until it breaks. both approaches have their cons. their code breaks more than mine. but they get stuff “done” a lot faster. i’ll let you guess who management likes better.

in the process of moving from the procedural world to object oriented program, i discovered try-catch-finally and exception handling, i was put under the impression that one should discover all possible exceptions, catch them all, and when all else fails, catch the general exception and do something with it. and heaven forfend that i actually intentionally throw an exception! that’s madness!

well, i may be changing my mind.

for context, i’ve been sucked into Microsoft.NET Framework programming. and for all my wailing and gnashing of teeth, it’s not all that intolerably horrible. of course, i was stuck in Java before this, so drawn your own conclusions. oh, what, you guessed that from my obsessive attitude towards catching exceptions?

anyway, i stumbled upon Jeffrey Richter’s Applied Microsoft .NET Framework Programming, where he makes the point, “After all, an exception is simply a violation of a programming interface’s assumptions.”

which made me realize how often i’ve bent over backwards to handle situations where, for example, i just want a simple method to return true or false…but i may need to know if something failed. but i’m not allowed to throw an exception, because that’s BAD. so i just return false. and then later i spend forever stepping through code with the debugger trying to figure out where something’s failing, only to discover that it’s because some piece of data 15 layers deep isn’t properly associated with another one, and the method that needs to know is hiding that from me by quietly returning “FALSE” when really it should say “HEY THE DATA IS BORKED!” since the vast majority of what i do is getting data from a database and deciding what to do with it, this happens a lot.

so now i finally realize the power of exceptions. i will throw exceptions whenever it damn well suits me. i will do it with pride. exceptions are my friend!

because i’m not far enough behind in everything iwant to do with my life, i have spent an obscene amount of time on a new, pointless personal project: analyzing peruvian paso horse studbook data.

the following will probably give real statisticians apoplexy, but for anyone who is curious what could possibly be of interest in a studbook, i’ve created the following reports:

NAPHA studbook analysis

it is astonishing the things you take for granted as simple and intuitive that experience will demonstrate are far beyond the grasp of mere end users.

one of the apps i wrote generates a “proof of purchase” code. this code is emailed to the purchaser, who then follows the link in the email, follows the directions to find the place to enter the code to complete the purchase process. it’s all electronic. you copy and paste the code from the email to the page, and bob’s your uncle.

i have now sent my fourth (FOURTH!) email in response to desperate pleas from customer service explaining that the reason customer X cannot redeem a particular POP code is that customer X has apparently decided that certain characters in the POP code are optional, and has continued to type the code into the little box without them.

this case has been escalated to RED HOT THE WORLD IS ENDING BECAUSE THE CUSTOMER CANNOT COMPLETE THE PROCESS THE INTARWEB IS BORKED!!@!.

i told them how the customer can fix the problem the same day he reported it. cut and paste. that’s all.

now, whether the customer managed to contact customer service but not supply a return email address that works, or that he checks, or if customer service cannot manage to translate my mighty application developer speak (”he needs to enter the code in exactly as it appears in the email, or perhaps just cut and paste it”) into something the customer understands, i don’t know.

but why the customer hasn’t bothered, in all this time, to experiment by just cutting and pasting is beyond me.

mind you, these are higher end products, targetted at the VAR and IT sysadmin market.

i weep for the children.

when it takes over an hour to regenerate the entire data set in the application you’re creating, you should either back up the data set before the data manipulation phase, or establish a much smaller testing universe.

maybe i don’t need to create and manipulate all 35,000 horses for testing purposes. maybe, you know, just a few.