Coding in the Clink VI is over!

Coding in the Clink V was quite some time ago.  We had a fairly long hiatus this time first because CITC6 should have happened right around Christmas, but it was tough to find folks who could make it then, and second because there was kind of an administration shakeup that affected the JavaGuys.

But we got that all taken care of and held CITC6 yesterday.

For the first time, I “sold” more tickets on Eventbrite (they’re free) than there were prisoners available to attend, because in the past there have almost always been a few dropouts.  It worked out perfectly.  Nine prisoners were available; I “sold” 11 tickets.  Three outside developers and one prisoner dropped out, so we had eight on each side.

Actually, one of the prisoners was delayed getting to the event and wasn’t able to participate in the first round, so another prisoner tripled with two outside developers, both of whom just happened to be female.

I’ll bet he enjoyed that.

Speaking of female developers, we had three this time, which is more than we’ve ever had in the past.  Amber Conville is a regular, but we attracted Gabbie Gibson and Kelsey Shannahan this time too.  Angela Harms was planning to show up too, but she and her husband Tracy had to drop out at the last moment because of a family emergency.

Here is the list of outside attendees; click the links to read their own blogs about CITC6.

From the inside, we had

  • Steve Crotts
  • Lee Leonard
  • Gene Lynn
  • Louis Pierce
  • Darrin Pordash
  • Mark Roberts
  • Ron Tracy
  • David Travis

(Sorry, I won’t be able to link directly to any of their blogs.)

Up until now, each of the CITC events has been very close to Corey Haines’ Code Retreat concept, with a couple of minor modifications—namely, we’ve always used Java exclusively, we’ve usually used problems other than Conway’s Game of Life, and, as Jeff pointed out, our culinary options in prison are somewhat more limited than they are outside.

But after each CITC, and especially after CITC5, there has been a growing desire among the prisoners to try a CITC where we don’t throw the code away at the end of each cycle, but leave it for the next pair to work on.  Continually coming up with new approaches to the problem is not bad, but extending somebody else’s solution is a lot closer to what these fellows are going to encounter in the real world of work.

(Of course, the reason you go to a real Corey Haines-style Code Retreat is not to simulate the real world as closely as possible, but to escape from it as far as possible.  That’s why it’s called a Retreat.)

So we tried it to see what it would be like, provisionally, with the understanding that if after the second cycle we hated it, we’d go back to starting over each cycle.

I figured we needed a problem a little bigger than Conway if we were going to spend several cycles on it, so I chose a form of the African children’s game of Mancala.  (You can play it here if you like, except that our game started with three markers in each pit instead of four.)  The specific problem was to accept a representation of a Mancala board at some mid-game point, and the specification of a move to be made, and determine what the Mancala board would look like after the move had been made.  (Since I didn’t know how far we’d get on the problem, I also wanted to know whether that move ended the game and, if not, which player had the next move.)

It turns out that Mancala is an excellent problem for emergent design, because you can start out with an extremely simple concept, but exceptions are continually creeping in and causing you to refactor your design, so that you have to keep it lightweight and bouncy or else you’ll either A) spend all your time providing for the exception-ridden future and never get any real work done, or B) find yourself with no way that you can possibly hack the next exception into the horrible mess you’re working on in a 45-minute cycle.

For example:

  • The board is just a circular buffer of pits—except that two of them (the mancalas) are special.
  • A move is just a dead-simple sowing process—except when you turn a corner onto the other side.
  • Turning a corner onto the other side isn’t that complicated—except when you turn the corner back onto your side and have to skip the opponent’s mancala.
  • Remembering the last pit of a move is easy—except that the fact that you don’t sow stones in the opponent’s mancala can screw it up.
  • Determining the next player to move is easy—except that a bonus move lets the same player move again.

In fact, I may lobby to see if I can get the guys to agree to using Mancala for CITC7 as well.  (Especially, come to think of it, since I have a voice commitment for CITC7 from a real African, Frank Gbenah of Pillar Technology.)

