Forem: Dan Han

Mastodon Backup

Dan Han — Sun, 20 Nov 2022 00:00:00 +0000

I have been active on Mastodon, posting one reactive, misguided, opinion per day. In this blog post, I’ll describe my mastodon backup process.

Why backup posts/toots?

The things I am posting to mastodon are important to me. I do my best to post thoughts and opinions that I think are worthwhile. I hope that they’ll be useful to others, which is why I’m not just posting to a local text file. But even if they don’t have value to others, I hope these old posts can be valuable to me. Maybe they can remind “future me” of something I forgot, or maybe they can help “future me” realize how far I have come. It’s really hard to remember how dumb I used to be. So, I want to have access to all my ramblings for all eternity.

I trust that the amazing folks maintaining my mastodon instance, fosstodon, want to provide a service that gives gives me full access to all of my toots. They surely want to preserve data and have it available for me. With that said, issues can arise. Stuff can happen that may block me from my own toots. Maybe there’s some bad actors that wipe out data. Maybe the instance runs out of funds, I miss all the warning messages, and it’s shut down before I get a chance to get my data. Maybe I turn on some setting that auto deletes my toots.

So, backup is important to me.

My backup process

My backup process depends on a few tools:

mastodon-archive provides the scripts to fetch the backup and render it nicely in html.
Docker provides a nice environment for running the script.
Synology NAS provides a task scheduler where I run Docker and stores the backup files for me.

The backup script

mastodon-archive has a thorough README and help documentation, so you will learn more by reading the docs there. I read them, skimmed them at least, and I found two commands to be particularly useful.

mastodon-archive archive danhan01010@fosstodon.org

This will create a file like fosstodon.org.user.danhan01010.json that contains all of your data. The first time you run it, it will ask you to go through a couple of extra steps to create a “secret” file. This gives the script the information needed to fetch your archive. It’s a one time thing, and the same secret file can be reused in the future.

The json file can be difficult to read. It can be rendered into a nice html format by running

mastodon-archive html danhan01010@fosstodon.org

which gives you a file like fosstodon.org.user.danhan01010.statuses.0.html, which you can open with your web browser. here’s an image of what I see after my latest backup.

Docker and Synology NAS

I wanted to automatically and periodically run the backup scripts, so I defaulted to tools I’m familiar with and have access to. Here’s my super simple Dockerfile.

FROM python:3.9-slim-buster
WORKDIR /app
COPY . /app
RUN python3.9 -m pip install mastodon_archive

It does two things. It copies secret files over to Docker, and installs the mastodon_archive package. Note, installing from pip will ensure we are using the latest published version of the package. You could pin the install to a particular version or create the package from source files if you worry that a broken change could mess things up. I just went with a simple install for now.

Then, I use docker compose to make things easy to run. Here’s my docker-compose.yaml.

version: "3.9"
services:
  archive:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - .:/app
    command:
      - /usr/local/bin/mastodon-archive
      - archive
      - danhan01010@fosstodon.org
  html:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - .:/app
    command:
      - /usr/local/bin/mastodon-archive
      - html
      - danhan01010@fosstodon.org

It’s a bit longer, but doesn’t really do too much either. It sets up two services: one to fetch a backup file and another to create an html file to view the backup. With all these docker files ready, you can run

docker-compose build && docker-compose run archive && docker-compose run html

I added that command to a scheduled task in my local Synology NAS. It runs once a week, and my backup process is complete. Of course, I have synology also running backups of all my files, so these files are backed up as well. Redundancy is good!

Conclusion

If you put any thought or energy into your Mastodon posts, you will want to back them up. I posted how I do it, but I’m open to hearing about any other better strategies.

Revisiting Your Technology Past

Dan Han — Sun, 20 Nov 2022 00:00:00 +0000

A couple of years ago, I was regularly developing with Flask. Since then, I’ve moved onto other projects and technologies. Today, I decided to revisit this “old” tech stack; it was a fun and interesting experience.

A little background

When I first used Flask, I was trying to build a personal website. It would be a simple site, containing a blog, a list of projects, and other static content. I built something and used it for a while. But eventually, I decided to shut my custom project down, and began hosting my site with github.

Since shutting my site down, I hadn’t done any programming with Flask. Today, I was thinking of building a new website/app. I read through some introductory texts on a few existing solutions: Django, Ghost, Wordpress, etc… And then, I came across my old friend Flask.

