Author Archives: Unknown

Introductory Blog Post

 Hello my Name is Sung Jin Kim doing my major of Computer Science for Bachelor’s degree. In this blog, i will be talking about Software Process management and how it is related to real life. 

I am hoping to meet everyone and those in the comment to share any of their experience.

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Introductory Blog Post

 Hello my Name is Sung Jin Kim doing my major of Computer Science for Bachelor’s degree. In this blog, i will be talking about Software Process management and how it is related to real life. 

I am hoping to meet everyone and those in the comment to share any of their experience.

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

 Links to evidence of activity on GitLab.

This is my frontend user interface for the report team

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend

I updated my frontend from sprint 2 in my local service which I used the sample frontend example from the professor. I have changed the background and move the start date and end date in the middle same as the common website let the user input the login information. 

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend

Austin and I connected the backend API to my frontend API, which can let customers download the report for the inventory. It got succeed download the report for the inventory when we connect the API together.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/35

My frontend design idea is based on the Worcester State University style of design. For the background picture and the color use, I followed the handbook of WSU style of design.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/67

I implemented FrontEnd for reporting with the most recent version.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/55

We Made some OpenAPI.yaml files for our FrontEnd and BackEnd.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/66

We looked over TheasPantryReport.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/71

We looked at the new architecture and plan accordingly.

Reflection on what worked well?

In Sprint 3, in terms of what worked well, the second phase was more efficient when team members worked together than ever before in completing the project plan. After a semester of teamwork, we have a deeper understanding of our ultimate goal and become more accustomed to each other’s habits. There will be a relaxed working atmosphere, and the team chemistry will encourage each other to push the project forward. The project progressed more smoothly, and the ZOOM meetings of the team were relatively frequent.

Reflection on what didn’t work well?

As for why it didn’t work out, there is a longer-term vision of the end product and the project’s future goals. Unfortunately, we failed to get the data of other groups. We made test data to run our report program. In addition, the team members were busy with other courses at the end of the semester, so there were some deficiencies in the adjustment of time in the later period. We had some confusion in the front end and back end docking. Through learning external materials and teamwork, we successfully solved the docking problem. Fortunately, we made timely adjustments and promoted the project objectives, and completed the group project.

Reflection on what changes could be made to improve as a team?

As a team with cooperation, smooth communication, and tacit understanding among team members are the basis and key to improving our team’s cooperation level. We would discuss the project after class and give some constructive suggestions about each other’s tasks. Good communication makes our team have chemistry. Through communication and cooperation, we have a thorough understanding of the team members’ tasks. Each knew the other’s project progress would be conducive to the overall advancement of the project. When a team member encounters a bottleneck in a task, we will appropriately slow down the overall progress and communicate with him to buffer his time to complete and push forward the overall task progress.

Reflection on what changes could be made to improve as an individual?

As an individual, I have watched and learned a lot about front-end production after class. It improves my front-end understanding and production skills, which helps my team better connect the front-end to the back-end. In this project, I learned and improved some problems encountered in team cooperation and realized the power of the team in finding and solving problems. In a team, the mutual understanding and tacit understanding among team members is the basic condition for the smooth operation of a team. It was a great honor for me to meet every team member in my last year of university, and I learned a lot of valuable experience from them in ZOOM meetings. At the same time, I am also very grateful to the professor for giving us an opportunity for a big team project, which benefited me greatly. I believe that I will bring my learning experience to my team in future team cooperation projects. Finally, I’d like to thank Worcester State University. It’s my great honor to be a member of the computer major.

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

Sprint 3 Retrospective

 Links to evidence of activity on GitLab.

This is my frontend user interface for the report team

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend

I updated my frontend from sprint 2 in my local service which I used the sample frontend example from the professor. I have changed the background and move the start date and end date in the middle same as the common website let the user input the login information. 

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend

Austin and I connected the backend API to my frontend API, which can let customers download the report for the inventory. It got succeed download the report for the inventory when we connect the API together.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/35

My frontend design idea is based on the Worcester State University style of design. For the background picture and the color use, I followed the handbook of WSU style of design.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/67

I implemented FrontEnd for reporting with the most recent version.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/55

We Made some OpenAPI.yaml files for our FrontEnd and BackEnd.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/66

We looked over TheasPantryReport.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/71

We looked at the new architecture and plan accordingly.

Reflection on what worked well?

