Godzilla Score

It's pretty rare for me to get genuinely excited about entertainment media these days.  Usually if I do it's over movies, and the last two times (Prometheus and Thing 2013) were colossal disappointments.  I look forward to things, but excitement doesn't come often.  I was looking forward to the new Godzilla movie, but I wasn't sure what to expect.  The last American reboot wasn't exactly amazing, though I didn't have the visceral hatred for it that apparently everyone else has.  A Godzilla movie of any kind is fun, so the Roland Emmerich one was more like a fun monster movie that happened to be called Godzilla.  The key ingredient is the giant monster.

I'm getting off track.  The point was that I went into the new Godzilla movie expecting a fun monster movie and little more.  Man, was I wrong.  I was blown away by how good it was.  I don't know how to describe it without sounding cheesy.  It really was amazing.  But that's not even what I'm excited about.  I'm going to talk about the movie more in a separate post.  What I want to talk about here is the score.

It grabbed me at the title sequence.  I don't know how, but when I heard that music I knew it was going to be a great movie.  It feels like the old music, but it's different.  It's hard to explain, but it's big, and menacing, and driving. It brought me right back to watching bits and pieces of all the old Godzilla movies when I was kid, catching them when they were on TV, not knowing which movie was which or what was happening.

I was so impressed with the score that I stayed through the credits just to listen to it.  I can't even remember the last time I noticed the score in a movie.  I bought the score yesterday and saved it to my phone, and listened to it at least 3 times today.  It just taps into some piece of me and doesn't let go.  Helps me focus, gives me energy, makes me want to do stuff.  Get things done, you know?  It's good music to drive to, assuming you don't need to stop very often.  I got so jazzed about this that I actually bought a Godzilla DVD box set.  Is this just nostalgia?  It seems like more than that.  I don't know how to explain it.

I found a link to the first song on Youtube.  Takes about a minute before it really gets going.  There are quieter, more somber parts of the score, and even more loud and bombastic parts, but this is a good representation of the whole.

It's strange to think about how my music tastes have changed.  This started while taking online and night classes to get my degree.  I developed a real appreciation for instrumental music.  Originally I just needed a way to shut out the outside world to write papers, and anything with lyrics would distract me.  I stumbled on instrumental surf rock, of all things, and that became my goto.  What's funny is one of my favorites is a band called Daikaiju, which is the name of the genre Godzilla type movies fall into in Japan.  If I'm not mistaken, kaiju means monster and dai means giant or large.  The instrumental playlist has grown since those days, and now includes some world music (Gamelan Jegog from Bali) and classical (mostly Yo-Yo Ma), and I sometimes put it on when writing code.  Sometimes I find it distracting, especially when encountering a new problem, but it's great for focusing once I know how I'm going to tackle a problem.  I will definitely be adding this soundtrack to the list.  More about the movie itself later.  The short version is it was awesome and everyone should go see it.  Until next time!


Trackr is a go!

My desire to write here seems to come in fits and starts.  I have stuff I want to talk about, just never seem to find time to write about it.  But this is a special occasion.  I've been working on a webapp to track hard-drive based backups of our servers at work.  It's very simple, but almost all of the technology was unfamiliar to me when I started.  The database was familiar, but using C# as the base language was new, the Webmatrix IDE I wrote it in was new, using the Bootstrap frame so it wouldn't look like crap was new, and adding a bit of Javascript was new and the most intimidating of the lot.

Implementing the code on the work server was an exercise in frustration, but I managed to get it working.  It's strange, there is an undeniable thrill when I get something working.  I experienced this when writing the code, and being delighted when something actually worked, and I got it the first time I got it working for real on the work server.

I know I've mentioned elsewhere the mentor relationship I have with my brother-in-law Adam.  I was talking with him about deploying the code and getting it working.  He told me I needed to get it in the hands of users so they can break it and I could fix it, that the first pass never stands up to actual users.  I was immediately a little bummed because I couldn't really see anyone using it.  This was a frustrating task I had to do by hand that I was hoping to automate.  So I figure it's no big deal, I learned a lot and I'll just pick a new project that others will use.  Turns out I was a little naive about my assumptions.

For one, I didn't anticipate myself as a user being a source of problems, but I found at least 4 little problems or typos that completely eluded me in the development and testing phase.  Small issues, easily fixed.  I just found it amusing, how it seemed rock solid while making it and I found problems in a matter of minutes when I actually used it.

The second thing I didn't anticipate was that my boss would end up using this.  The way it used to work is he would check on the backup appliance, then tell me what was on a backup and when it was made, and I would document it and switch the hard drive.  It never occured to me, but he could easily document it himself now.  So within about an hour of showing him the app and how it works, he starts requesting features!  Most of it was pretty simple, but one request threw me for a loop.  I think I can implement it, but I need to give it some thought before diving in.

