Today is my first day trying a standing desk. I hacked one together last night with some spare parts around the office. I wanted to try it out and see how I like it before investing in a more permanent solution. This was my tweet from last night:

Standing desk a la spare parts. Wanting to try it out before committing. #hack twitter.com/GDBolinger/sta…

— Gregg EC Bolinger (@GDBolinger) June 3, 2013

I had a rough week last week in terms of productivity. Usually, when this happens, I’ll make a change in my office like rearranging things, moving my desk around, etc. I needed something new and when I started doing some research I kept coming up with standing desks. I spent some time reading up on the benefits as well as the down sides to standing desks and as far as I can tell at this point, the positives outweigh the negatives. Some of the benefits I’ve read include:

I wanted to add DZone’s Voting Button to my blog posts. I did a little searching and there didn’t seem to be anything currently available. I opened up _config.yml and added the following:

1
2
3

# dzone badge
dzone_badge: true
dzone_style: 2

Then I added the following to source/_includes/post/sharing.html

You can see the results at the bottom of this post inline with the other sharing options. Simple as that. I’d like to figure out how to take a section of the blog post and put it in the dzone_blurb variable. If anyone has any suggestions, let me know. If I figure it out, I’ll be sure and post a follow up.

• The year: 1994
• The setting: Jr. College
• The game: Magic the Gathering

In the geekdom days of my youth many a tests and homework assignments were cast to the wayside in honor of Magic the Gathering. I can remember going to the game shop on Monday afternoons with my Sears paycheck in hand ready to buy as many booster packs as I could, hoping for that one card that would allow me to dominate my competition.

At some point I realized that I couldn’t keep doing this and ended up selling all my cards for what I’m sure was a totally undervalued price to some kid destined to follow in my footsteps. The years went by and 19 years later I’m finding myself sucked right back in. This time, however, it is more about spending time with my oldest son. He’s 12 and our family has become quite an avid fan of all things Tabletop.

I’ve started blogging about our games and as I was pondering MtG articles I want to write in the future I realized I needed a good way of linking the cards I wanted to display in the post. Specifically, if I wanted to show a certain deck build or cards on my wish list. Wizard’s official MtG forums have a nice way of doing this with their forum code tags. I liked this approach so I decided to see if I could duplicate that for Octopress.

I was notified that Posterous is being killing by Twitter (since buying them out). I set out to find a replacement and was recommended Octopress. Hesitant at first because I wasn’t sure I wanted to deal with hosting it myself but after reading the docs and seeing how easy it is to setup with a service like Heroku I decided to brave the waters.

I linger on several mailing lists and forums looking to help folks with their Grails issues and one of the more common questions I see is about using the Grails select taglib along with remoteFunction.

I decided to create a sample project with a couple of different ways to select an option from a select element that uses ajax to update a 2nd select element, since this is what most questions I see are asking about. And I’ll use this blog post to walk through the code and hopefully I’ll be able to just post to this example when answering questions in the future.

We’re using Terracotta on a new project. We have Terracotta installed on our staging and production servers. For it to work there needs to be a context.xml in the META-INF folder of the WAR with something defined like so:

This is fine for staging because the Terracotta server is on the same server as Tomcat. But for production, we have two (2) Terracotta servers on their own machines. In addition to that, we don’t want this file during local development or on our testing server since Terracotta isn’t running on either.

I created a folder in our app structure called “assets” and I placed 2 files there: context-staging.xml and context-prod.xml. I then created a file in the Grails scripts folder called _Events.groovy. Below is the code for that file which should be self explanitory:

And that’s it. Now, every time the app is ran or packaged we get the appropriate context.xml file.