Monthly Archives: May 2021

Sprint 3 Retrospective

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

Implementing the frontend for guest registration was the overarching goal of mine during the sprint; this encompassed all of the smaller individual parts.

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

This was fulfilling the specifications for the guest registration page, including collecting a new guest’s information and displaying/changing an already registered guest’s information.

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

This was in order to allow ID input from a card scanner swipe (within a text entry of the frontend page)

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

This was collecting a guest ID for lookup; employed the getGuest method, which made a backend request for a guest with the specific ID.

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

This was connecting frontend to backend methods, which was completed with the use of Axios.

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

This was creating the HTML structuring for the guest info page.

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

This was applying CSS styling for the guest info page; not much was completed here except for button styling and putting individual borders around each entry for the age of a member of the household.

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

This was changing the backend getGuest method in order to return an empty object in the case of no guest found instead of a 404 status. Also, not totally included in this but involved is the refactoring of the guest object in the backend openapi.yaml file to match what was best for frontend functionality.

Overall, I feel I was able to get a substantial amount of work done during this sprint. Actually, I felt this was the most I got done in any sprint. I think part of this was feeling totally settled into the sprint cycle but also because I was undertaking something I had never done before in building the frontend for the system, which was a very large part of the system and had a limited number of examples to work off of (at least, examples that were applicable). Not only was I having to learn on the fly, but I also had to then apply this knowledge to HTML and CSS (totally new to me, only having lightly dabbled in HTML) and JS (very limited experience as well). Getting through this was difficult, and I definitely should have asked for more help earlier on.

This was actually my main downfall during the sprint; I was trying to figure things out on my own for so long that later on, when help was needed the most, I felt there was not a good way to delineate the work, especially because it would take a great deal of time to explain the functionality of everything up to that point. More communication was definitely necessary. I felt during this sprint, our team was the most divided amongst their own work, with limited crossover, so communication suffered and sometimes it seemed work might be stagnating.

As a team, I still think we worked well. Although there were rough patches and points where I wasn’t sure how we would get to our respective endpoints, I think we did fairly well. Had we teamed up on more work, I think we could have gotten through cards/tasks faster. I also think there could have been a better division of labor. I felt the frontend was too large a task for me to be completing on my own, but there were other circumstances. I was the one who studied Vue.js, so I don’t know how much knowledge others had. Also, I should have been more vocal in asking for help once I realized the size of the task I was taking on. Better communication on a more consistent basis would have solved this, I believe.

Personally, I was happy with the work I completed. I went from feeling lost on most parts of the frontend to having some solid understanding of each part. This was good for my sake, but not optimal for delivering working products, since dividing responsibility might have limited the amount of hands-on work I had but would have brought results faster. Working mostly alone was not something we did much in past sprints, so I should have spoken up more in order to help coordinate our work.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Sprint #3 Retrospective Blog Post

For the third and final sprint of our project for this semester, we had the biggest list of tasks to complete. Not only did we have a tremendous amount of tasks, but almost all of them where big and difficult tasks. In our previous sprints, we had a lot of tasks that were smaller or that related to learning rather than creating. This made this sprint much more difficult for everyone. Some cards that I had to complete by myself were not too bad. One of them was simply to update the frontend example that I produced in sprint 2. We changed some things on it in order to have a smoother experience for the user when they are a returning customer. The questions that could be skipped if a returner logs in now will be autofilled in (with the availability to change their previous answers). Many other tasks I worked on were much bigger and were not solo tasks. Before the end of the sprint, I was able to help with tasks such as implementing the GuestInfoDB. It was extremely important for us to get as much of our tasks done as possible before the end of this semester so that future students could used what we have worked on to improve or even finish it all next year. We tried to write as much as we could in the cards themselves on GitLab in order to help anyone realize what we were trying to accomplish. Even if we failed to finish some cards, starting them and writing what our thoughts where will help future students when they get to the steps that we got to. We were able to utilize work from previous students this semester in the same way. By the end we were able to get a basic frontend working to an extent that ended up not being too bad in my opinion. Even the cards that we did not end up completing should be very helpful for future people working on this project, whether it be Capstone students or WSU employees. Before moving on from this project, we were instructed to add our thoughts and ideas to cards that we had not yet completed for that exact purpose, and from what I have seen from my group, that should be pretty useful in the future. It was nice being able to work on a real life example for this class, and it is something I actually wish I had done more often throughout my undergrad. Everything this semester, especially for this course, definitely helped improve my understanding of how projects would be worked on in the real world, and I am thankful for being able to learn in that way!

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch 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.