In Sprint 3, in terms of what worked well, the second phase was more efficient when team members worked together than ever before in completing the project plan. After a semester of teamwork, we have a deeper understanding of our ultimate goal and become more accustomed to each other’s habits. There will be a relaxed working atmosphere, and the team chemistry will encourage each other to push the project forward. The project progressed more smoothly, and the ZOOM meetings of the team were relatively frequent.

Reflection on what didn’t work well?

As for why it didn’t work out, there is a longer-term vision of the end product and the project’s future goals. Unfortunately, we failed to get the data of other groups. We made test data to run our report program. In addition, the team members were busy with other courses at the end of the semester, so there were some deficiencies in the adjustment of time in the later period. We had some confusion in the front end and back end docking. Through learning external materials and teamwork, we successfully solved the docking problem. Fortunately, we made timely adjustments and promoted the project objectives, and completed the group project.

Reflection on what changes could be made to improve as a team?

As a team with cooperation, smooth communication, and tacit understanding among team members are the basis and key to improving our team’s cooperation level. We would discuss the project after class and give some constructive suggestions about each other’s tasks. Good communication makes our team have chemistry. Through communication and cooperation, we have a thorough understanding of the team members’ tasks. Each knew the other’s project progress would be conducive to the overall advancement of the project. When a team member encounters a bottleneck in a task, we will appropriately slow down the overall progress and communicate with him to buffer his time to complete and push forward the overall task progress.

Reflection on what changes could be made to improve as an individual?

As an individual, I have watched and learned a lot about front-end production after class. It improves my front-end understanding and production skills, which helps my team better connect the front-end to the back-end. In this project, I learned and improved some problems encountered in team cooperation and realized the power of the team in finding and solving problems. In a team, the mutual understanding and tacit understanding among team members is the basic condition for the smooth operation of a team. It was a great honor for me to meet every team member in my last year of university, and I learned a lot of valuable experience from them in ZOOM meetings. At the same time, I am also very grateful to the professor for giving us an opportunity for a big team project, which benefited me greatly. I believe that I will bring my learning experience to my team in future team cooperation projects. Finally, I’d like to thank Worcester State University. It’s my great honor to be a member of the computer major.

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

Reading list

The most valuable thing you can get out of any book is a list of other books worth reading. Over time, you will find that certain books keep popping up from the “bibliography”, and you should move those books to the top of the reading list. Other books will sink. Since the reading list is essentially a priority queue, you’ll eventually find that some books sink so far down the queue that you may never read them again.

Start by picking a broad book to give you a general idea of the subject you are aiming for. Then choose a few specific books to master the aspects of the topic that interest you.

Reading the right book at the right time will have a better effect. A lot of reading can improve your reading ability. You will also improve your knowledge of the outside world through reading. For computer science, reading a lot of the latest information will be of great help to your future work and research. Reading will improve your horizon and enrich your spare time.

Even if you read a good book on programming every two months, which is about 35 pages a week, it won’t take long for you to gain a deep understanding of our industry and differentiate yourself from everyone around you. — Steve McConnell, Code Complete

Focusing on the classics also carries a risk: you devote too much energy to them, at the expense of more pragmatic knowledge and information that would improve your everyday skills. Make sure to mix classics with modern, more pragmatic books and articles on your reading list.

In practice, algorithmic problems do not appear at the beginning of a large project. Then, all of a sudden, they appear as subproblems when the programmer doesn’t know how to proceed or when the current program is clearly inappropriate. — Steven S.Skiena, Scenario Analysis of The Algorithm Design Manual

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

Reading list

The most valuable thing you can get out of any book is a list of other books worth reading. Over time, you will find that certain books keep popping up from the “bibliography”, and you should move those books to the top of the reading list. Other books will sink. Since the reading list is essentially a priority queue, you’ll eventually find that some books sink so far down the queue that you may never read them again.

Start by picking a broad book to give you a general idea of the subject you are aiming for. Then choose a few specific books to master the aspects of the topic that interest you.

Reading the right book at the right time will have a better effect. A lot of reading can improve your reading ability. You will also improve your knowledge of the outside world through reading. For computer science, reading a lot of the latest information will be of great help to your future work and research. Reading will improve your horizon and enrich your spare time.

Even if you read a good book on programming every two months, which is about 35 pages a week, it won’t take long for you to gain a deep understanding of our industry and differentiate yourself from everyone around you. — Steve McConnell, Code Complete

Focusing on the classics also carries a risk: you devote too much energy to them, at the expense of more pragmatic knowledge and information that would improve your everyday skills. Make sure to mix classics with modern, more pragmatic books and articles on your reading list.

