In many companies, appplications quickly become a web of interconnected systems with dependencies upon each other and testing changes to a single application may be hard, as the behaviour of the application may depend on interaction with other interconnnected applications.

Ideally it would be nice to have a test complete environment with (dedicated) test versions of any other application impacting the application being tested - and have a coherent and applicable test-data set to use (but let’s leave test data for another post).

Bruno is an open source alternative to tools like Postman or Insomnia. Both are nice, but they also seem to becoming more complicated than I really need, so I’ve been looking for something else.

Initially I didn’t have more complicated needs than wanting a tool to tinker and play with simple REST APIs, so I looked around and found Bruno.

As many APIs require some authentication, you often need to manage credentials, tokens or other sensitive data which shouldn’t be in your git repo, and luckily Bruno has a nice way it can be used with 1Password which is my password manager of choice.

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.
• A mono-repository is when all the sourcecode produced in a company is manged in a single repository.
• A Single-server respository (strategy) os whenn all sourcecode is manged in a single (git) server, but every project has its own repository.

On the multi (git)server, multi repository setup…

I don’t like it.

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.

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. In most cases the data is stored shortly - an hour, a day or a week - but there isn’t any fixed rule which define when the data disappear - just that it does by itself without any explicit cleanup or pruning from the developer (or user).

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. One of the most often picked suites is often Microsoft OFfice, where Word, Excel, Powerpoint and the other applications included in Microsoft office comes a single package - a suite.

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. Every complication - not matter if it is in the design, the architecture or the structure of the code - often provides the opposite effect of the desired outcome. The whims of your current self to impress developers with the latest fashionable technique, is short termed reward for a long term pain.

Most developers (and certainly professional shops) working with software- or webdevelopment has understood the ideas behind sourcecode version management - no matter if they choose to use cvs, subversion, git or any of the other fine systems available. How developers use these systems, can provide an easy insight into who is the dummy, the average and the great developer.

When to commit

One of the first distinguishing signs is what they commit - is the version management system used as a backup tool or as a version tracking tool. Some seem to think, you should end the day by committing all your sourcecode (no matter which state it’s in). This is really bad sign. Others commit whenever a new file is finished and thought ready to use - which is slightly better. Others again commit once - just before a new release - and has the commit contain each and every change since last release.

So it been awhile since I sort of promised some tips on developing web applications fast. This post contains my five generic tips, which may apply to you (but then again - your mileage may vary). I’ve tried to abstract the advice and not stick to PHP development here, though it’s by far the world I know best.

1. Spend time on the data model

Too often a data model is driven by code, not careful thinking, and this often causes problems has the web application develops and expand over time. When developing a site, which needs data stored in a database (as most web applications tend to do), do try to spend some time on the data model - which tables do you need, what fields should the tables have, are the naming logical and consistent, what constraints and limitations does the data model offer.

It’s always fun to read articles with tips and tricks by other developers and see how they figure “best practices” are handled. Most developers do seem to thing they observations and practices are easily adopted by anyone, and should be accepted without any argumentation or reasoning behind the advice.

One of the nice examples of this, was a story called “5 tips and tools to develop php applications fast”, and while it may apply to the web applications developed by the author, it’s one of those where I question who is supposed to be the audience. All 5 tips are often found in many textbooks and other stories on the net, and in my experience they are all wrong (more or less naturally).