This week I am reviewing another pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. For this week’s pattern I decided to go with the chapter “Your First Language”.  The context of this chapter is you have a shallow understanding of one or two different programming languages. This chapter grabbed my attention because while I have been in school for four years learning software development, I still feel that I only have a shallow understanding of a few different languages (in this case Java, C, and python, but Java is definitely my strong-suit). I feel that from the perspective of the classroom we know a decent amount about our languages, but from a real-world point of view, we only know the proverbial “tip of the iceberg” meaning that we still have much  more to learn about our languages. The problem presented by the book is that we feel that we need to be masters at our first programming language in order to be a good programmer and a purposeful part of your team at work. While the book says that you should not stress over the fact that you only know one programming language, they also point out that most jobs require that you know at least one programming language inside and out to get the job. This is a “catch 22” because jobs expect you to be masters in a language and be extremely proficient but at the same time they understand that you likely have little to no experience with your language because all you have had experience with is programming assignments in school. This kind of puts us at the disadvantage because we are expected to be masters at our trade to get an entry level position at a company we  may not be at forever. The solution proposed by the book is to improve your learning of your first language. How does the book propose this? By having actual problems to solve with your programming language skills and knowledge. I think this is important because using your skills to learn how to solve actual problems helps you retain your programming language skills and makes you a better programmer.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

As you may know, for our end of semester senior project we worked in groups of two in charge of developing a web application that had some sort of functionality. When we were first introduced to this we didn’t know whether to feel scared, nervous, excited or all of the above. What is HTML, CSS, angular, boostrap, etc.? So many things were thrown at us but in the end we made it. We learned all of it and no the question is.. are we full-stack devs? Maybe Eric An can answer that question in his article, ‘What is a full-stack web developer?’

The article begins with a big red T shaped image. The T-shaped model is a concept that describes the abilities/characteristics of an individual where a person has many generalized skills with a specialization in few. The full-stack web developer supposedly knows many technologies but specializes in few which is front-end development and back-end development.

Front-End web development is the presentation of the website which includes HTML and CSS and sometimes JavaScript; pretty much everything that the user sees when clicking a link. The goal is for users to provide a platform for users to interact with. Some other skills may be UE/UI design. For our project we learned the basics of HTML and CSS and I also learned how to use bootstrap to make things much simpler. Front-end development was a success!

Onto the back-end web development.. The creation of data collection processes haunts us to this day. We redefined the definition of struggle when it came to the back-end part of this project. Back-end development is associated with the front-end where as a server is being created to communicate with that the user is trying to do on the front end.

The definition of a Full-stack web developer is an individual who is in charge of performing both front-end and back-end so that all of the technologies put together makes up a website. After reading this article, although we are not experts in front-end/back-end development we could be considered full-stack developers!

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Towards the end of the semester we were working more intensively in group settings and even increased the number of individuals in our group which required greater collaboration among peers. I recently came across a post ‘Code Review: The Unit of Work should be a Single Commit’ by Paul Hammant. In this blog Hammant talks about the benefits of Code Review and how the end result is significant change in the way the program was written.

Some of the benefits he listed was:

– Two pairs of eyes catch more bugs (which saves hours of debugging if fixed early)
– Enforce coding standards, style guides (keeps overall readability & code quality high)
– Mentoring of new developers (learning from mistakes without breaking stuff)
– Establish trust relationships
– A good alternative to pair programming.

Our last few classes we as a group came across all of these aspects and more. We worked collectively as a team code reviewing some program and found that we listed many similar mistakes. Another important point he makes is that there is only so many times something is modified in review before it is considered ‘done’.

Although Hammant talks about reviewing code over Git and we did ours as a group in person the idea remains the same. Some steps he talked about were to lock a commit for the duration of each review and also how to move forward with which review change when two individuals have different points of view. I found that this article was relatable to our experience.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

This week I decided to read a blog post for my blog entry. The blog post I read is titles “These tools will help you write clean code” by Adeel Imran. Before finding this blog post, I’ve had a general and basic idea about coding and how it should be written, but I haven’t understood in great detail how to properly write clean code. The reason I chose this blog is to learn and be able to use the clean coding techniques on my future projects so it will be easier for other people read.

