Author Archives: therbsty

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.

Concrete Skills

  • Summary of the pattern.

The pattern is about how you need to have concentrate skills that can actually contribute to a team. In addition to general knowledge and willingness to learn. It says how a lot of teams want someone who can help in some way at the beginning and don’t need to be taught everything before they can help the team at all.

  • Your reaction to the pattern.
  • What did you find interesting
  • What did you find useful
  • What did you find thought-provoking about the pattern
  • Has the pattern caused you to change the way you think about your intended profession, or how you think you will work? 
  • Do you disagree with something in the patterns And why?
  • The tag for the in which the post was made, E.g. Week-1. (See the Schedule at the end of this syllabus for numbers.)
  • 350-450 words.

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

Unleash Your Enthusiasm

This apprenticeship pattern is about how when starting an apprenticeship you need to use enthusiasm to help the team since it is the only thing you have over the more established and experienced members of the team. It starts out saying how most people starting out have a problem when they start out in their career, they try to hide their enthusiasm.  They do this because they are worried about looking foolish or sticking out from the group. Although it says that there are risks to unleashing their enthusiasm. Such as if the team isn’t welcome coming to new comers the team might mock you behind your back. It also says that if the team values competence more than learning it might not be a good thing to unleash your enthusiasm. It says that if the team seems like a good fit for it they should unleash their enthusiasm because their enthusiasm is one of their biggest strengths. It says that it is one of their biggest strengths because unleashing your  enthusiasm allows out of the box thinking and new ideas that more experienced people wouldn’t think of. Lastly, it says that unleashing your enthusiasm is the most important thing you can bring to the team.

I think that the pattern is very good advice. It tells you what unique skills you can bring that jaded decrepit old hands can’t. I also found it interesting how the pattern says that even though you don’t have experience in a certain way that can be a good thing.In addition I found it useful how it gives you examples of why this is helpful and also when not to do it.I found it thought provoking how it says that your inexperience can be a benefit.This apprenticeship pattern has given me confidence that even though I don’t have much professional experience I can still be a benefit to a team.There wasn’t really anything I disagreed with in this pattern. Overall I agree with it completely and think it something everyone should read when they start out in a new apprenticeship.

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

The White Belt

The overall idea of the white belt apprenticeship pattern is that when you are learning a new skill for example a new language you need to actually need to learn a new skill and a new process. You can’t just apply the old process to the new skill. That will only result in, as the pattern says in its programming example, “writing fortran in any other language”. It says you can accomplish this by unlearning some of your previous skills and starting from scratch with the new skill. It also says that many people are scared to do that because they worry about looking foolish or ignorant. In the example of learning a new programming language it’s important because if you don’t unlearn some of your habits from a programming language you already know and unlearn how to code in that old language you will end up never learning how to use some of the new features of the new language. This is the overall idea and point of the white belt apprenticeship pattern.

I like and agreed with applying this pattern and its main point. I like how it says that in order to learn something you have to start from the beginning and let go of how preconceived notions about how code should be written. I agree with how it says if you don’t do that you won’t be able to write in the new language the way it was meant to be used. I also agree with how it says also that if you dont you will miss out on some  features of the new language.

I found a lot of it interesting and useful. I found it interesting how there was a saying about writing a new language like the old language. I found it useful to remember that when learning a new language it’s important. I found it thought provoking how it says that it’s important to unlearn before you learn. It’s kinda the opposite of what you would think at first. However it makes sense. I will definitely keep this in mind and use this in my future career when learning new languages or skills. Overall I really like this pattern.

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

Sprint Retrospective 2

For the first sprint we did most of the programming of the individual parts of the service. The first thing we did was update the working documentation with the new information from the meeting with the food pantry. Also in the working documentation we Changed the zip code and id to string in the working documentation since they can start with zero. This was pointed out by another team. The next thing we did was to update the REST server with the new information from the meeting with the food pantry. We also updated the register application with the new information from the meeting with the food pantry. The last thing we updated with new food pantry information was the database. Also in the database we looked into how to connect the database to the REST server. Next we created a new angular project with all the different types of inputs the angular applications would need to run. This was done to help the people writing the angular applications. After that we added a register class to the register application to send over the register endpoint. We also added an error checking method to the register application so that a bad registration cant be sent to the REST server. Next we added all the input elements to the register application and connected them to variables in the typescript file. The last thing we did with the register application was to connect it to the register endpoint from the REST server. We also added all the input elements to the is registered application and connected them to variables in the typescript file. The last thing we did with the is registered application was to connect it to the register endpoint from the REST server. This was all everything we did for the sprint.

What i did for sprint

Update the working documentation  with the new information from the meeting with the food pantry

Changed the zip code and id to string in the working documentation since they can start with zero.

Update the rest API with the new information from the meeting with the food pantry