Dig Deeper: Depth not Breadth

Photo by Laura Stanley on Pexels.com

Learning things is difficult much of the time, and when being pressured to learn something (or even multiple things at a time) for some impending deadline or project responsibility, it can feel like there just isn’t enough time to warrant building a truly deep understanding during that period. The more items on the todo-list, the less time then is able to be spent on each item, leaving a very shallow understanding which is simply good enough to satisfy the given problem or context exactly.

The idea of learning in a shallow sense versus learning deeply is discussed in chapter 6 of Apprenticeship Patterns. Dig Deeper refers to the idea of making an effort to learn about tools, languages, or other areas of study to more than just the necessary degree to complete the current project. The authors argue that to always remain focused on finding a solution, rather than learning about why that solution works can make the overall understanding of the subject relatively shallow. Focusing solely on “your part” of the project can leave you lacking in comprehension regarding everything else, and so it is beneficial to look into relevant context, supporting ideas which build the foundations of the solution to the problem, and the documentation associated with the solution. The idea is to focus on depth of understanding, rather than breadth of topics covered.

In practice this seems difficult to implement one-hundred percent of the time, as time constraints will likely impede any efforts to understand everything in a way which is absolutely comprehensive. But for important ideas, subjects which will likely form integral, foundational aspects of a program or project, it makes sense to learn as much as possible about them so that if something goes wrong, you will have the knowledge to fix it. Choosing which topics to use this sort of approach for is a judgement call which should most likely rely heavily on context (as with most of the patterns discussed in this book).

While I wouldn’t necessarily want to use this approach all the time, I can definitely see the benefit of learning about the context and deeper ideas associated with topics such as new programming languages, database management, or frameworks like the .NET framework, which is associated with Windows-based development. Topics which are especially interesting in this regard (in my opinion) are game development and GUI frameworks, where there are often a large array of interconnecting components, panels, windows and tools associated. Learning the tools becomes almost like learning another language within the language itself.

Book referenced:

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch06s04.html

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Stay in the Trenches

The problem in this pattern is an extremely simple one; you are a programmer at a company and you are offered a promotion that will take you away from programming. The provided solution is basically to just stay in programming despite the opportunity.

I would say I mostly agree with this pattern. This reminds me of Star Trek Beyond (2016) where spoilers, Kirk is offered a promotion to, what I believe is, Admiral which would mean he would no longer fly. After a long adventure, both him and Spock realize that where they belong is on the Enterprise together with the crew. So Kirk turns down the promotion. I think this situation – in a very decent film that most people seem to overlook – is a great match for this design pattern. The motivations are only partly the same, however. In the film, Kirk chooses the Enterprise because he is driven to explore. This design pattern, however, cares primarily about your future career and skills.

There is obviously an implication that the software craftsman enjoys programming, but the main reason they give for turning down the promotion seems to be that you need as much software experience as possible. If your career goal is to be in software, then being in a higher level position at some company you’ll probably leave in a few years doesn’t help you as much as being in programming. There are also potentially alternatives to a promotion that still accrue you the benefits you’ve earned.

Overall, I would say I’m in agreement with this pattern. You need to focus on your long term goals. In this scenario, that is most likely to become a good programmer. That said, its up to you to gauge the opportunity in front of you and determine whether or not it matches your goals. Perhaps the company you are at is a solid position with little fear of losing the job. Then, maybe you should take the promotion and simply keep climbing up. Its okay to change your plan in the face of new opportunities. The key is that you’re thinking rationally and properly about the situation at hand. After all, its your future.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Craft over Art