We agreed to the following rules: Pick a different pair partner for every cycle but the last.  Every cycle, pick a computer that neither of you worked on during the immediately previous cycle (but going back to a machine you were on cycle before last or earlier is okay).  For the final cycle, return to the pair partner and the machine you had for the first cycle, just to see what happened to the design you started.  (This last rule cropped up out of nowhere just before the last cycle, but I thought it proved to be a good idea.)

So for the first cycle, I paired with Louis Pierce, and convinced him to try to come up with a functional approach to the problem: you know, an immutable Board class, composed of immutable Sections—two of them, one for each player—consisting of six immutable Pits and an immutable Mancala.  The top-level function would take a Board, a player number, and a pit number, and would return a MoveResult object containing a new Board, a flag saying whether the game was over, and the number of the next player to move.

We weren’t really FP wizards, though, and Java isn’t a particularly functional language, so we managed to get something with only some mutable state started.  (If I remember, the Board was immutable, and you couldn’t get at the Sections to mutate them once they were in the Board, but you created the Sections empty and mutated them until they had the numbers of stones you wanted where you wanted them, then created a Board from them.)  But it wasn’t that bad, because from the outside you couldn’t see the mutable state.


Our story test drove us to write a Mancala class with two static methods: startGame(), which returned an initialized Board (three stones in each pit), and move(board, player, pit), which returned a MoveResult.

Then came the all-important second cycle.  This was the first one where we would encounter somebody else’s code.  Would we decide to keep the code again for the third cycle, or would we recoil in horror and decide to throw it out?

I might be misremembering, but I think my second cycle was paired with Steve Crotts on a codebase where the authors had decided to represent the board as a 14-element List<Integer>, where elements 7 and 14 were treated specially, and it appeared that you were supposed to be able to address pits like “Player 2, pit 10,000” and have that translated into the index of the list element Player 2 would encounter if he started with his first pit and went around and around the board for 9,999 pits.


Unfortunately, a 14-element list doesn’t have any element 14 to treat specially, so we had to figure out how the tests could possibly be passing for code like that (it wound up looking an awful lot like the test had been substantially copied from the code, so both had the same defect), and the code to translate virtual pit 10,000 to real pit whatever was fiendishly complicated and broken.

So we spent the entire cycle writing tests to expose the problems and fixing them, and so didn’t get any actual additional functionality added that cycle.  Even at the end of the cycle, we hadn’t addressed the skip-your-opponent’s-mancala issue.

The cycle retrospective was interesting.  If I remember correctly, there was only one positive remark about the code encountered: DJ Daugherty said he’d been really impressed by the code left behind by Mark Roberts and Jesse Cox.  Everybody else seemed to have spent the cycle improving the code they found.  Only one pair admitted to completely horsing the encountered design around to something they found more palatable.  However, perhaps because everybody thought they had been able to make things better, there were no objections to continuing to extend existing code, so we decided to keep the code for the third cycle as well.

And so it went, through a total of six cycles.  That means everybody had five pair partners, because the first and last were the same.  Let’s see if I can remember mine: Louis Pierce, Steve Crotts, Darrin Pordash, Ron Tracy, and David Travis.  Yup.

We discovered that the code quality, in all our opinions, was nearly monotonically increasing over the whole day from the second cycle to the sixth.  (Of course, almost everybody thought the code they encountered on the second cycle was worse than the code they wrote on the first cycle, probably because it looked nothing like the solution they’d had in mind.)  This flies in the face of the accepted maxim that the quality of a piece of code is inversely proportional to the number of hands that have touched it.

At the beginning of one cycle, we encountered a badly-broken suite of tests and a comment:  “GOOD LUCK :) We were in the middle of refactoring all this into the Game class when time ran out.”  I was disheartened; but then I was surprised to discover how easy it was for us to figure out what the previous pair had been doing and complete it.  I wish I had saved that code to look at later: I’m pretty sure that if I were interrupted in the middle of a sizable refactoring myself, my successor wouldn’t have nearly as easy a time as that figuring out what had been in my head, and a cheerful smiley comment wouldn’t have helped.

