brick-wall

Corporate Dogma: Good Intentions, Bad Policies

Recently, a colleague wanted to update our corporate profile on a well-known website for sharing interview experiences; we will call them Brickwindow. When signing up for a free corporate account, he filled out the fields honestly, stating his name, his job title, and checking the box that stated he represented HR, which he does as part of his various duties. 24 hours later (or thereabouts), the response came back saying that Brickwindow were not permitting him to open the account as his job title wasn't HR-related. They would need a C-level employee or member of the HR department to verify his authority (or to open the account themselves).

Here's the issue. Our organization does not have an HR department or traditional C-level employees like CEO, CFO or CTO. Just as we are trusted to make good software engineering decisions, we are trusted to make good decisions in other aspects of the business, including who we hire. There are no managers, no Chief Gubbins Officers, and no HR departments. So, my colleague wrote back to Brickwindow outlining how our company structure just does not fit their rules. He assured them that he is authorized to make HR decisions. Shortly thereafter, they responded reiterating that he could not have the account and asserting that they are committed to the security of their users.

So, I signed up.

I have the same job title as my colleague, but since we can choose our own job titles, I temporarily promoted myself to Assistant to the Director of HR. After submitting my application, I pondered on how they might verify this and quickly updated my LinkedIn profile to state the same title1. About thirty minutes later I had an account. It was that easy. My colleague had just been too honest. As for the commitment to user security, Brickwindow sent me my new user name and password in plain text. Brilliant2. I quickly changed it and then forwarded the account details to my colleague so he could continue with the task he had attempted to do the day before.

I think this tale serves as a great example of how we can get bogged down in process and miss the purpose of an activity altogether. In trying to make sure that no one could just create an account for any old company, Brickwindow made assumptions about its corporate user base that meant they could not adapt when faced with something that did not conform. Not only that, but they were so busy trying to enforce those assumptions, they missed the glaring loopholes. All they managed to achieve was a huge waste of time; theirs and ours. This had been an opportunity for Brickwindow to demonstrate they are forward thinking and adaptable, but instead they made it clear they are stuck in the past with the monolithic corporate structures of C-level employees and middle management. In the end, they failed on three major points: identity, roles, and security. We only persevered because we appreciate the primary service provided by Brickwindow.

So, next time you are faced with a situation that does not fit the script, consider whether the script needs to change before trying to change the situation. These conflicts are an opportunity to impress, not stick to rigid rules that don't even achieve the goals they intend to.

If you have any similar tales of well-intentioned processes gone wrong, or corporate dogma that gets in the way, please post them in the comments.

As for me, I have since demoted myself back to a Senior UX Engineer (a title I had chosen when I found out I would be speaking at CodeMash 2.0.1.4). It turns out HR was just not a good fit for me.


  1. Apologies to anyone who was confused 

  2. sarcasm 

Facebook Stickers and the Curious Self-pleasuring Dog

Yesterday, I discovered the new Facebook feature, "Stickers". These are a new way to comment by choosing a picture to post rather than words. You can select stickers from various sets (all of which are free, though am I certain that there will be many to buy in the long term).

In experimenting with the feature, I came across this dog. Being who I am, could not help noticing that he appears to be furiously pleasuring himself in a couple of his images. It seemed fitting to capture this in a comic strip before Facebook decides to take these particular stickers down.

Self-pleasuring fido

You are welcome.

top-logo_2

CiviCRM deployment on IIS WordPress

At Ann Arbor Give Camp this year, I worked on a team looking into donation management options for non-profits. Thanks to Dr. Milastname (it would be inappropriate to reveal his true identity), we found CiviCRM and spent much of the weekend getting familiar with its deployment and functionality inside of WordPress. CiviCRM integration with WordPress is a relatively new feature, so it was not totally unsurprising that we encountered one or two issues. The first and by far the biggest problem we encountered was the White Screen of Death (WSOD).

After some debugging (which involved editing a couple of PHP files inside of the WordPress and CiviCRM systems), we discovered that a PHP add-in used by CiviCRM for templating was relying on the open_basedir variable and this was not set on our IIS-based system. This caused the templating add-in to fail, halting the rendering of the CiviCRM admin screen and resulting in the WSOD.

To rectify this problem, I edited wp_config.php to introduce the open_basedir variable just before the require statement for wp_settings.php. I set the variable to the path of the WordPress deployment (ABSPATH) and refreshed the CiviCRM admin screen.

This fixed the WSOD and enabled us to continue our evaluation of CiviCRM1. We also raised an issue against the CiviCRM project and added a post to the CiviCRM forms, ensuring the lessons we learned would benefit future users of CiviCRM.


  1. And discover a bug that I had introduced all by myself 

dropthebomb

Drop the BOM: A Case Study of JSON Corruption in WordPress

GiveCampIn September, I attended Ann Arbor Give Camp, a local event that connects non-profits with the local developer community to fulfill technological goals. As part of the project I was working on, I installed a plugin called CiviCRM into a WordPress deployment that was running on an IIS-based server.

It turned out that WordPress integration for CiviCRM was relatively new and a problem unique to IIS-based deployments existed after installation. This led to a white screen when I tried to access CiviCRM. I spent some time troubleshooting and eventually found the issue after I edited two files to track it down. The fix was quickly implemented. Unfortunately, I then discovered that some other features were not working properly.