Clean code is extremely important in becoming a strong software engineer and when working in a team having clean code is a must so your teammates can understand your code. The blog opens up by saying that in more or less all software engineering jobs you will be working with a new code base at one point or another and that inconsistency is a big fundamental problem when working with different code bases. The author ends the blog by saying “In the end, coding is writing” and as a developer our responsibility is to maintain a consistently so it will make our code easy to follow when being looked over.

Besides all of the great resources that it gives, a major takeaway from this blog that I will apply immediately to my next project is using clearer names. Before reading this blog if I wouldn’t put much effort into naming things in my project but I learned that applying clear names not only improves readability, but boosts the context making the intent of the code easier to read. If I am to use clear names it will help the reader understand more quickly.

My goal is to become a software engineer and in the CS program sometimes it is hard for me to write clean code because I am focusing on other parts of the assignment or don’t have this labeled well. This article has given me ways to write clean, effective code in the future and I hope it can do the same for you.

https://medium.freecodecamp.org/these-tools-will-help-you-write-clean-code-da4b5401f68e

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

Hello readers, welcome back. This week I will be talking about code reviews and why they are essential to the testing process in computer science. I read  a blog titled “what is code review and why is it so important” by Eugene L. who is a project manager. He begins his blog by talking about how code reviews is a great form of communication between team members and for junior developers, they can become more proficient through this communication and at the same time help improve the code. Although code reviews are used to spot bugs, they have resulted in teams understanding each other better which companies enjoy. Another point brought up in Eugene’s post is that code reviews increase productivity. Because the code will be reviewed by someone else  the developer will be motivated to write better code and make sure its flawless. Finally another reason code reviews are essential is that it helps the developer understand the product better and as a result will be able to communicate better .

This blog had great points and helped me understand why code reviews are  so important to when testing. When it comes to myself, sharing code hasn’t always been a strong suit with me because I tend to get nervous when other people view. I understand that I’m not the best and I understand after reading the blog that one of the ways to improve is by having my peers review my code. Feedback is necessary to have successful code reviews. If you’re working on a project with someone else or a team, you would want to make sure that everyone understands your code and how it effects the product, as a result it will improve the team chemistry. In my recent projects that I have had in my, I try to make sure that my code is understandable. Code reviews are a crucial part in testing and with them, the product will be much better than it would be without it.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

Greetings reader!

In today’s blog,  I will be discussing the differences between black box and white box testing. This blog will briefly explain the benefits for each test, as well as point out their distinct features. I will also be sharing my analysis of QATestLab’s-“Difference Between White Box, Black Box, and Gray Box Testing” article from which I read. Without any further introduction, let’s begin.

Black box testing (BBT) is a testing method in which there is no access to the source code or the internal structure of software. The main goal of BBT is to check to see if everything works well from the view of a user.  Black box testing focuses on incorrect or missing functions, data structures errors, any graphical user interface errors, faulty software performance, and for any control flow errors.

Some advantages of black box testing are as follows. First, the tester can start designing test cases just after the specification is ready. Secondly, tests preparation time is short, and finally, there is no need for a tester to know the programming language of the application. The disadvantages of black-box testing: it is hard to design test cases without a specification, only some paths are covered , and it is impossible to to see what part of the code can cause a problem in future.

White-box testing (WBT) is a testing method where there is access to the source code and internal structure of the software (opposed to BBT). This testing type insinutates that a tester knows which code line is called for each function. It allows the tester to better choose an entry data set and to check errors and exceptions efficiently. White-box Testing focuses on bad code writing, conditional loops, the working flow of the code, and memory leaks.

Advantages of white-box testing are: there is no need to wait for the GUI application, it can conduct more detailed testing with more cases covered, and it can predict the potential problems in the software. The disadvantages of white-box testing is that a tester must know the programming language of the software, it can take much more time than other methods, and it can be expensive.

To conclude, there are advantages and disadvantages to both methods of testing, so there is none that is “better” than the other. They are both necessary and complementary.  The QATestLab’s-“Difference Between White Box, Black Box, and Gray Box Testing” article that I read was extremely informative and very easy to comprehend. I greatly recommend their articles to expand your computer science knowledge.

From the blog CS@Worcester – dekeh4 by dekeh4 and used with permission of the author. All other rights reserved by the author.