For the last cycle, I rejoined Louis and we went back to the partially-functional code we’d started, hoping that somebody had been able to rescue it.

Well, no, not so much, as it happened.  It was now completely imperative from top to bottom.  The Mancala class was still there, and it still had the startGame() method in it, but the move() method was now on Board, where all the state was now mutable, and Mancala had been filled with a bunch of static utility methods.  The StoryTest class had a number of unit tests in it.

The moral of this story, I guess, is that if you want code to be functional, you’d better dang well make it functional, because nobody else is going to.

That last cycle both Louis and I were really beginning to fade after a day of hard programming, so we didn’t get much done except mostly implementing the capture move.  We wrote a test for the implementation, and then wrote the implementation using a getOpposingPit() method that didn’t exist.  We didn’t have time to drive out the getOpposingPit() method before the end of the cycle, but other than that, our suspicion was that the problem was pretty much complete.

Consensus after the last cycle was that everybody had great fun, and it was definitely something that everybody wanted to do again.  Given that there were five brand-new outside developers this time, and at least two more brand-new folks who said they’d really like to be on 7, we might have the first real race for tickets on CITC7.  We’ll see.

Afterwards, Ravi had to head home for a family celebration, but the rest of us ended up at Bob Evans in Marion, where we closed out the day with a lot of good discussion, good food, and good service from Jess the waitress.

It’s a terrific experience, and one I’d highly recommend to any developer in the greater central Ohio area (Amber and Jeff come down from Michigan, even).  As DJ Daugherty said, “After awhile, I simply forgot I was in prison.”

What You Have To Know To Code in the Clink

If you want to come to a Coding in the Clink event, here’s what you need to know.

Q.  Are we going to be there over lunch?  In prison?  Maybe I should tell you what I’ve heard about prison food.

A. We’re pretty much leaving that to the guys inside to arrange. For the CITC #1, we ate in the prison chow hall with our guys and hundreds of other prisoners. It was only the third time I had eaten prison food. It wasn’t four-star, but it wasn’t nearly as bad as I had expected–and it was an adventure. For CITC #2, the Amvets donated enough money to get us each a fairly soupy but substantial submarine sandwich in Saran Wrap, which we could eat as we continued to code: that turned out to be the best part. The third time, we ate in the chow hall again, and again it was fine. This time? I don’t know yet. Let Dan know if you have dietary restrictions.

Q. But whatever will we do after Coding?

A. Tradition is to troop over to Bob Evans (about two miles south) and retrospect, although it’s also common for folks who have to get back to wherever they came from to skip Bob Evans and head on back.

Q. Where does all this happen, anyway?

A. The address is: 940 Marion-Williamsport Road Marion, Ohio 43302 The website is: The Google Maps satellite photo is:,-83.106707&spn=0.001012,0.002092&t=h&z=19 The directions from US 23 are: There are four Marion exits: you want the second-to-northernmost one, to Marion-Williamsport Road. (There’ll be a white-on-green highway sign saying “Marion Correctional Institution,” whether you’re coming from the north or from the south.) You go west (right, regardless of whether you come from north or south) on Marion-Williamsport Road, away from the airport; you’ll want the second prison on the right. (There are four of them on that road.) Turn right into the entrance just before you pass the Marion County Sheriff’s station on the left. Park in the visitor’s lot to the right, LOCK YOUR CAR, and go into the A building, which is the only one that sticks through the fence. (Don’t be seen examining the fence too closely: it makes folks nervous. Folks with guns.) Note: when you leave, you’ll have to turn left (north) onto the US 23 entrance ramp regardless of whether you’re going north or south. If you’re going south, turn before you cross the highway; if you’re going north, cross the highway before you turn.

Q. What’s the problem we’ll be working on?

