This is a pretty good guide to building a blog using ReactJS and Sanity. That said, I did run into a number of issues while trying to follow it. This post is about the issues I ran into and the solutions for them.

---

When I got to the part where it says to run sanity init, I got errors in Visual Studio Code saying the PowerShell script is not digitally signed, so it's not allowed to run. The fix for this was to run: Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Bypass -Force in the VS Code terminal.

---

Then I got the error Error: self signed certificate in certificate chain. Looked it up online and found that it seems to be caused by my VPN connection. I disconnected from my work VPN and it did resolve my issue.

---

I got all the way to the part of the guide where I was Building the page for all the blog posts. After following the instructions and copying the provided code into src/components/AllPosts.js , I kept running into a post.mainImage undefined error. It turns out, the provided code is expecting all posts I created in Sanity to have a main image. I had one for my first post, but didn't add one to my second post.

The fix for the issue above was to replace <img src={post.mainImage.asset.url} alt="" /> with {typeof post.mainImage !== 'undefined' && <img src={post.mainImage.asset.url} alt="" />}.

What that new line of code does, is check if post.mainImage is NOT undefined, and if so, render the img tag. If it was undefined, as is the case with my second post, it wouldn't render the tag, thereby avoiding the error.

---

After finishing the guide, I needed to figure out how to deploy the React app to Netlify. Posts online say it is as easy as dropping a Build folder into Netlify. However, there's no Build folder in sight in VS Code. Turns out, I had to run npm run build to generate the Build folder and its contents. After that, it was as easy as dropping the folder into the Netlify's deploy folder. You can find the live site on here.

Initially the site would load, but the blog posts wouldn't show up. The fix for this was to add the site url, https://laughing-lamarr-50f7df.netlify.app, as a CORS Origins entry in my Sanity account's API settings.

Tags: #ReactJS #Blog #Bookmarks

Discuss... or leave a comment below.

In the past, I used Wyam to generate the website files for my software development blog. I chose Wyam because it is a .NET static site generator and I am a .NET software developer. With Wyam, I got to play around with Razor and C# while working on my blog. And I learned a lot about HTML, CSS, JavaScript and even Markdown. But now it's time to move on.

I've already made some changes at the start of this year. Namely, I decided to start publishing new software development posts onto my journal. As I mentioned in this post, I didn't really like how it turned out. I didn't like how the content was getting mixed in with other totally unrelated posts. So, after only a few months with that setup, I decided to move my dev blog out into a stand alone blog once more.

Instead of going back to a static site generator, I decided to spin up a new blog with write.as. There are two main reasons for this.

Ease of Publishing

First, I loved the ease of publishing new content with write.as. Their Markdown editor is superb. The writing experience is distraction free. And all I really need to write new posts is a web browser. Yes, even the web browser on my mobile phone will work. I can't exactly say the same thing about writing new posts with a static site generator.

Keeping it Simple

Second, I wanted to keep things simple by keeping most of my sites under one roof.

I've realized that it was hard to maintain websites that were on different platforms. To post to my dev blog, I had to do it with Wyam. To post to my microblog, I had to do it at micro.blog. To post to my journal or music blog or photo blog, I had to use write.as.

Keeping my sites under one roof, using the same method of publishing, would make things a lot simpler. At least, that's the idea. So, I'm trying that out.

Whether this new setup will work or not, only time will tell. But the one great thing about owning your domain and personal websites, is that you can do whatever you want. You want to experiment with a different way of publishing, go ahead. You want to try a new theme, give it a go. You want to write longer posts, or shorter posts, it's all up to you. Your websites, your rules.

Anyway, that's all for tonight. I just wanted to publish a formal migrated to write.as post for this blog. I feel better now with that out of the way. So, I'll catch y'all in the next post. Thanks for reading.

Tags: #SiteUpdates #Blog

Discuss... or leave a comment below.

Update 4/21/2021: I've decided to keep my software development posts separate from my personal posts. I've tried having them both on my journal and I didn't really like how they turned out. So, I've created this new dev blog on write.as to house my posts on software development.

