scientist:~$ sudo su -
sudoscientist:~#

Welcome to my blog!

Nice to meet you. Thanks for being here. Here is a little bit about me, and my blog, sudoscientist. I go by Asara on the internet, and I am an aspiring engineer. I’ve been in the industry for a while, but it is an infinitely wide industry, and there is still much more to learn. This will be a pretty long blog post, but not a very technical one. The next post will deal with the actual process of building sudoscientist! The motivation for sudoscientist was twofold.

The primary motivation was that I wanted to get back into blogging, and being that I haven’t made any posts in about 5 years, I had to take action. I have learned a ton in that time period, and have shifted my focus from the general catchall of Linux to architecture, the cloud, and automation. Docker has absorbed the industry in this time, and from my humble dabbling in building docker back in 2014, to building Kubernetes in 2019, a lot has changed. I’ve flipped through a few jobs, built some really cool solutions to interesting problems, and it would be fun to write about the challenges that I will face going forward.

The second motivation was technical development. My previous blog was built with Pelican, the static site generator. This was a workable solution, but left a lot to be desired. I had no feeling of ownership over it. Like most things in life, it seemed like a tool that was given to me, which I used. I realized I didn’t truly understand what was going on under the hood.

A static site generator is a simple tool, it will take some plain text files, applying some templating to them, and rendering them as HTML. This however wasn’t interactive. I wouldn’t be able to improve or extend this solution without adding other tools from other providers. The feeling that I was just using tools and not building my own solutions bothered me. That lead to the beginning of sudoscientist.

Iterations

Blog engines are easy right? Everyone has one!

My personal experience has been that many engineers enter technology via content management systems. WordPress, Django, (insert your favorite content management system here), etc. This is a great start. Most of the confusing or complicated features are hidden from the developer. Model, view, and controller allows engineers to build solutions much faster, but leaves them tangentially dealing with databases, having a hands off approach to networking, and rarely working with serialization of data. Authentication? Already built in. Comments? A click away.

This was my experience. I started with Python, the language I was most comfortable with, and hacked away at Django. Django was a nice starting point. I had always been apprehensive about programming, as I never had any real math training. I still don’t know much about algorithms, or what the best data structures fit which situations, but that will come with due time. Django allowed me to rapidly build out a solution, but it didn’t really allow me to fiddle with things. I always felt that building around middleware was cumbersome, and frankly annoying. Plug and play works great, but comes at the cost of understanding.

The next step for me was moving from Django to Flask. Another Python framework, but a micro-framework this time. This again, was a nice comfortable median for me. I wasn’t so deep in the weeds; I was overwhelmed, but I still didn’t really need to learn what I was doing. Documentation such as The Flask Mega-Tutorial made working with Flask very straightforward. This was a good way to take off the training wheels, but I still felt as if I was selling myself short. Templating was all done server side, and the modern world was moving towards technologies such as Angular.js and the then, very young, React.js. Like Docker, JavaScript has taken over the world as well. This lead me to realize that I would have to bite the bullet eventually, and I decided to move away from the model/view/controller methodology, and towards the paradigm of RESTful APIs and static sites written in Javascript to access those APIs.

Enter sudoscientist

I began writing the back-end to sudoscientist in Python. Flask-restful is a fun tool, but I decided quickly that I wanted to move past Python for larger projects. Python is a great scripting tool, and I wanted to use it in that context. The decision to learn React was similar to that of choosing Go. Go has been gaining steam over the past few years and has a very mature HTTP standard library. While I didn’t write sudoscientist with only the standard library, go-chi, the routing framework used, is a very simple one, and is fairly easy to read and understand. I have also over time come to avoid, and possibly dislike object oriented programming. Golang’s hands off approach felt smooth. Along with this, many tools in my `${DAY_JOB}`` are built in Go. It made it a compelling language to work with. The focus on a low level of external dependencies when building, and the ethos of using the standard library for as much as you can also piqued my interest. With the tools chosen, I began working.

I started with the back-end in February, and hacked around with learning the language, the tools, and using curl to make requests. Once I had something I thought I could work with, I began the frontend, with a read me stating FML. About 9 months after starting this project, I am now able to say Hello World!

Thanks for being here, and I hope to catch you on the next one!