Category Archives: Week-14

Reflecting on “Apprenticeship Patterns” – Kindred Spirits

One of the most important lessons that I have learned from being in a computer science program is to surround myself with people who value computing as much as I do and push me to challenge myself and learn more about the field. When I first started working on my computer science degree, I tended to isolate myself from other people in the major and work on projects or assignments alone. However, over time, I did eventually start to find “my people,” or the people who were also pushing themselves through the program, focusing on improving their skills as well. This week’s apprenticeship pattern, “Kindred Spirits,” emphasizes how essential it really is to have people who not only support your growth in computer science, but also understand what it’s like to go through what you’re going through.

The problem that Kindred Spirits seeks to address is the situation where the apprentice feels like they are “stranded” without help or guidance from mentors or other supporters in the community of computing. They may feel like they are walking the CS path alone, which, in such a huge, rapidly-changing field, can be detrimental towards the apprentice’s success.

The solution is, in short, to get in contact with people who are involved in the same road of knowledge, as well as joining communities that encourage that growth. For some, this form of reaching out may be easy, but for others, it may take more effort to put themselves out there. For me, I tend to have difficulties with joining new groups, especially if I don’t know anyone from the group. But, as I’ve been progressing through the computer science major, I have acquired some great friends along the way who know how difficult this journey can be. For example, one of my pals, James (here’s his blog), and I have consistently collaborated on assignments and projects for a lot of our classes, and getting through those courses definitely would have been more difficult without the support from someone who is also working hard to learn more about CS. I’m also looking forward to meeting and working with my new co-workers, who I’m certain also possess that passion and determination to learn more about computing and want to share that passion with others.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Use Your Title

For this weeks blog post I will be looking into he Use Your Title pattern. The context behind this one is that as a result of your dedication to learning, you’ve been hired or promoted into a position with a title containing the words senior, architect or lead. The problem that will arise from this is that the job title doesn’t actually match what you see in the mirror. When you introduce yourself into this new setting you feel as if you have to apologize or explain the difference between your skill level in your actual job description. A solution to this is that you shouldn’t allow the title to actually affect you. Its just a distraction that should be kept on the outskirts of your active conscious. Use the title only to gauge your organization not yourself. Don’t get fooled by a fancy title, your mother might think you deserve it but the impressive title and responsibilities mean your apprenticeship is over. They serve only to remind you that there is a shortage of craftsmen in the industry. While on the other side of this coin is an unimpressive title despite the fact that you may have surpassed your colleagues. The frustration that comes from a lack of recognition should remind you that the industry has a problem. Using this as a measurement of your own organization and fitting it rather than allowing the frustration to bog you down. Another variant that comes from this theme is the informal versus formal titles. For example you may have grown into a position of authority on your own team despite the formal title remaining. These informal titles can be hard to actually ignore, because they are constantly reinforced by peers and colleagues. These titles remain even if they conflict with your own self assessment, keeping with your mentors and kindred spirits will be critical to keeping you grounded in reality. The recommended action to all of this is simply write down a long and descriptive version of your job title. Making sure it accurately reflects what you really do at work and your skill level. This is again another pattern that I agree with and can see myself using in the future.

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

Journey into “Breakable Toys” (An Individual Apprenticeship Pattern)

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 ninth individual Apprenticeship pattern I decided to blog about “Breakable Toys” pattern.

Summary

When you do not have much experience and you work in an environment where there is no room for failure and mistakes. Meaning mistakes are not tolerable, even if you can build experience from your mistakes/failure and grow and inevitably become successful the idea of failure is not an option allowed. Often the best solution to this problem is to build similar toy systems with a different scope to the one being built at work that will allow you to break it, test it, and budget for failure. This approach is the best solution because as a software developer having a comfortable safe environment where you are free to make mistake without any serious consequences. This approach will help allow you to learn from your mistakes and grow into a better software developer. When implementing this pattern it is important that the systems you build are relevant and useful to you. The book suggest: “For example, build your own wiki, calendar, or address book. Your solutions might be massively over-engineered for the problem they’re solving, and probably could easily be replaced by something off the shelf. However, these projects are where you are allowed to fail.” These are project ideas where only you are affected when mistakes or failure occur. As said in the book, “Breakable Toys is more about deliberately creating opportunities to learn by stepping beyond your boundaries and single-handedly building complete software projects.”

