Author Archives: Tyler Rego

Retrospective #3

The semester has finally come to an end, and that means that it is time for my third and final retrospective blog. This sprint was probably our best sprint in terms of communication, but it is weird because while we got a lot of work done, we ultimately had to resort to running the project locally due to issues with Docker. Below are the links to the progress that I made this sprint.

This is the link where I created one overall project with a Docker compose file because I was testing Docker compose and getting the containers to all run at the same time under one default network.

Here is where we were (finally) able to connect the database to the REST server. We used the JDBC connection driver to connect to the database from a Java application to add to the database from the application.

This is the Dockerfile that allows the database to run in a Docker container. I included the registerguest.sql in this to be able to create the database within the Docker container.

During this final sprint, I felt as though I was able to do a lot more than the previous sprints because there was a lot of experimenting with the database that had to be done this time around. For example, we had to try ways to connect the database to the REST server. I also had to figure out how to use Docker and get the database running in a docker container during this sprint. Our GitLab use was more or less optimized this sprint as we were using our cards, and commenting on our issues. We used the “block-by” feature much more this sprint. Our communication was also much better this sprint as we were meeting on Zoom much more, and texting among ourselves more about issues we were having.

I would say that the only thing that didn’t work well for us was our Docker use. We were all getting so many different, unforeseen errors that seemed like they had no solution after hours of research. I believe that the issue could have been that I was using Docker Desktop while the others were using Docker Toolbox, however, when I switched to Docker Toolbox, I couldn’t even start it up due to virtualization issues that I couldn’t find the solution too. Besides that, I’d say my only other issue was procrastination as I was still getting things done at the last possible moment rather than giving myself more time to work through all of the issues that we were facing which only led to more pressure on myself. Although, last sprint, I said that I wanted to get the database connected to the rest server, start my work on Docker, and have more Zoom meetings. I was able to do all of those things, so I am not too upset with how this Sprint turned out.

While we don’t have any sprints left for this semester, I still think we could all benefit from improvements because everybody can always improve. For example, whenever I work on a group project again at any point in my career, I will be sure to communicate more with both my teammates and other groups if it is applicable. I will also be working on my procrastination issues as I begin my career.

Dr. Wurst said that although we didn’t get an entire project working, that it was still very impressive that we were able to do what we did from scratch and have a functioning project to present. He also said that we should be proud of our work, and I completely agree. I don’t think what we did was easy by any means, and I am honored to have worked on a project like this for my last school assignment ever.

 

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Retrospective #2

There is one month left in the semester and it is already time for the second retrospective blog. This was certainly an interesting sprint due to the unprecedented pandemic that took the world by storm. Luckily, it doesn’t hinder us too much as technology exists enough to where we can still collaborate with our partners and other teams thanks to discord, Zoom, Gitlab, etc. To begin this post, I’ll be posting links to the progress I made this sprint.

This is thew link to our database repository because I had to modify it to reflect the new changes that were made after our meeting with Joanne. I am also using this link to show that the branches have been merged because I am no longer testing it.

This is a link to another one of my closed issues. This issue pertains to connecting the database to the server. While, I haven’t figured it out quite yet, there is a link in this issue with a tutorial that I have been using to experiment connecting servers with databases.

There wasn’t a large amount done by me on this sprint due to the COVID-19 outbreak which caused us to have a whole extra week off of school, and completely shifted us to online learning. However, there was a large improvement from the last sprint. Our Gitlab use improved immensely between sprint 1 and sprint 2. We started using the “blocked by” features to make sure issues were getting done in the order that they had to be. We also started commenting more on our issues, so everyone can see our progress rather than just our group knowing what we did. Also, I feel like our communication worked better compared to last sprint, but it could definitely still be improved.

As for what didn’t work well, I think that I could have gotten more work done for this sprint seeing that I only worked on database stuff for this sprint. I also feel like were still only involved in our each individual part of the project when we need to be more involved in each others parts. I also believe our communication with other teams could still use some work especially for this upcoming sprint because if we have time, we need to work on the aesthetic of our web application.

