Author Archives: Michael St. Germain

Last sprint but new beginnings

For my team’s sprint 3, there was not much more functionality we wanted to implement. On one hand we had the front end and back end working exactly how we wanted it to, for the full purpose of a demonstration. On the other hand, we knew that we would have to back track. The backend needed to be refactoring to fully represent an inventory backend instead of the guest info backend we had forced into working for us. This proved to be much more work than expected, more on that later. We also had a few different looks in regards to the actual display our front had. Slightly changing colors, logos, their sizes. All of the things you would expect when it comes to user interfaces and experience. While my own work focused mainly on the back end it was a good experience and very eye opening to work with the team members who were tweaking things and making different versions we were choosing from. It was fun to see what the tedious and seemingly bland work I was doing on the backend actually visualized and became something that felt actually usable.

For my own work on the backend, I was trying extremely hard to work with a teammate to go through Renaming and refactoring everything. At this point we had taken a backend that was being used to store guest information. Names, ID’s, and other identifying or important information. Them converted it to instead take the place of an inventory system that had not existed. This meant that the collections being used, the end points, the oaths, a lot of the comments, all of the documentation and all of the included tests. Would all need to be rewritten. What seemed easy on the surface quickly spiraled. Looking back it probably would of been better to dive into this issue before expanding on the whole project. By this time we had already connected the front end to it and a fetch script that worked as a middle man. After weeks of trying over and over to make this conversion. It became clear that it would have to become a project for whoever comes after us to work on. Although the opportunity is still available if I decide to take another shot at it, solo and on my own time. 

In order to at least make some progress I had moved forward with rewriting all the tests. I am extremely grateful for having learned Mocha and Chai testing from an old classmate a full year ago. He was also, is surprising serendipity, the person who had worked on the original tests for the guest info backend. Once I realized this I reached out to him just to check in and he was able to give me a couple resources and remind me of an assignment we had done together that proved to be a massive help.

This helping hand from a friend I had made really brought me back to the section finding mentors of the apprenticeship patterns. Having a network with friends who have understanding and experience in areas where you’re lacking can be such an amazing resource to utilize. Surrounding yourself with smart people, even if they’re not directly involved in what you’re working on can be a saving grace.

In the end, not as many features and additions were made in comparison to the first two sprints. Sprint 3 was a fun challenging experience that helped me reconnect with an old friend and rediscover how much I love testing software. 

With the original goals of all of the variable name changes, comment changing, documentation updates and rewritten tests. We were at least able to complete the documentation and testing. I even got the pipeline to finally pass with all of the tests and spelling checks.

I’m proud of what this team accomplished and the state of the project they were leaving behind for future teams to further develop. 

If I don’t get to it first >:) it is open source after all

From the blog CS@Worcester – Mike St G – 448 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospect

In sprint 2 my team and I actually got the project functioning as we had intended. We now have a webpage with a scanner that can read UPC codes off any product we can find. A fetch script that takes that UPC code and uses an FDA API to give us data on the product. This data includes brand, brand owner, product category and a description. This data is then merged into our back end and stored with a quantity that gets manually entered. 

While demoing the webpage our customer seemed very interested in it and how user friendly we had made it. They seemed concerned about having to scan every individual product until they saw that you only needed to edit the quantities after scanning one single time. There is only one issue we have in that regard. We are not able to find absolutely any products data in that FDA API. However we are in the process of creating manual entries that will be saved, so it will only be a problem the first time that item is scanned. Attempting to keep our theme of user friendliness.

It has been cool and very rewarding for the team to actually see our project function this way. We’ve all done projects where things don’t really get to the point of looking and functioning like a completed product. This is a first for a few of us.

Our communication with each other during the weeks has stayed pretty consistent throughout this entire semester. I would say that is the strongest characteristic of this team. We all hold each other accountable by just being visible and seeing the others working hard to get this done.

Relating our team with a chapter from the book apprenticeship patterns, a good one would be – be the worst. With our strong communication and the fact we are putting the different parts of our project together into one product. We all noticed the strengths each member has to offer. All though this does not perfectly match the example of the book by surrounding yourself with a full team that is better than you. I think we have all done a good job at noticing each other’s strengths and understanding of each portion. This sprint showed how much we really started to learn and grow as a team. 

