Author Archives: zloureiro

Retrospective Sprint-3

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/47
Create MongoDb Docker Container

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/50
Setup Rest Api Endpoint to Add to MongoDb

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/31
Implement methods in weight-entry component to communicate with REST API

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/30
Add checks for remaining weight allowed based on previous transactions

During our third and final sprint our teamwork and role designation really benefited our workflow. We applied ourselves to areas of work that we each had the most knowledge with (Rest Api, Mongo, Web UI, and Docker) and focused our workflow individually in those subjects. While at this juncture in the project most of the work is overlapping in order to connect either through Docker or with specific method calls we were all exposed to each other’s work. This way we each had an opportunity to learn about the different parts of the project and all had a deep understanding of our own work. Having such deep understanding of our own work allowed us to explain it to each other and to overcome obstacles when finalizing the connection between everything either locally or via Docker. So whereas in previous sprints we worked solely on our own part of the project, this sprint really started to blur the lines of our issues. 

For example, many of our Rest Api Endpoints needed to be set up to work properly with the Front End Angular Methods. Issues like Issue 50 Setup Rest Api Endpoint to Add to MongoDb became a three part issue. We need to make sure the Rest Method could add correctly to our MongoDb, but also this needed to be tested with the Front End code before it could be finalized. While working on this issue I found that roles were often switched and juggled between my teammate and I as I worked on Front End Angular code and they worked on some Rest Api Backend code.

There isn’t much that didn’t work well in this Sprint but I feel that keeping our Merges to Master on Git up to date and correct was sometimes a problem. We did not alway communicate code correctly and would send snip-its in discord that we would copy and paste instead of sharing it through git. Sometimes certain important code segments would get merged and then someone with old code from copy and pasted work may merge and we would lose that important segment of code in our most recent commit.

As a team we could improve our Git presence and organization. We should have been using it to solely share code instead of copy and pasting in discord. If we used Git only certain things would not have gotten lost in translation and confused. Overall, if we worked more cleanly on git we would have saved quite a bit of time on the project.

As an individual I could improve my knowledge and understanding of the parts of the project I wasn’t assigned to. Sometimes if an issue would arise with a field of familiarity like the Rest Api I would feel compelled to help my teammates with the problem. However, I could have designated some of that time to look over things like the Docker containers more and familiarize myself with their function better. Docker would not work on my computer so the only exposure I had with it was when working with my team members. I feel I could have learned more about the Rest Api and Angular Docker containers as opposed to just the Mongo Container.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

The apprenticeship pattern Expose Your Ignorance is like climbing a mountain taller than you may have climbed before. It seems so difficult and intimidating but once you are at the top, you realize how the hard part is over and it will now be easier moving forward. You may feel great pressure if your team has a task and they all seem to understand while you have some questions or are unfamiliar with the material. It seems as though exposing to them your ignorance will ruin their confidence in you or hurt your pride. However, exposing your ignorance does just the opposite! Your team members will see that your ability to learn is your strong suit and their confidence in you will be even greater. You will not be a master in one specific field but a master at obtaining skill and knowledge in any field you are presented with.

In my own experience, exposing your ignorance can be a great ice breaker at the beginning of a project. Just because your whole team may seem more knowledgeable than you on the material does not mean that they don’t need a refresher or are just putting on an act of confidence before they do research on their own to catch up. The most direct and fastest route to the knowledge is to ask your team member who has immediate knowledge. Perhaps the situation is vice versa and you have more knowledge than your team, asking revealing questions even if they are just for review can open the conversation for people to expose their ignorance and then learn the fastest way possible. It can be hard to swallow pride and fear judgment but if you remember that the most important thing is the project then your own pride becomes secondary. It is also better to have someone ask the questions they need than to put on an act and slow things down by learning as they go when the time could have been taken to spread knowledge amongst the whole team simultaneously. Now while you still may have to learn as you go after having exposed your ignorance, at least your team is aware and can now take proper steps to aid you until you have obtained the necessary knowledge.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Expand Your Bandwidth

The Apprenticeship Pattern Expand Your Bandwidth is something that should be learned at the beginning of your career, even in schooling. This pattern is about learning the ability to learn a large amount of information about more than one subject at the same time. You must be able to retain the vast income of knowledge, you won’t have to do it for very long, but it can be overwhelming. Overcoming the overwhelming feeling and successfully learning much more information than you’re used to is the crux of this Apprenticeship Pattern. There comes a time when your focus must spread from your everyday work and onto new information.