When it comes down to improvements, I know that I can try to work on a little more for this upcoming sprint. Once I figure out how to connect the database to the server, I can then move on to starting my work on Docker and helping everyone else with what they have to do, and hopefully we’ll be able to get to aesthetic because I feel like I would be helpful on that front. As for the team improvements, I still think that our communication with each other could be improved. For example, we can have more zoom meetings with each other and show each other our work. I also think we should talk to the other teams as well because they might be able to help us with things that we are stuck with. Besides that, I think our team is in great shape for the last sprint.

 

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Retrospective #1

Now that Sprint 1 has come to an end, it is time for the retrospective blog. I will start by including everything I contributed to this sprint:

This link is a note in an issue where I have put a document discussing the Pros and Cons of whether we should be using a relational database or not. I put some examples of relational databases and non-relational databases for when I was making a decision along with links explaining a few of them.

This link is another comment on GitLab basically stating that we are using mySQL because of the simplicity and it is easy to look up information on it if needed.

This is the repository for our database currently, it is currently on a separate branch and not merged with the master due to a sudden change in database fields which will be implemented first thing in the next sprint.

This is another repository that holds the results of completing the Tour of Heroes Angular tutorial. This was the last thing completed for the current sprint to give me a refresher on Angular as I haven’t worked with Angular in a little over a year.

This was our first sprint so everything obviously wasn’t going to be perfect. However, I believe that we used GitLab very well considering this is my first time actually collaborating on a big project using GitLab. I think that we created issues that were specific enough to be considered issues. We utilized the boards well too. Our communication was mainly done through class and text message, but overall, I still think we communicated every issue that needed to be communicated.

Of course there were things that didn’t work well either considering it was the first sprint and this is most of our first experiences with Agile and sprints. While I mentioned that our GitLab use was very good. There were some faults with it as well. For example, my desktop didn’t let me push to GitLab which is an issue that still needs to be resolved. I specifically had trouble working with the separate branches because it was confusing at first. Our issues weren’t created the right way at first, and had to be restarted even though there were ways to just edit them without restarting. We had good communication, but I felt as though I wasn’t as involved as I should have been with the other team members work. I also think that there wasn’t enough communication between the other groups in the class as a whole.

Some of the changes that can be made as a team is more involvement in each others work. I think that we can all spend more class time looking at each others work rather than looking at it on our own time because this allows for more discussion. I also think that our team could start communicating with other teams more. Most of the teams came to us rather than us going over to the other teams to collaborate.

My individual changes that I need to make is talking more to my team members about what they have been working on rather than focusing on my own work. I could offer more solutions to the front end team about design. Probably my biggest issue would be my procrastination. I have to start working on my assignments earlier because that has an effect on how the rest of my team performs. I think that this next sprint will be much better now that we have been exposed to this more.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Breakable Toys

This week I decided to write about the Breakable Toys pattern because the last pattern that I wrote about mentioned this pattern, and it was in the See Also section of the last pattern as well. From the title, I have gathered that this pattern is about just random coding projects that have no consequences and the programmer can just experiment with the code and try out new things.

After reading the Context section i discovered that this pattern involves failure and learning from those failures in order to become a better developer. The problem of this pattern basically says that you work in a field that doesn’t allow for failure, but your individual growth depends on failure. This makes sense because there isn’t a lot of room for mistakes in a real work environment because mistakes can lead to much bigger issues.

The solution to this problem is as I mentioned earlier with slight differences. Rather than coding just random projects, you should code projects that “are similar in toolset” (Oshineye, Hoover). The authors recommend using Wikis as your breakable toy. They say this because of their simplicity. They also mention that they can be great for learning HTTP and REST which I thought was interesting because our Capstone involves both HTTP and REST, so maybe I should start working on a wiki on the side. Another breakable toy idea that they suggested that one of their ex-colleagues used is creating games. This is a cool tool because it is a fun way to learn how to code because at the end you are given a product that you can play with way after the fact. Realistically, you could just look up Tetris on the internet, but it is much cooler if you are playing something of your own creation. Lastly, they mention how this pattern is similar to Be The Worst which is actually what I plan on writing about for my next blog.

The Action section basically just tells the programmer to create a very simple wiki, and add features into it as you continue with your career. I like this method because there are no repercussions if you mess up and you can learn from these mistakes. I think that I will actually use this pattern in the future, and my internship has kind of done this for me too. The projects that are assigned to me are projects that they use in their day to day life, but I have freedom to make mistakes and learn from them.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice

For this weeks assignment, I decided to write about the “Practice, Practice, Practice” pattern in the book. This one looked interesting to me because I thought to myself, “Obviously, you have to practice, what could they possibly have written for this” To my surprise they actually had a method that I wasn’t expecting.

The article starts off with a context and a problem like all of the sections do and basically the problem is that a programmer doesn’t have room to make mistakes in their daily job, and they can’t learn because of that. This problem makes sense because messing up in your daily job is too stressful. You aren’t given any room to actually learn from those mistakes.

The solution part, like all the patterns, is the longest part because this is where everything is explained. This section leads off by describing the ideal world as being like a school almost. Programmers can be given random assignments and receive feedback on said assignments, and they can get more assignments as they progress. However, we don’t live in that ideal world, so programmers “must fall back on their own resources to achieve the same effect.” (Oshineye, Hoover).

The next part is what really intrigued me. They relate coding to martial arts by saying the katas are a great way to practice. Katas are basically opponent less exercises to take away the stress from the fighter so they can just learn. In programming terms, this basically means just performing exercises on your own to help you learn without the pressure of being fired. I love that someone made an actual coding dojo in Paris because it is such a good idea. It gives people the chance to code stress free, and there are other people there to review the code that is being produced, and help those who are struggling.

The action section tells the reader to find a problem in one of their books that they should struggle with and they should keep doing it and keep note of how their solutions change each time they perform the exercise. This is a great way to learn because it gives the programmer a chance to learn how to better their code and come up with better, more efficient solutions.

Overall, I really enjoyed this section. Like I mentioned before, I didn’t know how they made practice a whole pattern, but it was very interesting. The whole martial arts metaphor worked really well because coding and martial arts apparently have a lot of similarities. I plan on using this method in my future.

 

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

The White Belt

For this week’s blog post, I decided to write about The White Belt.  This section is in Chapter 2 which is called Emptying The Cup, and if I remember the introduction for Chapter 2 correctly, this chapter 100% belongs in this section. Like all sections in this book, it is split up into 5 sections, context, problem, solution, action, and see also. The context is a short sentence that basically explains the reader is now confident in his abilities in a certain language, and people rely on them for help. I was actually shocked to read this because typically the white belt symbolizes the beginning, and this book’s description of a white belt is knowing a language and helping people. That’s shocking to me because that just means I have no belt because I feel like I’m in no position to be helping people with the skills I have now.

The next section is the problem. This section was also very short, but it should be because it is only discussing the issue. The issue for this section is that it is difficult to learn new things, and that your “personal development may have stalled” (Oshineye, Hoover). While this isn’t an issue for me yet because I am still learning my first language, this could very much be an issue in the future for me as I also struggle with learning new things.

The solution section urges the reader to start to learn new things by unlearning the things he already knows. They use real life examples as well as some code examples to get their point across. I particularly enjoyed the code section because I liked how they showed the same process being done with two “radically different” (Oshineye, Hoover). languages. They did this to show that because you have a solution in one language, you should still learn a new language to broaden your horizons.

This section was a really easy read for me. The part where they talked about how the white belt had to learn the way while the black belt knows the way really hit me because that was how my internship was. I had to watch and learn everyday before I could even do anything, and it was actually nice to learn along the way because I realized there was so much more that I had to learn before starting my real job.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns

This week we were tasked with reading and reviewing chapter 1 and the introductions of chapters 2-6 of our book, Apprenticeship Patterns. 

Chapter 1: This was a great introduction to a book. I am not a person who usually reads books because I usually find them boring, but I have to say that this introduction has really grabbed my attention. The parts that really stuck out to me was the very first paragraph, and Dave’s Story. I loved the first paragraph because it says that the book is for people who “have had a taste of developing and want to take it further.” This is an important quote because that includes me and every CS student at Worcester State. This capstone project is some student’s first taste of real development. I really liked Dave’s story too because it reminded me of myself, I have had trouble with software development in my time here at Worcester State, but through my classes, I have developed confidence in my abilities, and learned a lot. The description of apprenticeship also reminds me of my internship because that is what I am doing there. I am basically learning from my master by doing small projects that give me experience.

