When GlassFish Stomps On Your JSON

Funny thing about learning new technologies and stacks, you run into all kinds of hard to diagnose problems. Here's one that I ran into that took a few days to figure out.

The Problem

The stack I'm working on right now is a Backbone front end with a Grails back end running on Glassfish. The thing about Backbone is since everything is in Javascript, you do a lot of jQuery calls to get/update content. One of the things to consider when doing that is error handling.

In one of my Backbone views, I'm issuing an update via a button click. This sends a post up to the server and if there's a problem, it's supposed to return some JSON as an error:


If there's an error, it gets handled by a utility written to handle errors from the Grails stack:


I was testing the error handling which worked fine on my box but when it would get deployed to GlassFish, the errors weren't happening. I looked at the response coming back from the server and the JSON was in it but right behind it was this big chunk of HTML from GlassFish:



So what the hell? Now GlassFish has decided in its infinite wisdom to add to my JSON? I searched and searched for some kind of setting to change to make it not do that. Guess what, didn't find it. The controller code I was calling to was simple enough:


Why wasn't it just giving me the JSON? Also, why was it working through the Grails stack on my box?

Select Isn't Broken

Turns out I need to learn more about HTTP content headers. I gave up on configuring GlassFish, walked away from the problem for a while and then one day it dawned on me: in Grails, if you use render without specifying the content type it's just going to assume you're sending HTML. I made one minor tweak by specifying the content type and boom, no GlassFish in my JSON:


Hope this helps someone.

Stack Buffer Overrun Killed My CLR!

So I ran into an interesting problem the last few days. And by ran into I mean made me lose more hair than I have already lost! It took quite a bit of research and I thought I'd help the Internet by sharing what I ran into.

The Problem

We've been working on a new version of our product that was originally built on .Net 3.5 but has been migrated to .Net 4.0. Part of that application does a DllImport on some unmanaged code which has worked great in .Net 3.5.



Now that we're using .Net 4.0 the method that uses that DllImport is crashing. And I mean crashing HARD. There's a try/catch around the method call but it's not getting that far. There's no minidump to be seen, but there is an entry in the Windows event log:

Faulting application name: MyAppService.exe, version: 2.0.0.2, time stamp: 0x4f738b08
Faulting module name: clr.dll, version: 4.0.30319.239, time stamp: 0x4e181a6d
Exception code: 0xc0000409
Fault offset: 0x002b60d0
Faulting process id: 0x15b8
Faulting application start time: 0x01cd0dc5e21cf6a0
Faulting application path: C:\Program Files (x86)\MyCompany\MyAppService.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: 5453534c-79b9-11e1-8970-000c29dad353

Research

Wow. The freaking CLR died. No wonder no exception was caught. I looked up the exception code and it said that it was a Stack Buffer Overrun exception.

Stack buffer overrun? Can that happen in .Net? No, not really, but I was calling into unmanaged code which led me to believe that the unmanaged code was bad. Of course, if that code was bad, why did it work when .Net 3.5 was calling it?

Looking through StackOverflow.com I found a few things. Apparently stack buffer overrun protection has been in place in Windows for unmanaged code for a while but was ignored until .Net 4.0. I can't say for sure that this is why I'm running into problems but seems likely.

The Solution

Then I ran across this and this that talk about changing the calling convention from __declspec to __stdcall. At first I didn't think much of it because this was all C++ code and I was dealing with .Net. And then it hit me, that DllImport is using Cdecl isn't it? So then I changed the CallingConvention to use the StdCall and things started to magically work!

I wish I knew all the technical details about why this made things work but if this helps someone else out, I'll be happy enough.

Utah Code Camp Spring 2012

So check it out, I actually spoke at a code camp. I've always thought about speaking at code camp but I've never felt authoritative enough about anything to speak on it. Well, not anything interesting anyway. A few friends of mine finally coaxed me into taking the plunge and I totally survived.

