Author Archives: Johnny To

Sprint Retrospective – Round Four

            A reflection
on what I learned from this week’s sprint is that a poorly managed repository
will create problems for your team and slow down the progress. After translating
the work done in Java to Angular during our restart from last sprint. The initial
IDE used was an online IDE called StackBlitz however this was abandoned for
WebStorm a week later. This is because we weren’t able to successfully connect
it to any repository so that other members could make changes. At this point,
we downloaded a copy and started to transition into WebStorm.

            During this
transition, we decided to get a working copy into the GitHub so that everyone
from both groups can work on it. 
However, we did not make note that a properly structured repository is
important. In this iteration of the repository, the root folder did not include
all the necessary files needed to function correctly. The necessary files were
not exactly missing from the upload but rather located in the only other
subfolder. This subfolder was generated since we downloaded a copy from StackBlitz.
By placing this subfolder into the original root folder, we had plenty of
workarounds to make the project work normally.

            At this
point in time, instead of importing the root folder to start working on the
project, we imported the subfolder. This was a workaround since it treated the
subfolder like the root, so it functioned normally. In this folder, it also
contained a git ignore file that could not be used since it was located in
there. This meant that the node modules folder was also included to be committed
back into the repository. In the majority of cases, it is not recommended to commit
that folder, but little did we know what was happening.

           In the end, the Professor and another member managed to get a working copy sorted and uploaded to the master. Now it is structured with all the necessary files in the root and two other subfolders, one for backend and one for frontend. It is neat and easy to navigate, which meant that we would be able to easily pinpoint where new services and components can go. At this point, we don’t have to worry that making changes would risk breaking the builds that other members spent time working on. In the future, I will not let this situation happen again and will be more careful when structuring a project!

            During this sprint, I focused my efforts on creating a submission service. Currently, the intake form includes a submit button that only returns what the user has inputted in the form into a new page. I started using an Expressjs server, which has allowed me to get use simpler features to connect the main form with a local server. Eventually, the default url address should be directed to an actual server. In this current iteration of the intake form, it sends the array to the localhost at port 3000. By running both the server and the intake form in WebStorm and submitting a completed form. We can see that the array of data is now retrievable on the server, which can be seen in WebStorm’s terminal for the server. If everything goes smoothly we can most likely store the data into some form of non-volatile memory later on.

References:
https://expressjs.com/

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

It was there, the whole time.

For the tenth and final week of reading, I chose to read the pattern, Use the Source. This pattern focuses on the problem that without the presence of good source code to study, practice, and emulate, you can’t get better, and you might continue developing bad habits you didn’t know you have. The solution provided is to find another person’s code and start reading them. This will enable you to learn how they wrote their code and understand the thought process that made that code. The recommendation includes examining open source projects and examining them for why they work in such a way. Also, to attempt and refactor codebases to understand the decisions programmers make and why they didn’t choose a different way. This process also leads to why there is appreciation for code reviews and pair programming. Having other people read your code, you read theirs, everyone can learn from each other. Allowing yourself to get a feel for good and bad code, you can develop a better understanding of yourself and how to improve.

This pattern is interesting because I never thought about using open source projects as a way of learning. I always took open source projects as a way of getting things from the community and as a way of contributing back to the project. However, using it as a way of reading well maintained code, reading practice, and understanding the thought process is a creative way of using publicly available projects.

This pattern is also useful because once you have seen the code, you might remember it for later as the code is not textbook examples. Examining, dissecting, and understanding code from real world projects allow you to see more, retain more, and most likely apply it in your own code later on.

The pattern has caused me to change the way I think about my intended profession because there are many different ways of improving yourself as a software developer. Being on the look out for readily available information and tools and being creative with the resources you do have access to can make a difference. As such, this pattern is incredibly helpful at showing that sometimes resources for learning can be right in front of you, you just weren’t creative enough to know it was there from the start.

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

Sprint Retrospective – Round Three

