Is it plugged in? Is it turned on?
Every year my New Year’s resolution is to try a little harder – and I am pleased to announce that I am headed in the right direction! Here is my completely un-humble brag:
Last night I performed a weekly launch and COMPLETED IT! I didn’t wake up to a pile of documentation to do, or a bunch of orphaned branches that would hang around for a few weeks. I don’t have any admin or accounting to finish. Email notifications were all sent. No lingering related support items. No cards to archive or channels to close.
I did it. Completely. I was up until midnight, but I did it.
Way to go, me!
I often find life’s axioms can apply to coding. Today’s lesson: be your own best friend!
Not complaining, and definitely not bragging, but sometimes I experience “genius strokes” – typically while coding. Unlike a stroke of genius, they can last hours at a time and the results can be difficult to live with in the long run.
Did I just write an entire CMS framework in a couple of hours and less than 1000 lines of code? Yes! That’s great! Do I remember how it works the next day? Maybe. Will I be able to understand and modify it in a meaningful way a month from now, when I’m not stroking out? Good luck… The dev team members at infsoln always groan when I announce a project involving genius stroke code. They know it will be difficult to comprehend the logic and figure out the inevitable clever twist that makes the whole thing work. We all hate clever.
One of the things that makes this code so difficult to work with is that it isn’t documented. Whether it’s because it seemed obvious at the time or because the ideas were flowing rapidly or even if I simply didn’t want people in my code, the lack of description and explanation is a real bummer. Just a few words could save those who follow (including myself) a tremendous amount of time and headache. It may sound psychotic to wish I had left notes to myself, but I think this almost daily. This needs to be a natural part of code-writing, as automatic as semi-colons and curly brackets.
Another issue I find when coding rapidly is terrible variable names. $spa might have made perfect sense when I created it, but wtf is that, honestly. If it requires even an instant of interpretation then it isn’t a good variable name. Every distraction like this is yet another item to temporarily remember in order to hone in on whatever it was that I was in there looking for in the first place. Knowing that my virtual desktop could catch metaphorical fire at any given moment on any given day, the easier and more direct the route to a solution, the better.
And thirdly (I won’t say lastly as there are so very many more basic things I can do to set myself up for success), DON’T HACK SHIT IN. Hacked together code full of shortcuts and lazy coding is nothing more than prototype code. If it makes it to production I am guaranteed to have future headaches. I need to take a few minutes to go back and figure out the correct variable name, or put queries in a data access object, etc… my code quality will improve drastically!
The conclusion, after a long session of trying to interpret my own code-writing, is that while it is fun to run and frolic freely in the meadow of logic, if I leave myself a few signs pointing back to reality then I will enjoy visiting the place again in the future. And it is always more fun when I bring my best friend with me!
When my next door neighbor and generally awesome person Kelly said she wanted a blog site the possibilities seemed endless. My company has been doing a lot of websites this year and I had high hopes of integrating a third party blog script into our custom rapid development framework. Its been a couple of years since I installed a blog and so of course I went out and looked at reviews, hoping to find something new.
Looking at reviews and feature lists, my first choice was called NibbleBlog. I read reviews, I read their site, and even went to GitHub for a quick code review. Having been burned by deploying small open source software packages in the past, I headed over to look at their open issues list. The first request was from a couple of weeks ago but was unanswered, regarding a bug when uploading photos. The lack of reply seemed to hint at abandonment but I read on. The next issue request was from a user who enjoyed the software package, but wanted to see support for seo-friendly urls. Buried in the ‘me too’ responses to that issue request was a quiet note from the package author stating that the software was no longer supported. Had I not thoroughly reviewed the open issues then I never would have known. Obviously I’m not going to deploy deprecated software, so I moved on.
I returned to the lists of options and sadly dismissed each one, all no longer supported or missing critical functionality. Many that are listed as free are actually not, and I have several reservations about purchasing blog scripts. Few offer support, and many are hosted on scary looking websites. Everyone’s first web coding project is a blog, and there’s no such thing as a free preview when buying scripts. There truly is no telling what the author’s skill level was. So, running out of time, I gave up and deployed WordPress.
Don’t get me wrong, WordPress is fine, but it doesn’t advance my original goals of creating a custom blog module. And I’m still salty after Polish spammers took over my last WP install and were hocking kayaks on my home page (not kidding). I get a lot of work requests to make custom WP apps, but I really wanted to offer a simple alternative to my clients.
So I am sad to report that, like Wal-Mart, WordPress seems to have effectively eradicated the little guy in the CMS and blog world. If you know of a php blog package that can integrate into an existing website, be sure to leave a comment. In the meanwhile, welcome to my WP blog!