Sprint Retrospective 1 – Libre Food Pantry

The first sprint for the Libre Food Pantry software went very well for the most part. Since it was a spike sprint, it was mostly looking up tutorials, making sample projects, and brainstorming ideas.

What worked well for me was that I found a great tutorial on Node.js with Express which also shows you how to connect to and use a MongoDB database. This tutorial gave me a great foundation on how to run a server and handling HTTP requests. The tutorial had great explanations of why we are doing each thing step by step while other tutorials lack such explanations and just show you how to do whatever you are trying to do. From this tutorial I made a To-do list web application using Express, MongoDB, Ajax (Ajax code was provided from a source), Mongoose, and EJS(Embedded JavaScript) as practice for the Libre Food Pantry backend and also to make my skill/understanding more solid by practicing everything I learned from the tutorial. This also gave me a reference to look back on if I ever forget how to do a certain thing.

What did not go so well was my understanding of the project as a whole/how it all fits together. Studying the architecture of the project a few times did not do it for me. It took a while but learning Express, eventually asking my teammates about the technologies they are working with, how they fit in with the rest of the project and studying the architecture again after each new piece of knowledge finally helped it all click.

Some things my team and I could improve on would be to be more interactive on GitLab. By the time we made a repository to upload all of our progress, it was more than half way through the sprint. This meant that we could not review what our teammates were doing and have an understanding of our progress as a team. Also, our communication and teamwork could have improved as well. Instead of working on individual sample projects, we all should have worked together on a single sample project using everything that we learned. This would have been a better learning experience for us since that is what we will be doing eventually for the main project. We also could have had better communication with the product owner. I felt at times that not just me but my whole team was confused or stuck with what was wanted/expected from us. Towards the end of the sprint we eventually asked the product owner some important questions that really helped us move forward for the next sprint. Since we were mostly learning the foundation for new technologies this sprint it did not necessarily effect our productivity, but our motivation and confidence.

A change that I could make as an individual is to improve on communication. I felt that I did not have a good understanding of the technologies that my teammates were researching and how they intertwined with what I was working on. For example I did not understand what RabbitMQ was and what it had to do with the project when all I had to do was ask my teammate researching it to explain. Eventually towards the end of the sprint I did this and it helped my understanding of the project greatly.

Links:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Backend/NodeJSTutorial/NodeJSPractice – Repository where I uploaded files from each tutorial video.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Backend/TodoListApp – Repository holding files for the to-do list web application

https://www.youtube.com/playlist?list=PL4cUxeGkcC9gcy9lrvMJ75z9maRw4byYp – The tutorial I used for my sample to-do list app.

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.

Sweep the Floor

            In the “Sweep the Floor” learning pattern of the Apprenticeship Patterns book focuses on the transition when joining a team. Being the newbie is not an easy task, especially when unsure of your skills, so finding your place and claiming suitable work can be a struggle at times. Since I will hopefully be joining a software development team in the coming years, or even next year as an intern, getting accustomed to working on a team and proving my value while not finding myself in too deep on work that I am not ready for will be a somewhat tricky line to toe. This pattern focuses just on that.

            The idea of sweeping the floor, while not meant to be taken literally, can be a literal task. It means to take the tasks that need to be done but no one wants to do. This can either be menial tasks or simply tasks that are painfully boring or something. Although not attractive, this can be a way to start making progress on a team and pay your dues. It can help gain the trust of the team if the tasks are done well, oftentimes because they can be important sub-tasks which free up the way for higher-level developers to make more meaningful progress, so they’re still quite important.

            Having the humility to take on tasks like this is not something I’m worried about; I do not come into the field with a large ego. I knew nothing about computer science before I started my major. I’m not afraid of having to build from the ground up. I’m actually quite eager to. Others’ evaluation of my work will be the most valuable to me, a concept which is alluded to in many other learning patterns within the book. I think this is a great idea and helps carve out a position on a team which can only stand to grow.

            It’s also important to consider the downsides that the pattern mentions as well. Becoming the one that other developers dump the meaningless/annoying tasks on is clearly not the goal, so making sure to not get complacent and expressing an eagerness without overstepping bounds is essential. Nevertheless, I love this idea and plan on going through with it once I join a software development team.

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

The Long Road

 When working on an open-source project, 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. Take a look at the structure of the codebase and think about why the code is organized the way it is. Take a look at the way developers organize their code modules to see if it makes sense, and compare it to the way they might have used it. 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. Not only will it 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. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider the possibility that this is a legacy design that needs to be refactored; And 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 small problems more quickly and quickly. You’ll be able to tackle problems that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the code for 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 make use of 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 your own. 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 very important. 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 structure of the project and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same idea can be applied?

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

