Log in

entries friends archive profile Lupinia Studios Previous Previous Next Next
Rebuilding My Website, And Consolidating My Gender Presentation - Lupinia Studios
Randomness from Natasha Lockhart
Rebuilding My Website, And Consolidating My Gender Presentation
My personal website tends to get a redesign on a pretty regular basis, usually once every year or two. The last one was completed in 2012, and I've been reasonably happy with it; it was a challenge for my design skills at the time, and it holds up pretty well a couple years later. However, the underlying codebase hasn't had a significant overhaul since 2006/2007. That was when I started dabbling in custom PHP, gradually adding features and assembling a surprisingly robust application framework, to which I later added a content management system, and some other modular components. This framework has improved over the years, and was partially rewritten once, but the site's underpinnings haven't changed dramatically over the years.

At the time, I was damn proud of this project, and even tried to sell my framework a couple of times. Looking back on it, not so much. It holds up in some ways; I've yet to see PHP code as cleanly-written as mine, the CMS I developed has some features I've never seen anywhere else, and the database abstraction layer, while rudimentary, remains something that a lot of PHP apps aren't doing (and would benefit from). At the same time, I thought I was building a universal tool, when I was actually building something that really only worked for developing sites similar to mine, built by me. My attempts to document it for others to use reinforced this; when I took an objective eye to it, there were SO MANY things that required lengthy explanations.

The real kicker with the PHP framework I built, though, was development time. I greatly favor doing something right over doing it quickly, and trying to build new modules for the system was always excruciatingly slow. It got to the point that, once I started my full-time job, I really didn't have time to touch my personal site at all, because there was nothing I could do to it that didn't call for hundreds of hours of coding. So, my aspirations for my website teetered between "I guess it's good enough as-is" and "Once I finish such-and-such at work, I'll have more free time". Neither of those was productive or satisfactory.

Enter Python, and the Django framework.

I discovered Django on a whim, during the course of an unusual and highly perplexing project at work, one that had some of the strangest and most difficult requirements I've ever heard of in a web application. I knew it would require a great deal of custom coding, and I initially planned to do it in PHP, with CodeIgniter to help speed things along. But, I was getting pretty tired of PHP stuff by that point, and reading the documentation for CodeIgniter did not inspire confidence; its biggest competitor, the Zend framework, wasn't much better. So, I ran through the Django tutorial in about 1-2 workdays, and in the course of one Django exercise, I was utterly blown away. Everything really was that easy. I had never seen such efficient application development; building a PHP application with any framework looked like Assembly by comparison.

Since then, I've gained considerable proficiency with Django, and decided I want to touch PHP as little as possible for the rest of my career. Unfortunately, I hit two major hurdles in that goal, the biggest being that the aforementioned oddball project, which is my greatest accomplishment as a developer and the holy grail of my portfolio, is classified. I can describe in vague terms some of what I did, and some of the technologies I used, but I can't say what it's for, why it works the way it does, or why the implemented technologies are so out-of-left-field bizarre. As I discovered in a job interview in August, private-sector employers really don't know how to handle a project like that in the interview process. Which brings me to problem number two: I recently transferred under a new director who, among other things, put the red light on any new Python work, because he doesn't understand it.

When I discovered the awesomeness of Django, I knew I'd be rebuilding my website with it, because it's too awesome not to. And I even started on it. But it's been my experience that personal projects are taken much less seriously than job-related stuff, so I doubled down on work projects, pushing for approval to shift my very big, very public primary project into a Django-based rebuild effort. Drupal wasn't meeting their needs very well, and a Django-based site could do a better job faster; after what I did with the secret project, it was an easy sell. But, since that's now been retroactively halted, and crappy Drupal sites will only lead my career toward more crappy Drupal sites, getting my personal website revamped and completed is now one of my highest-priority projects outside the stuff I'm getting paid to do.

