Building the blog—the tech side
Putting functionality first
Update: to not much surprise, I've pivoted again. Check out my more recent posts.
Going into this project, I wanted to build a long-lasting product which I could rely on for the coming weeks, semesters, and on. It had to be adaptable to my varied interests, simple and effective in its user interface, and, above all, something which I and all site visitors thoroughly enjoy using.
Lastly, this project presented a great learning opportunity at a time that I knew I could get the most out of it: having finished my first year of college, this was a time to take on a rigorous side project, experiment with new technologies, and better understand full-stack application development.
With that preface, we can get into the decisions I made through drafting, developing, and implementing this site.
Deciding on languages and frameworks
I was a bit a torn between using Rails or not, but it proved an advantageous decision: Rails aligns itself beautifully with post-based applications. Specifically, the programmer can generate a simple blog application in quite literally three bash commands. From there, the application can be hosted locally and rapidly edited, viewed, and refined. All this is to say, Rails is a very product driven and product forward framework, thereby making it easy to quantify progress at every step through development.
The use of Bootstrap was a far easier decision--paired with Rails's ability to quickly generate the application, Bootstrap works to quickly generate elegant views with mobile-first and responsive development at its basis. Further, the recently released Bootstrap 4 is a lighter weight and more direct iteration of previous versions, making rapid development even easier.Having decided on how to build, it was now a question of what, exactly, to build at all.
Deciding on features and functionality
Unlike the process of framework and language decisions, feature selection is a far more fluid and dynamic one. Moreover, pivoting regarding one feature often means at least tweaking the implementation of every other one. As more and more features come to fruition, reality increasingly deviates from the developer's initial vision, thereby necessitating a shift in direction.
When struggling to find said direction, I always loop back to the product at hand's target use cases. In context of this site:
I should be able to...
- Easily add content without changing application code
- Pitch myself, my projects, and my ambitions
- Write without limitations on how I can display information
A visitor should be able to...
- Access desired content in as few clicks as possible
- Not be distracted by unnecessary features or excessive navigation
- Be interested in exploring the site as they use it
By this set of cases, I was able to decide on some features and decide against others, thereby solidifying the model and controller sides of my application. For example, tags and timestamps on articles allow visitors to easily find content and allows me to better organize my writing. However adding built-in components to the database side beyond an image, a title, and content were more than I needed in order to effectively get my points across and would serve to interfere with the writing process.
Last, but very much not least, I had to implement the view to best translate the work I put into the back end into the front end.
Deciding on user-facing implementation
On the blog side I wanted fully functional input and output: a set number of styling commands (a sort of hybrid of the markdown and HTML languages). Further, a lot of the blog input is tagged with:
Which allows for fully customizable features within blog posts by permitting the use of HTML. While this proves dangerous within a traditional, more social platform, i this case there are set administrators and thus there is no fear of a malicious attack on that front.
Similarly, the use of Prism allows for stylized code between pre and code tags (as I used in the code block above). This, and many other built in components, are pivotal in creating highly functional, in-depth, and interactive posts.
In order to actually identify what should be code, or a subheader, or a line, or some other component, I used a simple case based function for displaying content of the post to the user:
Parsing my input
First I split up the post's text line by line and applied the cases to each separated line of content.
If you are unfamiliar with Ruby, you can see it has a wonderful set of functions which allow it to read arguably closer to English than any comparable programming language. While this raises issues with efficiency, it undeniably yields short, clean code.
On the inside of this for each loop lies the cases:
<%= comp %>
<%= comp.html_safe %>
Essentially, the algorithm looks for lines starting with certain tags denoted by [...], and displays the component with tag accordingly. This allows for easily creating spaces, formatted text, code snippets, images, dashes, and other components within the post itself without writing pure HTML (although I also have that option when needed).
Implementing the rest of the site
The rest of the site was far more straightforward in development. While each page has a unique focus and a corresponding unique display, they are all bounded by a cohesive styling framework.
Thus, upon putting a lot of thought into organizing and optimizing information on this site, the product is, in my opinion, fittingly clean and informative. This post, in itself, serves as partial validation of my aims. All this being said, the true worth of the product can only be gauged via sustained use by a dynamic user base. To be continued...
The Ethics and Macroeconomics of Automation
Finding purpose, work, and flow with our machine friends