Rubbing Elbows

Until I can obtain a job, I will be working by myself most the time. This will inevitably impact my learning because working with others allows shared knowledge and experience for the parties to teach each other. The “Rubbing Elbows” pattern from Dave Hoover’s and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman discusses the benefits of collaborating with others.

The pattern mentions “Pair Programming,” a technique where developers code side-by-side. I have not coded in this manner in a long time. When I took my first computer programming class my best friend and college roommate was also taking that class. Given the circumstances, we often collaborated on assignments. While we did collaborate, we often coded the assignments solo and discussed our methods and problems. I cannot count the times that one of us would get stuck with an issue that the other had no problem with. I learned then that different programmers will find multiple solutions and methods while developing. These diverse techniques are worth examining and potentially adopting.

“Pair Programming” is not the only way to practice “Rubbing Elbows.”

“The goal is to find ways to expose yourself to the daily working habits of other skilled people, and observe the ways in which they gradually refine those habits into even greater skill. These habits extend beyond coding and into all aspects of software development.”

This statement from the pattern shows the type of knowledge the pattern will provide. “Rubbing Elbows” is not necessarily about learning new coding methods but about observing the small, often unmentioned details of a developer’s work habits. Because of this, developers can rub elbows by working on any part of the development process, including presentations or papers.

Working in LFP’s update module team provided plenty of learning opportunities for me. Some opportunities were coding related, while others were about project management.

I have a couple ways planned for practicing this pattern. Now that I am graduating, I think this would be a great time to collaborate on a project with my friend again. We have not worked together in years and this seems like an opportune time. He has been working in development for awhile and I am sure he has a lot for me to learn. I also plan on participating in the LFP spike-a-thon this summer. This will let me work on something familiar while presenting opportunities to work with other developers.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Sweep the Floor

I will hopefully be starting my software development career soon, and with that I will be joining a new team. Dave Hoover’s and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman’s pattern “Sweep the Floor” suggests “volunteer[ing] for simple, unglamorous, yet necessary, tasks” to contribute to the team. I will be one of the least experienced members in the team, so I’ll need to be proactive working on the more tedious work. Doing these tasks is more than just gaining trust from the team but also showing respect for the more experienced members. The experienced members should be focused on the work that requires their experience and not bogged down by simple chores.

“Examples of these tasks include maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, eliminating technical debt, setting up the project wiki, updating documentation, acting as a sounding board for other people’s ideas, and so on.”

While it may not be fun work, these tasks are still important, and the team will be grateful for the effort. To practice this pattern, “Sweep the Floor” suggests finding the tasks that the team has been putting off and do them. The pattern however warns of the potentiality of being perceived as incapable of more vital work. This can be averted by working on more complicated issues or personal projects alongside the simple chores.

When reading through the list of example tasks, I could see the tasks that often held up work during our LFP sprints with code review being the biggest culprit. I can see how completing these tasks would be good to focus on when joining a new team. Not only will the team benefit from these tasks being done but completing these tasks will also give valuable insight into the project. With code reviewing, the opportunity to study the unfamiliar parts of a project is presented. Work on the documentation was also often put off or forgotten.

I think this pattern makes sense having the inexperienced members handling the simpler tasks. These tasks are chores to the experienced members of the team but are learning experiences for the inexperienced.

The pattern includes an experience of a developer working in a formal software apprenticeship. The important part of the story is when the apprentice watches Uncle Bob Martin, a master craftsman, take out the trash. The apprentice’s mentor then scolds the apprentice for allowing the job to go undone and having a master craftsman take care of it.

“It is not the job of the master craftsman to take out the garbage.”

This pattern has made clear what I will need to focus on when entering a new team as an inexperienced developer. I will need to find the simple, more tedious jobs and work on them while furthering my learning. “Sweep[ing] the Floor” will help with my integration into a team by familiarizing myself with the code base and team practices. I will also build trust with the other members of the team. Once I gain enough experience and trust, I can then start to work with more complex, interesting work.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Create Feedback Loops

