Goal 1: Become proficient in using Gradle to build applications

It was decided early on that the Java examples and projects I would work on would all use Gradle as a build system to compile and run the applications. I had used Maven at my previous co-op position, but in a more operational role as the Maven project had already been built. Gradle is a widely-used build system for Java (being the standard build system for Android projects for instance), so it is a very useful tool to learn for future roles in Java development.

Gradle can support many different project structures - from a single-entrypoint class to multiple classes with main() methods running separate programs. Gradle can efficiently run multi-project structures as well - have a build.gradle for each project and a root settings.gradle file that connects all of the build files together. All of the tasks in each project build file can then be run from the settings.gradle location. I built every Java project to be built and run using Gradle, including projects with external dependencies like JUnit and Lanterna.

Gradle can be installed manually (via package manager tools like apt) but a cool feature of Gradle is wrapper files, named gradlew or gradlew.bat respectively for the different shell systems. If a project has a Gradle wrapper file, you run Gradle commands using that wrapper file (ex. ./gradlew build )and it will automatically download and run a local verison of Gradle for you, no manual installation required! This makes getting up and running with Gradle projects as a new user very easy.

I consider this goal achieved as I have a solid understanding of both setting up a Gradle build for different project scenarios and running Gradle builds from the command-line. Next steps would be to learn how to use Gradle for more advanced processes like running CI builds or advanced testing scenarios. Gradle scripts can also be written in Kotlin which would be an interesting avenue to explore and could lead to more Kotlin development.

Goal 2: Learn Java Design Patterns

I made this goal when I learned I would do most of my work in Java - object-oriented languages benefit from modular design patterns that promote flexible, reusable code.

The projects I worked on - preparing practice problems and Jupyter Notebooks for course topics - does not naturally lead to implementing Design Patterns, so I worked to include them into my role. I designed Jupyter Notebooks that would introduce a Design Pattern, explain why it was useful, and provide examples in Java that were relevant to the course project students would work on.

The patterns I focused on were the Factory Method, Singleton, Decorator and Strategy patterns. Each have their own approach to making code structure flexible and easy to work with.

• The Factory Method pattern allows you to decide at runtime what subclass type you want to instantiate

• The Singleton pattern creates a class with one (and only one) instance active at a time, globally accessed by other classes.

• The Decorator pattern allows you to layer additional effects and attributes onto a base class implementation. Think of it like decorating a tree - you start with a base tree, then you layer on whatever additional ornaments and effects you want the individual tree to have.

• The Strategy pattern provides a collection of methods that can be freely interchanged with different implementations. While quite similar to the Decorator pattern, the difference is that with the Strategy pattern you completely swap out method implementations, while with Decorator you are adding details on top of a base implementation.

I believe I accomplished what a set out to achieve with this goal - I learned the mechanics behind multiple common design patterns and applied them in code examples. I think learning design patterns from the perspective of having to explain them to other students was useful in understanding both the mechanics and why you would want to use design patterns. Some next steps for this goal would be to apply design patterns in a project setting, rather than as isolated code examples.

Goal 3: Learn to effectively present / introduce projects

This was a continuation of a goal a set last work term; I found that when attempting to introduce or explain technical topics I was often unclear or took a long time to get an idea across. As I was doing solo work on multiple projects this work term, I thought it would be good practice to present my progress on these projects as much as possible to build experience and confidence.

I had plenty of opportunities to present my work to others. Every workday the team would have virtual standup meetings, where we would be broken off into random groups to discuss our progress. Since each standup would have a different group of people than the last one, I made an effort to introduce and explain the projects I was working on - both so my group would have context and so I could get valuable practice.

Once every month the team would have a "Show and Tell" meeting where we would present what we were working on over the summer. These meetings were an excellent opportunity to practice technical and presentation speaking, and I used them as a judge for if I was improving or not. At the first meeting I presented the Jupyter Notebooks I had been created for CIS*2430, and at the second meeting I presented a proof-of-concept of making a Roguelike game using the Lanterna terminal library.

I found that creating a rough bullet-point 'script' to follow when demoing my work was really helpful in keeping me on track and providing a logical flow to my presentation. I created a bullet-point script for my Lanterna presentation and I found it was much clearer than my first presentation, where I went without a script.