A reflection on what I learned from
this week’s activities is that sometimes it’s best to restart. Our initial two
sprints brought us up to a point where the current delivery is usable but could
not be built upon. We had trouble trying to incorporate features from each of
our own work loads that was divided in Trello. The main issue from the scrapped
delivery is that it is written in Java and missing fundamental components that
would make it difficult to create a webpage with. As such, the problem resolved
after deciding to focus our efforts on Angular and using it’s features to make
our lives easier.

Another lesson learned from this week’s
activities is that having more than one repository between two GitHub and GitLab
is a nightmare. It was a mix between each of the members uploading to our own
repositories to share mockups of things we have created during the sprint. This
choice is backed by us not feeling up to upload mockups directly to the repository
made by the professor since we weren’t “feeling ready” yet.  Then there is the issue with having two different
food pantry repositories which further confused everyone. However, this issue was
eventually resolved when the professor and some students came up with another idea
for handling the repositories. The new system creates a fork from the main
project to the class repository. There are a couple other things mentioned
about incorporating “stories” using this setup that I have yet to fully
understand.

The third lesson learned from this
week’s activities, is that it is very easy to get lost and sidetrack from the
main goal. This lesson is mainly for myself as I was working on the database
but took me an entire sprint to realize that I was working on the wrong portion
of the project that was unneeded at the moment. Focusing unnecessary resources towards
a feature that should be left for later. The other members were focused on the
intake form and had created the front-end of it but needed a place to store the
information later on. This is the area I should have tackled, in which our
members would have been working in unison.

During this sprint, I focused my efforts on mainly establishing a connection to the SQLite database created from the previous sprint with the current project. Using JAVA and the available JDBC library found on the web, I was able to successfully connect to the database. However, when it came to transfer what I learned into the main project we were working on gave plenty of errors. There were missing libraries and many unused and preplanned files that needed deletion. Although this was a problem, the next problem is mentioned earlier in the blog. We needed a clean slate to work with since the project was in an unworkable state. After we got back to the point where we were in JAVA, now in Angular, I had to find a new way to get the SQLite database to work in Angular. Now that we are back on track, I can see where the project is likely headed!

References:

http://www.sqlitetutorial.net/sqlite-java/sqlite-jdbc-driver/

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

Record, Revisit, Retain

For the ninth week’s reading, I chose to read the pattern, Record What You Learn. The problem this pattern addresses is keeping a journal or history of what you learned but not casting it aside. It suggests that a journal, personal wiki, or blog of lessons can help you in the future. This can be either for mentoring purposes, or a source of information for yourself and others. However, the biggest trap stated is that you will write down the lesson and forgetting them. The next step of writing them down is to revisit them regularly and review what you have written down. Eventually, the outcome is that you will achieve an accurate self-assessment of what you actually know. An example of a successful journal is about a guy named Dave who kept quotes that shaped his learning and eventually totaled over 500 quotes. With this he was able to share it with others and was helpful when he started writing articles and this book in particular!

What I found useful about this article is that it made me do a self-assessment on the spot about how I’m currently retaining information from school. Notes, projects, presentations, and papers are all evidence that I have been actively involved in my learning. However, once the course has finished, all those notes, papers, projects, and presentations are forever locked away in my drive, closet, or thrown away. Valuable information that could be useful in the future is now stacking up somewhere that can’t be maintained in a practical way.

What I found interesting about this article is the portion of the personal wiki. I did not know that you could create a personal wiki and it answered a question along the way. The question is what happens if there is something you learned but don’t want to share publicly. As such, you could have private and public records with no issues. This sparked an interest for myself, as I need a breakable toy to mess around with and learn but didn’t want to create a blog from scratch to do the job. Overall, this pattern is meaningful as it’s a good place to start if you don’t have anywhere to begin.

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

Balancing solo-work and team-work

For the eighth week’s reading, I chose to read the pattern, Confront Your Ignorance. This pattern takes on the problem that you have gaps in your skillset that is needed for the job. These could be tools or techniques that you are already expected to know but you don’t and need a place to begin. The solution to this problem is custom to the person in need, there are many different ways to start. Two ways suggested are trying to start with introductory material or jumping straight into hands on learning. It is mentioned that even if you are doing this in private to learn and apply it in the workspace, there are issues that could arise. One is that you are using work project experience for private projects solely for yourself and not the team. Another would be that the team will not be able to help you, learn with you, or help you along the way. As an apprentice, you should be learning in public where others can see the way you work.