I started this dev blog back in December 2018. It initially started out as a Jekyll Now blog hosted on Github Pages. After about two weeks I made the switch to a Wyam powered blog. And it's been that way since then.

This was my first real website. The first one that I bought a domain name for. Fast forward to 2021 and I now have 4 websites. There's this dev blog, my personal journal, my music blog and a photo-blog. At one point in 2020, I also had a micro-blog that has since been discontinued. So, in total, I had five websites.

After my second digital declutter, I've come to the realization that five websites is one too many. I felt like I couldn't keep maintaining all five at once. Since then, I've been thinking about reducing the number of websites I maintained.

I've thought about combining this dev blog with my personal journal a few times in the past. What was holding me back every time, was that I wasn't sure it was a good idea to have one site that contained both professional and personal content. However, I was also keenly aware of the creeping exhaustion of maintaining multiple websites at once.

There's also the fact that to publish content on this dev blog, I needed to do it on a machine that had .NET Core, Git and Visual Studio Code installed on it. On the other hand, to publish content on my personal journal, all I needed was a web browser.

So, in the interest of simplifying things for 2021, I've decided to stop publishing software development posts on this blog. I'm keeping the existing content on this blog for now. But new software development posts will now be published on my personal journal.

I'm not sure if there are a lot of people who read this dev blog. If you are one of them though, I would like to invite you to check out my personal journal. And if that's something you don't want to do, that's okay too. In any case, thank you for reading this post and I hope you have a nice day!

Tags: #SiteUpdates #Blog

Discuss... or leave a comment below.

Adding a time to read estimate was something I've always wanted to do when I created my blog. I like the idea of giving readers an idea of how much time they would spend/lose if they read my posts. This is so they can make better use of their time. If they have enough time, they can read the post, if not, they can bookmark it or add to their reading list.

A note on customizing a Wyam blog

One of the confusing things for me when I first started using Wyam to create my blog is how to customize it. After running the command wyam new -r Blog, you will end up with an about.md markdown file, an input folder with a first-post.md markdown file in it and that's it. Well there is a config.wyam file but that's not what you use to customize the whole site. There are no .html, .cshtml or .css files that you can modify to customize your site. Turns out to customize the site, you will have to add new files to the input folder and add your modifications to those files. The next time Wyam builds your site, Wyam will pick up those files and process them.

What confused me was the use of the word “theme”. When I read theme, I think about the design of the site, mainly modifying the CSS files to customize how it looks. For Wyam though, theme means everything about how the site looks, which includes the design and layout of the content on the site. So say if you wanted to modify how the footer looks, like add content on it, you would have to create a _Footer.cshtml file in the input folder and add your customizations to that file. The Wyam documentation actually talks about that here and on the Overriding Theme Files section here.

Now that we've got that out of the way. Here are the steps I took for adding a time to read estimate for posts on this blog.

Step 1: Add a _PostHeader.cshtml file to the input folder

I wanted to add the time to read estimate on the top of a blog post, around where the Title and Published date shows up. So the file to modify is the _PostHeader.cshtml file. To do this, I created an empty _PostHeader.cshtml file in the input folder and copied the contents from this file. Note that the file is from the CleanBlog theme, which is the theme I'm using for this blog.

At this point you can do a Wyam build to make sure it works and that nothing is broken. Your site will not look any different because we have not made any modifications, we basically just copied the default code for the _PostHeader.cshtml file. When you don't have this file in your input folder, Wyam will actually build and process this file behind the scenes when building your site. When you have the same file in the input folder, Wyam knows to take that file and its content as the main source for processing the _PostHeader.cshtml file.

Step 2: Add code to calculate “time to read” in the _PostHeader.cshtml file

To calculate the time to read value for a blog post, we can use Razor, which is one of the reasons why I like using Wyam. At the top of the file I added the following lines of code:

char[] delimiters = new char[] {' ', '\r', '\n' };
var numberOfWords = Document.Content.Split(delimiters, StringSplitOptions.RemoveEmptyEntries).Length;
var TimeToRead = Math.Ceiling(numberOfWords / 200f).ToString();