For probably the same reasons as before, Flask appealed to me. It uses python, which I like. It feels relatively lightweight, at least moreso than Django. So, here I am again, after a couple of years, trying to build my Flask application, again for the second time.

Familiar faces and places

As I began building a new Flask app, things felt very familiar. The code was really easy to understand, because well, I had seen it before.

Google searches led me to Miguel Grinberg’s site. His site contains lots of great tutorials related to Flask. I used it a couple of years ago, so I was sure the content would be good.

When you go through introductory tutorials, it is easy to be overwhelmed. There is just so much to learn: domain specific jargon, new concepts, and other technical difficulties. Good tutorials try to explain the bare minimum to keep you moving, while introducing a whole new world. Tutorial authors must maintain a fine line to push forward without losing the reader.

But for experienced developers, who are revisiting a topic, there is a lot more room for error. Instead of trying to focus in and just get through the tutorial, you breeze through the easy steps and can absorb extra nuggets of information. When I went through the Flask tutorial, I diverged from the tutorial and experimented with different implementations. If things went wrong, it was easy to get back on track.

Revisitng Flask today, felt like a pleasant warm up. The muscle memory of how Flask works faded, but I’m waking them up and was able to get coding right away.

New bells and whistles

Coming back to Flask, I found that the landscape has changed a little. I’m sure the platform has improved internally, but I haven’t gotten deep enough into it to notice. I did however notice that tutorials provide instructions for building with Docker and putting a React frontend UI in front of the Flask server.

Finding that Flask is ready to work with these technologies is a nice surprise. I use Docker a lot these days, so I’m comfortable in that development workflow. I have been meaning to learn React, so this project gives me a good reason to learn.

What did I build?

Nothing much. I have a super simple app consisting of a flask backend server and a react frontend UI. It is ready to work and build with Docker. If you are curious about it, I posted the project here simple-flask-reack-docker.

Conclusions and Recommendations

I highly recommend trying out technologies that you used in the past. Maybe some of the things you hated about it have improved? So, you’ll find it more pleasant than before. Even if things haven’t changed a lot, you will still have some memory of how things used to work, so you should be able to get started without a painful learning curve.

And as a more experienced developer, you will bring a new perspective to technologies you used before. You may be able to understand more of how things work, which feels good. You may also be able to incorporate some of your new knowledge so that you can get more out of that old tech stack.

We all start as coding newbs. Blindly pointing and clicking, hoping to just get those “hello world” applications to run. Before you realize it, you have learned and forgotten plenty of tech stacks. Instead of jumping into the new trendy toolset, I recommend revisiting some old stuff and see what things looks like there. I think you’ll find it to be a rewarding experience.

Thoughts on Mastodon After 1 Week

Dan Han — Sun, 13 Nov 2022 00:00:00 +0000

Last week, I noted that I joined Mastodon. My overall recommendation is to join and give it a try. The rest of this post provides some other notes on mastodon after 1 week of usage.

Moved to Fosstodon instance

I originally joined a large “general” instance called “mas.to”. It seemed OK enough, but I wanted a more tech-centric focus, so I switched to “fosstodon”. You can now find me here

https://fosstodon.org/@danhan01010

If you want to switch instances, I’d recommend doing it early. It’s easy to transfer your follows and followers over, but migrating posts over isn’t done automagically for you. So, it’s better to re-home early on, when you are OK letting your few posts remain in your old instance.

If you find the idea of instances intimidating and confusing, I hear you. My advice is to spend a very small amount of time reading about it. I’d read one or two of the top Google hits on the subject. Then, just dive in and pick one. After a bit, you will find that your instance is fine, or that you may want to switch. In either case, you learn more by doing than being stuck in decision paralysis.

Decorated my new home

I added a avatar, banner, bio and a link to my website to my mastodon profile. I created the avatar from some free web tool and used google drawing to create a simple banner. Personalizing the default stuff is fun. It’s also more inviting and engaging for others than the default stuff you get.

It’s customary to create and pin an introduction post, but I haven’t done that yet. For now, I’ve only been posting about programming/coding. I’m not sure if I will expand my posts to other parts of my life. I’ll wait until I establish my identity on this platform before setting the introduction.

Tools

I’ve used the web UI, the metatext phone app and even the toot command line tool. I found that all of it worked well. Some things were a little bit confusing, but I blame my own user error and misunderstandings.

I’ve also tried the mastodon-backup tool. It worked out of the box. I’ve still got to figure out how to automate it.

Content

