For this week’s installment of individual apprenticeship patterns I have decided to write about the chapter of our textbook called dig deeper. The reason I did this chapter is because it initially caught my attention with its relatability. The catch with this article was that you have a superficial understanding of different software tools. I find this to be extremely relatable because we see a lot of different tools in our classes and at the same time we don’t have much time to cover the tools and master them. I think in my testing class we were using a new tool every few weeks, which really hurt us in the end because I did not have a chance to fully grasp or understand how the tools(s) worked so I have a very superficial and not very deep understanding of these tools. I could probably use them if I tried hard enough and used google to assist me in my journey. I wish that one of two things happened. I wish we had more time to understand these tools or I wish that we did not cover so many tools, however I do understand that we need to cover many tools because there are many tools out there that are constantly changing and they are always making new tools too. The solution to the problem of not understanding the tools or having just a superficial knowledge of the tools is simple. You have to study and learn the new tools. It kind of sounds intuitive that you would have to spend time to learn the tools, but you really have to spend time to learn the tools. This means doing homework outside of work and being able to understand your learning in these tools. By this I mean not just simply taking an online tutorial on a software tool that you well and fully know will cut corners in attempt to try to make the tutorial more understandable and faster. This may seem good in concept but they are leaving out pertinent information that you need to know to master the tools.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Sprint five lasted from April 8th to April 22nd. This sprint, we were focused on completing any big steps left that the project required in preparation for the upcoming sprint, where we will focus on our presentation. For the next sprint, we also have allocated enough time to polish minor details if necessary or finish any uncompleted project features.

My role this sprint was to implement a button that offered more buttons when pressed. This is useful in cases where we have multiple links or related content that can be categorized under a common theme.

To start, I created a new routing module and component for the new button. Yesenia helped me a lot with this task, since she set up the components for the existing buttons. She provided me with the correct commands, ng generate module file-name –routing and ng generate component file-name/sub-file-name. We worked together by bouncing ideas off as we pieced together the HTML and related programming for the new button. By the end of class, we successfully created a new button named dropdown that would rout to a new page, indicating the linked connection was successful.

This was not the full intention however, instead of bringing the user to a new page, the button should display three more options, each of which could have the capabilities to send the user to a new page. I created the three links, but I couldn’t figure out how to hide/show them upon triggering the dropdown button. I deduced that I would mostly have to play with the component.html file, I used the following link as a model of what I wanted to do.

https://material.angular.io/components/sidenav/overview

In that link, scrolling down to the section titled “Drawer with explicit backdrop setting” I was able to look at the existing HTML and trim it down to fit the needs of the project. Mat-form-field and mat-option was specifically what I needed and what I used. With few modifications, and again some bouncing ideas from yesenia, I currently have the feature up and running. Some small things that I would like to get done if possible would be changing the color of the dropdown text to match the other buttons, as right now it is very distinguished looking. Also the manner in which the new options appear is not what I originally thought of, instead of creating a pop out list, I was thinking the buttons would appear on the sidebar beneath the dropdown button and would shift all other buttons below it down. The link below shows what I was originally thinking, but I couldn’t make that work as easily.

https://www.w3schools.com/howto/howto_js_dropdown_sidenav.asp

The reason why I decided to use the other link directly over this one is because I didn’t understand how the provided javascript worked enough to implement it in our project. I’m sure if I dedicated to it, I would be able to get the feature exactly how I want it, but this is not necessary and Ill only change the existing feature if we have extra time.

The focus for our next sprint will be coming up with our presentation and trying to merge our project with some of the other groups projects. We want to be able to combine our side bar with the team working on the search bar without stepping on toes. Tim is currently working on that, I may need to copy and paste some of my work in order to make sure its implemented in the current master branch.

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

As I’ve been progressing throughout my computer science education, I’ve realized that I’m pretty psyched about coding and computing in general. Just thinking about how much that can be done with computer science is enough to get me excited about the kind of work I’m doing. I’m sure that at some point in my career, it may become harder to maintain this excitement for what I’m doing. Even though it’s incredibly cool, it’ll inevitably be my daily routine. This week’s pattern has to do with the continued passion and excitement that I should maintain about computing, even if others around me might not reflect it as much.

Unleash Your Enthusiasm presents the hypothetical situation where an apprentice, with a lack of experience in the field, brings enthusiasm for the subject as part of their skillset to a team. However, the team may be more established and therefore could be less outward about their enthusiasm towards their work. They may be focused more on completing their projects without taking the time to be excited about it. As a result, the apprentice may feel more obligated to keep their enthusiasm more inward and conform to what they think is the norm for the rest of the team. It is imperative that the apprentice keeps this level of excitement and isn’t afraid to let it out, even if others don’t necessarily share it or express it.

I honestly feel very fortunate to have surrounded myself with people who not only support my passion for computing, but also take part in that same enthusiasm. However, I completely agree that even if I were to end up in a situation where I may feel more pressured to subdue this flame of excitement for computer science, I should still not let this affect how much I love what I do. I’ve worked in some teams in my classes where my groupmates were determined to get work done, but they weren’t really excited about it. This has, at times, negatively influenced me so that I spent more time keeping my head down and refraining from showing how I really felt about our progress. But, as I finish up my undergraduate classwork and start my professional career, I am confident that I will have that supportive environment to fully express my passion for computing.

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.

