Author Archives: Michael St. Germain

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.

What is scrum

A development team is a unique environment that requires a unique framework for the developers to follow. In other industries such as construction, you need all of the workers to focus on one goal at a time. You wouldn’t want a team working on the stairs to an attic while another team is still working on the foundation. When constructing a bridge you would have a really tough time working on the middle without having the ends already built. While both software and construction have the goals of building or creating something, its clear they would utilize different frameworks.

That is where development teams have come up with the idea of having a scrum.

A scrum is a way for a team to break down a larger project into manageable goals that can be met within time frames called sprints. The main benefits are increased collaboration, flexibility and the ability to adapt leading to better quality, usable software in shorter time frames. These shorter time frames make it better for users by giving them products they can actually use at a more consistent pace.

There are 3 key roles in a scrum team, the developers, the scrum master and the product owner. The roles each have their own tasks in order to make the system flow.

The roles and tasks are:

Product owner:
-creating and communicating the goals

-creating and ordering backlog items

-making sure the backlog is accessible and understandable

Scrum master:

-serving, coaching and helping the product owner and the development team

-leading training and planning for both the product owner and development team

-removing barriers between stakeholders and the developers
-making sure that all the scrum events are taking place

Developers:

-planning of the sprint

-having a universally understood definition for the word done within the team

-holding each other accountable and staying flexible when needing to adapt

A sprint is where all of the members of a scrum team come together to create a product. A sprint has different stages called events. Each event has an important role for the team to consistently create products, understand their products, and continue to improve as a team. 

The sprint events and their uses are:

The sprint:

-the development process as a whole, containing the other events

-fixed lengths usually a month or less

Sprint planning:

-planning is done by the entire scrum team

-product owner creates and orders the backlog

-scrum master assists in the backlog and help communicate it to the dev team

-the dev team plans out which items of the backlog will be the focus of the sprint

-the main aspects are the sprint goal, backlog, and plan to deliver

Daily scrum:

-a short daily meeting among the development team

-check progress towards the sprint goal and adapt as needed

Sprint review:

-all members of the scrum team review the outcome of the sprint

-all members talk about what went well, what went wrong and how they solved what went wrong

Sprint retrospective:

-the scrum team goes over how they can be more effective in any future sprints

-review any impactful changes that have occurred with previous sprint retrospectives

-work to refine their abilities as a scrum team

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

Class Diagram Dissection (for dummies)

One day I had a friend start asking me questions about a project they were starting to work on with one of their new coworkers. This friend was working at a company in more of a business operations management role. However, they were tasked with working with a software developer to come up with a new design for a website the company wanted to create. Through reading some of their emails and conversations – with permission. I noticed there was some disconnect in the way they were organizing and talking about certain things. It was at this point I figured it would be best to teach my friend some of the basics of how the design process works on her coworkers end.

There are two types of diagrams a software developer should have a comfortable understanding of. It is also very beneficial for anyone who is working with a development team to understand the basics of them to aid in how they communicate their project needs and goals. These diagrams are called class diagrams and sequence diagrams.

*class diagram*

*sequence diagram*

Before diving in it was important for me to point out that this was not going to cover the small detail of these diagrams. The main goal was the basics, giving them the ability to double check that what they were asking for was included and helping them communicate effectively.

We started with focusing on a basic class diagram from a course I had conveniently started shortly before this.

Before this example my friend had never actually seen a class diagram before. Simply looking at it was enough to get the gears in their head turning and have them realize learning about this would give them a helpful tool.

First we talked about how classes (the individual boxes) were broken up. In this example we had 7 of them. At the top is a university member, a university member could either be a student or an employee. At the bottom is the courses, each course should have students and an employee. There were more in betweens that used an interface to work with some of the finer details. For their sake it made sense and was easy enough to see how things were being broken up into more manageable pieces.

The next part we covered was what was inside each box. Using university members we looked at each portion. At the top is the class name, university member. Below that is a list of variables and their assigned data types. Below that is a list of methods. The variables are pretty simple, first name, last name, ID number. The data types were a little confusing because they had never heard of the terms but I assured them it wouldn’t negatively affect them. The developers themselves have more needs for that. The last part was explaining the functions. Those should really show what the program does with the variables. In university member they are just “getter” methods to be able to access the values. There aren’t any setter methods which I briefly explained would be used to add or change data values for the variables.

The last part we went over was the arrows. I found and used a picture that includes each type of arrow and their names.

After this brief walk-through of a class diagram my friend went back to work the next week with more confidence and some background knowledge that her boss noticed and her coworker highly appreciated.

Sources:

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