Author Archives: Michael Mendes

Sprint 3 Retrospective

It is hard to believe that I am writing the final blog post for my capstone already, it feels like I was feverishly reading through Keycloak documentation only weeks ago. This final sprint did not exactly go according to plan, but I am not entirely upset with the results. Overall I felt that my team did well on this sprint, but again felt like I should have been further ahead on my own work with the IAM System to allow myself to help more with the Inventory System. But there was some needed bug fixing and research done into different aspects of Keycloak itself that should be helpful further down the line.

As stated, I felt as though the Inventory System team all seemed to make steady progress in developing the different parts of it. There was progress made on the API in addition to the various front ends needed for the Inventory System and it seems that there is a whole skeleton system now in place that can be iterated on later. As for the work on Keycloak, when meeting with Cam and Migena we managed to work out some errors I had made in the setup of some attributes needed to connect Keycloak to Professor Stoney’s basic front end. In addition to this, we discovered that our Keycloak docker image could have a backend with persistence set up relatively easily, with a variety of choices listed here https://hub.docker.com/r/jboss/keycloak/. The other major focus for myself this sprint was on figuring out how to get user information from tokens by making calls from an Open API, as I knew this would be needed for implementing Keycloak into the Inventory System, and potentially others. In doing this I did manage to get authentication tokens, but did not make more progress past this. Once again I felt as though none of this should have taken as long as it did, throughout the sprint I feel like I would get bogged down by one issue and could have handled this a bit better.

I feel as though there are not many changes that could be made for our team to improve, as we simply ran out of time to start compiling all of our work together. As stated I feel like the Inventory System team did get a significant amount of work done, but there just was not enough time to truly start to work together with all of the different systems we had worked on. As for my own performance, I simply feel like I could have done more had I spent more time working. Time management has been a skill I have slowly developed over the course of my time at school, and it has certainly come a long way. That being said, there were still multiple times this sprint where I could have buckled down and simply focused on getting more work done. In summary, I feel as though the work that was done will provide a solid foundation that can be expanded on, but could have been fleshed out a little more had I managed my time more efficiently.

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Dig Deeper

Another issue I have been facing as of late is related to my understanding of the systems and software that I use. I often find that I am able to learn just enough to meet the requirements for my assignment, but lack perspective of exactly what is going on behind the scenes. One class in particular that this was true for would be data structures, which was quite challenging considering I had no experience with any facet of it before then. This resulted in me learning exactly what I needed, nothing more or less, to succeed. Upon reflection of this class, I decided to choose the Dig Deeper pattern to discuss this week.

The first major tip given is one that I have often encountered in other patterns, being to break a problem down to its most abse form. As stated in the pattern, most programming issues can be broken down to an incorrect algorithm. Once the problem is broken down, you can examine each part of the problem in great detail, giving you a more in-depth understanding of both the problem and the tools used to solve it. Furthermore, the pattern states that you should focus on reading as much original documentation as possible since many articles may lose some information in translation. As for retaining knowledge, once again breakable tools are referenced, which I have discussed further in a previous post. Any new understanding can be represented in the form of a fun hobby program or blog post. Throughout the process of reading these patterns I have realized how interconnected they are, often relying on each other to result in well rounded software design principles.

One thing to note is that it does feel a bit strange to try and relate to these patterns, particularly because they are very clearly written for someone currently in the workforce in a software development position in mind. Regardless they still have some knowledge that will likely benefit developers at a variety of levels. This perspective being less relevant to me is my only real complaint, other than this I have found these patterns quite helpful! This will be my last post for the time being, but after everything I have ready I may have to return to this blog later on. Thank you for reading and, as always, if you want to read this yourself it will be linked below!

Source: 

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch06s04.html

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Passion

I decided to once again choose patterns that cover related issues, this one being about passion. This is something that I find myself struggling with on and off between projects, where I have moments of excitement starting a project and successfully implementing a function, but often encounter issues that can stifle this passion. Beyond this I simply have times where I lose the drive to work on personal projects and struggle to find the desire to continue working with software design of any sort. Thus for this post post I chose to focus on the Nurture Your Passion pattern.

