Category Archives: Week 11

Full Stack Developer

I am writing in response to the blog post at https://www.guru99.com/full-stack-developer.html titled “What is Full Stack Developer? Skills to become a Web Developer”. A full stack developer is somebody who is able to work in both front end and back end development. We have worked with back end development in CS 343 with our work in REST APIs, and we have also worked with front end development using Angular JS and TypeScript. Full stack development involves writing both ends.

The blog post describes a full-stack web developer as somebody who can work on both the front end and the back end of an application. It provides a tiered model of application layers that the developer should be familiar with: the presentation layer, business logic layer and database layer. We have briefly discussed the concept of a layered application model in class before. The presentation layer is the front end that handles the user interface, and the business logic layer and database layer correspond to the back end.

Some average income statistics are provided in the blog post, which shows that a “back end developer” earns more on average than a “full stack developer”, which seems counter-intuitive because a full stack developer, in theory, is capable of accomplishing the same tasks as a back end developer and more.

A clarification is made about the expected duties of a full stack developer; a supposed myth is that a full stack developer is going to be writing all of the code by themselves, writing both the front end and back end for a single large application because both jobs are within their skill set. In actuality, it is not the job of a full stack developer to produce everything alone. The blog post describes a full stack developer as a sort of a bridge between front end developers and back end developers who are working on the same project, because the full stack developer has a good perspective of both ends and how they interact with each other. In this sense, it is clear that a full stack developer in a development team is particularly beneficial for communication.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Integration Testing

In this week’s blog, I will be talking about Integration Testing from Software Testing Fundamentals.

The International Software Testing Qualifications Board definition:  Integration Testing is a test performed to expose defects in the interfaces and in the interactions between integrated components or systems.

Integration testing is a level of testing where units are tested as a group making sure they all work when put together. It is performed after Unit Testing and before System Testing. Developer themselves or independent testers are responsible for performing Integration Testing. There are different kind of approaches to Integration Testing:

  • Big Bang is an approach where all or most of the units are combined together to be tested in one go when the testing team receives the entire software bundle. Kind of like System Testing but it only tests the interactions between units and not the entire system.
  • Top Down is an approach where top-level units are tested first before the lower level ones.  This approach is taken when the development of the software was also from top to bottom.
  • Bottom Up it is basically like Top Down instead you go from the bottom to the top.
  • Sandwich/Hybrid is a combination of Top Down and Bottom Up.

I picked to read this blog because it offers useful analogies to make it easier to understand. There was also a gif at the bottom of the blog where it shows what happens when you do not do an Integration Testing. There were also tips on how to do Integration Testing properly. One of them was to “ensure that you have a proper Detail Design document where interactions between each unit are clearly defined. In fact, you will not be able to perform Integration Testing without this information.” I think that was pretty much the main point of that you have to take from Integration Testing. That you need to know how the system works or the design of it, else Integration Testing would not make any sense to do. Another take on from this blog is to make sure that every unit is unit tested before you start Integration Testing.

Lack of Integration Gif:

https://giphy.com/embed/3o7rbPDRHIHwbmcOByvia GIPHY

 

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Quality Assurance at Apple

For this week’s blog for quality assurance and testing, I decided to read an article from Wired Magazine that focused less on the testing process itself and more of how a company can benefit from it. The article I chose is a little less than a year old about Apple’s securities and vulnerabilities. The article confirms some of what I had hoped — that Apple still has a strong reputation for security. However, some vulnerabilities have damaged how the company is perceived by many. 
In High Sierra, all that you had to do to gain root access was type the word “root.” They fixed it impressively quickly. However, the article wonders if the security flaws like this are emblematic of deeper problems. There have been many more bugs and vulnerabilities found, such as wonky autocorrect on the iPhone. Although not every bug (like the autocorrect) is not always a security issue, it is incredibly irritating. 
One advantage that Apple has over its competitors is that most of its customers update as soon as there is an update. The advantage of this is that people will not be vulnerable using a software without the security fixes in the update. However, Apple might lose this edge if people are wary of updating if it seems like there are always too many bugs in every update.
One of the big problems these days is that it seems that everything seems rushed out. There is a big focus on new features, and not as much focus on fixing the bugs on the features that already exist. The article talked about a 2009 release of “Snow Leopard” which built on the previous release “Leopard.” It heavily focused on getting bugs fixed.
Another issue about perceptions is that even if the mistakes are fixed quite promptly, they are still remembered, with what is described as a pile-on effect. That is, a fixed security flaw won’t be “erased” from a customer’s mind.
The takeaway from all of this is how important quality assurance is to any product. It perhaps is more important than new features. If the old and new features are continuously full of bugs, it is hard for a customer to trust that company anymore. It is better to have solid core software than one with a million extra bells and whistles if it means there’s just as many bugs. Unfortunately, the article concluded that it seems like Apple is leaning towards the latter.

https://www.wired.com/story/apples-security-macos-high-sierra-ios-11/

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

