Oh, Hey Whiners! It's All About Inventing What You Need

In the course of day to day delivery of new functionality and services in Shopify platform Apps, there is a lot to be said in how much we get to take for granted in terms of stuff invented elsewhere, by others and for general use. Ruby is a fine example in that it is a free open source scripting language that anyone can download, change, compile and use. Most people will just install it on their computer and use it as is, but the freedom is there to change it if need be. Same thing goes for web developers that need to build sites. There are hundreds of frameworks and for the most part they are free and open source too. Ruby on Rails (RoR) and Django are two examples. Most people deploy a RoR website and at the end they have spent almost all of their time writing the code necessary to bring their vision to life and not a lot of time hacking on RoR. This is a good thing.

There are occasions where a framework or toolkit or plugin do not help directly with the solving of a problem. This is interesting to me and it reveals an all to common situation where some guy, gal or team of dudes/dudettes run into some wall or barrier with their open source project and they immediately fire up email, IRC, Twitter, Hacker News and other sources to complain. Whiney waa-waa comes out and they rant, bitch and complain that RoR is too slow, or jQuery plugin XYZ does not address a mouseout event properly or gem ibblefart throws some obscure core dump on their precious PC running Windows XP. This is annoying in the sense that most of these complaints are directed at people that have volunteered their time and energy to provide something of value to the community at large. I think people should be able to voice a concern in such a way that they expose the issue, provide some sane discourse on why it's necessary to bring it up and address it, and then leave it as a simple comment. A point of discussion perhaps. But not the beginning of a rant and whiney diatribe.

I am currently in a situation where I am rendering Shopify data in the form of a Tree View. A tree is a nice data structure where the trunk and branches and leaves of a tree are clearly defined for the end user. In my case, clicks on a leaf have to be dealt with in two dimensions. I need both the product ID and the variant ID for my App to be of utility. The product ID is the branch, and the variant ID is the leaf. The problem I encountered with the Tree View library I am using is that a click on a leaf provides only the variant ID. It has no knowledge of the branch holding it! At first I found this a bit disturbing. How can the company providing this free Tree plugin not know that someone has to know the branch that a leaf belongs to in one click! Getting down and dirty with the tree code itself, it turned out to be pretty simple to figure out what is going on. The developers of this library chose to not provide specific functionality but instead they chose to provide for any extras through a simple abstraction mechanism. If you need to keep track of the branch your leaf is on, you can easily render your leaf with the branch identity attached to it. Turns out that it is really just up to me to fine-tune how I use this library for my specific uses. Another example I found was that the library fires off a selected event when clicking on a leaf. It turned out that it does not fire a corresponding unselect event and that also troubled me. I need to know when a user deselects something. That was also easy to hack. I found where the tree code determines that a node is deselected. At that point I simply trigger the unselect event I need along with the node as a payload. Voila. Bob is my Uncle. I now have a tree that works perfect for me, and my App. It is Bootstrap3 so it looks good, and I know that I am playing with a full deck here, and not polluting the universe with a whiney rant that library tree view is not good because it does not do X or Y.

There is a lot of satisfaction in this process that keeps an old developer like me going. When faced with the pace of change out there, and the need for speed in terms of delivery, it common to beg, steal and borrow code from others to make delivery possible. Taking the time to learn what you're exactly borrowing is crucial at times. You do not need to learn all 250,000++ lines of RoR code to be effective with it, but if you stray into territory where it is not able to help you, you should be able to dive in and fix it up. That is the whole point.