I am a Full Stack Developer based in Toronto with a background in
electrical engineering.

With proven leadership and communication skills, I am passionate
about using creativity and best practices to tackle complex
challenges and working effectively in a team. Whether I am
creating a web application or building automation tools to make
businesses run efficiently, I want everything I build to be
scalable, maintainable and have a positive impact on the lives of
everyday users.


## Motivation

I joined a team called Experience Platform and Tools (EPT) within Telus Digital. This team was mainly in charge of a product called Site Builer as well as few other tools that are meant to increase efficiencies in building and maintaining public facing TELUS branded websites.

Telus.com is the main public facing website of TELUS and holds over a 1000 static pages. While building a static website from scratch using frameworks like React are not that complicated, maintaining over a 1000 pages can get complicated. As an organization we have to ask:

- How do we ensure design consistency across all these pages?
- How do we minimize developer time in building and launching pages that have to be updated weekly and sometimes daily?
- How do we make sure we don't reinvent the wheel every time a different team decides to launch a website?

TELUS's answer to these challenges is [Site Builder](https://www.telus.com/en/digital/our-work/site-builder), a server-side rendered React application, with Node.js in the backend and Contentful as it's CMS. We manage Site Builder like an open-source project within the TELUS and different teams within the organization are welcomed to use existing React component or if they don't suffice, welcomed to contribute more React components and build Telus branded static websites.

When I joined this team in May 2020, Site Builder was over 4 years old, laden with tech debt and in desperate need of a rewrite.

We started the journey of rewrite and building Site Builder 2.0 with the following objectives:

- We'd make minimal changes to how we manage content. Contentful would still be our CMS of choice.
- We'd improve the performance of Telus.com from a lighthouse score of around 50 to at least 90.
- We'd improve the content editors experience by moving content management from Contentful to the browser. Content editors would inline-edit content directly on the page they were looking to make changes.
- We'd improve developer experience by using the latest open source projects like Next.js or Gatsby.

