Category Archives: cs-wsu

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

The first chapter and the next five chapter introductions draw an outline for a general guide to how to learn. The relevance of software development or of the term “software craftsmanship” seems to go away after the first chapter, where the rest is just about self improvement and how to learn. I agree with the points being made in each chapter, but I am also recognizing that these ideas seem to extend to literally every field of study, and not just software engineering. Throughout most of the reading, I was actually thinking about mathematics and not software development, and the ideas apply just the same.

I think that chapter 5 seems to be the most relevant to me. I know that I have learned a lot already, and I am also aware that there is a lot more that I do not know, and even more that I am not even aware of. There is a lot of content to learn about that I find interesting, and I always seem to find that I am preoccupied with other tasks such that I am unable to spend as much time looking into new interesting material as I would like. I started reading the beginning of chapter five just as I was thinking this, and the chapter opens with a quote, directly relevant to that thought, about how there will always be some distraction from learning, so it is necessary to seek knowledge anyway even when the conditions are unfavorable.

I think the idea of “emptying the cup” from chapter 2 is also relevant. Chapter 1 mentions that somebody may recognize that they are at the beginning, as a newcomer to software development, even if they have already been programming for several years. I think it would be likely to have been exposed to some software development projects and practices during the “several years” of programming, so the term “beginner” does not seem to fit very well for somebody with that much experience. On the other hand, somebody who has been actively learning to the extent described within these chapters will definitely have transcended their level of experience. The idea of a “full cup” comes into play when an experienced person is not inclusive of further experience and knowledge. There is the expression about teaching an old dog new tricks. It is necessary, in order to learn, to actually want to learn.

I can see myself applying the principles in these chapters more so toward my mathematical education than my software development education, only because I am more aware of what I do not know in regards to mathematics. I expect that the focus should shift more specifically toward software development in later chapters; knowledge of careers and how software development works on the level of employment is much less familiar to me than the computer science component of software development, although there is still much more to learn in computer science alone.

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

Your First Language

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.

Hello Capstone

Hello, I’m Kristi and I’m Happy to be back for my last semester. I’m going to love the capstone class CS-448!

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.

Post 0

Hello, world

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

CS448 Introduction

This is just an introduction.

From the blog CS@Worcester – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Software Testing Principles

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.

Software Engineer Qualification

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.

The Problem of Testing

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 vs. REST

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.

Discovering Backend Frameworks

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.