After sprint one I wanted to make it clearer for everyone to understand what each part of the team was doing and where they were at. This sprint actually managed to do a lot of this for me. While putting the pieces together everyone really started to see the full picture and there was points when you could see the excitement across everyone’s face when things started to shape up and start working. This also proved to create a more cohesive team as the pairs that had been working in a more broken off system were having to explain what they did in order to get certain parts to function properly. Now that everyone’s working in the same directories we all witness the fast pace of progress we have had the whole time, that I believe I was the only one really witnessing.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend

-this is the current state of our project. It has a working webpage, back end and fetch script that works between them.

Start up:

  • start the backend using bin/rebuild.sh
  • Install the live server extension on vscode
  • Right click scanner.html and open with webpage
  • Start scanning items =]

From the blog CS@Worcester – Mike St G – 448 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

still thinking of a witty title

To start, this was my first real team project where I felt like all of the team members were highly capable of putting something of value together. It’s been a great experience to learn and collaborate with such a good group.

We started this project basically from scratch, learning just how difficult that actually is. Over time we worked out our goals and expectations along the way. Through some facet of peer pressure and blind faith I got elected to lead the team, though each member has done something to guide all of us in one way or another. 

This leads to the topic of what worked well with our team. First, we all tried to get to know each other a little better. Aside from having the same major and concentration, a friendly connection has absolutely benefited us when it comes to communicating and holding each other accountable. It also fostered an environment of being able to ask questions and for help when it was needed. It quickly became a good time coming to class and being on time just to see each other and show our work in person. Due to instinct or pure luck, the best move we made was breaking our group up into pairs, otherwise known as pair programming. This allowed us to have 2 people focusing on each aspect of our project making progress in all areas simultaneously. 

For myself, one part I would like us to improve is being more on top of explaining the finer details of what each pair is working on. Being the leader I am seeing the big picture of the project but I do feel at times the others get a little lost in their own portions. During the sprint reviews I think we did a good job showing each other what that meant, but we could certainly get better when it comes to the day to day aspect.

All of this culminates into one of the things that really stuck out to me in the second chapter of the book Apprenticeship Patterns referenced in a previous blog. This chapter was about “emptying the cup”. This phrase is an amazing metaphor for not allowing yourself to think you know too much to be able to learn from others. Too often have I myself fallen victim to my own thinking of already understanding all there is to know about a given subject. Sometimes it’s really beneficial to go into something with a fresh and open mind.

For example, while developing the inventory back-end there were at least 5 times where I had to start completely over. While this sounds like it would be extremely frustrating I was noticing that every time this happened, I was learning something new along the way. After having worked with the guest info back-end I thought I was going to breeze through replicating it. It wasn’t until doing it over and over that I realized just how much I was missing under the surface.

Nearing the deadline I was actually becoming a little worried that it wasn’t going to work out in time. We would have to move it into the next sprint. However due to having so much practice and my partners assistance making a mock version of what i was creating. We were able to very quickly and easily put together a working prototype of the true vision we had. This prototype is also proving to be fundamental to how we continue into the next sprint.

In the end my team came together and had 3 portions of this project ready to demo for the customer and our professor. It all worked exactly how we planned and it was so refreshing to witness. We all did a great job and should feel proud for how far we managed to come in just one month working on this and knowing each other.

Here are all 3 portions

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/guestinfobackend/-/tree/main/src?ref_type=heads

  • This is a 2 for one. 
  • The mock database itself was created by me and my pair partner Prince.
  • The script to fetch data from an API we are utilizing was done by our teammate Anairdo

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend

  • This directory is the front end our other teammates have been working on to pair up with our backend. Credit to Adam and Donna

From the blog CS@Worcester – Mike St G – 448 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

Learn How to Learn

Throughout my time in the turbulent process of learning in the major of computer science there have been quite a few things that have hit me later on in the process as something I wished I had learned or read in the very beginning. The latest occurrence of this has happened with the book apprenticeship patterns. 

To start the book had a list of community values, all of which really spoke to me. Things like having a growth mindset, understanding that you can always get better and things can always improve. Believing in sharing what we know is better than trying to hoard it. The thoughts that no one tool is going to work or be perfect for everyone and a focus on individuals instead of groups.

There were quite a few more values, however those are the ones that especially resonated with me. In the beginning it took me about 3 different languages and many many hours before things started to click. Finding peers who were more experienced proved both intimidating and helpful. In this major there can tend to be a sense of elitism and as you would expect with humans, some are more helpful while others might look at you as below them. Breaking down those feelings has always come to be the first hurdle I try to get myself and anyone I’m working with over. It also ties into the sharing of what we know and there is no one perfect tool values. This also ties in the aspect of focusing on the individuals instead of an entire group. Being able to communicate and disagree and find common grounds or understandings is so important to the learning process.

