I am writing in response to the blog post at https://blog.codinghorror.com/your-code-oop-or-poo/ titled “Your Code: OOP or POO?”

Most of the code I have ever written has been founded in the imperative programming paradigm. I began pulling concepts from object oriented programming in the last few years to help organize large projects and keep the structure of things more adaptable. It is a useful way to develop a large framework, but relying on objects for absolutely everything seems like it would tend to cause a lot more problems than it would ever be meant to solve.

This blog post refers to “POO” as “Programming fOr Others”, as opposed to plain Object Oriented Programming (OOP). One of the purposes of object oriented programming, and one of the reasons it is such a dogmatically adhered-to convention, is that it makes it a lot easier for people who did not write the code to understand what it is doing and work with it themselves. The blog post discusses on the topic that object oriented programming can be over-used, and it is not the only solution to writing code that is readable and easy to be understood by others.

There was an excerpt about how there was a type of programmer who would only write five or ten lines of code, preceded by twenty lines of comments, and object oriented programming basically allows the two to be combined. Instead of concise code accompanied by an explanation, there is a large file filled with descriptive language embedded into the structure of the code itself.

Another excerpt mentioned the use of object oriented programming for trivial tasks. I do not think that it makes any sense to go through the effort of supporting scalability and maintainability for something that can be started and completed and discarded so easily without the extra work. A simple command line in an imperative programming language would be far more practical for basic tasks.

Part of the argument made is that a programmer should focus on the principles of object oriented programming, rather than the name. Encapsulation, simplicity, code re-use and maintainability are the main ideas, not just objects.

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

I am writing in response to the blog post at https://www.guru99.com/grey-box-testing.html titled “Grey Box Testing: Process, Techniques, Strategy, Challenges”.

Grey box testing, as the name suggests, is meant to be a combination of black box testing and white box testing. In white box testing, the internal structure of the code is known, and in black box testing, the structure of the code is unknown, and in grey box testing, it is partially known. Grey box testing combines the benefits of black box testing and white box testing, combining the input of developers while testing from the perspective of a user.

An example of grey box testing is given where a tester is testing a website and something is wrong with the HTML code, so the tester is able to look at and make changes to the code themselves to continue testing. A few other types of testing are listed as qualifying as being in the category of grey box testing: matrix testing, regression testing, orthogonal array testing, and pattern testing. These methods follow the strategy of black box testing while integrating some white box testing practices to focus more on what the test cases should be looking for.

A sequence of steps is provided for how to perform grey box testing. The first two steps, identifying inputs and outputs, do not seem to be directly related to black box testing or white box testing alone. In black box testing, there would be no need to explicitly identify the inputs and outputs; they would already be given in the test specification. The creation of the specification does require access to the code, which relates to white box testing, so grey box testing in this sense seems like a real-time testing approach where there is not necessarily a pre-developed specification and learning about the environment is a part of the testing process.

Challenges in grey box testing that are listed include when a test executes and the result is incorrect, and when something being tested encounters some failure. These do not really sound like challenges, they seem to just be examples of what testing is for.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

I am writing in response to the blog post at https://9clouds.com/blog/premature-optimization-the-root-of-all-evil/ titled “Premature Optimization: The Root of All Evil”.

Premature optimization is about focusing on making sure the code will be able to run as fast as possible before anything actually works yet. It is time consuming and, by definition, “premature”, so it is not a good thing to do. The blog post quotes Donald Knuth who said “Premature optimization is the root of all evil.” For sizable projects, premature optimization is practically procrastination. It is about making sure that the program works well in theory before making sure that it works at all. The blost post seems to be referring to premature optimization on the scale of businesses, where I am only considering the effect on individual programs and projects, but the effects are the same. It makes more sense to finish something that works and then improve it than it does to improve it first and then finish it.

