This blog is about the first pattern in the Apprenticeship Patterns book by Adewale Oshineye and Dave Hoover called Your First Language.

This chapter was about picking your first language as a programmer. Picking your main language is difficult. There are so many languages out there that it is really hard to weigh the pros and cons of each of them. But you have to pick one since obtaining your first job will most likely depend on your proficiency in a specific programming language.

This chapter offers different solutions to this problem. One is to have an actual problem and solve it using the language that you chose. Instead of just following tutorials and examples in a book, solving an actual problem provide your first feedback loop. One other suggestion that they have is to write simple tests to check your understanding of the language. Since test-driven development techniques are so popular nowadays, it is impossible not to find a language that does not have a testing framework. It is a great way of learning how other people’s libraries work. One can always learn about a language and try to be proficient in that specific programming language, but it is still important to find a mentor.

I thought it was interesting how they kind of emphasize on having a mentor for your first programming language. Since we keep using different languages throughout the course, it was hard to find and settle on your first programming language. Not to mention, finding a mentor. Finding my first programming language is still a problem even now. I still cannot seem to settle on one language to master since each of them offers different specialties. This pattern has caused me to change the way I think. Since I always try to learn something new, I never really “specialized” on something. My mind is usually all over the place and I am always trying to learn new things. But, the problem is that I never mastered anything. I always seem to only learn the basics and then move on to different things. After reading this chapter, I want to try and settle on one language try to be better at it before moving on to other things.

From the blog CS@Worcester – Computer Science by csrenz 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/software-testing-seven-principles.html titled “7 Software Testing Principles: Learn with Examples”.

This blog post highlights some useful general guidelines for software testing. In order to write effective test cases, it is important to follow some logical approach toward determining what to test for and how to test it, and this is a guide that describes such a set of principles to follow that are well suited to capture the logic involved in software testing.

The first principle is that exhaustive testing is not possible. I am not sure I believe this. In general it is useful to assume there exists no perfect test, but for simple enough applications where the number of possible interactions are enumerable, I would think that it would be possible to achieve exhaustive testing, much like an exhaustive proof, where every possible path is covered and verified. Maybe I am missing the implausible event that the test is correct but the computer running the tests is corrupted in such a way that certain tests are not run. This is relevant to a point made in this area, which is risk assessment.

The second and third principles make similar points. Always running the same tests will eventually not cover certain issues. If all of the same methods for testing are always applied exactly the same, then eventually there will be some scenario which the particular method is not suited for, and it will miss something. This leads into the later principles: the absence of a failure is not proof of success, and context is important. Developing tests suited for the particular application is necessary to ensure the correlation between tests passing and the program functioning correctly, and just because every test passed does not mean the program is going to work perfectly.

This set of software testing principles can be summarized in a few basic points. Develop test cases that are well suited specifically for the application that is being tested, consider the risk of certain operations causing a failure, and do not assume that everything works perfectly just because every test case passed.

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.shiftedup.com/2015/05/07/five-programming-problems-every-software-engineer-should-be-able-to-solve-in-less-than-1-hour titled “Five programming problems every Software Engineer should be able to solve in less than 1 hour”.

This blog post shares a story about a history of people who apply for the position of a software engineer and claim some loosely related skills without actually having any chance of understanding or performing the job. The frustration of the author is expressed, and the author lists five programming tasks to disqualify any supposed “software developer” who would not be able to complete them in under an hour. I attempted them myself and they only took five minutes.

I am not sure what motivation people have to apply for a job that they are in no way capable of performing, but the author of this blog post seems to be fed up with how common it is. Supposedly, though, people who do not know what programming is are attempting to become software engineers.

I think that the list of five programming problems and the time constraint of one hour is a generous filter to sort out all of the people who have never written a program in any language ever before. It certainly would not be enough to qualify for the position of a software engineer, but that is not what the problems are meant to indicate upon fulfillment, it is simply what they are meant to reject upon failure. Somebody who claims to be a “developer” and fails to accomplish these simple tasks should revisit their resume.

The problems themselves are very basic. Find the sum of some numbers using loops or recursion, combine elements in two arrays, calculate Fibonacci numbers, and the last two problems are more peculiar but still simple demonstrations of basic problem solving. It should be evident in much less than an hour whether a person is capable of solving them, and any experienced software engineer should only need ten minutes.

The blog post acknowledges some feedback about the last two problems that are a bit less conventional than the others, but I think that the ability to solve unconventional problems is important, and I think anyone who writes code in something besides a markup language or an object notation could solve them.

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

Software teams are increasingly facing the pressure of having to deliver quality software while still staying ahead of their competition. Release buggy software and users will be quick to switch away but lack the features your competitors provide and you will have trouble attracting new users. The traditional view of software testing is that the … Continue reading The Problem of Testing →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

SOAP and REST both allow you to create your own API. API stands for Application Programming Interface. It makes it possible to transfer data from an application to other applications. An API receives requests and sends back responses through internet protocols such as HTTP, SMTP, and others. Many popular websites provide public APIs for their … Continue reading SOAP vs. REST →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Developers need a backend framework to create an application with which user can interact and perform some actions (which result in responses). In this context, the backend is defined as the subordinate processor or program (not directly accessible by users), which performs a specialized function on behalf of a main processor or software system. You … Continue reading Discovering Backend Frameworks →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 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.codementor.io/learn-programming/comparing-programming-paradigms-procedural-programming-vs-object-oriented-programming titled “Comparing Programming Paradigms: Procedural Programming vs Object-Oriented Programming”.

Object oriented programming seems to be the focus of all that is ever taught in a computer science course after the basics of syntax and control structures are covered, which are the basis for procedural programming. The shift into object oriented programming seems to mostly be for the sake of establishing proper design principles such as encapsulation and normalization to reduce redundancy, but these are not mutually exclusive features of the object oriented programming paradigm; it is still entirely feasible to write procedural code that is still “good” code.

The blog post does not directly define what procedural programming is about, but it alludes to the writing of straightforward code that makes use of variables, scope, functions and control loops. Then comes the brief anecdote of writing thousand-line long programs that start to become difficult to maintain, and how the object oriented programming paradigm is the solution. Object oriented design is definitely helpful for improving the scalability of a large program by introducing better organizational practices to the code structure, but the principles of encapsulation and modularity can be applied directly to the poorly maintained program anyway without changing paradigms. This is not to say that object oriented programming is bad or unnecessary, but the point is that procedural programming is not bad and does not need object oriented programming to “fix” it. Procedural code happens to be the most common poorly written code because it is most commonly used by beginners, who learn about better coding practices once introduced to object oriented programming.

Some of the faults with object oriented programming are described in the blog post, adding that it is not the best idea to avoid the use of procedural programming for the sake of adopting the exclusive use of object oriented programming. Modularity regarding class extensions and modification of a class can make things difficult in languages that focus on object oriented programming, where overriding a method or re-implementing a class may have adverse effects on subclasses. It is ultimately decided that multi-paradigm programming is a good choice, where the benefits of procedural and object oriented programming can be combined.

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