Author Archives: alexmle1999

Sprint #3 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/58

The card I created for adding rabbitmq to docker compose

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/backend/-/issues/8

The card I created for adding message sending to the backend

This sprint not much worked well for me, mostly because of outside forces unrelated to the class. I simply was not able to put as much time and effort in as I wanted to. Most of the sprint was spent working on figuring out the messaging system. I was able to send and receive messages locally. What I was not able to do was send messages to other computers. I am pretty sure if I kept working on it I would have gotten it eventually; I found many solutions online that I did not get to try yet. 

That does not mean everything went poorly though. Something that did work well was transitioning between the two teams. This sprint I worked more with the event system so I had to meet with Derin and Rainiery more often. It was really easy to get the team together because discord is made to do that. If we were using zoom for class meetings it would have been a lot more difficult. 

I think my team did well this sprint. Marcos and Tim were able to do a lot of work on the front end and while it did not get where we wanted it to be we still got far. This sprint I think David was able to do a lot really fast and because of that he was able to start working on the integration portions. Cam was a lot like me in that he did a lot of work outside of our system with the IAM team. 

Even though this was our last sprint, there are a lot of things I can do to improve. The improvements may not be for the next sprint (there isn’t one), but they will be things for me to carry into my career. Time management is a huge thing I need to work on. Expecting to be able to do a ton of things all in one day just does not make sense. This sprint and this class really taught me that I can only be productive for a few hours at a time. Anything after that is probably wasted. It’s better to let a bunch of short work sessions add up. I also need to make sure I do a little bit every day. It is more efficient and I forget less if I minimize time in between work sessions. 

As a team, if we were to work together again I would want us to communicate more. I think David and Tim both were looking for more work to do during the sprint. I should have asked them for help with rabbitmq. We could have sent mock messages to each other and probably would have figured out the messaging system a lot faster. When I got stuck I also could have taken a step back and helped out with some other parts of the system, maybe doing something like helping test out the front end. That would have helped me clear my mind but it also would have helped make sure the front end worked for when we demoed it.  

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/34

This is the card I made about meeting for the event system cross cutting team.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/44

This card was for deciding the message format we would use.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/43

This card was to learn how to use rabbitmq with docker.

This sprint was not significantly better than the first for me, at least in terms of productivity.  Something that worked a little better than last time was adding details to cards. Last sprint I used the cards very little, if at all. I mostly added links to cards with no explanations. This time I added explanations for the cards’ purpose and updated them (at least the meeting card was updated).

Many things also did not work well this time. Because I did not join the event cross cutting team until this sprint, I had no idea I would be working with RabbitMQ. This sprint a lot of time was spent learning about it. That probably should have been done during Sprint 1. I also just did not do as much work as I should have or wanted to do. It was a little tough having to coordinate between two teams as well. I felt like I was neglecting my original team as I worked with the event system team. The even system team if really more like two pairs though with Rainiery and I trying to coordinate with the reporting system separately to send messages to them.

As a team I think we did really well, or at least the rest of my team did really well. Adding Cameron did not disrupt our workflow at all, and he meshes really well with us. I also feel like he brings a lot to the table and is just a really smart and cool teammate in general. We are able to communicate what we need with from each other well too. Like when Tim would show us and keep us updated with the mock front end design. We were able to give some input as to what we thought needed to be changed or what we thought was working well. We were generally just on the same page and I was very satisfied with my team for this sprint.

As an individual, first and foremost I should contribute more to my team. While I do not feel like I was holding anyone back, I do not feel like I was adding anything to the team. I understand we are all working on separate systems, but I do not think I did much to move our team forward. I also should have kept my team updated better on what we were doing in the event system so we could plan ahead for sending messages from our back end. Personally being able to communicate better with everyone is something I have to work on.

Overall, while this sprint was not my best performance, it was one filled with a lot of progress of my team as whole and at the end of the day that is what is more important. I am part of a team and we have a task to accomplish. I should be a part of accomplishing that task and sharing the load equally with everyone else.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Breakable Toys

This week I looked at the pattern “Breakable Toys”. According to this pattern you have to fail at least as much as you succeed. The problem with the workplace is that failure is not supposed to happen, so if you want to learn you have to do it on your own time. You can do this by building smaller projects that are similar to what you have to do and work on them knowing that it is okay if something goes wrong. A personal wiki is a good example of a breakable toy that can teach you a lot. Even Linux was created as a breakable toy.

I like this pattern because it reinforces the idea that failure is okay. I initially disagreed with the premise that the workplace does not allow failure. Many people will fail at work and that is okay, especially if you are new in a certain field. After thinking about it I came to agree more with the author. While failure in the workplace happens, it is tolerated not encouraged. It is okay to make mistakes but you do not want to make mistakes all the time. If you are working with a breakable toy in your own time you can have catastrophic failures with nothing on the line but your own time and sanity.