Lastly, when I first started learning I was always hyper fixated on trying to understand the “best” way of doing something. It wasn’t until years later I learned that is a silly thought process to have. Sometimes it’s better to just make something work and then revisit it to try and make it better. It is all part of the process, you can get better, everything can always get better too.

Littered throughout the book are fantastic quotes to further motivation and would have given me so much more peace when recognizing my inabilities early on. Failing is an important part in learning something. My favorite excerpt from the book was a story about a master and a philosopher. While the master was trying to teach the philosopher, he kept being interrupted because the philosopher was assuming he already knew about the subject. Leaving the master with nothing to really teach. I can remember so many times where I thought I knew something and began to brush off the information I was being taught. Only to later learn how useful it would have been had I taken more time to open my mind and absorb it all, even a second or fiftieth time.

source:
https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/#toc-start

From the blog CS@Worcester – Mike St G – 448 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

plantuml and markdown – tools learned too late

Every computer science student has taken a course that requires them to make charts, diagrams, graphs and other visual tools. One of the biggest tools I wish I knew about early on is plantuml in markdown files.

Unified modeling language, the UML portion of plantuml is as a visual modeling language. To be more specific, plantuml is just a good open-source tool that incorporates uml and other things like support for visualization of JSON and YAML files.

Markdown (a .md file) is a language that lets you format text and symbols. 

The combination of these languages would have made many of the courses in my past much easier. I could also see it being useful in the future when it comes to modeling any work. VScode only requires a couple extensions to get it to work .

There are a few different sources one could go to, to figure out how to write the code that they need for whatever task is at hand. Those resources will be listed at the end.

For now there will be a couple basic examples showing how the diagrams from the previous blogs are made.

This is the diagram from the previous blog:

For this breakdown we will be keeping it simpler and using a smaller portion of this diagram.

The diagram we will be looking at:

Oh how nice it would have been if I could use this to organize group projects early on in my academic career. 

the code to make it present this way looks like this:

