Category Archives: Week 3

Self-Directed Professional Development Post #3

For this week’s blog post, I’ve decided to learn more about API documentation. I found a YouTube video titled, “Get an overview of the Java API documentation and how to use it” in order to do this. The reason I picked this topic is because as I create and design programs/software, I will likely be referencing Java API documentation. Therefore it is important that I understand and know how to navigate this information. 

One of the first things this tutorial taught me is that the documentation I will be using will be under Java SE and not Java JDK. The speaker of this tutorial, Steve Perry, did not go too in depth into what Java JDK is so I ended up doing some additional research to learn more about JDK. JDK stands for Java Development Kit and it is a platform released  by Oracle Corporation to develop Java applications. Although this may seem like a trivial thing to learn, I appreciated learning more Java/programming jargon.

After explaining that the different classes in API documentation are grouped by modules, Steve selects the java.base module to walk through because of how commonly used it is. In modules, there are packages which are a group of related classes. The first package Steve introduces and reviews is the java.lang, which contains classes that are fundamental to the Java language. He explains that each package starts out with a description of the package, followed by its interface, classes, enumerations, exceptions, and errors. Steve also refers to the documentation of this particular class as a javadoc which is something I’ve heard before but now know exactly what it refers to. 

Steve then selects the String class, again, because of how commonly used it is. We then learn how to access String’s constructors and methods. Steve shows us how clicking on a method gives you more details, such as a method’s description, parameters, return values, etc. The last useful bit of information I learned from this video was how to access the information for classes if I don’t know what module or package they may be in. I can do this by using the index or clicking on the top left section titled, “All Classes” in order to do so.

Overall, I considered this to be a very worthwhile use of my time because API documentation is something I often get redirected to when I have a question about a particular class I’m using. However, since API documentation contains so much information, I often get overwhelmed and lost in all the classes and information available for a particular class. Because of this blog post and this tutorial, I was able to learn the organizational scheme for API documentation in a way that I will remember. Although it may seem like a small step, it’s a step that makes me a little more confident as a java programmer.

Tutorial link: https://www.youtube.com/watch?v=ULEOb8wLa_k

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

Analyzing Code Smells

This week, the topic that I wanted to focus on was design smells. I wasn’t confident in my own knowledge of what exactly design smells were or how to implement that knowledge into my designing of code. So I found a blog post by Sandor Dargo, in which he reviews the book Refactoring for Software Design Smells. Dargo’s blog has a background in software-design related book reviews, so it seemed like a good place to learn a little more about what design smells were.

The review covers a lot of the fundamentals of design smells, much like what we did in class, although it focuses more on what design smells affects within software design, such as understandability and reliability. I really liked this way of thinking about design smells, as simply learning them felt a lot more abstract to me, but showing what it affects and how it can harm the design of software makes it a little bit more understandable, to me at least. The first half of the post talks about the concept of technical debt, and the later half is more on the design smells. Obviously these both impact each other, but I liked his breakdown of technical debt as being similar to taking out a loan to get something done that needs to be done, but if you don’t keep up with that debt you will get further and further into debt until you fail. I think it is a very good analogy to technical debt, and aided in my understanding of the topic as a whole. The final part of the post focuses on common issues that are caused by design smells and how these seemingly insignificant things can make your code less and less usable over time.

I found this review to be extremely useful in my understanding of what design smells are and why code refactoring is so important. The most important aspect of this post to me was the discussion on technical debt. It is such an important aspect of software design to consider, as is allows us to make quick-and-dirty solutions when we need to, but also tells us how important it is to go back and change the code before it gets out of hand. We must design code in a way to make it as easy to use as possible, and easy to build on in the future. If we are able to properly document our code, allow for reusability within the system, and make use of abstraction and encapsulation to make code as simple to follow as possible, we can create an environment that can significantly increase not just our own workflow, but the workflow of any collaborators, or anyone who needs to make use of our code. It is our job as designers to make sure that as time goes on, our code gets easier to work with, especially as complexity increases to meet the demands of our clients.


Source:

https://www.sandordargo.com/blog/2021/01/30/refactoring-for-software-design-smells

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Software product development common mistakes to avoid

Software developers play a critical role in creating to deploying an application, the amount of works and effort that they have to put in is tremendous. Therefore, mistakes are inevitable. According to Hackernoon, a well-known blog for developers, there are seven pitfalls that developers should limit during the development and the solutions.

Planning fallacy (Time creep)
Time is essential while creating a product. Developers want to ship their applications on time and also not taking too much time to develop. The managers want them to meet the deadline without hitting any barriers. The best way to prevent time-consuming as the deadline loomed is to have the best time management. By doing so, we avoid running out of time at the end of the developing cycle and deploy the product on time.