By design, mastodon gives you exactly what you ask for. Your personal timeline will only contain stuff from those you follow or stuff they boost. For newcomers, who are not following anyone, things can feel empty. You can jump to other timelines that have bigger scope, ie within your instance or beyond, but the information may not target your interests.

I could try to search for people to follow and curate the perfect timeline to start, but instead, I’ve decided to focus on posting regularly. I’m aiming to post one toot per day. I’d like to be more of a producer than a passive consumer. If anyone follows me, I’ll follow them back. If you are interested in me, I’m probably interested in your thoughts. It’s simple to unfollow, so there is little cost.

As I run into interesting posts, I’ll follow the posters. Over time, I’m sure I can evolve my follower list to create a rich timeline for me to browse.

Future plans

My plan is the following. Post a thought once per day to mastodon. I think this will force me to publish ideas, even if they are half baked. The goal is to post things without worrying if they are perfect or not. Waiting for perfection has been a blocker for me in the past.

Then, once a week, write a blog post. I can use my recent mastodon posts as inspiration for writing ideas. Hopefully these blog posts are slightly more “baked” than my short mastodon toots.

Hope and dreams

The things I noted above are things I’ve done or will do. The last reason for using Mastodon is for the hope that it can connect me with others. I hope that I engage with some interesting folks and ideas and that we’re all better off for it.

Joined Mastodon

Dan Han — Sun, 06 Nov 2022 00:00:00 +0000

I just joined Mastodon.

Twitter is in a point of transition. It got bought, lots of folks were laid off, and major changes were announced. Most people are predicting doom and gloom. And as people worried about the end of twitter, I heard about the app “Mastodon” a bunch of times. So, I decided to try it out. After some pointing and clicking I created a new account.

https://mas.to/@danhan01010

My tentative plan is to just post to it regularly. I will try to get out of my way and just post things. In my bio, I said I’ll be posting “half-baked ideas”. I could then look through old posts and expand on them as more fully baked blog posts.

Let’s see how this goes.

Zen of Every Day Things

Dan Han — Sun, 14 Mar 2021 00:00:00 +0000

This month, I read most of Zen and the Art of Motorcycle Maintenance and some of the Design of Everyday Things. I couldn’t quite finish either of them before time ran out and they were due back to the library. With that said, I think I got a good feel for what each author was saying overall.

Both books delve into the relationship between objects and people. In Zen of Motorocycle Maintenance, the author views objects with reverence. For him, a motorcycle is a dynamic being. He observes and responds to it. As it strains from overuse, he reduces the speed of the bike so it can recover. He is attuned to any signs of failure and promptly works to correct issues. The limitations of a motorcyle, such as overheating, are not strictly design flaws. They are bounds in which the object can work well. If you place the object out of bounds, you can not blame the bike for coming up short.

In the Design of Everyday things, the author was much less forgiving of the object. Objects provide some utility and give some hints as to how a user may access that utility. For example, a door provides the utility of transit into a building. Its door handle will have a certain shape that indicates to the user whether you should push, pull, turn or slide to open the door. If the user of a door cannot easily deduce how the door should be used, the blame is on the door, or the designer of the door. It should have been made in a way that would make things easier for the user.

I wonder how the authors of these books would feel about the other book.

I sympathize with both camps. As a software developer, it’s good to think like the author of Design of Everyday Things. You want to make things that are generally easy to use. Any confusion can lead to user errors and overall dissatisfaction. So, you have to put yourself in the mind of the new user and guess how they might feel about your product or API. Is the most natural way to use your product also the correct way and also the easiest thing to do? Telling people to read the manual is a signal that the design can be improved.

As a software developer, it’s also good to think like the author of Zen of Motorcycle Maintenance. You need to observe and be attuned to your code. If it misbehaves with bugs or bad performance, you can’t just blame the original authors and say the design is poor. You have to foresee or at least react to issues. Each bug is an opportunity to understand your system a little bit more and improve your system to be a little more robust.

In total, while I see the merits of both, I think I lean towards the Zen of Motorcycle philosophy. What about you?

One Win for a Team Lead

Dan Han — Thu, 01 Oct 2020 00:00:00 +0000

Being a manager is challenging. On any given day, I can look back on so many things that I could’ve done better. I could have brought more energy to a meeting. I could have spotted something that was bothering a team member a little earlier. I could have prioritized work differently or reduced the scope of a project. And on and on and on…