What we're doing here is getting the content of the current blog post, then splitting it into an array to get how many words are in the blog post. I actually got that code from a StackOverflow answer. Then we divide the number of words by 200 to get a conservative time to read estimate value in minutes, which is then converted to a string.

To display the time to read estimate, I modified the line of code that displays the date the post was published and I ended up with this:

<div class="meta">
    @if (Published != default(DateTime))
    {
        <text>@Published.ToLongDateString(Context) &rarr; @TimeToRead min read</text>
    }
</div>

I basically just appended an arrow that points to the time to read estimate, on the same line that shows date the post was published.

At this point, you can do a Wyam build and preview your site. All your blog posts should now have a time to read estimate at the top, just below the title.

To view the whole content of the _PostHeader.cshtml file for this blog, you can check here.

#Wyam #Blog

Discuss... or leave a comment below.

As I sat down to write the post on how I added a basic Tags page to my previously Jekyll Now powered blog/website, I thought about how I'm playing catch up as far as blogging related features go. I had to add an Archive page. I had to add a basic Tags page. The sitemap and feeds feature didn't seem to work and I haven't spent the time to figure those out yet. So before I write even more blog posts and in the interest of saving myself time, I've switched to using Wyam to generate this blog/website.

I should have gone with Wyam from the start, but I found the Jekyll Now repository last minute and thought it seemed too easy not to give it a try. So I gave it a try and yes, it is very easy to get a blog up and running without touching the command line at all. A lot of people have used it and are happy with their blogs. However I think it's time for me to get back to what I really intended to do in the first place, and that is building this static blog/website using Wyam.

Here are some reasons as to why I want to use Wyam for this blog/website:

• It is a static site generator that is written using .NET Core. Being a .NET software developer myself, using it to generate my blog/website is extremely rewarding in some way. I've also wanted to play with .NET Core for awhile now, so this is just another excuse to try it out.
• It supports building pages/websites using Razor, which I think is awesome.
• The configuration file is written using C# code and I love C#.
• You end up with a fully featured Blog when using the Blog recipe. By that I mean, you have a working Archive and Tags page, as well as automatically generated feeds.
• It is very easy to switch themes, even on an existing live site.

I must point out that creating/maintaining a blog using Wyam is slightly more challenging than using the Jekyll Now approach. You will have to use a command prompt/terminal to build your site and getting it hosted is not as simple as just creating a repository in Github and changing some settings. I like the extra challenge though. And writing blog posts using text editors and building the site using a terminal, kinda makes me feel like I'm blogging like a hacker, except I'm using .NET Core and Wyam instead of Jekyll.

Tags: #Wyam #Blog

Discuss... or leave a comment below.

As I alluded to in my previous post, part of the limitations with creating a blog using the Jekyll Now repository, is that it didn't come with Archive and Tags support out of the box. Considering how easy it was to get a blog up and running with Jekyll Now, we shouldn't hold this against it or its creator/contributors. Instead, we should take this as an opportunity to learn more about Jekyll and start writing some code. So here is a quick guide on how you can add an Archive page to your Jekyll Now blog.

Step 1: Add a new archive.html file inside the _layouts folder in your repository.

The content of this file will be a mixture of HTML and Liquid. Liquid is a template language that you can use with Jekyll to help control the pages that are generated for your static site. Think of it as some programming code that gets processed when your static site is generated.

I actually struggled with this for awhile as I could not reconcile how a static site had, what looked like server side code in its pages. What I didn't realize then was that the Liquid code is only used to generate a static page/site. From a .NET developer's perspective, it is almost like Razor, except it is only used to generate a static site/page. It is not going to run as server side code.

The content of the archive.html file will be as follows:

---
layout: default
---

<article class="page">
  <h1>{{ page.title }}</h1>
  <div class="entry">
    
    {% assign previousYear = "" %}
    {% for post in site.posts %}
      {% capture currentYear %}
        {{ post.date | date: "%Y" }}
      {% endcapture %}
    
      {% if currentYear != previousYear %}
        {% assign previousYear = currentYear %}
        <h3>{{ currentYear }}</h3>
      {% endif %}
    
      {{ post.date | date: '%B %d, %Y' }} - <a style="font-weight: bold" href="{{ post.url }}">{{ post.title }}</a>
      <br />
    {% endfor %}    
  </div>