Insufficient budget

Budgets, like time creep, can easily be overloaded if they are not kept in check. Time itself will exceed the cost since time is money. However, We don’t talk enough about this issue and it’s hard to find a good approach to solve the problem. Hence, limiting the time of development and the delays would eventually lead to narrow the cost of production.

Conflicting Communication

Since the pandemic started, we all feel like human interacting and communication have gotten less appreciated. We spent countless hours on video call conferences, did not have face-to-face interactions, and made the connection between us felt apart. As developers, we spend the entire day on laptops, and previously we already get so little human communication unless when we discuss the problem with our team. Pandemic widened that gap between developers and led to miscommunication between each team member. Working remotely makes it harder to express our ideas and thoughts to our team members. As the perception is not demonstrating enough, this might lead to communication breakdown and ultimately causes conflict among team members.

Security

Security has always been a big deal in this industry and especially to developers. Security vulnerability always exists. It’s part of software developer life. Software is among one of the most important things when it comes to secure user’s data. Billions of users have been affected by massive data breaches each year, showing that even big companies can sometimes make mistakes in developing the product. All we can do to minimize the risk of data breaches is to ensure the credibility of that software. By testing as often as developers could, they help cut back that possibility.

Many of the things in this blog is what I think is consequential to developers. More topics need to be covered, but personally, time, money, and security are needed to deserve more attention than the rest while developing a product in the Computer Science industry or in any other industry.

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

Boundary Value and Equivalence Class Testing

This week in the Software Quality Assur&Test class we got the third assignment that was about Boundary Values and Equivalence Class Testing. We had worked during class time in different activities that covered this assignment so I would say I really enjoyed working in this assignment. We had to complete three parts each with a different level of difficulty. I learned to understand more of the way testing works and what exactly get tested.

What we covered in this homework:

Boundary testing is the process of testing between extreme ends or boundaries between partitions of the input values.

Robust Boundary Values. Introducing outside of boundary values.

Equivalence Class Testing, which is also known as Equivalence Class Partitioning (ECP) and Equivalence Partitioning, is an important software testing technique used by the team of testers for grouping and partitioning of the test input data, which is then used for the purpose of testing the software product into a number of different classes.

Weak Normal Equivalence Class Testing: In this first type of equivalence class testing, one variable from each equivalence class is tested by the team. Moreover, the values are identified in a systematic manner. Weak normal equivalence class testing is also known as single fault assumption.

Strong Normal Equivalence Class Testing: Termed as multiple fault assumption, in strong normal equivalence class testing the team selects test cases from each element of the Cartesian product of the equivalence. This ensures the notion of completeness in testing, as it covers all equivalence classes and offers the team one of each possible combinations of inputs.

Worst-Case boundary value analysis is a Black Box software testing technique.

In Worst case boundary value testing, we make all combinations of each value of one variable with each value of another variable.

Edge Testing is a combination of Boundary Value Analysis and Equivalence Class Testing.

Weak Robust Equivalence Class Testing: Like weak normal equivalence, weak robust testing too tests one variable from each equivalence class. However, unlike the former method, it is also focused on testing test cases for invalid values.

Strong Robust Equivalence Class Testing: Another type of equivalence class testing, strong robust testing produces test cases for all valid and invalid elements of the product of the equivalence class. However, it is incapable of reducing the redundancy in testing.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Be The Worst

This time the pattern that I would like to write about is Be the Worst. I always thought about which is better, to be the worst on the best team or the best on the worst team? This pattern explains that is better to find a stronger team where you are the weakest member and have room to grow. When you are in a strongest team you learn from them and makes you feel perform better. The other members of that team will often prevent you from making mistakes, and help you recover from mistakes so smoothly that you won’t realize that you may not be learning as much as you think. 

I have been part of both cases. I have practice being the best in a group and vice versa and I would choose to be the worst any day. Personally, I’d rather be the weakest player in a strong team. That makes me look like a better player, and it helps me develop the skills to become a better player. When I worked in a project with some of my teammates that had more knowledge and experience than me, I was able to improve myself and learn some tips than books or videos would show me or learn you.

When you are in a group like this it is easy to forget, and you start compare yourself with the best and sometimes you feel stupid or not doing enough. I felt that in more than one occasion, but this pattern has reminded me another thing that I have forgotten. Your goal is to measure your abilities and find ways to be better than you were yesterday. We’re all on the same journey and comparing ourselves to others is useful only when it allows us to find ways to help each other improve.

