This was my third and last work term, starting in Janurary and going 8 months until August. This work term was notable for being entirely virtual despite the company's Guelph office - I did all all of my work working from home.
Camis provides parks and campground software for different parks and natural resource organizations in both Canada and the United States. They are a 'full solution' provider - providing the public-facing reservation website, the in-park management and analytics software suite, and any hardware or resources needed to support these applications, including call-center support.
I was part of one of a few software development teams that build and maintain the reservation website and park software. Nominally each team was responsible for a specific domain of the software - sales, analytics etc. - But work would be shifted between teams where priority or capacity required it.
The development process was slightly different from previous places I've worked at - Camis teams follow a more regular Kanban approach, with no regular development intervals like sprints being used. Instead, you have a regular flow of tickets being added to the kanban board (from discovery meetings, bug reports) and developers take tickets off of the Ready pile when they have capacity. The only development timeline was releases - certain tickets and epics are slotted to be complete for certain releases.
The codebase itself supports two separate applications - a reservation website that customers can use to book campsites and rent/buy park supplies, and Windows desktop application that acts as the "in-park" application for park staff - facilitating bookings, sales and park telemetry.
The in-park application was .NET - a WPF frontend interface (with XAML pages) with business logic written in C#, and relational SQL Server backend. The reservation website also had a .NET backend, but used Angular for the frontend UI.
I found C# to be very similar to Java in many ways, and overall was a very nice language to work in - I found some language features like LINQ queries to be really natural and easy to use.
An immediate challenge at the start of the work term was adjusting to working and interacting with my team completely online. My immediate concern was onboarding and getting my development environment set up - In previous co-ops my experience was that getting set up could be a hard process that greatly benefitted from the institutional knowledge that a team could provide, which could be harder in an online environment.
Fortunately I found the setup process to be quite straightforward and without many issues - I was able to get the application up and running and start contributing by my third day of work without any major issues. I attribute some of this success to my previous work term experience - some tools like Jira I was already familiar with, and I had more experience in troubleshooting the setup process and asking the right questions than I did at my first work term.
A separate challenge that was present throughout the work term was keeping up to date on the status of other developers on your team and the status of what they were working on. There is much less opportunity to 'overhear' conversations between other developers or get information on the progress of work indirectly - you have to use direct methods, such as standup meetings or directly asking a developer to get information on a ticket's progress.
I created this goal when I learned more about the database backend that Camis uses for their application. In previous work terms the development teams I was on did not regularly interact with the application database - that was something that had already been established by the time I joined the team. At Camis dev teams are able to write SQL stored procedures when building features, so I wanted to capitalize on the opportunity to get some experience working with databases.
While I did do some work importing scrub databases and querying some application data, I wasn't able to find the opportunity to write SQL stored procedures of my own - I was not completely surprised though as the application was in a state where the database logic was mostly complete.
I made this goal at the start of the work term. Camis maintains two separate frontends - one for the in-park application that uses Windows Presentation Foundation(WPF) through XAML files, and one for the reservation website that uses Angular.
I got quite alot of experience writing Angular components during an internal hackathon that was run in February. My team built a Google Maps integration that would embed Google Maps into the reservation website, and I helped to build the embedded Angular component. Angular is (something)
On the desktop side I worked on a number of components in WPF (Windows Presentation Foundation) - this used XAML files as the UI markup, paired with C# classes that linked UI actions (eg. Button presses, dropdown selections) to the business logic. XAML is not altogether too different from HTML, in that both are XML-based markup languages. One difference is that you can design custom components (similar to frameworks like React and Angular) and use those within your other XAML files.
By the end of the first half of the work term I considered this goal complete - I had experience in building UI component for both the web and for native Windows applications.
I made this goal at the start of the work term, once I had some understanding of the codebase's testing structure. Camis has unit tests for individual code components, integration tests for groups of components that perform certain business logic, and end-to-end tests for some main reservation workflows (mainly on the website side). I wanted to have a practical goal to accomplish in this test environment - writing a full test suite from scratch was unlikely considering the mature position of the current test setup, so I thought achieving full test coverage would be attainable, useful for me as work experience and useful for Camis in improving their test quality.
The Camis application uses NUnit for its unit tests. NUnit is very similar to JUnit in terms of structure and operation, so I didn't have much trouble getting accustomed to it.
An important feature of unit tests is that they test an isolated component of the codebase. This rule becomes tricky when trying to test a component that uses many dependencies; As soon as you pass in a full dependency to your test suite it no longer can be called a unit test, becoming more like an integration test. To solve this, you must 'mock' the dependency, setting up a faked component that returns a preset response that you then pass to the component being tested. For .NET codebases, a common framework that automates mocking for you is Moq.
Once I understood how unit tests in .NET land worked, getting a component to full test coverage was relatively simple. Creating pull requests automatically ran a SonarQube scan that would analyze test coverage and notify you of common code smells. I also utilized IDE tools that allowed me to determine test coverage locally.
I consider this goal to be complete as I wrote multiple components that were calculated to have 100% test coverage. I also learned alot about the test ecosystem of .NET applications, which I consider to be the most important outcome from this goal.
I made this goal halfway through the workterm, once I had gotten more familiar with the metrics analysis process my team used to gauge application performance.
The Camis application stores logs and performance metrics in Azure Application Insights, which generates dashboards teams can use to monitor performance metrics such as request successes and failures, response time and payload size, and more. Every other Friday my team would have a meeting where we would go over these dashboards for various parts of the application and look for any failures or outlying requests.
Unfortunately I did not make too much progress on this goal. I did get some practice looking into Azure Application Insights dashboards - these were visual graphs and data tables that presented key metrics from the application. Dashboards had been setup for the different parts of the application (in-park software, website etc.) measuring metrics such as load time for different pages, the number of successful and failed API calls, and some sales metrics like what products were sold recently at each park. Ahead of our weekly metrics meetings I would look ahead at these dashboards and see if I saw anything out of the ordninary - a large amount of failed requests, extremely long average load times and other red flags. I would then flag these issues in a Slack comment chain.
Unfortunately I did not get to the point of providing actionable guidance beyond just identifying issues - I did feel I had the required experience with the system to diagnose performance issues, and I became busy with development initiatives near the end of my work term.
I made this goal halfway through the workterm, once I had a better understanding of the project's structure and existing documentation. Project documentation is only useful if it is accurate and up-to-date; otherwise, it is more harmful than having no documentation at all. I considered updating documentation to be a good goal to work on when in-between development work.
Unforutnately I ended up not making too much progress on this goal. When our team briefly contributed to an upcoming mobile application, I made a setup doc that outlined the steps needed to set up a local dev environment to work with the project. Documentation is only useful if it is up-to-date; otherwise it can be worse than having no documentation at all! To address this, I periodically asked some senior devs who maintained the mobile project to take a look at the document and let me know if any of the setup steps had changed. I would also ask new devs to follow the setup guide and let me know if there were any steps that behaved differently or didn't work.
Beyond this documentation maintenance I didn't make any progress on other pieces of technical documentation - I got caught up in other development initiatives and didn't find the time to get back to this goal.
Overall I found this work term experience to be very rewarding. I gained development experience in a tech stack I had never worked with before (.NET) and got to develop in both desktop and web applications through the C# desktop app and the Angular web app. All of this was done using industry-standard Agile practices and tools (Jira, Confluence etc.)
Beyond regular work, Camis actively provided opportunities for developers to learn new skills - weekly tech meetings provided opportunities to ask the principal developers about technology and decisions behind the Camis codebase, and a hackathon at the start of the year let me work deeply with an Angular codebase.
My team was an absolute pleasure to work with - they were never hesitant to help me with any development issues I came across and had a really positive team environment that made work really enjoyable. I want to thank everyone on Sale squad who made the work term great - Andrew and Sheeja were great senior devs that provided alot of guidance, Ali was an amazing software analyst and always a friendly face, and Ian was a great project manager who always knew how to keep the team on track. Amninder provided alot of front-end experience, and Thomas and Aracelli were great project managers when Ian was away. You all made the experience at Camis amazing!