This pattern coincides with that of Draw Your Own Map quite a bit. These two patterns are all about taking your future into your own hands. Expanding your bandwidth is a skill you have to learn to help your path become clear. If you want your map to expand then your knowledge too must expand. Sometimes when you need to take in a vast amount of information at one time it can be stressful and confusing. However, once you have retained this new information it unlocks new opportunities and new paths to be taken.

In my personal school experience I feel this skill was necessary at times, even at the very beginning of my pursuit of a Computer Science degree. I remember the knowledge jump between Intro to Programming and Data Structures was enormous, but not only larger, it moved faster too. My fellow students and I had to learn new information constantly all while applying our already new knowledge. It was that way for about the first third of the semester. We had such vast amounts of information coming in, but after that first third of the semester we had already learned most of what we would be doing. There was still more information to come of course, but it was more or less experimenting in more detail with things we had already done. We expanded our bandwidth at the beginning so that the rest of the semester we were prepared for a variety of projects. It was as if the flower had bloomed for us finally and our paths were much more open.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Draw Your Own Map

The apprenticeship pattern Draw Your Own Map helps express the idea that you create your destiny so to speak. There are things that may be required of you to achieve a goal and other people may be involved along the way but when it comes down to it only you are responsible for the steps you take in order to reach your destination. Your Professors, employers, or counselors can help guide and teach you but they cannot decide for you what you will do. It’s all up to yourself to hone your skills and knowledge to forge your own path, to decide what your goals are. This apprenticeship pattern isn’t just about creating large long term goals either, it’s also about making some goals, the single steps. Having small goals will help lead you towards your ultimate path, failures and successes will help mold you, but the more goals you pursue the more knowledge you will have of yourself.

I think this apprenticeship pattern is especially correlated to my experience in Computer Science. This pattern is all about making your own future and since the very first day of pursuing a Computer Science degree that has been an important skill to learn. When learning about programming you can learn all the textbook examples and read documentation and examples. However, the real learning comes when you start making mistakes. When you start to learn through trial and error along with educating yourself. You learn the skills necessary to be a programmer but in order to program you have to apply those skills yourself. It’s like being an English major who wants to one day write a great novel. You learn all the skills to write well, but you have to create the story, it won’t write itself just because you know the skills. Just as your Professors cannot write your code for you, or your employer cannot apply for your next job for you. You must create your own future with skills that you learn to use for yourself.

Since learning that Computer Science is all about taking your skills and applying them in your own fashion, it has given me insight to my future that I did not have before. It’s true that I do not know where my career will take me specifically, but with my knowledge and skills I learned I know how to get myself there. Wherever “there” may be for you, you can Draw Your Own Map.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Create Feedback Loops

The apprenticeship pattern Create Feedback Loops is an interesting way to learn from yourself and your own interaction with your environment. This apprenticeship pattern is about finding ways to review or “give yourself feedback” regarding your level of skill and competence on whatever you may be working on. 

Working in a team environment you may want to find out your team’s opinion on you and your contribution to the work. It’s not enough to judge your success based on the team’s success, whether that success is good or bad. Being on a team that is great and completes tasks efficiently it is important to know if you are a key contributing factor, or as this pattern put it, a “backup singer”. Just the same if you are on a team that is not producing good work, you can’t get stuck thinking that you are the best on the team and blame the failure on others. Even if it’s not your fault you have to realize that you are not contributing yourself correctly and this could hold you back from furthering your career.

Testing yourself on your own is also important in setting a realistic but higher standard for yourself. Test your work early, learn to expect failure and don’t be discouraged when you do. This pattern is about overcoming your failure by understanding what you can improve. Creating clear feedback is basically a criticism that can be acted upon. “Reinforcing feedback encourages you to do more of something. Balancing feedback encourages you to do less of something”. See both of these types of feedback require you to act, they aren’t stalling you with no clear direction.

One of my favorite examples from this pattern was that of asking for feedback from job interviews or team members. Asking people’s opinion of yourself can help you understand how you are contributing to your environment. A job interview that rejected you could be a great source of knowledge to prepare you for your next interview. Building from failure is how you create success, the more you have from failure the more you can put together to succeed. I find it vigorously motivating to ask my team members their opinion of me and my contribution. Of course I take pride in hearing positive feedback, but I often find that the criticisms help motivate me to be better. Now as long as feedback is delivered to you respectfully it’s great to receive in order to help with your direction. Your team members will also find that an open and friendly environment of communication helps team morale and forward progress.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Retrospective Sprint-2

This issue was to create a Backend Rest Api that could communicate with both our database and Front End UI.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/11

This issue was done early in the sprint to see if MongoDb was a viable option to use for our project.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/8