This is a pattern I should try to fit into my own life. My friend David, who is also in this course, is always making some kind of breakable toy and it is really admirable. He has been doing it for years though so I should not expect to be on his level just yet. He’s even making his own programming language right now which is something I can’t even imagine myself doing.

Making breakable toys is definitely the way forward for me to improve my programming skills. More than anything I need to write more code. I need to learn more and be forced to solve more problems. Even though I have been in the CS program for three years, I do not feel I have written very much code – especially code from scratch. Most things are 80% done by the time they are assigned to me; I just put the finishing touches.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

JaCoCo

After taking a quick look at JaCoCo in class I wanted to learn a bit more about it. This article is an introduction to using JaCoCo and gives some good examples.

The article explains that when you write tests there are some criteria to consider:

“

  • We want to make sure that the parts of the code that are best tested are the parts that are most likely to contain bugs.
  • We want to focus our tests on parts of the application that are critical, the parts where bugs are most likely to lead to a bad outcome for our customers.
  • We don’t want to write tests that repeatedly cover the same areas of the code while ignoring other parts of the code.

“

You can find which parts of the code are the most likely to have bugs by finding the most complex parts. A common way to do this is using cyclomatic complexity (check the article for the algorithm).

JaCoCo measures code coverage, can report on the complexity of each method, and can tell you how much complexity is untested. In the article a lot of the things we covered in class are repeated, but it helps to see it again to reinforce the concepts and also to reference for the future. While we spoke about it in class, a lot of the things that are said are not recorded anywhere.

The article also brings up the use of JaCoCo to measure complexity. After getting as much code coverage as possible you can refactor your code if the complexity score is too high. In the example they reduce a method’s complexity from 21 points to 9 points. That just goes to show how useful JaCoCo is. After reducing complexity and improving code coverage you can be confident your code is ready for a code review.  

View at Medium.com

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Code Reviews

This week I wanted to learn a little more about code reviews. As first I thought, “Yeah code reviews just get someone to look at your code isn’t that common sense?”. After looking into it more I learned code reviews have a lot of benefits that you might not think of.

Code reviews share knowledge. Most people are going to be working as part of a team. With code reviews there is always more than one person that understands some portion of the project. This makes the team more flexible. With this shared knowledge also comes a better ability to estimate how much work some portion of the project is. When the reviewer gives feedback the are also exposed to the complexity that may underlie an issue. This gives multiple informed inputs to create more reliable estimates for the team.

Code reviews also give you a break from the monotony of a certain task. If you are spending a lot of time on a certain part of the project, doing a code review is like a breath of fresh air. It is liberating to work on a different area of the project. It can even feel fun, almost like a vacation.

Code reviews can also motivate developers to work harder. When you know one of your peers is going to take a look at your work you might take an extra effort to create something you find presentable. You would want your code to be clean and for all your tests to pass.

Code reviews are really more than just having someone else look at what you have done. They are an important part of any software development team and deserve to be formally incorporated into the development process.

atlassian.com/agile/software-development/code-reviews

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Reading List

This week I took a look at the pattern “Reading List”. According to this pattern, you should keep a list of books that you intend to read. By making a list of the books you have read and the are going to read, you give yourself an easy way to reflect on your own patterns of studying. As you read you will probably come across more books in the references or bibliography sections. You can add those books to your list as well. Your reading list should also be somewhere online and publicly available. Others may benefit from it or you may benefit from their suggestions.

Despite always being assigned at least one book for every CS course I have taken, I have never (at least until now) considered really using a book to learn about programming or computer science. It seems like a no-brainer to use the internet for anything computer related. Modern search engines allow you to ask extremely specific questions and get almost exactly what you are looking for. Maybe this is because as a student I always know what I need to learn.

As the author points out, it is hard to know where you need to go next or what you need to learn next. I am a student, so I always have a professor who provides a curriculum to follow and assignments to complete. I always know what I need to learn. This is all going to change now because I am graduating in a few weeks. I will have to take the initiative to set my own course of study if I want to improve as a programmer. Without any direction I should probably turn to books.

It is probably time I start reading more books about software development, especially if that is the field I am going to go into. Reading the “Apprenticeship Patterns” book has made me realize books do have a lot to offer aspiring programmers. They are a good way of forcing material in front of you. Because books are restricted by their physical form, authors have to put a lot of material in the book to make it worthwhile. You don’t have to figure out what to learn next; books are carefully curated sections of study, at least textbooks are. It’s about time I start my own reading list too, starting with all the books I neglected to read in the past few years.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

This chapter’s opening quote was a very insightful one for me. It says: ” Tomorrow I need to look stupider and feel better about it. This staying quiet and trying to guess what’s going on isn’t working so well.” The whole point of this chapter is that there are going to be times when you do not understand what is happening, what you need to do, or how to accomplish the task at hand. This is ok. Even if there are people depending on you to just know the right answer you will not always. You must ask questions and show that you are capable of learning how to do your job. That is how you grow as a craftsman.

