Link: Painless Merge Conflict Resolution in git

Just sharing a quick link today, because I found Painless Merge Conflict Resolution in git to be an extremely useful, descriptive article on resolving merge conflicts in git.

Javascript - so unobtrusive I can't even find it

Ok, so, what's the problem with obtrusive javascript?

Near as I can tell: it's a bit messy having all your js intertwingled with the html. Much like the once-dreaded embedded font tags - for which stylesheets were a wonderful invention. They pulled everything out of the way and kept them in one place , which cleaned things up a lot.

Enter: unobtrusive Javascript. Your JS is tucked away neatly, and placed onto your active DOM objects via id-tags et al - just like your stylesheet.

What are the down sides?

Well - lets say there's some magic JS doing something with the Foo element on your page... only there's a bug in it and it needs fixing ASAP. But all I know is which part of the page is being updated - I have no idea where the JS is located. The KS-functionality appears like magic from.... somewhere.

Lets complicate things (like real life) and say I'm new to the project, and the previous developer quit and is now living on a beach somewhere in a non-extradition country... so I can't ask them.

How do I actually *find* the JS that is unobtrusively messing with my html element?

It's ok if there's just one JS file that does a few things, or if you have a JS file per HTML page or some other sensible way of finding out which JS belongs on what page... but if you're coming onto the typical legacy project, you've got dozens of JS files with uncommented JS code for adding, removing, showing, hiding, dragging, dropping elements willy nilly - some of which are no longer used and who have useful, non-unique names like "move_stuff" or "display_items".

Sure, I can grep across the project for the ID of the html-element in question... unless the JS is operating on it via the DOM (eg every second child element of a td from a table that's inside the third div from the left...). But it's a little awkward.

There's also one other problem. Let's say I *don't* happen to know there's any JS operating on this element, and I update the html without even realising there's some accompanying JS to update (remember, I'm new to the team, and the former developer wasn't much for commenting).

Now the html and JS are out of synch. The JS is almost certainly broken, because I've just moved that html element into the second div from the left and nested it inside another table... and I will never know it was supposed to "display_items" then "move_stuff"... until Joe Random User suddenly notices that he can't submit the end-of-year accounting because the submit button no longer magically appears when he's finished filling out and validating the form (or whatever).

Clearly there are some benefits of the JS being tucked away out of sight (it looks prettier, which makes the html easier to maintain) but there are also clearly some disadvantages (it makes the JS itself difficult to maintain - two separate files mean a synchronisation-problem).

So, what's the solution?

As ever in design for computers, there's a balance/tradeoff involved, and your decision will probably involve a sightly different balance to what we do.

Personally, I like keeping the JS alongside the HTML it operates on. Sure, don't have it entangled in the html, but you *can* have your JS near the html that it relates to and still have it take into account the aspects of unobtrusive JS. ie the JS still adds to your HTML elements by using ids and DOM-paths... but the actual JS is either in the same template as the HTML (at top of bottom of the file), or is in a partial that's included into that template - so you always know it's there.

I'm sure it's far from the "perfect" solution... but it works for me, and makes it less likely that I suffer from the two problems outlined above, ie that I:

1. can't find related javascript
2. don't actually realise there *is* related javascript to keep in synch

What solutions do you use?

Link: On technical entitlement

A Post by Tess Rinearson called On technical entitlement, has provoked a bit of a stir in reddit.

Apparently some posters consider to to somehow be emasculating... which is ironic, as the whole point of the article is to show how the behaviours of some people in the industry has an effect of destroying self confidence... and not just for women.

In my mind the only reason why the "women in tech meme" (as one commenter complained about) even shows up in the article is because the poster just happens to be female and it was a convenient example of the *general* problem that tech-entitlement seems to cause.

I think the discussion has been blown way out of proportion to the original article - which is an interesting look on one way that we can all think about our own behaviour (me included) to help newbies to the field feel more comfortable with being the beginners they are (and are allowed to be!).

What I took out of the article is that next time I meet somebody who's new to comp sci - I shouldn't try and "impress them" with my own l33t skillz to make myself seem big. Because often all that succeeds in doing is to make somebody else feel inferior - and that's *NEVER* a good thing. Instead try to encourage their own love of problem-solving ability, starting from where they are right now.

Snippet: Array#to_hash

I've been finding this quite useful - especially when partition just isn't enough:

    def to_hash(&block)
      return {nil => self} unless block_given?
      the_hash = {}
      self.each do |val|
        key = block.call(val)
        the_hash[key] ||= []
        the_hash[key] << val
      end
      the_hash
    end

Usage examples:

   [1,2,3,4,5,6].to_hash {|v| v % 3 }
    => {0=>[3,6], 1=>[1, 4], 2=>[2, 5]}
   Widget.all.to_hash {|w| w.status }
    => {:pending => [<Widget1>,<Widget4>], :complete => [<Widget2>], :awaiting_approval =>[<Widget3>]}