This issue was to create a definition of done for our issues so that the team had a better structure to follow when working.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/23

In sprint two our team excelled in taking on the correct work load. Sprint one left us with too little work and we had to add things while we were working and even did some work without creating issues. However, in sprint two we proposed our work with proper weight classification and so we had just enough work. Our workload reflected our Sprint length well and we were able to split up the workload well between team members. This time around we took large tasks that had several parts and instead of weighting them higher we broke the issue down into several smaller issues. This way we were able to spread the workload out throughout the team and didn’t leave anyone working on one large portion of work for too long. I think this worked to our advantage because it was easier to formulate a plan and track our progress this way. As we completed more smaller issues we could see how far along we were with progress and dictate work to team members better. 

We didn’t have much of a problem at the beginning of the Sprint, although, towards the end when school was moved to online classes only we began to have some issues. It may not be within our power to control but the move to online classes was a detriment to our work ethic and communication as a team. Having a second week of spring break that otherwise would have been a week of working was a blow to motivation and the team’s communication was lacking. Now that we have returned to classes online we have gathered ourselves well and are ready to work. However, the removal from our work for twice as long as we had originally planned deemed to be a detriment to our momentum. We still completed the work load we had planned but we felt rather scattered.

Moving forward we need to work on our communication as a team. Before the national crisis we would meet in person as a group weekly and work for three or more hours together. This synchronous work ethic proved to be our most productive environment. Now that we cannot meet in person I think we could plan for synchronous online meetings to help aid our disconnect. Even if we are not collaborating on issues I believe it could help morale and productivity to know we are all working simultaneously.

As an individual I believe I just need to get back in the groove. Hopefully, with the help of my team we can create a schedule to add some structure to our workflow and get back into a forward momentum.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Craft Over Art

I have endured the struggle between craft and art, beauty and functionality. The dream for any project is to master both but most times it is unrealistic that you will have the time to fully master either one without needing maintenance. Since there is no guarantee of the complete fulfillment of either functionality or beauty you must find a common ground. This is not a common ground of what you think should be but a common ground to make the customer or user happy. You can’t go all functionality and present a fugly work, even if it an amazing work of code. Vice versa you cannot pass in a beautiful shell of a Web User Interface with feature that don’t work correctly!

My favorite part of this chapter was the separation between a craft or art and fine art. It’s not about your own expression, it’s about meeting the threshold of what will make your customer happy and developing past that if possible. First you need to create a great but simple work that meets the basic needs and looks presentable, then you may chase functionality or beauty.

Another great point in this reading was that the best way to learn can be fixing mistakes rather than starting over just because you messed up. If you go to far with functionality or beauty and one starts to fail because of the other than you need to stop and find out why. You may learn something that will help you in the future, hone your skills. Refactoring and repairing may be more beneficial for you and the customer.

I know I have experienced this issue in a slightly different scenario. My partner and I were creating a Web User Interface that connected to a database and we had both come up with basic models for the code. Instead of starting a new project from scratch we refactored one of our projects to incorporate the things that worked in the others program. We learned many lessons on functionality and beauty by fixing code rather than restarting. Since our code was a mix up of each others design we had to find out how our web page would change. We ended up going with the best functionality we could get with a little less beauty than we liked. However, it worked great and was up to standards with it’s appearance so the result was a success.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Digging In

The Dig Deeper pattern is all about knowledge and gaining more of it. More specifically, this pattern is about taking something new that you have learned or are currently learning and teaching yourself about that subject’s roots. It’s not enough to know how to use the subject matter to solve your specific issue, you need to know that subjects use as a whole to gain knowledge of its context. This pattern is about understanding how a system works as a whole and not just the part you are working on. This deeper knowledge allows you to understand your work more concisely based on the context of it as a whole, which will help you understand your specific issue even more.

When I first started reading on this pattern it felt like a very blunt lecture. It felt as though I was being told to learn everything to its fullest and if I do not then I will be a less desirable individual for hire. However, as I read on I realized it was not about having total knowledge of EVERYTHING, that would be overwhelming and nearly impossible. I began to understand that it was about delving your knowledge into specific things, subjects that you are currently working on. If you are working on a specific issue and find the solution, it’s not about knowing every way to solve the problem, but to know in detail the workings of your solution.

