Table of Contents
Markit On Demand — Jun 2014-Aug 2014
Markit On Demand is a consulting company specializing in web development for financial institutions. As an intern I was assigned an in-house project: to make a website for the Design Team. The website functioned mostly as a well-designed wiki with a superior What-You-See-Is-What-You-Get(WYSIWYG) editor. I worked with a fellow intern, Alex Kessock, on the project.
For this project, we were given free reign in terms of designing the stack and choosing the tools we used. We worked closely with the head of the Design Department to get the proper look, feel, and ease of use for the website. In the end, we decided to focus on creating an easy user experience, and to help us do that we decided to use Drupal to take care of the back-end.
Alex worked with the CSS and Javascript, while I worked almost exclusively with Drupal’s multitude of modules. Among these modules were:
- Views
- Views PHP
- Wysiwyg (with CKEditor)
- Rules
- Entity API
- Media
- LoginToboggan
- Lightweight Directory Access Protocol (LDAP)
- Various PHP Modules
This project was a fantastic opportunity for me to experiment with a Content Management System(CMS). I had never looked into CMS before, so I was very curious about it.
Originally, though, I wan’t too thrilled to use any CMS. I had really wanted to work on a large-scale site completely from scratch, to get a better feel of what it was like to build a complex website. But, in the short two and a half months I would be with Markit, I came to appreciate Drupal. It gave me the opportunity to work on more important things than devising a backend system.
While designing the website, however, we came to a point where the functionality asked for by the design team was not easily implemented in Drupal. Or, at least, there were some aspects of functionality that did not have modules available. So instead, I used custom PHP modules. For example, we were expected to display a relative “Last Edited” date for articles and comments on the site. I wrote custom php code within a module to translate the difference between the “last edited” timestamp and the current timestamp to relative time periods. The relative time periods included today, yesterday, days ago, months ago, and years ago.
Another aspect of the project was to connect Drupal accounts to Markit’s LDAP servers for easy authentication. While there was a module for LDAP, it was still a challenge to set up the authentication in such a way that it would not break should an account disappear.
As part of this project, we also worked with the Quality Assurance (QA) interns to make sure the project was meeting guidelines and did not have any bugs. This was the first time I worked with a QA team. Getting almost immediate feedback on bugs was fantastic. It helped Alex and I fix bugs we had missed and get the site finished, 99% bug-free, before our internships ended.
This project also gave me the chance to really explore web development as a career opportunity. Overall I found the entire process rather enjoyable. I certainly enjoyed my work with Markit far more than just coding assignments for class.
Lexmark International, Inc. — Jun 2013-Aug 2013
Lexmark is primarily a printer company. They design and manufacture printers and toner. As an intern, I worked with the Firmware Security team on some printer functionality that the team kept pushing back because of higher priority items.
My first project was to add a new function to the printer so that an administrator could filter printer logs by criteria, such as the name of a user, the date, the application accessing the printer, etc.
This project was meant to help me better understand the printer firmware system, and so was small in scale. However, in order to implement this functionality, I had to understand how different software pieces of the printer communicated via an object bus designed by Lexmark. I spent a good amount of time just looking at code and experimenting to see what would happen when I messed with things. It was a nice first look into Lexmark’s system and allowed me to be better prepared for my second project.
My second project was to create a program that auto-configured a wireless printer to use the fastest server available for Kerberos authentication. It also created the Kerberos configuration file so that users would not have to.
Going into this internship, I had absolutely no idea how any authentication systems work. Prior to even starting the project, I had to read up on how Kerberos authentication worked in the first place. I had to learn what the essential pieces of a Kerberos configuration file were so that I knew what lines to write.
Not only that, but I was using the unistd C library very heavily, and for the first time. Everything I did for this project, except for using C itself, was brand-new to me.
One of the tougher moments I had during this project involved pinging the available servers in order to choose the fastest one. Originally, I had not taken the time to read very far into the various ping configurations. Every once in a while, while testing my code, the program would run for large lengths of time, upwards of 10-20 minutes, and even then would not always terminate. It took me a great deal of time to figure out that the ping would sometimes hit a slow server that may or may not be down, and the ping would wait patiently for a return, even if no return would ever come. In order to fix this, I had to do more research into the workings of the ping command I was using, and figured out how to set a default timeout, such that the ping would give up after about 2 minutes. After that, my code ran smoothly.
After writing the program, I had to make a user interface accessible from the printer’s preference page. The only things required to set up the configuration file were a username and password for authentication. I used some basic HTML5 form elements, which spoke to some back-end java code. Honestly, this part of the project was mostly automatically generated by some nifty Java/Eclipse functionality, but it did give me my first practical look at Java, and while many of the functions were generated, I had to modify them and make sure they led to my C program and behaved in the way I expected it to.
Overall, I found the work rather enjoyable. I got to learn a lot of valuable information in a real-world setting. However, staying mostly in the back-end was not my favorite. Firmware is important, and I appreciated the opportunity to work with it, but it wasn’t for me.