The problem of this pattern is a very common situation; virtually any time you are building something for a client. You are tasked with producing something that will solve the client’s problem. While you could follow a basic, common method, you also could explore new solutions and build something more custom. The pattern then determines that the solution to this problem is to rely on the tried and tested method. The justification is that your job is to create something functional and you must prioritize that over all else.

I’m not sure how I feel about the proposed solution to this. I would say I overall disagree. Firstly, just because you’re trying something new doesn’t mean its entirely original. There are varying degrees to which you could try something new. So I disagree with the absolutism of the statement. Next, I don’t think that taking the time to create something new is entirely selfish. Just because you could hack together something functional quickly and deliver it to the client doesn’t mean that they won’t have a successful, or even better product from you creating something original. In fact, I think in a sense it shows how much you care for the client. Rather than giving them something cookie cutter, you chose to think specifically about their problem rather than force it to match some other problem. When it comes to coding, that practice might significantly aid performance, for example. Cookie cutter solutions to intensely computational problems can’t be as efficient as specified unique solutions.

Lastly, not all developers have the time to create original content in their free time. If developers spend all of their time copy pasting the same projects, how will the industry as a whole ever advance? So once again, it isn’t just about advancing your own individual skills. I feel there is a disconnect with this pattern. The author seems to be referring specifically to artifying the job, but their descriptions are much more vague than that and can encompass less “negative” practices. When it comes to treating every job like a unique art piece, I’d generally be against that since I don’t think it is a good business model. However, it depends mostly on what the client wants. Perhaps the client wants that level of connection with the craftsman.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Testing in Python and Sea

Something that is worth noting is Python’s assert keyword. Python has a built in way to create basic unit tests beyond simply printing and making comparisons. This has me thinking about my Sea programming language.

I think much of the hassle I’ve had with unit testing has come from simply getting the environment set up in the first place. If unit tests could be more like a data structure or design pattern – something you know the design of and you can simply implement – I think that would simplify a lot. So while I could create a Sea library for unit testing similar to numerous other libraries (or wait for someone else to make one in Sea), I’d prefer to create a more internal solution.

Sea is fundamentally C, so that means it doesn’t have a lot of high level features that can make unit testing easier. I mean, Sea isn’t even object oriented. That said, the entire design philosophy behind Sea is based on simple syntax that doesn’t add a runtime performance cost. One way I could achieve this is by adding another “stage” to the language. The current design of Sea involves a preprocessor, a lexer, a parser, and a visitor (interpreter, transpiler, or compiler). What I could do is add a tester that would run before the visitor, to test compile-time things (checking types or any other value known at compile time) and then a runtime tester. These could be modular features of the language itself and could be removed if desired.

Another simple solution is to add a handful of keywords to Sea similar to assert. The problem with that is C doesn’t have runtime exceptions. The design would have to be based on the notion that the program is the unit tests. I’ll continue to think this over. After all, Sea is still in its early stages. I’m currently rewriting it (just on the visiting functions now) and then I’ll add functions, pointers, etc. However, if Sea is to become a real, usable language then there will have to be ways of testing code; the simpler and more convenient, the better. After all, that’s the whole point of Sea.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Confront Your Ignorance: Filling in the Gaps

Photo by Ann H on Pexels.com

Software development often involves a large variety of interconnected tools, patterns, standards and ideas which must be understood at a functional level to be able successfully apply them to the project at hand. Sometimes the sheer number of things which require your understanding can feel overwhelming, and going into a project without knowing absolutely everything you might need to know often leads to stress regarding the gaps in knowledge versus what is required.