I have done a lot of premature optimization on small projects, and it certainly does take up a lot of time. I tend to do it just because it is interesting, though, to try to come up with such an implementation that performs optimally. It is a secondary challenge that puts off the original task. If it becomes tedious or starts to seem wasteful then I just write something that works and move on to the next part, and if it matters or makes a difference, and it never does, I can just look into how to make things faster again. The idea of actually producing something in a professional sense and becoming caught up in the performance details on a small scale before the rest of the product is finished definitely seems like it would be a waste of time. Premature optimization requires making predictions of how things are going to work after they are made, and devising a plan to make things fit together smoothly before the things even exist yet. It makes much more sense to make the things first, and then make them work together better afterwards.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

I am writing in response to the blog post at https://www.guru99.com/back-box-vs-white-box-testing.html titled “Black Box Testing Vs. White Box Testing: Key Differences”.

Black box testing and white box testing are topics that we have covered in the CS 443 software quality assurance and testing class. Black box testing involves testing from the perspective of a user, who does not have access to the code, and thus the testing is done without referring to the code. Instead, the behavior is tested directly by checking inputs against expected outputs. White box testing involves code coverage and testing different branches and paths of code based on the code itself and not a pre-defined specification for the behavior to meet.

The blog post provides a table of comparisons between black box testing and white box testing. Most of the points are that black box testing is done without access to the code and white box testing focuses on the code. One of the points made is that black box testing is not good for testing algorithms. This makes a lot of sense, and for certain algorithms, black box testing would be impossible to do. Black box testing requires some specification for the behavior of the program to meet, and that specification is supposed to cover everything that might go wrong with the program. This is fine when the program is made up of a set of conditional branches, but something more intricate like a computational geometry or machine learning algorithm would be impossible to test every case for because the number of different paths the code can take is on a completely different scale. White box testing in this case would be the only way to check that the algorithm will work, and that is by proving that it works. The only way black box testing could prove correct behavior would be with an exhaustive proof.

White box testing is not necessarily as easy or convenient as black box testing because it requires understanding and analyzing the code instead of just running it and seeing what happens. In some cases, though, it is necessary to use.

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

I am writing in response to the blog post at https://www.guru99.com/difference-information-data.html titled “Difference between Information and Data”. This is a topic that was covered in my Database Design and Applications class, but it is still a useful distinction to be familiar with for the purposes of software testing.

The blog post firstly individually defines data and information. Data is defined as a raw, unorganized collection of numbers, symbols, images, etc. that is to be processed and has no inherent meaning in and of itself. Information, on the other hand, is defined as data that has been processed, organized, and given meaning. My general understanding of the difference between information and data is that data is information without context, and that seems to be consistent with what how the blog post is explaining it.

There is a long table of contrasting descriptions of different attributes of data and information listed on the blog post; data has no specific purpose, it is in a raw format, it is not directly useful and has no significance, whereas information is purposeful, dependent on data, organized and significant. One particular property is labeled “knowledge level”, where data is described as “low level knowledge” and information is said to be “the second level of knowledge.” I have never considered “levels” of knowledge before, this seems to suggest that there are multiple additional categories. It later mentions “knowledge” and “wisdom” as additional categories. DIKW (Data Information Knowledge Wisdom) is explained, which is something I have never heard of before. It is a model used for discussing these categories and the relationships between them. An example it provides lists an example value for data as “100”, information as “100 miles”, knowledge as “100 miles is a far distance”, and wisdom as “It is difficult to walk 100 miles by any person, but vehicle transport is okay.” These additional levels of knowledge seem to further process and contextualize the information. I think that it would have been interesting if it expanded further on these topics and how things like knowledge and wisdom are significant independently from data and information, and whether further levels of knowledge exist even beyond that.

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

I am writing in response to the blog post at https://www.guru99.com/typescript-vs-javascript.html titled “Typescript vs JavaScript: What’s the Difference?”. This is particularly relevant to our CS 343 Software Construction, Design and Architecture class because our final projects are written using Typescript.

The blog post starts out by describing what JavaScript and Typescript are. JavaScript is described as a scripting language meant for front end web development for interactive web pages, and it states that it is not meant for large applications – only for applications with a few hundred lines of code. I think the google home page source code would like to disagree with that, with its thousands of lines of condensed minified JS code running behind its seemingly plain surface, but given the speed of JavaScript in relation to faster languages, it makes sense that it was never actually intended to be used for large applications. The blog post moves on to explain what Typescript is about. Typescript is a JavaScript development language that is compiled to JavaScript code and provides optional typing and type safety.