This pattern discusses the need to have good, quality feedback to allow for personal growth. Often times, the only form of feedback is coming from ourselves and what we have done. As discussed in the article, this can often cause our reflection and feedback to be skewed and biased. If you are on a very good team, it can cause you to either ride their coattails and feel more prepared than you are in reality or cause you to become overwhelmed and feel as if you know nothing. On the other side of the spectrum if you are on a bad team, it can cause you to become complacent because you are able to succeed easily on this team.

The way that this pattern offers a solution to this common problem is to be able to develop a test of actual tangible data that will allow for an honest form of feedback. For example, if you are in team but writing your own portion of code, have another teammate peer review your code. By having another pair of eyes on your own code, they will be able to pick up and point out portions of code that are bad, messy etc. that you would usually gloss over because it was how you had always done it. In a similar manner, if you have any supervisors or managers above you it is always a good idea to be asking for feedback from them. This will not only help you improve your abilities but will also show them that you have initiative to improve yourself.

I believe that this type of feedback is very important to get. Many times, people can become too complacent with their own skills and not try to improve or gain more knowledge. This has happened to me and the main reason I was able to realize my complacency was by working in a group project. By constantly collaborating with them it was easy to see my strengths and weakness and what needed to be worked on. By having the group give feed back and documenting the project as you go, allowed for you to see your progress in a tangible sense.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Concrete Skills

This pattern begins by discussing the desire to get into the software development field with the drawback that often times managers or HR won’t hire without experience. To be able to show that you can become an effective member of the team, you need to be able to translate all of the knowledge gained previously into concrete skills. A good way to show these concrete skills is the capability to demonstrate that you would be able to make an immediate positive impact to the team, even if that impact is something very basic. By showing these concrete skills, it will give you a leg up on the competition when hiring.  HR is already taking a chance on you; it is best to show that it will not be for nothing and you are at least capable of something beneficial.

The way to go about this that the article discusses is by going through CVs or anything that shows the concrete skills that well-respected professionals list about them. Then find which one(s) of the skills are applicable to whatever team you are trying to join. From there, work on being able to demonstrate that skill as a concrete ability, whether it be by doing a pet project or simply practicing that over and over.

I believe that this pattern is something very important to learn. As someone who is just getting started into the software field, it can often be hard to even get a foot in the door for some companies. When you finally are able to get in the door, it is absolutely essential that you show that it was not a waste of time. The most successful interviews I have had was when I was put in front of a team leader who wanted me to demonstrate certain skills that would be able to help them immediately. Often times it is simple problems that are needed to be shown, but it is very important to show that you not only understand the problem but are able to apply the solution. A hiring manager is far more likely to “take a chance” on you if they think you’ll be able to immediately have useful, applicable skills for the team.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Share what you Learn

“Share What you learn”

This short sentence has so much to take in. This sentence has always come in my way and I appreciate everyone who has taught and shared their experience and teachings with me.

My parents always taught me if you want to be better at something you have to share your knowledge with others. It will help you and others. It is good for the community as well so that people are aware of certain things and would understand your point of view.

In the Computer Science field, it is absolutely important to share the knowledge. You learn the basics when starting to learn a language but how to implement those basic to intermediate and advanced levels. You need someone to spark your creativity in it. I am lucky to have such mentors and classmates who were understanding about my lack of knowledge in the beginning of my first semester at university. They shared some of their work and how they did which helped me see and learn the program in a different and convenient way. 

Teaching is a powerful learning tool…”When one person teaches, two people learn.”

Sharing adds on to the ability of reviewing the task in the past as well. Couple months ago, one of the freshmen was struggling to solve an algorithm problem where you have to  prove each speed’s growth. His frustration caught my attention because a year ago I saw myself struggling on that same problem. I walked by and asked if he needed help. I gave my explanation and showed him an easier way to do it. I was amazed how fast I was able to do and I still remember.

