Once again almost 8 months have passed since I posted anything in here. It’s always the same, right? You design and develop a better portfolio when you’re looking for a new job, but after that’s done you forget about it. Same with your CV.
During this time I did a bunch of stuff that I thought I’d write down here.
Learning about DevOps and agile
I read two books related to DevOps in the last few months: The DevOps Handbook as well as the Phoenix Project. Also, Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations touches the same subject, but from a more scientific standpoint.
These books taught me a lot. The most important thing: DevOps is a culture. It is a development culture within a workplace.
It is not a role, it’s not just about automation, it’s not about using a specific set of tools, it’s not just about continuous learning. It’s the collaboration of developers and operations people. Cultivating an environment where failure is not just tolerated, but encouraged. Where continuous learning and innovation is promoted, where multidisciplinary teams work together to find the best solutions embedding things like security and testing to the work from the start… among a bunch of other things.
Agile
DevOps also enables agility. Agile in itself is very simple. An agile coach I’ve been working with has told this many times:
There’s having an agile mindset and working in an agile way. Those two are separate things.
As I’ve come to understand agile better, I’ve also understood how no one should just take an “agile” framework and try to follow that with their teams. By definition these frameworks are not agile. All of them tell you to follow them exactly, or you won’t reap the benefits from them. That’s not agile. That’s the exact opposite.
Instead, what I recommend is you get to know what Lean is, what Scrum is, and build your own development process from there. Adapt to the agile mindset and start working in an agile way, collaborating, innovating, focusing on the customer value. You can do this in a number of ways.
The biggest blocker to agile in many companies is middle management. Often these people adapt an industrial mindset and want to know the deadlines, the budget and trying to hold onto a fixed plan so they can rein in those two things. But that’s not agile.
I believe that teams harboring different types of talent (so they can work an entire slice of the cake) should collaborate with stakeholders (business owners, users, customers…) to discover what problems exist and work those problems to deliver value. They should be constantly prioritizing the work, learning new things and adjusting. We’re all adults. Management should give development teams a goal to reach and trust for them to get the job done.
Getting more and more into TypeScript (but also .NET)
I’ve always been a web developer who’s mostly used PHP. I started working with it over 15 years ago and I use it to this day. But the industry has moved a little bit more towards TypeScript (JavaScript) due to its powerful ecosystem that enables fast prototyping and development.
Right now I’m working as a full stack developer on a project where my main focus for the first year was the front-end, built using TypeScript. I got rather advanced using React. I also built a lot of freelance projects using TypeScript, including building the back-end services with it, instead of PHP. What this means is I’ve been developing apps using Node.js runtime.
However, TypeScript isn’t the only language I got into deeply this year. I took a deep dive into the new .NET Core and re-familiarized myself with C#. This enabled me to start working with all the layers of the project I’m currently in. Building microservice apps using .NET Core in Azure is fun.
Projects
I’ve mostly been developing two major projects this year. I can’t get into specifics so I’ll just call these Project #1 and Project #2 while describing their problems and what I’ve been doing to solve them.
Project #1
Problem: Poor user experience using a third party ordering system, to which customers are forced to be redirected when they want to order something.
Solution: Move the order process into the front-end application that serves the company’s website, building an integration between these two application while improving the flow.
High level tasks:
- Improving the user experience of the order process to make it more streamlined.
- Developing an integration between a front-end application and a back-end system that has a poorly designed API by building a proxy API that contains business logic and some security features.
In general I would like proxy API’s (API Gateways) to be void of logic, but in this case that was impossible. As the third party system API was poorly designed, I was forced to add logic to it to make the order process work. The API also didn’t support user sessions or exchanging user credentials for a token to be used with the API. I had to build authentication and authorization into the proxy API.
Project 2
Problem: Costly third party cash register and payment terminal services.
Solution: Build a mobile application that integrates into a payment terminal, lowering running costs and enabling more customization.
High level tasks:
- Building a mobile application for tablet devices that integrates with a Poplapay payment terminal, using Flutter. The mobile application would communicate with an Azure Functions serverless app back-end that handled the products, categories, sales and all other information.
- Developing an administrative application with TypeScript and React for restaurant owners to log into and control their sellable products, categories, cash registers, payment terminals etc.
- Identity management using Azure AD B2C
Last summer I had some spare time between projects and decided to start learning mobile development using a hybrid framework from Google named Flutter. In comparison to something like React Native, Flutter compiles itself to native languages, making them faster. The ecosystem is not the best yet, but I managed to work with the framework to build the application.
Having the realization that building an app with Flutter is much like building a front-end application in the web using something like React, made the work much easier.
Sunsetting a personal project
For seven years I built a platform that I thought was gonna solve a big problem in the LAN event space. Unfortunately life itself happened and I found less and less time to work on the project. Then the pandemic started and events shut down. We tried to restart the project a couple of years ago, building the ticket management system and rebuilding the platform in itself, but we hit motivation issues and started to wonder if it was worth it.
In the end, solutions to this problem already exist. Building and maintaining a large scale application would take too much of our time and we decided to call quits. We also decided against open sourcing the existing work because it was too unfinished, and open source projects also need some sort of effort to maintain. None of us had the time for that.
So, bye bye Xerberus.