Horace called him “your friend with the eye shadow”, and it clicked for me. The ancient Egyptians use kohl around their eyes. There have been hieroglyphics around since the hatch timer.

Richard Alpert’s initials are RA. To quote the old fortunes program:

Ra is the sun god!
He is a fun god!
Ra Ra Ra!

The revelations in the season finale seem to point in a different direction.

Surprisingly, Jughead refuted the main evidence that Richard had traveled through time.

I just wanted to get on “the record” in case I’m actually right.

There are also methods with capital letter. I keep confusing them with constructors. I can deal (barely) with irregular formatting and spacing. How hard is “space after keyword” to remember anyway?

These non-standard names are freaking me out!

git also has lots of ways to change what was checked in. I fear those commands!

Often when I’m fixing a bug, I find a few more too. Darcs lets me check in each of the fixes separately which give me a better change history.

I can do this with other SCMs, but it’s a lot of hoop jumping. I have to copy the fixed file somewhere, revert the working copy and then copy each of the fixes back into the working copy and check each change in. (I find ediff in valuable for this. It’s worth using emacs just for that one feature.)

Darcs just naturally fits my working style. I also have a tendency to make other changes while I’m editing, and sometimes work on more thing at a time.

Git users say that it operates on content, not files, but it appears that I can only commit a file. (I haven’t explored git very much). None of the other popular distributed SCM programs seem to have that kind of feature. Maybe “cherry picking” is close, but that seems to come after a commit.

Maybe darcs “theory of patches” is unique. And given the plethora of ways to get different SCM systems to interconnect, I can likely use darcs locally whatever the originating system is. This lets me work on various open source software using different repositories. The best of both worlds?

I was making a web app to manage database information, and I decided to use a modern web framework to make myself “more productive”. Ha! They all seemed to use hibernate. I eventually decided to use Grails.

I also decided to use Annotations to handle the data descriptions. The JBoss Tools had hibernate support, and WST (I think) had JPA support. The first annoying part was that Eclipse expects you to create a new project to get JPA or hibernate support. I ended up merge .project files to get support for both.

The JPA tools are marked 1.0, but I don’t think they are ready for prime time. I got a lot of null pointer errors, but never got a backtrace in the error dialog to help me figure out what might be the problem. I got lots of “persistence.xml not found” errors. I move the persistence.xml file to various places in the project with no success. Eventually I edited the file with vi and discovered that it didn’t end with a newline. Adding one at least made it loadable. I never did get anything in my database.

Hibernate3 also supported use of annoations, but I never could put all of the pieces together correctly. The documentation was pretty patchy, odd things happened, and the error messages cryptic. I never found a single location for the hibernate.cfg.xml that made Eclipse, Maven and runtime happy.

I should have switched back to the older hibernate methods, but I was too stubborn. I wanted make it work the shiny new way at any cost, but it soon reached the point where it didn’t matter any more. Sometimes stubborness and persistence are good; sometimes it’s a character flaw.

The combination of a newbie and imperfect tools and documentation made me shoot myself in the foot. Next time, I’ll quit hitting my head against the brick wall earlier. I hope.

This “Beautiful Code” example about a regex matcher in Haskell was very instructive, but I agree with one of the comments about variable name. Almost every example of Haskell I see uses mostly single character values a,b,n,m,x,y. Sometime they use two letters: xs ys. I know that Haskell comes from a mathematical background, but I believe that it’s widely accepted that good variable names make code easier to understand. head:tail instead of x:xs. Even car:cdr is slightly better. They do care about good function names, but don’t apply the same logic to variable names.

They apparently really program that way, look at the code in the standard prelude. Not all Haskell code is like this, the Hitchiker’s Guide for example. It’s almost like the old saying “it was hard to write, it should be hard to read”. I sort of believed that in the 80s when I was writing C code, and it took me a long time to get over it. Hey, *p++ = *s++ looked cool!

If you’re evangelizing, using good variable names make the code look better, and less scary. And maybe change a few more minds.

Then again, I remember when it was Kentucky Fried Chicken…

One of the lists was was the top 25 worst rapper names. This morning on the way to work I walked past a poster for local concert by number 10, Del The Funky Homosapien. He’s changed the spelling from funkee to funky, but it’s him.

Wierd. Doesn’t mean anything though.