For this weeks Blog Post I will be looking into the pattern known as “Study the Classics” where one is but to study the classics. The context behind this one is that you are self-taught or valued skill training over theory. The problem that would arise from this could be experienced people collaborating with you are constantly referencing concepts that they have assumed you read. But since you are value practice over theory you may have skipped over this reading/research. This will of course cause some problems, perhaps nothing serious but will lead to some confusion between the two parties. A solution to this is go back and study the classics if you will. If you were to pick up a book and think how old or out of date this book is, then you are probably reading the wrong kind of book. Successful apprentices will tend to focus on long lived books (classics) and use the internet or through practice to see how the information has evolved exactly. A classic they give in the excerpt is “The Psychology of Computer Programming” while this is “dated” wit h its punch cards and room sized computer parts the book was non the less relevant with is wisdom. Classics portray vital information to keep you heading in the right direction down on the Long Road, another apprenticeship pattern. By just focusing on classics you may take it to far and abandon more pragmatic knowledge and information that would enable you to improve your day to day craftsmanship. A simple remedy to this is to just mix the classics with modern, pragmatic books and/ or articles to your reading list. A way for this to act is simply pick up the oldest book in your pile. Or if you are looking through another developers book, take not of the oldest books and ask them why they still own them, sparking a conversation relevant to its wisdom it gave. Overall this is something I see myself doing down the road.

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

Read Constantly is a brief section, but it is an important apprenticeship pattern. Read Constantly is what it says. You need to constantly by reading and introducing yourself to new information in order to learn new ideas and improve. Most of the learning you do is from reading, whether its from sources on the internet or chapters of a good programming book. The more often you read and the better reading skills you develop, the better off you will be.

There is a book out there for every different programming language, every concept, every challenge you will come across in your professional career. I am currently reading a book that discusses the whiteboard problems brought up during many coding interviews. The book is long, and the content inside is dense, so it is important to read it carefully, take notes, and read it again to be sure of the information. That is my usual strategy for reading information that I need to learn.

My biggest challenge with reading constantly is feeling like I’m not absorbing all the information because I’m just trying to get through it. That’s why it is always good to do exercises in the book, if any are provided. That way you can do practical work alongside the reading that helps break up the monotony of reading and also gives you a different way to learn the content.

Another good strategy I use when reading is to take notes. There are often ways to boil down a text to its essential parts and the things you need to focus on and remember. Keeping notes, highlighting key lines, and keeping track of answers to exercises is a good way to maintain a reference if you ever want to brush up on what you just read.

Read Constantly is an important pattern when you want to learn something new or build a new skill. Good reading habits can open the way to learning lots of new things in a short period of time. It is absolutely the best way to learn quickly, especially if you are an independent person.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

On this Software Development Capstone journey part of my assignment is to choose 10 Individual Apprenticeship Patterns out of 35 patterns among Chapters 2-6 from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsmanby Dave Hoover and Adewale Oshineye. For my seventh individual Apprenticeship pattern I have chosen to do “Retreat into Competence”.

Summary

There will be times, where you will feel completely over whelmed because you have taking on more than you can handle. Feeling over whelmed can be caused by other circumstances like having lack of knowledge and/or lack of understanding on just about anything regardless of complex level. Using the “Retreat into Competence” pattern is a good solution for this dilemma, even if  this solution is only a temporary solution. This pattern suggest that when you are way over your head the best solution is to take two steps back in order to be able to take 10 steps forward towards the right directions. The way the book puts it is to “Pull back, then launch forward like a stone from a catapult. Retreat briefly into your competence to regain your composure.” We must understand that to use this pattern we must set a time limit to our break or however long we choose to take a break. The reason is that if we take to long we can get stuck and never end up moving towards our true end goal. Another suggestion given is to seek guidance from your mentors because with their help and the new information you had picked up from your past experience will help you “be better equipped to handle the inevitable bumps on the road when you try again”.

My Reaction

This pattern helps you understand the importance needed to retreat into competence in order to have a clearer mind that can help you solve whatever, issue you might be facing at the moment. I agree with this idea because I found this pattern to be interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think because it has made me realize that I should not panic if I do not know something but instead I should be taking steps back to see the big picture in order to be able to move forward and handle the situation I was presented with.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Hello dear readers. Welcome back to my blog. As we know by now most programming language support and encourage object-oriented programming and in this blog post we are going to talk about the principles of the Object-Oriented Programming. The key design principles of Object-Oriented Programming are:

Abstraction – is the idea of simplifying a concept to its bare essentials in some context. It allows you to better understand the concept by stripping it down to a simplified version. Your abstraction should be intuitive.

Encapsulation – can be thought of as putting something inside a capsule. In software, restricting access to inner objects and properties helps with data integrity. Encapsulation makes your classes easier to manage, because you know what part is used by other systems and what isn’t. This means that you can easily rework the inner logic while retaining the public parts and be sure that you have not broken anything. A disadvantage of it is that working with the encapsulated functionality from the outside becomes simpler as you have less things to think about.

Decomposition – is the action of splitting an object into multiple separate smaller parts. Spitted parts are easier to understand, maintain and program. There exist three types of decomposition relationships: 1. Association, which defines a loose relationship between two components. They don’t depend on each other but work together. 2. Aggregation, which defines a weak ‘has-a’ relationship between a whole and its parts. The parts though can exist without the whole. 3. Composition, which defines a strong ‘has-a’ relationship where the whole and the part can’t exist without each other.

Polymorphism – is the ability for data to be processed in more than one form. It allows the performance of the same task in various ways. It also consists of method overloading and method overriding.

