I want my job to be just a job and not something I enjoy doing or something I take pride in doing. This way when one of my coworkers decides he wants to be a total prick to me, I will not want to scream/cry/scream some more.

Here is a picture drawn with my mouse to express how I feel today.

And here is a rage comic about what transpired.

alert("OMFG Why are you not catching you piece of crap. I hate your stupid face");

or the super fun “I wonder what this variable is returning…” alerts that may or may not contain 1000 data point sets and create the scariest looking popup ever.

And woooo, can you imagine if that accidentally get’s pushed so a client can see it. I wish I had a funny story about that happening, but beyond a team member accidentally writing Blah on a test page and it getting pushed, I haven’t had first hand experience.

Anyway, instead of alert, use Firebug, open console and in your code write

console.log("OMFG Why are you not catching you piece of crap. I hate your stupid face");

Oh noes, but what about when IE is my debugging nemesis! Well don’t worry because Firebug lite is there to help you out.

And if you need even more from your console.logs like history and preventing array wrapping, you can use helpful wrappers like this one that Paul Irish made.

Chances are that if your logs accidentally get pushed and the client opens firebug and sees them, they are probably another idev working long tiring hours for the man and you can high5 about it sometime and talk about your favorite stackoverflow threads and the cutest cats of reddit.

TL;DR
Using alerts to test code is a bad idea.
Using console.log might make you super friends.

HTML5 rocks!

Deathbear = me.

I’m finding that performance is in jeopardy based on the size of the json files as well as the number of calls that are made, so I’m trying to figure out that’s the best way to approach this. All of my visualizations are plotted on 2 dimensions, ie: [longitude, latitude], [distance,time] etc.. So a lot of my json returns look like this

{
    "data": [
        [
            1,
            2
        ],
        [
            2,
            2
        ],
        [
            3,
            2
        ]
    ]
}

These arrays are easy to plot and require little adjustment to work with the graphing plugins, but I’d have to make lot of calls to populate every graph.
So one way to deal with this is to lightly modify and reuse json arrays that I get from the back end so that I can use them in multiple visualizations that are on the page. This involves a little more data fondling on my end to get everything to work and that’s where the .map() method comes in.

{
    "data": [
        {
            "lat": 1222,
            "long": 32323,
            "distance": 12,
            "time": 0.35
        },
        {
            "lat": 22,
            "long": 323,
            "distance": 19,
            "time": 0.45
        }
    ]
}

What .map() does is take an array and then remap it into a new array. For distance, long I would take the json array above and change it to

var data =[];
data =$.map(json.data, function(n){
return n.distance;
});

Which should return a new array with [distance, distance, distance] point sets.

FUN FACT: There is a bug with $.map where it always flattens your array, making tuples impossible and making Sues pull their hair out.

The way I tackled this issue for a recent project was using $.each().

var longLat =[]
$.each(json, function(i, val){
longLat.push([json[i].long, json[i].lat]);
}

Which gave me longLat= [[long,lat],[long,lat],[long,lat]]

When I need to create a new array containing multiple arrays of point sets I use .push without an each instead.
IE- I want this:

{
    "metric1": [
        [
            1,
            2
        ],
        [
            3,
            2
        ]
    ],
    "metric2": [
        [
            "blue",
            1
        ],
        [
            "green",
            2
        ]
    ]
}

to become: data = [ [1,2],[3,2] ], [ ["blue",1], ["green",2] ] ];

Then I would write:

data =[];
 data.push(json.metric1);
 data.push(json.metric2);

This is helpful if you are making multiple calls for datasets and need to put each into the same array. I will eventually put visualizations up so this makes more sense.

My best friend on this project has been JSONlint, making sure that my json returns weren’t total crap. And often a ” or a } was missing in a 1200 line return, which would be impossible to find without it.

I was asked about URL encoding today in case we have slashes in the User IDs we are passing, which who knows on this project considering the other team is not getting us real UIDs to work with… Whole other diff bitchfest there which may end up being called “Fake Agile projects.”

Dave linked me to this jQuery URLencoding plugin and asked if it was decent. I said that I was unsure. Honestly I have never encoded URLs in javascript and did not know it was BUILT IN to the language. I asked the iDev chatroom what they thought and got a tag team of why wouldn’t you use “decodeURIComponent()“.

