Author Archives: antcao

Following Clean Practices

When I first started coding in AP Computer Science, I found it fun. It was like solving a puzzle, a difficult one at first, but it slowly made sense. One thing I struggled with was clean code. I remember vaguely writing code that was disgustingly dirty, as in unorganized, unreadable to others, and all around messed up. I’m surprised I was able to get something to work in those conditions. I soon realized that clean code would be a game changer, as I would be able to read it clearly, and follow along easily.

Clean code consists of some points, having good and descriptive method and variable names, appropriate spacing between different lines of code, and good sectioning are some examples. Ultimately, these can go further based on context. Some variables may not need overly descriptive names if there’s enough context to imply what it is used for. 

In this blog post, Karolina Tóth interviews Robert C. Martin, or Uncle Bob, on his way of building quality code. The post is fairly lengthy but it has very good tips. Uncle Bob talks about what clean code is, its benefits, how not using clean code can negatively affect you, and many more. One tip he gives is keeping your functions as small as possible, because once they start to get large, the method starts to become confusing. By not writing clean code, you slow everything down. On a team, it’s difficult to work together if someone’s code looks like a 5 year old wrote it. By writing clean code, the team can work effectively and efficiently, ensuring quality code. 

I think this is a good post, Uncle Bob has good information, not only on clean code, but also boosting team morale and how to ease into using clean code. His knowledge in teamwork comes from his own experience and mistakes, which I like. Someone has to make mistakes for others to learn, and fortunately, Uncle Bob has done just that.

Clean code is important, whether you work in a team, or alone. It’s good practice to do so. When I first started, it was sloppy code. But now, I can’t stand seeing unorganized code. Even after we had learned clean code in class, I realized that mine wasn’t exactly perfect either. I liked my variable names to be descriptive, but short, and I made the short part priority because I’m lazy. But after reading this post, I understood that it’s not always good to keep them like that, having overly descriptive names can be beneficial, but when they have to be. I like things to be clean, and orderly, and neat, and whatnot, so I’ll be sure to refer back to this post, and the rest of Uncle Bob’s resources later down the line.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Managing your Licenses

When it comes to sharing your work publicly, there are certain things you have to do in order to protect it, and you. Whether the work is a form of art, product, or even code, you have to put a license on it. The creator can put software licenses on their code to allow users to use it in certain ways, according to the license agreement. 

Software licenses are categorized into types, which are ranked from least restrictive to most restrictive. The least is the public domain license, which has no restrictions on your code, meaning anyone can do anything with it. Next is the permissive license, similar to the public domain one, except it has some restrictions on how users can use, modify and redistribute the code. The next one is the copyleft license, which also has restrictions on how to use, modify and redistribute the code, but it also states users must distribute the source code with it. The most restrictive is the proprietary license, which only allows users to use the code if they agree to an agreement, and does not allow them to modify or redistribute the code. Under each of these types, there are licenses that have their own extra requirements, so it is important to look at each one to determine which is a good fit for your code.

In this blog post, Ibrahim Ogunbiyi gives us 7 practices that can help with license management. Step one is documenting your procurement process, document where you purchased software, who did it, when, and other important details. Having documentation on software purchases is important for when you need to look back for information. Step 2, having a central list of all software licenses. If there are multiple departments in your organization, having a central list containing all software licenses is good to have. Step 3, understanding all software license agreements, reading through and understanding the agreements. Step 4, implementing a software license management tool. Having a tool to manage your licenses, tracking use, and optimizing use is really nice to have. This can also knock out step 5, regularly tracking license use, and step 6, keeping licenses accurate and up to date. The tool can do that for you, but sometimes, doing it yourself is nice. Step 7 is training employees about license management, which is important for an organization. Having everyone follow the same methods of management promotes uniformity, which makes things easier.

Although I may not belong to an organization that purchases software, I feel knowing these steps is good. Software licenses, or licenses in general, are scary and confusing. It’s not something you are taught in school, so having learned it in class was nice. I can’t quite relate to this just yet, but it is important to know management tips so that when the time comes, I will be ready. In the future, I know I will be coming back to refresh my mind on it.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Designing in Git?

