Backend Development

I am writing in response to the blog post at titled “What is Backend Developer? Skills to become a Web Developer”. We have begun learning about backend development in the CS 343 Software Construction, Design and Architecture class by studying REST APIs using TypeScript and Angular JS. The blog post gives a general description of backend development and some career-related information like skillsets and average salaries.

Backend development is about defining the behavior and structure of a backend server and/or database. As opposed to the front-end, the backend is not visible to a visitor of a website or application or user of a service. One primary part of the backend may involve a database, where information is stored and retrieved to present to a user. The other primary component of a backend is the server, which is the machine that runs code and handles functionality. APIs are also part of backend development, which are interfaces designed for the purpose of enabling a front-end to communicate with the server.

A backend developer is an individual who creates and maintains the backend. The blog post goes into some detail about what a backend developer is generally expected to do, what their goal is, and also how much they tend to get paid. According to the blog post, back-end developers get paid more than front-end developers. Backend developers tend to the database, server and API for the purpose of supporting the front-end.

One particularly interesting distinction between a back-end and a front-end is that a back-end can be developed independently of a front-end, but a front-end cannot be developed independently of a back-end. It is possible to simply design a back-end for no intended application, and then afterwards build the application around the existing back-end service.

This article is a good summary of what backend development is about and what a backend developer does, and the difference between a front-end developer and a backend developer. Aside from the database management related components of backend development, the given description of backend development is consistent with what it is we are dealing with in class.


Domain Testing

I am writing in response to the blog post/tutorial at titled “What is Domain Testing in Software Testing? (with Example)”. It goes into some detail describing what domain testing is, which is a topic that we have already seen in the CS 443 Software Quality Assurance and Testing class. Domain testing is a type of functional testing, which is a quality assurance process for testing whether the functionality of a system is behaving properly by verifying that certain inputs correspond to the specified outputs.

One thing about the blog post I am not quite certain about is that it refers to domain testing as an important “white box testing method”, which seems inaccurate; the act of checking inputs against expected outputs is independent from the software’s inner workings. Feeding the program an input and checking that the output is correct is a black box testing approach. The clarity provided by a white box would however be necessary in defining the specification itself, methods such as boundary value testing or equivalence class testing require equivalence classes and boundaries to be identified, which would require access to the inner machinations of the software.

Equivalence class testing and boundary value testing are a primary focus of the blog post. Equivalence class testing partitions the set of possible inputs into subsets of inputs that have the same behavior, and boundary value testing tests the behavior given inputs at the boundaries of equivalence classes. The boundary values are particularly useful inputs to test because they are edge cases that are more likely to produce incorrect results compared to arbitrary values chosen within the boundary. If there is an off-by-one logical error then testing the boundaries is what will make it apparent.

I think that this blog post is a good summary of some of the testing methods we have learned about in our classroom activities. It does not go into as much detail or cover more specific varieties of testing such as weak and strong or robust boundary value testing, but it is a short and simple introduction to what domain testing in software testing is about.


This blog titled “Identifying Anti-Patterns” discusses what it refers to “anti-patterns”, a category of common code practices that resemble the organizational structure provided by the use of design patterns, but are actually counterproductive and not a good design. I think that the existence of anti-patterns is interesting; in an effort to write code that is well structured and easy to follow, it is actually made worse. The blog post points out that anti-patterns are most commonly used by programmers who are inexperienced and end up writing code with bad design and bad performance, but it is also possible for experienced programmers to do well in implementing a good design, but at the cost of a significant sacrifice on performance. In general I think it would be common for the implementation of a design pattern to have some performance trade-off with readability and maintainability, so there must be some line as to where a design pattern would become an “anti-pattern” if it were to cause some level of a decrease in performance. Design patterns are commonly used for the sake of scalability so that a program with a well-structured foundation will be easier to maintain as it becomes larger, but these design patterns that are implemented during the beginning of the development of the program may seem like unnecessary anti-patterns that are unnecessarily abstract for the current scope of the program. It may be difficult to identify anti-patterns given that excuses and arguments can be made for why code should be implemented in a certain way. Over-complicating things has an impact on performance, but an organized foundation is well suited for a large project, and re-implementing a lot of code as a project grows would likely be more counterproductive than being careful from the beginning. There definitely are some practices that are objectively wrong, but this blog post does not go into any examples, and it is also possible that what may be identified as an anti-pattern could be a false positive. When there is a trade-off between design and performance, it makes the most sense for an anti-pattern to refer to a mistake that is ineffective in both areas.

(NaN == NaN) == false

In this blog post “NaN is not equal to NaN!”, Dron Rathore discusses the IEEE standard of NaN being a value which is not equal to itself. The blog explains some of the definitions and implementations surrounding NaN. It is not an opinionated blog post, it is mainly for the sake of being an educational resource. My particular interest is the actual reason in the first place for why NaN is defined as not being equal to itself. The result of comparison must be a boolean, so the only options for trying to compare NaN to itself are to return true or false, or error and crash. In mathematics, NaN is effectively “undefined” or “indeterminate”, so something like 0/0 is undefined. The truth value of the equation 0/0 = 0/0 is also undefined; the operation of equality is not defined for values that are not defined themselves unless the operation itself is given additional definition to account for that case, which is what must be done for programming languages so that it results in a boolean value. The choice for that value to be false is peculiar and ultimately seems arbitrary, but it is useful for detecting values that are NaN; if (x == x) is false then x is NaN. This blog post does not directly give any feedback on the reason for this implementation of NaN, it merely describes it, but I would like to get some perspective on how the choice is made and how it is more logical to have NaN not equal to itself over an alternative implementation where it is. Comparisons involving NaN may still result in confusing outputs; infinity > NaN is false, for instance, and so is infinity <= NaN, but “not (infinity <= NaN)” is true. For the sake of software testing, NaN adds a lot of strange edge cases where assumptions about equality lead to contradictions. In these cases, or in any case where it is not okay for NaN to exist, it makes the most sense to just have errors instead of trying to deal with this unique behavior.