If my previous blog posts haven’t reflected it enough, I am definitely nervous to step into the professional software development field. This is likely mostly due to my case of imposter syndrome, where I think of myself as less capable or knowledgeable than I actually am. On another hand, though, I have also been overwhelmed by the thought of being behind other team members or colleagues in terms of knowledge and experience, even though everyone will, and should, be aware of this gap.

This week’s apprenticeship pattern, Expose Your Ignorance, further reassured me that learning new things and not necessarily knowing everything right away on the job is a normal occurrence. Everyone on the team is under pressure to submit work by a certain time, and when there is a “weaker link” who may not be on the same page as other team members, it can certainly cause some tension and perhaps anxiety for this team member. However, in order to best confront this issue, the team member should break down their walls hiding their ignorance toward the subject of the project, as well as let everyone else know about of how much they know and how much they still need to learn. It is suggested that one of the best ways to show this ignorance of any topic is to ask questions, as well as remain transparent when working with others so that the team member’s level of expertise is not misinterpreted. The apprentice should not only disclose this information, but also emphasize their willingness to learn and catch up with the rest of the team.

I already had a feeling that upon entering the workforce, senior developers and other colleagues would have some sort of understanding that I will not have as much experience as them, and that I will need to spend time catching up to what they know. This pattern was great to allow me to realize that I shouldn’t be afraid to let everyone know where my knowledge of our work stands, even if it requires further progress to strive towards everyone else’s level of understanding.

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.

          The “Sweep The Floor” pattern is described as a way be able find your place on a new team that is unsure of you. This pattern expresses how to find a way to earn your teams trust and contribute to their work without getting in their way. A good way to start is to volunteer to do simple tasks to show initiative and competence for small tasks to eventually work your way up to the big ones. An important fact to remember is to go for quality of work rather than quantity to ensure your teammates of how seriously you are taking this opportunity given by them. This may seem like a step back from all the studying and preparation you’ve done to get to the point, but you must also remember that now you are hired to be on this team. You must prove yourself before they can put any sort of trust in you and the best way to do that without causing any accidents are smaller tasks. This does not mean that you should let the team see you as the pack mule for meaningless tasks, but rather someone who can pick up the slack if needed.

         I found this pattern to be a great introduction to read before really starting out on a team. It allows an easier incorporation to the team dynamic and earn a teammates trust. It created a good sense of what to do and not to do so as to make sure that you are doing extra work for the good of the team while not becoming a pack mule. I want to start using these skills and think that they will definitely make working in a team easier. I think it will make the workload harder, but it seems to be a good trade off to earn the respect for other teammates. I agree with this pattern for that very reason because respect is a very big deal in teamwork. Every team member should prove their skills and respect for the good of the team. I want to continue this practice to make sure that my dedication and commitment to the team is seen to create a better bond with teammates.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Hello dear readers. Today we are going to talk about SOLID, the first five principles of the object oriented design.

S.O.L.I.D is an acronym for the first five object-oriented design principle. When these principles are combined together, it makes it easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to avoid easily refactor code and are also a part of the agile or adaptive software development. SOLID stands for:
S – Single responsibility principle
O – Open/Closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Inversion principle

Single Responsibility Principle states that a class should only have one job, only one reason to change. The reason why we should use SRP is because it makes your software easier to implement and prevents unexpected side-effects of future changes. Another benefit of this principle is that classes and software components that have only one responsibility are much easier to understand, explain and implement than the ones that provide solution for everything.

Open/Closed Principle states that objects or entities should be open for extension but closed for modifications. Using this principle prevents situations in which a change to one of your classes also requires you to adapt all depending classes.

Liskov substitution principle states that every subclass/derived class should be substitute for their base/parent class. To achieve that, your subclasses need to follow the following rules: 1. Don’t implement any stricter validation rules on input parameters than implemented by the parent class. 2. Apply at the least the same rules to all output parameters as applied by the parent class.

Interface segregation principle states that a client should not be forces to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use. By following this principle, you will be able to prevent bloated interfaces that define methods for multiple responsibilities. You should avoid classes and interfaces with multiple responsibilities because they change often and make your software hard to maintain.

Dependency Inversion principle states that entities must depend on abstractions not on concretions. High-lever and low-lever modules also depend on the abstraction. This design principle does not just change the direction of the dependency, it also splits the dependency between the two levels by introducing an abstraction between them.

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

Good day, my dear reader! As I continue my education in Software Quality Assurance, I continue to read blogs and keep finding myself reading a blog about how to do one particular topic, or how to test in one specific method. Now those reads were all good and useful but one particular article caught my attention, “5 Reasons you are wasting your testing time“. Now I will admit, I did succumb to the very obviously clickbait title but, this was one title I am glad that I followed. In class, there is a lot to learn but some things are best learned on the job or get glanced over or forgotten in the classroom. This particular blog was about 5 ways to review your testing time and see where you are wasting yours.