When it comes to software, and working on it as a team, or sharing it with others, Git appears to be the bread and butter of it. That is what class is kind of centralized around, learning how to use Git, and how it benefits you and others. At first glance, it appears very hard. However, after understanding its role in the greater scheme of things and putting it into practice, it’s not all that hard. Originally, I thought Git was another coding language, like Java or C++. I was severely wrong, as it is more similarly to Bash in a way, but unique in its own way. It allows for people to create code, share it with others online, where it can be used, changed, and reshared with the original creator or other people, where the same thing can happen, making branches of versions of code different from the last.

To use Git, you need a code hosting platform, like GitHub or GitLab, and a code editor, like VS Code. You don’t need to use these specific sites or editors, as each is similar and unique in their own way. Once you have these, you can start writing your code, stage it, commit it and push it into your code hosting platform on the internet for others to see, use and change. Or you could fork some code you see and change it up however you want, stage, commit and push it back and see what others think. Git allows not only teams to work on code together, but strangers to work on it, from all over the world. 

But who says Git can only be used for coding purposes? In this blog post, by Bruno Brito, they describe how Git can be used for designers, as in those creating graphic design and photo editing. In the post, they describe what Git is, how it is used, how to use it, and other things needed to know as a beginner to Git. However, instead of editing code, they use photo editing software. In the specific post, they are using Tower, which is similar to our VS Code. They describe how to create repos, how to stage and commit, and then how to use code hosting platforms, or for designers, cloud-based hosting platforms, to maintain synchronization. Then they go on to describe forking, cloning, pushing, pulling and branches. 

At quick glance, this could be interpreted as a tutorial for Git, which it is. But it is in a setting different from coding, specifically for design. I like this post because it shows that Git can be used for other fields, similar to my last post. I find that these ways of organizing code, among teams and many people, efficiently, and it allows many people to chip in, and upload their work. Although the post to me is essentially useless, as I have already learned how to do Git, it can be helpful to others who are looking for ways to create an efficient work environment. I can relate to this in a way, as a communications student as well, I am somewhat fond of art, and graphic design. I may not use Git if I am creating work on my own. But in a team, keeping track of who is doing what, and what changes have been made to this piece and what not, it can be helpful.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Scrum for other fields?

This week in class, we went over the process of Scrum. Essentially, it is a loose framework on how a team should be working if they want the greatest potential from that work. I say ‘loose’ because it is loose, other than providing how the process should go, it allows teams to not only follow this framework, but adapt it and make it unique for their team and their work. I like this methodology for this reason. 

Scrum states that a team consists of developers, a product owner and a scrum master. Each has their own roles and responsibilities in the process. The process has five parts. The main event is the Sprint, which is a one month process where everyone is working in order to achieve a goal. Before this can happen, there is the Sprint planning, which is planning the Sprint and figuring out what needs to be done. Everyday before people start working, there is the Daily Scrum, a short meeting about what needs to be done that day. At the end of the Sprint, there is the Sprint review, going over the results and progress of the Sprint, and the Sprint retrospective, reflecting on the Sprint, as a whole and on individual parts, so that the next Sprint is better. Each part, and the roles, are described in detail in the Scrum guide.

In this blog post, Gregory Crown and Robert Pieper talk about how Scrum could be used outside the realm of software development, like marketing. I chose this particular post because not only does it connect to what we’re learning in class, it talks about how Scrum can be used outside of software development. In the post, they specifically talk about how marketing can use the framework of Scrum, and how it benefits from it. Pieper says that if it is a complex activity or problem, Scrum can help. He describes complex as something requiring a lot of opinions. He uses a water bottle as an example, saying one stakeholder may not like the color, another may ask what the purpose of the rubber thing at the bottom of it is, etc. Essentially, if you show the benefits of something, and there are a lot of different opinions on it, you can benefit from Scrum. He describes it in a very nice way, saying, “if you’re in a subjective environment where you’re getting a lot of opinions, use Scrum.” He says that if what you’re working on is something that just meets requirements, and then moves on, you don’t need Scrum. 

Personally, I agree with what he says. On paper, Scrum is an excellent framework for a lot of things. It has the layout on how to do things, but allows people to fill in the rest, however necessary for things to be done. It is a clean way of doing things, strict yet flexible. This shouldn’t just be a computer science thing either, if others can benefit from this, do it.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Hi

Hello, my name is Anthony Cao. I am currently a third year computer science student, studying at my local university. This is my blog, where I will be sharing my ideas with the public, and document my growth as a student aspiring in the computer science department.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.