The interesting part of this pattern is about the negative side effects from learning in private. When you work as a team, it is expected that you fail together, learn together, and learn from each other. By working solo and focused on improving your own performance, you are neglecting your team in the process. Another negative would be that you chose to implement a feature or system that has already been created elsewhere. By implementing your own version of it, the other members of your team are now required to learn from you about the system. This is a drawback and should be carefully considered when valuing your company’s resources and teammates workload.

This pattern has caused the way I think about my intended profession because there is a need for balance in terms of solo and team activity. If the workload shifts towards solo, then you aren’t benefiting your community. But if the workload shifts towards the team, then you are over reliant on the team. What I learned is that, you must know how to balance your learning such that everyone is winning in the end.

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

Can you walk the walk?

For the seventh week’s reading, I chose to read the pattern, Concrete Skills. This pattern focused on the problem where you want to work on a talented team to learn more and improve yourself. However, the risk of hiring someone who may not contribute directly to the work and could be a baggage is too high. The solution to this is to “acquire and maintain” concrete skills. Examples of these concrete skills are as listed “writing build files in various popular languages, knowledge of various popular open source frameworks like Hibernate and Struts, basic web design, JavaScript, and the standard libraries in your language of choice”. The objective of these concrete skills is to present enough understanding of what you can do on day one. This will provide a chance where your likelihood of being hired is increased. However, when you are hired, you do not have to repeat the steps in the future because you likely have built a reputation and portfolio with your current job. As such, credibility has been established and should prove to future teams that you can be useful on day one.

What I found interesting about this pattern is that it mentions “getting past crude HR filters and managers who construct teams by playing buzzword bingo”. This relates to stories I heard of HR or managers who do not have enough knowledge to do the hiring but is placed in a position to do so. As such, they would deploy tricks and systems, or “filters” in order to find the people they need. Another interesting point brought up by this pattern is the action provided at the bottom. It states that we should note discrete skills that could be useful right away for the team that you want to join. I do believe this is a good strategy to be on top of knowing what skills you can bring to the table.

This pattern has not caused me to change the way I think about the intended profession because this also useful for other professions. The process of hiring people onto a team is always a risk in one way or another. Systems are brought into place because they want to avoid issues off the bat from a new hire, as such you have to demonstrate that you can do the job they expect of you.

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

Sprint Retrospective – Round Two

            A reflection
on what I learned from this week’s activities is that when the working mindset
begins it goes quite smoothly. Once everyone settles in and breaks the ice, we
are able to communicate clearly and effectively what our intentions are and how
we are to go about it. When a certain task is finished, other members are notified,
and opinions are needed before we go any further with the task or beginning a
new one. When we get proper feedback, we are able to safely continue down the
path or create a new one to account for changes.

            Another
lesson learned from this week’s activities is that members will tend to focus
on tasks that they are comfortable with first. In my case, since no one was
comfortable picking up the role on working with databases, I felt confident and
comfortable enough to pick up the task. As for the other group members, they
also went off in the direction that would prove most beneficial to the group.
This way, the group will spend less time learning material that other members
are clearly proficient enough to get started. After that, we are able to
converse and teach our knowledge with the rest of the group members which is
quite efficient.

            In light of
this lesson learned, the next time there is a situation where the group is
clearly new to each other, and a project is being newly developed. It should be
safe to assume that everyone is not comfortable with each other yet and needs
time to adjust to the new environment and mindset. In this case, there is no
need to be anxious about the project over the course of several weeks as the
working process will natural come.

            During this
sprint, my task was mainly focused on creating a design for the database. This involved
reviewing materials provided by the client and any requirements or constraints that
are to be noted. The chosen route when creating a database to account for Database
Management System (DBMS), as such an E-R Model is required. The chosen platform
for the database is SQLite, we noted the importance of being able to export the
database file as a CSV file and vice-versa. Being able to obtain a CSV file is
important for the client as it’s their preferred filetype for distributing
information.

            Starting