When I first set out to rebuild my site, I planned on pretty much just doing a Django port of what I had already built, to start with. The data models were identical, and the conceptual structure was identical. At first. As I worked on it, however, I realized more and more that Django, while awesome and flexible, does things differently enough from my legacy PHP code that trying to replicate it exactly was going to take far more work than I anticipated. As I stewed on this thought, I decided to halt development on my current code branch, and start a new version. This time, though, I wouldn't commit my data models into the database, or even execute any code until I had planned out how all this would interact and come together. Given my usual impatience and "dive in head-first, sort out the details later" approach to starting a project, this was unusual for me, but it's proven to be a breath of fresh air. In making an executive decision for myself that nothing would officially "start" without thorough pre-planning, I've freed myself up to re-evaluate all the design decisions I've ever made, to see which ones still fit.

A lot of things have changed in the process. For starters, since I'm replacing my trusty old Gallery2 photo gallery, I've given a LOT of thought to how it will interact with the rest of the site. And, I decided to buck the design conventions of Django a bit; instead of using path structure to indicate content type (site.root/contenttype/category/document), I'm going to use path structure purely as organizational structure, separated from any of the various content types, and use file extension to determine content type (site.root/category/document.type). Because, well, I rather like knowing that .htm is a content page, while something that ends in a / is a directory.

Probably the biggest design decision, though, is to no longer have a separate "male" version of my site.

In 2007, a lot of things were happening. I was coming to terms with being transgendered and deciding to transition, I had decided to seriously pursue web development as a career, and I started taking some side classes to brush up on web standards and CSS. My website reflected this; it had always purely been a personal site, very separate from anything professional, and was a hodge-podge of things that weren't great to put in front of a professional audience, as I later discovered in a hard and embarassing lesson. In the process of trying to tailor my web presence to specific audiences without building redundant isolated websites, I implemented a feature in my site that I couldn't really discuss in detail if I wanted it to work: Content separation based on domain.

This feature matured over the years, and is a focal point of the most recent rebuild of the site. Basically, I have a whole bunch of domains pointing to the same site, and the code has the full list. When it matches the domain the list, it determines which version of the site to display, and which content is accessible. There are two basic boolean settings; gender (m or f) and furry (true or false). Through the combination of them, therefore, there are four different versions of the site that can be served.

The idea was that I could give different URLs to people who knew me as furry and not TG, furry and TG, or as a non-furry boy, and they would all see different flavors of the same site. Additionally, I created a pronouns system, so that anything referencing me by name or in the third-person would match whichever gender the site was displaying. This matured considerably in the most recent version of the site, to the point that I defined a custom HTML tag for it in the CMS's output processor.

For awhile, this worked perfectly. I got to have a fabulous purple layout to link to from my Second Life profile (the first substantial and noteworthy instance of people knowing me as Natasha), and I could show my mom and my web dev professor my website without them getting deep into my furry art collection.

As time has gone on, however, my presentation and needs have shifted considerably. I've long since ditched the male version of my psuedonym, and no one who's met me since 2008/2009 has even heard it. I don't present male anywhere outside my current job, and even if I did, I stopped showing potential employers my personal website sometime around 2009 (though, that was to keep them learning I'm TG, something I won't be hiding, going forward). I even came out to my mom, which means I can finally shift the domain she knows about (lupinia.net) to the "female" setting on the site. And I did, a couple months ago. And it felt GREAT.

In thinking about how to implement this on the new rebuild of my site, and the technical challenges involved, I started rethinking whether I even need it at all. And the answer is a resounding "no". It's still a good idea to have a furry/not-furry separation; it'll never be fully Google-proof, but that's fine, my concerns are regarding first impressions and perceived priorities. My past attempts to fully hide furry and other fandom interests from employers had nothing to do with those interests, I hid them solely because I was hiding being TG, and those things are all interconnected in search results. But the additional male/female separation is getting nixed in the new version. I have no need for it, and the sooner I purge my old psuedonym from top search engine rankings, the better; it's not as uncomfortable as my legal name, but I'd still like to put it behind me.
Howl At Me