Author Archives: kbourassa18

Front End Testing

As my journey to becoming a full stack developer continues, I have begun to encounter the need for front-end testing. When finding an article, I realized that I did not have very much knowledge on what front-end testing entailed or how to implement it into my coding. I found the blog “Front End Testing: A Comprehensive Overview” by Kiruthika Devaraj (https://testsigma.com/blog/front-end-testing/) on my search for information on this topic.

The blog starts off by explaining that front-end testing is focused on the user’s experience. While past experiences have taught me that back-end testing specifically tests the functionality of the code, front-end, also known as the user-facing end of a website, testing has a higher focus on the user’s interactions. The author also delves into eight different types of front-end testing and the elements that make up these different types:

  • Unit Testing is the analysis and testing of the individual components to ensure they each work as intended. 
  • Acceptance Testing involves testing to ensure permissions, such as account accesses, are working properly. 
  • Visual Regression Testing tests for visual changes in the front-end by comparing a reference picture to a baseline image. This can typically create brittle tests that can fail due to the slightest changes in an element’s location on a page.
  • Performance Testing measures an applications stability and responsiveness under different levels of simulated stress and traffic.
  • Accessibility Testing ensures that individuals with visual impairments or other additional needs can still use and access the application to the fullest of their capabilities.
  • End-to-End (E2E) Testing involves testing the application from start to finish while testing all components and systems for how they work together.
  • Integration Testing is when each individual module is tested to ensure it has been implemented correctly.
  • Cross-Browser Testing tests that the application works correctly across multiple browsers and confirms compatibility.

Devarj also provides tips for better front-end testing, the first tip is to always use a testing framework. These frameworks, also called front-end tools, are what actually run the tests. Although countless front-end tools exist, the blog provides information to 3 popular options; Testsigma, Selenium, and Ranorex. Testsigma and Selenium are both open-source front-end testing frameworks that may be worth investigating further, while Ranorexis a commercial framework that may be more than what I am currently looking for. 

Front-End Testing Moving Forward

As I move to implement automated front-end testing into my projects, it is important to remember that the front-end testing is focused on ensuring the project is user-friendly, responsive, and visually appealing by testing the layout, design, and functionality across multiple browsers. Doing so will provide users with the best possible experience.

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

The White Belt Pattern

The white belt pattern focuses on the idea that new situations should be approached with all previous knowledge set aside. The white belt signifies an entry level of knowledge and understanding of a subject, and is only achievable if all preconceptions and past experiences are removed during the learning process. This mental clean slate prevents old habits or patterns from getting in the way of exploring new possibilities when it comes to solving problems.

The more I reflect on this pattern the more I agree with it. However, my opinion felt like it went from agreeing to disagreeing back to agreeing. When in reality, it went from agreeing with some parts, and disagreeing with parts I didn’t fully understand. To eventually gaining an understanding of the pattern that I fully agree with.

Originally agreeing with the overall idea that you should have the mentality of a white belt when learning something new, I disagreed with the notion that all previous knowledge was bad. I, as do many others, learn by being able to take previous knowledge and experiences and relating them to the new situations. This however is the trap that this pattern is actually trying to avoid. The interesting part in this section that made me realize my mistake in my in initial interpretation was the “problem of ‘writing Fortran in any language.’” Not knowing what FORTRAN was, I researched it and found out that I was in fact making this same mistake. Learning a new language doesn’t mean just being able to recreate a simple program. It involves learning all the small nuances and limitations each language has. The only way to explore those is to approach each situation independently and with a clean slate.

My first language was java, and when it comes to learning a new language it is helpful for me to be able to relate things in the new language to elements in java. This turns out to be a trap if you are only looking for 1 to 1 relationships, or you let your old knowledge prevent you from learning something specific to the new language. The more I think back to all my older projects that involved learning in a language that was not java, all I actually learned was the syntax of how to rewrite my code in another language. My understanding of the language or coding in general did not get deeper. Having my previous knowledge acted more as blinders than guidelines, showing me the one way I already knew, but preventing me from seeing other possibilities I didn’t know even existed.

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

Apprenticeship Patterns

As I read through the first chapter of Apprenticeship Patterns by Dave Hoover, Adewale Oshineye the idea of treating software development as a craft makes a lot of sense. I, myself, feel like an apprentice in college seeking to learn from both my professors and peers. Learning won’t stop at graduation as the more knowledge I gain in this field, the more knowledge I realize I am lacking. 

The world of software development is vast and ever-growing, requiring developers to be agile and never be complacent with their level of skills and knowledge. This is something I have always believed.  I however, rarely practice this in my spare time, but now I seek to improve this skill. Chapter 5 relates to apprenticeship patterns for perpetual learning and the notion that you should never be complacent with their level of skill. As I am well aware that my level of skill and knowledge is nowhere near a level where I could even consider being complacent, it is important to start these patterns early so that I remain in the same mindset later down my career. 

The book suggests these patterns should “strike you as unoriginal” and therefore be familiar to us, either by seeing others following these patterns or by us doing it ourselves. Some of these patterns are immediately familiar to me, such as breakable toys, the white belt and your first language, as they are patterns I follow regularly. Other patterns, such as find mentors, read constantly, concrete skills, and many others, are patterns that are familiar but practiced less. 

I think the most interesting concept this book has to offer is simple, yet typically overrated and overlooked; the first thing anyone needs to learn is how to learn. In doing so we discover these patterns, even without knowing it. The more patterns we are able to identify and apply in our work, the more efficient we can learn and grow.

 While there was nothing I disagreed with in the reading, there are patterns that I immediately know I will have a hard time with. Chapter 6 focuses on the importance of reading and curriculum, which is something I personally have never been strong at. Hopefully, with the help of these patterns I will be able to tackle the challenge of learning through reading.

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

YAGNI

“You Aren’t Gonna Need It” is an agile design principle from ExtremePrograming that goes against building code for future features before they are needed. Martin Fowler states in his blog “YAGNI” (https://martinfowler.com/bliki/Yagni.html) how building these features early typically add more time than they save. Fowler breaks down the individual costs of these features and where they add up, along with how these costs vary between three different scenarios. The best scenario is that the presumptive code was still required and added to the project when it was needed. The next scenario is that the feature is scrapped from the project entirely. Arguably the worst scenario is that the feature is added, however, the code that was built in the past was built incorrectly and needs to be updated. These scenarios each have their different costs, but even with the best scenario it is likely time was still lost between deciding to build the feature and when it was finally needed. Assuming that time can be saved by adding a future feature early because it relates to something you are currently doing will only add more work when it comes to debugging, refactoring, and reading the code.

  • Cost of Building – All effort and time programming, analyzing, and testing the feature.
  • Cost of Delay – The time spent on the presumptive feature could have been spent on a more relevant and required feature, creating a delay in the release and actually monetary and time based costs.
  • Cost of Carry – Adding unnecessary code to a project only makes it harder to read and understand, slowing down further production.
  • Cost of Repair – Assuming the feature is eventually added to the project, the way it was built in the past may not be right anymore and needs to be repaired or redone.
  • Cost of Removal – In the event that the feature is scrapped and removed from the project, the code will also need to be removed or will only continue the accumulation cost of carry.

Following the principle of YAGNI means time spent building code should be spent building code that is relevant to the current state of the build. This does not mean that refactoring falls under YAGNI principles as it is time being spent making the software easier to modify.

As projects become larger and more complicated it is important to keep my code clean, organized, and on schedule. The best way to do this is to ensure features are added only when they are needed to not clutter the space with unused code.

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

Clean Code

What is clean code, and how do I make sure my code is clean?  These are the questions I had when first hearing the term “Clean Code.”  In my quest to answer these questions, I found a blog (https://codingsans.com/blog/clean-code) transcribing Karolina Tóth’s interview with Robert C. Martin (Uncle Bob) who literally wrote the book Clean Code.  The main topics covered in the interview are clean code, developer and manager communication, and code ethics.  Focusing on what Uncle Bob has to say on the importance of clean code while including my personal experiences. 

Uncle Bob quotes Michael Feathers saying, “Clean code always looks like it was written by someone who cares.”.   Which makes sense, as I have taken pride in having simple aspects of Clean Code such as clearly named variables and proper indentation in my code blocks.  In contrast, as a tutor, I was asked to review code written with neither of these aspects by a student who openly expected not caring about the class. 

Looking at the functions reveals a lot about the code and how clean it is. Uncle Bob states that you can measure the size of a function, and that going above six lines of code they become too large.  Naming the functions properly will also create cleaner codes as Uncle Bob points out that having smaller and more specific functions will require more specific names.  This combined with the if and while statements will create easy to read code that is close to english.  

Understanding the importance of clean code starts with examining the consequences of having dirty code.  Uncle Bob emphasizes that everything goes slower when you are working with “dirty” code.  Developers commonly believe that quick and messy code is faster upfront, however the slowdown happens a lot faster than most realize.  The example given by Uncle Bob is someone writing bad code in the morning and after a simple lunch break they will be lost in what they wrote.

“Slow is smooth, smooth is fast,” is a quote drilled into my head from my highschool soccer coach.  Take your time with your movements, make them deliberate, and the result will be smooth.  Going slower and executing a move is better than going too fast and failing.  It feels slower to stay disciplined in writing clean code, however the time saved by having easy to read code will immediately and only grow over time.

Listening to what Uncle Bob had to say about the flow of functions and how they should create sentences really sticks with me. As someone who never saw the need for “the flood of functions”, having easy to read sentences in my code will make returning to projects significantly easier.

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

Code Refactoring

As I approach the point in my professional development where my code is going to have to be presented, it’s best that I have my code prepared for the eyes of other people.  This means having clean code, and as mentioned in my previous blog, I am guilty of not using functions to their fullest potential.  To fix that, I will look into refactoring my code with the help of the blog Code Refactoring: Meaning, Benefits and Best Practices By Nuradil Alymkulov (https://maddevs.io/blog/code-refactoring/).  Alymkulov covers refactoring in depth by explaining what refactoring is, why it’s important, how to refactor, when to refactor, different methods of refactoring, and best practices.

Writing code is much like writing an essay.  Essays require going back and rereading the content to ensure it is written correctly and that it flows in an organized manner.  When writing code the first attempt at solving a problem or adding a feature may be functional but, like an essay, could do with revisiting for organization and cleaning up.  Refactoring is revisiting old code and making edits that do not alter functionality but, instead, are meant to help with readability and restructuring.  Having readable code will significantly help in finding bugs.    Doing this will encourage programmers to be more thoughtful with their future code, including these refactoring practices in the initial code.

Code blocks should be easily visible, so a good place to start is proper indentation and formatting.  Another large part of refactoring is removing unused or duplicate code.  Renaming your variables and functions may make unused variables or duplicate code more noticeable.   Variable and function names should make sense and form pieces of a sentence when put together.  Reducing the size of each function will encourage developers to name functions in a way that helps form these readable segments of code.  Once the code is restructured, a final clean up of comments that were needed in that past may be self explanatory due to the renaming of functions.

There have been countless projects that I would think about an additional feature I could add.  Only to never revisit them due to the idea of having to reread my old code before I could even begin working.  After learning the importance of refactoring code I can approach these projects with the mentality that not only will I clean up my code, but I will learn better practices for future code.  Refactoring my old code will prepare it for future features and give me the tools to write better code.

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

Software Licensing

Software licensing is everywhere in the technical world, and for good reason. Without it, our current copyright laws would make it impossible to distribute software in ways that are both beneficial for the user and developer. Fernando Galano does a great job explaining what software licenses are and how they are used in his blog, “Understanding Software Licensing” (https://www.bairesdev.com/blog/understanding-software-licensing/).

In short, a software license is a legal contract between the developers of a software and its users. We, as users, have all been asked to check a box in the past agreeing that we have read and agreed to the terms and conditions.  These terms and conditions are called an end-user license agreement (EULA) and spell out the rights and liabilities of both the user and software provider.

EULAs are typically large documents that contain information on how the end-user may install, modify, copy, or distribute the software. These are the more common things to find, however, they are not limited to this.  EULAs may also specify time of use, pricing, and support. These documents are usually very large because of the extent of topics they cover. 

  • Software under a public domain license can be used, modified and distributed freely with little to no restrictions. Not all free software has a public domain license.
  • Software under a copyleft license may be modified and distributed providing the modified software is distributed under the same terms as the source code.
  • Software under a GNU Lesser General Public License may have its code altered or used in other software and distributed under a different license. 
  • Permissive licenses are open sources licenses with requirements on how users may modify, reproduce, or distribute. This gives developers control over what happens to their code.
  • Typically used for commercial software. Provides the greatest restrictions for users and typically are not allowed to modify, copy, or distribute. 

Quoting the first line from the blog, “Your product could be phenomenal, but before you deploy it, you need to grapple with the legalities surrounding the distribution and usage of your software.” (Fernando Galano).  It is clear to see that without a proper grasp of how software licensing works, development of software can only get so far. The next step in being able to distribute work is to license it properly for its intended use.

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

REST APIs

Diving deeper into exploring APIs I found a great blog on RESTful APIs called “REST APIs: How They Work and What You Need to Know” (https://blog.hubspot.com/website/what-is-rest-api) by Jamie Juviler. Juviler does a great job explaining what makes an API RESTful, why they are useful, how to use them, and provides a few examples from popular  websites like twitter, instagram, and spotify.

Application Programming Interfaces (APIs) allow two software applications to communicate and send data between them. They define how requests and responses will be formatted.

A Representational State Transfer (REST) involves a client sending a request for a resource from a server and the server responding with the current state of the resource. This means responses will vary based on the current state of the resource.

Juviler states there are 5 guidelines an API must follow to be considered RESTful, with one option guideline.

  1. Client-Server Separation:
    • Communication in a REST architecture is only ever initiated by a client. A request is only ever sent from a client to a server, followed by the response being sent from the server back to the client.
  2. Uniform Interface:
    • Every request and all responses must follow a common format. This is through the use of HTTP language. HTTP has become the standard for REST APIs and with it, the use of endpoints. All requests are formatted to contain two pieces, the HTTP method, and the endpoint. Endpoints are used to access specific resources on a server.
  3. Stateless:
    • All communications with a server are independent from each other. A request needs to contain everything required to complete the interaction. There is no memory on the server to store or access previous requests. 
  4. Layer System:
    • Additional systems, like layered servers, may be added for security, but should not alter the format of messages between client and server. Requests and responses should always follow the REST architecture regardless of backend code.
  5. Cacheable:
    • REST APIs allow for caching responses. This means APIs can have larger resources saved on the client for faster access.

APIs are a necessity in the software development world, and exploring RESTful APIs in the future will allow me to develop software that can communicate and interact with software around the world. Understanding the REST architecture will greatly improve my ability to create functional, organized, and scalable APIs.

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

Understanding APIs

As a teen, I remember the first time a video game prompted me to share an achievement with my friends through facebook.  How could a game not related to facebook in any way communicate with the servers to make a post?  Connecting applications together is vital for keeping up with the expanding technical world.  This is done with APIs.

Jason Johl does a great job explaining what APIs are and how they are useful in the real world in his blog,  “What Are APIs, and How Does an API Work?”. (https://blogs.mulesoft.com/learn-apis/api-led-connectivity/what-are-apis-how-do-apis-work/#:~:text=Share%20post&text=API%20stands%20for%20application%20programming,the%20response%20back%20to%20you)  He starts of by explaining the importance of APIs and how they enable speed and agility in software.  Then, gives a great example of how APIs can relate to a real life waitstaff at a restaurant.  Followed up by examples of actual APIs used in booking a flight.  Finally, listing different types of APIs, specifically the Web APIs, which I will be exploring more in detail later.

API stands for application programming interface, and is a messenger between software that handles delivery of the request and response.  Much like how a waitstaff in a restaurant is trained to take a customer’s order to the kitchen and then return with the food.  Kitchens take orders a certain way and it is the waitstaff’s job to translate the customers order into a format designed for the kitchen. Customers can’t interact directly with the kitchen, and must use the waitstaff to handle the requests. 

Travel sites are a great way to visualize APIs in work and how they are useful.  The travel site collects information from a user on the client side and is able to take that information and search all different airlines databases to compile available flights.  To do this, the client, in this case a web browser you are using to access the site, sends an individual request to each of the airlines servers through the use of an API.  Then, the API in the airline servers takes that request, and returns all flights that match the fields such as dates and airports.

APIs can be designed and used for any software such as Java APIs allowing two objects to communicate with each other.  In most cases, I will be working with Web API’s that communicate between a client and server.  The most common Web APIs are Representational State Transfer (REST), Simple Object Access Protocol (SOAP), and Remote Procedure Call (RPC).

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

Scrum VS Kanban

The first step down my professional development path to become Agile involves understanding different Agile methodologies. The two most popular being Scrum and Kanban. Cassidy Knight does a great job comparing the two Agile methodologies in her blog, “3 Differences Between Scrum and Kanban You Need to Know.” (https://www.cprime.com/resources/blog/3-differences-between-scrum-and-kanban-you-need-to-know/) Knight starts the blog off with an easy to read table illustrating the three main differences are found in team roles, work boards, and the scheduling/cadence of the workflow.  She breaks down Scrum and Kanban individually for better understanding of how they are similar, before diving deeper into the three differences.  The blog finishes up with explaining that there is no clearly defined better methodology, but rather that they each have things that work better for different teams. 

Scrum consists of breaking up large projects into small manageable tasks to be completed through several scheduled iterations called sprints.  During these sprints the Scrum Team, consisting of a Product Owner, Scrum Master, and Developer work together to design and build new features for a project.  Each new feature is broken into story points that are prioritized by the Product Owner in the project backlog.  The Scrum Master then selects what points will be moved to the sprint backlog to be worked on in the following sprint based on the priority and size of each point. 

Story points are tracked through the sprint on the Scrum board. The Scrum board breaks down workflow into columns, starting from the backlog, to work in progress, to completion. Each story point is given a limited amount of time to be worked on during the sprint. Scrum boards only show the work done for that sprint and are wiped clean after each sprint. Work produced by a Scrum team is evaluated at the end of the sprint and is found successful if all of the story points have reached the team’s definition of done.

Kanban, unlike Scrum, does not work in scheduled iterations.  Instead, the workflow in a Kanban is limited by the amount of story points in each column of the work board.  Instead, each team may be made up of specialists that only handle work from the board that suits them.   The work board in a Kanban is like the one found in Scrum with the major difference of each column having limits to how many story points may be in each.  This means a “work in progress” point must be finished before a new one may be opened.

Using Scrum and Kanban Moving Forward

As I continue to learn how to work in agile environments, I will learn what parts form each of these methodologies that work well for me and my team.  Applying practices from many methodologies to create a hybrid methodology may be the best way to move forward. It all depends on the project and the team.

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