jQuery: .attr() and .prop() what’s the difference?

In jQuery, you can use the .attr() method to get or set the value of a DOM element’s property. This is usually things like .attr(‘type’) which for a text box would return “text” b/c WHOA, that is what is literally written in the type attribute. Attr is short for attribute. Makes sense, right?

In jQuery versions 1.6 and later, .prop() is another method you can use to get and set properties on DOM elements. For a while (in my addled brain) the two methods attr and prop seemed to be nearly the same thing. Well, it turns out they can be, but not always, which is why I didn’t get it for a while. What is this voodoo? Well, here is the difference:

.attr() is the initial value on an element, so whatever is written in the code and rendered when the page is loaded.

.prop() is the current value of an element’s property, including any updates. So if AJAX or javascript is involved, and changes the value of your property, attr is the token old guy of the bunch, who only cares about the good old days, and prop is the young whippersnapper who doesn’t have a firm grasp on history.

jQuery: Star Wars

I know, I am a silly silly nerd. I don’t care. #dealWithIt

$('* > .wars').newHope(function(empire){
  // empire calls back
  if(empire==true){
    var jedi = true;        
    return jedi;
  }
});

Connect Nitrous.io to Bitbucket Git SSH Public Key

This is a frequently up-voted post on Stack Overflow I wrote on a little-known problem you may have trying to use Nitrous.io with BitBucket or other external code repo service.

If you can’t connect your Bitbucket git repo to Nitrous.io, and you see errors like this:

Permission denied (publickey).
fatal: Could not read from remote repository.
 
Please make sure you have the correct access rights and the repository exists.

At first it seems like bitbucket wants your computer’s public key in Nitrous and Bitbucket to connect them, but that doesn’t work either.

All you have to do is:

Go to your nitrous box (IDE or Terminal), and run this:

cat ~/.ssh/id_rsa.pub
which will display the Nitrous SSH public key (not your computer’s public key, but the one for that box).

Go to Bitbucket > My Account > SSH Keys and paste the Nitrous key in. Be sure to name it Nitrous or something like that so you know what key it is later. Then your repos will connect just fine. You are literally using an “in-cloud computer” so that computer’s SSH key needs to be in Bitbucket so it “knows” your nitrous instance as a friend. Normally you’d think of your SSH key as being something on your local machine, and in this case, I got my wires crossed because the “local machine” in question was actually a “remote in the cloud local machine” and that fried my brain. If yours was fried too, this should help.

My apprehension with TDD seems to be correct

So, I have for a long time been somewhat apprehensive on TDD as a programming practice, not sure I see the value in it. It is a major time suck for not a lot of return on investment for me. I just don’t think the result is enough to warrant me spending time on it. Apparently, I was on to something there.

Sure, testing is huge for any app, but I favor the real-world version. Sure, it isn’t as nerdy or scientific, but it works for what you need it for most of the time. It isn’t a perfect solution, but I think TDD many times introduces more complexity and takes up time I’d rather spend writing actual code that effects my app, my users, my company’s bottom line. That is what matters to me. It seems my reasons for not selling my code soul to the TDDevil are warranted.

This year’s railsconf keynote brought DHH (as usual), who is the creator of rails and probably the most respected programmer I know of. He basically shot TDD in the face as not being all that worth it after all. We’ve put too much emphasis on something other than the main thing and TDD is the culprit. I’ve been asked to research whether TDD was a good idea, and in the past my answer was basically that I don’t see the value.

For more, check out DHH’s excellent post: Test-induced design damage

jQuery: What background images should I pre-cache?

If you’re trying to pre-cache images with javascript, you’ll need to know which images are actually being loaded to add them to your preload array. Here’s how to list image your page is using with a nifty bit of jQuery code.

I am using this code from Stack Overflow to pre-cache images (to make them load faster) in my page:

<script>
$(document).ready(function(){
    function preload(arrayOfImages) {
        $(arrayOfImages).each(function(){
            $('<img/>')[0].src = this;
	});
    }
    var imgroot = '/assets/img/';
    preload([
        imgroot+'image.png',
        imgroot+'image2.png',
    ]);
});
</script>

And here’s how to find all the images your elements are using as background images:

<script>
$(document).ready(function(){     $(*).each(function(){         console.log($(this).css('background'));     }); });
</script>

Please note that if you are using “background-image” in css, instead of “background”, use that inside .css() instead, like this .css(‘background-image’);

It is good practice to use all background images on elements in your page (or so my front-end guru friend tells me). This code comes in handy when you follow that convention.

The * (the star selector) in CSS means “all elements” so this may make your page lag badly, depending on how many elements it has to go through to find and output the background of. You can use div instead to only get the background images for divs, if that is what you are using. Also, don’t forget to remove this code in production b/c it will make your page lag for visitors.

Galaga Code, Baby!

Screen Shot 2013-03-20 at 5.35.21 PM

galaga-code-blurred

This is something that only happens to the geek elite. People recognize your code as a throwback to oldskool nerdy video games. This was just how the code ended up, this isn’t a plant. It was just pure awesomeness at it’s best. The cool kids call this “elegant” code. That’s right. This is how you know you’ve made it into the upper echelons of geekdom.

Back story: David is the best front end engineer I know and a total web dev badass. We nerd out about Doctor Who, sci-fi, code and other geeky stuff daily.