I will now continue to deviate from the pre-ordained path of preset web portfolioing and offloading of assets to a lego block stacker robots by developing my own website, proper. I think taking advantage of the significant level of control offered by the fast-and-loose framework of Jekyll/GH-Pages in making my web log has allowed me to develop some good working knowledges on the matter of front end web development. However, there’s always been a safety belt strapping me in to my learner chair. Jekyll does much menial but important construction, based on the directories, includes and markdowns you feed to it, which takes you from an intelligently compartmentalized set of html molds to a fully socketed site. Then of course there’s the extensive documentation and community to rely on for aid, along with further helpful features like CSS being processed from/by Sass.
It is easy enough to make a dot html file, a dot css and dot js files, but what more is there to this process? You can open a html file in browser to check it out, relative links in the head working, but shouldn’t it be loading onto a server - if not locally now to have a look, then in deployed state? Firstly, I am looking to move away from Github for this project, and using Heroku instead of using GH-Pages. It seems to be a service more intended for use as a web-app host, but there are ways to use it to provide a simple static site. Amongst the supported languages are things like Node.js and PHP, the former (with which I am a little bit familiar) can quite easily be made to shoot out a webpage locally and the latter requires a single line of code in a PHP file as documented in many guides that are specific to website-on-heroku handholding.
Rather than simply viewing html, we want things to resolve as they would on the remote server Heroku is kindly offering. To do this via PHP we need to install PHP, which is surprising. One way to collect it is as part of the XAMPP package, which assembles a very capable and cross-platform ecosystem of tools to develop PHP applications, including the foundational Apache, to provide hosting function. This seems like overkill, and I believe it definitely is, but either way we can now access an up to date PHP installation inside the XAMPP install, and set an environment variable to use it directly in command line.
Now this is interesting. It seems I have taken a somewhat scenic route, because Heroku themselves are offering “Heroku CLI” which purports to allow running such applications locally itself. Let me see. Installed composer. Now this is interesting. I really should have just followed this PHP guide on heroku website, which takes you through the process of understanding/mirroring the way these applications will work on their side of things. Notably, a composer.json which will notify of dependencies in what appears to be a similar way to how a gemfile/bundler works with Jekyll/GH.
This is so cool. I went ahead and tried out their sample application, which is very slick and demonstrative. Maybe taking a further look at this sample will help inform some choices in building the site or at least further experimenting. Since my only requirement is that Heroku (and thereby PHP) spit out a static HTML to the user, there’s not much need for any functionality potentiated here (that is databases, dynamic pages stitching themselves together with scripting) and it is simply only present as a buffer in going this route of hosting a website using free computer clouds - but whatever, it’s half an hour too late to turn back.
While in the future I will enjoy to do more with the webpage, for now I do not even want a portfolio present - rather a simple bespoke business card linktree-alike. What more is there to say? I’m not sure. With regards to function, there really is none whatsoever. Beyond a bundle of hyperlinks I suppose it needs to be responsive, looking nice on mobile as well as desktop. That can easily be achieved with HTML + CSS however. Yes, there is literally nothing to say here. It is a simple job for now - perhaps in a future development there will be more interesting things to accomplish. For now this is straightforward, perhaps I will like a dark mode.
The website envisioned is simple, but mock-ups have been rasterized for non-strict referential use. It looks quite nice, there are some giant texts, and the way the containers will work might be interesting as there is some potential vertical overlap. I need to remember to set a nice font, and I also need to provision for things to be drawn vertically on a phone - this design is sucking up most of the screen real estate. There is not much to it… right now I am without my usual prodigious vision.
Here’s one I prepared earlier. I spent the day fiddling around with CSS - still finicky for me even after a lot of time spent working with it in more complex setup. This time was different of course: I want a full viewport utilization, rather than a traditional scrolling webpage. Something unusual I had to do to get this to work was setting the height of the root “html” tag, as well as body tag, after seeing that was one of the main issue causing elements with the useful dev tool element inspection device installed onto chrome and chromium browser.
Outside of this, being unwilling to deviate much at all from my mock-up, I had to incorporate a custom font. Having not cast a discerning eye over the font name while mocking-up the mock-up, I unfortunately never saw that I had selected a font I had collected from the Adobe font library, where I would have hoped it was a freely available and open license one. Either way I have a way to go before I can renege on my sweet Adobe CC deal, so using their very cool web-project licensing and stylesheet reference is an option in the short term.
With the basic site set-up, I now move toward deploying it to Heroku with domain. This has been very simple, while not using composer in any real way. After creating a near-blank composer.json and setting up the git remote, I push. Then set up DNS records and so on for domain. Very simple. One unfortunate hang-up is that Heroku, I guess by nature of its cloud-computing systema, will not play at all with A-records that need a nice stable IP address - this means no root domain can be used. Instead, CNAME and redirects mean everyone can and will get to the site via the WWW (world wide web) subdomain, which is whatever. That’s it. Very light work all around.
This has effectively been a process of porting a digital business card, from a proprietary Adobe solution for plebeians to a full fledged php environment power-user setup. Next up will be polishing the site as is, and adding further functionality via the interesting potentials PHP provides. I have absconded my dark-mode button implementation for now, which has flown over my head as I constructed my barebones web-shack. Skipping over logging of thoughts for any immediate neatening, I will describe the next larger update once I am ready to roll. That’s it.