I've been doing a lot of work with Mercurial at work lately so I decided to speak about how great it is and how it's totally viable as a version control system for both personal and work use. I didn't have the biggest audience in the world but I was able to fill up the time and was even able to field a few questions. It was stressful, exhilarating and I totally need to do it again.

I decided to do the slide deck through Google docs (which was pretty brave on my part as the wireless was brought to its knees during the conference). I don't regret it as it's easy to share and reference later. Anyway, here they are if you're interested, I included fairly detailed notes on each slide so if you missed my session, you can see what I talked about.

jQuery Autocomplete With Columns

My current job has shifted dramatically from doing Windows application development to web development (and then back again, and then back to web, etc.). With that change has come a crash course in JavaScript & jQuery programming.

One of the things I ran into was putting columns in jQuery's autocomplete. I found a pretty good answer on StackOverflow but I wanted to avoid using tables if I could. After some experimentation and a little more research I found an implementation that works.

I'd love to show an example of what I'm talking about within this post but Blogger's javascript support is... lacking (here it is on my Skydrive if you're truly curious or blogger butchers the code in this post). Since my JavaScript-fu isn't strong, I welcome any comments on doing this better but anyway, here's the code I came up with:

With the associated html:

It's assumed that the jquery, jquery ui and jquery ui css files are pulled in on the page.

The key to getting the columns to work lies in the _renderItem method override. The autocomplete is going to give you an unordered list tag and an item from the source. What you want to return is the unordered list with whatever list items to add added on.


The pitfalls I ran into were how the items should be formatted:

1. The information needs to be wrapped in an anchor tag to play nice with the jquery ui stuff, then you can start wrapping things in divs (I'm definitely no CSS expert so if it's done wrong, I'd love to know how it should be done).
2. I needed to make sure to set the width on the parent div so that nothing would wrap to another line.
3. Each column had its own div with a set width floated left except for the last one. Whenever I tried to mess with that, the highlighting in the drop-down would be messed up.
4. There's a space at the end of each column in case a field was null/empty. This prevents other nonsense that would happen with the drop-down highlighting.

Interview Observations

There have been some big events that have happened recently that have affected me professionally:

1. World of Warcraft: Cataclysm was released (or National Call In Sick Week).
2. Burned out on World of Warcraft and quit.
3. Changed employers.

I could talk for ages about items one & two but this is a programming blog so I better talk about number three.

Looking for work was an interesting journey because I went from participating in & conducting interviews to being the one interviewed (and then back again to participating in interviews). From all these experiences I have learned a few things that I wanted to share with others that may be looking for development work.

Preparation

Keep Up

First and foremost, keep yourself marketable before you need a new job. It's one thing to look for a job because you're bored or feel like your current job has run it's course but it's quite another if you're laid off/fired. If you wait until then to start sharpening your skills, it's kind of too late.

It'd be neat to be able to say that you know how to effectively program in C#, Ruby, Java, etc. in all their respective frameworks but that's quite a feat even if you don't have a family to support or other responsibilities. What you can do is do a little side project here or there in your favorite language and maybe target an interesting framework you don't necessarily use at work. Breaking that project out in an interview can show your potential employer that you love your craft.

Know The Jargon

Though it's not required, it's extremely helpful to know some of the newer concepts being thrown around the development community. And hey, why not learn what they mean why you're at it? It's never fun getting called out on a subject you said you knew, but don't really. Here are some of my favorites:

• SOLID
• TDD
• DDD
• DRY
• YAGNI
• MVVM

Know The Movers & Shakers

Another optional thing to look into, but very valuable nonetheless, is to know the important people in your industry. And not only know who they are, find out what they're working on next. This can be as simple as following a blog or a Twitter account. Some of my favorites include Scott Hanselman, Oren Eini and Uncle Bob (there are a ton more).

The Interview

So you've done all your preparation and got an interview lined up. If you well and truly know your stuff, the interview shouldn't be much trouble. In fact, if you're prepared, interviewing can be fun, just keep a few things in mind:

• Take a shower - I've had people come in that I can smell. If the interviewer can smell you, you're not getting the job.
• Don't lie - Either in person or on your resume, you will get called out on it, you will look like an ass, you won't get the job.
• If you don't know, you don't know - If you're asked something you don't know, say you don't know. It may or may not be a deal-breaker for the interviewer but it's always a deal-breaker if you lie and get caught in it.
• Show enthusiasm - If you act like you don't care about the job now, what's to say you're going to care after you're hired?
• Be confident, but not cocky - I actually had to learn this the hard way. You might "know in your heart" that you're an above-average developer. You may think you're the best candidate for the job. But you know what? There will always be a better programmer than you and the best programmers are always aware of this. People that are cocky come across as someone that will be hard to work with and will poison a team's morale. Humility is key!

When Things Don't Work Out

You've done your homework, the interview went well (well, you're pretty sure anyway) and yet you get that call/email saying "thanks, but no thanks." It happens. It's happened to me and maybe I made it happen to someone else. Maybe you didn't say a magic word the interviewer wanted to hear. Maybe another candidate out-awesomed you. Maybe the interviewer just didn't like your face. You might find out why but most likely you won't. Just try to make sure that you're more prepared next time and stop being a cocky shit during the interview!