A. We’ll be implementing a version of the dart game Cricket (which is not like the ball game cricket). History: for CITC #1, we did Conway’s Game of Life. For #2, we did Tic-Tac-Toe. For #3, we scored tennis. For #4, we played Dots. For #5, we deduced the order of a series of things from statements about their relationships to each other.  For #6, we coded Mancala.  For #7, we solved two-dimensional mazes. For #8, we wrote a version of the game Morabaraba. For #9, we tried our hand at George Walters’ and Guy Royse’s Evercraft kata. For #10, we worked a version of the classic Traveling Salesman problem from computer science.

Q. What programming language will we be working in?

A. Java and JavaScript. Not Scala, not Clojure (darn!), not Ruby, not Erlang, not Visual Foxpro. Why Java? Click the link.

Q. Prison? Prison?! But…but…

A. Things to Remember About Volunteering in Prison:

Probably the first thing you need to know is that you’ll need a government picture ID to get past the A building. For most people, that’s a driver’s license. Please make sure you bring it–especially if you’re coming from some distance away–else you’ll be sitting in the A building all day while the rest of us are inside.

Second, don’t bring in anything except the clothes on your back, your government picture ID, and your car key if you’re driving. No money, no drugs, no candy, no cough drops, no laptop, and especially no cell phone or anything else with a radio transmitter.  (If for some reason you have to bring in one or more of those items, talk to Dan far enough ahead of time that he can negotiate with the prison for you.) Nothing to give to an inmate: that could get him sent to the Hole and you instantly ejected if not arrested. (If you have something you want to make available to a prisoner, there may well be ways of doing it; but just handing it to him isn’t one of them. Talk to Dan about it.) Dan’s advice: put all that stuff in the trunk of the car you’re riding in.  And oh yes, one more thing: if you forget and leave something in your car, or if you forget to leave something in your car, and have to go back out to the parking lot, then walk, don’t run.  Even if everybody else is waiting on you: walk.  Running near a prison–especially away from a prison–tends to attract a lot of attention, and it’s all very much the wrong kind of attention.

Third, don’t accept anything from an inmate to bring out of the prison. Obviously, this includes a note saying, “The northwest corner of the fence will be unobserved at 2:20am; meet us there with the guns,” but less obviously, it also includes a handmade thank-you card expressing gratitude for your participation or a message to a prisoner’s mother that he loves her. The prisoners know this rule better than you do, and mostly you won’t have trouble with the fellows who are Coding in the Clink; but if somebody asks you to take something out for him, tell him, “I’ll do whatever I can to help; let me talk to Dan real quick.” (Probably he’ll say, “Oh–ah–don’t worry about it then, I’m good, never mind.”)

Fourth, don’t go anywhere outside the six-room Lifeline complex where we’ll be holding the Code Retreat (for example, to the bathroom) without an escort. Precisely what “escort” means will vary depending on what your destination is, but it will never mean “prisoner.” Even inside the Lifeline complex, don’t work things so that you’re the only outside person in a room, whether or not that room has prisoners in it.  Get somebody else from the outside to come with you. If you have to go to the bathroom, let Dan know and he’ll arrange things. If you have to leave the prison early, you’ll need to wait for a correctional officer to escort you, and that could take awhile. If you need to leave early, and you need to be out at a specific time, it’s best to let folks know as early as possible so that things can be arranged ahead of time.

Fifth, it’s “correctional officer” or “CO,” not “guard.” I had a CO tell me once, “Guards are people who prevent inanimate objects from being stolen. Our job is to keep you in the community safe from prisoners and to keep prisoners safe from each other.” There’s no prison rule that you have to be courteous to COs, but it’s important to remember, if we want to keep doing this, that our presence as outsiders in the prison makes their job considerably more difficult than it would be without us. To the extent courtesy can serve to mitigate that difficulty, it’s highly recommended. Nod, smile, say “Good morning!” Be pleasant. There is, however, a prison rule that you have to obey COs. If a CO tells you to do something, do it without question or challenge. If he’s wearing a white shirt instead of a gray one, it means he’s not a CO, he’s a sergeant or a lieutenant or a captain or the Major. Especially don’t mess with those guys. If you’re in the corridor and you hear an announcement over the PA and suddenly COs are running full-tilt past you down the hall, just stop where you are and make yourself small. There’s an emergency somewhere in the prison. Step the wrong way and you’re liable to get run over by 250 pounds of adrenaline-suffused meat–and he won’t stop to apologize.