var url="http://mysite.com?name=stfu&snarkyopinion=do/not/want";
document.write(encodeURIComponent(url));
//gives me:
//http%3A%2F%2Fmysite.com%3Fname%3Dstfu%26snarkyopinion%3Ddo%2Fnot%2Fwant
Why wouldn’t I use it? Cause I didn’t know it existed. I’m self taught and trying to get my comp sci masters NOW. There is a lot of things I DON’T KNOW. Why do people have to be dicks about it?

Like for instance I won’t to your face tell you that your use of CSS is fucking criminal, you architect things assbackwards and you’re 2 positions above me. You win, you knew about encodeURIcomponent before me.

Monday. Hate people.

git push origin master –force *

I am not sure if this was the exact command used to write over everyone’s work this week, but so help me god if I didn’t want to bean that guy in the noggin with the nerf ball after I pulled from the respository.

The man at the bar watches him flirt and buy rounds and flash bankrolls of money and get all the attention in the room for an hour before getting up the nerve to approach the man.

“Excuse me, Sir…” he says, “I have to ask…I see you here with all these beautiful women, and all this money, and all this attention…but I noticed you have an Orange for a head. How did all this happen for you?”

The man with an Orange for a head replies “Well I was walking on a beach one day when I found a magic lamp. I rubbed it and a genie popped out and granted me three wishes.

First, I wished for all the attention from the hottest women in the world.

Second, I wished for an unlimited supply of money.

Third, and this is where I kind of fucked it up, I wished to have an Orange for a head.”

Did you know IE hates 1px X 1px repeating transparent background images? Well it do. Pain in my ass. You can make it 1px X 2px, or 1px X 3px and watch a significant performance increase, but don’t you dare make it 1X1 or you will get a bizarre gradient effect in your background expanding out from the top corner.

Check these out in IE
1 x 1

1 x 2

Now that I’m home on a computer that functions, opposed to my work computer which frankly is a piece of shit, I noticed this issue is gone in IE8. I’ll double check IE7 native tomorrow on the ol’ crapbook.

That was not a fun bug.

I learned a valuable lesson this week. “Just say no”

I am currently working on a project where the client is moody and grumpy. It doesn’t help that I, too, am moody. Take that and combine it with a project manager who probably gets 3 hours of sleep every week due to new baby screams, and a Client Partner who gives me douchechills, this project has not been fun. In fact it may be the worst project I’ve ever worked on in my entire life.

With a moody client, the managers tend to want to give them whatever they want, without thinking it through. I’m a big fan of “NO.” Scope creep? No. Work weekends so a CP can get a bonus? Um… no. Give into insane requests? No.

Unfortunately I am so tired of this project, I gave in and minified a bunch of files before we were done with QA because the client was worried about performance and making a big deal about it. Or rather, my PM was. I was/am miserable, and all I want is to see the light at the end of this tunnel. It’s not even rewarding work. It’s not fun or challenging, unless you consider the dev environment being so volatile it could explode any second challenging. I don’t. I hate when you can’t estimate how long it’ll take to complete a task because there are too many outside variables. The site could be getting attacked by hackers who don’t like the client’s policies. Their IS team could have upgraded their system and not warned us. Someone could have checked in bad code over night in China or India. Someone could have checked in bad code locally.

This project is like a bomb and every commit or update is another wack from a hammer.

Anywho, when it comes to minimizing files, I like to do it a the end of QA. That way it’s easy to tell if minizing broke things, opposed to the 50 other code changes you made that day.

I spent at least 10 hours on a bug for IE trying to figure out why my code from last week was completely screwed up. I had to read multiple client bugs were the QAers wrote how things FAILED and bitched. All because of zoom:1px; which should have been zoom:1; The client is more upset & to appease them the managers seem to make things worse.

Sure, these things happen on every project. This project is just the worst of all time. I am so tired and so burnt out. Beyond the initial meeting in Nov where there was a chance we might use Dojo instead of jQuery, I can’t think of anything good about this project. All it’s done is make me want to boycott the client’s products.

Playing with a javascript and canvas toy called Harmony.