In the end we decided on using Next.js as our framework and also decided to experiment with [Tina CMS](https://tina.io/) as our inline-editing framework.

As of time of writing, Site Builder 2.0 project is moving full speed and we are very close to MVP. Content editors are able to build Telus Branded websites from scratch using the Telus Design System and are able to make almost all the changes to an existing page without ever visiting Contentful.


Site Builder is an internal site building tool similar to Wix and Squarspace built on React. It's a rendering engine that allows teams within Telus to reuse content, code and design to build web pages with minimal coding skills. As of October 2020, there are over 1000 pages hosted on Site Builder

TELUS Site Builder

## Motivation

I had the opportunity to work as a Front-end Developer at OMERS, one of the largest pension funds in Canada with over 500 thousand members.
myOMERS is the logged-in experience for OMERS members that allows them to perform a variety of administrative tasks related to their plans. Some of these tasks were:

1. Checking their total retirement contributions to date.
2. Increasing/decreasing their retirement contributions.
3. Getting their annual tax slips.
4. Changing their communication preferences, their passwords, etc.
5. Having secure communications with agents.
6. Transferring money from their pension plans to their personal bank accounts.
7. And many more!

As a Junior Developer, I was incredibly fortunate to work with a team of very strong developers to re-platform myOMERS application from a legacy AngularJS and JQuery stack to a modern React and Redux stack and had the opportunity to be involved in every step of the process from initial planning and setting up the repo, all the way to the release of the new application!

While going through this experience, I had exposure to the following that I think allowed me to advance and become an intermediate developer.

1. Learning proper state management:
   - For a given feature, where should the state be stored? Should it be local or should it be in the global redux state?
   - What part of the state should be ephemeral and what part should be saved in cookies or local storage?
   - How do we handle side-effects?
2. When working with multiple developers on the same feature, how do we, the developers, make sure we are not stepping into each others toes. (Hint: over-communicate and use proper git-flows)
3. How do I separate the concerns of the data Layer from the rendering layer?
4. What are the best practices around architecting a React application?
5. How does one assess the performance of a web application?
6. Proper git flow and release management.

## Final thoughts

I was incredibly lucky to join an evergreen project and be a part of a full product development cycle. With the help of amazing mentors, engineers and team members, I grew as a developer and am proud to say that I contributed considerably to the successful launch of the new myOMERS experience.


Is a secure web application that allows members to do administrative and financial tasks seamlessly from the comfort of their homes. Allows members to update communication preferences, check pension information, increase/decrease retirement contributions, access administrative documents and many more.

myOMERS

## Motivation

Even though I have worked with Java and Python in the past (during university), until I started working on this project I had never build a full stack application outside the Javascript/Typescript ecosystem. To that end, I decided to pick up a new language and build it's backend with it.

I found myself trying to decide between using Ruby, Python and Go but in the end I decided to go with Go for the following reasons:

1. It's a statically typed programming language. So I'd be able to add on to what I had learned from Typescript but I wouldn't be able to cope out of typing when I found it convenient by using the "any" keyword like I'd be able to with TypeScript.
2. I'd be able to explore topics like concurrency, multi-threading and pointers, again topics that don't exist in the Javascript ecosystem.
3. Even though the first version of Go was only released in 2007, as per StackOverflow, it's almost as popular as Ruby giving me the confidence that I was learning a "hot" language.

For the sake of focusing more on learning Golang and less on feature building, I decided to work on a relatively simple application and chose to build a simple url shortener similar to [Bit.ly](www.bit.ly).

My MVP for the server was the following:

1. When a url is sent to the servers "/create-hash" endpoint, it would first check if the hash for that url exists in the hash table and if it did, would return the hash. Otherwise, it would create a new hash in the hash table and then returns that newly created hash.
2. When a user were to hit the server with a hash (ie. the endpoint /{:hash}), it would redirect the user to the url stored in MongoDB.
3. This server would also serve the front-end if a user were to hit the root url.
4. And I would develop all this using test-driven-development approach.

My MVP for the front end was just a simple React front-end capable of sending /create-hash request to the server. I could have used Golang templating language to build the front-end but in the end I decided that React is already a great tool to build front-ends and my time could be better spent learning the intricacies of Golang as opposed to a new templating language.

## Final thoughts

This was a challenging but nonetheless rewarding task and I'm very proud of how it turned out. Though I'm not 100% satisfied with my back-end code as I think there is a lot going on in my "main.go" and it might have been a good idea at some point to extract some of the key logic of initializing a mongo server out to a separate package.

It was also very painful to figure out how to serve a React build bundle from the server. With full stack React frameworks like Next.js and Gatsby.js, this is seamless but with the Go server, I actually had to outline when to serve the html as well as handle static asset request. Another pain point was that, because I didn't have a proper production pipeline set up, every time I wanted to make changes to the React code, I had to rebuild the React code with `npm run build` and then copy paste the `build/` file inside the server. Considering these pain points, if I were to build a Golang + React project again, I'd probably forego the mono-repo architecture and have two separate servers: one as a BFF (back-end for the front-end) written purely in Typescript and one as the Go server as a separate API.


This is a full-stack application I built as a practice while learning Go. It's a url shortener similar to bit.ly. Given a url, it shortens it and when users hit that shortened url, it redirects them to the original url.

url-trim.shop

## Motivation

When I first started learning JavaScript, for better or for worse, I immediately jumped into using libraries and frameworks to manipulate the DOM. It was first JQuery then it was React. I figured just using vanilla Javacript to manipulate the DOM was a gap in my knowledge.

To better understand DOM manipulations using vanilla JavaScript, I decided to build a relatively simple game that I used to play as a child: Mastermind, with the goal that I would only use vanilla Javascript ie. utilities and constructs that are natively available in JavaScript and wouldn't rely on any external JavaScript packages. For that reason, if you look at the [project directory](https://github.com/canrozanes/mastermind), you won't see a package.json or a package-lock.json file.

## Reflections

Even though I had a lot of fun building it from scratch, this project made me truly appreciate the power of React. So many little things I had to worry about while building this game such as having to store references to DOM objects, mutating them, adding an removing classes from them, are almost seamless with React whereas in vanilla Javascript, requires a bit of heavy lifting.

I also like to think that I got better at Mastermind because I had to play it so many times during testing. It's a fun game!


Put your logic skills to the test as you try to break the randomly generated code within 8 tries. Built using only vanilla JavaScript and zero dependencies.

Mastermind

## Motivation

This is a fun little project I built with [Eugene Michasiw](https://michasiw.com/) in the span of few days. The app consumes an external api [Open Trivia DB](https://opentdb.com/api_config.php) and serves 15 Computer Science related questions in the format of "Who Wants to Be a Developer".


Test your Computer Science Trivia! A computer science focused trivia game in the format of "Who Wants to be a Millionaire."

I’m a Full-Stack Developer.