“Expose your ignorance” is a pattern I have a lot to learn from. The opening quote talks about staying quiet when you do not know what is going on and that is something I am often guilty of. Just like the author says, I am afraid of looking incompetent. I often feel this way despite knowing I am not yet expected to be a competent programmer; if I were then I probably would not be in this class (I would consider some of my peers to be pretty competent though). As I student I am surrounded by professors who are literally being paid for me to expose my ignorance to, and they are happy to hear it. I am confident all the faculty in the CS department would love to hear more students ask questions and admit they do not have any idea what is going on. Most classes are silent though, especially in online courses. I am not sure if it is from a lack of interest in the course, the difficulties of online courses, or a fear of asking questions (it is probably a combination of the three.)

Moving forward I will really keep this pattern in mind, both as I finish this course and as I go out into the workforce. Not knowing everything does not mean you are not good enough. It simply means you are not good enough yet. Asking questions and actively working to improve shows that you are willing to put in the effort to become better.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Integration Testing

This week I wanted to look at integration testing. Most projects have multiple components coded by different programmers. The purpose of integration testing is to expose any defects in the way these components interact with each other. It is sometimes called ‘I & T’ (Integration and Testing), ‘String Testing’, or ‘Thread Testing’.

Integration testing is the next level of testing after unit testing. While each individual component of the software is unit tested, there may still be defects. These may be because:

  • A module written by one programmer may have different logic and understanding of requirements from another causing their two components to work together improperly.
  • New requirements may be added by the customer that need to be tested.
  • The software may not be interacting with the database correctly.

There are multiple approaches to integration testing. Big bang testing is integrating all the components at once and testing as a unit. This works well for small systems, but it may be hard to isolate issues. Incremental testing starts with only a few modules ad gradually adds more after testing for proper function. This can be done bottom-up by testing lower-level modules first, or it can be done top-down with higher level modules first. There is also the sandwich method which tests higher level and lower level simultaneously and then combines the two.

While we have not yet taken a look at integration testing in class, I wanted to have a rough idea of what it is at least. I am sure our POGIL activities will go more in depth and explore why integration testing is used as well as exactly how it is done.

https://www.guru99.com/integration-testing.html

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Kindred Spirits

The apprenticeship pattern I chose this week is “Kindred Spirits”. According to this pattern, you may find yourself in a workplace that does not encourage software craftsmanship. In the absence of a mentor, you should find like-minded people who are also looking to become software craftsmen. Unlike mentors who are people you aspire to be like, peers are people you can feel more comfortable with. You can exchange ideas without feeling pressured like you might with a mentor. It is important to remember though that you should not just follow the crowd. It is important to think for yourself.

As a computer science student, I have the good fortune of being surrounded by kindred spirits. Most of my peers are of a similar experience level to me. Because we are all in the same classes, we are all learning the same language and doing the same assignments. It gives me so many other people I can bounce ideas off.

The author also discussed the difference between mentors and kindred spirits, and I think that difference is really highlighted when you are a student. It is often intimidating to ask professors for help or ask for their opinion. Sometimes when a professor tells you something or gives you a suggestion, you feel like that is the only way you can do something. With other students you are not as afraid to ask questions, especially if you are friends with each other. You are also able to take advice from them without feeling like that is the only way a problem can be solved.

Under the “Action” section the author discusses finding communities to join based on the languages you know or the tools you use. This is another benefit of being a student. Groups like the computer science club offer an in-person community to be a member of. It might be a bit harder to find a group after graduating but it is still do-able – especially with social media. If you cannot find an in-person group to join there will always be a discord server to join. You could even organize your own group easily using social media like the author says to do.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

7 Types of Software Testing

This week I wanted to learn more about the types of software testing that are out there. In class we already learned about methods like black and white box testing. I wanted to see if there were more methods that we may not have covered. 

This article describes 7 of the most common software testing methods. It is important to note that software testing and software development as a whole is always changing. As such there are many more than just seven software testing methods and there will definitely be new methods created in the future. These seven here are just some of the most common. 

They are:

  1. Black Box Testing
  2. White Box Testing
  3. Acceptance Testing
  4. Automated testing
  5. Regression Testing
  6. Functional Testing
  7. Exploratory Testing

Something I found interesting about this article is the relationship the author outlined between automated and regression testing. Automated testing is making your tests run automatically and regression testing is testing to verify the system still works as it did before some changes were made. Automated and regression testing go hand in hand because as software is incrementally changed you have to perform regression testing often. This is the real purpose behind automated testing – you can test repeatedly.

Another interesting method that was discussed is exploratory testing. The author refers to it as a “lazy” method of testing but also acknowledges its merits. Exploratory testing is essentially looking at a certain area of an application and exploring for any unexpected behavior. This testing method does not have any test cases. While this testing method does not really apply to the small applications that we work with in class, it may be useful in the capstone course. In that course we are creating a much larger web application with a front and backend so exploring may prove useful. 

https://usersnap.com/blog/software-testing-basics/

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.