And the wins can feel quite sparse. When I was a developer, each day had some level of success. I got the code to compile. I was able to reproduce and fix a bug. I helped a colleague debug an issue with one of our libraries. Even when our team has a big successful release, it’s not as easy to spot what the team lead actually contributed.

So when I come across a clear win, I make a special note of it. Last week, I had one of those wins.

One of my team members was falling behind. He was working on a bunch of items: a bug fix, some research work, some admin work. He happily volunteered for the work, but they weren’t getting done. Prior to our weekly 1-1, I wondered what was the best way I could help him course correct.

I eventually approached him with a couple of questions instead of demands. I asked him how he was doing? I said that I noticed he had a lot of things pending, and asked him if this was his preferred working style.

Luckily, he said he didn’t like what was going on. This was fortunate. Instead of me making demands, such as “Get focused and start finishing work”, he came up with some modifications. He’d try to wrap things up, post updates more regularly, and ask the team for help earlier. I said I understood his current situation and offered my help. I told him that I would help prioritize items for him so that we could spend more time on the things he really enjoyed. After some discussion, I felt we were in a good trusting space. At that point, I was able to say the higher level things I really wanted. I wanted him to get things done and to be transparent with updates. I think this discussion went well. His goals were now aligned with the team’s goals.

I don’t know what will happen next. Maybe things will improve. Maybe he will continue his bad habits. No matter what, we had a conversation that lays the groundwork for building trust and partnership.

Setting up NextCloud on My Raspberry Pi

Dan Han — Sat, 01 Aug 2020 00:00:00 +0000

Over the last week or two, I set up our raspberry pi to work as a Nextcloud server. I wanted an easy way to back up photos from my phone.

I read through and followed lots of guides to get it working.

Now that it’s up and working, I can say that it alls works pretty well without too much trouble. With some time and perserverence, I’m sure you can set it up as well. But as a reminder to myself, I wanted to notes some things that tripped me or slowed me down. No matter how trivial the project, we should all remember, these things take some time.

Even before I really got started at all, I found out that my Raspberry Pi operating system was a bit behind. So, I spent a bit of time upgrading. First, I had to upgrade from “Jessie” to “Stretch”. Then, I upgraded from “Stretch” to “Buster”. This was completely straightforward, but it took a while (hours?) to complete. It probably went quicker than that, but it was so long that I stepped away and just periodically checked on it. I think this sort of “rot” happens on any project. You go to fix one thing, but you discover you have to do a lot of other clean up before you can even get started.

The next big time consuming thing was permissions. In Unix, every file and folder associated permissions. Who owns a file? Who can read, write or run a file? Setting tight permissions prevents bad-guys from messing with your stuff and keeps you from shooting yourself in the foot. But it can also be a pain. You “workaround” this problem by just relaxing all restrictions and making every file readable and writeable by everyone in the world. It’s simpler to get things done when there is no security. In contrast, doing the right thing takes longer, and the benefits are often unsatisfyingly delayed, but it’s usually worth it, right? So, I fiddled around until permissions and user ownership were just enough to get things working, and not any more than necessary.

Finally, the last big time suck was figuring out how to adjust the power settings on my hard drive. I expect the NextCloud server to sporadically need to read and write to the my hard drive. It would be a couple of times per day max, and many days, no reading or writing would be needed. So, I wanted my hard drive to spin down to save on wear and tear. A lot of suggestions on using one tool or another sounded like they would work, if your hard drive was compatible. In the end, I got to a happy solution, but it took a decent amount of trial and error.

Conclusion

I’m glad that I completed this project and that I’m putting my raspberry pi to good use. It didn’t take too much to set up the Nextcloud server, but yet, it took longer than I expected. I’ll try to remember this whenever I estimate work. If I don’t know exactly what I’m doing, it’ll probably take a little longer than I’d guess.

Custom Domain For Github Pages

Dan Han — Sat, 23 May 2020 00:00:00 +0000

I recently set up github pages to use as my blogging platform. And I have had no major complaints so far. I already added lots of bells and whistles: commenting, analytics, rss feed etc… Today, I’ve set up custom domain for my github pages.

I already had a domain with Google Domains, so I just had to point it to my github pages site. To get it working, I followed this medium post and the documentation from github. Now that it’s all done, going to any of these urls, programmerdays.com, wwww.programmerdays.com, dannyhan12.github.io should all take you to “programmerdays.com” which shows my github pages site.

The process involves just 3 steps, but I found it a little confusing at first. Here’s some notes that explains what is going on.