There are a few key points mentioned to help with this issue. The first mentioned is that you might just have to put any current work you are struggling with aside if possible to focus on another aspect that interests you. This can be in the form of a different part of the system you are currently working on or even just a breakable toy that will help you learn and grow, rather than stifling this advancement. Additionally, you should try to find a community that you can participate in. More often than not there are others in similar situations, and if you look online you can find discussion boards or even whole websites that have a variety of programmers discussing with each other. Getting different perspectives on the craft from others can reveal new insights to you, reigniting your interest in what you do. Furthermore there are even online study groups if you need particular help with specific issues. Beyond this you can also try reading some of the classic, well-regarded books in your free time. This will allow you to learn in a very low risk environment, removing the immediate stress of having to have functional code and allowing you to enjoy the intricacies of whatever is discussed in the book. Finally, if you are in a professional setting, you have to set work environment standards ahead of time. This can mean setting a hard time for when you stop working to ensure any toxic conversations are steered towards a productive topic.

While I am not in a professional setting yet, this information has helped me. I have never really thought about having to set standards for myself going into a job and will keep that in mind for the future. Many of these tips, as always, sound like they will be very helpful in the future and i have nothing to disagree with.

Source: 

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch03s04.html

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Failure

Something that I am sure many others who have pursued a career in computer science have encountered is failure. Throughout my attempts at coding, I have found that a vast majority of my time is spent trying to fix my own failed programs. This was, and can still be, a pretty large barrier to my enjoyment of programming, as simply trying to fix your own broken code over and over give the impression that you are not really making progress. To get a different perspective on this issue I chose to cover the Learn How You Fail pattern for this week.

This pattern gives a few key ideas to keep in mind when you feel like you find yourself stuck in a rut of failure. Firstly you should try not to focus on the disappointment of your failure, but focus on determining what happened that caused this failure. Work back through what you did to get to the point of failure and determine exactly what you did that caused this, then make note of the cause. If you can record these issues you will be able to determine your own strengths and weaknesses. This may lead you to realize that you have to put in a large amount of effort for seemingly small gains, but this will allow you to set accordingly realistic limitations on your goals. Accepting these limitations is also important, as it allows you to determine where you should and should not spend your time, which may require you to drop some projects for now. This will allow you to focus on any other issues you are encountering, and you can always return to the previous issue later.

So far I have found that failure is something that goes hand-in-hand with software design, especially when learning something new. Personally, I have always taken the very straightforward hit your head against the brick wall until it breaks method with failure, often  spending a long time solving small issues. After reading this pattern I have realized I should be recording what I am doing wrong each time, and that would certainly save me some time in the long run. Though I am still early in my career I found this pattern to be useful yet again and had nothing to disagree with.

Source: 

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s09.html

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Breakable Toys

Having covered recording knowledge in the previous week, and specifically considering the conclusion I arrived at, it was only logical to cover the Breakable Toys pattern next. For those who missed that post, I determined that the best method to keep track of previous knowledge was to use a breakable toy that others could access. This would allow one to both record any information, create a potential feedback loop if others can access this information, and finally just get experience by building and maintaining this toy. But this all begs the question, what exactly is a breakable tool?

These toys can come in a variety of forms that can be decided based on your own interests, but each should be a software project that you will complete on your own. This can range from a wiki or a blog to a calendar or even a video game, but there are some important points to keep in mind about the purpose of these toys. Of course these toys will be helpful in your growth as a software developer, but in order to reach a sufficient level of development on these projects you must maintain your motivation. When choosing a breakable tool to create, ensure that it is something that you know you will enjoy developing further down the line. This may sound obvious, but there are many times where I myself have dropped projects after the initial excitement dies down. Furthermore these toys do not have to be complex, especially at the outset of their development. While it might be tempting to have a vast amount of features to implement in this new project, and it may come from a place of genuine wanting to learn how these work, you should keep in mind that this toy can be developed over a long period of time. Focus first on developing the toy in its most basic form and slowly build on it as your development skill progress, allowing for even further growth.

In summary, these breakable tools should be personal projects in any form that interests you and should be something you return to for further development. This pattern has changed my view from what I said in my previous post, as I was initially going to make a wiki or blog. If I am being honest with myself, making a game appeals to me more than many of the other options for tools that I had listed. I have been playing them for a long time and have always had interest in developing one, especially working on an AI system within the game. Once again I had nothing to disagree with, this was a great read! 

Source: 

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s03.html

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Software Testing: The Best Testing Tool

As stated in my previous post, I did a group honors project where each member covered a different software testing tool. The primary reason for this was to determine which tools were useful for what purpose, one of which, being Jacoco, I covered in the previous post as well. But, after having heard each group member’s analysis of their tools it begged the question, which tool is best? To properly discuss this I will be examining the pros and cons to each of the tools my group member’s covered in addition to a brief summary of Jacoco.

