Travelocity Researcher is not quite so old, dating back to mid-2007, but it's still a dusting-off of a project I thought finished and forgotten.
B-- contacted me about almost two years ago, as I said, explaining that, as part of his work, he had to compare Avis's rental rates with their competitors every day. To do that, he used a simple Travelocity search, but even with the information available, he still had to record it somehow (and if you've ever tried to copy and paste a table off a web-page, you know how excruciating the next step (formatting) is.
So, with much help from K--, I put together a a script that would perform the three searches automatically, asking Travelocity for rates on an immediate short-term rental, an immediate long-term rental, and a long-term rental sometime in the future. It then parsed the info it got back from Travelocity (using regular expressions) and used tabs (and truncated strings in a lot of cases), to print out the information to a text file. If you opened the text file, it looked like a nearly-organized chart, with rows and columns.
At the time, B-- had asked me how hard it would be to get it converted so people at other locations could use it (currently it's hard-coded for the OKC airport), and I said, "A little bit hard," and that was the end of the conversation.
Then I guess a couple weeks ago B-- got an email from someone else in the organization saying, "Hey, I'd heard you were using this script, and I was wondering if your programmer guy could make it work at other locations," which is essentially the same question I got two years ago, but times have changed.
Specifically, with the economy as it is and travel-related businesses particularly hurting, employees at Avis need every edge they can get just to stay hired (or, as a completely outside observer, that's the impression I get). So I figured B-- handing over the keys to a major efficiency improvement for people company-wide would be a real feather in his cap.
And, to my surprise, when I opened up the script I wrote for B-- oh-so-long ago, I discovered it still worked. I hadn't even looked at it in the intervening time, but the design was pretty simple and straightforward, and mercifully Tavelocity hadn't done anything to break it.
When I started thinking through the best way to make it portable, though, I came to a certain realization. You guessed it: I needed to build a GUI (which, in case you don't know, is ASS). As I said, the old one you'd just double-click, and it would pop up an hourglass cursor for forty seconds or so, and then there was a text file there. That was the whole program.
This time, I went all-out. Running the program opens a window with three search panes (and the Travelocity logo for that polished look). You can open an old file and the program knows how to display it in the three search panels, or you can run a new search, and it will populate the panels with today's data. It also color-codes the data for an at-a-glance comparison to Avis's prices. Then you can save the data from the File menu (just like any other Windows program), and for an extra touch, I learned how to output to Microsoft Office products.
So instead of just writing out a text file with a faux table built out of tab spaces, You can now print out the three searches to an Excel file with separate worksheets for each of the three searches, which also gives you all of the extra functionality available in Excel.
Then I added a Preferences tab, which lets a user enter an airport code (for the location customization that was the only thing I actually needed to add), decide whether or not to include the color-coding when writing to Excel, adjust both the length and start date of each of the three searches, modify where it saves files and what types of files it saves by default, and control web access settings (specifically the timeout length and max number of retries).
And then I had to make all that work. It was no small task. Oh! And save these user settings from instance to instance.
And then I went in and added another script that, using the options stored in the user settings file, just pops up an hourglass for forty seconds or so, and then creates the output file (without ever opening a window), because ultimately that's all you'll want to do.
All of that is done. It's amazing. I'm now in the process of releasing it, which requires two things: user documentation and byte-compiling. For the documentation, I built my own Help system using dialog boxes and some faux hyperlinks, and now all I need to do is finish writing the content (which is about half done). It's the compiling that's giving me real troubles.
There's some software out there, py2exe, which is a free library for all versions of Python. What it does is read through your Python script, find out all of the modules you use when the script runs, and then package those up in a zip file and generate a Windows executable (.exe) file that can draw information out of the zip file. So instead of requiring everyone who uses my program to install Python, I can just have them download this executable and the library zip, drop them in a folder, and run the executable the way you would any other Windows program.
Nice and neat. Except that it doesn't work.
I'm encountering a bug right now that appears to have to do with Python 2.6 specifically (althoug a quick effort to use py2exe with Python 2.5 didn't yield any immediate fixes). What appears to be happening is that the executable works fine on my development machine, or any other computer that has Python 2.6 installed, but won't work at all on machines without it (which makes the whole process of compiling it a complete waste of time). We've used py2exe before with no problems, so I'm sure there's a solution, but it's going to take me some time and frustration to get it figured out.
Still...I'm at the tail end of this project. I could always add more functionality later, but this is a pretty polished package already, if I can just get it compiled and shipped off.
Status: In Development
No comments:
Post a Comment