Software Engineering

About Monorepositories

It would seems a new fashion has come to the world of software engineering, which anyone is expected to have an oppion about. The so called mono-repo talk. As with so many other cases there seems to be multiple definitions flying around and not asserted definition of when you have a mono-repo, but let me try to share some thoughts. A repository is a place, where sourcecode (and potentially other stuff) is associated with software development is stored.

Git for other stuff

Git is often refered to as a source control tool. It’s useful both for teams working on a shared source code as well as individuals how wants a log of the changes in their sourcecode over time. While sourcecode handling is the most common use case, Git itself isn’t per say limited to just managing sourcecode and using Git repositories for non-sourcecode may also have value in your daily work. This post is a small apetizer of some of the cases I’ve been using Git for non-sourcecode.

Emphemeral and immutable

When storing data, most data have a lifecycle - it created, managed and eventually deleted through operation of the application or script that use it. There are however to kinds of data storage which is slightly different, which developers should know about as they may be nice patterns to know and use when applicable. Emphemeral data The first data storage is emphemeral data. This kind of data will eventually automatically be deleted.

Best of breed or best of suite

In (domain or enterprise software) architecture, there are to generic patterns you’ll likely come across often, yet many developers does not seem to be familiar with them and knowing a bit about them may help understand why some choices are made when building a complete software stack across a company or enterprise. These are: Best of suite Best of Breed. When adopting the “best of suite” strategy, the Enterprise Architecture will seek to find big software suites, which can over a large domains.

How not to become the maintenance developer

As a developer it seems, you always seem to strive towards producing ever more complicated code. Utilizing new frameworks, adopting an ever evolving “convention before configuration”, pushing object-oriented programming - maybe Domain Driven Development - are practices introduced, refined and explored in the quest to prove yourself as a steadily better developer with rising skills. Yet to what point? While the intricate complications may impress fellow developers, doing so often digs a hole which may be pretty hard to get out of.