For this weeks blog pattern post I will be looking into the pattern known as confronting your ignorance. The context behind this one is that you have identified the gaps within your skillset that are thereby relevant in your everyday work. The problem that will arise from this is that the tools and techniques needed to master seem unobtainable as you don’t know where to begin. These may already be around you with people around you doing them but there is an expectation you already have this knowledge. The remedy to this that you should pick one skill, tool, or technique and seek to fill the gaps of your knowledge about it. Finding out the most effective ways that suit your style. For some the best approach involves getting an overview of introductory articles and FAQs. While others may find jumping straight into the construction of Breakable Toys the best approach to understanding something. Whichever approach works do not forget to ask around your Kindred Spirits and mentors to see if someone already has the skill and if they will be willing to share their knowledge. Others may be actively seeking this skill as well which can allow you both to work towards this goal. There aren’t enough hours in a day to hone all your skills to a high level, so making necessary trade offs between them is something that will have to happen. This pattern is closely related to Expose Your Ignorance, but implementing it is a less difficult task to your pride since it can be down privately. But eventually you may have to Expose your Ignorance as well, since learning in public will allow an apprentice to being their transition to a journeyman. Taking the list of items from Exposing your Ignorance and striving to learn each one, while crossing the completed off is a good place to start. This way you can see gaps you maybe hadn’t noticed before. This pattern is important to say the least, one that most people should honestly follow if they need to.

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

We are looking at testing with Fakes, Mocks and Stubs. A Test Double is automated testing it is common to use objects that look and behave like their production equivalents but are simplified. This reduces complexity, allows to verify code independently from the rest of the system and sometimes it is even necessary to execute self-validating tests at all. The three implementation variations of testing doubles:

Fakes are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code. Fake implementation can come handy for prototyping and spikes. We can quickly implement and run our system with in-memory store, deferring decisions about database design. Another example can be also a fake payment system, that will always return successful payments.

Command Query Separation- Methods that return some result and do not change the state of the system, are called Query. It returns a value and is free of side effects. There is also another category of methods called Command. This is when a method performs some actions, that changes the system state, but we don’t expect any return value from it. For testing Query type methods we should prefer use of Stubs as we can verify method’s return value.

Stub is an object that holds predefined data and uses it to answer calls during tests. It is used when we cannot or don’t want to involve objects that would answer with real data or have undesirable side effects. An object that needs to grab some data from the database to respond to a method call. Instead of the real object, we introduced a stub and defined what data should be returned.

Mocks are objects that register calls they receive. In test assertion we can verify on Mocks that all expected actions were performed. We use mocks when we don’t want to invoke production code or when there is no easy way to verify, that intended code was executed. There is no return value and no easy way to check system state change.

There are more test doubles such as dummy object, test spy. I thought this blog show clear each test and simple example.

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.

Hello dear reader. Another concept that I came across this semester in my Software Design and Construction class was UML diagrams and I wanted to write about UML diagrams in one of my posts.

For all of you that are new to UML, UML is not a programing language. UML stands for Unified Modeling Language. UML is a standard model language of an integrated set of diagrams. UML was developed to help system and software developers for specifying, constructing, visualizing, and documenting the code of software systems. It is a very important part of developing object-oriented software and the software development process. UML uses mostly graphical notations to express the design a software. Using UML helps teams communicate and validate the architectural design of the software. We use it to portray the behavior and the structure of a system/project.

A question that I asked myself when I started to learn about UML was: Do we really need UML? The more I learned about it the more I understood how important UML is. This for different reasons like: – there are a lot complex applications and systems that need planning from a lot of different teams, and clear explanation need to go to each and every team working on the same project; most of our users might not ever know what code is, but there are a very important part of our project and that’s where UML kicks in by translating this ‘foreign language’ called code.

UML can be classified in two types: Structural and Behavior Diagrams. Structural Diagrams get the static aspect or structure of a system. It includes Object Diagrams, Deployment Diagrams, Class Diagrams and Component Diagrams. Behavior Diagrams on the other hand get the dynamic aspect or behavior of the system and it includes Interaction Diagrams, State Diagrams, Use Case Diagrams and Activity Diagrams.

Except school I have come across UML Diagrams at my job too. The diagram I have seen and that we use a lot if the Deployment Diagram as each of us should be aware of the architecture of the system as deployment.

I like the way Noel explains UML diagrams and where/how to use them. He provides great graphic examples of the diagrams.
https://tallyfy.com/uml-diagram/

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

The article How to Conduct Effective Code Reviews by Billie Cleek covers code reviews, when to use them, and what your objectives and goals should be when working on or submitting a code review. He discuses the different roles you can take in a code review (which are almost analogous to our roles in two of my classes this semester) and what you should expect to do while in those roles in the process of a code review.

A code review is basically a conversation between developers on a proposed set of changes to a project. It can be a discussion about why a certain part of the code is the way it is, whether or not something is effective, or if certain changes need to be made and how to go about that. Code review boils down to having a constructive conversation regarding the development of your project, and what changes might need to be made.

I personally have had a lot of trouble communicating difficulties and voicing my opinion in past classes. It is hard to find your voice and be confident, stating the issues you see and opening yourself to feedback, however through code reviews everyone who participates stands to gain knowledge from their peers as well as experience in effectively communicating to your colleagues. As long as you are able to give and receive feedback in a helpful but constructive manner, you can help clean up a project, fixing errors and making it clear and understandable for viewers to read.

In a way, I feel like my software classes this year have done a lot of work in preparing me for being effective in code reviews, as well as in the workplace in general. A lot of the important skills in code reviews are just as important in group work: effective communication, making sure questions are answered, and mutually agreeing on the decisions being made are all essential to having an effective and useful code review. Building these skills in general will make you a better team member, and help you work better in a group on big projects.

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.