BUG: Flash Google Analytics trackEvent

Today I was integrating with Google Analytic’s Flash codebase and ran into a bug that had me running up against a wall for about 45 minutes. It was a simple bug, but no details bubbled up from the code base to let me know what was occurring. I’m noting it here for everyone else’s sanity. If you want to skip all the details and just know the cause jump down to the end of the post.

SYMPTOMS
I had set up my analytics package all via code and made a simple track call.

For the sake of this example, it looked equivalent this

 import com.google.analytics.GATracker;
 
// setup tracker
 var tracker:GATracker = new GATracker(this, "UA-111-222", "AS3", true);
// make simple track event with a numeric value
 tracker.trackEvent("MyCategory", "MyEvent", "Title1", 10.5);

Very simple right? I had followed examples online and on the surface it all appeared to work correctly. I could see the calls in the visual debugger working exactly how I wanted. However, when looked to see if the calls were going to the server with a packet sniffer, no dice! Nothing was going through. I checked my code about 500 times, looked to see if trackEvents were just beta, and tried to find out if I wasn’t setting something for production.

DEBUGGING
I couldn’t find anything. It wasn’t until I switched the call to trackPageview that it started to go through. That worked. I decided to take the numeric value out of the call for the trackEvent call, since that was a variant between trackEvent and trackPageview. Ching, ching, little winner. Everytime I added it back in it failed silently and didn’t call the server. I then noticed that the number was a fraction and not a Integer (even though the call’s signature has it as Number). Therefore I decided to round the fraction everytime, and triple ching, we had the final winner.

CAUSE
The bug turned out to be that trackEvent can only take Integers as the numeric value in it’s call. If you make calls using trackEvent you must round all numbers going in or the calls will not be sent out to the server.

Hope this helps with some folks headaches. Also if you ever have a bug with no details, follow the example above and work backwards. Looking at variants and testing multiple inputs you can find the root.

Teams, Chad Fuller, and Business Investments

CHOOSING A TEAM

Owning and running a business, the most important elements to your company are your image and the people working with you. This is even more important when you are a smaller business. If you are surrounding by the best of the best, that becomes the perception of what your company is. A small agile company composed of experts is a lot different than a large company with a few experts and a lot of worker bees. Both are valid models and neither is right or wrong. I opt for the quality over quantity approach, regardless of the income difference.

Therefore, when looking for folks to work on projects or to join the team, I look for people that are:
a) smarter than I am
b) completely devoted
c) care

It’s a decision that I don’t take lightly since I’m essentially asking someone to join a “family of friends”. That’s how I view work. It is part of your life, the people around you are part of your life, and you should surround yourself with those that bring out the best in you and themselves.

CHAD FULLER

Last June, Mr. Chad Fuller sent me a note mentioning that he was moving to Atlanta. I knew Chad well, knew how smart he was, but also knew that he didn’t have any work experience. Point blank, experience is huge for us. Due to the positioning of Dreamsocket, we typically receive jobs I would refer to as high experience work. Thus, we can’t have people work on the projects who don’t know the technologies better than they know their own name. It is our position and what we’ve built the business on it. So Chad was in a way a gamble. Obviously there is risk with any gamble. You either win or lose. However, I took a pretty calculated gamble and came out ahead…. way ahead. If I were in Vegas, I would probably be the owner of the Wynn right now ;).

How did I win? Instead of throwing projects at Chad he would tear his hair out with, I decided to invest in him and the company. Chad’s first project was dreamsocket.com. If you haven’t looked at the site yet I highly advise that you do. Not out of self promotion, but to see what he accomplished. Before the project, Chad had never touched HTML or built a website. After the project he could boast a site that included a store front, live docs, bug tracker, and more all under one dynamic system. Needless to say, I’m more than impressed. Being able to own and shape it himself, Chad really was able to take value in his creation and learn a lot (at least I think he did ;)).

INVESTMENTS