The Long Road

 When working on an open-source project, 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. Take a look at the structure of the codebase and think about why the code is organized the way it is. Take a look at the way developers organize their code modules to see if it makes sense, and compare it to the way they might have used it. 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. Not only will it 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. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider the possibility that this is a legacy design that needs to be refactored; And 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 small problems more quickly and quickly. You’ll be able to tackle problems that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the code for 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 make use of 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 your own. 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 very important. 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 structure of the project and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same idea can be applied?

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

The Long Road

 When working on an open-source project, 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. Take a look at the structure of the codebase and think about why the code is organized the way it is. Take a look at the way developers organize their code modules to see if it makes sense, and compare it to the way they might have used it. 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. Not only will it 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. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider the possibility that this is a legacy design that needs to be refactored; And 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 small problems more quickly and quickly. You’ll be able to tackle problems that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the code for 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 make use of 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 your own. 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 very important. 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 structure of the project and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same idea can be applied?

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

Transpiler

 Transpilers, or source-to-source compilers, are tools that read source code written in one programming language and generate equivalent code in another language with a similar level of abstraction. A good example of a translator is the TypeScript translator, which translates TypeScript code into JavaScript. The Babel compiler can also be used for ES6 JS code to ES5 JS code.

Compilers also translate code from one language to another, but the level of abstraction is very different between the two languages. For example, compile from .java to .class files.

ES6 and ES5

To understand the translator, you must first understand the difference between ES6 and ES5 JavaScript. ES6 (ECMAScript 6) is the specification for the next version of JavaScript. Some of its major enhancements include modules, class declarations, lexical block scopes, iterators and generators, a commitment to asynchronous programming, deconstructing patterns, and appropriate tail calls.

The features are great, but most browsers do not support the specification until now. As a result, any UI application specification written in ES6 will not work in most browsers. To run these applications, you must convert this ES6 source code to the supported JavaScript version ES5. ES5 is supported by almost all browsers and is by far the most stable version.

ES6 – Brings “types” to JavaScript. Make it closer to strongly typed languages such as Java and C#. So far, most browsers don’t support it. It must be converted to ES5 to execute in the browser.

ES5 – Over the years, we’ve been writing plain JavaScript.

Translation unit

A compiler is a program-like compiler that converts ES6 JavaScript code into ES5 JavaScript code to run in a browser. When the compiler sees an expression that uses the language functionality that needs to be translated, it generates a logically equivalent expression. The resulting expression can be very similar to or very different from the source expression.

What does a translator do?

ES6 code => ES5 code (even ES4, ES3)

Sources

https://scotch.io/tutorials/javascript-transpilers-what-they-are-why-we-need-them

https://devopedia.org/transpiler

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

Transpiler

 Transpilers, or source-to-source compilers, are tools that read source code written in one programming language and generate equivalent code in another language with a similar level of abstraction. A good example of a translator is the TypeScript translator, which translates TypeScript code into JavaScript. The Babel compiler can also be used for ES6 JS code to ES5 JS code.

Compilers also translate code from one language to another, but the level of abstraction is very different between the two languages. For example, compile from .java to .class files.

ES6 and ES5

To understand the translator, you must first understand the difference between ES6 and ES5 JavaScript. ES6 (ECMAScript 6) is the specification for the next version of JavaScript. Some of its major enhancements include modules, class declarations, lexical block scopes, iterators and generators, a commitment to asynchronous programming, deconstructing patterns, and appropriate tail calls.

The features are great, but most browsers do not support the specification until now. As a result, any UI application specification written in ES6 will not work in most browsers. To run these applications, you must convert this ES6 source code to the supported JavaScript version ES5. ES5 is supported by almost all browsers and is by far the most stable version.

ES6 – Brings “types” to JavaScript. Make it closer to strongly typed languages such as Java and C#. So far, most browsers don’t support it. It must be converted to ES5 to execute in the browser.

ES5 – Over the years, we’ve been writing plain JavaScript.

Translation unit

A compiler is a program-like compiler that converts ES6 JavaScript code into ES5 JavaScript code to run in a browser. When the compiler sees an expression that uses the language functionality that needs to be translated, it generates a logically equivalent expression. The resulting expression can be very similar to or very different from the source expression.

What does a translator do?

ES6 code => ES5 code (even ES4, ES3)

Sources

https://scotch.io/tutorials/javascript-transpilers-what-they-are-why-we-need-them

https://devopedia.org/transpiler

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

Transpiler

 Transpilers, or source-to-source compilers, are tools that read source code written in one programming language and generate equivalent code in another language with a similar level of abstraction. A good example of a translator is the TypeScript translator, which translates TypeScript code into JavaScript. The Babel compiler can also be used for ES6 JS code to ES5 JS code.

Compilers also translate code from one language to another, but the level of abstraction is very different between the two languages. For example, compile from .java to .class files.

ES6 and ES5