When this happened, I shot off an email to Adam explaining that I've created a monster, and that he was right about it not standing up to real users.  He replied with "Congratulations you are now a junior programmer. Save the date and start tracking it. You will need it." So for any potential employers out there who may end up reading this, I have created a thing, deployed it, and on the following date had it beaten on and started working on unforeseen features and problems:

May 13, 2014

I made it nice and big so it would be easy to find.  I'll write some follow-ups once I have a chance to fix and implement some of the issues my boss raised.  I've also started on a new project to further my education.  I'm running into database issues with this one, but that is a story for another time


Some Updates

Nothing too long-winded today.  The pants arrived safe and sound.  They fit and look work-appropriate enough, so this story had a happy ending.

The backup tracking app continues to plod along.  Currently one can view a table of backups, a table of hard drives used for backups, can add new hard drives, modify existing drives (not sure there's a lot of need for that, come to think of it), and add new backups.  Still need to add a page for modifying existing backups, and a way to delete entries.

I showed my wife the progress I had made a few days ago.  She did the best she could, but it's hard to get excited over something so simple as this tracking app.  I don't generally get any real feeling of accomplishment when I do things.  Usually the closest I get is relief that a particular task is over and I can move on to something else.  But this is different, somehow.  When I figure out a solution to a coding problem it's a genuine rush, if only for a moment.  It sucks that there's no way to convey that feeling when looking at the finished product.  She can't see the two hours of research, experimentation, and testing, she just sees a dropdown list that pre-selects the right entry when you hit Edit on the hard drive table.

I'm starting to update other areas of this site, slowly but surely.  Added a link to my Github profile.  I've updated LinkedIn and Google+, though I don't think they're linked here yet.  I still can't really bring myself to use all these social networking sites properly.  I think I just missed being part of the generation that cares about this stuff.  It's more than just the feeling of "who cares", it's the time.  Seems like there's precious little time to go around these days, and proper social networking seems like it would be a time sink.

Speaking of time sinks, Titanfall comes out on Tuesday.  I had a chance to play the demo a few weeks ago when they were stress-testing their servers, and I'm looking forward to getting my hands on the full thing. The link up there is to the ridiculous Collector's Edition, which clocks in at $250.  They're also selling "Professional Quality" branded headsets for $150, and even have Titanfall Xbox One console bundles.  This all seemed highly unusual for a new franchise until I did a little research and found this was being done by some of the original Call of Duty guys.  Some of the gameplay elements address some of the problems I have with these big multi-player shooters, plus it's got big-ass robots, so I'm in.  I'm sure I'll explore that in greater length in a future post.  This one has already gone on way longer than I intended.  Until next time!



An amusing story about databases and pants

I've found that my current career as an IT support guy has been rather rough on my clothes.  Crawling under desks, hauling computers and servers around, taking the old junk to storage, it's a lot for your typical polo and slacks to stand up to.  So a few years ago I switched to worker brands.  Carharts, Dickies, that sort of thing.  These last far longer, and they're passably business appropriate.  Well a pair recently started giving out, so I decided to give Duluth Trading company a try.  I make my order, and start eagerly awaiting delivery.

I tend to check delivery status every couple days for everything.  I don't know why, it's not like I can really do anything if there's a problem, and the crap I order is rarely important.  But I do, and the first few times I checked these everything was fine.  Then I check again and the status shows as "Exception", which I've never seen before.  It says to check the Shipment log for more details, so I scroll down and find this:

TRAIN DERAILMENT?!  That was certainly a new one for me.  Apparently this sort of thing isn't entirely unprecedented for poor Helena.  I checked the status again today, and it's now stuck in Kalispell, MT due to severe weather conditions.  Now there's certain evidence that suggests UPS might be more into logistics than I am, but I feel safe in suggesting that Montana during the winter may not be the best route.  It's anybody's guess when these pants will actually arrive now, but I hear they're pretty tough, so I'm not too worried.

So what does that have to do with databases?  Glad you asked!  As I've started to get more serious about programming, I've had databases on my mind more recently.  One of the first things you're likely to learn about database design is that you want to avoid duplicating data in a table wherever it's feasible to do so.  If you're tracking something like, say, delivery statuses, you don't want to type the same delivery status messages in for the various records.  It's more efficient to make a separate table (sometimes called a lookup table) where you enter the status once, then reference the ID number of that status message in the original table.  This is more efficient in terms of data storage, and it makes it easy to change the message later if that's ever necessary.  Changing the description in the lookup table effectively changes it everywhere because the other places are just saving the reference to that description, not the description itself.

While this makes logical sense, I found it to be extremely counter-intuitive when I was starting out.  The natural approach for me was to try to make the table look like a spreadsheet, where everything I wanted or needed was in a single table.  So there would be a status column with the statuses written in.  Fine for a small table, but what if you need to change the wording of the status?  What if you made a typo in some of them?  It's just too messy and inefficient.  Storing the reference ID makes the table harder to read in the raw form, but how often are you really going to do that?

So to tie this all together, that delivery status field is the perfect candidate for a lookup table, and as I was looking at it that first time, slightly in awe, I wondered if that was a recent addition, or if train derailment came up in a planning session or requirements meeting.  Now I'm not up on train derailment statistics, but it seems like a definite possibility that it hasn't happened since UPS started this online tracking system.  Looking a little closer, I noticed there's a period at the end of derailment, but not at the end of any of the other entries.  That makes me think it was added later.  And I belive my suspicion was confirmed when I checked later and saw a slightly more informative description in its place.  Pretty weird, huh?


Partial Pages in ASP

I wrote some code. Imagine that! If someone were familiar with this backup tracker project, but not with me or my family, it would appear that I started testing out partial pages, then fled in terror for 3 months. Not true! While the specific implementation of partial pages in ASP.NET is new to me, I understand the benefits.

The basic idea is to write a piece of a page that you can use multiple times in other pages. In this particular case, that's a form. Whether you want to add a backup/harddrive, modify an existing entry, or delete one, you need some kind of interface for entering that data. If you want to add a new entry, the form is blank. If you want to modify an entry, you pre-populate the form fields with the data about the harddrive or backup and allow the user to edit some or all the fields. If you want to delete, you pre-populate the form, restrict the ability to edit, and make it super-duper clear that you're deleting something. Partial pages lets you write the big chunk of that page -the form- once and use it in different contexts by inserting it in other pages.

This was a new way of thinking about this problem for me. I'm mostly self-taught, and I started with PHP. When I needed to do add/edit/delete forms for a project in PHP, it took a while to figure out how to do it. My first thought was to just write 3 pages, but I rejected that idea almost immediately. Copying code like that is a bad idea. What if the form has to change? What if something with the database changes? What if someone else has to change something, and doesn't know to change the other two?

So the next thing I thought of was to do all of them as a single page. This seems like a good idea until you try to do it. The hard part isn't really writing the code, it's trying to understand it later. Now I'll admit that I probably didn't hit upon the best way to do this particular idea, so maybe there are ways to do it that are easier to manage or make more sense. My pages were a mess. The problem is you need to account for 3 different complex tasks, all while trying to use the least possible amount of code. You want the add/edit/delete options to use the same form or you run into the problem of having 3 completely separate pages. The solution is to use variables in the form, and account for them in the code blocks for the 3 specific options.

So what I did was split the page into 3 parts. The first part was Setup, where there was some code to figure out what you want to do, and prepare the correct data for that option. If you wanted to add an entry, it would use blank variables so the form would be empty. If you wanted to edit it, then it would get the info from the database and put it in the variables to pre-populate the forms. The delete would do the same as modify, but also add a little piece to the form that made the fields uneditable. This section would also define the instructional text above the form, change the title of the page, etc.

The second part was the actual page. This was mostly variables, since the title should be different for each, and instructions. This is where the actual form code was written, but it was almost unreadable because of all the jumping in and out of PHP code, or using echo or HEREDOC statements to build the forms.

The third part was the Results section. This is where it would attempt to validate the data, and perform the final database option of adding, editing, or deleting, and display the results. Sometimes this section was bigger than the other two combined if a lot of work had to be done on the data before interacting with the database.

To make things more complicated, I usually did forms on a single page and split them up by how they interacted with the server. This is get and post. When you first request a page, you use GET to retrieve it from the server. When you're submitting data, you're using POST. So if the server got a GET request for the page, it would display the form. If it was POST, it would execute the form processing steps and then add it to the database. This meant my 3 part page was further split into 2 sections, with the Setup and Form parts in the GET section, and the Results part in the POST section.

The end result was a huge, complicated, almost unreadable page that worked, but god forbid I ever need to modify anything in it. It's ridiculous, I would be afraid to change anything because it was so hard to see what the results of that change would be. Would I break another part? How would I ever find that part again if it did break? What a mess!

Now using partial pages doesn't completely negate all that, but it does make it easier to manage. That changes the actual form from taking up easily 40+ lines for a simple form to a single line of code to render that as a partial page. This makes using separate pages for each action far more attractive. You still run into the problem of adjusting for a database change, but changing the form is simple. It's also easier to keep track of what you're doing when you don't have that big chunk of form code sitting in the middle of your work. It makes all the code (except the one line) for those pages only about the task of that page. It was also pointed out to me today that there are other options for doing the delete that don't require the form, so that makes things even easier.

Now the only trick is actually writing it. I'll report back on that later.