Apprenticeship Pattern: Create Feedback Loops

This week I read the pattern “Create Feedback Loops”. I thought that this pattern was the most one of the most practical of the ones that I’ve read so far because there are so many ways that this could be applied. I also think that this is one of the most crucial patterns that everyone should apply because it has the power of significantly shortening the time it takes to learn, as well as pointing out any potentially catastrophic errors in the way that things get done.

A great thing that this pattern was able to do was telling us some mechanisms that are available for acquiring this feedback. The ways of getting feedback included test driven development (TDD), using type-checked languages, as well as just simply asking a colleague. Of those provided, my favorite is TDD. I am a huge fan of TDD because it gives you instant feedback letting you know that the functionality is implemented correctly, but even more important than that, it lets you catch regressions even faster. I find that TDD is even more effective when someone else has written the tests, and when there are negative tests cases written as well. Fortunately this is something that nearly every tech company practices so I will not have to convince anyone of it’s value. The method of getting feedback that can be the most daunting is asking a colleague or boss, but it can be very valuable. It can be difficult to honestly assess yourself (as this pattern stated), so having the opinion of someone else can help give you a more true vision of your performance. When it comes to asking another for their opinion, the author hit upon a very important idea which is essentially that the given feedback must be “useful”. So if the feedback that you receive is negative and there is no way to grow using this feedback then it is absolutely worthless.

I agree completely with this pattern, and it is one that I intend to use throughout my career. The learning potential using this pattern is extremely high, and if applied correctly will lead to extreme success!

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

Walking the Long Road: Draw Your Own Map

In this Apprenticeship Pattern “Draw Your Own Map”, it explains the importance about creating and managing your career path once you are exposed in the software development environment. A couple of key points that the pattern states are:

  1. Your manager, professors, or colleagues are not in charge of where you position your career as a software developer.
  2. Your are responsible for your destination and goals.

These couple of points emphasizes the concept of a software developer’s individuality. It is true that within the software development field, everyone is a programmer and creates many different types of software. It is up to you as an individual to take steps towards what you aspire to do and become within this field of development. One quote that stood out to me was this one below that talks about your vision of goals versus the employer’s vision for you.

“If you find that your vision of yourself is not in accord with your employer’s vision for you, and there doesn’t seem to be a way to reconcile the differences, examine other opportunities to see if they’re heading in the desired direction. Remember, there isn’t one single path that all apprentices follow. Instead, successful apprentices follow paths that share a certain family resemblance. These resemblances do not happen because apprentices are inexorably shepherded into making the same decisions by their mentors. They happen because each apprentice, consciously or not, chooses their route through life based on an overlapping set of values.”

I agree with this idea because it seems like it will be the most realistic to me once I start working for a company that may not have the same vision for my career as I do. This idea also will allow me to change the way on how I would manage my goals and career paths while working in the field. I will continuously plan and weigh options that would be available to me out there in the software development field since there are many companies and employers to work for. It goes back to the concept of leaving your current job for a better one because it does not meet your intended needs or it doesn’t help you grow in the field. For me, I’d like to work for a place that respects my needs and aspirations. As a future video game developer, I want to have that luxury of being able to grow into a successful video game developer and there would be nothing more  important than that.

 

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

Apprenticeship Patterns: Sweep The Floor

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

Kindred Spirits

Problem

Organizational cultures that encourage software craftsmanship are rare. You find yourself stranded without mentors and in an atmosphere that seems at odds with your aspirations.

Solution

The solution the text offers is to keep your momentum going, there will be times when you may not have access to a mentor so you must keep in contact with those who are walking a similar road you are, as well as seeking out others who may be looking to excel. The Long Road is not something you walk alone, some relationships are short and effective, others are long lasting, and help nurture your passion. Though there are many benefits of a community of like-minded people, you need to be wary of group-think. It’s O.K. to follow the crowd sometimes but must always remain vigilant and question something when you feel it’s important.

This pattern is a good reminder to always try to keep people around that you can rely on to share experiences and learn from each other. I think it’s interesting you can have mentors all over the world, you may have never even met in person but you have a connection because you are walking a similar road. Having a Kindred Spirit to talk to, to take a break from the 9 to 5 work and share something that may be new or interesting. The dynamic is different because you can share what you know without coming off as a mentor you should follow. Kindred Spirits reminds me how important relationships are especially with the people you work with, as they can be great resources especially when you need advice on something work related. Having a community around you is another good way to ensure you have kindred spirits, and I like the idea of healthy debate, to keep the community fresh and healthy. I like that the pattern encourages finding those in community who may have a broad interest in software development, but then slowly find those who may have a particular niche that you may benefit from. Knowing those with obscure knowledge can help you when you if you ever find yourself in a situation where you are working on something unfamiliar.

The post Kindred Spirits appeared first on code friendly.

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

The Long Road

