Entries in Projects (4)


The Grind

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


Automated New PC Deployment

One of the first elective classes I took at community college was an odd class that combined A+ type hardware teaching, using the Windows command line tools, and peer to peer networking. The p2p networking stuff was interesting, but tedious enough that I haven't bothered to set it up at home.  The A+ stuff I already kknew for the most part, but the command line stuff, specifically batch files, really opened my eyes. Between the command line and the registry, you can do almost anything from a text interface.

  The idea to start using batch files to automate some of the new PC deployment tasks came to me after banging my head against imaging and deploying PCs across different hardware. See, the thing is, we're not big enough at work to have our own PC model that we order.  We tend to buy a few as we need them, then a few more. The result is we end up having many different hardware profiles. Loading a new PC from scratch is a tedious, boring process. Between applying all the updates, making all the security and configuration changes, cleaning up and defragging, it could easily take two days to get one up and running (less than 1 if it's my top priority).

  In an effort to make things more streamlined, we would get each PC to a basic starting point where everything was just the way we liked it, then we would make a duplicate image so we could just load that on new computers, thus saving many hours of tedious setup. Here's where the fun starts: Deploying an image on different hardware than the PC the image was made on was a total crapshoot. Sometimes it worked fine, sometimes it wouldn't even boot.

  Now, I thought that Microsoft's Sysprep tool was the solution to this. The idea is you get the PC set up just the way you like it, then run Sysprep, which will "reseal" the device. This regenerates the SIDs (I believe that stands for Security Identifiers, which all have to be unique on PCs in a domain), and makes you go through the set up process. You could even make an answer file to make the re-setup quick and painless. What's that you say? That sounds perfect? I thought so too! The problem is either user error or a flaw in Sysprep. I'm inclined to think it's a little bit of both.

  The problems I ran into Sysprep were twofold. One, it was still a crapshoot on whether the image would work on a PC with different hardware than the original. This one might be user error. There might be a way or place to specify that the image will be used on different hardware. I believe there is a place to add drivers, but I couldn't really figure out which drivers to add. The second problem is that Sysprep seems to have a weird anti-piracy feature built in, where it won't reset the grace period for activating Windows if you run sysprep several times on the image. The trouble I was running into was making last minute tweaks, then reimaging and re-sysprepping. After a few changes, I started getting a message saying that Sysprep wouldn't reset the grace period for activating windows. At the time, I didn't really understand what that meant and went on with my business. I found out a month later when I was trying to deploy the image to a machine and I couldn't log into Windows because it wasn't activated, and I couldn't activate it because I couldn't log in and load the network driver.

  To me, this is a flaw wit Sysprep. If anyone wanted to update their image more than five times, then Sysprep would stop reseting the grace period, meaning it'll turn PCs into brick in a month if you try to use it. I think this is partly error on my part for not being able to figure out the drivers, and a goof on Microsoft's part for making the tool counter-intuitive to use. The work around for the issue I described is basically to take an image, save it, then only run Sysprep on it when I'm about to deploy the PC. This works, and it's what I'm doing, but it feels like there should be a better tool for this type of thing.

  So that leads me back to why do I need a way to automate the setup of new PCs? I've decided that I have the best chance of successfully restoring an image to a new PC if I remove the hardware differences. So that means I need one image for each model of PC we get. If I had to set up each one of these by hand each time, it wouldn't take long for me to start looking around the office to see what I could slice my wrists with, or to try to figure out if a USB cord noose would support my weight.

  This is starting to look a little long. I think I'll end this now and save the actual trials and tribulations of my automation attempts for the next post.


Database Projects

Now that I have a better idea of how databases work, I want to using them at work.  There are two things I do by hand that I think could be greatly enhanced by using a databases.  The first is tracking computer deployments. We have specialized software that is deployed on certain PCs, and right now I track all of them by hand using various spreadsheets. This works, but it isn't exactly ideal.

The other thing that would benefit from some databasin' is the employee directory. There are a bunch of things we track and put on the intranet about employees, and it's all done in separate documents by hand.  Email lists, a list of birthdays, a photo directory with phone numbers and a phone directory without pictures. It occurred to me during the database class I took that it's madness that I'm tracking this stuff by hand. This is, literally, what databases were designed for.

My biggest hurdle at the moment is mostly inexperience mixed with fighting the inertia of not doing it. I'm trying to be good and actually plan it out instead of just rushing in and making a bunch of mistakes. I've heard, though, that doing things like this have to be done 3 times to get it right. I'm wondering if maybe I should just plow ahead and screw it all up. Then again, the 3-time theory probably doesn't work that way. I don't want to be the guy that has to do it 4 times.

I'll try to catalogue my trials and tribulations implementing these systems at work. I'm not too clear on how specific I can (or should) get about things like that on here. I think it's best to play it on the safe side, at least for now.



One goal I had in starting this blog was to talk about what I was learning in school, and possibly how I intend to apply it. To that end, I think I'll start posting about projects I'm working on that are influenced by what I learned. This is partly inspired by a recent netcast from Steve Gibson that told of his youth fiddling and building things and how that helped him later in life. I know I learn best when I'm building something or taking something apart, so it seems natural to me to use what I learn in a practical way, and to use this blog as an outlet for process.

For now, everything will be in a big blob together. Once I get a decent amount of project entries, and enough other reviews/other stuff, I'll probably add a bit more structure to the site.

Stay tuned!