Building This, My First Website
Published: Jan. 10, 2016, 1:33 a.m.
Now that I've built my own website, performing all of the development work myself from end-to-end, I'm surprised that I hadn't done it much sooner. At this point I could've gone with one of the ubiquitous plug-and-play solutions available now, but that's not my style. My initial intention was to consolidate my web presence, resume/CV, and what portfolio I have available for presentation. Now that the site is up on my own domain I intend to shift focus to data science oriented content.
I always prefer productivity through finesse, to work intelligently and efficiently, rather than just working in large quantities which I'd equate more to productivity through brute force. Part of attaining that finesse is settling on an optimal workflow, whatever the creative domain may be. In the case of web development/design it took me a while to determine, for my simple purposes, what standard problems or requisite tasks were faced, firstly, before zeroing in on researching the best approaches to these problems or tasks. Obviously any workflow is dynamic, but I've gotten to a point I'd wager the changes will be less rapid or dramatic than during the first two months learning my way around.
I first began programming my first year of grad school learning from my advisor's VBA in the lab, then taking a community college side class in VB.NET. Within a year I was writing non-trivial code for processing video-based eye-tracking raw data into publication-quality metrics (saccade/fixation parsing, blink, pupil size). By my last year I was using Psychtoolbox with MATLAB to control every aspect of my eye-tracking experiments from stimulus randomization and presentation to collection and scripted analysis of all manual and gaze responses.
Given these initial experiences, I'm accustomed to writing code from an IDE. I prefer debugging with visual breakpoints and configurable watches. I learn my way around a language and solve new problems more quickly when context help and autocompletion are available. (Learning R at NLSN was less painful once I discovered RStudio.) Aptana Studio was one of the programs I found that would support all of the languages and features I wanted to be able to use to build this site and any others, although not right out of the box.
I've vaguely understood for some time that web pages are written in HTML, styled with CSS, and any other client-side functionality was facilitated by JavaScript (JS). Also, any underlying data are stored in a database (DB) that is manipulated/controlled by a back-end language. Considering I had begun using Python for some data science work at NLSN I decided to build on that experience by learning the Django framework for back-end. Lastly, I'd always been excited to harness the historical narrative of a project that emerges by using version control - Git of course is the most popular and relevant. As I came to discover, Aptana is also suitable for editing shell scripts, although with my current config I can't test them. (I could probably clone my Openshift gears locally as Docker containers but haven't researched that.)
Basic front-end HTML/CSS/JS are easily usable (with some linting even) post-installation. Getting something like jQuery autocompletion takes more effort. PyDev comes installed as well but to receive automatic updates I re-installed it independently. Similarly, I have coopted Eclipse plugins for Emmet, Django templates, SQL Explorer and Gulp control into my Aptana installation, although with mixed success (I suspect using Aptana as an Eclipse plugin rather than a stand-alone could mitigate some small failures). Aptana itself is made with Ruby, which I also had to install to use Redhat's Openshift command line tools and to use Compass to compile SCSS. (I've had to consciously override my conditioned aversion to entropy many times in this process.)
By the time I'd been through a tutorial or two and had pilfered enough codepens for my own base design I had started to get a sense of how it all really works implementationally. I had a better sense of the archetypal problems and the varied approaches to solving them. Wanting to see how far I could go for free I settled on an Openshift account for deploying, which revealed a blindspot I had for handling my staticfiles. Django's included development server was easy to execute from Aptana's Run/Debug commands (after configuring my projects to match with their venv interpreters) but bypassed the difficulty of handling staticfiles in a production setting. Beneficially, Openshift comes with simple cron and action_hook functionality - so pinging my sitemap to search engines and syncing local DB changes to production is trivially easy.
In the end I came up with a base HTML template for most of the site, a few more for individual posts, a post list, an about page, and basic HTTP error codes. Openshift gears only have 1 gig disk space so I started out with a lightweight SQLite DB. I write posts as HTML in the DB locally with any ad-hoc styling inline. URLs reference posts by a random 6-char alphanumeric hash and a title slug. The slug is generated on the fly by the server and never copied to the DB; I decided they reside better in browser histories and search engine results (change anything about the slug but the hash and the server will redirect you to the post with the corrected slug). The random hash also functions well as a unique identifier to link my posts to their comments on Disqus.
Wanting to get a handle on D3 I used it with JS to generate my background animation. Despite some effort it is a massive resource hog, although I have yet to load anything D3 with animation (whether on bl.ocks or elsewhere online) that didn't immediately max out one of my CPU cores. For that reason I included the button on the top right to stop or restart the animation, but I wanted that mechanism to persist between visits which lead to dropping a cookie to track the animation status, which I also handled with JS. A few minor button-click actions were handled with jQuery, otherwise all JS is vanilla or D3 syntax. I definitely found JS the least straightforward to work with; writing and linting code in Aptana, Gulp watching, bundling, and uglifying files on save, reloading the page in my browser, and finally checking/manipulating the code in the developer tools to see what's wrong.
A middleware parses client user agent strings and serve one of two stylesheets; one for the classic desktop experience and another for touch-capable devices. Icons appear in the bottom left of the footer depicting the results of user agent (device, OS, browser) detection. I require Pure.css in my Compass configuration to make the layout responsive. Compass/SCSS was most valuable refactoring the codepen I used for my sliding social nav section; being able to use mixins for all of the different browser prefixes actually made it readable. Realizing more generally the importance of minimizing the number and size of requests from my server I installed Node.js to run Gulp locally, which I used to watch my static asset folders, control Compass for compiling my SCSS into a single unified stylesheet and to similarly concatenate and minify/uglify my JS. Lastly, style-wise, I made post content the only selectable content on the page (hit CTRL+A and note how only important stuff gets highlighted), and added a print style that similarly excludes content outside the post and also appends a QR code with the page URL to the bottom (do a print preview on this page to see it.)
Knowing what I do now and considering the lightweight nature of the content the site hosts and how it handles virtually no user input, I've clearly over-engineered it. If I were to do it again and never build another thing, I probably would've gone with a static site framework like Jekyll on my free GitHub page. Looking back now it seems impossible that a simple site could have taken a few months but that's overlooking all of the hours of research and troubleshooting it takes to get things to work in the absence of experience. Moreover anytime something doesn't work - every time I followed the steps in a tutorial and got an error that author didn't and was forced to wrestle with issues that they didn't, almost always I end up searching online and going through a few more clicks to narrow results to those within the past year because stackoverflow results from 3-7 years ago are either irrelevant or worse, misleading. It is true that unlike audio engineers who work with the semi-objective criteria of how things sound and tend to guard their knowledge as trade secrets, programmers/developers seem eager to tell anyone who will load their page how they work - however, it seems with the size and level of participation of that audience it makes for an excessively dynamic body of knowledge that's still hard to pin down, still elusive in its amorphousness.
In conclusion - I write HTML/SCSS/JS/Python in Aptana, Gulp watch runs in the background to compile my SCSS and unify my front-end assets, I run/debug the Django dev server from Aptana to check the site, and when satisfied I Git push my code to my Openshift deployment from Aptana as well. I'll use Vim and other command-line tools via Putty on the server-side once deployed, but for the most part stay exclusively in my IDE. Had I easily found a way to run code from within Atom editor I may have used it instead of Aptana - I do miss the ability from RStudio to simply select some code and CTRL+ENTER to run it in the interpreter, and I do think the context help leaves a bit to be desired. If I am to continue learning I imagine the next area to spend some time is on a JS framework with a virtual DOM to couple with D3 for quick data visualizations.
I'm happy to answer specific questions about how I did anything here, and eager to accept any criticism about the design or features.