The pattern discussed in chapter 2 of Apprenticeship Patterns, (link: https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch02s06.html) discusses the idea of confronting your ignorance, by which the authors mean that you should seek out and eliminate any holes or gaps in your knowledge, rather than allowing the “ignorance” to be a detriment to yourself. More specifically, the pattern describes the process of picking one skill, language or technology to focus on at a time, and working to better your understanding of that one idea. Rather than trying to focus on everything at once, you focus on learning one skill at a time, generating a more “precise” understanding of it than if it were being lumped together with other subjects.

This idea makes a lot of sense, intuitively you might think it would be second nature to begin learning a new topic by focusing only on that topic instead of trying to do everything all at the same time, but often that is exactly what ends up happening. Whenever there is a larger “stack” of tools to learn, I sometimes find myself actively trying to absorb everything all at once, because I feel that maybe slowing down and taking each single tool or topic on by itself might slow things down too much. This hesitance not to “multitask” when learning new ideas makes it harder to really focus on any one thing when trying to become familiar with a large number of tools and ideas in a short timeframe.

Overall the major ideas of Confront Your Ignorance are simple, and easy to implement , the big drawback being the time it will likely take to focus exclusively on one topic can often take time away from other activities. Like most patterns discussed in Apprenticeship Patterns, finding an effective balance between this pattern and others is important and likely dependent on context most of the time.

Book Referenced:

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch02s06.html

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.

Converting a Project to Gradle

A few weeks ago, a few classmates of mine asked for some help with converting code to Gradle and I created a quick guide. I’d like to go through and create another guide with more detail.

Assumptions

  • You have Gradle installed.
  • You know which language you are using.

Instructions

The first step is to run gradle init in the project folder that you wish to convert to gradle. I would recommend if you’re unsure about the process or the settings you’ll use, just create an empty folder somewhere and practice creating a gradle project in that. Then, delete it.

Note that depending on the options you choose, you may be asked questions I do not cover here. Just do your best to figure out what it means and use the internet for research. Worst case, you can always modify the settings afterwards.

When you run gradle init, you will be asked some questions about your project. You simply type the number corresponding to the option you want and then press enter (or simply press enter without a number for the default option). In our classes, we always used libraries. If you have a main method, you’ll probably want application.

Next, it will ask you for the language you want to use. This is probably the simplest question. In our classes, we’ve used Java but you can use any of the displayed programming languages.

Next, is the build script DSL. If you don’t have a strong opinion on this, just use the default.

Similarly, next is the testing framework. Use whatever you’re comfortable with. In our classes, we’ve used JUnit Jupiter.

Next you can name the project anything you like.

This last step where it asks for source package for Java is a step where many people mess up. The default option is an undesired package name, since it will include capital letters. I recommend using a lowercase package name.

Now, you can open lib/build.gradle. You can remove the lines and comments for api and implementation. These are auto-generated, but not necessary. Next, if you plan on using GitLab’s ci, modify the testRuntimeOnly line. Notice how the testImplementation line has a version number following a colon. Modify the testRuntimeOnly line so it has the same version as the testImplementation. After these steps, my dependencies looked like this:

dependencies {
// Use JUnit Jupiter API for testing.
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.2'

// Use JUnit Jupiter Engine for testing.
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.6.2'

}

Now, gradle will have created a gradle/lib, gradle/app, etc folder. Locate your package which will be a subdirectory of gradle/lib/src/main/java in my case. The main folder will contain your source files and the test folder will contain your tests. Move all of your source files into main/PACKAGE_NAME and move all of your tests into test/PACKAGE_NAME. You can delete the files gradle generated for you.Then, if you’re using java, you’ll need to go into each java file and add a package declaration. Make sure its the first line and that there is only one. It should look like:

package PACKAGE_NAME;

Where PACKAGE_NAME is replaced with the package name. You can then run tests with the gradle test command. If you want to have GitLab run your tests for you when you push a new commit, download .gitlab-ci.yml (ideally the newest version so not from this link) and add it to your repository. Now, things should hopefully work.

Closing Comments

It’s taken us a while to become familiar with Gradle so I think it was worth me writing all of this down (albeit hastily) to help other people in the future, and especially to help me remember it if I ever use Gradle again in the future.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.