off, I noted for four entities, staff, client, inventory, and items. In the
staff entity, it contained the attribute OneCard_ID
and a composite attribute Name which
accounted for First, Middle, and Last Name of the staff member. For the
client, it contains all of the attributes of the staff entity but introduces a
third attribute called Last Visit Date,
to account for information regarding the last time the client visited the food
pantry. Then you have the inventory entity which only contains the attribute Total Weight, since the pantry uses weight
to keep track of how much food is in stock. Lastly, the items entity contains
five attributes, Item ID, Item Name, Item
Weight, and Item Stored Date
. However, to account for a concern from the client
about confidentiality of information the names of staff and clients are later
crossed off from the E-R Model. In conclusion, after consulting the group, the
next step is to create and connect the database with the project in order to
fully utilize its intended function.

            Starting off, I noted for four entities, staff, client, inventory, and items. In the staff entity, it contained the attribute OneCard_ID and a composite attribute Name which accounted for First, Middle, and Last Name of the staff member. For the client, it contains all of the attributes of the staff entity but introduces a third attribute called Last Visit Date, to account for information regarding the last time the client visited the food pantry. Then you have the inventory entity which only contains the attribute Total Weight, since the pantry uses weight to keep track of how much food is in stock. Lastly, the items entity contains five attributes, Item ID, Item Name, Item Weight, and Item Stored Date. However, to account for a concern from the client about confidentiality of information the names of staff and clients are later crossed off from the E-R Model. In conclusion, after consulting the group, the next step is to create and connect the database with the project in order to fully utilize its intended function.

            Starting off, I noted for four entities, staff, client, inventory, and items. In the staff entity, it contained the attribute OneCard_ID and a composite attribute Name which accounted for First, Middle, and Last Name of the staff member. For the client, it contains all of the attributes of the staff entity but introduces a third attribute called Last Visit Date, to account for information regarding the last time the client visited the food pantry. Then you have the inventory entity which only contains the attribute Total Weight, since the pantry uses weight to keep track of how much food is in stock. Lastly, the items entity contains five attributes, Item ID, Item Name, Item Weight, and Item Stored Date. However, to account for a concern from the client about confidentiality of information the names of staff and clients are later crossed off from the E-R Model. In conclusion, after consulting the group, the next step is to create and connect the database with the project in order to fully utilize its intended function.

What I produced this sprint:

References:

https://www.geeksforgeeks.org/database-management-system-er-model/

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

Every little bit helps!

For the sixth week’s reading, I chose to read the pattern, Sweep the Floor. This pattern focuses on a problem where you are a new apprentice on a project. The real-world experience of joining on a team means that you have to learn about the team and the team has to learn about you. These situations are uneasy and earning the trust to contribute to the development that they have worked on before you joined is a problem to be solved. The solution provided for this is to start contributing to the project by completing tasks that the other members do not want to do. Examples provided do not entirely mean that it has to be about coding and could be other tasks such as code review, setting up a project wiki, or updating documentation. As long as you contribute to the team, they will have an easier time and appreciate your work and build trust. The objective is to build enough trust that you can take on bigger challenges and eventually become one with the team.

What I found interesting about this pattern is the excerpt in the second to last paragraph. It is the last thing a student that is about to graduate from university would want to hear. Completing your tertiary education, after spending the four years or more getting the degree, accruing massive student loans to hear someone devalue your education is heart wrenching. However, those who chose the route of getting a degree should be fully aware that this is the reality. The knowledge you gain from school is like a baseline for real work experience. Being accepted to work at a place does not automatically mean you are on the same page as everyone else. You will have to spend time as a newbie and learn about everything the company, team, or workspace has to offer.

This pattern has not changed the way I think about the profession or how it will work because everyone has to start from somewhere. As someone fresh out of school should realize that education doesn’t mean all that much when compared to actual experience in the field.

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

Rising from the bottom