A list of reasons why to use JavaScript and why to use Typescript are provided, but they are not in opposition; the reasons to use JavaScript are not reasons to not use Typescript, they are really just descriptions of JavaScript. JavaScript is a useful language, and Typescript is a useful extension of JavaScript. After a history of the languages are given, a table of comparisons is provided. Typescript has types and interfaces, JavaScript does not. Typescript supposedly has a steeper learning curve, but given that plain JavaScript syntax will work when writing Typescript, the learning curve does not seem steeper necessarily, only longer, given the additional functionality that is offered by Typescript. Similarly, Typescript not having a community of developers as large as JavaScript’s seems to not be significant given that a programmer writing in Typescript may gain just as much utility from the community of JavaScript developers as the community of Typescript developers, given how similar the languages are. An interesting factoid at the end is that Typescript developers have a higher average salary than JavaScript developers, by about a third.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

I am writing in response to the blog post at https://www.guru99.com/difference-compiler-vs-interpreter.html titled “Compiler vs Interpreter: Complete Difference Between Compiler and Interpreter”. A compiled language is a language that requires a compiler to convert it into another language or format, like bytecode or native machine code. An interpreter translates the program to machine code as the program is running.

The blog post describes a compiler as a program that translates code into executable machine code before it is run, and an interpreter as a program that translates each statement into machine code when it is run. I think that this description is somewhat of an over-simplification. For C, compiling a C program means translating it into an executable program, which is comprised of machine code that is native to the platform it was compiled for. Compilation in general does not always refer to this particular process, though. A compiler may exist to compile one language into a different language, or even into the same language. The key is that the resulting compiled program is semantically equivalent to the original source code. If an interpreter existed for both programs then the result of interpreting the original program should be the same as the result of interpreting the compiled program.

Another detail that was not addressed by the blog post is the concept of “just in time” compilation. C programs are compiled “ahead of time”, where the code is compiled into another program before it is run. Instead of doing this, just in time compiling occurs in run time and compiles blocks of code as the program is running. This allows for a different perspective for an optimizing compiler to make the program run faster in instances that would not be possible for an ahead of time optimizing compiler that does not run in run time. Java is one such language that uses just in time compiling. The blog post does mention one detail about Java, and that is that it is both compiled and interpreted. Java is compiled into bytecode, which is portable because it is not specific to one platform’s native architecture, and then that gets interpreted into native machine code by the JVM when it is run.

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

I am writing in response to the blog post at https://www.guru99.com/full-stack-developer.html titled “What is Full Stack Developer? Skills to become a Web Developer”. A full stack developer is somebody who is able to work in both front end and back end development. We have worked with back end development in CS 343 with our work in REST APIs, and we have also worked with front end development using Angular JS and TypeScript. Full stack development involves writing both ends.

The blog post describes a full-stack web developer as somebody who can work on both the front end and the back end of an application. It provides a tiered model of application layers that the developer should be familiar with: the presentation layer, business logic layer and database layer. We have briefly discussed the concept of a layered application model in class before. The presentation layer is the front end that handles the user interface, and the business logic layer and database layer correspond to the back end.

Some average income statistics are provided in the blog post, which shows that a “back end developer” earns more on average than a “full stack developer”, which seems counter-intuitive because a full stack developer, in theory, is capable of accomplishing the same tasks as a back end developer and more.

A clarification is made about the expected duties of a full stack developer; a supposed myth is that a full stack developer is going to be writing all of the code by themselves, writing both the front end and back end for a single large application because both jobs are within their skill set. In actuality, it is not the job of a full stack developer to produce everything alone. The blog post describes a full stack developer as a sort of a bridge between front end developers and back end developers who are working on the same project, because the full stack developer has a good perspective of both ends and how they interact with each other. In this sense, it is clear that a full stack developer in a development team is particularly beneficial for communication.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

I am writing in response to the blog post at https://www.guru99.com/what-is-backend-developer.html 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.

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

I am writing in response to the blog post/tutorial at https://www.guru99.com/domain-testing.html 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.

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