Posts tagged with notes

  • API Style Guide

    Using a microservice architecture allows development teams to work separately, delivering work faster and focusing on a specific part of the business domain. Working independently means that developers are free to make their own choices. While that’s great, there’s the risk of building the tower of Babel.

  • Code review guidelines

    In this post, I’m describing some do’s and dont’s about code reviews. I’m not focusing on the technical side, which depends on the technology stack, but on the process and the etiquette.

  • CI requirements

    There are so many programming languages out there and so many frameworks to choose from. From a continuous integration perspective, I think that there a couple of requirements that one should check before jumping onto something brand new.

  • On versioning

    According to Wiktionary, the word version means “a specific form of variation of something”. In computing, it’s “a particular revision of something” (e.g. software). The word has French and Latin roots. The Greek translation, έκδοση, can also be translated as publication.

  • Developer Utopia

    What happens when developers get the full freedom to work on the things they want with the tools they want? “Get the best people, give them the best tools and get out of their way”. That should work. The reason it doesn’t, it’s because we haven’t defined what “best” people means.

  • On git branching models

    Usually, when you work with a version control system like git, development happens in multiple branches. It’s funny to see people’s faces when you tell them that the author of Continuous Delivery, Dave Farley, advocates “no branches”. I had that same surprised face myself the first time I heard that concept. But, so far, I haven’t really worked somewhere where no branches were used.

  • Ergonomics and APIs

    According to my Google search, ergonomics is the study of people’s efficiency in their working environment. The developer’s working environment consists of the physical world but also the virtual world. In the physical world you desire a quiet office, good desk and chair, proper lighting, the best tools your budget can buy, etc. In the virtual world, you have software tools, IDEs, etc. But when writing code, the working environment also consists of the APIs you code against, as well as the code you have written for yourself.

  • Keeping it simple with microservices communication

    The term microservice has been getting a lot of hype and attention. I have to admit that I fail to understand what’s the big deal about it. The best practices about microservices are similar to the ones we should apply to everyday software design. Avoid tight coupling. Single responsibility principle. Keeping things simple. Even those principles go back to the old Unix mantra of doing one job and doing it well (and that’s from 1978). And even that could in turn be labelled just “common sense”.

  • On Code Comments

    I recently joined a different team at work, working on a whole different project. For the past one to one and a half year, I did my bit in building up a culture in my old teams regarding code quality and the moral responsibility of a developer towards the codebase (also known as boy scout principle). Now, we have to start all over from scratch with the new team.

  • Worked fine in DEV, OPS problem now

    During the past year at work, we did a complete rewrite of our websites from scratch. Not only did we aim to build a mobile-first responsive website with high performance, we also tried to do it with continuous integration and continuous delivery in mind. All that on a proprietary platform not built with CI in mind. This was a very big challenge, which involved a culture change in a lot of people. Unfortunately, the project had a hard deadline. Things were left out. Corners were cut.

  • 20th Century Code

    I spent the previous week migrating some old code I had laying around into GitHub. More specifically, I had a single git repository named “Legacy” that contained all sorts of projects and demos I had created over the years. It’s difficult to find exact dates but I found a few that go as back as 1998, so I can justify the title of this blog post.

This site uses third party cookies from Google Analytics and Google AdSense Accept and close popup