Portfolio

Here are a couple of projects I've worked on in the past, some for fun, some for work. They're a good overview of my style and the range of technologies I've used over the years.

RuskinARC: Historic Property Management

RuskinARC is my most recent project, stemming from a chance reunion with someone that I used to work with in 2001. He works as a historic preservation consultant and came to me with a unique problem.

Since about 2003, he had been working on a web application in Perl that cataloged and reported on historic survey work done for cities. Most of the historic work done now is all performed and stored in big paper binders and he thought it was high time to revolutionize that industry. The issue was, while he had built the system himself from the ground up, it was very tied to using flat file databases and had gotten quite hard to modify.

At the beginning of 2011, he asked me to take a look and I started on a job to rewrite the whole thing in PHP with a MySQL back-end. I chose the Kohana framework, since it has ended up being, for me, the best of the fully object oriented PHP frameworks that is very simple to extend and test. In a month, I was able to rewrite the whole application, making it faster and more customizable. After completing that, we started on his wish list that he had been saving for years and added Google Maps, searching, photo attachment, revision management and much more.

One of the most interesting problems was one of flexibility. We allow all collections of resources to be shown as a map, as a table and as a collection of photographs saved on the resources. As you add one, it shows on the map and everywhere else you would expect. But we were just showing searches as a table of the matching properties. But it's a search just a collection of resources itself? Shouldn't it work just like any other collection?

Thinking along this idea brought me the abstract the collection motif out and build a system that allowed other back-end classes to substitute for a concrete collection class. Now you can have a search collection that acts just like a regular collection. After a search, you can view the results in a map, table and collection of photographs. You can also draw a boundary around a subset of resources and then view everything in the boundary as a boundary collection with a map, table and collection of photographs. These subclasses of collections bring the power of the application to every aspect of the system.

To get a feel for the application, feel free to check out the demo from the main site.

FirstEnergy Corp.: Billing and Payment Site

This happened about a year after I was hired at the company in 2006. I was put in as the Tech Lead of the programming behind the redesign effort as we moved onto some new SAP NetWeaver JEE web servers and brought in a company to do a full redesign of the site. The back-end/front-end programming was handled by me and three contractors in the Struts 1.2 framework using Java EE 1.4.

I structured the site into a couple of separate applications with a couple of different layers in between; the JSP view layer, the Struts Controller layer, a business delegate layer that handled all the business logic, and then the model layer that was actually a mix of Oracle database facade objects and SOAP web service objects. It really sounds like a ton of layers, but it really kept everything in it's own black box and made having four people in there mucking around at the same time really easy. It really proved itself recently as the site is being moved to an OSGi container and most of this code is being moved and used as-is, saving a ton of conversion time.

As anyone who programs in Java knows, separate applications on a JEE server don't share sessions, so wasn't that a pain? We definitely wanted to have SSO and share the sessions across all the applications, so I wrote a "Global Session Object" that would save session information in the users session and in a database. This was all handled via HttpSessionListeners and HttpSessionAttributeListeners. If an attribute was added that started with a certain key in it's name, it would also be persisted to the database. We would also track how many applications the session was attached to, and when it reached 0, we would clean up the database. This got us around an huge stumbling block and the nice thing was that the Java developers never even had to know it was there. They could use the session as normal and everything happened behind the scenes.

LiesWeTellOurselves

I had a silly idea for a website and decided to code it up in Python to see how I liked programming in Django. I have since put the code up on GitHub, so you can get it here: GitHub - LiesWeTellOurselves

The main concept behind the whole thing was that we all have things we like to tell ourselves that we know aren't true. "How many other people believe these same things?" I wondered. I envisioned a site where you could post the little white lies anonymously and others could come to the site and vote up the ones that they do also and even add their own into the mix. It also had to be very AJAXy. That's very important.

By far my favorite feature of Django is just the absolute ease of testing. The ability to write tests right in the docs of the Model classes and using fixtures and writing full-stack integration tests were just a dream. I worked on this far too long for it's usefulness mainly because it was so damn enjoyable.

I was constantly working to make the code as compact and quick as possible and I remember one challenge really stood out. I was allowing people to vote on the lies as a thumbs up or a thumbs down. I was saving them as individual entries in the database and linked up to the lies table and needed a way to add them all up to give a total. I'm not a fan of duplicating data in my database for any reason and decided that the best way was to loop through all the votes for a lie and sum them. I eventually came up with this:

return reduce(lambda init, item: init + item.value, self.votes.all(), 0)
If you don't know Python that line might be super confusing, but just know that I was so proud of that when I wrote it.

Move Command Line Script

I'm a programmer that likes to "scratch his own itch", as they say. One of the problems I ran into at an old job was that we had a remote test server we ran all of our development code on. Standard practice was to edit the files on the server and then refresh your browser to see if the changes worked. This process didn't include version control, didn't take into account network drops and didn't scale at all if two people happened to be trying to work on the same thing at once.

The Dude did not abide.

Wanting a better system at least for myself I pulled all the code locally, set up a SVN repository locally and just uploaded the stuff over an SSH client when I wanted to test. This became a bit of a pain since I was mainly working in the command line, or at least an editor with a command line, and hated to constantly switch between the editor, SSH client to upload and then browser to test. So I wrote move.rb:

move.rb is a simple script that takes filenames or directories from the command line and uploads them to the server. The key is setting up a config file at the root of the project called .move and setting the first line to the connection string of the server, like me@myserver.com, and the second line as the corresponding root folder on that server, like /htdocs/project. It's then very simple and easy to just call move.rb put index.html media/ to move index.html and everything changed in /media up to the server or move.rb get portfolio.html to pull portfolio.html from the server down to your local computer (always a good idea when working on a project with no version control and everyone else is editing the files directly on the server, which I don't recommend anyway). And since it uses rsync, which will only transfer files that are different, you can specify a whole directory and not worry that it will take forever if you only changed one file in it.

You can also run the command anywhere in your project tree and the script will move up the tree until it finds an appropriate .move file. So you can actually keep all of your files in one place on your local computer but still have different directories going to different places on the remote server or even completely different servers.

This certainly doesn't replace a good build script, but it can help when doing quick projects or file changes that you need to get out to a server to test.