Backend development is the server side of a website. This is everything that the users of the webpage do not see. Backend is mainly focused on databases, APIs, and Servers. In order to help the website, communicate the data being used, programmers who are backend develops write code in order to store data from the webpage into databases. The code written can be read, updated and deleted from the database.

An example of this is when you create an account on amazon. When you click ‘Create Account’ is takes all the information you just submitted, processes that data and stores it into a database. Amazon now have the details you shared into their database. However, you didn’t see it happen because it happened behind the scenes. This is what happens in the backend of the webpage. This is just the beginning of the backend.

Since we mentioned backend developers, lets go into depth on what they do. Backend developers are responsible for building the structure of a software application. Unlike frontend developers who mostly uses only three tools such as HTML, CSS, and JavaScript. Backend developers uses various tools such server-side languages, databases, and servers. Some server-side languages could be Java, Ruby, NodeJS, and .NET. These languages are what most backend developers use to create codes that help the backend of the website work. Databases and servers that are used could be MYSQL, Oracle and SQL server. Databases and servers are where the data from the websites get stored, such as addresses, emails, and any other kind of useful information for the customer or what the website may have. To become a decent backend developer, the skills you must have knowledge of programming languages, and how to use databases, servers, and APIs.

The reason why I chose to write about backend development is because I have an interest in it. I eventually want to become a full stack developer and that means I will have to know both front end and back development. As technology gets more advance, there will be more need for individuals who process such skills. Not only that but I plan take my skills further and someday develop my own websites and other useful applications.

A blog I found that I would recommend is: https://www.interviewbit.com/blog/backend-developer-skills/. This website contains a lot of useful information on backend development for those who are interested in where they should start and understand what it takes on becoming a backend developer.

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

HTML which is also known as ‘Hypertext Markup Language’ is a programming language used to describe information you may find on a web page. When used with CSS and JavaScript, these three makes up the essential foundation of any website found worldwide. A website may be broken down into three components. First, we have the page’s appearance which is made with CSS. CSS is also known as ‘Cascading Style Sheets’ is used to design the appearance of a webpage. This allows you to set things from the size and font of texts shown, to the color of the page, and so on.  Then we have the functionality of the page using JavaScript. JavaScript is a language used to program the page. For example, if you were to click on “shopping cart” on amazon, this would navigate you to a page that were to show you what’s in your cart that you want to buy.  Lastly, we have what some call the ‘bones’ of the webpage. This is where HTML is used.
CSS is known as ‘Cascading Style Sheets’ is used to design the appearance of a webpage.
When designing a webpage, many contains important information that may recede in headings, paragraphs, or many other types of data. HTML is used to specify what kind of information goes into these types of things on a webpage. This type of work is mainly used by Front-end developers. These developers use HTML language to code different things that relates to the overall structure of the page.
HTML is something every website uses no matter what browser you use. From social media web pages like Facebook and Google, to web players like YouTube or Spotify. If you were to look at the coding behind done for these pages, you would see that they all use HTML. That’s why HTML is important.
To become a front-end or full-stack web developer, HTML is a good place to start off with. Combine HTML with CSS and JavaScript will provide you all the necessary to create an interactive webpage.

A blog I would like to share is https://www.theblogstarter.com/html-for-beginners/. This blog has a lot of useful information about HTML and if you’re looking into become a front-end developer or a full-stacked developer I highly encourage it!
I chose to write about HTML because I am highly interested in learning full-stacked development. I think it will be very useful in the type of career I will choose once I graduate from Worcester State University. Another reason why I chose to research and write about it, is because it is on our syllabus, we will be learning about front-end development, so I thought it was appropriate to talk about HTML.

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

Summary:

This article starts off by explaining what software scoping is and that doing it well will help establish requirements and expectations between the customer and user, reduce friction during the development process, and help outline budget and timescales. Agile is well suited to support processes because it encourages you to establish high-level requirements first, and finer details later. The article continues by going into certain topics such as how to facilitate engagement, the drawbacks of a highly detailed initial scope, adapting to change, and preventing project creep. Scoping software projects the Agile way means developers can concentrate more of their time creating fantastic code, and business stakeholders have peace of mind that their organization is taking full advantage of the latest digital opportunities.

Reason:

The reason I chose this article is because I know that in software development, we must learn how to create applications in an efficient and straight forward manner. I know that it is difficult to measure the amount of effort it may take to accomplish a task as well as unexpected challenges that might occur. The importance of a well-run team allows for applications to be developed to the best of its abilities.

What I Learned:

I learned that Agile principles help instill a certain level of discipline early on to support the development of software. The agile methodology focuses on a highly detailed initial scop but that doesn’t mean it’s always the best. In doing something so highly detailed, you consume valuable time, create unnecessary delays, there may be a lack of budget clarity, and may be complicated by organizations that don’t know what they need. A lot of the time you don’t know what is going to happen so a team need to be equipped to tackle those issues and agile is built for it. Agile helps absorb negative impact of change by incorporating it at the scoping stage and throughout the rest of the project. Project creep is also something that occurs and that is when the work requirements begin to inflate after a project has begun. With the agile approach, it helps diminish project creep by not being distracted beyond the immediate horizon, like-for-like workload swapping, and contingency tolerance. Not being distracted allows for a developer’s understanding of future stages in a project to remain loosely defined as long as it is practical even with changes to the cope. Like-for-like workload swapping is the last minute desire to abandon requirement X while simultaneously prioritizing the creation of a new requirement Y. A contingency tolerance is when Agile tricks have been exhausted, there is essentially an emergency fund of time that can be dipped into so that the project timelines stay on track.

Source: https://developer.ibm.com/articles/d-scope-software-agile/

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Welcome to my blog, here you will be able to follow my journey about the things I learn and the projects I will be working on. As an aspiring software engineer, this blog will be able to show employers and others not only what I am capable of but the also how much fun I have coding the things that I want.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