Inheritance – is the ability of one class to inherit properties of another class, called the parent class. We can inherit properties from other classes s well.  So, when we create a class, we do not need to write all the properties and functions again and again, as these can be inherited from another class which possesses it. Inheritance allows the user to reuse the code whenever needed.

Design principles are rules in software design that have proven themselves valuable over the years. Just like any other ‘game’ even when we code we need to know and follow the rules. This is the main reason why I choose to write about the principles of Object-Oriented Programming.

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

Anders Hejlsberg is known as the creator of TypeScript. On 2010, he and his team began developing TypeScript, and in 2012 they released TypeScript 0.8 for the first time. There were several versions of TypeScript released since 2012. The last version announced is TypeScript 3.2 RC, which is the release candidate of the next version. According to Anders Hejlsberg, JavaScript is TypeScript, but TypeScript is not JavaScript, which makes TypeScript a superset of the JavaScript language. That means that any valid JavaScript code is also valid TypeScript code.

TypeScript has additional features and does not exist in the current version of JavaScript, supported by most browsers out there. In TypeScript, we have this concept of strong or static typing. If you have worked with languages like C# or Java, you know that in these languages when we define a variable, we need to specify the type of that variable. In TypeScript typing is optional so we don’t have to use this feature. But using this feature makes our applications more predictable and it also makes it easier to debug them when something goes wrong. Typescript also brings Object-oriented features that we have missed in JavaScript for a long time. We have the concepts of classes, interfaces, constructors, access modifiers like public and private, fields, properties, generics, and so on. Another benefit of using TypeScript is that with TypeScript we can catch errors at compile time instead of the runtime, of course not all errors but a lot of them. There is a compilation step involved, and when we compile with TypeScript code, we can catch these errors and fix them before deploying our application. And finally, another benefit of using TypeScript is that we get access to some great tools out there. One thing that I personally love about TypeScript is the autocomplete suggestions that we get in our code editors as we are coding, like Atom and Visual Studio Code.

TypeScript is a beautiful language but the browsers that we use every day don’t know TypeScript, and it is very unlikely that the browsers are going to support TypeScript in the future. So, we need to compile or more accurately Transpile our TypeScript code into JavaScript code.  This is part of building an application. Whenever we build an application TypeScript compiler kicks in and it Transpiles TypeScript code into JavaScript code that browsers can understand.

References: https://en.wikipedia.org/wiki/TypeScript,

https://channel9.msdn.com/posts/Anders-Hejlsberg-Introducing-TypeScript,

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

As I take another step towards my journey in software C.D.A. I dive into REST APIs. Where I will be talking about the YouTube video I found “APIs|REST|REST APIs Demystified” from The TechCave. For this weeks blogs I am going to try things different. I will give a very short summary of what the blog talks about and if you are interested in the topic I strongly suggest watching the video it is very interesting and on point to the topic. The video also provides a short example to help you understand and see how rest APIs works using Node.js.

This video talks about what an API is, and how it relates to a web service and/or relates to REST. This is a very interesting video because it seems to cover a lot of basic knowledge needed when dealing with APIs, REST, or RESTful APIs. It also talks about what a person needs to start building APIs. In the video the presenter answers the following three question:

1. What is an API?
   • Also known as Application Programming Interface, that has the ability to give software component a way to communicate with each other.
2. How does it relates to web services?
   • API relates to web services because they both work as a communication sharing base between services or components.
3. What is a REST API?
   • “Is an API that follows the rules of the REST specification”.

for more specification on those question just watch the video by clicking the highlighted link above. I have to say that from this video I found the following tip from the video very useful and interesting… “Questions every API should answer:

1. How can the client tell the service provider which operation it wants to perform?(Method information)
2. How can the client tell the service provider what data to operate on?(Scoping information)”

That is because it helps you understand during building the API it needs to answer those question in order to make sure your API would be successful. This video is not just interesting… it was also useful. From now on when building an API I will ensure that it answer those two questions.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Greetings reader!

In today’s blog, I will be discussing the differences between specification-based testing and code-based testing . I will also explain the benefits of each test, as well as pointing out their distinct features. Without further explanation, let’s begin!

Code based testing is a technique used to see if each line of code has been executed correctly. It corresponds to the testing that is carried out on code development, code inspection, and unit testing in the software development process. The idea is to find out whether any bugs exist in the program by choosing a set of test cases that can create the wanted results. Code based testing involves dynamic testing, static testing, and calculating Cyclomatic complexity.

In static testing, code is not executed; instead it checks the code, requirement documents, and design documents to detect errors.  The goal of this technique is to improve the quality of software by finding errors in early stages of development. Dynamic testing is when you are providing an input, receiving an output, and comparing the output to the expected behavior. Cyclomatic complexity is a mathematical based technique that helps reveal the facts that may be hard to find. It is the calculation of the number of nodes reached and the jump to the next node. It is done with the help of a control flow graph.

Specification-based testing technique is also known as black-box testing because they view the software as a black-box with inputs and outputs. Black box testing is a testing method in which there is no access to the source code or the internal structure of software. The main goal is to check to see if everything works well from the view of a user.  Black box testing focuses on incorrect or missing functions, data structures errors, any graphical user interface errors, faulty software performance, and for any control flow errors. The testers have no knowledge of how the system or component is structured inside the box. Specification-based techniques are applicable at all levels of testing where specification exists.

Types of Specification Based Testing Techniques

1. Equivalence Partitioning
2. Boundary Value Analysis
3. Decision Tables
4. State Transitioning

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