Sixth, it’s generally considered impolite to ask a prisoner what his crime was, or how long he’s been in prison, or how long before he gets out–especially if it’s just to satisfy idle curiosity. If he wants you to know, he’ll tell you; but since our purpose for being there has absolutely nothing to do with that sort of thing, probably he won’t get around to it. You’ll get along best with these guys if you simply treat them as equals and interact with them the way you would interact with junior developers at an industry conference. You may even find that one or two of them are not so junior after all, depending on the particular skill under consideration. There is, however, a reflex that makes them different from the average developer you’ve paired with, and that’s the reflex that tends to keep them from correcting a visitor. I think the mechanism is that they’re afraid a visitor will be insulted by a correction, and that if he’s insulted he may leave and not come back, and visitors in prison are highly valued. Most of these guys have done some work on extinguishing that reflex where pairing is concerned, but you may have to help them work on it some more. Even better would probably be to make them drive most of the time.

Seventh, don’t wear shorts or jeans–or any denim. I’m not sure what the thinking behind this rule is exactly, but it’s pretty common in prisons. Also, if you normally wear shoes with structural steel in them (steel toes, steel shanks, whatever), you probably won’t make it through the metal detector with them. You can take them off and put them back on if you like, but it might be easier to wear shoes for the occasion that have no structural steel. (And don’t say “shank” in prison: it’s like saying “bomb” in an airport.)

Eighth, don’t get involved in the politics of the situation. Don’t commiserate with the staff about what worthless scum the prisoners are, and don’t commiserate with the prisoners about how corrupt and brutal the staff is. You’ll undoubtedly have your own opinions going in (although they may change while you’re there) and there’s nothing wrong with that; but from a practical perspective we’re going to be depending on both groups to make this work. We can talk among ourselves about it before we go in and after we come out; but while we’re in there, let’s concentrate on code.

Finally, if you have to be reached while you’re in prison, here’s the number your people should use: 740 382 5781 Dial 0 and ask for LifeLine, extension 3361.

Q. Okay, you’ve told me a lot of stuff, but what I really want to know is, when is the next Coding in the Clink?

A. We’re using this page for a permanent reference that covers all of our events.  Event registration will be handled at EventBrite.  We try to Code in the Clink once per quarter; occasionally we succeed.  This should be a link to the EventBrite page for either the next upcoming event or (if we haven’t scheduled the next one yet) the most recent one.  More current information will be posted on Twitter under #citc.  If something here needs to be updated, mention it to @dnwiebe on Twitter.

Other Blogs About Coding in the Clink III

After the other two Code Retreats, we had a little blog activity, but after this one more than half the outside developers blogged about it, so I figured I’d gather the links here.

Rob Conaway

Amber Conville

Mike Cornell

Angela Harms

Tracy Harms

Jeff Hoover

Max Langensiepen

Dan Wiebe

Aaaaand it appears that I’ve forgotten the name of one of the eight developers who participated. Somebody please correct me, and apologies in advance to the unidentified developer.  Thanks.

Update: Ah, I remembered.  The last guy is Max Langensiepen, who signed up late. Sorry, Max. Gotcha in there now.  Oh–and Amber, thanks for reminding me…although I did actually remember before I saw your tweet.

Another Update: Now we have a sixth blog from Tracy Harms.

Hopefully Second-To-Last Update: Seventh blog from Angela Harms. Now Max is the only one missing.


Coding in the Clink III – Another JavaGuys Code Retreat at MCI

I wish I knew who came up with the name “Coding in the Clink.”  It’s perfect.  I think it was somebody on Twitter.

Anyway, once again due to the driving force of Louis Pierce, with much support from prison staff, Win-Win staff, and outside volunteers, we’ve had another successful Code Retreat in prison.

This time there were eight outside professionals and thirteen prisoners: so we had five triples and three pairs.  It seems mostly the prisoners like triples (I think maybe because the full intensity of the professional’s personality is not focused solely on one person), and the volunteers like pairs.

