Internship Report: Rio Software, LLC
1.0 About Me, in Brief
|
My name is Andrew C. Vogan. I am currently a computer science senior (fall 2002). But I am only starting my second year at JMU, since I transferred in from Blue Ridge Community College with half my BS degree already completed. That's a slight oversimplification, though: I came in with half the credits for my degree, but zero CS classes so far. So it has been an interesting few semesters getting started here, and finally having freedom to focus on my major coursework, with no troublesome gen.ed. classes getting in the way. |
While I did take my first college CS course last fall, I am not really new to programming. I have been programming seriously for about 10 years, and professionally for the last four years. Working my way through school has been strenuous sometimes, but also enjoyable overall, since I have remained employed in my field of interest. Primarily, I worked for a software company near Harrisonburg, helping with development of their Windows application suite for medical practices (we primarily used Microsoft Visual Basic).
In the CS transfer & freshman orientation class I took
last fall, I can remember Professor Lane repeatedly telling us,
"I would like for all of you to do internships. You will
benefit from it in many ways."
"I don't think so," I thought, "I already have a
job." But when financial difficulties forced my company's
owner suddenly to lay off all programming staff at the beginning
of this year, I remembered Professor Lane's advice, and decided
to seek an internship for the summer.
2.0 Getting the Job
2.1 How I advertised my availability.
My first step was to search the Internet for sites that had
internship listings. I found many good resources; but predictably
no opportunities in my local area. (I preferred working in
Harrisonburg to moving up to Northern Va. or elsewhere, so that I
could take an extra JMU class this summer.)
Next I paid a visit to Mr. Allen Berg, who assists the CS
department by helping to line up student internships. This past
spring, he would accept student resumes and forward them to
"partner sites" - companies that had registered
interest in getting interns from JMU.
But it wasn't quite that simple. When I first met with Mr. Berg,
he changed briefly into Col. Berg; and the first thing he did was
to take my resume and tear it to pieces, figuratively speaking!
In our meeting he assumed the perspective of a potential
employer, and pointed out everything in my resume that he saw as
unconvincing rhetoric, unclearly stated, or simply irrelevant
"fluff." When he was finished, I had in my notes a very
clear idea of what needed to be rewritten to provide my best
showing to employers. Let me emphasize that as long as Mr. Berg
continues to offer his excellent internship help to CS majors, I
recommend taking advantage of it.
Mr. Berg sent my finished resume off along with the others; but
it was simply a bad year for tech internships, and few companies
seemed to be hiring. As it turned out, I heard nothing back from
any JMU partner sites.
2.2 How I found out about job openings.
Mr. Berg's help was certainly invaluable for reworking my resume;
but the best option for pursuing internship opportunities lay in
taking initiative and pursuing possibilities as I came across
them. My primary source was the CSOfficial mailing list, which I
watched for any job listings.
There were a few disappointments. Once I politely declined an
interview, after finding that the company's business model was
based on some kind of pyramid scheme. No, thank you! You run into
all sorts of interesting situations when you're searching around
in the job market.
Finally a possibility came along that seemed better in many ways
that anything I had expected. It was advertised in the CS mailing
list. The job included programming in my favorite language (Borland Delphi); it was
located in the local area (Harrisonburg), and it offered a pay
range that didn't cause me to wince (based on the salary I had
drawn professionally). The position was working with Colin
Sarsfield, a programming consultant and owner of Rio Software, LLC. One
thing that caught my attention was that the job involved pair
programming, something I had read about from the XP (eXtreme
Programming) movement.
2.3 How I Landed the Internship
As soon as I found out about this position, I customized my
resume and cover letter for the job description, and sent them by
e-mail, as requested in the advertisement.
A day or so later, Colin called me up to arrange an interview.
Things were just a little bit crazy at the time, because it was
nearing the end of the spring semester, I was taking 20 credits,
and my time was at a premium. But I made sure to be fastidiously
organized and professional in my preparation, including
familiarizing myself with his web site, and making sure to bring
along any materials to the interview that might be useful to
reference, such as the internship syllabus, FAQ, and relevant
forms.
The interview went very well; I answered everything he asked as
well as I could, which included some questions to test my
technical knowledge. (I will probably do better on a few of them
after I take CS 352.) I think that the reason we
"clicked" in the interview was that I was able to
communicate my general enthusiasm for programming, and my
intention to stay in the field for the forseeable future. Another
thing that definitely helped was my existing familiarity with
Delphi, a benefit he hadn't really expected, since it is a
less-used language.
After a few weeks, he called and offered me the position. Since I
still hadn't seen anything that interested me nearly as much, I
accepted, and we agreed on a starting date.
If I did it all over again, one thing I would probably do
differently would be to give him a call to ask how things were
going, fairly soon after sending in my resume. Many employers
actually like to be bugged like that, because an applicant is
demonstrating that he is truly interested in the job.
3.0 About the Job
3.1 Employer
My employer is the owner of his company, and an independent
programming consultant (member of the ICCA). I work at the same
computer with him throughout the day, as I mentioned before.
Actually, pair programming is a major part of his reason Colin
decided to get an intern -- to help protect against RSI (Repetitive Strain Injury).
Because of Colin's existing problems with RSI, I generally get to
control the console.
We usually worked from nine to five, Monday through Friday;
though he was kind enough to let me adjust my hours and take a
class for part of the internship.
It might seem like working at the same computer as another
programmer would get old quickly; certainly I wondered how it
would turn out. But in my research on XP, supposedly the benefits
include improved task focus and discipline, reduction of the
defect injection rate, and better design. Whether having two
programmers at one machine is overall more efficient than having
them work independently, I still don't know. But I do know that
we have realized all of the benefits I named, to a level that has
been surprising to me. Anyway, I'm sold on it.
Now with that said, it definitely does make a difference who you
do pair programming with; but I will go on record by saying that
Colin is a genuinely nice guy, who has been more than willing to
discuss and debate issues related to development, and has been
quite patient with me as I've slowly built industry, code base,
and general CS knowledge.
Of course, I have had to be willing to adopt his coding and
documentation styles. One thing he noticed was that I am a little
bit, uh... hyphen-happy. I don't know why; I'm just a
hyphen-liker. Colin almost never uses hyphens. So you see that
even little things like that can potentially become an issue, if
two people are programming on the same computer all day. This
just underscores the importance of mutual courtesy and respect,
to create a productive work environment.
The hyphen example is a little trivial; but there are many of
Colin's standards, ranging from areas like identifier naming to
code structure. Becoming comfortable with these has been an
important part of getting up to speed for me. I often find that
as soon as my comprehension of a particular code base increases,
the logic of the associated standards also simultaneously becomes
clear. There is generally a rhyme and reason to Colin's
programming practices. And as I've assisted in extending his code
base, I have also helped in extending and documenting his
standards, which has been both enjoyable and educational.
3.2 Job Description
One of the benefits of pair programming for me has been that I
got on-the-job training, everyday. So I did not need a protracted
orientation period. Because Colin already knew what he was doing,
we were productive from the day we started. Granted, I did more
observing at first, and for a while it was more like taking
dictation than programming! But I started catching on, asking
questions, discussing implementation details, and finally
accepting often his challenge to proceed on my own on a project
with little direction beyond what I had learned already.
Here is a list of some of the main things I do in my job:
- Delphi OOD (object oriented design) and coding, in a pair
programming environment.
- User interface design and coding, typically generating the bulk
of UI elements on-the-fly from very concise and flexible code.
- Optimization, using a code-instrumenting profiler.
- Creation of automated unit tests (which have made our lives a
great deal easier).
- Documentation writing, in several formats and structures
including WinHelp.
- Automation of tasks by use of MAKE, batch files, and sometimes
our own command-line utilities (we both prefer the command line
to visual utilities, for the sake of easier automation).
- Use of the TextPad
programmer's editor to manipulate text in many ways using
hundreds of macros, regular expression search and replace, and
other features you won't find in Notepad.
- Use of WinCVS on a regular
basis to see which files in a particular application's directory
tree were modified, followed by a Diff and WinCVS check-in.
- Application setup packaging and deployment.
Here is a list of some of the major projects we have worked on
during the internship.
- Four different equipment rating/selection programs for HVAC
manufacturers.
- Many XP-style unit tests for key modules in the programs.
- Five different command line tools for process automation.
4.0 Typical Work Day
Because Colin and I currently are Rio Software, we get
to work on a wide variety of interesting tasks; but what follows
is fairly typical of our work.
On this day, I came in at 9:00 AM, my usual starting time. One of
us marked the time sheet with the current time, as well as our
initials to show that both of us were working, and the name of
the client company and specific project we would work on. All
these are important because Rio Software has multiple clients,
which are billed by the hour. Colin also uses this timesheet as
his record of my time.
Currently under construction was our unit ventilator selection
program. Our first order of business was to work through e-mail
correspondence from engineers at the manufacturer, to clear up
some discrepancies in their documentation.
Using the updated spreadsheets we had received, we were able to
update the data tables within the program, and came that much
closer to being able to present all unit ventilator options the
manufacturer offers in our program. In addition, we added new
rules to the selection process to ensure that only valid option
combinations could be chosen. It was a little tricky remembering
to update the new equipment options in every different place that
needed to reference them. At one point I was rapidly getting
confused by the rules logic we were implementing, when it
occurred to me that we had to put some of the same code in up to three
different places. So after some discussion and some thorough
code research, we integrated the two routines, so that pricing,
UI display, and output/report presentation code used the same
logic to determine option visibility. Ha! A victory for concise
coding, and a change to make our lives easier in the future.
We also slowed down at one point, and had a discussion on ways to
modify the user interface to provide friendly and instantaneous
context feedback to the user, and how the existing
object-oriented framework might lend itself to an elegant
implementation of in-program help and status information. The
object oriented design is so tight in this project, that many
things are possible; but you also don't want to go rushing into
changes that violate the "aesthetics".
We took an hour for lunch, after which we worked until around
5:00 (or thereabouts, as soon as we reached a logical
"stopping point".)
5.0 Relevance of CS Studies to Internship
The CS classes I had before the internship were CS 139, 239, 280,
345, and 348. Of these, I would rate 345 (Software Engineering),
the highest in terms of relevance to my job. In my years of
programming professionally, I have often seen the value of
keeping tight control over the development process, by means of
responsible practices such as task prioritizing; and by means of
tools such as version control systems. As an example, we use WinCVS as our source
code/version control system. We check our work in, not just
daily, but after every important change. And every time we check
a file in, we perform a "diff" on it first so that we
can (a) quickly inspect the changes, and (b) add a descriptive
comment about exactly what was changed to version control. Having
revision histories of every file has often been a great benefit
to us.
The other musing/advice I have for future CS interns is: Do not
underestimate the importance of a strong background in
mathematics. Do not underestimate the importance of wide and deep
exposure to algorithms. Do not underestimate the importance of a
working familiarity with logic and obscure Boolean constructions.
If you get a programming job that is any fun, you will end up
needing all of it.
6.0 Relevance of Internship to CS Studies
One thing I enjoy about working with Colin is that he is serious
about expanding his horizons as a computer scientist. As an
example, just the other day Colin and I were performing a test
run of an air conditioner unit selection application. Just
playing around, I repeatedly copied and pasted the contents of a
list display, making the list grow quickly to thousands of items
(each item in turn encapsulating thousands of different
attributes). The program slowed down to a painful crawl.
So we fired up our code profiler, and analyzed where the slowness
lay. As a result of this analysis, we ended up increasing the
efficiency of our sorting code, taking it from a simple quicksort
to a hybrid quicksort/insertion sort, as well as updating the
code behind our XML data conversion units. In all, our changes
provided a speed increase of well over an order of magnitude for
many operations.
This was just one example of how an everyday situation in my
internship was taken advantage of as an opportunity to expand my
knowledge and proficiency in programming. Rather than living with
a minimalist implementation, we researched ways to improve the
quality of our solution. One thing my boss repeatedly urges is,
"Don't program by accident!" Surely this is a major
goal of computer science - to find creative ways to go from
creating haphazard solutions to well-understood and
thoughtfully-designed ones.
Listing 1 -- cleanrtf.sed, a SED script we wrote to perform several "clean up" functions on our RTF WinHelp source. If you can understand this without reaching for a reference, you are more of a UNIX person than I am.
s/\\page$//g
s/[K$#]{[^}]*}//g
/[K$#]{[^}]*/{
$!N
s/[K$#]{\n\|[^}]*}//g
}
Listing 2 -- TC.dpr, the entry point for our Table Compiler command line utility, for flexible code generation from spreadsheets.
{
DESCRIPTION:
Parses the file name(s) of tabular source data for compilation as
described
in Compiler.pas.
COPYRIGHT:
Copyright 2002 Rio Software, LLC. All rights reserved.
HISTORY:
Created on 7/17/2002 by Colin Sarsfield & Andrew Vogan
}
program TC;
{$APPTYPE CONSOLE}
uses
..SysUtils,
..Compiler,
..RSLExcept in '..\RSLExcept.pas';
procedure Main;
var
..WaitForEnter: Boolean;
..i: Integer;
..TableFile: String;
..procedure DoWait;
..begin
....if WaitForEnter then begin
......WriteLn('Press ENTER to continue...');
......ReadLn;
....end;
..end;
begin
..WaitForEnter := False;
..WriteLn('Table Compiler 1.0 Copyright Rio
Software, LLC 2002');
..WriteLn;
..if ParamCount < 1 then begin
....WriteLn('Usage: TC [-w] file1 [file2 ...]');
....WriteLn;
.. .WriteLn('.. -w..
Wait for user to hit ENTER.');
....Halt(1);
..end;
..for i := 1 to ParamCount do
....if ParamStr(i) = '-w' then
......WaitForEnter := True
....else
......try
........TableFile := ParamStr(i);
........CompileTableFile(TableFile);
........WriteLn('Finished compiling: ' + TableFile);
......except
........on E: Exception do begin
..........WriteLn(E.Message);
..........DoWait;
..........Halt(2);
........end;
......end;
..DoWait;
end;
begin
..Main;
end.
Miscellaneous images selected from my daily programming at Rio Software.
A sample of Delphi's code explorer, currently
browsing
one unit within the highly object-oriented PEF Select product.
WinCVS, our source code/version control system.
MEC, the Dunham-Bush Malaysia Electronic Catalog
rating/selection application
PEF Select, the PEF Industries, Inc. rating/selection
application
TC, our Table Compiler command-line utility providing flexible
code generation options from spreadsheet sources.