Since the site was an internal project, it was an investment. We invested in defining our image more concretely, creating a way to extend our business, and developing ole Chad. Personally, I know what its like to run in his shoes. Developers that care want to learn as much as they possibly can, to work on great things, and just enjoy what they do. It felt really good to give him a project that he could call his own, mold it, and learn from. That is really what being a business owner can do for you, it can help you help others.

As much as the business will let me, that is what I intend to do. Invest in the folks around me. If your folks have passion, let them run with it as much as you are able to afford. Your workers will grow in strength, which will in turn mean that you get an experience level you couldn’t get any other way. On that note, Chad got the IPhone bug and I’m letting him get all over it. It means diversification and it means he continues dealing with things he is really excited about. Wait and see what he’s got running ;).

Look for big things on Chad’s blog and our site

Event type naming: qualifying vs simple

I have put a lot of thought into event naming recently. In my research, I’ve seen a few developers fully qualifying their event type names. This is something I actually debated myself when writing our Media Framework, but opted not to do. The subject is debatable, so let me describe what I mean by fully qualified names and why I decided not to use them. Based on the points I outline you can make your own decision of whether to use them yourself.

What is a fully qualified event type name?
ActionScript 3 has a formal event framework where objects dispatch events and others subscribe to them and react accordingly. Each event dispatched is represented by an event object. All of the native AS3 event objects follow a formal convention of defining the types of events they can be dispatched as. This convention places a static constant representing the type name directly on their class to allow for strict typing. For example, Event.RESIZE denotes an event type of “resize” for the flash.events.Event object. The property value itself equates to a simple string. In all native AS3 objects these strings are simple and only represent the action (ex: “resize”).

Some programmers are actually fully qualifying these strings. Instead of Event.RESIZE representing the string “resize”, it is equal to “flash.events.Event.RESIZE”. Now why do this? Well say you had another event ComponentEvent which had a resize event. If you fully qualified it as well, you would have ComponentEvent.RESIZE equating to “com.dreamsocket.events.ComponentEvent.RESIZE”. Notice that now both events could be thrown from the same object and subscribed to distinctly. If they both represented the string “resize” then you would run into cases where you thought you subscribed to one event but would potentially receive both.

Why I chose not to use full qualifed names
Even though fully qualifying the string that represents the event type resolves subscription conflicts, for the most part you can resolve them just by prepending your event’s name to the type. ComponentEvent.RESIZE could be “componentResize”. In a sense this allows you to qualifying it without having a very long unique string. This is what I opted to do. One of the reasons I did this was for less advanced users and for code spiking. Simply, if you want to do things fast, it is easier just to type in a short magic string when listening to an event vs actually importing in the class and typing it out statically.

foo.addEventListener("componentResize", this.onEvent);

vs

import com.dreamsocket.events.ComponentEvent.RESIZE;
foo.addEventListener(ComponentEvent.RESIZE, this.onEvent);

Yes, this is kind of the lazy approach and one might also say its bad practice since without strict typing it could result in a “magic error”. However, I do it when I’m trying to spike an idea real fast, and I know others do it as well. I’d even venture to say designer/developer hybrids are especially prone to use it since it serves as a comfort concept they brought over from ActionScript 2. It is a practice that exists and I can’t say whether it is right or wrong.

Summary
In summary, fully qualified event types have a purpose and serve their purpose well. In our case, we wanted to take into account developers who were used to exploiting existing conventions. I feel even bad habits have advantages if it creates productivity, so the coin toss resulted in a choice not to take them away.

What are your thoughts?

Blog Facelift

Yesterday I had Dreamsocketeer – Chad give this blog a much needed face lift. Unfortunately, I let it go to long with a dated default look that made it hard to read some entries. Obviously, most people just grab the feeds through a reader, but for those making the trek to the site it made sense to give you something that appealed to the eye. In addition to lovely new “clothes”, I threw in some additional social links of mine in the navigation for those wanting more info on who I am, what I do. Enjoy the new lovely!