Step 1

First, update Google Domains or your DNS provider to send your apex domain, such as "<my-awesome-custom-domain>.com" to the IP addresses owned by github. This is pretty straightforward. You need to tell the "internet" where to find the server that will process your requests.

Step 2

Next, update the settings of your github project to use your custom domain. Now, when Github servers get requests for “my-awesome-custom-domain>.com", they'll be able to properly map it to your github pages, "<username>.github.io". Conversely, if you make a request to the original github pages, the url is auto-magically updated to your custom domain.

I used this curl command to review requests

curl -v -L -D - https://programmerdays.com -o /dev/null 2>&1 | egrep '>|<|\*' | less ,

and I could see that the request is sent to one of the github IP addresses and that it immediately returns with a successful code, 200. If I run the same curl command with the url of my github pages, “<username>.github.io", I get a 301 redirect rcode. Then another request is sent to my custom domain.

Step 3

Finally, update Google Domains again. Add a CNAME for the subdomain, “www”, to your "<username>.github.io." page. Now, requests going to “www.<my-awesome-custom-domain>.com" will also get your github pages page. The github docs mention that the proper redirects work between a subdomain and an apex domain.

Conclusion

Setting up a custom domain was pretty straightforward. I got it working without too much trouble, or even understanding. I then took a little time to learn about DNS records and HTTP redirects. Getting something working and learning something is a nice double win for me.

Tips for Writing Pull Requests

Dan Han — Wed, 29 Apr 2020 00:00:00 +0000

These days, when you update code, you often do it via a pull request. You write code, create a pull request, and hope that your changes are accepted.

Pull requests and code reviews are scary. Posting your code for someone to critique is nerve-wracking. Doing it in public is terrifying. Here are some tips to make it all a bit less scary.

Communicate

A pull request should start with communication. The person reviewing the code should confirm that the update you want to make will be welcomed. You should confirm what you will be doing and even how you will do it. A pull request shouldn’t be a pop quiz. It should be a take home exam, where you can ask the teacher how to answer the questions before you go home. And then you can ask follow up questions as you are working on the test. Communication ensures that you are coding a fix that everybody wants.

Stay Focused

Now that you know what you want to do, deliver what you promised, but not much more or less. Don’t add extra “drive-by” fixes. If you spot a bug somewhere else in the code, don’t fix it in this Pull Request. Create an issue so that it can be fixed later on, and stay focused on the purpose of your pull request. Don’t try to do more than one thing in this pull request. Pull requests targetting one item are easier to read and review. Getting a single pull request merged is hard. Don’t make it harder by adding in some extra things that stir up more questions and discussions.

Test

Demonstrate your pull request works with tests. Add new tests to show that your update works. Or note which failing tests are restored. Code reviewers don’t have to rely on your word or their mental debugging skills to be sure everything works. The tests in the pull request prove that the code works and document the normal and edge cases that you’ve considered. If the repository isn’t easily testable, at least describe what tests you manually did to prove things work. Including some screen shots or standard output may be the best you can do, but it’s better than nothing.

Fit in

Make your code look like the rest of the existing code. Whatever style conventions exist, mimic them. No matter how much you dislike the conventions used in the code base, just go with the flow. If you add code that doesn’t fit in, it’s harder to read. It’s also somewhat insulting to the original authors.

Cheat

If you’re nervous about submitting a pull request, look at other pull requests that have already been closed or are being reviewed in the repository. You can see what sort of reasons other pull requests were rejected or accepted. You can see what sort of questions people ask. This will help you avoid common mistakes.

What else?

If you’ve done all of the above, you’re in a good position to get your pull request accepted. Do your best to write good code with good commit messages. Then, go ahead and submit with confidence.

Being Nice

Dan Han — Sat, 18 Apr 2020 00:00:00 +0000

I have always been a nice person.

I am polite; please and thank yous all the time. If you ask for help, I give you some. If you make a mistake, you'll get the benefit of the doubt from me.

It was always easy for me to maintain this level of aggreeability. But it's getting harder. On a personal level, I've become a parent. Kids are exhausting. They consume my patience with their unrelenting need for attention. I love showering them with love, but it's still exhausting.

On a professional level, I've shifted my role from individual software developer to team lead. Being a manager is depleting my reserves of nice-ness. It takes boatloads of empathy to be an effective manager. There are so many relationships and interactions to navigate. Being consistently nice to everyone (team members, your manager, other teams, your clients, etc...) is tricky.