Sharing what you have learned in the past with others keeps you on track as well. The mind alters you to keep it simple and informative at the same time. Before teaching others especially your team, you have to come up with a strong structured technique so that they can understand it better. The challenge is to keep it simple while getting the main points in it as well. You would find yourself in rethinking and researching MORE to make it simple for others and yourself to understand it better.

Learn, share and be the source of knowledge for others and for yourself.

From the blog CS@Worcester – Tech a Talk -Arisha Khan by ajahan22 and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 3

The main things we did for this sprint were dealing with the database connections along with cleaning up code and setting up docker. More specifically we learned how to connect the database to the rest server. We chose JDBC to do this. After that we coded the connection. Next we converted the endpoint and the whole rest server to use the database using JDBC. This was done by creating a class to access the database containing a method for each one of the endpoints. Then making each endpoint call the corresponding database access class method. 

At the same time other members of the group were installing docker and doing tutorials for it. Along with reading about docker. After that we each tried to write our own docker files. That went fairly well. So we got the angular app is-registered running in docker container. Along with the angular app register running in docker container. In addition to the rest server running in docker container also the get database running in docker container. After that we worked on cleaning up the code for the is registered app. We also worked on cleaning up the code for the register app. We also figure out how to call another endpoint from the rest api. We did this using the web reactive framework. After that we started working on connecting the docker containers. We tried creating our own bridge and using the container IP’s we also tried using docker compose and using the container names and IP’s. none of this worked and the angular app was still getting CORS errors. The connection to the database couldnt connect either. We tried talking to the other teams about it but we were still unable to get it to work.

For this spring I personally focused on the rest server and the docker connections.  First I looked at what another team member had one for connecting the database and worked off of that to finish it and add methods to it to do all of the operations on the database that were needed. Next I converted all the endpoints in the controller to use the method that i created in the database access class. After that I worked on learning how to call the update modules endpoint. I learned about the web reactive framework and it seemed to be good. I was able to call one of our endpoints from another as a proof of concept. However i was having trouble understanding how the update groups endpoints worked so i moved on to the docker connections after that. I spent the rest of the sprint trying to get the docker connections to work. I first created the docker file for the rest server. Then I tried manually creating a bridge and connecting the rest and angular containers and running them. Then I tried using docker compose. Neither worked. That was all I did for the sprint.

I thought overall the sprint went well. I think we did a good job with the planning meeting. I also thought we did a good job with working together on connecting the database to the rest server. I also thought we did a good job using zoom to work on stuff together. I thought we should have communicated closer when we were all working on docker stuff. I feel like we just all worked on it independently and didn’t really talk about what we had tried and what progress we had made. As a team we could improve on communicating when more than one of us is working on the same issue. As an individual I should have done a better job of communicating my progress on the docker communication.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/register-guest-service

The register guest service

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Register-guest-deployable

The docker compose file

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui/-/tree/working-on-conection

The work on connected the docker container in the is-registered app

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/register-guest-service/-/tree/working-on-connecting-containers

The work on connected the docker container in the register guest service

From the blog CS@Worcester – Tim's WebSite by therbsty and used with permission of the author. All other rights reserved by the author.

3: Sprint Retrospective

Recently we finished our last sprint. This was our 3rd sprint. During this sprint my team and I worked on setting the registerGuest app together. We mainly focused on databases and getting the docker working. Each one of us spent time on learning about docker. Most time was spent on the database as we were having some trouble running it and Docker because no one was familiar with Docker. However, we managed to get the database working for the app. Everyone was familiar with the components of the project, besides docker. But we are happy that we got the docker containers running. Overall, the team did a good job in reviewing each other’s work which helped progress the sprint. Zoom meetings, constant discussion on errors via texts were helpful. Main thing was keeping track of gitlab issues that were created and working on them kept everyone on the same page.I believe we did a great job as a team contributing toward the project.

My contribution:

