I had my first decent coding stretch on CONGO tonight in quite a while. I put in 4-5 hours to work through some issues that have come up while running the v2 code for a ‘live’ event. This is the first time the new codebase has been exposed to ‘real’ customers, and so far things are going okay.
There haven’t been any showstopper bugs yet (knock on every available source), but there have been a few rocks along the way. The fellow running the conference has been very supportive, knowing it’s new code, and I’m looking forward to a post-event debriefing. “What should be done differently?”
Overall, I’m quite proud of the v2 code. It’s still missing a lot of functionality from the first codebase, but I do enjoy having everything in Java in a sane build system and a rock solid database layer.
And now… bed.
Category: Business yammerings
Azureus / Vuze under Ubuntu FAIL!
I’m not sure who to blame here, but someone should get drawn and quartered.
I’m working on setting up Azureus Vuze to run headless on yawl while I’m not around. To test it, I decided to install and run it on clipper.
Things were going quite well – with aptitude installing Vuze fine. I had to run java-update-alternatives to make sure I had the right JVM:
dbs@clipper:/usr/bin$ sudo update-java-alternatives -l java-6-sun 63 /usr/lib/jvm/java-6-sun dbs@clipper:/usr/bin$ sudo update-java-alternatives --set java-6-sun
Then, Vuze wouldn’t start:
dbs@clipper:~$ vuze exec: 11: /usr/lib/jvm/java-6-openjdk/jre/bin/java: not found
“Oh no, they didnt….”
They did. The vuze script starts up the azureus startup script, which is hardcoded to the java-6-openjdk java path:
dbs@clipper:/usr/bin$ head -5 azureus #!/bin/sh JAVA='/usr/lib/jvm/java-6-openjdk/jre/bin/java -Xmx1024M'
This isn’t hard to fix, it’s just a quick edit to the startup script – but cmon package maintainers. Get a grip here. The whole java-alternatives stuff is specifically made to avoid this sort of crap. Get it together!
Ubuntu Sound problem – won’t work after suspend – quick fix
Pursuant to my last post regarding PulseAudio problems under Intrepid, there appears to be a workaround.
The issue has to do with the PulseAudio system not being ‘suspended’ properly when a laptop goes into suspend. There’s a very easy way to sort of ‘nudge’ it back on track.
After resuming, type the following – this is done on my laptop ‘clipper’ :
dbs@clipper:~$ pacmd Welcome to PulseAudio! Use "help" for usage information. >>> suspend 0 >>> suspend 1 >>> <control-d> dbs@clipper:~$
I just tried this, and things started making noise appropriately – didn’t even need to restart Firefox to get youtube videos going again.
This is documented in Bug 202089 in the Ubuntu bugtracker, but I’m reproducing it here if folks can’t find the answer.
Why yes, I have been at this convention.
Thanks to Ben Levy for forwarding this to me – UserFriendly takes on registration at an IT conference…
CONGO – And so we go to alpha testing
On Sunday night I released CONGO v2 into alpha testing. The first client to be using the new platform wants to be up and running on January 1st, and this is on-schedule. The last couple weeks haven’t quite been a death march, but there has been a helluva lot of code written, checked in, and tested. The log of messages posted to congo-dev tells the tale. While November wasn’t as intense as October, we still did over 105 commits against the server. The CONGO v2 codebase is rivalling the original system in size, though now it is entirely java based (the old system was part PHP, part Java).
I’m pleased with how the system is coming along. An entirely new payment interface, refactored contact information, and a new Events module for managing activities at conventions is worked into the new model (though not all of it is complete yet). I’m satisfied with the choice to move to using Struts2 as my web framework, but my dissatisfaction with OGNL grows daily. Why OGNL was necessary for the struts tag library, when the expression language (EL) was around is beyond me. For most of my code I’m replacing struts tags with JSTL and assorted libraries, and using EL for referencing action, stack, and session based content.
The next 2 weeks should see the last pieces of functionality falling into place, at which point we go into beta testing. All coding should be done, and we’ll be tuning the system for “go live” on January 1st.
After that? Well, due to the awesome new build structure, I’ll be able to release CONGO v2 for use by other folks. The system is now self-installing and configuring, so setting up a new host to run a convention is an order of magnitude easier than it was in the past. Stay tuned for details on how you can download CONGO and install it for your convention!
And so ends our busiest month.
So here we are on November 1st (I could tell it was a new month because of all the Mailman notices in my inbox this morning).
But there’s another reason this is an important milestone.
Whenever I make a change to CONGO, I submit it into our SVN repository. That submission generates a mail message letting other interested parties know a change has been made, and they should update their local copies.
My philosophy, and one that is the ‘unwritten rule’ for SVN usage is “Commit Early, Commit Often. The idea is that the repository should reflect the most recent version of working code, and avoids the “I have had such and such code checked out for months, and you went and changed the repository on me! Now I can’t merge my code in!” problem.
Because my pattern really hasn’t changed, I can use my commit timing to judge how busy I’ve been on a project.
Last month, October, 2008, was the busiest, and therefore (arguably) the most productive month of coding on CONGO since the project started. The congo-dev mailing list statistics show that during October there were 119 commits against he repository. The previous ‘record’ month was December, 2004.
Virtually all of this work is reflected int he progress being made in Congo V2, and I would be remiss in not giving thanks to Owen Jacobson’s help in porting Congo to a Struts / Spring model – his commits are in there too.
V2 is coming along. I’ll have something to show soon!
The weekend. Let me tell you about it.
So this weekend had me out to Ubercon down in NJ. All in all, things went pretty well. It was the second time I took Zach with me to an event, and he and blk’s son Justin had a riproaring time gaming, socializing, and geeking.
On a personal level, this wasn’t one of my banner events. It’s been a while since I ran at at-con registration of a reasonable size, and a lot of things conspired together to fail so that, by today (the last day of the con), I felt pretty down about my showing. Let me esplain. No, there is too much, let me sum up.
- Mame – My MAME cabinet, which I’d been hauling down to Ubercon for now the third event, gave up the ghost last week. deathstar refused to boot, and I almost cancelled bringing the machine. The UC folks happily offered up some spare hardware, and I decided to bring the machine down. Early Friday morning I did an emergency load of Kubuntu 8.10 on a spare laptop, installed my MAME drive that has my roms in as an external drive, and configured up KXmame. The end result? Unstable, video modes not working right, and general bleah. I managed to keep it limping along through the weekend, but it was not the glorious, elegant machine of the last event. There needs be work here.
- CONGO – Hardware – The server I use for events, ‘endor’, has been running faithfully for almost 20 events now. I’ve done one full OS reload, and for the most part it has been dependable as all git out. This weekend however some hardware twitches started to come up. First, the CMOS battery died, which causes the ‘things have reconfigured!’ message on boot. What I didn’t realize was it had also reset the dates, so that all the log entries for CONGO this weekend have a datestamp somewhere in 2006. This will require manual fixing. We also lost power twice due to a flaky outlet. The last bit was I attempted to cut back the amount of hardware I bring to events, and in doing so managed to arrive short 2 keyboards. Fortunately, Ubercon loaned me a pair so things were fine, but Grr.
- CONGO – Software – For the most part, CONGO behaved appropriately and did all we asked of it. I’m itching to get v2 up and running, because of all the deficiencies I keep seeing in v1. But, the old tried-and-true still chugs along, and we cranked out hundreds of badges over the weekend.
- Organization – I normally have a very competent reg manager running the event with me. This time, the normal Ubercon chap I work with was unavailable (due to health issues). While other folks helped man the desk (we were never short on people), not having an “In charge” Ubercon person with us really pointed out weaknesses in the process control in CONGO (things like cash drawer management).
Despite my grumblings, the convention was a success, and I think we did a bang-up job on keeping everything flowing nicely. I am utterly, 100% exhausted – the drives up and down take their toll, and caring for a 9yr old while running an event can be a bit taxing. Would I do it again? Absolutely, and will next year. For now, I’m going to go fall over.
CONGO Progress and Pretty Pictures
Another good night of coding!
After finishing a hefty project at work, and a busy week of Life Fun, I took 4 or 5 hours last night to hack into CONGO and try and get some rough edges worked out. I really feel like I’m approaching a useable system, with workflow doing what it’s supposed to, database tables updating the way they should, and crashes being few and far between.
I’m a visual person, so I wanted to come up with an up to date ERD for the v2 table structures. Ages ago I used DbDesigner4 to create an ERD for v1, but the tables have shifted a lot since then, and I wanted to see if I could auto-generate a diagram from table structures
Hunting around, it looks like DbDesigner has been absorbed into MySQL Workbench. I downloaded the latest version, and found myself bewildered by it’s interface until I realized what this thing was. It’s a tool for creating and designing databases, as opposed to a passive maintenance tool. Not… quite the approach I was shooting for – I was hoping for something like dbVisualizer that had a button that said “Make an ERD of this.”. While dbVis does have that to a certain degree, it’s pretty weak.
Eventually I figured out the incantations necessary to create an ERD with MySQL Workbench from existing table structures (it involves dumping the MySQL tables to a .sql file, and ‘reverse engineering’ the structures from that file). A few more mutterings and a dead chicken later, I had a visual representation of all my tables and their relationships to each other. Score!
Alas, the tool isn’t really a ‘reporting’ system, so the resulting graph needed some fiddling in Gimp to add titles and other text. Naturally I realized after the fact that I didn’t move a couple tables into the view before snapping the picture, but it’s still a pretty good representation of where I am.
Coding wise, v2 is missing a vital component – the Properties system is not yet working, and this is critical for basic operation. I started into it last night, building up new DAOs and domain objects representing a Property for a registrant and an associated PropertyDefinition. What’s left to do is write all the management tools around them to make them workable from Coconut, and start testing.
The last big project will be the public interface. In many ways, that’s going to be the simplest and most rewarding – it’ll be the outward facing side of CONGO. Essentially what registrants see when they want to attend a convention. Previous stabs at this worked reasonably well. Attendees at the various events were able to do the basics of what the event needed, but I’m really looking forward to going the ‘next step’ and offer a full service deployment.
My delivery date for CONGO v2 FC is December 1st. So far, I think I’m going to make it.
A WeekBlog – A Post a Day – CONGOv2
So this week I’m faced with a situation I haven’t had in front of me in, well, as long as I’ve been married… at least as long as I’ve had kids in my life.
This week Cat is up in Maine with Zach. I have my normal work going on during the day, but no commitments for the evenings.
A unique opportunity to be sure.
The Plan [tm]
So here’s what I’m going to do. A few months ago I started work on a complete rewrite of CONGO. The rewrite is underway, and has been getting attention fairly regularly over the last couple weeks, but I need to make the final push to an alpha release.
This week, I will dedicate 2 hours a night every night to continuing work on CONGO v2, with the goal of reaching an alpha-testable version by the end of the week. I will also make a post each night with an idea of where my progress is on the rewrite, and what I’ve accomplished. (I do reserve the right to post the next morning if I’m up until Oh-Dark-Thirty coding and fall asleep in the middle of writing an exception handler.)
Anyone wishing to follow the riveting details of my work, I subscribe to the Commit Early, Commit Often philosophy of source code control, so when I’m working, you’ll see commits firing off pretty quickly. If this sounds interesting, you can sign onto the mailing list, or, if you’re uber-hip, subscribe to the RSS feed.
Yeah? So? Why us?
So why bombard ya’ll with my chattering? Well, I work better with encouragement, or if I know folks care about what I’m doing. Curious about bits of CONGO? Ask! Wanna help out? Give a “wow, kick butt, dude. Go for it” comment or two.
Hopefully I’ll have some work to show for tonight, but if not, stay tuned for truly exciting blow by blow Java coding!
Revisiting old code, and Good decisions made
Over 5 years ago, I began work on an application called CONGO, a registration and badging system, not only in the vein of “There’s gotta be a better way”, but also to help out a friend who was running registration at con in Philadelphia.
The first versions of CONGO were crude, but worked well – with a custom Swing interface, custom terminals and servers, it was an impressive setup. What wasn’t apparent was this was my first foray into writing any decent sized Java application. I made what I thought at the time were good design decisions, and looking back on 30+ events run, and hundreds of thousands of badges printed, I’d say the design was, for what I knew at the time, solid.
But it’s time to change. With everything I’ve done over the last 3 years in Java and enterprise-level applications, I feel I’m ready to rewrite CONGO into a proper Java based webapp. CONGO 1.0 was part Java, part PHP, part templating. CONGO 2.0 will be a pure java application, based on Struts, and will allow features that I could not shoehorn into the old model
I started work on CONGO2 about a week ago, and I have my first screens working properly and chaining together as they should. Part of this process is factoring in the old logic code, and linking it up with the new presentation layer I’m building using JSPs and Struts. This means making calls to 12,000+ lines of Java code that was written as I was learning the language.
But one thing I did consistently – I documented my methods. Every piece of the CONGO appserver has full Javadocs describing how to call the method, and what it returns
Because I’m doing CONGO2 using modern tools (like Eclipse and Tomcat, my GUI is showing me these docs whenever I try to link to my old code, and is reminding me how to use the old libraries. Why is this remarkable? Because other than generating static documentation, I’ve never actually seen my own comments and documentation popping in interactive windows in my IDE. Until now.
It gives me a little thrill each time I see my own docs pop up as helper windows in Eclipse, showing me comments I made half a decade ago on structures and calls, and reminding me how to use the system.
It wasn’t easy to learn Java, it wasn’t easy to learn Swing, it wasn’t easy to learn JSPs, JSTL, and Struts. But now I do know them – some more than others, and I’m enjoying this massive refactoring of one of my proudest creations.
And now, a word from my day job.
I don’t talk about my day job much. For those outside of the Java Geeky circles, it’s pretty dull stuff. But today has been particularly active, so I thought I’d share some of the bits I learned while teaching myself the wonders of Struts. This can best be summed up by the following revelations…
1) When changing a struts.xml file, within an Eclipse WTP environment, being serviced by Tomcat, WTP does not click that the Tomcat server needs to be restarted. The ‘Dynamic’ part of WTP does not take effect, and no matter how many times you save what you’re working on, it won’t go live in the server until you actually restart Tomcat.
2) Despite all the awesome advances in Eclipse in the last few years, there’s twitches that still drive me absolutely gonzo. One is that the ‘smart insert mode’ (which helpfully closes XML tags and closes quotes and parentheses for you) cannot be turned off globally. You can do it on a per-editor basis, but not globally, so I’m always forgetting to turn it off when I open a new editor. Another is XML syntax validator is still quite twitchy, and occasionally will flag incomplete tags or non-well-formed XML when the file is just fine. A close and re-open fixes it, but ugh.
3) Last, but not least – that which almost got me up on the roof with a high powered rifle. I give you a quiz as my example. One of these two struts.xml configurations apparently tickles a bug in Struts2 and will cause an internal server error and stacktrace with a Null Pointer Exception. The other will not. Can you figure out which is which?
<action name="/*">
<interceptor-ref name="mystack" />
<result name="success">/WEB-INF/jsp/{1}.jsp</result>
<result name="login">/WEB-INF/jsp/index.jsp</result>
</action>
<action name="*">
<interceptor-ref name="mystack" />
<result name="success">/WEB-INF/jsp/{1}.jsp</result>
<result name="login">/WEB-INF/jsp/index.jsp</result>
</action>
Just for fun, here’s the actual stack trace:
1.
INFO: Server startup in 954 ms
2.
Jun 17, 2008 7:41:14 PM org.apache.catalina.core.StandardWrapperValve invoke
3.
SEVERE: Servlet.service() for servlet default threw exception
4.
java.lang.NullPointerException
5.
at com.opensymphony.xwork2.config.impl.ActionConfigMatcher.convertActionConfig(ActionConfigMatcher.java:168)
6.
at com.opensymphony.xwork2.config.impl.ActionConfigMatcher.match(ActionConfigMatcher.java:144)
7.
at com.opensymphony.xwork2.config.impl.DefaultConfiguration$RuntimeConfigurationImpl.getActionConfig(DefaultConfiguration.java:316)
8.
at com.opensymphony.xwork2.DefaultActionProxy.prepare(DefaultActionProxy.java:169)
9.
at org.apache.struts2.impl.StrutsActionProxyFactory.createActionProxy(StrutsActionProxyFactory.java:41)
10.
at org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:494)
11.
at org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:419)
12.
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
13.
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
14.
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
15.
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
16.
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
17.
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
18.
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
19.
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
20.
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
21.
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
22.
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
23.
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
24.
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
25.
at java.lang.Thread.run(Thread.java:619)
How the hell am I supposed to debug that?
I finally did, after a good 2 hours of hair-ripping, gnashing of teeth, and spewing my venom upon the #struts IRC support channel.
How Not to Run a Convention
I do conventions. I work a lot of them. Even though I’m not a conchair, I’ve been high enough up in the hierarchy, and worked with enough of them, to know how much work they are, and how they can go wrong.
But I’ve never seen one go as badly as this.
This is the story of FedCon USA. A Trek convention in Dallas Ft Worth where the organizer, one Tim Brazeal, apparently through pure incompetence, caused an entire event meltdown. The reasons appear to be manifold, but the causes seem to be miscommunication, poor organization, and in some cases, out right falsehoods.
On the flip side, it appears this failure is, apparently purely due to mismanagement, and cannot be ascribed to malice. He didn’t wreck the event on purpose, for profit or for some other reason – he simply screwed it up. Badly.
It should be noted, that this is FedCon USA, which only bears the name FedCon as borrowed from FedCon Germany. That organization, which is widely respected, issued a press release describing their dealings with Tim, and how he lied and alienated them as well. FedCon Germany withdrew support for the event, but Tim went on advertising that he had their financial and organizational backing:
I never in my life meet an individual like Tim. First he seems like to be a great buddy, but after a while you discover a person, who is constantly lying, apologizing and making things up. He was never straight forward, almost everything he said was a lie. I never in my life met someone who actually believes all this BS he says. He was always totally sure, what he says. But saying and doing are two totally different things. He is the person who says: “Okay no problem, i book the flights for you!” As soon as you hang up he totally forgot the conversations he just had. But if i would have told the fans earlier, I would for sure got some legal problems!”:
All i can say is, FedCon Germany (the real thing) is always a feast for the fans and if i can help out some of you at one of our next shows please let me know, just email us and sent us some proof that you purchased a ticket for FedCon USA and we give you something back at our next show.
I also think, the whole staff from FedCon USA (not Tim!!) have nothing to do with this mess and they sure worked their asses up to make some things better, but with their figurehead hiding in dream worlds, lame excuses and lies, this was just not possible.
My heart goes out to the volunteers, staff, and particularly the attendees who, in some cases, drove many hours or flew in for the event, only to have most of the guests not show (even though they were still on the conventions schedule), and have the event shut down halfway through Saturday.
So next time you’re having a hard time at an event? Think of how bad it could get, and thank your event staff.
And another one done.
Today is the last day of the National Cohousing Conference at Bentley College in Waltham, MA. I, naturally, was providing CONGO for registration and badging, and oddly enough, everything went smoothly. Systems and printers all worked as planned, no last minute badge panic, and the database worked great.
In the background, I’m starting work on Congo v2.0. I’vebranched SVN, and I’m committing against a new 2.0 branch. More on this later, but suffice to say I’m pretty excited.
As always, I learned a lot, figured out problems that need to be fixed, and made plans to add features. This was also the first time we had directly linked CONGO to a credit card payment system, though that wasn’t active at the event. Next time, however, we’ll have it all live at the same time, and won’t that be cool! 🙂
Everything’s packed up into the cases, and we’re ready to head home.
Another one done.
Coconut gets a facelift
Ever since I first wrote Coconut, the web interface to CONGO, I’ve been using the same stylesheet. It was really my first foray into stylesheet-driven design and layout, and while it was a good first try, it was ugly as sin.
Last night I finally sat down to rewrite the stylesheet into something reasonably attractive. I got rid of the dark background and greytones, and the ‘All Caps’ font styles, and used more pastels.
I’m pretty happy with the result, but for the hundred or so folks who are used to the old look and feel, it’ll be a dramatic change!
Dear Jboss. QA yer damned site.
Why is it so hard for any organization, from opensource on up, to understand it’s a good idea to give the users information they want, in a form that’s useable?
I zipped over to JBoss.org to see if there was an update to the 4.2 server I’ve been using for the last year. Sure enough, there’s a 4.2.2 release that came out in October. Great, I wonder what changed?
Well, the downloads page has the new release on it, and a link to the release notes. Which, you’ll note, is completely illegible because the lines are not wrapping. (I tested this in Firefox under Linux and Windows, Konqueror, and under IE6 in Windows. None of them make that page useable.)
Was it so hard for the JBoss release engineer to click on links and check if they worked? Apparently that capacity is beyond them. Sad.