« New Computer | Main | Blood Lake? Blood Snakes? Lake Vampires? »

Employee Directory

I haven't been very good about posting updates. I don't know if it's the summer heat, or if I'm just feeling down lately, but it's been hard to get myself motivated.

There have been some developments. I've been working on a PHP project at work to keep track of our computers and help plan our migration to Windows 7. It's not especially sophisticated, but it's probably some of my better PHP code, and it shows I'm not a one-trick pony I've got at least two or three tricks. I'm also planning to add a repo for some powershell scripts once I have a few that are worth it. All of that is on Github

What I wanted to talk about today was the new C# project I've been working on, which is an employee directory for work. I don't know if it's more apt to compare me working on this directory to Sysiphus and his rock where I'm Sysiphus and maintaining the directory is the rock, or maybe like Grendel in Beowulf. Although in that one, I guess I would be a mead-hall, and the directory would be the unkillable beast that terrorizes me. You know what, nevermind. Suffice it to say I've been working on this thing in one form or another for years.

It started out as an excel spreadsheet that would be converted to HTML when people were added or removed. This was cumbersome, and rather inefficient. We would add photos, and resize them, and it would often include the resized image and the original. There would also be TONS indecipherable code that I assume was meant for translating the particulars of the XLS format to HTML. Worst of all (as far as I was concerned at the time) it was visually inconsistent. In hindsight, maybe we should have resized the images first, but it didn't occur to me at the time.

In an effort to fight the bloat, I tried moving it Open Office's version of Excel. I'll call this better-ish. It eliminated some of the big problems, but also introduced some new ones. But the new problems weren't that bad.

I wasn't happy with better-ish, and I had run out of spreadsheet software to misuse, so I opted to hand code a directory with plain ol' HTML and CSS. This completely fixed the issues of visual consistency and bloat, but it's cumbersome to hand edit changes and add people, and it imposed a certain knowledge hurdle on making changes. No one in the company knows the first thing about HTML except me and my boss, and him just barely. While that sounds like good job security, it's not really the greatest job out there. I wouldn't be upset if I never got to manually edit that directory again.

That's where PHP came in. I was teaching myself how to code HP, and I can't really learn something unless I break it down and see it in action, so I wanted a project. That version of the directory was the most ambitious thing I had tried at that point. I did get a mostly feature complete version running, but I abandoned the project.

It was abandoned for a few reasons. For one, we didn't really have a production server to run it on. Our intranet server at the time was old and temperamental at the best of times, so installing PHP on it seemed like a bad idea. New hardware was apparently around the corner, but that corner turned out to be pretty far away. Plus the requirements changed drastically in the middle of the project due to a new HR person. Now granted, she had no idea I was working on this, but it really sucked out the last of my motivation to finish. It's probably just as well. I looked at the code the other day, and it was a little rough. You'd think I got paid by the comment. Every line had a comment, with paragraph length description comments of every function and section.

That brings me to current times. I'm trying to take things a little further. The PHP version was basically just a database-powered version of the HTML one with a form for adding and modifying people. This one is a bit more dynamic, allowing for multiple phone numbers of various types, multiple job descriptions, etc.

This is my first real use of LINQ that I know of. I'm using it to filter employee-specific data during the loop that creates each employee's entry. So if employee A has 3 phone numbers, it will just extract those from a larger phone numbers query-result set while on that employee's part of the loop. I owe that little bit of insight to mentor/teacher Adam. My initial attempts at implementing these open-ended fields was to use nested loops, which would mean looping through the entire employee result set 6-7 times to catch all the dynamic elements. In practical terms, this probably wouldn't have created a noticeable lag in the creation of the page. Work has about 120-130 employees, so there wouldn't be much lag, and people would probably write it off as typical network latency. But it really bothered me how staggeringly inefficient that approach was.

As of this writing, I am done with a rough version of the display page. It's ugly as sin, both the code and the presentation, but the information is there. I'm going to re-factor the code a bit to make it easier to read, then get started on the adding/modifying employee form. I'll probably focus on the presentation last so I can make everything visually consistent at the same time. I also need to figure out how to restrict the editing to a few individuals. Wouldn't want just anyone able to modify these entries, right? More on that as it develops.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.