I believe every pattern has its own good and bad sides. You can’t stay for a long time being the worst in a team because the phase where you learn ends and team moves on and so do you.  Being the worst on a team of outstanding developers can’t be compensated for with environment, equipment, or money. You can’t compensate for learning next to people who have already traveled the path and know how to avoid the holes on the road ahead. Pairing with great software developers is invaluable.

Source:
Apprenticeship Patterns by Adewale Oshineye; Dave Hoover, Be the Worst

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns

The book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye gives great solutions/patterns for problems often faced by software developers, mainly apprentices or beginners of the craft. I have enjoyed reading up to where I have gotten so far (Chapter 1 plus 2-6 introductions) and it has taught as well as clarified many ideas and methods. One thing I have never thought of is how your first language will affect how you will think and learn other languages in the future. While this may be the case, the more diverse knowledge you have, the more you will improve upon this fact. For example (given by the book), people who are more comfortable with object-oriented languages should explore functional languages. This will broaden your understanding and problem solving. Another pattern I found interesting was the Be The Worst pattern. This discusses your environment and its relation to your growth. Being on a team where you are the best or most skilled does not give you much room or motivation to improve as you will not be learning from your peers. It suggests keeping yourself in an environment/team where you are the least skilled. This forces you to catch up to your teammates so that you don’t hold them back as well as forces the habits, ideas, and information of your higher skilled teammates upon you. A few patterns that addressed things I already “knew” but clarified the process at which I should take are Expand Your Bandwidth and Reading List. If you want to be a software developer then you should already know that you will be constantly learning. Expand Your Bandwidth gives solutions on how to learn more than what your job teaches you. It gives examples such as joining online academic courses, following influential developers on social media, contacting authors and more. This gives you a starting point from which you can come up with your own ways of learning or just to boost you in the right direction. The other pattern, Reading List, gives great methods on organizing your book backlog. The first suggestion is to not only keep a list of books you wish to read but the ones that you have read as well. This allows you to keep track of the books you’ve read from which you can review and find gaps or trends in your learning. This can direct you/help decide what you should read next. The pattern also suggests that you keep your book list as a priority queue. If you find a book on a topic that would be more useful or has a higher urgency then put it at the top of the list. If the bottom of the list gets to the point where you will probably never read the books in those spots then thats okay because it clearly is not a priority. I like the way this book structures these patterns too. The authors organize these patterns into Context, Problem, Solution and Action. This makes it easier to understand rather than if they were just put into normal paragraphs.

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

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

Software Craftsmanship raises some of the thorniest and most
sensitive questions about software development and comes to the controversial
conclusion of finding answers in a system that has thrived for hundreds of years:
technology. Software Technology is a systematic
expression of the author’s ideas and attempts to answer the difficult questions
that have been plaguing the software industry. How should we restructure the
process of building software, such as we want it to be effective?

 

The author of Software Craftsmanship has been emphasizing
the role of the craftsman in the project. Craftsmen sounds is a very old word,
the craftsman in other industries is a what kind of person I want to say, must
be done in the field of a good man, I explain the below mentioned software
process artisans do what kind of person, craftsman is mentioned there is a very
rich in the process of software development experience, after years of
development, products are well received by customers, has a certain reputation,
they can submit a robust, high quality of the user application. A good
craftsman can make or break a project. This shows that the human factor plays a
very important role in the development of the project. Someone I have been
thinking without learning software engineering in software development has a
very important role in understanding of software engineering make me realize
software can also like assembly line engineering, development mode, people do
not development process, mainly the development process of software engineering
control, a relatively fixed process, as long as people do some mechanical work
can complete this project. In the current environment, software engineering
ideas are still dominant, but software technology ideas also have their base of
support, such as workers in the open-source community.

 

Software technology of the main pressure is a very important
role in the whole project, software process is very strict requirements of the
team, the team first small number, no more than 15 people, the general team is
three people, but for the team of personal ability request, the other teams
also are in high demand of health, a more stable team, team members can develop
the tacit understanding.

 

The book Software Craftsmanship gives us a good development
model, but many projects in the current environment are developed using
software engineering ideas. Why is this? In my analysis, the main reason is
that software technology requires too much of the team, and there are too few
excellent craftsmen, so it is difficult for many companies to organize such an
efficient team. Right now, the idea of software craftsmanship can only be seen
in the open-source community, where many of the true craftsmen are gathered.

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

Software Craftsmanship raises some of the thorniest and most
sensitive questions about software development and comes to the controversial
conclusion of finding answers in a system that has thrived for hundreds of years:
technology. Software Technology is a systematic
expression of the author’s ideas and attempts to answer the difficult questions
that have been plaguing the software industry. How should we restructure the
process of building software, such as we want it to be effective?

 