When Things Do Work Out

After you've nailed that new job, keep in mind what you had to go through to get it. Don't let yourself get complacent. Stay informed of new technologies coming out. Get involved with the development community on and offline. Be grateful that you have a job doing something you love but always be ready for when you need to move on.

Shared Stuff

I'm still alive!  Had a bunch happen in the last month or two so I've been a bit busy.  I have a longer post coming up that I'm still working on so here's a little something in the meantime.

I like reading blogs.  But I also like to read blogs socially.  How is that done?  By sharing what you read and commenting on them!  Here is a feed of the stuff I've shared out in case anyone is interested.  It's mostly developer-like stuff but it has a healthy dose of random stuff I just found to be funny or insightful.

Working Yourself Stupid

"Ability to contribute over the standard 40 hour work week if deemed necessary by management but more importantly thru self motivation when extra time is required to get the job complete."

This line came from a job posting I saw the other day which made me chuckle a little.  At first I was a little shocked to see that a company almost requires overtime (I'm assuming it's not an hourly paid job) but then I thought, at least they're being honest.

So why would that be so shocking?  Well, where I'm currently working we're trying to be agile (well, most of us anyway) using a combination of Scrum & XP and one of the practices we've tried to follow is sustainable pace.

In a nutshell, sustainable pace is finding the right amount of hours people should work without ever burning out.  This provides, amongst others, a few benefits such as:

• Little to no burnout
• More accurate estimates
• Employee job satisfaction

Right now I'm happy to report that I generally don't have to worry about working crazy hours to get things done in my department and I think we've been reaping the rewards as well.  There was one time where we deviated from this principle and paid for it in the end.

What happened was we were getting behind on some defects that needed to be sorted out and so we decided to take a few weeks to put in some extra hours to pound the defects through.  We worked hard on them and at first it really seemed to be making a difference as the defect count went down quite a bit.  Satisfied that we had beaten back the beast, some people laid low to recover from the push and a month later, we were back to where we were before with the number of items that needed to be worked on.  We have since tried to be a little more selective with what we work on so that we get the most bang for our buck rather than trying to brute force our way through things.

Now, I'm not saying that ALL overtime is bad.  There are times where working a few hours here or there can prevent last minute problems from happening, etc. but be prepared for the time needed to recover from that extra push.  Taking that time to recover can be hard to do as well as everyone likes to be a hero and putting in that extra time sure looks good to management.  But if you burn yourself out to the point where you're not worth much, you won't look so good anymore.  Be honest with yourself.  Be realistic.  Plan better next time.

If you happen to work for the company that the job posting came from or you are currently working somewhere that requires extra hours, have a look at this (very, very interesting read) and plead your case to management.  Worst thing they can do is say no and then you can make a decision from there.