To understand the translator, you must first understand the difference between ES6 and ES5 JavaScript. ES6 (ECMAScript 6) is the specification for the next version of JavaScript. Some of its major enhancements include modules, class declarations, lexical block scopes, iterators and generators, a commitment to asynchronous programming, deconstructing patterns, and appropriate tail calls.

The features are great, but most browsers do not support the specification until now. As a result, any UI application specification written in ES6 will not work in most browsers. To run these applications, you must convert this ES6 source code to the supported JavaScript version ES5. ES5 is supported by almost all browsers and is by far the most stable version.

ES6 – Brings “types” to JavaScript. Make it closer to strongly typed languages such as Java and C#. So far, most browsers don’t support it. It must be converted to ES5 to execute in the browser.

ES5 – Over the years, we’ve been writing plain JavaScript.

Translation unit

A compiler is a program-like compiler that converts ES6 JavaScript code into ES5 JavaScript code to run in a browser. When the compiler sees an expression that uses the language functionality that needs to be translated, it generates a logically equivalent expression. The resulting expression can be very similar to or very different from the source expression.

What does a translator do?

ES6 code => ES5 code (even ES4, ES3)

Sources

https://scotch.io/tutorials/javascript-transpilers-what-they-are-why-we-need-them

https://devopedia.org/transpiler

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

Sprint 1 Retrospective

Links to evidence of activity on GitLab.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Frontend

I created a sample frontend using vue.js and learned how to build up the environment and set up a sample project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Frontend

I learned how to create a climate for vue.js on Udemy and Youtube to set up my vue.js settings. I used my tutorials to build my first sample project.

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

I am working with Migena for the Small Frontend, which is going to test the login feature with keycloak. We will use vue.js to build the Frontend and the third-party system, keycloak to test it. We will see how a real example of securing our system with keycloak. Our goal is to build a simple frontend to test keycloak.

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

I will keep meeting with the other teams working on the Frontend to discuss the Frontend’s style, format, and other components.

Reflection on what worked well?

The reflection on what worked well is that we work together with the team members we have worked with before to complete the project plan. Because we have worked together in the same group before, we have a deeper understanding of our teammates and are more accustomed to each other’s habits. There will be a relaxed and happy working atmosphere in the group, and the chemistry between the groups will encourage each other and push the project forward.

Reflection on what didn’t work well?

The reflection on what did not work well is that we didn’t know much about the project initially and thought it was a big project. When faced with the unknown challenge, we were a little confused at first. As we got to know each other and started to move forward with the project, we found that labor division was not reasonable. Because in many issues, Frontend and backend are related. Being responsible for each task affects productivity. So we have overlapping project leaders working together to complete the job, which leads to increased efficiency. It was difficult or challenging to push the task forward, but we encouraged each other through the ZOOM meeting after class.

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

As a team with cooperation experience, 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 together.

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

As an individual, I need to improve my understanding of the Frontend more quickly to help my team better connect Frontend and backend. I need to arrange my group tasks more reasonably to help promote the whole group project’s completion. Besides, I also need to make clear my work objectives, continue to follow up on the team’s project, and make my part and the whole develop simultaneously. 

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

Sprint 1 Retrospective

Links to evidence of activity on GitLab.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Frontend

I created a sample frontend using vue.js and learned how to build up the environment and set up a sample project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Frontend

I learned how to create a climate for vue.js on Udemy and Youtube to set up my vue.js settings. I used my tutorials to build my first sample project.

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

I am working with Migena for the Small Frontend, which is going to test the login feature with keycloak. We will use vue.js to build the Frontend and the third-party system, keycloak to test it. We will see how a real example of securing our system with keycloak. Our goal is to build a simple frontend to test keycloak.

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

I will keep meeting with the other teams working on the Frontend to discuss the Frontend’s style, format, and other components.

Reflection on what worked well?

The reflection on what worked well is that we work together with the team members we have worked with before to complete the project plan. Because we have worked together in the same group before, we have a deeper understanding of our teammates and are more accustomed to each other’s habits. There will be a relaxed and happy working atmosphere in the group, and the chemistry between the groups will encourage each other and push the project forward.

Reflection on what didn’t work well?

The reflection on what did not work well is that we didn’t know much about the project initially and thought it was a big project. When faced with the unknown challenge, we were a little confused at first. As we got to know each other and started to move forward with the project, we found that labor division was not reasonable. Because in many issues, Frontend and backend are related. Being responsible for each task affects productivity. So we have overlapping project leaders working together to complete the job, which leads to increased efficiency. It was difficult or challenging to push the task forward, but we encouraged each other through the ZOOM meeting after class.

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

As a team with cooperation experience, 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 together.

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

As an individual, I need to improve my understanding of the Frontend more quickly to help my team better connect Frontend and backend. I need to arrange my group tasks more reasonably to help promote the whole group project’s completion. Besides, I also need to make clear my work objectives, continue to follow up on the team’s project, and make my part and the whole develop simultaneously. 

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