Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
We've long been promised a world where automation and other tech would free up our time to focus on more creative, rewarding pursuits.
However, we still find ourselves battling with small, but time-sucking tasks. We all want to surrender ourselves to the deep focus we need to complete more important work, but there are two big old-time sucks:
Much like running up bills on your credit card, technical debt can easily get out of hand. To avoid this happening, you need to keep track of how much debt you’re building up.
Technical debt metrics are designed to help you make sense of all the data you collect. There are many different metrics to choose from nowadays, and plenty of tools for recording the data.
One of the development team’s biggest challenges is having a consistent and reproducible environment between team members. The bigger the team or more teams working on the same project codebase, the issue is amplified. Different languages try to manage dependencies using a specifically inbuilt language-specific package manager.
For example, Python is using by de-facto pip as a Python package installer that is using Python Package Index repository. All dependencies can be declared in the requirements.txt file and installed with pip install -r requirements.txt Pypi is limited in managing consistent Python packages and versioning. New Python package managers try to solve the limitation of the pip like Data Science oriented Anaconda or Poetry that bring multiple improvements over pip with dependency management and packaging. Poetry is arguably Python’s most advanced dependency management option today by using a configuration file in toml format and generating project scaffolding, locking dependency in the *.lock file.
To call Google a titan of the tech industry would be an understatement. Their name has become synonymous with the internet itself. The very act of retrieving information from the internet - the core functionality of the internet and its most basic purpose - is known simply as “Googling” something. On their road to becoming the web’s biggest search engine and a moniker for the internet itself, Google also pioneered much of what it takes to grow a company at scale.
On the Dev Interrupted Podcast Google Senior Engineer’s Hyrum Wright and Titus Winters, shared their lessons learned from programming at Google with LinearB Co-Founder and COO, Dan Lines. Both engineers have a deep understanding of the principles behind software development: Hyrum is semi-famous as the "Hyrum" of Hyrum's Law; while Titus is responsible for 250 million lines of code that over 12,000 developers work on.
Google is a titan of technology with one of the largest codebases in the world. Managing and scaling this amount of code is a monumental task. And while Google doesn't profess to have all the answers, you can probably learn a thing or two from their journey.
In the first episode of a two-part series, Senior Google Staff Engineers Hyrum Wright and Titus Winters joined me on the Dev Interrupted podcast to discuss lessons learned from programming at Google and to talk about their new book.
When developing an application for only one client or only a single version, the main subjects you focus on are how to implement the features, security, performance, design, time to market, etc. What will happen if the number of clients increases, and each one of them has different requests that contradict each other? Are we going to duplicate our codebase and have different apps, which we have to implement common features to every instance separately? Or are we going to manage them from one codebase?
Diversity in labels might be managed with different property files, but will this be enough for all kinds of requests? The flow in the logic might be directed with control blocks. What will happen to them when you have 100 different clients? What will happen to the readability/manageability of the code? We might decide to extract the logic that differs from one client to another and have multiple microservices. This will allow us to have clean code, but will we be able to turn all the logic that differs from client to client into microservices? Is our structure suitable for this process? How about managing and deploying all those services? Is it worth the cost?
A 12-factor app is a methodology or set of principles for building scalable and performant, independent, and most resilient enterprise applications. It establishes the general principles and guidelines for creating robust enterprise applications. 12-factor app principles got very popular as it aligns with Microservice principles.
Below are the 12-factor principles