DEV Community: David Emily

Clean Code Chapter 2 Thoughts

David Emily — Mon, 15 Jul 2019 00:26:14 +0000

Clean Code Chap 2

Ahh chapter 2 of Clean Code. For those just joining, I wanted to finally finish reading Clean Code and saw typing up my thoughts as a way to stay motivated. If you're interested in following my thoughts, chapter 1 was posted here.

Chapter 2's title is "Meaningful Names", which sufficiently hints at what the chapter is about. One thing I found particularly interesting about this chapter is that much of the material seems pretty common knowledge but also something that we should focus more on. As Robert Martin states,

"Names are everywhere in software. We name our variables, our functions, our arguments, classes and packages. We name our source files and directories that contain thm. We name our jar files and war files and ear files. We name and name and name."

I love this saying. It perfectly annotates what programmers do, name things. I've heard many people refer to programming more as art and less of a science and I think that's very true. Maybe some classes over English and wording would have been more helpful than the ton of math classes I had to take... maybe. Anywho, let's get on to learning how we can be better namers and, in turn, better programmers. The chapter covers many different thoughts and I hope all of you eventually read it. I wanted to cover some of the main points in hope that I remember to use them on the job.

Use Intention-Revealing Names

Of all the naming rules covered, I find this one the most important. I remember very distinctly the use of "records" or "recordsList" variable names on the job. While at the time it made perfect sense, only to return several months later and be unable to recall what type of records it was. Furthermore, how did a list of "records" differentiate from "recordsList"? The book goes even further into detail to abstract out comparisons to a useful naming standard, which I think is a great help. Sure comparing the count of "recordsList" against 5 meant perfect sense at the time but it would have been much easier to understand with a comparison against "full application record".

Avoid Disinformation

I found this section pretty interesting but perhaps not as impact on my day-to-day job. Perhaps it is just the environment I work in - all Microsoft tech, very intelligent people, particular pieces of the product - but I find a general lack of disinformation in our code. I think this is one of the advantages of large corporations and teams with specific goals, my team's jargon matches several of the team's I work with. I can see this becoming more of a problem in environments with different operating systems, third party software, and tools. I think a lot of this ties in with being mindful that other environments and tools exist.

I do remember a time when our team would pass around the term "cron". Coming from a Linux environment, I was confused on where our cron job was being ran and how to modify it, only to find out that it was instead a house-spun, scheduled program that runs on a timer. While this only caused a thirty second delay while someone explained it to me, if this software was passed off to another team it could be have been more harmful.

Use Pronounceable Names

While I get a chuckle out of the mental image of me asking my coworker how function "Xyz23gh" works, I am glad I don't deal with that. This is one of the sections that I think is pretty common sense and actually kind of difficult to do. Maybe it is just my experience working with bright individuals but I can't imagine writing a function and not naming it something easy to pronounce. With naming it something pronounceable, comes the advantage of being able to call out a specific part of the code and have someone know exactly where it is, or where to find it. If there's a problem in "GetRecordsAsync", I'll probably be able to find it more quickly than trying to spell "RecPulAsy".

Class Names and Method Names

"A class name should be a verb. A method name should be a noun."