My Reaction

This pattern helps you understand the impotence of building “Breakable toys” because it allows you to build systems that you can break and learn from its failures and mistakes. I agree with this idea because the best way to success is through failure. However; in a work environment failure is not an option so the best way around that is to build your own toy. 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, the reason being is that it has made me realize that I need to start working building “Breakable toys” that would give me some experience.

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.

Data Flow Testing

What is data flow testing? As we looked at path testing in class, data flow testing is one of the testing strategies, which focuses on the data variables and their values, used in the programming logic of the software product, by making use of the control flow graph. Data flow testing is the form of white box testing and structural type testing, which generally keeps check at the points, where the data values are being received by the variables, and at the points, when it is called for use. It is used to fill the gap between the path testing and branch testing.

Data flow testing keep in check of the coding errors and mistakes, which may result in to improper implementation and usage of the data variables or data values in the programming code. If all the data variables, present in the programming code have been initialized, or data variables which are put into use, have been, priory initialized, and if the initialized data variables, has been used, at least once, in the programming code. The data used in programming code, the life cycle goes through 3 phases:

  • Definition: data variables are defined, created and initialized, along with the allocation of the memory to that particular data object.
  • Usage: Declared data variables may be used in the programming code, in two forms
  • Deletion or Kill: Memory allocated to the variables, gets freed and is put into for some other use.

2 types of Data Flow Testing: static data flow testing study and analysis of code is done without performing the actual execution of the code such as wrong header files or library files use or syntax error. And dynamic data flow testing, this involves the execution of the code, to monitor and observe the intermediate results. It basically, looks after the coverage of data flow properties.

The coverage of data flow in terms of “sub-paths” and “complete path” may be categorized under following types: all definition coverage all definition-c use coverage, all definition-p use coverage, all use coverage, and all definition use coverage.

This blog goes over basically all what we look at in class, although there not a lot of new information. There are more information on this website, specially about testing.

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

API

Hello dear reader. As I was staring at my computer and was trying to find a good subject for today’s blogs a bell ringed in my mind: APIs.
I never came across the name API until I started my job. I remember when everyone used to say ‘The API is not working’, ‘We need to call the API to make this process happened’ etc. and I was super confused so I entered google and wrote what is API. Google told me ‘Application Programming Interface’ more fancy words. I started to watch videos about it and also, we started to use them at school. Now I am the one using the term API.

Application – think of an application like credit card. You expect the credit card to help you purchase items and goods.

Programming – API allow the credit card needs to contact your bank and make sure you haven’t extended the limit in your card and is okay to go on.

Interface – is the way we interact with an application.

Simple for you: API define rules that developers must follow to interact with a programming language, software library, web interface or any other software tool. Everyone uses an API every day in some way. A simple comparable example would be you accessing a webpage in your browser. You make a request by entering the webpage URL and the view you see after you press Enter is the response. The API has the same process of request/response but the difference is that API requests provide data in their response.

But why do we even use API? Many of the APIs are made with the intention to allow 3rd party developers to build applications using company data, Since the APIs simply provide data, there are limits on how a company can then go on to use that data. APIs act just like a door and keys. Only the people having the key can open the door and enter the room.

https://www.youtube.com/watch?v=InoAIgBZIEA This video is a great example on how to use the API ( how to call and get the information you need).

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

Spring Framework

When Spring came out, it was a simpler, a light-weight alternative to J2EE, to make J2EE development easier. Enterprise Java refers to Java enterprise software. It’s a computer software used to satisfy the needs of an organization rather than individual users. Examples can include: accounting software, billing Management, business process management, CMS, CRM, ERP, etc. … Continue reading Spring Framework

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.

The Value of Testing

The blog post How Do I Know My Tests Add Value? by AutomationPanda discusses the value of proper testing. The author brings up the common issues that sprout from use a bug-fixed count as a metric for successful testing, and highlights why testing is important and can help improve development.

Testing is important because it validates that your program is working as it is expected to. Well-written tests with the proper amount of coverage give you information about your program and whether any changes need to be made. A passing test indicates correctness and that your program is working as expected. A failing test points out a bug that needs to be fixed and helps highlight weak parts of your code.