We also had a photographer wandering in our midst, snapping photos that beg to be posted somewhere.  However, we’ll have to get some special administrative permission to get those photos out of the prison, so they’re not part of this blog post. We gathered in the corridor outside for a group photo too: that should be in the mix, when it comes, as well.

Two of our outside volunteers this time were women: that’s our record so far.  Women volunteers who are not authority figures get a lot of attention from the men inside, but it’s all extremely respectful and gentlemanly attention–even from guys who have only the vaguest idea, mostly from hearsay, of what a gentleman is.

Most of our volunteers were from central Ohio, but three of them came all the way from Michigan.  At least two of the three were enthusiastic enough after the experience to declare that they would definitely come back for the next one.

The problem we chose was scoring tennis.  The story test most of us probably used, taken straight from the problem description, would have been to turn this:


into this:

love all
Alice fifteen, Bob love
Alice thirty, Bob love
Alice thirty, Bob fifteen
thirty all
Alice thirty, Bob forty
forty all
advantage Alice
advantage Alice
game Alice

Since the Code Retreat was (probably inadvertently) scheduled for the same weekend as Kairos, scheduling was a bit unusual and we only got to run two cycles in this Code Retreat, which is not as many as three, but a whole lot more than none.

I happened to wind up in pairs both times, mostly because a number of the guys have already paired with me and are more interested in using the Code Retreat to pair with unfamiliar folks so as to learn new things rather than old things.

For the first cycle I paired with Lee Leonard, and although we slid the keyboard back and forth, he pretty much took the strategic lead.  It was a good one, because we finished the problem almost half an hour  before the end of the cycle.  (Finishing a problem at a Code Retreat is a new experience for me.)

Between the two cycles we ate lunch, again in the prison chow hall.  It seemed to be a pleasant adventure for most of the outsiders, although the prisoners mostly seemed embarrassed to have us experience their food.  It wasn’t the best food in the world, perhaps, but it seemed better than–for instance–what I remember from elementary school.  (Of course, that memory is decades and decades old, so it could be a little fuzzy.)

For the second cycle I paired with Jason Sexton, and it worked out that I had most of the strategic lead, because Jason thought a functional solution sounded more interesting than another imperative solution, and he hasn’t really had a lot of functional-programming emphasis in Java.  As it happened, we finished the problem again, but this time just barely under the wire.

There was plenty of time for retrospective and socializing, and most of the folks there seemed to take advantage of it.  Next time, we’re going to try for not two cycles, not three cycles, but four cycles.

Once again, it was a thoroughly positive experience both for prisoners and for volunteers, and the prison staff, even heavily loaded down by the requirements of Kairos, were cordial, professional, and prompt as well.

The next Code Retreat hasn’t been scheduled yet, but it’ll likely be in the summer sometime.

Big Meeting Tonight

From the time when the JavaGuys program started to the time Rob and Joel joined, there were just the guys inside and me.  The program was run a certain way because that was the best way I could think of to run it with just one guy on the outside.

When Rob and Joel joined, and were inexperienced with working in prison, we pretty much kept doing things the way we had done them before, just because that was the way everybody knew to do them.

Lately, though, both the inside guys and we outside guys have been becoming dissatisfied with the status quo.  Joel and Rob and I met for dinner to discuss it, and wound up burning up three hours.  The next time we were in prison, we discovered that that very night a bunch of the inside guys had also met to discuss their own dissatisfaction, and had come up with a few interesting ways to improve things.

So we scheduled a common meeting tonight, and talked about A) improved ways to get things into and out of the prison, B) improved methods of reviewing code, C) how to help the guys pair more effectively, D) how to use everyone’s time better, and D) what to do on Tuesday nights.

Lots of it is still vaporware, but I think there’s definite potential.  It was a good retrospective.

Another Code Retreat

Louis has decided to schedule a third Code Retreat in prison, this one on Sunday, March 27, 2011.  (If you’re interested in participating, go here and register your interest.)