This sprint was quite challenging for me. I started off by researching more on Docker. After reading about Docker I tried to install docker desktop. Unfortunately, the Docker desktop was not supported by windows 10 and MacBook version 10. I started to research more on installing docker. One of the helpful resources I found was from Docker Hub. I followed the tutorial from Docker Hub and installed Docker toolbox. I followed up with Shams, because she and I both installed Docker toolbox form there. I experimented with Docker toolbox and tried to run by creating a new angular app. I was struggling for a while but looked at Shams and did a zoom meeting on how she was able to get it running. We both discussed what error I was getting.

When docker toolbox was working, I worked on helping my team connect the docker containers together. Again, it was challenging because the angular app was able to read each other individually but the servers were unable to connect to each other. We are able to open the shell inside docker and run the app but due to the servers not being connected to each other we were unable to run the project with docker. However, discussing and having 6 meetings on zoom about the problems we were facing we got each part of the app running inside the docker container locally.

After everything was running properly, I reviewed, approved some issues on gitlab. Also, after shams made some adjustments to is-register-webui, I went back to gitlab and clean coded is-register-webui, fixing the padding, the window size, borders and WSU logo position and pushed the final results.

What didn’t went well:

Things that did not go well for me was running docker properly and using Angular materials.

I was curious and excited to work on docker and angular materials. I spent more time researching docker and Angular material. I was not able to use Angular material on this project because it was time consuming to get it working on time and I knew it would take more time since the deadline for the project was near. However, with CSS and HTML code I am impressed how the design came out. 

Docker was not friendly. I was not familiar with it and neither one of my teammates were but the team managed to run the app locally. 

Improvement?

What we could have done was focusing on main things and being organised a little more. I felt everything seemed scattered. I was lost sometimes. Interacting more with each other on certain problems and discussing with each other what they are planning on doing and how they will be doing it would have been helpful.

Individual improvement?

Some areas where I feel like I could improve would be time management and keep track of the project progress. Due to lack of knowledge on docker and angular material (what I wanted to work on since I was done with is-register-web-ui) I spent more time in research and sending links and notes to my teammates about those two, I spent less time in contributing on gitlab issues. It would have been better if I were introduced and have resources about docker and angular materials.

The Project:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest

Is-registered-web-ui:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui

Issues:

  • Learn about Docker:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Plan/-/issues/58

  • Experiment with Docker:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Plan/-/issues/59

  • Running the Angular App in Docker container:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Plan/-/issues/48

  • Dockerfile:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui/-/blob/master/Dockerfile

Cleaning code Links:

  • is-registered-web-ui- app.component.ts:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui/-/blob/master/src/app/app.component.spec.ts

  • is-registered-web-ui-app.component.html:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui/-/blob/master/src/app/app.component.html

  • is-registered-web-ui-app.component.css:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui/-/blob/master/src/app/app.component.css

  • is-registered-web-ui-app.module.ts:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui/-/blob/master/src/app/app.module.ts

From the blog CS@Worcester – Tech a Talk -Arisha Khan by ajahan22 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

At the end of last week, we finally conclude our third sprint in our development process of the LibreFoodPantry, aiming at a deloyable environments so that they all are isolated in their own space. This is also our last sprint so we tried our best to wrap it up as much as possible, so that the team after us can easily pick up from where we left off. We were able to work together more this time, comparing to us having to separately work on our own stuff in the previous sprint. We finally got a working, operational and deployable user interface as well as a fully implemented, buildable and deployable backend system with REST API and mySQL database. We were also able to adapt with the online communication and worked more effectively with each other.

List of what we accomplished during the last sprint:

       – Successfully integrate Docker into frontend UI and the REST API, allows them to communicate with the existing mySQL container with configurable parameter in config.json file (REST API Docker, ApproveGuestWebUI Docker)

–         –  Having an operational admin page user interface or ApproveGuestWebUI, although without actually data fed from backend systems, but mocked with data points (ApproveGuestWebUI Epic)

–         – Having a mocked or stubbed backend for the frontend to test connections establishing mechanics (Registration Stub)