First there is PIT, which is a mutation testing tool. I was not familiar with these different types of tests, so I will give a quick explanation of what they are. Mutation testing involves the tool essentially making multiple copies of the code which are then given faults, these being the titular mutations. Tests are then run against each mutant with the result being the mutant’s death, meaning the tests failed, or the mutant surviving, meaning the tests passed. The quality of these tests is then determined by the amount of mutants that could be killed. This method of testing is very robust and covers code coverage as well, but this results in these tests being slower than others. PIT is advantageous as it is the fastest of the mutation tests, and has a lot of support from build tools. The other type of testing covered was Programming Mistake Detector, or PMD for short. This tool focuses on finding more expected flaws, like unused variables, useless objects, empty catch blocks, and other such errors we are all familiar with. In addition to this it can also spot any duplicated code with a copy-paste-detector. This is all handled by rules used to test source code, which are grouped into rule sets. Unlike mutation tests, this is much more lightweight and easy to run from a command line, additionally you can run multiple rulesets at once. However this is a less robust testing method, not accounting for any runtime issues or a way to match a ruleset with its generated error easily when running rulesets on a file. So what is the verdict?

Ultimately, there is only really one type of testing that seems sufficient to be used in and of itself, this being mutation testing with PIT. If you are looking for the most condensed testing tool that can do the most in one package, this would be the answer. However you will want to ensure that using mutation testing is necessary, as if you are only really concerned about code coverage Jacoco would be easier and more efficient. Simultaneously, if you want to check the code itself to ensure there are not many errors and do not care about the coverage, you can implement PMD. The answer will ultimately vary from system to system, and if you want to read more about these tools I have provided some resources below. If you want to read about Jacoco be sure to check my previous post!

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Taking Notes

Yet another post, yet another shockingly related issue addressed by these patterns. The pattern for this week being Record What You Learn, something that is particularly relevant with online learning being the primary method of schooling for most. I have found that, throughout my classes, I have forgotten a significant amount of the minutiae for some of the older projects I have worked on, or even some coding languages I have learned. One way to solve this issue would have been to have a more defined method of documenting what I have learned and worked on, and this pattern has given me some ideas of how to do this.

With a problem as general as this, there are a variety of solutions one can implement. There is the most obvious method of doing this, being to keep a blog about what you learned. The benefits of this are straightforward, as it not only allows you to keep track of any important information, but also allows others to view it. Not only can this help others who are encountering similar problems, it allows others to provide any knowledge they have gained with you. This creates a feedback loop and will undoubtedly aid in remembering this information, as you can also implement changes to any blog posts based on feedback. While this is certainly an effective method, it is not my favorite and keeping a private wiki seems more appealing to me. This, however, has the downside of losing that feedback loop, as it is purely for your own use and maintenance. The option that appealed most to me was to meak a breakable tool that can be used for the record keeping. This allows you to not only record, and potentially share based on the nature of the tool, information learnt but also learn more through the process of utilizing the tool itself.

Everything said in the pattern sounded reasonable to me once again, so nothing to disagree with. If you cannot maintain your knowledge on the subjects you learn, it will slowly decay, so this must be offset. I have realized that, to truly learn this new information, you have to continually engage with it in some manner. Be it through a thoroughly maintained blog or breakable tool, this is the way to retain the learnt knowledge. 

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Software Testing: Jacoco

For this week’s blog post I chose to focus on a topic that I had to research for an honors project, this being Jacoco. In case you are not familiar with it, Jacoco is a software tool that is used to test code coverage, which in short just involves checking how much of a system’s code is being tested. This may sound redundant if you, like myself, have only really been using tests on small scale projects, but as a program’s complexity increases so does the complexity of the tests required. Additionally you will have to write more and more tests, making it difficult to determine exactly what has been covered. Before anything else however, I am going to break down exactly how code coverage is checked.

Having not known about Jacoco at all, I found this article on Baeldung that was extremely useful in understanding how it worked. As I stated the essential idea is to check code coverage, which consists of line and branch coverage. Line coverage essentially means Jacoco will check how many lines of code are being executed during tests to determine which are actually being tested. Branch coverages is similar to this, but focuses on checking the logical splits in the program, such as conditionals like if statements. The total amount of branches present is then compared to the amount that were covered to give the results. There is one more aspect of a program Jacoco checks for, being cyclomatic complexity. This is essentially a measure of the logical complexity of the program, or how many branches the program has. Now that we know what Jacoco is we can discuss why you might want to use it.