After a piece of software, whether that be the project as a whole or simply one component as part of a system has been completed, it makes sense to give the final product a sort of “look-over” to make sure that everything is working as intended and meets any required specifications. This is something which generally seems to be good practice to follow anyway in my opinion, since it could be easy to overlook something during the development process. It can be easy to become hyper-focused on one thing or another when working on larger projects with multiple components, which could lead to the potential to forget or leave-out some minor (or major) requirements, introduce bugs or flaws, or otherwise implement things in a way which is inefficient or ineffective.

This is where the more formally defined process of “Code Review” is beneficial. While looking into the process, I found this helpful writeup from Atlassian: (https://www.atlassian.com/agile/software-development/code-reviews) which goes into great detail regarding the practice. Overall, the process involves looking for any clearly visible bugs or issues with the code, as well as considering logic errors and concerns. The finished code/components is compared to the requirements of the project, and any test-cases or testing methodologies used are evaluated (how complete is the test coverage, should any new tests be added?). Additionally the code is compared to preexisting code (referred to as “style guidelines” in the post by Atlassian) which exists within the same space or project to promote consistency and cohesiveness.

Compared to the process I described earlier, the formal definition of Code Review provided by Atlassian hits many of the same key areas. The finished piece or product is examined in relation to any requirements, testing/test cases are examined to determine coverage and whether any additional tests are necessary, and bugs, errors, or logical flaws are sought out and fixed where they have occurred. I would say that the last point regarding “style guidelines” is less important, especially in solo-development environments where you might not be working in a team. Regardless it still seems like a good thing to keep in mind when working in larger group applications. Code review is a helpful and largely effective way to take a second look after the main development process is complete and make sure that the final product is what it was intended to be.

Article Referenced:

https://www.atlassian.com/agile/software-development/code-reviews

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

When working on a piece of software or project, often I will encounter a point where some particular piece of the program cannot be tested properly due to one or more components or features not being completed yet. Rather than waiting until all these things are completed, and potentially rushing them to completion in order to do testing, mocking allows me to bypass the issue and use a “mock” version of the missing dependency or component needed for testing.

This is a convenient way to get around having to develop the entire program all at once before being able to test anything, which could arguably lead to more errors or issues over time since you then aren’t able to test as you implement features, but rather only after they have all been implemented. This aspect alone makes mocking seem like an overtly beneficial concept. But there are some drawbacks to consider with mocking, some of which I will discuss below.

When researching the concept of mocking, I found this article: (https://www.accenture.com/us-en/blogs/software-engineering-blog/to-mock-or-not-to-mock-is-that-even-a-question) to raise some good points in regards to both the upsides and downsides of the practice. The author of this blog post brings up three major downsides to mocking, those being that a.) mocking can violate the DRY principle (https://thevaluable.dev/dry-principle-cost-benefit-example/) ‘Don’t Repeat Yourself’, b.) mocking can complicate refactoring or reorganizing code, c.) mocking can add to the complication of your code in general.

In regards to the first issue, repetition, I think that in some cases that this can be justified, and while mocking does represent some duplication in that it is taking a preexisting piece of the program and creating a placeholder for it, this seems unlikely to have the same negative effects that say, having three different train classes which only differ in the value of their color attribute.

The second and third points regarding refactoring and complication of the program seem like legitimate pitfalls to watch out for. When restructuring, the various mocks present could no longer be applicable based on changes in the location of various dependencies and test-cases in relation to them. Mocking does introduce an additional layer of complexity which would not otherwise be present, definitely a fair concern to consider.

Overall, I would say that most of the issues associated with mocking which are described by the author can be mitigated or completely avoided provided that they are considered during development. Mocking still seems in general to be a benefit in relation to testing during development rather than after it has been feature-completed.

Articles Referenced:

https://www.accenture.com/us-en/blogs/software-engineering-blog/to-mock-or-not-to-mock-is-that-even-a-question

https://thevaluable.dev/dry-principle-cost-benefit-example/

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

Recently I was introduced to JUnit 5 as a testing framework for Java programs, mainly for the purposes of one of the courses I am taking currently. While I have in the past used methods such as print statements (to test for expected outputs and debug) or using the built-in IDE debugging functions (breakpoints mainly), this was often time-consuming and not easy to scale. When trying to test for a number of different conditions or desired results from a section of the program, I would often end up writing conditional logic just for testing purposes which would end up getting deleted later on in the finished program.

JUnit seems like a relatively logical progression from this process, instead of writing numerous checks and conditional statements into the working code of the program, test classes can be used to rapidly test many different conditions or input/outputs at once. This allows for me to keep the main code of the program neater and to avoid the time consuming process of having to continually write tests or print out values in order to test that everything is functioning properly. JUnit overall is a more efficient way to go about the process.

In the past, I had used an older version of JUnit (JUnit 4) to test an older project from a number of years ago. I found this blog post from Java Magazine (https://blogs.oracle.com/javamagazine/migrating-from-junit-4-to-junit-5-important-differences-and-benefits) was able to highlight many of the major changes and differences between JUnit versions 4 and 5 clearly. Generally, JUnit 5 differs the most in it’s organization into various modules, while older versions of the framework would include all features irregardless of which ones might actually be needed at the time.

Additionally, more recent Java features such as lambda functions (absolutely useful within the context of running tests) make this version of JUnit more powerful than earlier editions.

I would consider JUnit 5 to be one of the better options at present for testing and debugging Java programs and will likely continue to utilize this framework until it inevitably sees a version 6 release.

Article Referenced: https://blogs.oracle.com/javamagazine/migrating-from-junit-4-to-junit-5-important-differences-and-benefits

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