Boilers and plates
I enjoy how easy programming a computer to do what I want is. It has simple, easy rules that it follows. Nothing alone is complicated. I have spent my lifetime learning how to generate incredibly complex behavior from very basic operations. Emerging complexity from a system of simplicity is delightful. But it has it’s pain points, moments that I see how limited a human truly is.
Today I am working with a language and framework that has a lot of boilerplate code. Boilerplate refers to the crappy overhead code that you need to stick in place in order to get to the business of your intended real work. Sort of like the TPS reports of programming. I created an object to use as a boilerplate for some other objects. Then I clones that object out to the appropriate file names and began filling in the files with my real work.
I eventually hit a bug. One of my new objects wasn’t registering. It was like it wasn’t loading at all. Because of the nature of the language and framework, two little pieces of the object did work when I called them in another area of the application. The rest though was like a ghost. It was sort of there, but sort of not.
Four hours later I found out my code isn’t working because of two reasons. Simple, easy rules that the computer followed precisely. It did the things I asked of it and it was my humanity that failed in processing my requests.
The new objects file was named alphabetically earlier in a list that another object. This means that the framework read that file in first.
The new objects name though, I had never updated that from the original boilerplate object. I had two objects with the same name. And because of the nature of what I am working with, instead of the latter replacing the former, it merged the two. Only the differences between the two stuck around. Which happened to be my previously noted “two little pieces” that did work.
In the scheme of things, I was only off by a tiny amount. But these simple rules are beautiful for their inflexibility. The machine does not guess. It does not deviate. It does what is asked and nothing less. It takes a human to really fuck things up.
Four hours because a rose needed to be thusly by another name.
Today I am working with a language and framework that has a lot of boilerplate code. Boilerplate refers to the crappy overhead code that you need to stick in place in order to get to the business of your intended real work. Sort of like the TPS reports of programming. I created an object to use as a boilerplate for some other objects. Then I clones that object out to the appropriate file names and began filling in the files with my real work.
I eventually hit a bug. One of my new objects wasn’t registering. It was like it wasn’t loading at all. Because of the nature of the language and framework, two little pieces of the object did work when I called them in another area of the application. The rest though was like a ghost. It was sort of there, but sort of not.
Four hours later I found out my code isn’t working because of two reasons. Simple, easy rules that the computer followed precisely. It did the things I asked of it and it was my humanity that failed in processing my requests.
The new objects file was named alphabetically earlier in a list that another object. This means that the framework read that file in first.
The new objects name though, I had never updated that from the original boilerplate object. I had two objects with the same name. And because of the nature of what I am working with, instead of the latter replacing the former, it merged the two. Only the differences between the two stuck around. Which happened to be my previously noted “two little pieces” that did work.
In the scheme of things, I was only off by a tiny amount. But these simple rules are beautiful for their inflexibility. The machine does not guess. It does not deviate. It does what is asked and nothing less. It takes a human to really fuck things up.
Four hours because a rose needed to be thusly by another name.