When life gives you lemons…

Make lemonade. Don’t bother because those weren’t lemons you got.

My day started off pretty well. I slept in until 11AM. I spent an hour on YouTube checking out what multiplayer looks like in Modern Warfare 2, which looks like an amazingly awesome game. I’ve been waiting for it since I first played CoD4 two years ago. Now that it’s finally out, naturally, I am forced to wait. I ordered the game on Amazon and debated having it delivered to my apartment, but decided it represented too much of a temptation to not do work and had it shipped home instead. Since I obviously am not able to be at home on a Tuesday, I decided not to waste money on release-day delivery. I expected, due to the game’s popularity, that it probably wouldn’t get delivered until some time next week and I wouldn’t be able to play it for another two weekends. Then Amazon got my hopes up by sending me an email saying they had shipped it. Of course, what that really means is that they paid for the postage and assigned me a tracking number, not that they’ve actually put it in a box and kicked it out the door. The USPS says they still don’t have the package yet, although they’ve been told to expect it. This, of course, is absolutely meaningless because the USPS tracking system sucks. I’ve actually been holding packages in my hand before the USPS tracking system even acknowledged the existence of said package.

Moving on from that aside/rant, I then got an email from Professor Claypool saying the second Networks homework is delayed until Monday. This made me especially happy because I finished project 1 and lab 2 yesterday, and the Webware homework due Friday doesn’t look particularly complicated. I figured I’d be able to spend all day on the IQP and make some serious headway.

Yesterday: Basically, we’re declining the help because it doesn’t look like we need it. Although with my luck, something disastrous will happen and I’ll be eating those words…

Today: I hate it when I’m right.

No, I’m not considering reversing that decision, but something disastrous (kinda) did happen today. The top priority currently is a significant refactoring of the SOAP service, specifically, the data types it uses, in order to eliminate some confusion that had developed and to streamline things better (I talked about this in a post last week). Well it’s usually not a good idea to make lots of massive changes at once. It’s easier to do things piecemeal, changing and then testing a few things at a time in isolation. In this case, it turns out we have no choice but to do it wholesale.

See, my plan was to tackle one SOAP operation at a time, which would mean that the base data types (things like Project and CompanyPermissions) would remain unchanged until the refactoring was mostly complete, at which point the data overlap would be eliminated. Well, the first operation I decided to tackle was getting the per-company permissions for the logged in user. I fixed everything up, compiled the app, ran it… and watched it blow up in my face.

It took me about half an hour to ascertain the first part of why: the object I was pulling out of the ArrayCollection was somehow null. It took another half hour to figure out that the reason it was null was because the type cast was failing. Remember: no generics in ActionScript, so when you pull an object out of an ArrayCollection, you have to cast it to the appropriate type. It took about five minutes on Google to figure out how to get the class of the object, which turned out to be ObjectProxy.

*shakes fist* OBJECTPROXY!!!!

Yes, for some reason, instead of giving me an object of the appropriate class, Flex decided to give me an ObjectProxy that was sort of like it (but not really) instead. I went around in circles for about four hours trying to figure out why, since this behavior doesn’t appear to be documented anywhere. It just wasn’t logical: the SOAP service returned an array of CompanyToCompanyPermissionsMapping objects. Said objects contained a string and a CompanyPermissions object. Whoop-de-friggin-do! The getAllResponsesForProject operation creates a map in the exact same way and it doesn’t have this problem! WTF?!?

I knew there had to be some difference between the two that caused them to be treated differently. Eventually I got so frustrated (and hungry, because it was approaching dinner time) that I decided to go get dinner and come back to this after. This method actually works remarkably well for me: I get frustrated over a problem, say “fuck it”, go do something else, and then have a brainstorm as to what the problem is and how to fix it. Today was no exception. As cliche as this is, I was standing in the shower when the light bulb finally appeared over my head (and I swear, it was audible!).

Yes, it turns out that Flex decides to be a jerk and give you fake objects only if the object contains another object nested at least two levels inside it! The operation that worked didn’t have this: it’s a map from a User to a ProjectResponse, both of which are contained in some other objects but neither of which contains any other objects. The operation I was trying to refactor was returning a map from a string (a company name) to a CompanyPermissions object. Since I was trying to do the refactoring piecemeal, the CompanyPermissions object still contained a User object. By the end of the refactoring, this would be eliminated, but I needed to leave it in temporarily so that other parts of the application using the class for other as yet unrefactored operations wouldn’t become uncompilable.

So, to sum it up:

Fine: UserToProjectResponseMapping, which contains a User and a ProjectResponse.

Not fine: CompanyToCompanyPermissionsMapping, which contains a string and a CompanyPermissions, which contains a User.

Hence, the only way to accomplish the refactoring is to do it wholesale and change everything at once, so we don’t have any class containing two levels of nesting at any point. I’ve tested and confirmed that this is the cause. It would be really, REALLY nice if you had actually, ya know, documented this little “feature” of yours, Adobe! Or better yet, never have implemented it at all! Honestly, whose brilliant idea was this?!?

Anyhow, I can’t pick up where I left off, having discovered this, because the process of making the discovery has left my working copy of the project so mucked up that I can’t remember what I’ve messed with or where. So I’m going to revert to the base revision copy and begin anew. I don’t know if I’ll manage to finish this refactoring by the end of the week. If I do, it’ll likely be the only thing I accomplish this week for the project. I’ve been trying so very hard not to have any more “infrastructure” weeks and I especially wanted to start working on the analysis functionality. Clearly, that isn’t going to happen until next week at the earliest. Just as I was a little swamped with Networks this week, the first Webware project is due at the end of next week. It’s being done in small teams, and I don’t even have a full team yet, never mind actually writing any code. *Sigh* Anyhow, we’ll see how this pans out.

I’m contemplating creating a page on Wikipedia discussing the causes, symptoms, and (lack of) cures for actionscriptophobia, the completely justified fear of anything involving ActionScript, which I believe this latest incident has caused me to develop. Good idea? Let me know in the comments.

Advertisement
This entry was posted in Epic fails, IQP, rants. Bookmark the permalink.

One Response to When life gives you lemons…

  1. Pingback: Flex Sucks: Greatest Hits! « CaptainRichard's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s