Changed the zip code and id to string in the rest API since they can start with zero.

Create an angular project with examples of the different inputs

Added register class to register application

Added error checking method to register application

Reflection on what worked well?

Planning was much better than last time

Used the boards better

Added relations to the issues

Ordered issues better

Reflection on what didn’t work well?

Did Not communicate enough during sprint

Didn’t talk to each other during two week break at all

Didn’t finish everything

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

Try to keep each other updated on our progress during sprint better

Finish everything

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

Try to tell other people what i am doing more

Ask other people option more

Links to evidence of activity on GitLab with one sentence description for each

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

  • The input example project

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

  • The is registered application

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

  • The register application

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

  • The rest server

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/register-guest-data-base/-/tree/master

  • The database

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

Sprint Retrospective 1

For the first sprint we did a lot of setup tasks as well as the designing of the architecture. In addition to some of the programming. The first thing we did was talk about the architectural design of the service. Once that was settled a group member created the wireframe for the “register” user interface. A group member also created the wireframe for the “is registered” user interface. The next thing we did was create the blank projects on gitlab. After this we initialized two blank angular apps in the user interface projects. We also created the blank rest server. While this one going on a group member was working the database understanding it and creating one that the architectural design specified. At the same time we created the class the design specified in the rest api and created the endpoints. We also connected the endpoints to a run-time database to test the rest server. In Addition we put in a template to learn how to make scheduled calls in a rest server. At the same time we also started coding the wireframe designs in HTML pages. That basically all we did for the sprint.

For the sprint I personally first created the main documentation issue and kept  it updated. I did this after the meetings or after consulting with the rest of the team and coming to a consensus with them. I also did several of the issues. First I did the issues for creating the 4 projects and initializing them. I also did the issue for designing the endpoints. I also did the issue for creating the object classes for the rest server. In addition i did the issues for creating the endpoints and finishing the rest server with a fakes database implementation. The last issue I did was researching how to make a scheduled method call in a rest server.

For the sprint I personally first created the main documentation issue and kept  it updated. I did this after the meetings or after consulting with the rest of the team and coming to a consensus with them. I also did several of the issues. First I did the issues for creating the 4 projects and initializing them. I also did the issue for designing the endpoints. I also did the issue for creating the object classes for the rest server. In addition i did the issues for creating the endpoints and finishing the rest server with a fakes database implementation. The last issue I did was researching how to make a scheduled method call in a rest server.

I thought the sprint went mostly well. I thought we did using the issue to break the work of the project up into smaller pieces for us to do. I also thought we did a good job of assigning issues to different people to make sure everyone had something to do. Lastly, I thought the documation issue worked well to keep the whole team on the same page as far as what the current plan was.

    Even though the sprint went well there were still some things we needed to improve on. I feel like there should have been more time spent planning before we started. Since a lot of  the first half of the sprint was spent changing our mind on the design and having to start over and this was inefficient. In addition before the working documentation issue was made we were not really telling each other what the plan was or when we changed it. We also could have had better communication overall especially at the start. We got much better later on though.

There are a few we could do better for the next sprint. I don’t think there is much however as we fixed most of the problems by the end of this sprint. The most important thing is to have a better planning meeting. We could be more communicative with each other on what we are doing. Lastly i guess the communication we do have could be better quality and more informative.

I could do a better job individually too. For the next sprint I need to do a better job of explaining why I am making the decisions i am making. I could also do a better job keeping the team updated on what I am doing and my progress. Lastly I could do a better job with the overall documentation of my issues. That being said, I don’t think me or anyone else in the team really needs to be better individually to much.  I think the biggest problem was the poor planning meeting at the beginning.

GITLAB LINKS:

  1. https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest
    1. This is the whole project.
  2. https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/register-guest-service
    1. This is the rest server project i was working on.
  3. https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Plan/-/boards
    1. This is the issue board for all our issues.
  4. https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Plan/issues/16
    1. This is the working documentation issue that has the current plan for the project.

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

Apprenticeship Patterns Guidance for the Aspiring Software Craftsman Reaction

summary

what was interesting

what was the most useful

what changed my opinion

what do i disagree with

what chapter was the most relevent

overall thoughts

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

FOSSisms

Hello All, today I decided to talk about FOSSisms 16 principles of open source software in teaching. On that that found interesting was number seven which was ask for forgiveness not permission. It basically said that should just start working on something and you don’t need to ask first. This is because changes you make have are unlikely to derail a project. This is because of the use of version control which means it is very easy for the community to undo what you did or even fix the mistake you made. I picked this a subject and this particular rule because it very different to how you typically work on group project where you should communicate and talk to other before you do anything

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

Introductory Blog Post

This is my blog for CS-448-01 Spring 2020

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

The Finished Project

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