I gave a presentation tonight on JBoss Rules to the Phoenix JUG. There was a good group of people there, and we had a very lively discussion around some of the strengths and weaknesses of rules engines in general. It was fun to cover a topic that I don’t hear much of (outside of sales pitches), and to see so much interest. There were a log of thoughtful questions, and many people were interested in ideas of how to program using rules.
At work, we use JBoss Rules for a small portion of our code but that code handles an awful lot of our transactional complexity. Spring, Hibernate, and Struts handle most of the heavy lifting of our structure. But JBoss Rules helps keep our routing logic and call script questions fairly clean and maintainable.
While a lot of the value of a presentation is in the verbal exchange that goes on in the room, I figure there’s something to be gained by gazing through the slides and sample code after the fact. With any luck, I’ll take some time in the next couple weeks to put up some podcasts (gasp!) on JBoss Rules. Enjoy.
Presentation: rules.pdf
Source Code: jboss-rules
We are pleased to unveil to you, codesmack.com, home of the funniest programmer t-shirts. We have over 15 different designs that can be paired with different shirt/color combinations to dress you out in style. Our designs try to bring humor to the IT world, promote good programing practices and add a little good natured smack talk to your wardrobe.
We welcome any feedback you have regarding the site design (treat it gently; it’s brand new), t-shirt ideas, or any other comments you would like to make. If you like a shirt, we won’t even complain if you buy one (or more).
Hope to see you in a CodeSmack t-shirt!
–Tim and Aaron
http://codesmack.com
With this little announcement we let our family, friends, coworkers, and open source associates know what we’ve been up to for the month or so. We’ve got a great selection of designs started, with plenty more to come in time. Digg your favorites soon and you just might get a chance to pick one up at RailsConf.
Kaizen and Juice 2.0 – Juice Analytics
We built the new site using Python and Django.
I really like the Juice Analytics blog. These guys know their stuff when it comes to business analytics and data information display. They know all the big names, all the new tools, and they’ve got their own tips on top of that which makes it a great read. I really like their new site layout, and find it interesting they went with Python and Django. Most of my new stuff these days is Rails, but I have respect for anyone that makes a conscious decision about what they’ll use. And today, there’s a lot of power in light languages combined with flexible frameworks. Rock on, Juice.
I’ve been using Firefox for a long time. Last night I decided to give Camino a spin. I’m using a nightly build of what will become the 1.5 stable release later this month. This thing sings. It’s fast, feels lean and light, and it stores my passwords in Apple’s Keychain. Lovely.
There’s no way I can give up Firefox for development — Firebug is just too cool. I may, however, use Camino for normal “work” where I’m not trying to tweak the CSS, layout, or whatever of something I’m actually building. This dichotomy could perhaps become too burdensome; though I think QuickSilver will surely see to most of that concern. I could discover that I insanely miss the occasional GreaseMonkey thing, or I really miss…something. We’ll see. For now, I’m happy to have a zippy browser again.
So you’ve got a great Rails app. You’re setting up page caching for those publicly accessible pages shared by everyone. One of your pages is the :index. It seems like the caching isn’t working when you’re testing it, but the output constantly says:
Cached page: /tag.html (0.00044)
What gives? Try seeing if “/tag” seems to use the cache, but “/tag/” doesn’t.
The mechanism behind the Rails page caching takes your action output and stuffs it all into an HTML file that can easily be found by the web server. Ah! So there’s no voodoo in Rails itself that tries to check for that page. In fact, it’s banking on not being called by pushing that burden off to the web server. In our case, this is Mongrel.
So how does Mongrel decide? Well, the mongrel_rails fires up a RailsHandler which uses the PATH_INFO to check for the existence of a cached file. When you’re requesting “/tag/” it’s looking for tag/.html, but not finding it.
I put together a patch here to address it. Seems to work in my limited testing, but I don’t know what I may have broken. Yeah, usually I make sure to write a test for my patches. This time I didn’t. Perhaps it won’t make it in until I do, but at least I’ve got it written down here to remind me when my cache doesn’t seem to work quite right.
So I ran into a funny error today while trying to install erlang on my Mac.
Zdot-MBP:~ tim$ sudo port install erlang
Error: Unable to execute port: invalid command name "configure.cppflags"
It turns out (after running port using the -d option), that macports was trying to upgrade my gettext version. The Portfile seemed to be trying to set the CPPFLAGS option for the configure tool. I opened up /opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports/devel/gettext/Portfile and replaced:
configure.cppflags \
-no-cpp-precomp
with this:
configure.env CPPFLAGS="-no-cpp-precomp"
That seemed to have fixed things. I was able to continue my install and fire up erl. Since I couldn’t find the answer on the big Google-Net I cast, I figured I’d write it up here in case some poor soul had the same bad luck I did.
Now it’s time to try out some Amazon API stuff.
My youngest cousin was in a building next to Norris Hall. She’s an engineering major at VT. Her mother works on campus. Her father has worked for the campus for years, and works for the campus from home. She wrote yesterday with a brief update that said, in part:
One guy I know was in a classroom in Norris (the building that the gunman barricaded) but they put a table up against the door and all pushed on the door when the gunman tried to enter. Two bullets came through the door at chest level but everyone was down low to the ground and later escaped safely.
As I read through the Wikipedia entry she sent, I was amazed at the story of Liviu Librescu. He was a survivor of the violence of the Holocaust.
He was killed in the Norris Hall Engineering Building. He was 77 years old.[5] Librescu held the door of his classroom shut while the gunman, Cho Seung-hui, was attempting to enter it, and was shot through the door, but was able to prevent the shooter from entering the classroom until his students had escaped through the windows[6][7], sacrificing his life to save several students from being harmed and is regarded as a hero during the aftermath of the Blacksburg massacre.
As a student of self-defense, I have great respect for those willing to put their lives at risk to help others. My uncle suggested that in addition to classes in self-defense, we should have classes on group defense. The heros of United 93 forever changed the way airplane passengers respond to threats. Tragedies like the Virginia Tech massacre and others may produce the same resolve for group defense in our collective culture when we’re faced with such situations.
Virginia Tech and Blacksburg, our hearts and prayers are with you.
In last year’s JSF Burrito podcasts, I argued that I didn’t see the point of using a strong component model for JSF and that throwing away nice HTTP RESTful URIs is a Bad Thing. In an interview with InfoQ, DHH takes up a similar (though probably more polite) stance.
InfoQ: DHH Responds to Stateful Web Applications Row
[There is an] assumption that all web developers really want to be desktop developers and that all web applications would be better if only they were more like their desktop counterparts. I don’t accept that assumption. I love working with the web as it is. I love the architectural patterns offered by HTTP and REST.
So in many ways, I see chasing a desktop-like view of the web as chasing the past, not the future.
I’ve written about my reactions to JSF one year after the burrito entries. I find myself clearly in the camp that DHH is in: making desktop-like web apps is chasing the past, using RESTful style development is an approach I prefer.
A number of months ago we held an internal debate over XUL, and its place in our development. For the most part, we debated many sides of the issue and came out with “let’s wait and see.” Basically the core of the debate was whether a desktop-like UI is better for our apps or if a web model was more appropriate. Some of us leaned toward the web app side, some just thought the timing was too soon to tell for XUL. Personally, I prefer to keep all the MVC issues on the controller side, and limit JavaScript on the client to handle issues of rapid user feedback (check out the code behind Google’s “star” in GMail), and leave the control flow and rendering decisions to the server-side.
But that’s just me.
Grand Canyon Skywalk :: Hicks-Wright.net
This was not because the package was that complex, but because each person in the line thought they were going to be paying $25 per person. In reality, the tribe was charging another $50 on top of the $25 for each person. You read that right, 75 bucks a pop. The “Question Answerer” explained it to us:
“The investor wants to get his, that’s the $25. But it’s our land, and we don’t get any of that $25, so we have to get ours too, you know?”
When I heard about the glass skywalk it sounded like a really cool idea in principle. Now that I read this, I’m definitely passing on the trip for a LONG time. No cameras on the skywalk (what!!??!), long lines, and hidden fees. $75 per person is not even thinkable. No way. Too bad they launched in the day where one guy’s blog post can touch a few thousand potential customers.
I’ve been silent again. I know, it’s not what I intended at the beginning of the year. It’s just that it’s so much fun to go off and build stuff. I get sucked into all sorts of side projects outside work that are interesting and time consuming (not to mention time spent with the fam — two under the age of 2 is both a joy and a handful!).
So here’s one glimpse into my recent projects. I’ve been hacking away at another WordPress site. It’s a volunteer project I do mainly on the weekends. It’s been interesting to fiddle with PHP more in depth while still doing heavy Rails stuff in the evenings. I forget how functional style programming tends to work. Shared variables abound, and one file melds into another. PHP seems really good about working with files, though. It’s really amazing how easy it is to say, “now go use that file”. I’ve done stuff like that in JSP and other languages, but it’s pretty darn simple in PHP. The mental concepts of assembling a web page seem to be all about choosing the file that renders a certain part of the page. That’s different from JSF where you think mainly about assembling components, and different from Struts where you often think of Actions or logical forwards, and different from Rails where you think of the method in your Action and the responds_to block.
So it’s not likely that I’ll hang out in PHP land for long. Nor is there any danger of me evangelizing it, but I look at this as simply one of many recent experiences I’ve had while building something that confirms another of the Pragmatic Programmer’s axioms: learn a new language every year. I’d add, Do it while hacking something together.
My two year old just blasted past between my laptop and the plug. The mag adapter dropped off my MacBook Pro in silent fashion. My two year old kept quietly running (a rare thing — the quiet part). I was happy. It’s the tiny details like this where design shows its true colors. Is your app built for your users’ reality? Do your programmers need a reality check? How many “two year old” problems exist in their workspace, that you should handle beautifully instead of try to put those problems in a straight jacket?
I don’t know how many years I’ve used the following command chain to add all my unknown files to Subversion:
svn st | grep ? | sed -e "s/? *//" | xargs svn add
Inevitably I occasionally end up using that string on some directory where I have a space in the pathname, and everything bombs. So I finally got around to adding it to my ~/.bash_aliases file today, with the additional -e "s/^\(.*\)$/\"\1\"/". Simple, really (just make sure that something sources that file):
alias svnaddall='svn st | grep ? | sed -e "s/? *//" -e "s/^\\(.*\\)$/\\"\\1\\"/" | xargs svn add'
I may still play with the actual alias name to see what sticks in my every day practice. Maybe I totally missed a way simpler way to do this. Seems like I’ve done something like this since back when I started using Subversion at release 0.18 or 0.19. Maybe I haven’t kept up, so I’d be happy to be enlightened.
Do you have anything tiny hanging around that should be automated right now?