It seems that we did not do a lot for this sprint, but it was actually much more challenging for us because of more advanced technologies that we have to research on and a lot of new barriers that we have, such as us having more things to do for our career and other classes, voice and video communications became harder as the internet becomes unstable, for me at least, etc. Despite all of that, I think we did a very good job wrapping up all the work we have done from the sprint and even make it deployable, so the next group can just skip the hard part of Docker and focus more on the part of developing operational products for the food pantry. We think that is much more important than to waste time on getting them to be able to run on an actual server, so I heavily prioritized to get it done, both on Docker Desktop and Docker Toolbox. I would say that out of all the sprints, this one is pretty boring since I personally had to read a lot comparing to the two last one that all I do is setting up systems, coding, and a whole lot of checking on people if they can run the same system and if they need some help.

For future improvement, if we have a chance to work more on the project, I think it is better to centralize our work source into either backend or frontend, then move on to another. I believe it is better that way so all the team member can know what other members are doing and learn both the backend and frontend stuff. Another improvement that our team can use is more official communication and well documenting our steps of implementing. It is the same problem that persists from the last run, but we did make sure to have more transparency in what we do this sprint, which I think is a major effort from us.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

SPRINT RETROSPECTIVE #3

What we did as group  for sprint For this sprint we worked on two main things: the database and the docker, we spent 4-5 zoom meetings expermanting with docker until finally we managed to run the angular apps in the docker containers individually. The database part took the most time to get it work but … Continue reading SPRINT RETROSPECTIVE #3 →

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

Sprint 3 – Retrospective

Sprint 3: 04/08/2020 – 05/04/2020

Sprint 3 preparation started on 04-08-2020. Since Sprint 3 was the final Sprint we were planning to get work done as much as possible. We proposed too many issues that were all appropriate, but we wouldn’t be able to finish them all on time, so we all agreed to keep the most important ones. Our top goal for this Sprint was to have the UpdateGuest service work as a whole.

These are the issues we came up within our Sprint 3 planning (we had more in our backlog):

  • Create MongoDB database for UpdateGuestService
  • Implement WebUI in Angular App
  • Decided which type of Angular form to use for Web UI
  • Learn about Angular Testing
  • Create endpoints in backend
  • Learn how to create tests for backend endpoints
  • Learn Docker
  • UpdateGuestWebUI: Create Docker Configuration
  • UpdateGuestService: Create Docker Configuration
  • Implement requested endpoints from registrar team
  • Decide what needs to be tested in the frontend
  • Implement endpoints in Frontend
  • Implement Angular form in WebUI.

 During Sprint 3 I worked in multiple issues and supported the team with issues discussions and merge requests’ review:

1 – This issue was part of Sprint 2, but we had some minor changes that needed to be done before we merged the merge request.

2 – We had to decide which Angular Form we were going to use, and as a team, we decided to use Reactive Forms.

3 – This is issue was more about learning. The first thing learned was that the latest version of Docker cannot be installed in a Windows Home edition unless you are using it as an enterprise. Docker in Action was a great resource to learn Docker.

4 – I have reviewed, approved, and merged the merge request for this issue.

5 – I created the Docker configuration of the UpdateGuestWebUI using the NGINX proxy server, which by default will run at PORT 8080, using the Docker container IP.

6 – We had a couple of merge requests for this issue. I have reviewed the merge requests of my teammates and implemented the Age&Employment component.

What we needed to do less

We should not focus only on the issues we get ourselves assigned to. Reviewing each other’s work is very important.

What worked for us as a team:

  • Reviewing each other’s work helped a lot with our progress because of the feedback we gave and received.
  • Helping each other through Gitlab Discussions and during our class meetings.
  • Checking GitLab constantly as we decided on our working policy helped us be on the same page.

What we need to improve 

There is always something that needs to be improved, especially when the team is determined to constantly make progress and succeed. In our case, we should improve the way we manage our time. 

Conclusion

I think we finished Sprint 3 successfully. We managed to work together even better than Sprint 1 & 2. The reason for that is because we were able to communicate, discuss, share, and collaborate with each other the whole time. In the end, we all feel satisfied and accomplished with the progress our team had.  

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