This pattern further enforced my idea that you can do anything, learn anything if you put your mind to it. If there’s something I really want to excel at, deepening my knowledge can only help me achieve my goal. Being able to fully express my knowledge on the specific things I have worked on, though maybe few, is far greater than a larger quantity of surface knowledge. It reminds me of using MongoDb for the first time in our libre food pantry project. It’s all good and well to set up a database and query and get the results you want. However, it’s much more important to understand how the database functions beyond my own entries and data types I’m working with. In furthering my knowledge I was able to communicate my understanding into the other areas of the project including tying the database to a Java REST API. I fully agree with the ideologies of this apprenticeship pattern, dig deeper into your knowledge and it can only benefit you.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Retrospective: Sprint-1

Links below for my work on Sprint 1 of the LibreFoodPantry project.
MongoDB spike:
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/11
The goal of this task was to preview MongoDb and determine whether or not it will be useful for the project.

Production DB:
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/8
The goal of this task was to create a working Database to match our schema and work with our Rest API.

My favorite part of the scrum framework was actually the integration of kanban. The mixture of the two frameworks really made the work environment productive, predictable, and understandable. My team members and I assigned roles respectively to the scrum framework guidelines, at least two members of the team would know how something is done so that only one member would not have sole knowledge of the task. This way it made it easy to spread the knowledge throughout the team without holding up productivity. If one team member was busy then often the other would be available, or would be in the near future. This team plan also made development quicker in a way that if you were stuck on a task, your fellow task member may have another way of figuring out the issue. Together you can overcome obstacles easier than on your own. A great example of this is when I was developing a Production Database that could be used with our Rest API. I was having trouble figuring out the java code for MongoDb queries. Setting up the connection wasn’t the main goal of the task but it was necessary to have an understanding of it to be sure that MongoDb was the database application we would use. The issue was querying dates and one team member and myself were using CalenderDate which worked, but it ended up being eight lines of code to set up. My other team member on the task figured out LocalDate can achieve the same success with only two lines of code. If I had been left to the task myself the code would be less clean and bulkier, but thanks to my team members different approach we have clean and concise code.

The only things that didn’t work so well was our activity on planning and taking notes on Gitlab. We did not plan in the best way that we could have for the sprint and were constantly editing our backlog and to do lists. We also scarcely posted notes and updates on Gitlab. We did complete our task frameworks in order to move them into the done board. However, we did not thoroughly record our progress on Gitlab. In this way it could be hard for a newcomer to understand the evolution of our issues and how we solved them. They would only see the beginning and end product which is not clear and understandable.

To improve as a team we need to break down our planning technique and make sure our issues are concise and weighted correctly. I think our only problem with this was that we planned last minute because we were unclear of what was expected. However, now that we know we should be able to plan better and make sure our to-do list is concise.

To improve as an individual I need to record my progress, mistakes and achievements on Gitlab more often. Frequent updates on Gitlab would allow a newcomer to see my process and avoid failures that I may have already attempted so that they don’t waste time on something that already is proven to not work. Perhaps they actually solve a failure that I had attempted but was not able to make functional. Without notes to address these topics then a newcomer would not be able to interact and understand our work.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Concrete Skills

I have furthered my reading in Chapter 2 of the Apprenticeship Patterns this time about Concrete Skills. With all the romanticism of being an Apprentice and obtaining the ability to learn quickly this chapter really tells the other side of that. It does pay to bring a level of enthusiasm for learning to a team but in order to be hired on a team you need a point of persuasion. This is when concrete skills come into play. Examples described in this chapter are things like a basic knowledge of various industry popular languages, frameworks, and a well developed understanding of your native language. Having these basic, or concrete skills, allow you to show some sort of way that you can benefit a team indirectly with basic tasks before you learn how to directly help.

This chapter addresses something I often think about. Some questions that run through my head, “What are the basic skills I need for getting my first job?”, “Am I expected to know what they are developing and how to contribute, or will they teach me?”. The truth is you can’t know about a development project before you are part of it. How things are done and what the scope is, will have to be learned as you go. Then my first question of what it is I need to know beforehand becomes more clear. My concrete skills need to be further developed, I need to explore more now at this stage in my career. 

I often feel the pull to my familiar skills when presented with a project. I need to use Java because that’s what I know, I need to use this IDE, I need to use this Database. However, it’s interesting as I read this book I see my development toward these goals presented in each chapter. The reading helps solidify my exploration into the unknown. The start of this semester I thought I would only use my most used IDE and the database I was used to using. As the semester got going I began to use a new IDE that seemed to better fit my interests after I took the step to get familiar with it. I also took the chance to learn about a new database application that better fit the needs of the project rather than catering to my familiarity. My next goal is to learn a basic understanding of a few more popular languages.

Developing these concrete skills is just as important as unleashing your enthusiasm for learning. Both are beneficial for a team but concrete skills will give you a practical use upon hiring.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.