In practice, algorithmic problems do not appear at the beginning of a large project. Then, all of a sudden, they appear as subproblems when the programmer doesn’t know how to proceed or when the current program is clearly inappropriate. — Steven S.Skiena, Scenario Analysis of The Algorithm Design Manual

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

Detailed and basic usage of Mockito

 Mockito is a Mock framework for Java single-testing, but it can also be used with other single-testing frameworks in addition to JUnit. Mockito changes the behavior of a class or object, allowing us to focus more on testing the code logic without the effort of constructing the data.

The basic concept

Mocks can be of two types, Class and Partial,so Mockito is called spy. The behavior of changing methods on mock objects is called Stub.

A Mock process is called a Mock Session, and it records all the Stubbing. It consists of three steps:

+———-+ +——+ +——–+
| Mock/Spy | ===> | Stub | ===> | Verify |
+———-+ +——+ +——–+

Class Mock

A Class Mock changes the behavior of a Class so that the object it mocks completely loses its original behavior.

Method returns default values (null, false, 0, etc.) if it is not pegged.

The most basic usage is as follows:

1
2
3
4
5
6
7
8
9
10
11
12
import static org.mockito.Mockito.*;

// use List.class to creat a mock subject --- mockedList

List mockedList = mock(List.class);

//operation of mockedList

mockedList.add("one");
mockedList.clear();

//validation

verify(mockedList).add("one");
verify(mockedList).clear();

Partial Mock(spy)

If we only want to change the behavior of an instance, we need to use spy:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
List list = new LinkedList();
List spy = spy(list);

// optionally, you can stub out some methods:
when(spy.size()).thenReturn(100);

// using the spy calls *real* methods
spy.add("one");
spy.add("two");

// prints "one" - the first element of a list
System.out.println(spy.get(0));

// size() method was stubbed - 100 is printed
System.out.println(spy.size());

// optionally, you can verify
verify(spy).add("one");
verify(spy).add("two");

As you can see from the code, the main difference between a Spy and a MockSettings is that the MockSettings for a Spy needs to be passed in a SpiedInstance.

The default Answer to a spy is CALLS_REAL_METHODS, which means that if a method is not stub, it performs its real behavior.

The default Answer to a mock is RETURNS_DEFAULTS. Methods that are not stub return a default value.

source:

https://www.vogella.com/tutorials/Mockito/article.html

https://howtodoinjava.com/mockito/junit-mockito-example/

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

Detailed and basic usage of Mockito

 Mockito is a Mock framework for Java single-testing, but it can also be used with other single-testing frameworks in addition to JUnit. Mockito changes the behavior of a class or object, allowing us to focus more on testing the code logic without the effort of constructing the data.

The basic concept

Mocks can be of two types, Class and Partial,so Mockito is called spy. The behavior of changing methods on mock objects is called Stub.

A Mock process is called a Mock Session, and it records all the Stubbing. It consists of three steps:

+———-+ +——+ +——–+
| Mock/Spy | ===> | Stub | ===> | Verify |
+———-+ +——+ +——–+

Class Mock

A Class Mock changes the behavior of a Class so that the object it mocks completely loses its original behavior.

Method returns default values (null, false, 0, etc.) if it is not pegged.

The most basic usage is as follows:

1
2
3
4
5
6
7
8
9
10
11
12
import static org.mockito.Mockito.*;

// use List.class to creat a mock subject --- mockedList

List mockedList = mock(List.class);

//operation of mockedList

mockedList.add("one");
mockedList.clear();

//validation

verify(mockedList).add("one");
verify(mockedList).clear();

Partial Mock(spy)

If we only want to change the behavior of an instance, we need to use spy:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
List list = new LinkedList();
List spy = spy(list);

// optionally, you can stub out some methods:
when(spy.size()).thenReturn(100);

// using the spy calls *real* methods
spy.add("one");
spy.add("two");

// prints "one" - the first element of a list
System.out.println(spy.get(0));

// size() method was stubbed - 100 is printed
System.out.println(spy.size());

// optionally, you can verify
verify(spy).add("one");
verify(spy).add("two");

As you can see from the code, the main difference between a Spy and a MockSettings is that the MockSettings for a Spy needs to be passed in a SpiedInstance.

The default Answer to a spy is CALLS_REAL_METHODS, which means that if a method is not stub, it performs its real behavior.

The default Answer to a mock is RETURNS_DEFAULTS. Methods that are not stub return a default value.

