Web Developer - Front End Intern, Summer 2007, San Francisco, CA
Technologies used: CSS, Firebug, HTML, jQuery, PhotoShop, TeamSite (Interwoven Content Management System)
This internship was done through the Pacific Gas & Electric Company's College Summer Internship Program. Each summer, PG&E hires approximately one hundred college interns. I interned at the Web Channel department for 12 weeks. The Web Channel department is in charge of Pacific Gas & Electric Company's websites (internet and intranet). Even though I was an intern, I felt like one of the web developers. My duties were not limited to what one would usually think of that an intern would do (ex. filing, photocopying, etc.) I was exposed to every part of the web development process but for the most part I stay on the front-end internet side.
I worked closely with one the senior web developer (he was like a mentor to me), but I also collaborated with the other web developers. During my internship I learn how to use the company's content management system (CMS), Interwoven TeamSite. For those of you who don't know what is TeamSite, TeamSite is a software that manages your (internet/intranet) files. It organizes your files in one place (usually on a server) and it prevents two or more concurrently users with the same file opened from overwriting each other by locking the file; only the first person who opened the file can edit and save it.
It was also during this internship that I learn how to use jQuery (a javascript library) and fell in love with using it. It is a very simple and easy to use JS library that came out in January 2006, and is still continuing to gain popularity. jQuery makes writing JS fun again. Not that I have anything against javascript, but most people would agree that javascript can be a bit tedious. I used jQuery to manipulate and traverse the DOM (Document Object Model). For example, there was a page with a long list (more than 10 items), it was too long to have it as one list (too much empty space to the right). Most people would have created a table with two columns and split the list in half. But to be XHTML compliant, table should only be used for 'tabular data' and should not be used for layout purposes. So I used jQuery to count the number of listed items and divide it in half. I then add two different classes to the first and second half of the list; those two classes have CSS properties that defined the position of the two halves of the list. Thus, I was able to make a two column list without having to use a table.
One of my biggest accomplishment during my internship at PG&E was writing an efficient jQuery script for the new PG&E website. The original javascript was a couple thousands of lines long. It is a form (at several different pages/locations on the PG&E website) that lets users enter location(s) of light post to be fixed, turning on/off gas and electric, etc. If there are more than one location that a PG&E service person have to go to to fix the problem, the user can then select a number (up to 25) from a drop down list. The form will then display/shows the additional addresses entry lines; displayed in a fieldset (related form elements grouped together, usually with a border around it). This is what cause the javascript to be thousands of lines long, initially the form is only displaying one fieldset (assuming the user is entering one location), and hidding the rest of the 24 fieldsets. The 24 additional fieldsets is hidden from the user until s/he needs to enter more than one location, and then the additinal will show up on the form (in javascript this is the show/hide element). Most of the time, a user only need to enter the location of one address, thus the code for the other 24 fieldsets are rarely used. If there are codes that are not used, it would be a good idea to eliminate them because having them can cause the page to load slower on the client side. So I wrote a jQuery script that would clone the original fieldset if the user were to enter more than one location. Besides cloning, the script will also append the appropriate IDs to the input field (ex. address1, address2, etc. instead of all the fieldsets having the same IDs, which is 'illegal' because there should be only one unique ID per element).