Something that makes total sense when read but can be difficult to remember while you're coding. It can be a lot harder than typically thought to keep them separate, not because we're not all smart people but just due to how language works. If I was making some kind of blogging software, the variable name "reader" might make perfect sense to me as class name for someone who is consuming my blog. "Reader" might also make perfect sense as method name to reflect me consuming an API. Instead of making this mistake, a better option (although I'm sure even better ones exist) might be to call the class "Customer" or "Account" and the method "SaveArticlesApi" or "AddEmployee".

Additionally, it's important to stick to a naming standard and not to be too creative. If your entire codebase is using the action term "Retrieve" it makes sense to continue that pattern and not to start randomly starting the method with "Pull". It also makes sense to not name classes or methods after inside jokes on the team. While I'll probably chuckle if I read a method named after an event that happened on my team months ago; I would probably not chuckle if I read about an event that happened on another team, I would probably just be confused and need clarification.

Conclusion

While this is not an exhausted list of all the naming standards, these are the ones I found most useful. I wanted to leave the other tips out so I don't steal Robert Martin's thunder and I suggest reading over this chapter if only to expand on the tips I mentioned. This chapter really hit me not because it gave me ways to improve but also because it made me appreciate the environment I work in and the hassles we avoid by (somewhat) decent naming standards. We had a saying in the Navy that "every rule is written in blood" and I'm certainly glad to learn these naming rules from those that preceded me and not from pulling out my hair at work.

Clean Code Chapter 1

David Emily — Sun, 23 Jun 2019 19:14:13 +0000

Clean Code

Clean Code by Robert C. Martin (Uncle Bob) has long been spouted as a book every programmer should read. The book explains reasons why someone should want to program, why one should program cleanly, and how to program cleanly. I picked up a copy of this book during college but never finished it. I tried to read the book again during my internship but failed again. This time I'm going to make it through and you all are going to hold me accountable! So no more wasting both of our time, let's go into my thoughts on Chapter 1 of Clean Code. Much of my writing will be what I have taken away from the chapters. Please do not take what I say with any sort of authority as I have not discussed my thoughts with others and certainly have not discussed it with Robert Martin.

There Will Be Code

The first part of chapter 1 goes into the future of programming and attempts to dispell the idea of programming becoming obsolete. The arguement for the disappearance of programmers is that coding languages will soon become so highly abstracted that the product owners will simply be able to enter their requirements themselves. Uncle Bob's retort on this being that humans have long missed the opportunity to match exactly what their costumers require and that requirements can sometimes too exact for a certain level of abstraction.

I certainly see both sides of this arguement. As a programmer myself, I'm extremely hopeful that this field will be around for a long time. My personal experiences in the field lead me to believe that programming will be around at least for the next 20-30 years. We have seen that legacy systems do not simply grow to use modern languages and there lacks expertise, money, and time to convert them all to use newer systems. I believe legacy systems will become like the aging equipment in industries like manufacturing, where there will always be a small skeleton crew to maintain and upgrade the equipment; or like the accounting field where there exists efficient systems for the masses to use cheaply but businesses, or those with specific needs, will need to outsource to experts or keep an experienced individual on the premises.

I think the best thing for someone wanting to make a career out of programming can do is just continue to learn. Continue to learn your current job and learn how to best use other technologies in conjuction with it. Be the person to bring up workflow systems or the abstractions your company is looking for.

Bad Code Is Everywhere

This part of the book brought up so many personal feelings. Several times have I experienced, or been a part of, 'quick fixes' that are never documented or new changes that are not accompanied or covered with tests. 99% of the time these events happen for good reasons and just simply get forgotten about. Perhaps the change was a hotfix to a system in production and the team's need to document is put in the backlog. This is followed by the tempo never really slowing down enough to afford documenting that system and soon no one really remembers what the hotfix did or that it even existed. Additionally there's been times were tests haven't been added since the project belonged to a separate team and no one really knows how to set up the tests to properly test the new feature. This can continue on as the next developers don't want to add tests because the earlier group doesn't.

Maintaining coding standards is hard. It takes a certain amount of integrity and energy from others to keep everything readable and up-to-date. It reminds me of a separate book I read, The DevOps Handbook that recommended using 20% of the overall time a week to work on technical debt. I certainly think this is one way of moving forward but I think it would need buy-in from management and excellent documentation to be able to prove the value of doing it.

What Is Clean Code

This was probably my favorite subsection in chapter 1. Uncle Bob has used statements from other successful programmers to argue what the definition of clean code should be. While I will not go into depth what every programmer said - although I recommend you to because they were all very insightful - I did want to talk about Bjarne Stroustrup's section.

Some of you may know, Bjarne's the father of the C++ language. In his quote he uses the words 'elegant' and 'efficient' multiple times. Clean code should be elegant and efficient! As with any product you buy - cars, cleaning equipment, household items - the item should do exactly what it says it does. If you buy Tide detergent, it's probably not because of how it looks on your shelf, although that may be a part of it, but you're probably buying it because it cleans your clothes. Code should be like those products. It should do exactly what it says it does and it should tell you exactly what it does.

Additionally, the section goes into how bad code can 'tempt'. I'm so glad that Robert chose this section to go into. For those not reading the book, Robert talks about how a house with a broken window will continue to fall into disarray. If the window goes unfixed, the floors will probably go without being cleaned and the pipes will probably go without being maintained. This is much like a programming project. If you don't update the documentation with your changes, it's doubtful the next person will. If the documentation isn't getting updated, why update the tests or refactor the functions? It reminds me of cleaning my apartment. I can either clean for 15 minutes a day or let it go, but by letting go I will probably spend more time on it in the long run. This ties in well to the last part, the boy scout's rule.

The Boy Scout Rule

"Leave the campground cleaner than you found it". While I was never a boy scout (I stopped after becomming a cub scout), I was in the military. In the military we had a thing that if you found with a mess, it was your mess. It doesn't matter if someone before you caused it, you being there meant you were responsible for it.

I like to continue this thought process in the coding world. If you added a feature, fixed a bug, or just refactored, you need to make sure all of this is documented. If you found a mistake in early code, that mistake is now yours to fix. I think it's extremely easy to just use source control to find out who caused the issue and then push it off your priority list. If it's not your priority, who's is it? While you could probably argue that the original person needs to fix it, it's impossible to know what the deadline or requirements was asked of them. At the very least, I recommend bringing it up to them and offering to help. I find too often we take things too personal when the other person simply wants the product to succeed. Always try to imagine best intentions of others and always try to be a good steward.

Conclusion

I'm looking forward to working my way through this book. I know it will continue to get more technically deep and that the beginning chapters set guidelines and thought processes. I'm hoping you continue to join me on this journey!

Removing Root Login And Other First Steps Ubuntu

David Emily — Fri, 21 Jun 2019 00:48:05 +0000

Removing Root Login

Just recently I created a fresh DigitalOcean to play around with a side project. I think managing a remote Ubuntu server can be a little overwhelming so I wanted to walk through some steps to set up a safe, remote environment.

Connecting to your Server

DigitalOcean will either prompt you to choose between SSH keys or a one time password. For this example, I chose to use a one-time password, all though I suggest setting up SSH keys which can be created using PuttyGen. For Windows, things are a little tricker but I suggest using Putty, which can be found here or by choco install putty if you use the Chocolatey package manager. Soon you should receive an email from DigitalOcean containing your new server's name, ip address, and one-time password. You'll want to enter the IP address in Putty's 'HostName(or IP address)' box, verify the 'Port' box is set to 22, and hit 'Open'. You should receive a warning about this being unsafe if you do not know what you are trying to connect to, but go ahead and hit continue.

On the Server

So now you're in! You should have a CMD-looking window asking you to login. For the 'login as' enter root and hit the enter key. It will now prompt you for a password, which will be the one-time password sent to you over the email. After entering the password, it'll prompt you to change the password. What ever you choose to be the root password, try to keep somewhere safe. While you soon won't need to login as root, having the password will save you a possible headache down the road.

Update Server

First thing after resetting the password is to make sure your server is up to date. This can be done easily using Ubuntu's included package manager by typing sudo apt update && sudo apt upgrade. This will run through your programs and make sure you have the most up to date versions.

UFW Firewall Setup

Next I'd install a firewall to keep your server safe. I recommend installing the 'UncomplicatedFirewall', or UFW, on your server. This can be done by typing sudo apt-get install ufw although most DigitalOcean droplets come with it pre-installed. Now choose which ports you want enabled and disabled. You will want to ensure the SSH port (how you connect to the server) is enabled so I recommend starting with sudo ufw allow ssh command. Next is dependent on what services your server is running. If you're wanting to turn this into a web server, you will probably want to additionally run sudo ufw allow 80/tcp and sudo ufw allow 443/tcp. Now start the UFW service by typing sudo ufw enable and type yes when it asks if you want to proceed. Now that the service is enabled, you can type sudo ufw status to see that the service is running and what ports it is allowing. This is useful if down the road you want to add more to enable more features.

Fail2Ban

After enabling a firewall, I'd install Fail2Ban, a service that stops users from brute-forcing entry into your server. This can be done by entering sudo apt-get install fail2ban and hitting yes at the prompt. Fail2Ban has additional features such as emailing an address when supicious activity is occuring and the ability to see what IP addresses have been banned, so feel free to read the Fail2Ban Wiki for more options.

Creating Account

Next, let's create a new account so you will no longer need to do anything under root. First use the 'useradd' command by typing useradd username with username being the account's name you'd like to create. Next change the password to that account by typing passwd username where username is the account name you just created. Now that there is a new account, let's give it the ability to use sudo commands by entering usermod -a -G sudo username with username as the account's name.

Removing Root Login

You're almost done! Now that we have a firewall, a security system, and a new user, let's remove the ability to remotely SSH in by root. Enter vi /etc/ssh/sshd_config to open the server system-wide configuration file. Now you'll want to change the line that says 'PermitRootLogin yes' to say 'PermitRootLogin no' and add a line under it saying 'AllowUsers username' where username is the account name you created. This can be done by using the arrow keys to navigate to that row, hit the 'i' key to enter insert mode, delete the 'yes', type in 'no', hitting the 'enter' key, typing AllowUsers username where username is the account name you created, hit the 'Q' key to quit insert mode, hit the 'ESC' keyboard key, and then entering :wq to save your changes and exit the file.

Restart

Moment of truth! Type in service ssh restart to restart the SSH service or just sudo reboot to reboot the server. Now open another Putty window and try to connect using root.. you should be denied! Now try with your new account and you should be able to login.

You did it!

While this is certainly not the end of security features you should install, this serves as a good baseline when starting a new DigitalOcean droplet or any remote Ubuntu server.

Gathering Ideas For A Project

David Emily — Wed, 12 Jun 2019 02:28:45 +0000

Getting Started

It seems like while I was in school I had so many ideas for projects but I could never find time to work on them when keeping (or trying to keep) my grades up. I'm embarrassed to admit how many good ideas I thought of, put on the back burner, and then totally forgot about. Now that I'm a full-time developer, I never seem to want to code when I get home. It's not that I don't enjoy coding, quite the opposite, but life always seems to just get in the way. I've decided one that thing that might help with this is just getting a project going. At the moment I don't really have anything ground breaking but I know I want it to cover a couple things.

1. Plans

Sometimes I'll just be browsing around the internet and hear about a new technology or service that I'm really interested in but the service needs some kind of already existing infrastructure. For example, I've really enjoyed reading about GraphQl and have thought about ways to learn more about it. Unfortunately, you can't just build a GraphQl service with nothing to query -- or maybe you can but I'm not going to. Other technologies like gRPC and Redis sound extremely useful to know but need a purpose. Knowing all of this, I decided to build a project that would start as a CRUD (Create, Read, Update, Delete) web application and see where it goes.

2. Data

I know for my project I'm going to need data, and a lot of it. Many of the things I want to play around on work a lot better when there's pre-existing information to pull from. I don't have a great pool of data to pull from so I thought I'd take someone else's. Luckily for me, my home state of Missouri collects a lot of free-to-use data at data.mo.gov. While I'm not super particular on the data I use for this project, I thought I'd use something at least kind of personally interesting, alcohol. Ahh yes, nothing like keeping track of my favorite watering holes. I decided this project will use the "Missouri Beer, Wine and Liquor Wholesaler List with Zip Code" data set which just so happens to be updated daily. Now that I've decided on what data to host, it's time to decide on how to host it.

3. Hosting

This is truly the golden age of hosting options. Just by web searching for hosting, I find options such as: Google, Microsoft, Amazon, Digital Ocean, Linode, etc. For many school projects I ended up using DigitalOcean, mostly because they had cool stickers. I thought since they already had my billing information, and they offer really reasonable prices for what I'm looking for, I'd continue to use them. So what am I looking for? I think a huge part of the learning experience is building the entire project from scratch, and since I'm looking for learning experiences (and items to blog about) I'll just need a basic box.

Conclusion

Now that I have the idea thought out, it should just be slowly working through the steps. Sometimes it can seem like a hard task to keep up on, but I find the most difficult part is just to start. I'm glad to be living in a world where I can share my thoughts and goals and where you all can keep me accountable. I plan on logging my steps in some posts so hopefully others can learn from my growth and my mistakes, and so you can hold me accountable :)

Chocolatey, package management for Windows

David Emily — Tue, 11 Jun 2019 02:35:50 +0000

Package Managers

As a long time Linux user, the thing that still bothers me about both mainstream Operating Systems (MacOS and Windows) is the lack of solid package managers. For those unsure of what I'm talking about, a package manager is a program that keeps track of what other programs are installed and where releases for those can be found. So if you're on a Ubuntu machine, doing a

sudo apt-get update && apt-get upgrade

will find all of the current programs being tracked by the package manager and update them to the most current version. It's been a constant issue for me, as a new Windows user, to remember to update my software and to remember where it is located. Luckily, I've just recently found Chocolatey and it's made Windows feel a little more like home.

What is Chocolatey?

Chocolatey is an open source package manager for Windows. Much like Homebrew for Mac, Chocolatey is a delightful command line package manager that has been released for Windows. While it is not officially supported by Windows, it has a long history (since 2011) of filling the need in keeping programs up to date. It requires Windows 7+(Windows Server 2003), PowerShell 2.0+, and .NET Framework 4.0+ to run. Chocolatey does have a paid service which includes really cool options like private package sources, package download throttle, and many more resources.

Using it has been a dream. At this time, it does have a graphical user interface that you can download, but I haven't found the need since using it's command-line interface is easy and intuitive. The hardest part of using this amazing tool is just remembering to run PowerShell in administrative role as it lacks the ability to switch to admin role mid PowerShell -- no Linux sudo here :(

The software is easy to set up as well and can be downloaded from the homepage here. While the website contains all of the instructions needed to set it up, you'll mostly just need to run the installation software, find the programs you want on Chocolatey's gallery, and follow the instructions for that package.

Keeping your packages up to date is also easy. By running

choco upgrade all -y

Chocolatey will run through all of the packages it is managing and install the newest version from the repository. Although it's easy to add existing programs to Chocolatey, I ended up just reloading Windows on my laptop so I could add all of my commonly used programs (and remove all of the existing Windows bloatware) to it.

Alternatives

Like all good software, and popstars, there's a couple alternatives that try to mimic the success. Specifically for the Window's environment, this alternative is Ninite and the default Windows Store that comes installed with Windows 10. Ninite has a very intuitive website to use and many of the commonly found installs. My only complaint with Ninite is that a paid version of the software is required to keep those programs up to date. Windows Store on the other hand has been a constant pain since I first tried to use it. The GUI is overly busy and it is loaded with advertisements for software I don't want to use.

Conclusion

Package managers make keeping track of software a breeze. Never again will you need to maintain a .txt document of where downloads can be found or combing through 'About' links checking if your software is on the newest version.