source:

https://www.vogella.com/tutorials/Mockito/article.html

https://howtodoinjava.com/mockito/junit-mockito-example/

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

Use the Source

 When working on an open-source project, please get in the habit of downloading the latest version of the code (preferably from their source control system), so you can review its history and track future developments. Please take a look at the codebase structure and think about why it is organized the way it is. Look at how developers manage their code modules to see if it makes sense and compare them to how they might have used them. Try to refactor the code to understand why its coders made the decisions they did, and think about what the code would look like if you were the one coding it. It will give you a better understanding of the projects; Also, make sure you can build those projects. If you’ve found a better way to do something, you’re ready to contribute code to the project. Inevitably, as you go through the code, you’ll come across decisions you completely disagree with it. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider whether this is a legacy design that needs to be refactored; consider whether making a toy implementation for the relevant feature would help clarify the issue.

You end up with a toolbox filled with all sorts of quirks that you’ve collected from other people’s code. This will hone your ability to solve minor problems more quickly and quickly. You’ll be able to tackle issues that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the Git distributed source control system written by Linus Torvalds or any code written by Daniel J. Bernstein (known as DJB). Programmers like Linus and DJB occasionally use data structures and algorithms that most of us have never even heard of. They’re not magicians — they’ve just spent their time building bigger and better toolboxes than most people. The great thing about open source is that you can look at their toolbox and make their tools. One of the problems in software development is the lack of teachers. But thanks to the proliferation of open-source projects on sites such as SourceForge. Net and GitHub, you can learn from relatively representative code examples from the world’s programmer community.

In ODS, Bill Gates says: “The most subtle test of programming ability is giving the programmer about 30 pages of code and seeing how quickly he can read through it and understand it.” He realized something significant. People who quickly learn directly from the source code will soon become better programmers because their teachers are the lines of code written by every programmer in the world. The best way to learn patterns, idioms, and best practices is to read the open-source. Look at how other people to code. It’s a great way to stay relevant, and it’s free. — Chris Wanstrath at Ruby 2008 [

Pick an open-source project with deep algorithms, such as Subversion, Git, or Mercurial source control system. Browse through the project’s source code and jot down any algorithms, data structures, and design ideas that seem novel to you. Then write a blog post describing the project’s construction and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same concept can be applied?

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

Use the Source

 When working on an open-source project, please get in the habit of downloading the latest version of the code (preferably from their source control system), so you can review its history and track future developments. Please take a look at the codebase structure and think about why it is organized the way it is. Look at how developers manage their code modules to see if it makes sense and compare them to how they might have used them. Try to refactor the code to understand why its coders made the decisions they did, and think about what the code would look like if you were the one coding it. It will give you a better understanding of the projects; Also, make sure you can build those projects. If you’ve found a better way to do something, you’re ready to contribute code to the project. Inevitably, as you go through the code, you’ll come across decisions you completely disagree with it. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider whether this is a legacy design that needs to be refactored; consider whether making a toy implementation for the relevant feature would help clarify the issue.

You end up with a toolbox filled with all sorts of quirks that you’ve collected from other people’s code. This will hone your ability to solve minor problems more quickly and quickly. You’ll be able to tackle issues that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the Git distributed source control system written by Linus Torvalds or any code written by Daniel J. Bernstein (known as DJB). Programmers like Linus and DJB occasionally use data structures and algorithms that most of us have never even heard of. They’re not magicians — they’ve just spent their time building bigger and better toolboxes than most people. The great thing about open source is that you can look at their toolbox and make their tools. One of the problems in software development is the lack of teachers. But thanks to the proliferation of open-source projects on sites such as SourceForge. Net and GitHub, you can learn from relatively representative code examples from the world’s programmer community.

In ODS, Bill Gates says: “The most subtle test of programming ability is giving the programmer about 30 pages of code and seeing how quickly he can read through it and understand it.” He realized something significant. People who quickly learn directly from the source code will soon become better programmers because their teachers are the lines of code written by every programmer in the world. The best way to learn patterns, idioms, and best practices is to read the open-source. Look at how other people to code. It’s a great way to stay relevant, and it’s free. — Chris Wanstrath at Ruby 2008 [

Pick an open-source project with deep algorithms, such as Subversion, Git, or Mercurial source control system. Browse through the project’s source code and jot down any algorithms, data structures, and design ideas that seem novel to you. Then write a blog post describing the project’s construction and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same concept can be applied?

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