Year in Review: Redgreenrepeat in 2017
2017 was a big year for me personally and even for my blog! I reached 100 articles November 2017 and have more highlights I want to share.
A Message to My Audience
For those that regularly read my blog: THANK YOU. Although I write for myself, I really appreciate your time and energy in reading my blog.
For those that are just finding my blog: Welcome! I write on technical topics I find interesting and love to share more of what I learn with others.
Please connect with me through my contact page and you can message me anytime on anything.
I wrote 52 articles over the year.
- the total number of words: 62,960 words, which is enough for a novel.
- the average article length 1,210 words - five pages per article
- the total number of pages I wrote: 62,960/250 = 251 pages.
So wow, writing weekly really adds up!
With 52 articles in 2017 and the following articles were my favorite. All of them pushed me to learn better than I would normally, develop content for non-technical people, and one helped me contribute to a great open source project.
Reading and writing about nonviolent communication was enlightening. First, I discovered I really didn’t grasp the ideas after one reading. Second, writing about it gave me a different understanding than from just reading. It definitely felt drawn out by writing a chapter a week, but it definitely helped set a good pace to integrate the material into my life.
The learning does not stop here with nonviolent communication. I plan on furthering my understanding by attending nonviolent communication events in my vicinity.
My series on basic computer system security started as a question:
How secure is my server on the internet?
Only when I thought about how to test and validate the answer did I realize how vulnerable open servers are on the internet.
At the same time, it made me think about how to protect the server by incorporating fail2ban, sending notifications me when logins happen.
This article has given me content to use to explain why server security is really important, even to non-technical people.
At first I doubted the error, but when I ran through simpler scenarios, I confirmed the error was in the documentation.
That made my heart race.
The main reason was: wow, here is a chance for me to contribute to an open source project!
Not just any project, but one that I love and my coworkers use frequently. I was a bit nervous about getting my pull request accepted, but it turned out smooth and I impressed bbatsov .
Writing has been helpful in getting my thoughts together but it has helped me learn certain technologies better than I would have on my own.
I have used vagrant before, but only when I sat down to start scripting it and using the provisioning system that I really understood how powerful it can be. I didn’t just want to write about how to use vagrant, but to teach others how to command vagrant to do things they want: building custom developer boxes.
This basically started because the setup steps for emacs on a new system annoyed me and I did not want to keep looking it up.
Now I include a Vagrantfile in any hobby project so I and anyone else can easily revisit the project later.
After vagrant, I took the next step in learning provisioning systems: Puppet.
I have used Puppet scripts before and had a hell of a time updating it. I had no luck modifying the script and I couldn’t understand why.
Only after writing my own Puppet script and to set up my own server inside vagrant through numerous builds, searching for solutions, that I found the main problem I had learning puppet: versioning!
Puppet 3 is different from Puppet 4 and Puppet 5 is slightly different from that, mixing in different version of Vagrant. These slight differences is not noticable in the answers provided online, but they are apparent in the really weird errors from Puppet and Vagrant, which these errors are not documented anywhere, until now.
When collecting data about the number of server accesses for my security article, I had to parse through log files My instinct was to just write another Ruby script, but was hestitant as there was a bit too much testing required. I also wanted a functional approach.
So I used the tools available: cat, grep, awk, wc, sort, uniq, etc.
These utilities are on almost all unix distributions and used frequently. I had a lot of fun slicing and dicing the log files that I was able to make additional insights from the log since I did not have to test the utilities and can trust them.
Another shining moment was when I had an interview question about these utilities, I was confident in every one of them, even though I did not use them recently. For another interview, I was able to suggest using these utilities to solve the problem instead of writing out a Ruby script.
Things to Improve
Over this year, I definitely found areas in my blog that I can improve on. I enjoy writing but there are times where I look back at an article and think: “why did I do that?!”
There are instances when I look at previous articles that I see grammatical errors. This may be a function of two things:
- I am writing the article at the last minute.
- I am too concerned with following writegood rules.
I am solving both of these can by writing the article sooner and spending time to proofread.
There are some articles I read again and I wonder: what did I want to write about?? Could this article be better?
So, I will start revisiting previous articles and rewrite them. Bring the code and project files up to a new standard (i.e. including a Vagrantfile.)
Writing for 2017 was fun. Thanks to key articles, I was able to: get build content for non-technical people, make a pull request to an great open source project, and learn unix utilities so well I can use them under stress without using them recently.
For 2018, I want to improve on writing my articles sooner so I am publishing more polished articles.