The Grind
Friday, June 5, 2015 at 5:48PM
Rich in Classifieds, Programming, Projects, Projects

As I write this, my latest project, the classified ads page for work, is incomplete but stable. The part of the page that will display ads is done, including pictures. When I first started this seemed like such a minor step to completing the project, but it turned into quite a milestone.

The reason the display page became so much more of a big deal is because I'm attempting to make it with objects. I'm relatively new to object oriented PHP. More accurately, I'm relatively new to object oriented programming altogether. Almost all of my previous PHP projects were all written procedurally. Back when I was first learning the language objects were weird and intimidating. I've gotten a lot more familiar with them lately, but it's been a slow process. Thus, the title of this post.

I think I can identify the source of many of my issues. I think it's safe to say that most of them are self-inflicted. For example, I noticed I have a tendency to get really focused on solving a problem without taking the time to think if I'm solving the right problem. There were many times where I would be chiseling away at a particular block of code. I would change this piece, refine that piece, inching closer to the expected result set when I tested it. And when I finally got there, I would sit and think "I can't use this at all". It's a great feeling to finally get something to work after struggling with it, but it's equally, if not more, deflating to realize you did all that for nothing.

Almost worse than that, I would occasionally stop what I was working on to inexplicably work on a different feature. Even at the time I thought it was odd. I was still working out the details of pulling in the pictures for each ad when I decided to stop in the middle of that and implement an image resizer, which I wouldn't actually need until WAAAAY later in the project.

One fun little problem I ran into was during that image resizer implementation. Up until that point I had avoided namespacing. I figured I was starting out, and namespacing was a layer of complexity that would cause more frustration than it would fix problems. Now maybe the problem I had was because I didn't include the namespacing from the beginning, but who knows? Basically, once I added the namespaces everything just stopped working. I kept getting errors that the files couldn't be found at the expected locations. I spent hours trying to troubleshoot this. Making all sorts of minor changes, looking up solutions from other people with these problems, trying those fixes, trying everything, all to no avail. And near the end, I figured something else must be going on because I've been at this enough that I can just tell I have it right. So I called it a night. The next day, without making any changes, I tried it again and it worked fine. I can only assume it was something in my test environment that needed to get reset.

I did notice that I found it more difficult to think out the logic with objects. I think it's a mixture of still being unfamiliar with some of the object syntax, and also that I'm generally trying to hold more code in my head when working with objects. With the procedural work I used to do, it seemed like I would only need to keep a few lines of code straight to get the next piece to work. With the objects it's more like I need to keep what the code is doing in my head. For example if I'm writing a class that will do something to an array, I need to remember how the array is coming in, what I need to do with it, and how I want it to leave. While that's not unreasonable or even difficult, it's different from what I used to do and takes some adjustment time.

On the plus side, I find it FAR simpler to refactor object code. While it was definitely a grind, it would have been a lot worse if not for using objects. I believe this is due to what I talked about earlier, where you have to know what is going into a class or object, and how it is expected to return. Everything is organized into little discrete chunks, which makes it far easier to identify and address a trouble spot. I found I was much more confident in the code I wrote and whether it would work than when I made everything in the procedural style.

It's funny, when I look at the last project I made with PHP compared to this one, it's like night and day. It was a database and website for tracking PC deployments at work. The way we were doing it just wasn't good enough anymore, so I put this thing together over a few days. It's...good enough...but I haven't touched it in a long time because the code is a mess. Looking back, it almost looks like I was trying to write one of those "Don't Do This" examples for a text book. I would love to expand on it, and use it in different ways, but I'm terrified to touch it at this point. It's so easy to break with just minor changes. It's a good lesson, and probably one that I had to learn the hard way.

I'm planning to get back to this classifieds project soon and finish it. I've been a little out of sorts lately, and the need to detach and zone out has outweighed the need to better myself through applied learning

Article originally appeared on Rich Burns (http://richburns.me/).
See website for complete article licensing information.