Chapter 2: I felt that this chapter was more irrelevant because most of us have already passed the step of choosing our first language. By first language, I mean choosing one that we will become fluent in. I have chosen Java as mine because that is what I have learned the most about, and it is the primary language that my job uses as well. However, this chapter did show me that you don’t have to be proficient in multiple languages, but you should master one of them. I also really enjoyed the connection between apprenticeship and the “Tasting a New Cup of Tea” story. It has a really deep meaning of getting rid of bad things, and learning new and better things. I will also be using that empty java class technique for when I need to test unknown features.

Chapter 3: I felt as though this chapter was a direct attack on me. Honestly, I am one of those people that is in this field for the money, and I will probably be taking the job that offers me the highest amount of money. However, after reading through this I will be thinking about learning more about the long road as it could help me enjoy what I do and make a lot of money along the way.

Chapter 4: This chapter was great. I love the “Be the Worst” mentality because I do think like this, but unlike these other people. I haven’t been using that to better myself. I always just assumed I wouldn’t be as good as them, but I should be using that as a way to learn more so I can become as good or better than them.

Chapter 5: This chapter was less interesting to me because it told me stuff that I already know. I know that I need to expand my horizons when it comes to software development. Another reason I disliked this part was because it told me to do a lot of reading, and as I mentioned before I do not like reading. I’m going to use this section as my chapter 6 review too because they both have to do with reading. Chapter 6 was irrelevant to me because I don’t have an extensive reading list nor plan on having one.

 

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

The LibreFoodPantry FOSSisms

For this first (technically second) post of this semester,  I decided to talk about the FOSSisms section of the LibreFoodPantry main page. This sections was located under the about section. This sections leads off with a short introduction about what FOSSisms are and it was very useful considering I have never seen the word used before. To put it simply, FOSSisms are maxims that Heidi Ellis developed from, open source culture. I won’t talk about all 16 of them because I would be here all day, but I will talk about some of my favorites. I really enjoyed the productively lost section because it explains that the students should get lost, but that they should use this sense of confusion to learn more about what they are confused about. The last section, I’ll talk about is avoiding uncommunicated work. This section was interesting because it basically says that all work should be communicated with other members of the group, and I think that is extremely important for this project that we are about to take on.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

One Month Later, We’re Back

Hello again everyone, I know it has only been a month, but I am back to writing posts bi-weekly for my software development capstone. In this blog, I will be mainly discussing topics covered from the book for CS-448. This is my last semester at Worcester State University, and I’m looking forward to writing more blogs for all of you.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

The Last Blog, Ultra Efficient Computers

For what may possibly be my last ever blog post on this blog, I found an article that discusses the possibility of Ultra-efficient computers using Atomic scale manufacturing. That sentence alone is enough to grab anyone’s attention (It certainly got mine.) After reading the introduction, I discovered that this article is about saving the environment rather than just having really fast computers. However, that’s still great because something needs to be done about the environment and this could be it. The article states that today’s computers require enough power to release more than 1 gigatonne of carbon emissions per year. That is actually really bad.  ACS Nano has a solution though. They are making computers that store more data, and use less power. You would think that this wouldn’t be possible without some kind of trade off, but they figured it out.

The attained this by manipulating singular atoms in order to produce “ultra dense memory arrays” which can store way more data in a smaller space. They have ran into an issue where bottleneck is apparent, so they are still trying to find a way to make this process more efficient. In order to conduct this process, scientists must use a technique called hydrogen lithography. This is a process in which they remove certain hydrogen atoms from a silicon surface in order to write more data. They demonstrated this technique on a 24-bit memory array, and the result was a 1000 times faster fabrication of atomic computers. This means that “real world” manufacturing can begin. According to ACS, this method would consume 100 times less power, making it a huge step in the right direction towards a cleaner Earth.

It was a pleasure reading this article considering it was very short and it had a lot of interesting information on it. I didn’t expect so many chemistry topics to be involved, but I love chemistry so that is okay. This will probably be my last blog post ever, so to my readers, you have been a great audience. Thank you.

https://www.sciencedaily.com/releases/2019/11/191127090225.htm

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.