My new recipe website is definitely falling into the "labor of love" category. Jekyll, after a few small hiccups, has been extremely easy to navigate through and does a lot to help me minimize the code I need to rewrite. As of this writing, I've got about 400 lines of code - mostly html and css with a few Ruby directives and filters mixed in - and about 80 lines of configuration in place for a fully functioning website. I expect, that, given my current strategy of adding recipes and, eventually adding a cooking lessons section to the site, I'll have about 2000 total lines of code and configuration in place for my website. In addition, Jekyll's ease of use has even allowed me to do a full recipe page redesign and make the page responsive to different sized devices.
Of course, anyone familiar with software engineering will point out that this is just a simple static site. That's true, but getting to simple is often the most difficult people take to solve a problem. Simple solutions are often deceptive, because, in hind sight, they seem so obvious, even though the effort to get there could take a lot of effort.
In my case, it literally took years. I started with the idea of website and thought I'd need to create a CRUD (Create, Read, Update, Delete) app with a database that's so ubiquitous across the web. And of course, like a lot of developers, I didn't bother to really see if something existed before starting. This was partly by design - to keep my programming skills fresh - but partly because I didn't do any upfront investigation.
Eventually, I did look for an existing tool, because I wasn't getting anywhere close to generating a recipe site with my then current course of action. Once I had an existing tool, I spent time cutting out the cruft that I didn't need for my site and upgrading old portions of the code that was present. I was still no closer to a recipe website though.
Then I decided to create a static site, but wanted to create a recipe generator, so, as I mentioned in my last post, I wouldn't wind up with a lot of duplicated code. Eventually, through a tip of one of my friends, I finally stumbled across Jekyll. And now, in about 2 weeks, I've been able to crank out more recipes, with a much better design, than I had in the previous 2 years. It seems so obvious - why didn't I just look for a static site generator in the first place? But, it took a lot of design-based suffering to come to this conclusion. I'm grateful for all of the tools and techniques I learned about on my journey, and some are even helpful in my job. Even though I knew about the difficulty of creating a simple solution before undertaking this project, I'm happy that I was able to prove the theorem to myself by going through all of the iterations to get to where I'm at now.
Oh, and, by the way, the new site is now here.
Thursday, March 29, 2018
Tuesday, March 20, 2018
Static Cling
While spending time generating the basics of my recipe site (which will likely move soon - I'll update the address once the move is complete), I've been on the hunt for software engineering tools that will make its maintenance much easier. As the site stands now, it's fashioned in a 1997 type of HTML and CSS only site that requires a lot of duplication. For every recipe I create, I need to copy an old page, make the necessary updates to the page for the new recipe, proofread it to ensure I don't have any typos on the page, deploy it and view it to ensure it renders correctly to the user.
This is really error prone, especially with 52 recipes. It also makes updates to the site extremely difficult, because if I want to, for example, switch the ingredients section with the instructions section, I have to make changes to 52 pages.
As any competent software engineer knows, we don't want to do this. We want to follow the DRY principle (Don't Repeat Yourself). The layout for the recipe pages is exactly the same. The only thing that differs is the content. So, if I can create a template for the page and render the content, I give myself a lot of flexibility and freedom from maintenance nightmares. Turns out it's 2018, and this has been the core of web programming for the better part of a decade and a half.
My preferred requirement is to keep the site static. That means that once a user makes an initial call to the website, there are essentially no further updates required. There's no data storage on the backend that the user needs to interact with, no middleware to call, no philosophies for caching data for speed, since the content has already been generated and isn't going to change. By and large, a static website is not what the vast majority of the websites in the world are. If you're running a travel website, for example, you'll need to call back to other systems to log users in, search flights and hotels, remember their preferences, and process their payments.
However, with a recipe website, where the content changes infrequently, we don't need to log users in (unless I begin offering premium content or sensitive content), and we don't need to process payments, a static website is preferable. It's less maintenance, and, since it has fewer moving parts, more secure, both from my perspective and the user's.
So, then - a static website with some seemingly dynamic content. Sounds like a job for Javascript! I won't go into the details of how I selected a framework, but I eventually selected Vue.js for the job. It's got a clean interface and would be able to help me follow the DRY principle. Except that it also adds a lot of overhead to the site. I'd need to install something called vue-router to make sure that I could create recipe content on the fly. In order to use vue-router in a manner that makes it easy to read and write, I'd need to install a Javascript bundler called webpack. In order to use webpack, I need npm. In order to make sure the Node version associated with npm was up-to-date, I'd need nvm.
So, then - a static website with some seemingly dynamic content. Well, there's a much cleaner alternative that I'd only heard in passing - a static site generator. The industry standard seems to be Jekyll. It took me a little while to get into the groove, but the documentation is pretty solid and there's a ton of additional help online, which is great. Unlike Javascript, which injects content into a template when a user requests a particular recipe, the site generator uses the template before I even post the content to create a bunch of seemingly duplicate pages. From the user's standpoint, it looks like I am just creating tedious HTML and CSS pages, but from my standpoint, it's all done with a little code and is as easy, if not easier to maintain, than a Javascript based solution.
This is really error prone, especially with 52 recipes. It also makes updates to the site extremely difficult, because if I want to, for example, switch the ingredients section with the instructions section, I have to make changes to 52 pages.
As any competent software engineer knows, we don't want to do this. We want to follow the DRY principle (Don't Repeat Yourself). The layout for the recipe pages is exactly the same. The only thing that differs is the content. So, if I can create a template for the page and render the content, I give myself a lot of flexibility and freedom from maintenance nightmares. Turns out it's 2018, and this has been the core of web programming for the better part of a decade and a half.
My preferred requirement is to keep the site static. That means that once a user makes an initial call to the website, there are essentially no further updates required. There's no data storage on the backend that the user needs to interact with, no middleware to call, no philosophies for caching data for speed, since the content has already been generated and isn't going to change. By and large, a static website is not what the vast majority of the websites in the world are. If you're running a travel website, for example, you'll need to call back to other systems to log users in, search flights and hotels, remember their preferences, and process their payments.
However, with a recipe website, where the content changes infrequently, we don't need to log users in (unless I begin offering premium content or sensitive content), and we don't need to process payments, a static website is preferable. It's less maintenance, and, since it has fewer moving parts, more secure, both from my perspective and the user's.
So, then - a static website with some seemingly dynamic content. Sounds like a job for Javascript! I won't go into the details of how I selected a framework, but I eventually selected Vue.js for the job. It's got a clean interface and would be able to help me follow the DRY principle. Except that it also adds a lot of overhead to the site. I'd need to install something called vue-router to make sure that I could create recipe content on the fly. In order to use vue-router in a manner that makes it easy to read and write, I'd need to install a Javascript bundler called webpack. In order to use webpack, I need npm. In order to make sure the Node version associated with npm was up-to-date, I'd need nvm.
So, then - a static website with some seemingly dynamic content. Well, there's a much cleaner alternative that I'd only heard in passing - a static site generator. The industry standard seems to be Jekyll. It took me a little while to get into the groove, but the documentation is pretty solid and there's a ton of additional help online, which is great. Unlike Javascript, which injects content into a template when a user requests a particular recipe, the site generator uses the template before I even post the content to create a bunch of seemingly duplicate pages. From the user's standpoint, it looks like I am just creating tedious HTML and CSS pages, but from my standpoint, it's all done with a little code and is as easy, if not easier to maintain, than a Javascript based solution.
Wednesday, March 7, 2018
Random Meta Ramblings on Writing
As we're just wrapping up awards season with the Oscars, and it always seems that there's some movie (or TV series) that scores big in peeling back the layer of the entertainment industry and giving an insider's view to the masses, I thought I'd take the opportunity to write about the act of writing.
Of all my hobbies, writing in one fashion or another, is probably the one I've practiced the most. When I was younger I wrote a few stories, but abandoned the practice due to a lack of self-confidence and the realization that I was going to have write some real crap and subject myself to honest criticism if I wanted to grow in that area.
Instead, I've channeled a lot of my writing desires into other areas of my life - emails, status reports, documentation, and - off and on - blogging.
Blogging, or consistently creating anything on a fixed schedule, has proven to be difficult. Some days, the words flow easily, even when I think the topic is sparse. My series of posts on beginning guitar is a great example. I thought it was going to be one post with some general musings, and I realized that could actually be a series of about 10 posts (which I haven't completed, but that's a different discussion).
Other days, I feel like I've got a really meaty topic, like the discoveries I made while starting my recipe site, and realize I'm struggling to compose my thoughts.
Still, other days, I have no topics nor any words to describe my non-topics and am left simply staring at a blank screen trying to come up with something.
But that's why I precisely like having a deadline of 1 blog post per week. It forces me to write. I know professional writers are much more intense. I've read they often write 1,000 or 3,000 or some other arbitrarily high number of words per day, even if it's complete nonsense, in order to stave off writer's block. This is my own version of that. Of course I'm doing it on a 'public' stage. My navel gazing is out there for everyone to see if they stop by, but it's a blog, so quality is expected to be a range anyway.
However, the fact that this is a blog leads to some interesting dilemmas. If I never told anyone about this blog, chances of anyone finding it and reading it are low, even if it's public facing. In that case, this is essentially just a diary. I could write about all of my potential doubts, shortcomings, hopes, dreams, and character flaws and no one would really be none the wiser. Of course, if someone does stumble across it, then my vulnerabilities are immediately on display and open for comment.
Luckily, all commentary on the internet is thoughtful and sensitive, so I don't need to worry about some troll excoriating me for indicating that I have liberal leanings or bashing me as a know-it-all libtard for using the word 'excoriating.'
But all internet sensitivity aside, that's actually one of the beauties of the medium. I've read articles indicating that we're becoming a lot more desensitized to others' points of view because we now have a gigantic universe where we can be anonymous assholes. From my vantage point, I think people have always been this type of asshole - genocide isn't a new phenomenon, and many people are complete jerks when they're alone in their cars because they're provided with a pseudo-anonymity. The internet has just unmasked these tendencies in us.
And, as stressful as it can be, it also provides a certain liberation - any random passerby can scribble "UR Blog Sux" in the comments section here, and regardless of how flawless my writing or my logic will continue to double down on offending me. Because I know there's somebody out there willing to hate me simply because I exist, and I can do nothing to change their mind, I also have the freedom to write random, rambling posts and not have to worry about what the internet is going to think of me.
Of all my hobbies, writing in one fashion or another, is probably the one I've practiced the most. When I was younger I wrote a few stories, but abandoned the practice due to a lack of self-confidence and the realization that I was going to have write some real crap and subject myself to honest criticism if I wanted to grow in that area.
Instead, I've channeled a lot of my writing desires into other areas of my life - emails, status reports, documentation, and - off and on - blogging.
Blogging, or consistently creating anything on a fixed schedule, has proven to be difficult. Some days, the words flow easily, even when I think the topic is sparse. My series of posts on beginning guitar is a great example. I thought it was going to be one post with some general musings, and I realized that could actually be a series of about 10 posts (which I haven't completed, but that's a different discussion).
Other days, I feel like I've got a really meaty topic, like the discoveries I made while starting my recipe site, and realize I'm struggling to compose my thoughts.
Still, other days, I have no topics nor any words to describe my non-topics and am left simply staring at a blank screen trying to come up with something.
But that's why I precisely like having a deadline of 1 blog post per week. It forces me to write. I know professional writers are much more intense. I've read they often write 1,000 or 3,000 or some other arbitrarily high number of words per day, even if it's complete nonsense, in order to stave off writer's block. This is my own version of that. Of course I'm doing it on a 'public' stage. My navel gazing is out there for everyone to see if they stop by, but it's a blog, so quality is expected to be a range anyway.
However, the fact that this is a blog leads to some interesting dilemmas. If I never told anyone about this blog, chances of anyone finding it and reading it are low, even if it's public facing. In that case, this is essentially just a diary. I could write about all of my potential doubts, shortcomings, hopes, dreams, and character flaws and no one would really be none the wiser. Of course, if someone does stumble across it, then my vulnerabilities are immediately on display and open for comment.
Luckily, all commentary on the internet is thoughtful and sensitive, so I don't need to worry about some troll excoriating me for indicating that I have liberal leanings or bashing me as a know-it-all libtard for using the word 'excoriating.'
But all internet sensitivity aside, that's actually one of the beauties of the medium. I've read articles indicating that we're becoming a lot more desensitized to others' points of view because we now have a gigantic universe where we can be anonymous assholes. From my vantage point, I think people have always been this type of asshole - genocide isn't a new phenomenon, and many people are complete jerks when they're alone in their cars because they're provided with a pseudo-anonymity. The internet has just unmasked these tendencies in us.
And, as stressful as it can be, it also provides a certain liberation - any random passerby can scribble "UR Blog Sux" in the comments section here, and regardless of how flawless my writing or my logic will continue to double down on offending me. Because I know there's somebody out there willing to hate me simply because I exist, and I can do nothing to change their mind, I also have the freedom to write random, rambling posts and not have to worry about what the internet is going to think of me.
Subscribe to:
Posts (Atom)