I anticipate my career to involve software development for the rest of my life. I need to start preparing for the intense journey to come. That being said, I want to discuss The Long Road apprenticeship pattern. It seems directly relative to the situation I find myself in, which is a soon-to-be entry level software developer.

The Long Road is a portrayed as a direction apprentices should take when new to software development. It is asserted that those looking to journey down this proverbial road should not be looking to become instantaneously rich and famous. Instead, it is suggested that we ought to steadily increase our knowledge and skills throughout the decades to come. We should not feel obligated to accept any promotion that could potentially constrict our quest for knowledge.

I realize applying this pattern will likely mean turning down promotions in favor of strengthening my overall skills. But honestly, I don’t think I’d be comfortable taking a job I didn’t enjoy just because the pay was better. I’d rather spend my professional career looking forward to going to work, instead of potentially dreading it. For that reason, I believe The Long Road is an appropriate pattern for me to follow.

When beginning to apply this pattern, it is suggested to think about where we might end up in the decades ahead when traveling down this “long road.” Personally, it is hard for me to imagine what I’ll be doing ten or twenty years from now. But one of the immediate goals I’ve set for myself after graduation is to learn as many programming languages as possible. This ought to require a lot of reading, programming, and collaboration with other developers. I’m genuinely looking forward to it.

If I were to guess what I’ll be doing many years from now, I am hoping to become well-versed enough in the software development world to have helped others in some substantial way. With all the reading on software development I plan on doing in the decades ahead, perhaps I will have written my own book or two. I guess only time can tell where I’ll end up, but I think I’ll always stay on “The Long Road” in favor of any promotion that might distract me from furthering my overall career. Ultimately, I predict I’ll always be a software developer in one way or another.

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

Post #27 – Reflection on the “Dig Deeper” Pattern

This week, I will be writing a reflection on the “Dig Deeper” pattern.  This pattern addresses developers who feel that feel that they only possess a superficial knowledge of some of the technologies, tools, and techniques utilized at their workplace.  The problem that arises, in this scenario, is that the developer begins having trouble with maintenance of his or her code because it was written with only superficial knowledge that is likely to be forgotten.  I chose to reflect on this pattern because I really like the advise that Oshineye and Hoover provide about how to truly immerse yourself into the learning process and transform your superficial knowledge to deep knowledge.  I also agree that having a deeper understanding of the everyday things in your life can be incredibly beneficial in a number of ways.

The primary importance of deep knowledge is that allows you to explain the inner workings of systems you work on, which will distinguish you from colleagues that are unable to do so and show others that you are more proficient in working with that system.  I recently had an interview for an internship and many of the questions I was asked were related to my contribution to and understanding of past projects.  The recruiter got back to me a short time after the interview and informed me that I ‘knocked the interview out of the park’ and I was offered the position – I accepted!  Oshineye and Hoover explain that deep knowledge can also act as a safety net in that you can refer back to how you gained your deep understanding in that area to gain confidence about learning something new.

They recommend that developers ‘dig deep’ into the tools and technologies involved in the project they’re working on, until they have a deep understanding of how those tools and technologies work and why they are being used.  One of the ways somebody can dig deep into something is by getting their information from primary sources.  Primary sources understand the problems they were trying to solve.  Another way somebody can dig deep is by looking at tutorials and guides regarding the thing(s) they want to learn, and asking themselves if there are underlying computer science concepts behind what you they are learning.

I think this pattern will prove to be a useful piece of knowledge in my repertoire.  I will try to apply it regularly in my career and I strive to become a person who truly understands the tools and technology utilized in the software I am working on.  I have used this pattern and seen it work, first hand, and I hope it will lead me to more success in the future.

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

Find Mentors

This pattern also captured a very important issue that is often ignored. As a newcomer, you need someone to guide and coach you to get grounds in the field. We sometime failed to understand that only what is learned in class can’t take us to the field. The outside world has its own convention of doing things and a newcomer need somebody who is already in the field with experience to guide him. There are so many benefits for having a mentor. Working alone is the hardest thing you could face in the outside world and having someone as a mentor walking with you side by side or sitting with you face to face could save you a whole lot of time spent trying to figure out how to dealt with certain problems. Even though it sound very simple to say find a mentor, it is usually challenging to get someone who is willing to accept you as an apprentice.  Even though the writer talks about the field being young and which we can’t tell who is a master craftsman, I don’ think that is a problem. Because, no matter the situation is, those who are already in the field will have some experience that a newcomer doesn’t have. The issue here is everybody readiness to share what have been learned. Most people don’t want to share their knowledge with others because they feared their jobs would be taken from them. They also forget the fact that when you teach other of what you know, it helps you remember it all the time. In fact, it sticks in your mind forever. With regards to this problem, if you are fortunate to have many people mentor you, you will definitely gain enough knowledge to keep you going in the field. Another thing that every apprentice needs to know is that nobody knows everything and though the master has more experience than he has, they might both be learning certain things together. Regardless of whatever challenges I might face in the industry, with this whole ideas in my mind, I think I can survive in the industry.

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