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.

While most of the Apprenticeship Patterns  I have read thus far are mainly focused on developing long term skills with an internal locus of control, as many of these patterns’ goal is to change our perspective to be more successful and adaptable to the software development industry. What I like most about this pattern, “find mentors”, is that the authors give good advice for branching out socially into the software development community by finding skilled individuals who can serve as mentors that can use their perspective and experience to catalyze the growth of our skills.

What spoke out most to me about this pattern and the reason I decided to write about it was their quote which seemed to me to encapsulate exactly the meaning of what they were going after; “Your apprenticeship is unlikely to happen in isolation”. While it is ultimately up to us as apprentices to take responsibility for our own development, there is an immense value in finding someone else who is worlds more experienced than you to show you the ropes and use the benefit of their experience to learn the best ways to do certain things or pitfalls to avoid.

The authors give a lot of good advice which I would not have thought about without reading this pattern. First, they highlight not only the importance of finding mentors but also the difficulties associated with finding something. Not only is there the risk that the individual is not interested in mentoring an apprentice, but it can also be difficult to find such a suitable person. The solution the authors provided is to start out by lurking at online forums related to the field and topics that we are going into. After lurking and getting a good sense of the community and their values, then it is good to start discussing on threads with people, and even asking for advice.

What I learned from this pattern is the importance of finding a skilled mentor to catalyze my professional development, as well as concrete strategies for finding people who might be willing to take on an apprentice. While the responsibility is on us as apprentices to gain the skills needed to succeed, finding a mentor is definitely a huge step forward in the journey to master the craft of software development.

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

This week, I will be exploring another apprenticeship pattern, which is “Breakable Toys.” I briefly mentioned this pattern in my last post, and I thought it was worth revisiting.

The professor of my capstone, Dr. Wurst, had suggested for us to try to create something, even if it wasn’t exactly what we were trying to do. This would allow us to dive deep into learning one thing.

The term he used for what he was talking about was “spike,” which I isn’t exactly the same as this pattern, but it certainly is a similar idea. This pattern more pertains to doing projects on your own time to learn from your mistakes.

In school, it wouldn’t make sense to turn in projects that don’t work. It would be hard to pass most classes if I did. In many cases, school or work, failure is not an option. Of course the authors don’t advocate experimenting with those projects. They would rather you learn independently so that you can apply the skills you pick up.

For the past few blogs, I have talked about being more proactive. I have made a conscious effort, but it has been hard keeping it up. I have to realize that change doesn’t happen overnight, and it’s good to take these setbacks in stride to avoid being discouraged.

In the pattern, it uses the analogy of someone learning to juggle. I once read a study where of those instructed to juggle just five minutes a day, all of the participants were able to juggle by the end of the study. Reading this was enough to encourage me to try this experiment for myself. I set a timer for five minutes everyday, and I was able to pick it up after a few weeks.

The important thing to note is that five minutes was the minimum I set for myself, but I would invariably go for much longer than that. Currently I do not have any side projects that I am actively pursuing. If I were to set a five minute minimum to do something, although it would be small, it would be far better than nothing. I’m willing to bet most days it turn into much, much longer segments of time than five minutes.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.