I decided to learn more about angular since it peaked my interest in class and in general. in my search for more information on Angular, I found “Introduction to AngularJS” by GeeksForGeeks. This post explains the strengths and important things to know about Angular and some of the key features of Angular. some key points from the post are that its easy to use and requires little understanding of different coding languages like HTML, JavaScript, and CSS. Angular saves time as well and avoids unnecessary code. Angular is a powerful framework that allows the developer more control over their applications and web resources. Angular is also unit test ready which helps the developer even more in there processes of creating applications and resources. Angular has Data Binding which means that the developer does not need to continuously update the HTML file or create a special code to bind the data. This keeps data consistent and updated with the most recent version of an application or resource that the developer provides.
Angular seems to make web development easier than ever and gives people the templates and tools needed to create powerful and intuitive applications to suit their own needs. From my short experience with angular, i felt confident and powerful while using the framework and wasted less time than expected had i tried to create a web application without it. I felt in control and could see the real time changes that were occurring in my local website due to the changes I was making. Angular has been for sometime one of the three major frameworks for web developers and the other two are React and Vue. I’m unsure about the other too languages are better or worse or have advantages over Angular, but at this point in time Angular seems like a strong and good choice for my future with any type of web development. the one thing that i think makes angular so appealing to me and others is that the data is bonded and you don’t need to constantly change things to reflect one change in a web application or resource. This framework is something i could see myself using in the future or something like it for web development because it simplifies a larger more difficult job and allows people with enough information to traverse its power and harness that power to create powerful applications. I can’t wait to learn even more about Angular and how to use it effectively.
link to article referenced: https://www.geeksforgeeks.org/introduction-to-angularjs/

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

Several weeks ago, we briefly discussed the SOLID design
principles in CS-343. This discussion was supposed to lead into a homework
assignment where we would research a couple of principles, but since this never
happened I decided to research a SOLID principle for a blog post instead. In
this post, I will be focusing on the Single Responsibility Principle, or SRP
(the ‘S’ in SOLID). This principle declares that a class should have only one
reason to change, or in other words, a single responsibility. It sounds like a
simple concept, but actually implementing it can be challenging. My research
into the SRP helped me come across a blog post by Patrick Smacchia titled “SOLID
Design: The Single Responsibility Principle (SRP),” which defines guidelines
that may help make the principle easier to follow.

The blog can be found here:

In the blog, Smacchia explains that the SRP is not as simple
to follow as it sounds, because different programmers may define a responsibility
or a reason to change in different ways. For this reason, he approaches
the principle based on its fundamental purpose of determining which logic
should be in which class. From this approach, he explains several aspects of
the SRP using example code, and he provides a set of concrete guidelines that
can help enforce the principle. I chose to share this post because Smacchia’s
approach to explaining the SRP has helped me understand it better by getting me
to think about it from a more fundamental perspective. I also think his
guidelines would be useful to any programmers, myself included, who intend on
following this principle in their projects.

I certainly intend on referring back to the guidelines
included in this blog to ensure that my future projects follow the SRP. Although
there are a couple I don’t fully understand, such as the one on POCO classes, I
think the others will greatly help me adhere to the SRP. His suggestion to keep
logic related to different functions separated into different classes makes
sense thanks to his Employee example, which I will refer back to when deciding
which functions should be separated into different classes. I found Smaccia’s
discussion on cohesion especially interesting because it exposed me to the Lack
of Cohesion Of Methods metric, or LCOM, which is used to actually quantify how
cohesive a class is. It surprised me that a more complex class can have a lower
LCOM score than a simpler one, and that a class’ simplicity does not represent
its adherence to the SRP. I will definitely refer back to this blog to help me
ensure that my own classes keep a low LCOM score even as they grown more
complex as a way to follow the SRP. I have certainly had issues with classes
getting too large and doing too many things in the past, and I think learning
more about the SRP from this blog will help me avoid this problem in the future.

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

If you have ever been around anything web-based, there is a
good chance you have heard or come across angular. Angular for those unfamiliar
is a framework that allows for a wide range of possibilities. Angular all stems
from 4 main parts: components, dependency injection, property bindings and
typescript. Components are what Angular is entirely composed of. Most things
created in Angular are components or collection of components. While there are still
a few other concepts to angular, components are the most prominent. Components
are usually comprised of HTML, CSS and JS but with angular, these are all
combined into an easy to manipulate sense to allow for customization of the
components. The next part of angular is the dependency injection which helps
largely with dependency management. Dependencies are all in a collection together
and when new components are created, the dependency for that object is
automatically created and put into the collection alongside the other dependencies.
This allows for the user to easily streamline dependency management as angular
is able to “automatically” create and track dependencies. The next main aspect
of angular is the property bindings. What this means is that the data that the
app contains is separate from the what is being presented. This allows for the
user to make changes to this data and automatically have it update and be
displayed on the presentation side. This allows for the user to seamlessly update
anything needed in real time. The last part of angular is the support and use
of typescript. Javascript, for the ones unaware, is a subset of typescript.
Typescript allows for a very straight forward approach to writing javascript.
The user is able to write the code needed in typescript and it will be automatically
generated into javascript to be used by the app.

The main benefit of angular is allowing for users to easily
be able to build large scale apps with everything being self-contained in the program.
A lot of the complicated processes that went along with developing apps are now
very easy to be implemented with Angular. People that are not skilled in javascript
generally have a much easier time adapting typescript due to the fact that the syntax
is not all too different from java. Most skilled programmers are able to pickup
and implement typescript rather quickly. This allows for almost anyone to be
able to create and build large scale apps without having to personally be
responsible for many of the complications that would prevent people from trying.

If you want to learn more, this website has a great overview
of Angular:

https://www.telerik.com/blogs/all-things-angular

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Hello again my few readers, sorry I haven’t posted in a while but as you all know, I am a heavy procrastinator hence why I have 6 weeks to write 6 blogs in order to obtain an A in my class. Luckily, I am attending a presentation today so now I only have to write 5 blogs. Regardless, lets get this show on the road.

Today, I am going to talk about a blog with the title of “How Testers Can Become Agents of Change” Honestly, kind of a long title, but I don’t mind. The article is pretty short overall with 5 short sections. The first section is simple introduction to what the blog entry is going to be about. That is kind of like what I did for the first paragraph of this post. The author asks the reader to consider what they think is difficult at their job and how they will overcome said difficulty. Honestly, so far this sounds like one of those inspirational talks with some really outdated famous celebrity talking about how to be like them. This isn’t a bad thing, I just found that to be funny.

The post then explains how to identify opportunities for change. She mentions how there are three types of change: “Tool’s, processes, and people” (Norville) I assume this can mean that staff is always changing, methods are always changing, and tools are always changing which makes sense in a working environment. She says that anyone can bring change which sounds kind of cheesy, but I do like that because this shows that somebody like an Intern can bring about change. She then mentions a start, stop, continue model which is explained as the team discussing what they should stop doing, and what they should start doing. She uses an agile group as an example here and we learned about agile last semester.

Norville then talks about how to actually enact this change. This section is broken up into several subtopics which I think makes an article look cleaner and more organized. She tells the reader to know their audience in order to persuade them in the best way possible. She also says to fully understand the problem which is self explanatory. She describes the pitch as a way of presenting your information and evidence to the person you are trying to convince. This kind of follows the know your audience path. She also tells the reader to poke holes in the pitch. This is interesting because it is kind of exactly like testing where you try and break the code in order to ensure quality.

The last real paragraph is some tips that you can use in case you hit some bumps. The first of the tips is “Don’t Give Up” (This is in every inspirational post I swear). But regardless, it is true, even if you hit a bump along the way, you shouldn’t give up. The next tip is finding a team. This can be helpful with the knowing your audience part because everybody is different. She mentions learning from others successes, and I think this one is helpful because you can use methods that other people used to get your point across.

The actual last paragraph is just a closer telling the reader to start enacting change. I did enjoy this article, however this seems like an article that was directed at everyone rather than just testers. This isn’t a bad thing, but I would have liked to see more direct examples of how Software Testers can enact change. Overall this was a very well written blog. It was short and concise, and it was organized very well. I would recommend this article to anyone who is trying to make changes in their workplace, but they donf’t know how to start.

Making Software Quality a Critical Priority: How Testers Can Become Agents of Change

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Hi my readers. Welcome back to my blog.  In this blog post I am going to talk about an interesting pattern called “Use Your Title”.

Most us, who have worked in big companies and most of you who will in the future, are gonna have a FANCY title at your job. Sometimes even the person itself will get confused by its own title as at the beginning might not describe well what it means.

The best advice given by the authors for this pattern is: “Don’t allow your title to affect you! & Don’t be fooled by an impressive title!” It happens a lot nowadays that people have to explain what they really do because not everyone is aware of what a job title might be and what are the duties and responsibilities. There are also a lot of other cases where people misinterpret the job titles. My job title in my company is Support Engineer. and when some people would hear the name Support they automatically told me ” So you like talking on the phone with customer huh?!” That’s where I had to explain what my real position was and what was I actually doing. As I come from Albania, at the beginning I used to ‘blame’ on the company for giving me this title, but later on I realized it was the people who were to blame.

As you might know by now, I am graduating this May with a major in Computer Science and Software Development concentration. While having a conversation at my office with my teammates we all agreed that our titles were a bit too much as we hadn’t graduated as Engineers but developers. However, we all like using the fancy title.

The other side of the coin is where you have such a high job position and your job title doesn’t fully express much about it until you say what you actually do.

In both cases, the most important thing is to explain what you do with your own words and not the title, fancy or not. It is always good to have a written definition of what you do and what your duties are as you might never know who you might come across to.

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

For this post, I was looking for an eye catching pattern name and “Be the Worst” definitely caught my eye. After a second a of thought, it was pretty obvious what this pattern would be about. This pattern breaks down why it is important to not be the big fish in the little pond. It encourages apprentices to not rush into leadership roles and to not strive to become the best on your team and stagnate with your position. Instead, if you find yourself at the top and lacking learning opportunities, it may be time to move on and find the bigger pond, to surround yourself with higher tier developers when you leave.

I almost entirely agree with this pattern. I remember growing up in a relatively small town, where we had a couple athletes who were notably better than anyone else in the town at their respective sport and position. None, yes none, of them tried to get into bigger school districts where they may be challenged more and had more of an opportunity to get scholarships and even potentially make it professionally. Instead they all enjoyed their high school careers at a school with roughly 500 students in a division 3 conference. They didn’t aspire to leave the little pond and they never made it anywhere in terms of athletics. There are definitely parallels to this even in the college world and looking for positions directly out of school. There are always going to be people who are happy to just cruise by and not learn everything that they can at each step of their careers. I honestly feel like these are the people who are most likely to never even get a job in respective majors and then somehow blame the university for not finding them a job with a 2.0 GPA. No one owes you anything and you can’t expect anything to be handed to you, knowledge especially. There is always more to learn and never enough time to get everything into a four year curriculum. Never settle for being the best you know. All that means is that you need to meet more people.

The only part of this pattern I disagree with is how the authors try to sway readers from promotions. Promotions and new responsibilities even outside of coding are definitely important to becoming the best within a company. If the goal is to rise through the ranks of a company, isn’t this an obvious side effect? That being said, I will definitely consider this pattern as I move along in my career.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.