The first way is not setting a clear goal. Establish a goal for the testing session and ensure that by the end of your testing session, the goal has been met. The second way is that you might not understand the value of the tested feature to the end user. This is saying that, while we are tasked to test a feature we should keep in mind if this feature actually is useful or helpful to the end user. The third way is that one doesn’t keep track of what was tested and your finding. This boils down to that you need to be able to adapt your tests as you are testing. Fourth is not consulting existing information to get testing insights. The last reason is refusing to do post-test reviews or feedback sessions.

The first thing that popped out to me is the consideration for the end user. This is definitely something that is not talked about in class. It’s something I keep running across and I hope I can keep it in mind as I head out into the job market. The end goal is to create a usable, program that an end user will actually use or purchase. The next thing that jumped out at me is that some testers, “…who say they consciously prefer not to see the previous test-runs or the bugs found in an area of the system in order to avoid any bias towards those areas during their current testing session.” I found this kind of silly that some people see testing a program like a clinical double-blind study. When I hear testing, I think of video game testers effectively ramming their heads against a particular part of a game until it breaks or they do. While I doubt I will ever have this mindset, it’s always good to know what to avoid. The last thing that caught me was that testing, “While at the same time it is an art, as you need to (almost instinctively) know how to adapt and change your testing based on actual stuff you find along the way.” This caught me off guard admittedly. Testing does seem dynamic to me but not in that sense of having to change the nature of a test mid-session. This is something that I will have to remember and try to put into practice out in the field.

Thus ends another blog and another week of discovery and learning. I can only wonder what I will learn next week and I am definitely excited to find out. Until then, have a good night folks!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Source: https://blog.lelonek.me/how-should-we-do-code-reviews-ced54cede375

This week’s reading is a blog about conducting code reviews properly by Kamil Lelonek. It gives a general overview of code review as a process of giving feedback about another person’s code. By utilizing this process of rejecting and approving certain changes to the codebase, it will generate improvements as a whole. However, it goes much further beyond code review as it is not as simple as it seems. Even though benefits such as catching bugs early and ensuring that the code is legible and maintainable moving forward. The post makes it important to realize that developers are very protective about the code that they write and will attempt to defend against criticism. So, it provides different approaches to mitigating problems that could rise while undergoing code review. The benefits of these approaches should be able to correctly reach out without appearing as a threat. Some of these techniques would be to distinguish opinions from facts, avoiding sarcasm, and being honest with yourself. Also, by understanding the ten tips provided, it should make code reviews more effective for everyone involved.

What I found interesting about the article is how straight forward it is towards addressing one’s ego. They are right when they say that developers would like to say that they have wrote good code but sometimes they need to leave the ego behind them. By not opening themselves to criticism and addressing it as threats is detrimental to the team as a whole. Also, when actively code reviewing, I can see that providing evidence for nitpicking at certain lines of code should make it easier for the reviewee to understand what you are addressing specifically. However, I believe that avoiding jokes and sarcasm should be remembered as top priority. Especially when you are reviewing code for a friend. Recalling from personal experience, I do believe I did not help my peer to the best of my abilities by using sarcasm during code review. This also applies to distinguishing opinions from facts where sometimes through practice, you are led to believe that one technique is better than another. In conclusion, these tips are great for improving code review sessions.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about the term “simplicity” when we refer it to a software product. There have been an old ‘80/20’ rule meaning that 80% of the people use 20% of the features. So, you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies. Unfortunately, it’s never the same 20%. Everybody uses a different set of features. In a period in the past, dozens of companies tried to release ‘lite’ word processors that only implement 20% of the features. Most of the time, they gave their program to a journalist to review, and the journalist reviewed it by writing their review using the new word processor, and then the journalist tried to find the ‘word count’ feature which they needed because most journalists have precise word count requirements, and it was not there, because nobody in the target 80% would use this feature. The journalist ended up writing a story that attempted to claim simultaneously that lite programs were good, bloat was bad, and he could not use this program because it would not count his words.

Making simple with 20% feature products is an excellent bootstrapping strategy because you can create them with limited resources and build an audience. So, you sell “simple” as a wonderful thing and coincidentally, it’s the only thing you have the resources to produce. Bootstrapping strategy has advantages in certain situations, however, it would not be good for long term strategy because there’s very few obstacles to prevent the next two-person startup from cloning your simple app, and because eventually you can’t fight human nature of wanting the features.

Success is a result of a combination of things: building an audience, evangelism, clean and spare design, emotional appeal, aesthetics, fast response time, direct and instant user feedback, program models which correspond to the user model resulting in high usability, and putting the user in control. All of these features share a common character of having benefits that customers like and pay for, but none of them can really be described as “simplicity.” With many years of experience running his own software company, Joe Spolsky saw that nothing he have ever done at Fog Creek has increased the revenue more than releasing a new version with more features. When a new version came out with new features, there was a sudden, undeniable, substantial, and permanent increase in revenue.

