Posts Tagged ‘Programming’

Internship In A (Large) Nutshell

October 30, 2008 2 comments

How It Came To Be

This summer (Summer ’08) I had a 3-month internship with Thetus, a semantic knowledge modeling and discovery software company based in Portland, Oregon (my home town).

How I got the internship was amazingly unexpected.  During Winter term last year I had a CIS course in which I made a good impression on my professor.  Towards the end of the term I was looking around at internship opportunities, but unfortunately most I found required someone to be further along in the CIS degree; it was looking like I was going to have another summer of video games (bittersweet, huh?).  I then recieved an email from my professor asking if I was interested in a summer internship in Portland.  How perfect!  He was friends with the founder of the company and they came to him in search of an intern.  As I had made a good impression on him, he thought of me.  Of course I said yes, and he got us in contact.

I then had to make 2 trips up to Portland to meet with my “boss,” or the developer who I would be working directly underneath/with.  During our hour-long meeting at a Portland coffeeshop we ended up talking about music and University of Oregon professors and classes.  As it turns out, my “boss” was a recent graduate of University of Oregon (where I am currently a student) and even has the same major and minor that I do.  So we had a lot in common, we had a comfortable talk and we discussed my skills and knowledge for about 15 minutes total.

It turned out well as they asked me back again a few weeks later for a meeting with one of the founders.  We met at the office so I was able to check the place out and meet some of the other employees.  The meeting wasn’t as smooth as my first, but nonetheless was successful.  A few days later my “boss” called me and told me they were pretty excited about bringing me on board but still had to get the okay from the real boss.  Several days later I recieved another phonecall, this time from the real boss, to tell me congratulations and discuss details.

The Happening

So, summer came along and I immediately went to work for Thetus, from June 23rd to Septemeber 23rd.  Aside from various small things, I spent most of my time writing server-side and client-side applications.

I used Adobe Flex for client-side applications, Java for server-side programming, and JSON for communication between the two.

I wrote these applications to get experience with semantic technologies, abstraction, and ontologies. My applications were mostly for in-house use – not something that would be given to a client. For instance, I spent about 2 months working on an application that displayed a family tree (in a detailed and abstraction-supported way). The company offered several courses on how to use the knowledge and software they provide, and this application was to be used in the demonstration to provide a visual, interactive component. The courses use a family tree as an example, particularly the Kennedy family tree. So for 2 months I learned about the Kennedy family while writing this application.

For the last month or so, I began working on another application that was to be given to a client as an example of the services provided by Thetus. At one point, I was given a list of features that I needed to implement by the end of the week, and furthermore, the application was going to be demo’d to the client by the boss! That was an incredibly stressful time as I had to work late and come in early, and even after all that I failed – I couldn’t get all the features implemented fast enough! I had to give screen-shots to the boss to demo – man, what a feeling of failure. Apparently the demo went fine anyway, and not having the application working wasn’t as big of a deal as there was already a second demo planned. I wasn’t going to be around for that, so another developer was to pick up my application and finish it.

Aside from those Flex/Java applications, I wrote a couple other programs. One was written in JavaScript and was to be used in tutorials to present code snippets, and another was written in pure Java as a command-line tool to read through a set of (real-world) locations, query a geo-coding service, and write the latitude/longitude to these locations. I also had some experience with Ant for Java build-scripts.

In The End

All-in-all, I learned a wealth of information that I couldn’t while sitting in a classroom and doing homework. Despite being the youngest (both in age and education) intern they’ve had, they were pleased with my performance and asked me back as an intern next summer, or as an employee with a position and salary. Wow, that’s quite a good start to my career. I will definitely be returning in the future. I can’t thank my professor enough for thinking of me.


Formatting Your Functions

October 27, 2008 Leave a comment

I’ve noticed in a lot of code people tend to write entire functions within an if/else block, particularly when error-checking must be done first-and-foremost in the function (like verifying parameters). I write my code differently; let me explain why.

To show you what I’m talking about, I’ve created a basic example:

public double calculateMass(Object something)
     if(something != null)
          // Perform calculations
     } else {
          // Error

This is poorly formatted for several reasons:

  1. Someone reading this code must scroll past the entire if block to see the else block. It should be clear from the name of the function what the if block does, but it is not clear how the function reacts to errors, which are in the else block.  The reader must skip over the giant if block to see the else block, hidden at the bottom under a giant formula of physical calculations.
  2. This indentation is unnecessary and makes the code harder to read. Anyone who’s written code knows things get messier the more they’re nested in blocks.  In the example, the code is immediately nested, already making further blocks 1-level deep – off to a bad start.
  3. An if-else wrapping the entire function implies the function has 2 calculations. Depending on some condition the function will perform a different calculation; one calculation in the if block and the other in else block.  In the example, this is not the case; the else block contains nothing relevant to the calculation.  The calculateMass function only has 1 calculation: to calculate the mass of a given object – there is no ‘else.’

To better highlight that the function has only 1 purpose, this “main” code should begin in the 0-level indentation of the function, i.e. it should be flush with the left-most indentation of the function. For example,

public double calculateMass(Object something)
     // 0-level
          // 1-level
               // 2-level
                    // 3-level

To handle the error-checking and remove the else block, a simple if block with a negation should be used prior to the “main” code.  For example,

public double calculateMass(Object something)
     // This is the negation of the original condition,
     // 'something != null'
     if(something == null)
          // Error

     // Perform calculation

With this format, it is clear to anyone first viewing the code how the function handles errors. Since they can already assume that the code that follows will calculate mass, there is nothing left unknown to the reader at this point (aside from implementation details).

Got an objection? Got your own formatting you prefer? Share it in a comment.