The absence of testing might not necessarily lead to bugs, but we all know as programmers that even when it seems your code is running exactly as you intended it to, logic errors can happen and sometimes things weren’t written with every situation in mind. When testing is in being implemented, developers are accountable for the code they write, and must think carefully about the issues that may arise.

Tracking bugs isn’t necessarily effective because it encourages testers to find issues even when there may not be any. All tests passing is still good news and a sign of progress, even if it just means you are doing everything right. Enforcing bug quotas and forcing testers to find issues means they will expend effort looking for things that aren’t there and nitpicking small issues rather than writing more tests or making sure they have good coverage, which are far more effective and finding issues in your code.

At the end of his post, the author suggests some different metrics to use: time-to-bug discovery, coverage, and test failure proportions. All of these serve as much more accurate and effective measures of determining whether your testing has value. Whatever metric you use, it is important to think about why you are testing and whether you are doing it in a way that tells you something about your program.

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.

Model-View-Controller

On his blog, Mikke Goes takes the time to explain the Model-View-Controller design pattern in his post What is the Model-View-Controller (MVC) Design Pattern?. He uses the analogy of an ice cream shop to describe the different functions of the components. The waiter is the view, the manager is the controller, and the person preparing the ice cream takes the role of the model. Together, when a customer makes an order, they each can perform their responsibilities and successfully handle the customer’s request.

The Model-View-Controller design pattern separates the components of your code into sections that divide logic from interface. Keeping the functionalities separate from each other will make your application easier to modify in the future without running into issues. Each of these different groups has a different responsibility when it comes to the application and how requests are handled.

The view consists of the parts of your application that your user will see and interact with. It is not very smart, only outputting the information given to it by the controller. The view helps users make sense of the logic behind your application and interface with it.

The model is the opposite, dealing with all the logic and data manipulation behind wheels of your application. The model responds to requests by processing any data in the necessary ways and giving it back to the controller in a form the view can understand.

The controller handles the communication and interaction of these two. When a request is put in through the view, the controller brings this to the model, and takes the model’s output back to the view to be displayed. It is a middleman that helps connect the two other layers of responsibility.

The Model-View-Controller design pattern seems like a pretty simple design pattern to comprehend. All of the components are divided by responsibility and the program is written with this in mind, making sure that only certain components handle tasks that are within their category. In terms of our projects, the front-end would amount to the view and the back end to the model, with the typescript file functioning as the model. It seems like the development of web applications would sort of naturally fall into this design pattern.

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.

Object Oriented Programming

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.

Using Swagger for API Documentation

As we are nearing the end of the semester and about to finish our projects, I’ve been thinking more about the documentation process for the different parts including the frontend and backend. With this in mind, today I found a great topic about documentation generation for REST APIs with a tool called Swagger. I’ve never heard of Swagger before today, but it is a useful framework that allows for testing, documentation, and other useful features for building APIs. This post shows a quick little tutorial of how to implement Swagger for documentation generation with a Spring Boot project that is very similar to my project and the example REST API order system we have been using. It is a relatively simple process that includes adding the necessary dependencies for Swagger and adding a controller class for it, then all you have to do is just add the necessary documentation statements for each controller and requests within the controllers. The end result is a very nice-looking HTML page that displays a well formatted layout which includes the documentation for your API backend with a graphical display for each request and all the information associated with the request such as body and return information. Now as I was reading this article and this new way of creating documentation, I was comparing it to the way we’ve been doing it so far with a simple table written in Markdown for all of our API endpoints. The output of doing it in Markdown was nice but writing it was a tedious task with the formatting of the table. I much prefer the simplicity that Swagger allows you when adding a new endpoint. I also like the final product that Swagger produces a lot more than the simple Markdown document. In the future if I am creating another Spring Boot project, I am going to try to use Swagger from the start for documentation instead of using a Markdown document with a table for a basic readme as it appears that using Swagger makes adding new endpoints much less tedious with formatting. I would also like to try to add this to my current project if there is enough time, and also see if it is possible to use it with Angular too.

Source: https://dzone.com/articles/swagger-generation-with-spring-boot

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