It is fine to use the term “simplicity” to refer to a product as meaning that the user model corresponds closely to the program model, so the product is easy to use. More, it is fine to use the term “simplicity” to refer to a product with a spare, clean visual appearance. However, if you think simplicity means “not very many features” or “does one thing and does it well,” you can’t go far with a product that deliberately leaves features out.

Article: https://www.joelonsoftware.com/2006/12/09/simplicity/

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

This blog from Microsoft Developer is related to what we are doing in class, specially to the final project. “Simplify REST API development for modern Single-page apps with SQL Server” by Jovan Popovic, talk about Single page app architecture, persisting JSON models in database.

First is single page app architecture – end-to-end, similarly to what we are doing in class, there are 3-tier pattern architecture in single-page applications.

Client-side is from users view, from web apps or mobile apps, this using frameworks or library such as Angular, JQuery, ect. This side executed and communicate with some middle application via REST API, then provides or accept data as JSON. JSON requests obtained from client-side and create some SQL queries to get or store data to the database.

If the client wants to get the data from the database, developer would need to add a few sub-layers in the applications layer. Developer would have some data access component to execute the query and fetch data, then some kind of “view model” to view the results of the query. The objects would take that information in JSON format to display to the client.

Second part is Persisting JSON models in database, as we know many modern web applications is running on the client side. We can use frameworks that enable developers to maintain state of the application on the client side. When the application saves the state being sent to the app layer via REST service.

To save the state provided by client-app, developer need to analyze JSON text from the client, use some data transfer objects and save data transfer objects into the database.

This blog cover mainly back-end of REST API. To show Built-in JSON functions in SQL and SQL Database, enable you to simplify your application layer code and work with database using the format that is already used on your client-side apps. I thought this blog somewhat useful since we learned about Angular, Node.Js and SQL in database class. I want to learn how all that fit in with each other. Web design really good and useful skill to have, specially this is how we view the internet though our eyes.

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.

We learned few techniques of testing in class such as Boundary Value Testing, Decision Table-Based Testing, Path Testing … however there are other techniques. In this article,  “Test Design Techniques overview” there are other techniques like Classification Tree Method, State Transition Testing, Cause-Effect Graphing, Scenario Testing. Different techniques are useful in different scenario.

Classification Tree Method. When to use it: we are testing hierarchically structured data or data in a form of a hierarchical tree. Identification of test relevant aspects and their corresponding values, then combination of different classes into test cases. Draw hierarchical classes as graph as shown below, then make projections of tests on a horizontal line using one of the combination of strategies.

           State Transition Testing. When to use it: a tester is testing the application for a finite set of input values, also test sequence of events that occur in the application under test. This will allow the tester to test the application behavior for a sequence of input values.

            Cause-Effect Graphing. When to use it: To Identify the possible root causes, the reasons for a specific effect, problem, or outcome. To set up, identify conditions and effects, draw the graph with all logical dependencies and constraints. Convert the graph into the decision table, tracing each combination of causes that lead to an effect from the effect. This technique helps us to determine the root causes of a problem or quality using a structured approach.

           Scenario Testing. When to use it: to help understand a complex system to test better where in the scenarios are to be credible which are easy to evaluate. Tester put yourself in the end user’s shoes and figure out the real-world scenarios and use cases. Before using scenarios for creating test cases, they are layout described using a template. Then create specific test cases using equivalence partitioning and boundary values techniques.

I like this article because the simple structure, and information with example. In the “Specification-Based Testing Techniques” section, different techniques divide into different group, and which scenario fit better to techniques. I think it’s would be better if there are example with the source code. We can look that the Test Techniques with real life scenarios, to have better understanding.

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.

For this week’s blog post I will be looking at another design pattern, this time called Façade. This time once again from the handy site of SourceMaking.com. The overall intent of the design pattern is to provide a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, wrapping a complicated subsystem with a simpler interface. The problem that faces it is a segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. Essentially façade discusses encapsulating a complex subsystem within a single interface object, thus reducing the learning curve necessary to successfully leverage the subsystem. The only access point for the subsystem will limit the features and flexibility that power users may need. The façade object should be a fairly simple facilitator. “Façade takes a “riddle wrapped in an enigma shrouded in mystery” and injects a wrapper that tames the amorphous and inscrutable mass of software.” With the quote from the site above the name really comes into play here. A good example of this would be something like that of a catalog. Where the consumer calls one number from the catalog and speaks with costumer service. The customer service representative acts as a façade, providing an interface to the order fulfillment department, the billing department and then the shipping department. Façade defines a new interface where in the Adapter design pattern it uses an old interface. The site/article then goes on to explain some general rules of thumb that can prove useful to those wanting to learn more or follow the design pattern even more. All and all the site is an excellent resource for anyone looking to learn more about design patterns and more with this article proving that with valuable information on a new design pattern I have not seen or used before.

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