So far we’ve got five professional developers committed to the Retreat, but if we have nineteen prisoners or so, we’re going to need a lot more.

It’ll be interesting to see how this one goes.

What, Another Conference?

This was a good week, at least from my point of view.

I’ve been working on writing a shell around a data dump from that I can take into prison so that the guys can use it as a mini-Google when they have technical issues, rather than having to wait until we come in on Tuesday nights.

I decided to do everything I could in a way I’d never done it before, in order to learn more stuff.

I’m using Git for SCM…and having all sorts of problems.  Hopefully I’ll get those straightened out.

I’m writing all the code so far in Scala, which is my first real use of that language.  (It was nice to see all eight cores of my desktop machine running at 98-100% utilization; I managed to create 3.5 million XML files in a single directory in about 1.5 hours.)

My idea so far has several steps.

First is to split up the posts.xml file from into one XML file for every post.  (That’s done: it’s where the three and a half million files came from.)

Next I traverse all the little files and create another file containing thread associations: post 1234 is a question, and posts 2345, 3456, and 4567 are answers to that question.

Then I traverse the thread-associations file and generate two sets of files, with one file in each set representing one discussion thread.  Both sets will consist of XML files.  One set will have an <?xml-stylesheet … ?> line to point the browser to an XSLT script to make HTML out of its contents; the other will be a full-text index file for Solr, with a URL to the other XML file for payload.

Then I feed all the index files into Solr to make the other XML files searchable and linkable.

I’ll throw together a little CSS so that the XSLT-generated HTML will at least be readable; then I’ll take the whole shebang into the prison, where Mark Roberts will undoubtedly tweak the CSS to make everything look really cool.  (I’m not really a CSS guy.)

It turns out that my random choice–Scala–is excellent for this project, both because its Actors are an easy way to do multiprocessing simply and correctly, and because of the way it handles XML directly as a language feature, rather than through libraries.

When I got into prison this evening I was a little curious about how Lee Leonard had handled last week’s problem.  He had a Hibernate-based servlet going that could not see changes in the MySQL database unless it was killed and restarted.  He had a version using HSQLDB that was working fine, and he couldn’t figure out why the MySQL one didn’t work.

I couldn’t either, but I recommended that he pull the java.sql.Connection out of the Hibernate session and run raw SQL over it and use JDBC to examine the results to see if the same problem existed.  He did, and found out that he couldn’t see the data with JDBC either.  That’s about when I had to leave.

So it turned out that he had tried using DriverManager–rather than Hibernate–to set up a JDBC connection and used raw SQL over it, and everything worked just fine.  So he figured out how to create a Hibernate session factory from that JDBC connection, and then Hibernate started working fine.  He wasn’t happy about abandoning the standard Hibernate configuration, though, so he wrote code to read it in and set the session factory’s properties appropriately.

That’s a hack, and he’s looking through the Hibernate configuration to find out what the original problem was; but I’m very proud of him that he was able to do as much hacking as he did to localize and work around the problem.  I really hope he and Pillar Technology give each other a chance when he gets out.

Louis spent some time talking to me.  Just as a new mother quickly forgets the agony of childbirth and is anxious to become pregnant again, Louis has quickly forgotten the agony and hassle and stress of managing last month’s tech conference, and is talking about putting on another one in July of next year.

He has a number of interesting ideas for it, but the one that hits me hardest is that he wants to see if we can get Uncle Bob Martin to keynote for us this time.


“Uncle Bob?” I said.  “Here?  Are you serious?”

“What can it hurt to ask?” he replied.

Sheesh.  The guy doesn’t know the meaning of the word “intimidation.”

So I’ll see what I can do.  Jeff Langr, this year’s keynote speaker, used to work for Uncle Bob.  Maybe he can put in a good word for us.

I’m a little scared, though.  Everything else Louis has set his hand to has blossomed in beautiful colors; if Uncle Bob keynotes at Marion Correctional, the JavaGuys in general and I in particular will probably get a whole lot more attention than I’m comfortable with.