Feb 24, 2016

An Exercise in Pair Programming

I've spent many years as a software developer working in contented solitude: wrapping my mind around spaghetti code; stepping through a debugger; implementing an algorithm. I'm an introvert, so I'm comfortable being alone.

The past few years, though, I've felt pulled to collaborate more with others and to participate more actively as a member of a team. I've done this by communicating with end users, clients, and non-technical team members as well as doing informal mentoring and teaching.

I've known about pair programming for some time but have never practiced it. So when it turned out that one of my colleagues and I were both learning jQuery and JavaScript, I suggested we do an exercise together via pair programming.

Luis and I have pretty different backgrounds. He is a college student majoring in computer engineering. I'm a very seasoned programmer who later moved into web technologies and have re-entered that field after a long hiatus.

We built a client-side game for a person to scramble and then solve the 15-puzzle (source code in GitHub repo ). This was done over a few weeks during off hours when we were able to schedule snippets of time together.

(Update: play the puzzle )

It went really well, and I want to jot down a few thoughts about what enabled it to be a positive, constructive experience.

* We already had a good working relationship.

Luis and I are both part-time developers at a digital consulting agency. We had worked together before and felt personally compatible, so much so that we've made a point of going into the office on the same days so that we can readily consult with each other.

* We did it as part of a learning exercise.

This was done not as part of our paid work but of our individual learning endeavors. Luis has been using one of the online services, I've been going through a traditional book. This meant that not much was at stake in terms of producing results, which reduced the potential stress level considerably.

* Neither of us dominated.

Although I am far senior in terms of general software experience, I am a novice with respect to JavaScript and jQuery. And most recently, my career path has been a pretty choppy one with a lot of non-technical roads taken and committed to. These factors together with a strong preference to collaborate rather than compete means that I simply treat Luis as a peer.

* We were open to each other's criticism and suggestions.

If you can sufficiently suspend your own preferences, habits, and beliefs about what's "right", it's possible to learn a lot from another developer. Each of us was willing to try coding differently. This ran the gamut from how to do indentation to what data structures to use for the underlying model.

Small example: in jQuery there is consistent and frequent use of anonymous functions that are passed as parameters. Luis suggested giving names to those functions even though the names are never used. Although this appears to go against the most common coding practice, I ended up liking the additional clarity and expression of intent that such unnecessary function names provide.

* Debugging went much faster and more efficiently.

Case in point. Luis realized that certain event handlers were not working because they no longer existed -- the DOM elements they were attached to were being removed and then some of those elements were re-created as replacements, minus their handlers. Stuff like that is obvious when someone else points it out!

For my part, I correctly suspected that a recursive use of a particular jQuery selector was causing the failure of an iterator to affect all intended objects. It's a subtle bug that I still don't understand the root cause of, but my background in programming languages led to a good guess.

* Both of us have an academic background.

This allowed me, for example, to jump into explaining terminology such as "operator precedence" and "operator associativity" without Luis' eyes glazing over. He not only has the intellectual chops, he gets it that taking the time to learn basic concepts and acquire fundamental understanding is worth it.

Doing this exercise has given me momentum and encouragement to look for opportunities to do more pair programming and to expand further my own envelope. Nice!

Resources:

Pair Programming
http://guide.agilealliance.org/guide/pairing.html

Pair Programming Considered Harmful?
http://techcrunch.com/2012/03/03/pair-programming-considered-harmful/

Pair Programming vs. Code Reviews
https://blog.codinghorror.com/pair-programming-vs-code-reviews/

Feb 1, 2016

Unwanted Side Effect of Reducing Permissions on Drupal Text Formats

On a Drupal 7 site, we were getting malicious comments that were triggering undesired page redirects, as I wrote about in  Malicious page redirects and Drupal's Filtered-HTML text format.

One cause of those redirects was malicious html using the <meta> tag. This tag was allowed because Authenticated Users had access to the Full HTML text format. So we decided to limit use of Full HTML only to Administrators.

Since then, I have learned that this caused an undesirable side-effect. The symptom was that when a user tried to edit content that they had previously created, in the text area for doing the editing they got the following message.

This field has been disabled because you do not have sufficient permissions to edit it

Very puzzling! Why would a user not be able to edit their own content that they had created?

It turns out that when text content is created, the text format in effect at that time is stored with the content and is applied when editing is done later.

If you limit the roles that have access to a particular text format, then text content created earlier by users who have that role may no longer be editable by those users. They are blocked from making any changes.

On our site, this is not a serious problem. Text content is almost always written and submitted once and not revised further.

    * * *

However, a site with content that is actively edited is going to run into a wall. There are a couple of things you might be able to do.

If the number of content items is small, then while logged in as an Administrator or some other role with sufficient permissions, edit each item so that it uses a Text Format that the author has permission to use. In our case, it would have been from Full HTML to Filtered HTML.

If you have a lot of content and you're dangerous enough to hack around directly with the database, then a database global change will also work.

For example, in our case, we have two tables that are relevant. Executing these SQL commands changes the values.

  update field_data_body 
    set body_format = 'filtered_html' 
    where body_format = 'full_html';

  update field_revision_body
    set body_format = 'filtered_html' 
    where body_format = 'full_html';

(And don't forget to clear cache!)

Thanks to David Needham for a particularly pithy and helpful comment in the second article cited below.

Sources:

Signature box for authenticated users - This field has been disabled because you do not have sufficient permissions to edit it
https://www.drupal.org/node/1034064

This field has been disabled because you do not have sufficient permissions to edit it
https://www.drupal.org/node/1064168