The author of Software Craftsmanship has been emphasizing
the role of the craftsman in the project. Craftsmen sounds is a very old word,
the craftsman in other industries is a what kind of person I want to say, must
be done in the field of a good man, I explain the below mentioned software
process artisans do what kind of person, craftsman is mentioned there is a very
rich in the process of software development experience, after years of
development, products are well received by customers, has a certain reputation,
they can submit a robust, high quality of the user application. A good
craftsman can make or break a project. This shows that the human factor plays a
very important role in the development of the project. Someone I have been
thinking without learning software engineering in software development has a
very important role in understanding of software engineering make me realize
software can also like assembly line engineering, development mode, people do
not development process, mainly the development process of software engineering
control, a relatively fixed process, as long as people do some mechanical work
can complete this project. In the current environment, software engineering
ideas are still dominant, but software technology ideas also have their base of
support, such as workers in the open-source community.

 

Software technology of the main pressure is a very important
role in the whole project, software process is very strict requirements of the
team, the team first small number, no more than 15 people, the general team is
three people, but for the team of personal ability request, the other teams
also are in high demand of health, a more stable team, team members can develop
the tacit understanding.

 

The book Software Craftsmanship gives us a good development
model, but many projects in the current environment are developed using
software engineering ideas. Why is this? In my analysis, the main reason is
that software technology requires too much of the team, and there are too few
excellent craftsmen, so it is difficult for many companies to organize such an
efficient team. Right now, the idea of software craftsmanship can only be seen
in the open-source community, where many of the true craftsmen are gathered.

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

Software Craftsmanship raises some of the thorniest and most sensitive questions about software development and comes to the controversial conclusion of finding answers in a system that has thrived for hundreds of years: technology. Software Technology is a systematic expression of the author’s ideas and attempts to answer the difficult questions that have been plaguing the software industry. How should we restructure the process of building software, such as we want it to be effective?

 

The author of Software Craftsmanship has been emphasizing the role of the craftsman in the project. Craftsmen sounds is a very old word, the craftsman in other industries is a what kind of person I want to say, must be done in the field of a good man, I explain the below mentioned software process artisans do what kind of person, craftsman is mentioned there is a very rich in the process of software development experience, after years of development, products are well received by customers, has a certain reputation, they can submit a robust, high quality of the user application. A good craftsman can make or break a project. This shows that the human factor plays a very important role in the development of the project. Someone I have been thinking without learning software engineering in software development has a very important role in understanding of software engineering make me realize software can also like assembly line engineering, development mode, people do not development process, mainly the development process of software engineering control, a relatively fixed process, as long as people do some mechanical work can complete this project. In the current environment, software engineering ideas are still dominant, but software technology ideas also have their base of support, such as workers in the open-source community.

 

Software technology of the main pressure is a very important role in the whole project, software process is very strict requirements of the team, the team first small number, no more than 15 people, the general team is three people, but for the team of personal ability request, the other teams also are in high demand of health, a more stable team, team members can develop the tacit understanding.

 

The book Software Craftsmanship gives us a good development model, but many projects in the current environment are developed using software engineering ideas. Why is this? In my analysis, the main reason is that software technology requires too much of the team, and there are too few excellent craftsmen, so it is difficult for many companies to organize such an efficient team. Right now, the idea of software craftsmanship can only be seen in the open-source community, where many of the true craftsmen are gathered.

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

Apprenticeship Patterns

We are at the point of life that in a few years we all be fully working adults. It is crazy to think that 4 years of college just flew by so fast. This semester the software capstone class will be the most interesting and challenging I believe. When it comes to reading a book, I have no patience at all, but after reading the introduction, something about this book: Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman is making me want to read it appropriately. It is possible to be that I can relate to this book on so many levels and it is relevant to me. After just reading the introduction I feel like it changed the way I think and view my profession.

All the patterns in the book are interesting and powerful in a way that we can adapt and combine these patterns in many ways and situations. One of the patterns that stood out to me the most was “Be the worst” from chapter four. The author has explained the concept very well in which it states that “Surround yourself with developers who are better than you. Find a stronger team where you are the weakest member and have room to grow” This statement Is very interesting and when I think deep into it, I believe that being worst in a team at least for me is a motivation to work hard and grow to improve. The goal is not to stay the weakest but instead work my way from the bottom to the top.

The author also talked about the risk factor that associates with being worst in the team including dragging the team down, good teams do not tolerate you, and the risk of being fired. Although I do agree that in situations all these scenarios could be possible but on the positive side this can motivate a person to improve and build a mindset that helps the individual. I do not think I disagree with any aspects of the pattern but, these patterns and the whole book have certainly changed the way I think about a certain aspect of software development. I realized that I need to work even harder and push myself to the limits for me to get where I want in life.

 

 

 

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.