Sarah Vessels' (CS) second tour at Lexmark, Fall 2006

Lexmark International Color Science and Imaging

Sarah graduated from Edmondson County High School in 2004

Fall 2006, Tour 2 Web Design and Graphics

"I made use of my skills as a web designer and graphics designer to create visually appealing pages. Besides having pretty graphics and page layouts, as a programmer, I was concerned with having pretty code."

  Sarah had two main projects this rotation (her second): a time tracker and a comparison tool. She had written the comparison tool in her first tour, but it was also the first application she had written in the Ruby programming language using the Rails framework. After a semester of additional coursework, she decided that her coding style and mannerisms, naming methods, and even the general flow of the program were much messier than a typical Ruby application.

  "So, I rewrote the comparison tool, still in Ruby using Rails, but much more comfortably with the language. The rewritten application works much faster and offers several new time-saving and ingenious features to the user. For example, previously, one could only compare the scores of the chosen printers in one metric at a time. In the rewrite, all the metrics can be compared at once. Another improvement was that with the previous version, only an HTML table of the results would be generated initially; if one wanted the results in a graphical or plain-text format, further submissions of the form would have to be made. Now, the HTML table, the image, and the plain-text results are all generated at once and displayed to the user in an organized tree format, much like how data in Windows Explorer is laid out. This layout is also made use of in the rewrite's entire query form, since it is a clean way to display lots of data. The user can show or hide whichever parts of the form he or she wants, and it also has familiarity to it as it is a structure seen in various other applications and web sites.

  Yet another improvement I made in this tour to the comparison tool involves the generated graphical result. The graphical result is the main point of the application and is considered to be the most important part. Therefore, I worked hard at making the generation of that image faster and smoother for the user. I dropped several seconds off the time it took to generate all the results, particularly the image, by optimizing my code as well as by switching to a different image generation library. There were also improvements made to the appearance of the result image. It is now more attractive with a modern look, and the data is laid out in a more organized and easily read manner.   The time tracker project was a new one that I received just this semester. My manager wanted an application that would keep records of loose estimations of time that developers spent on projects. The application should be on a login-only basis, should allow managers to view the logged hours of their team members, and should be able to generate graphs of said hours. One new thing that I had to learn in order to write such an application was knowledge of a graphing library, so that I did not have to generate all graphs by hand, but rather have the ability to give hour data to the library and have a graph generated for me. Gruff Graphs was the library that I chose because it too was written in Ruby and worked well with Rails. It also offered theming, so that I was able to write in the functionality for users to be able to change all the colors and fonts of the graphs they generated.

    The time tracker keeps track of three types of user: administrators, managers, and regular users. Administrators have nearly complete power over all the data stored in the time tracker database and can view, edit, and delete all of that from within the application. Managers can assign other users to groups that they manage in addition to logging hours themselves and graphing hours that their team members have logged. Regular users can log hours and generate graphs of their own hours. The time tracker also differentiates between programs, which are large networks of projects, and projects, which are individual applications. The tracker associates each project with at least one program, as well as with any number of groups. Users can only log hours for projects that are associated with groups to which they belong. This way, managers can choose where users can log their time. The idea was to give each particular level of user the appearance of having great control without sacrificing security.

  Since both the time tracker and the comparison tool are web applications, accessibility and usability were two very important topics. I had to ensure that everything functioned with or without Javascript, in Internet Explorer or Firefox, if the user had no images and no stylesheets enabled, and under many other circumstances. It was my goal to ensure that each user, no matter their disabilities or technological shortcomings, could access all parts of the applications and use every feature. Some features were impossible to implement without Javascript, but those features degrade gracefully so that, for example, instead of search results appearance automatically as a user types a query, the user instead must submit the form before seeing the results.

  As web applications, it was also a concern that they be easy on the eyes. I made use of my skills as a web designer and graphics designer to create visually appealing pages. Besides having pretty graphics and page layouts, as a programmer I was concerned with having pretty code. While the Ruby language lends itself to writing beautiful code, it was still a focus to comment every class and method, and provide further comments in confusing areas. Since each application was written in Rails, future developers of these applications can use one command to generate full API's.

  I mostly relied on knowledge that I had to acquire myself in order to do this job. While the computer science background from UK was a foundation, the specific languages, frameworks, libraries, operating system, and even programming concepts, such as the LDAP authentication used to allow users to log into the time tracker, were not specifically covered in my classes. The Internet and various programming books were invaluable to me in achieving my goals in this tour.

  A typical work day for me began by arriving around 7:30 a.m. (by my choice-my manager was fine with 8-9 o'clock) and eating a bowl of instant oatmeal while I read the morning tech news. I would then begin with whatever I had left off with the previous day, and program until I had 1) achieved a particular goal, 2) gotten frustrated enough to take a break, or 3) realized I'd been coding for three hours straight and should take a breather. It became a habit to go out at least once a week to a nice place with my coworkers; popular spots were Siam , Fusion Cafe, and San Marco's. After lunch I would resume my code-break cycle until it was time to go home, which was usually around 4:10 p.m. I worked 40 hour weeks and preferred to work more on Monday-Thursday so that I could get off early on Friday.

  Lexington's cost of living is about average, I would guess, from my limited experience of living here and in rural western Kentucky . My salary was more than enough to pay rent, a phone bill, an electric bill, a gas bill, for gasoline, for groceries, and for the occasional shopping trip. My finances have also been supplemented by student loans and scholarships."