So, I'm finding it harder to be nice. That's a big problem, because being nice is part of the job.

What do I mean by being "nice"? It's a subjective thing. I think it is one of those things that "You know it, when you see it". The key question may be, how welcoming are you? When people are looking for help or advice, would they seek you or would they dread having to go to you? If you are nice enough that people like to interact with you, then that's probably nice enough.

There are so many things that make a software project and software team successful. Being nice is one of them. Sure, jerks write code, their stuff gets used, and they can be successful. But people also write shoddy, untested, slow and buggy code that succeeds as well.

Nice isn't necessary or sufficient for success. Steve Jobs and Linus Torvalds were infamously not nice and also super successful. Although, linus has admitted his need to increase his empathy.

But for most of us, being nice is an important ingredient for long term success. Just as bad code slowly cripples projects with technical debt, not being nice (being a jerk) will poison a team. You will be left with code that no one wants to touch and a bunch of people who dread talking to each other.

Being nice enables communication. Your team can raise concerns to you earlier and you can start addressing them before they get out of control. Instead of a teammate telling you they are leaving unexpectedly, you would be aware they were unhappy and help them shift them focus or at least make a smooth transition to another team.

If you're known as a jerk, you'll miss out. Other teams won't collaborate with you. You'll miss out on building things together or waste time addressing the same issues as someone else.

And on the positive side of things, being nice is contagious. Your team will pick up on this attitude and it will be part of your team's culture. We are all nice to each other. Isn't that nice?

So, I want to be nicer. Here are a couple of things I have been telling myself to do more, so that I could be a nicer person/manager/teammate.

Get healthy. If you are tired, hungry or otherwise unhealthy, it's harder to be nice.
When people speak, listen and don't do anything else (taking notes is OK). If you are reading or thinking about something else, it's impossible to show any real empathy.
When people send you email, read the whole thing, don't just skim.
Do something. Being a passive bystander, is not the same as being nice. Take initiative. RSVP immediately, Reach out and respond to people.

Most of that boils down to being less self-centered and more interested in whoever I am trying to be nice to.

Being nice isn't easy, but it's part of the job. As coders, we all spend trying to level up our development skills. As team members, are you working on being nicer?

Blogging with Github Pages

Dan Han — Sun, 12 Apr 2020 00:00:00 +0000

I’ve tried a bunch of different blogging platforms in my day. I used out-of-the-box tools like Blogger and Wordpress for a while. I also wrote a completely home-made application based on Python/Flask for some time. There’s plusses and minuses to everything, so it’s hard to say what tool is the best for you. For me, my interests keep on changing, so, the right tool seems to change as well.

In the end, the blogging software doesn’t matter nearly as much as the person writing the blog. I’ve had long periods where I stopped writing and publishing. None of the above blogging platforms could’ve helped me there. If you want to be a successful blogger, just start writing.

With that said, I’m now giving github pages a try.

Why github pages?

It’s free. Before, I was paying $5/month to self host. I can afford $5/month, but free is even more affordable.

It’s easy. I write in markdown and save my posts to github already. So switching my blogging/publishing to github pages doesn’t involve any extra work. It’s actually less work.

It seems like the right choice today. Github recently became part of Microsoft and Microsoft seems to be very developer friendly. If I’m wrong, and things aren’t so friendly here, I can always move this blob of text somewhere else.

Initial Impressions

I was able to get something up and working in a few minutes. But then, I found this guide which helped me transform my barebones site into a more fully featured blog.

I forked the repository, renamed it, and then dropped my old blog posts into the _posts directory. And everything just worked. Voila, I had a pretty functional blog. I then updated a couple fields in _config.xml to unlock some sweet blogging features.

RSS feed. You get this for free with github pages. Setting a value in the _config.yml will add a link to your RSS feed on the page. I still use RSS feeds, so this was convenient. Even better, I plan to register the rss feed to my dev.to account. I hope cross posting to dev.to should give me some readers.

For comments, I set up a new disqus site. Once you set that up, you need add it to the config. Then, you need to add comments: true to the front matter of each post.

To know how my blog is doing, I set up Google Analytics. I set up a new tracking ID and added it to the config. There’s obviously nothing much to see so far, but who knows, over time, maybe there will be something to smile about.

Parting thoughts

This post is mostly meant as a reminder to myself of when I switched blogging platforms, and what I was thinking and feeling today. New tools are fun. If this entices me to write a bit more, than it is worth the time.