This testing tool certainly has some major benefits for anyone working on a large system. If you are working on writing tests for a system, it may begin as something straightforward, but as the system grows it will become increasingly hard to track exactly what components are being tested. This is where Jacoco comes in, allowing you to see exactly what lines, or just classes, are being tested so you can ensure there is sufficient test coverage. Additionally it can show you the degree of logical complexity present in the system, which could then be adjusted accordingly. One point to keep in mind that is mention in this article is that you should not get tunnel vision when trying to increase code coverage. High code coverage does not necessarily mean the tests being run are adequately testing the system. It is more important to focus on writing a few functional tests for each component rather than just having a plethora of tests that do not really do much of value. This article discusses Jacoco in more detail than I can so if this interests you I would recommend checking it out!

Source:

https://www.baeldung.com/jacoco

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Learning Languages

I am once again impressed with the relevance of these patterns, covering many issues that I have been struggling with recently. For this week I chose to focus on the Your First Language pattern. This might sound strange, as I am a senior and at the end of a pretty significant part of my journey as a software engineer, and yet I feel as though I have yet to become an expert on any particular aspect of programming. In terms of programming languages, I have found myself vaguely utilizing many without fully understanding how they work. This is exactly the issue discussed in the pattern.

This pattern focuses on a few different tips for learning a new language well. After choosing a language to focus on this pattern advises you to focus on creating a useful feedback loop with whatever type of work you are doing. This can be through a variety of methods, being finding existing communities of practice online or someone you know who is an expert themselves. As for how to learn the language, there are a few different methods recommended. The overarching method is to have a specific problem to solve rather than just solving small examples present online and in books. I have often ran into this exact situation myself, finding my initial excitement in learning a new language stopped abruptly by some frustrating example problem that has little relevance to what I want to do with the language. Instead, what is recommended is to think of a larger problem you would like to solve with a program. Starting from this very general level try to break it down into smaller components and, after getting to the most basic component to work on, start from there.

Personally I once again had little to disagree with. I have realized that learning new languages seems to be a critical skill for software developers, as there is such a variety available. Each language generally has its own advantages and disadvantages, with some having specific use cases, like html for web design. Thus it is important to know how to go about successfully learning a new one,  as it is its own little road on your greater path to becoming a software developer.

Source:

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02.html#your_first_language

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

It probably goes without saying, but this sprint certainly seemed more effective than the first. This is essentially a given, as a good portion of the first sprint consisted of figuring out how to work within my team in addition to adjusting to the teams shifting around a bit. After this, I feel as though we were able to accomplish everything we set out to, and a little more in some circumstances. Though this sprint certainly was not entirely bereft of some issues, at least with my own contributions to the team. Other than these though, I am satisfied with how this sprint went.

After adjusting to being embedded into the InventorySystem team, the sprint went very smoothly. Initially I had some difficulties being in a community of practice and the team, not really knowing if I should be meeting with others from my COP. We ended up establishing some meeting times and help each other with some parts of Keycloak. We were able to find a method of connecting our mock frontend app to keycloak, in addition to developing a logout function. Additionally, both Keycloak and the mock frontend app were containerized in docker. These were the major issues that I had focused on this sprint and all were effectively completed. Beyond myself, the InventorySystem seemed to accomplish many of the issues, with the exception of maybe one or two, that were posted for this sprint. One part that I felt did not go entirely well was how exactly I could help out the InventorySystem team. It might have just been the nature of the issues I had involving just using Keycloak, but I was concerned that I could have been helping them more in some way. Other than this there were no real issues that I could think of.

Despite the overall success of this sprint, there are a few more thing that I personally feel could change to improve the next sprint. I should clarify that these changes are entirely with myself, the first of which being what I felt was my own lack of participation in the InventoryTeam’s issues. I did not feel like I involved myself enough, this is also the reason why I cannot really speak on how the team can improve. As for changes I can make, I will simply try to involve myself a bit more, if not through taking up some of their issues then just through communicating more. I will try and ask where they are at throughout the sprint so I am more aware of what is happening and, ultimately, when I will be implementing Keycloak into the system. Additionally, I still had some struggles balancing my work for this class with some others, but I have been working on improving this for the next sprint. I have been sticking to the time I have set aside for working on schoolwork and have, at least, kept up. In conclusion, I am very pleased with my current progress going into sprint 3 and am excited to finally finish implementing Keycloak into a system!

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.