The primary places this new issue surfaced were in displaying dialog windows within CiviCRM. It turned out that these dialogs obtained their UI via an AJAX call that returned some JSON and for some reason, jQuery was indicating that the call failed. Investigating further, I saw that the API call was successful (it returned a 200 status result) and the JSON appeared completely fine. How strange.

JSON in binary editor of Visual Studio
JSON in binary editor of Visual Studio

I made some debug changes to the JavaScript using the Google Chrome development tools and looked at the failure method jQuery was calling. In doing so, I discovered jQuery was reporting a parsing error for the JSON result. This seemed bizarre, after all, the JSON looked fine to me. I decided to verify it by copying and pasting it into Sublime. Still, the JSON looked just fine. Being tenacious, I saved the JSON to a text file and then opened it in Visual Studio's binary editor and there, the problem appeared. There were two characters at the start of the file before the first brace: byte order marks.

Corrupted JSON in Google Chrome developer tools
Corrupted JSON in Google Chrome developer tools

A byte order mark (often referred to as a BOM) is a Unicode character used to indicate the endianness (byte order) of a text file or stream1. JSON is not supposed to include them at all. In hindsight, I could have seen this issue much sooner if I had paid closer attention to the JSON response in the Network tab of Chrome's developer tools. This view had shown two red dots (see above) before the opening brace, each dot corresponding to a BOM that Chrome knew shouldn't be there. Of course, I had no idea what they meant and so I promptly ignored them. Lesson learned.

So, armed with the knowledge of why the JSON was causing parser errors, I had to find out what was causing this malformation and fix it. After reading about how a BOM in an incorrectly formatted PHP file2 could cause BOMs to be prepended in the PHP output, I started looking at each PHP file that would be touched when generating the API response. Alas, nothing initially stood out. I was getting frustrated when I had an epiphany; I had edited exactly two files in trying to fix the installation issue and there were exactly two BOMs. Coincidence?

I went to the two files that I had edited, downloaded them and discovered they both had BOMs. I re-saved them, this time without a BOM and uploaded them back to the site, which fixed the JSON corruption and got the CiviCRM plug-in in to working order.

In tracking down and fixing this self-made issue, I learned a few valuable lessons:

  1. Learn to use my developer tools
  2. Never assume it is not my fault
  3. It pays to understand how things work

Hopefully, my misfortune in this one incident will help someone track down their own issue with corrupted JSON in WordPress. If so, please share in the comments. Together, our mistakes can be someone else's salvation.


  1. Wikipedia – http://en.wikipedia.org/wiki/Byte_order_mark 

  2. one saved as Unicode with byte order mark 

1799670_1439781526268639_1888950461_n

Ann Arbor Give Camp 2014

Last weekend saw the return of Ann Arbor GiveCamp. This community event, organised and hosted by Jay Harris, Hilary Weaver, Ken Patton, and their minions, is held at Washtenaw Community College who generously accommodate Give Camp on the third weekend in September every year (18th-20th September, 2015, put it in your calendars).

GiveCampGive Camps are events where volunteers from the tech industry including developers, designers, and artists come together to help out local non-profits with new websites, social media, and other technically-centric projects that might otherwise take dollars away from their primary mission. This year, the combined efforts of the volunteers donated nearly $150000 of effort1.

The non-profit our team was earmarked to work with this year unfortunately had to pull out of the event, so, we turned our efforts elsewhere. Each year, Give Camp receives proposals from non-profits that are just not feasible within the 48 hour time-frame and a common theme of many proposals is donor and donation management. While there are many professional solutions available, they often carry a heavy price tag, taking money that otherwise might go to the non-profit's primary mission.

This kind of software is not simple. Most packages contain features to track donors, volunteers, relationships, donations, events, campaigns, and a lot more besides. Given the obvious complexity and nuances of this kind of specialized accounting software, our expectations of achieving much over 48 hours were low. We decided our main goal would be to flesh out a basic design that could be used to kick start some future effort at some future Give Camp. This plan soon changed.

CiviCRMThe very first step we took was to research the available solutions. Thanks to the Googlefu of one team member, known to our team as Dr. Mylastname2, among the large number of commercial offerings we discovered CiviCRM, a free and open source solution with a very extensive and supportive community. Not only that, but CiviCRM supported WordPress integration, making it a natural fit for Give Camp projects3.

On discovering CiviCRM, our mission changed from specifying some future development effort to evaluating an existing solution. By the end of the weekend, we had two test sites up and running, and a solid set of recommendations for how CiviCRM might be deployed to non-profits at future Give Camps. The project was a great example of how things can change at Give Camp.

As with the two previous Ann Arbor Give Camps I have attended, the team in which I participated faced some unique and intriguing challenges, ultimately reshaping and redefining what could be achieved. I met old friends, made new ones, and saw what can happen when people choose to focus on others. It never ceases to amaze me just how adaptable people can be when failure is ruled out and that is just one of many things that makes Give Camp a fantastic experience. I look forward to next year and hope that you will join us to make it even better.


  1. based on average consulting rates 

  2. pronounced, meelastname 

  3. WordPress is the CMS of choice for non-profit websites at Ann Arbor Give Camp 

but mostly…