With the plantuml extensions you simply put 3 back quotes (“`) and plantuml. Then go to town following whatever cheat sheet you like to use to help you write the code. You can show relations, display classes and even put notes for more details.

This example keeps it fairly simple, it can get a little more complex depending on the size of your diagram and what you are doing. 

Like was mentioned earlier you can even make diagrams for relational databases!

ex.)

The amount of time me and my friendsin class had spent using different cookie cutter diagram makers in our browser that would hide features we needed behind paywalls…

Even if you’re just making a list of tasks you need to do or formatting a paper markdown by itself has a lot of useful tools. One of my personal favorites is crossing off a list using the tilde key (~).

ex.)

Markdown and plantuml are on the same list as unit testing when it comes to things I wish were taught before getting deep into programming courses. 

Do yourself a big favor and get at least a little familiar with it.

Cheat sheets:

Plantuml simple – https://ogom.github.io/draw_uml/plantuml/

Plantuml official – https://pdf.plantuml.net/PlantUML_Language_Reference_Guide_en.pdf

Markdown simple – https://github.com/adam-p/markdown-here/wiki/markdown-cheatsheet

Markdown official – https://www.markdownguide.org/cheat-sheet/

Sources: 

Database example – https://medium.com/@elvis.gosselin/plantuml-for-database-modeling-1b71e6d4622d

From the blog Mikes CS 343 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

Sequence diagram dissection

Along with class diagrams is the topic of a sequence diagram (mentioned in previous blogs). Sequence diagrams are a good way to understand the flow of a program that helps developers when it comes to creating and testing their products.

This blog will go into detail of how to read a sequence diagram and show why they are important.

To start here is the example given from a class activity and the previous blog:

As an overview this is the sequence diagram for a program that creates a student and a day. Courses and appointments are assigned to a student, working as a mock schedule creator. The student has a name, phone number and an email address. Days are a collection of courses and events. The courses have a start time, end time, course code and room number. The appointments have a start time, end time and description. Displaying the day shows all of the assigned courses and events.

With the overview we can look into how all of that information is extracted using just the sequence diagram. Ideally you would want a class diagram as well in order to write the program initially but the sequence diagram also helps explain the flow and give an idea of what should be tested.

Starting from the top we have a user, that being the driver class that someone is using to run the program. We begin with creating 2 days and two courses. The courses variables are listed above the line leading to the order of their creation. Next a student is created. This student is named sam and the associated variables are listed in a similar manner. An appointment is created in a similar manner as the courses.

All of the created courses and events are then added to the list of events. A new course is created and added to the events. Then comes the “testing” portion. By displaying the days you should get outputs that show all of the events. After removing the created appointment and displaying the day again you should see it has been removed.

All of this shows the actual behavior a program should have. Along with giving samples of inputs that can be used to test that the program is working as intended.

Below is the code written to match the sequence diagram:

As one can most likely see. The code itself follows the diagram almost perfectly. The main differences are just the syntax and the way certain aspects are implemented. It’s important to check over the class diagram and code itself to know how to properly implement the sequence diagram.

The power of a sequence diagram is that it gives a developer a basic example of a program’s expected behaviors. For actual proper testing you would want to implement more things that wont be discussed here. However it is a strong stepping stone leading towards that.

From the blog Mikes CS 343 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

GIT(ting) My Friend A Promotion

For teams of developers having a centralized repository for code is essential. Git provides an extremely powerful and relatively user-friendly base for teams to collaborate effectively.

After teaching one of my close friends, involved in a development project at work, the basics of class diagrams. They gave her a more hands-on role with the entire development process. Even though she had never worked with programming before, having someone in a business oriented role who could communicate and check over the team of developers was perfect for them.

That’s when she was selected as the product owner for her company’s new website. In a serendipitous twist they were using git as their repository while I simultaneously was being taught about it in school.

The next step was to teach her a basic overview of how it all looks from a developers perspective.

We started with a picture from my professor.

At first glance, I had completely lost her. After explaining that she wasn’t the maintainer responsible for handling all of this her mind was eased a little. The main ideas were just to understand the flow of how the developers were going to be working. All she had to remember was FCBPP.

This acronym I created for her was simple. They would FORK their own copies. Make CLONES of that. Make a BRANCH where they would do their work. PUSH that work kind of like a save. Then create a PULL request. As a developer it is obviously a lot more nuanced and there are more steps involved. But for someone that isn’t actually doing hands on work that was enough.

After getting the gist of it and before getting further into the details of how it would benefit her to know that stuff. We took a look at the stuff she would really be involved with. The product and sprint backlogs.

In git it is actually fairly easy for someone who doesn’t really understand programming itself to look at, arrange and audit backlog items. It would also allow her to check in regularly to see where the team was when her boss would ask questions.

In the real life case while explaining this part we did use the real github of her company but for the sake of confidentiality it will be a new blank project.

I told her to focus on the issue board under planning. It looked similar to this:

With properly labeled boxes and the lists of items and features the team was working on or planned to work on she felt so much more comfortable asking about things and helping plan everything out. After circling around the topic a few more times we realized just how powerful having a product owner who knows this process could be

We also joked with her boss that with me teaching her these things I should be hired as a consultant (small business unfortunately) with a bonus for my professor.

From the blog Mikes CS 348 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

Whats that smell

Writing good clean code is a work of art that takes a lot of practice and understanding. One of the first practices you should use is what’s called design smells. Design smells are indicators of possible poor design principles that will eventually impact the quality of your project.

We’ve all had that point when we first started learning how to write code where we wrote some pretty ugly “spaghetti”  code. To start, the names of these smells are rigidity, fragility, immobility, viscosity, needless complexity, needless repetition and opacity. Most of these tend to go hand in hand or could stand alone. 

It’s good to know their meanings before talking about their importance.

Rigidity: when your software is difficult to change in even the simplest ways. 

Fragility: having a tendency for your program to break in other places when you make a change.

Immobility: having useful code that could be used in other systems, but can’t be integrated very easily

Viscosity: when it’s not easy to make only one change.

Needless complexity: containing things that don’t really have any use yet.

Needless repetition: repeated code that could be abstracted instead or written over and over.

Opacity: not visually clear.

While the use of being able to identify these design smells may be obvious to some. We will start with some examples before ending with why identifying these smells will be helpful in the long run.

When first starting a project sometimes it’s hard to know where to really start. That is why developers have tools such as class diagrams, but that is for another blog. Starting off with no real design in mind it’s easy to have needless repetition pop up. Once you’ve identified you can break certain things off and turn them into their own methods, you may also realize it has caused rigidity and fragility. Moving those lines might be much harder than you think. Those problems also lead into viscosity if you end up with a big enough mess (speaking from experience).

Next is the problem of needless complexity. Without having a class diagram you might find yourself jumping ahead to try and fix a problem or do something you don’t have a need for yet. The problem is exacerbated if you don’t end up needing it at all. No one likes useless code. This can lead to opacity when your code is making the goals and intents of your work unclear.

With the previously discussed class diagrams (see previous blog) to guide you. Along with an understanding of poor design principles it’s easy to see how being able to identify these smells can keep your work in much better shape for yourself and others. We have stuck with the design process for now, a future blog topic will cover how to make the code itself “cleaner”.

From the blog Mikes CS 343 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

Is weak copyleft the strongest? (part 2)

In part 1 we covered the different types of software licensing and how they work. Now we will be looking at why you should pick a license, how you should pick a license and which license you should pick from the plethora of options.

We will start with why you should license your software. In reality there are many reasons why you would want to put a copyright and license on your software. It is something that you created after all. It is your intellectual property and hard work. You wouldn’t want someone to steal it and use it for their own gain with no credits or regards to you. You also wouldn’t want to be found liable if someone uses what you wrote and it causes something bad to happen whether it be system breaking or cause a security breach.

As for how you license your software. There is a massive amount of licenses to choose from and you don’t need to make one from scratch. In fact it is very much recommended to use one of the many that have already been created and are easy enough to add on to what you’re working on. Leave it to the legal professionals and save yourself the time and effort.

Which license is best for you depends on your own beliefs and what you would want others to be able to do with your work. As stated in part one a closed-source project is likely something you’re doing in a commercial setting so unless you’re the business owner it won’t be your decision.

If you’re starting your own project and aiming for it to be open source and don’t care too much if its modified and has the license changed or is incorporated into an existing project under a closed-source project a permissive license will be fine. You’re still the owner and your own code is still open source. An MIT license would work for you

If you’re like me and don’t want your work to be used in a setting you don’t have insight to or the ability to decide which license is used, you may look to copyleft. A GNU General Public License would be good in this case.  

There is somewhat of a middle ground however.

Mozilla is a special case and has their own license called Mozilla Public License (MPL). It is considered a weaker copy left since it does allow developers to use their software inside of a project with a different license . Though  still requiring the portions used under their license remain under their license and be open source instead of the whole project. In my opinion, it seems to be a great blend for the future of FOSS and would be my choice.

From the blog Mikes CS 348 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

Is weak copyleft the strongest? (part 1)

Software licensing has quickly become one of my favorite topics to research. When I was first introduced to the topic I sarcastically thought and said “yay” imagining the legal nonsense that i thought was coming. My professor told me he actually found it very interesting and it shouldn’t really shock me that he was right.

There are different categories for the different kinds of licenses that serve different purposes. 

You have the closed-source license which everyone is familiar with. This would include things like operating systems, Microsoft windows or Apples ios. Unless you’re a maniac using Linux on your personal computer. It also extends to a lot of smaller more commercial products like zoom, adobe products and a good amount of video games.

On the other hand you have open-source software that is steadily becoming more and more popular. You have my preferred web browser (Mozilla Firefox), the previously mentioned Linux and WordPress (where this blog is being written).

While closed-source software has a very strong and sometimes important foothold in the world we live in. There are many developers who strongly believe in the continued growth of free open source software (FOSS). For personal reasons my independent research and guided learning have pushed me towards those beliefs as well.

Inside of open-source software there are different types of licensing which can be categorized as copyleft and permissive. Both of them are great if you believe in FOSS but they do have some interesting aspects that make them different.

To start, a permissive license does exactly what you would imagine for open source software. It lets users use, modify and distribute it with minor restrictions. An example of this would be an MIT license which is used by jQuery and node, which are libraries and runtime environments for JavaScript. The minor restrictions of an MIT license are fairly basic. There’s no warranties, no liability, you must retain the copyright notices and accept liability for any issues caused by using the software.

In contrast, a copyleft (or restrictive) license has all of these restrictions but it gets to be interesting when you also restrict changing the licenses down the road. Basically with a copyleft license it forces anyone who uses, modifies and distributes the software to use the same license. This removes the ability of a user to lock up and sell their version of the software. The one drawback is you cannot use a copyleft licensed work inside of a project that uses a different license. An example of copyleft licensed software is the Mozilla Firefox web browser.

you may be thinking how do i pick a license? which license is best? which license is for me?

These questions will be answered as we explore more in part 2!

From the blog Mikes CS 348 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.