For the fifth week’s reading, I chose to read the pattern, Be the Worst. It is about facing a problem where your rate of learning has plateaued. As such, a solution is needed and is presented as instead of being in a team where you are at the top. You will have to find a team where you can be at the very bottom. The objective is to work your way up from the bottom, and from that you should be able to learn from those who are better than you. By actively trying to become better than what you were before, you allow yourself to continuously improve. However, there are risks of placing yourself at the lowest. The first is that you could be a negative impact to the team which would mean that you aren’t contributing as much as you should. Second, you might find yourself losing motivation when things do not pan out the way you thought it would. The action provided in this pattern is to rank teams by skill level and find a team that would allow you to work your way up.

What I found interesting about this pattern is that there is no easy way of solving this problem. You have to be willing to improve, willing to learn, and willing to drop your comfortable position to continue chasing the top. After allowing yourself to do that, you need to continue having the motivation and enthusiasm to improve yourself in a team that you know is way more knowledgeable than yourself.

This pattern has made me think about the intended profession in a way that everything will not remain the same forever. As time passes, teams will become more knowledgeable, but every individual will learn at a different pace. If you happen to be a person that progresses faster and becomes better than the team much quicker. You will eventually come to the realization that your learning has plateaued. By planning your road map in conjunction with this pattern, you have a chance of continuing your journey to become a master if that is what you wish. This is what I learned from this pattern.

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

Sprint Retrospective – Round One

            A reflection on what I learned form this week’s activities is that everything is easier said then done. We are given a sprint board and should strive to meet the objectives by the end of the sprint. However, it is not surprising there is issues to be accounted for during the first sprint. As expected, the amount of communication outside of class is lacking than when we are interacting with one another during class. In regard to this, the solution is to make sure that everyone is fully aware that our only source of communication, Slack, is important to check every day. As it also affects our course grade due to our attendance with the sprint standups. This is solution is also applicable to any problems regarding communication in the future as it’s simple to address but execution requires effort.

At the start of the sprint, our
backlog started with two items to complete. The first item is summarized to
speaking with other university professors about what information is valuable.
The steps taken to ensure we have contact with the other professor was to join
the appropriate slack channel. In this case, I joined the LibreFoodPantry slack
channel with my respective group members and under the “food-saver” channel.
Our group got information indirectly from another team’s question regarding the
REST API addressed to the other university’s professor. In response, we learned
that they would like to know how long an item can be eaten opposed to its
actual expiration date, and possibly a way of filtering by food categories.
This is the first step but there is a roadblock, even if we know what is needed
from the client, if we don’t have a place to begin then it seems pointless to
know what they need.

            The road
block is what leads to our second item in the sprint backlog, which is to
develop the REST API interface to manipulate a JSON file. From the Department
of Agriculture’s Food Safety and Inspection Service, we are provided a public
JSON file to work with.

The first step is to figure out
where to start, and my approach was to tackle a small issue that was mentioned
beforehand, which is a place to store, and pull the JSON file from. In which, I
spent about an hour looking up information about DigitalOcean and there was a
way of getting 12 months of access to DigitalOcean for free from GitHubs
Student Developer Pack. However, I put this information on the back of my mind
since another member was looking into Heraku.

In response, I chose to get started
on researching about REST API. The first site visited is restfulapi.net which
introduced the concepts of REST. Next, since the group unanimously decided to
work with JAVA as the preferred language, I decided to revisit my favorite java
IDE, IntelliJ IDEA. On the JetBrains site, it provided a tutorial to REST API
web services which I read and got introduced to the JAX RS library. Lastly,
after completing that tutorial, I learned that it was not the place to begin
this journey and found the “Building a RESTful Web Service” with spring
tutorial. In conclusion, I’m still working on the spring tutorial and that is
where this sprint ended for me.

What I produced this sprint:

https://gitlab.com/irresoluteduck/spring-boot-tutorial-example

References:

https://catalog.data.gov/dataset/fsis-foodkeeper-data

https://www.digitalocean.com/

https://education.github.com/pack

https://restfulapi.net/

https://www.jetbrains.com/help/idea/restful-webservices.html

https://jersey.github.io/

https://spring.io/guides/gs/rest-service/

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