creating this blog

without anything installed on my computer other than Chrome

I wanted to create this blog in a zero-infrastructure way, so I’m going to use Firebase which gets me out of the cloud infrastructure business and Google Cloud Shell which gets me out of the personal infrastructure business.

I set up Firebase for my project in a new folder inside my Cloud home:

mkdir /home/syed/ashrafulla-website && cd /home/syed/ashrafulla-website
firebase init

I selected yes on everything, including installing all the Firebase things, except when the installer asked if this was a single-page app.

Now to get started on Hugo. While still inside ashrafulla-website:

sudo apt-get install hugo
hugo new site blog
cd blog/
hugo server --port=8080

I set the port so I could use Cloud Shell’s preview. Hugo defaults to 1313, which is blocked by Cloud Shell.

I prefer the blocky, colorful themes to the minimal themes, so I’m going to go with forty instead of the developer-centric themes. Still inside blog, I did

git init
git submodule add themes/forty

I opened config.tomlat the /blog directory and added

theme = "forty"

I also made my first post as an empty post

hugo new blog/

and moved all these notes into that post. Running hugo server --port=8080 got nothing because it turns out forty needs a bunch of extra config.toml edits which are best setup by copying their example, which you already conveniently downloaded:

cp themes/forty/exampleSite/config.toml config.toml

At this point, I realized this was a website, not a blog, so I renamed the folder:

mv ~/ashrafulla-website/blog ~/ashrafulla-website/website

Now hugo server --port=8080 works and it’s time for Firebase,

hugo && firebase deploy

which failed trying to deploy a function. I only want to use the hosting, though, so

hugo && firebase deploy --only hosting

… and the app link doesn’t show anything :(.

I can see a /public folder so why isn’t Firebase showing anything? After thirty minutes, I see that /website/public also exists and then it clicks: I got the filesystem wrong. Hugo writes to a /public folder from its root. Firebase publises from a /public folder in its root. For this to work, Hugo and Firebase must use the same root. This means the website folder is bogus, so let’s get rid of it:

rm -rf website/public
mv website/* .
rm -rf website
git init
hugo && firebase deploy --only hosting

and now we have content but the CSS is bad.

Based on a Hugo forum post I added a netlify.toml file copying from a file linked in the post. But that was useless, and that’s probably because Firebase isn’t using Netlify.

I got another hint from Nicolas Marin’s blog which was to use the hugo -b option:

hugo -b "" && firebase deploy --only

and that worked. Why? -b sets the base URL for Hugo, and that seems to matter (at least for forty). This also means that the above is for pushing to production, and the development sandbox is

hugo -b "" && firebase serve -p 8080

Onward to presentation. I don’t like the banner, so I edited themes/forty/layouts/index.html to add an if-else that disabled the banner (just like the other stanzas). I also added enable_quicklinks to params.footer so that I could disable the copyright and quicklinks, which also required editing themes/forty/layouts/footer.html.

I also think posts is a better name than blog for my posts, so let’s rename and re-push

mv content/blog content/posts
hugo -b "" && firebase serve -p 8080

… and the folder blog still exists in /public. New lesson: development can either obliterate /public all the time (i.e. the “clean build”) or make sure to clean up deleted items from /public. I choose obliteration, but that also means I should ignore /public when using git. The new dev & prod commands are:

rm -rf public && hugo -b "" && firebase serve -p 8080
rm -rf public && hugo -b "" && firebase deploy --only hosting

I also now notice I should’ve just removed all the other Firebase stuff since it should go into separate folders if I want to play in that world. So, I deleted all the entries except for hosting from /firebase.json. I also added .firebaserc to .gitignore for portability.

Next, I want to point to, so I went to the Firebase project console. This link doesn’t work well if you are logged into multiple Google accounts because redirects to which is a problem if your second or third or fourth login is the organization holding the account. Change the number from 0 to the appropriate login, which you can find by looking at the URL for that account’s gMail page. It’s of a similar form:{YOUR NUMBER HERE}/#inbox.

I then typed and hit Connect and I got a 503 within a second. What? I think this is because I haven’t verified the domain fully. I verified it on transfer so now I’ll fix the MX records based on this page. I suspect this is related to my transition from HostGator-mediated to self-owned so I deleted everything except my MX records from the advanced DNS manager of and I’ll see what happens tomorrow. I also wonder if Firebase just doesn’t work in incognito mode. It could also be that HostGator required an A record and extra A records may be bad for Firebase based on this StackOverflow post.

Firebase came back to me and said that I hadn’t finished domain verification so I enabled Google Search Console for here at the recommendation of Firebase support. I’m now through to verification! Step 2 is a normal ownership check (adding a TXT DNS to your domain’s DNS manager). The .la domain is pretty slow with these updates, so I’ll do something else in the meantime.

That something else is fixing this website. I think forty is pretty bad for a website with a blog in it, because the blog isn’t made as a list. Let’s fix that. Hermit is ok for other people but not for me because there isn’t a geometry to it. Hamburg has some rectangles in nice places and it may be able to separate posts from projects, which is one goal of mine. Min night is very LaTeX-y so no. Massively is better than forty and seems more fun to click around, so maybe that’ll work? I also like the way Kube natively handles a blog for one part and projects (docs in their example) on another part. That’s a good enough factor to go with Kube. I might modify the colors (orange instead of green) but the idea is right.

rm -rf themes/forty
git submodule add themes/kube
cp themes/kube/exampleSite/config.toml .

and then I’m editing config.toml as before.

That didn’t work because kube needs Hugo 0.19 and Debian/Ubunto only have Hugo 0.18.1. So I’ll go to the backup of Hamburg. That didn’t work either because it uses a fileExists function that doesn’t exist in Hugo 0.18.1.

Another thing I just learned: vim in Google Cloud Shell does not allow backspace over end-of-line. Add set backspace=indent,eol,start to your .vimrc to get that crap out of here. Thanks to David Cain and Lemkurve in StackOverflow for that fix.

In the meantime, the DNS records updated within 30 minutes. Now it’s good to go! The certificate is apparently invalid for a few hours, so I’ll wait to check that SSL certification is a-ok.

The themes failing is too frustrating so I’m going to install Hugo from source:

sudo apt-get remove hugo
sudo dpkg -i hugo_0.53_Linux-64bit.deb

That worked, so now let me try kube again:

git rm -cached .gitmodules && git rm -cached themes/hamburg
rm .gitmodules
rm -rf themes/hamburg
git submodule add themes/kube

OK this is good. It’s time to personalize this to my liking. I’m going to throw out all the bottom part of index.html. I also threw the header out of index.html and am going to use buttons to point to posts, projects, and other links. Next, I’m going to move kube to use “projects” instead of docs in its code, and “posts” instead of “blog as well.

mv themes/kube/archetypes/ themes/kube/archetypes/
mv themes/kube/archetypes/ themes/kube/archetypes/
mv themes/kube/images/docs.png themes/kube/images/project.png
mv themes/kube/layouts/section/docs.html themes/kube/layouts/section/projects.html # I also renamed the title here.
mv themes/kube/layouts/blog themes/kube/layouts/posts
mv themes/kube/layouts/posts themes/kube/layouts/projects

Lastly, I fixed the footer, and learned that in the root directory, static/ merges with themes/kube/static so I don’t have to modify kube to get Facebook and Instagram icons into the website.

I disabled the projects button since there are no projects yet. I also added an optional change to the tab icon in case a static/img/common/favicon.png file exists.

That’s it, time to launch and iterate.

Published by using 1430 words.