Running On Empty

A friend of mine told me about an experience with their child psychologist the other day. It was mostly about dealing with teenager issues but one thing they mentioned that I found interesting was how every child has a sort of "love cup".

The idea is that every time the parent plays with, compliments or encourages the child as he/she grows up, another drop is added to the love cup. Any time that the parent ignores, tears down or hurts the child, drops are removed. If the parent removes too much from the love cup, the child will respond in unfortunate ways such as rebellion, anger or poor self esteem. If the cup goes beyond empty (negative), the child may become self-destructive which would require a lot of drops added to the cup to even get to empty.

It's an interesting theory which I've found to be true not only with observing children of friends and family but my own children as well. With every drop added, the more I see children respond positively to their parents as well as being happier overall.

Hearing about this idea of a "love cup" made me think about how I should spend more time with my children but it also made me think of how applicable this is at work. I would still consider it a "love cup" at work (because you love your job right?) but it probably sounds better as a "trust" or "satisfaction"cup.

Satisfaction Cup

I know that when I start with a new employer, the sheer excitement of starting somewhere new fills my cup most of the way. New people, new environment, new challenges and new code bases always seem to do it for me and most developers I know.

Once the honeymoon period of a new job is over, things start taking drops from the cup:

• Management issues
• Nasty legacy code
• Team issues
• Interoffice team issues
• Not enough to do/boredom

It's funny, the things that add to the cup are the exact opposites of what takes from the cup. I've seen good managers turn teams around. I've also seen strong teams wade happily through some of the nastiest legacy code simply because they enjoy hanging out together. As long as the cup is being filled faster than it's being emptied, a job can be satisfying.

But what happens when the cup goes into the negative? That's usually when one starts becoming toxic and although it may be possible to turn things around, I've found it's usually a sign that it's time to start looking for other employment.

Know Your Cup

If you find your cup draining faster than it's being filled, let someone that can fix the problem know. It's sad when someone is struggling and those that can fix the problem don't know about it. Actively look for ways to stop the hurting and if your cup fall into the negative and you notice yourself becoming toxic, take the time to decide if it's best to leave before burning too many bridges.

It's an interesting theory and I'm curious as to what others think of it. Does it resonate with you? Am I way off? What fills your cup? What empties it? Let me know in the comments.

Image © Parrus | Dreamstime Stock Photos & Stock Free Images

Maximize Your Commute With Podcasts

I have a commute. It's not a long commute, but long enough (20 minutes-ish). Although I enjoy listening to music while driving, I've found that my time is better spent listening to something educational or interesting through podcasts.

How Do I Listen To Podcasts?

With the advent of smartphones, subscribing and listening to podcasts is super easy. I've never had an iPhone but I've seen that there's a podcast app in the App Store that should be sufficient (correct me if I'm wrong). For Android, Google used to make a nifty little app called Listen but has been discontinued. The app I'm a big fan of right now is the Car Cast Player app. It's made for listening to podcasts in the car and it does it well. There are other podcast players in the Google Play store but this is the best free one I've found.

The way you subscribe to a podcast is much like subscribing to an RSS feed. Most podcast players will have a way to either search for podcasts or link up to one through a feed URL. For example, if you wanted to subscribe to Hanselminutes, I would first go to the site and find a subscribe link. Sometimes you can just hover over the link to find the feed URL that you can enter into your podcast player. What I like to do is to actually subscribe to the feed into Google Reader so that I can read the show notes later. This also makes it easy to refer to the subscription link later and verify that your podcast player is pulling podcasts correctly.

So What Do You Listen To?

I created a nifty page that I'll try to keep up to date here. But here's the short list version relevant to right now:

• .Net Rocks!
• Hanselminutes
• Herding Code
• Javascript Jabber
• Ratchet And The Geek
• Ruby Rogues
• Software Engineering Radio
• This American Life
• This Developer's Life

If you're not a programmer, find something you're interested in. There are a TON of podcasts covering whatever subject you may be interested in. So go forth and maximize your commute! Listen to some podcasts!

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.