I've been thinking about the way I program and how the methods I use affect the productivity in my department.  In many cases, the first solution I can come up with is the one that goes live and the amount of time it takes for the process to run is not a consideration.  The thought is, if it takes an extra click, or if it's easier to take a few extra seconds and switch screens a couple of times, then okay, let's do that.  It's still going to be faster and more accurate than someone manually making the keystrokes.  I tend not to consider if a program I'm writing is going to be used numerous times a day by numerous people in the department, or if the program is going to be used for a 5 line file or a 5000 line file.  It can all add up.

Then there's my current project.  We've determined that the download of a document off one server, converting the document from the current blob format, back into a 'real' file, and then uploading it to a new server, should on average take 4 seconds.  My coworker told me this, and I thought 'hell, that's pretty good'.  Then he reminded me that there are almost a half-million files that we are going to have to run through this process, and that, by his calculation, it will take >9 days of a computer working 24x7.  Doh.

As a lot of people in class are busy focused on learning the programming basics, I'm interested in fine-tuning the skills that I have.  How can I be an efficient programmer?  What are the advanced tools that I can take advantage of?  How can I build programs that are not only easy to use, but are also easy to update and maintain.

2/12/2008 4:07:59 PM (Central Standard Time, UTC-06:00)    Comments [0] Trackback

On the first day of class, Marc made a comment about how if, as a programmer, we haven't had to learn XML, we will at some point.  That hit home with me, because earlier that day I had hit that point.

At work, we're looking at upgrading our online document storage tool.  Currently, we get almost everything into the department in electronic format, yet we still have to print the documents and then scan them into tiff files that get uploaded to an online database and a searchable website.  It's a lot of wasted paper and wasted time.

We've found that the submission and workflow tool that we use has the ability to automatically store the documents - but then we run into the issue of having to replace our website with something that is compatible with the new system. 

The new system is able to provide us an XML feed of our content, and it supports something called XSLT.  XSLT is a formatting language that lets you place a customized skin over the XML feed.  It gives complete control over what information is displayed from the XML and in what format it is displayed in.  This is going to let us create our own user interface, complete with dynamic links and advanced search capabilities.

My success last week was creating my first working template.  It was very basic - displaying my XML records with some simple HTML formatting.  It was the end result of a days worth of trial and error.  The logic to how it applies the formatting is the complete opposite of what I'm used to in programming.  In the basic coding, the data determines the order and the format follows.  This week, the project is moving forward.  I've been able to add a search form and display the results.  I had to brush off some very rusty javascript skills to get that to work.

It's just a start though, and I look forward to learning more.  I love the idea of being able to be in control over how my data is being shown and what can be done with it.

1/31/2008 5:22:16 PM (Central Standard Time, UTC-06:00)    Comments [0] Trackback