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.

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 and used with permission of the author. All other rights reserved by the author.

Draw Your Own Map

Deciding your concentration when you are in college is one of the most important steps that a student can take. Understand that it’s not up to your career counselor, or your professors to decide for you. You can ask for help and opinions but deciding what you want, you have to do it by yourself. Draw your own map talks about how arriving at your next step and charting the course to ultimately arrive at your ideal destination is your responsibility. With your next career step identified, visualize the smaller, interim steps you need to take to move forward. It is vitally important that you take the first step even if it doesn’t seem that significant. That first step will generate the momentum that will help carry you toward your goals. It’s the willingness to take that first terrifying step (and all the other steps later on), even in the absence of a perfect plan, that turns your map from a daydream into reality.

Until late in my senior year I wasn’t sure what I wanted to continue my concentration on. So, what helped me was analyze my strong and weak points. What I enjoyed and what not. What education should I continue after I finished my bachelor and what possibilities are there for both cases. After much thought I decided that the subject that I enjoyed more was big data. A strong background in math and statistics will put you ahead of the pack. Also, the computer languages that I really enjoy are Python and R, which are two important ones in big data. I like to play around with visualization and analyzing datasets. For me, a dataset is more than numbers and characters. I like to discover the hidden connection behind it. This keeps me going and learn more.

 Remember, there isn’t one single path that all apprentices follow. Instead, successful apprentices follow paths that share a certain family resemblance. These resemblances do not happen because apprentices are inexorably shepherded into making the same decisions by their mentors. They happen because each apprentice, consciously or not, chooses their route through life based on an overlapping set of values.

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