19 November 2012

(re)work

/TECH RANT
Remember last time when I said Doppelganger has the caveat of "subject to change"? Yeah, apparently my work projects also have that. Two weeks ago I was "finishing" a form project only to have a discussion last Monday that made me go, "Oh crap." So my main project for the past month or so has been updating our Cell Phone Allocation form to include the option of getting a phone through the company. Previously you could only get a reimbursement for using your personal phone for business related work. Now, the university is offering full-time employees phones paid for by the university and the employee takes a deduction on each pay check for using the business phone for personal purposes. What I had spaced was the fact that the addition and the deduction were opposite from each other. So in five days I re-worked a significant portion of logic in the form to properly calculate the pay period allocation or deduction.

Five days isn't much, but I managed it. The worst part is because all these changes had to be to the current form, we now need to re-convert the form for our SharePoint 2010 migration. You might think that I should just make the changes to the new form rather than re-convert but I'll tell you now, it'll be faster to re-convert. The changes were extensive and although I just finished working on it, I can't remember everything I did and really need to hand the 2010 version over to a co-worker. So re-conversion it is.

The Cell Phone Allocation form isn't the only one that's been hijacked. So has one of the SharePoint Team's least favorite form: the IRB application. This form has given us numerous problems though most of them can be attributed to user error. However, to attempt to mitigate these issues the form has been updated numerous times since it was converted. Yes, with proper documentation we could probably update the 2010 form without trouble but how often do you have good documentation available? How often do you make good documentation?

I've even been improving our documentation, but it's improvement is secondary to the immediate problems of conversion and troubleshooting. Documentation wasn't always a problem for me. In fact in programming I'm pretty good about commenting code and what-not. But SharePoint and InfoPath documentation are different because they're visual design editors with no way to comment segments. So documentation has to be put in a separate document. Which means if you update something, you have to update the documentation separately. And most of the documentation is done through screenshots of the layout and design.

I apologize to people reading this expecting to see solutions to problems on various systems. Perhaps I should move these rants to my other blog and start posting more technical things here...

Until next time:
Work hard. Play harder.

05 November 2012

subject to change

/TECH
Tech changes a lot. A generation in technology is often only a few months to a couple years long depending on which technology you're talking about. In the case of servers, it's more often a couple years. This is because servers are supposed to be a more consistent resource, constantly providing data or services. But for me, servers on Doppelganger are more often going to be talked about at the month level of iterations. Here's a quick rundown of the various appliances and VM's I have running on Doppelganger, my Proxmox Virtual Environment:
  • Amarok
    Service: Plex Media Server
    Allocation: 2 cores, 2GB memory, 20GB storage
    Status: running, rarely used
  • Balrog
    Service: Minecraft server
    Allocation: 2 cores, 6GB memory, 8GB storage
    Status: offline, merged to Gryphon
  • Faoladh
    Service: LAMP for developing a Dungeons & Dragons character tracking web app
    Allocation: 1 core, 1GB memory, 10GB storage
    Status: running, not used
  • Gryphon
    Service: Minecraft server and Tekkit server
    Allocation: 3 cores, 8GB memory, 8GB storage
    Status: running, frequently used
  • Kitsune
    Service: WordPress
    Allocation: 1 core, 512MB memory, 4GB storage
    Status: running, untested
  • Naga
    Service: Ubuntu 12.04 server
    Allocation: 2 core, 6GB memory, 6GB storage
    Status: offline, waiting re-purposing
  • Raven
    Service: TeamSpeak
    Allocation: 1 core, 2GB memory, 8GB storage
    Status: running, frequently used
  • Siren
    Service: Icecast
    Allocation: 1 core, 512MB RAM, and 10GB storage
    Status: offline, not working
  • Warg
    Service: Windows 2008 R2 Server running Terraria server
    Allocation: 2 cores, 8GB memory, 32GB storage
    Status: offline

At the beginning of summer I had an idea and an overly simple plan that allowed for exploration. I never imagined I would have all the things above set up and I'm still exploring different possibilities of things to do. Looking back I now see a trail of projects--some working, some failed, some in between--and a series of decisions that were made on a thought. Naga had a very short lived purpose to serving as a remote platform for a friend to finish a school assignment. I set it up in about 30 minutes. It still sits in the list of servers hoping to someday become something else. Balrog had a long-term plan, but has since been incorporated into Gryphon, a more stable appliance. I maintain a spreadsheet online with a list of all the computer names I'm using or might want to use, what purpose that machine might serve, and various details about ones that are in use such as IP address and machine number. There are a lot more names on that list than I gave here, some of them being the names of my personal computer (Phoenix) and other active devices, some being undetermined, and some being machines that will be setup in the future.

Perhaps the most interesting machine on my list is the one that sits at the top and has never been implemented in any way but has gone through the most iterations: Cerberus, my eventual router and firewall. Although its name and eventual IP have never changed, my ideas of how it's to be implemented have been in constant flux. And unlike most of my machines that are virtual, Cerberus has to be a physical box to be its best. The hardware I want to use for it has gone from using an old Pentium 3 or 4 with 3 network adapters, a 24-port switch, and a wireless access point to buying a specialized integrated device that minimizes power consumption and physical space requirements. My thoughts on Cerberus could be an entire post for that matter and probably will be one when the time comes that I finally build it.

In the end, I discovered that my initial plans weren't that good and that there was a better way. I now have an asterisk next to the whole plan that refers to a footnote stating: subject to change. And in the end this was and is the best way to approach Doppelganger.

Until next time:
Work hard. Play harder.