</article>

All I'm trying to do here is get all the blog posts on this site and list them down by year. *Note that I am relying on the fact that the list of blog posts returned by the Jekyll Site Variable site.posts remains in reverse chronological order. For now, that seems to be the case and I don't have to add Liquid code to correctly sort the entries.*

If you're wondering what the line of code ”| date: '%B %d, %Y'” does, that is what is called a Liquid filter and that simply formats the date value to a format I specify. This is similar to calling the ToString() method on a DateTime object in C# and passing in a custom datetime format string.

Step 2: Add a link to the Archive page by editing the default.html file.

The default.html file is also found in the _layouts folder in your repository. The link we want to add is this:

<a href="{{ site.baseurl }}/archive">Archive</a>

To find where to insert that line, just find the block of code in the default.html file, where it has the links to the About and Blog page. The code below is an example of what you are looking for.

  <nav>
	<a href="{{ site.baseurl }}/about">About</a>
	<a href="{{ site.baseurl }}/">Blog</a>
	<a href="{{ site.baseurl }}/archive">Archive</a>
	<a href="{{ site.baseurl }}/tags">Tags</a>
  </nav>

As you can see in the code above, I have added the link to the Archive page after the link to the Blog. This is also the code to modify if you wanted to change the order that the links show up on your website.

Step 3: At the root of your repository, add an archive.md file.

The content of the archive.md file will be as follows:

---
layout: archive
title: Archive
permalink: /archive/
---

Adding a .md (Markdown file) at the root of your repository will force Jekyll to generate a html page for that .md file. This is also how Jekyll decides to create the About page, because there is an about.md file in the root of the repository.

Some notes on the content of the archive.md file:

• The layout entry simply tells Jekyll to reference the archive.html file that you added to the _layouts folder. So basically when this Archive page is generated, it will use the layout/html that you have specified in the archive.html file.
• The Title entry is simply the Title text that will show up on the Archive page.
• The Permalink entry is used to ensure that the generated Archive page shows up on “yourdomainname.com/archive/”. You can also supposedly set this in the configuration file, but I just chose to do it here.

There you have it, that wasn't too hard I think. For reference, you can view the source code for this website on Github to see how I implemented it.

#Jekyll #Liquid #Blog

Discuss... or leave a comment below.

If you are a software developer, this is probably the quickest and most fun way to get a blog up and running in like 5 minutes. If you are not a developer and don't have time to tinker with your blog, I think you might be better off creating a blog using a CMS like Wordpress. At the very least, you would need to learn how to write content using Markdown if you are going to follow this approach to creating and maintaining your blog. (Markdown is very easy to learn though, even for non developers.)

Regardless of whether you are a developer or not, this approach is pretty easy to follow and you will end up with a simple blog that just works. You don't even need a custom domain to try this out and your blog will be hosted for free on Github pages.

This is how this blog/site was previously created. I have since updated this blog to be powered by write.as.

There are a number of articles/posts about this topic already so I won't rehash what others have already written. I'll keep this short and simple and just point you to where you need to go to get this done.

1. Sign up for a Github account.
2. Find the Jekyll Now repository on Github and start reading the readme info. Actually, you can jump straight to the Quick Start section and follow the instructions there.
3. That's pretty much it actually. If you follow Step 2 and go through the instructions from the Quick Start section, the end result is your very own blog up and running on the web, hosted on Github Pages for free!

Barry Clark, the creator of the Jekyll Now repository also wrote a more detailed tutorial on how to create a blog using Jekyll Now and Github pages. If you made it this far, I suggest reading that as well.

There are some limitations to creating a blog using this approach, namely, your blog will not have an Archive and Tags pages out of the box. Those are features that I think people would normally expect to be built-in on a blog website. It is not the case here, most likely due to the restrictions Github Pages has on Jekyll plugins. Fear not, as these are easy to add/implement yourself. I will cover adding an Archive and Tags page in a future post.

I hope this post has at least helped you get started on a blog. Good day everyone!

#Jekyll #GithubPages #Blog

Discuss... or leave a comment below.