Then I discovered website builders like Wix. They let you pick from ready-made templates and just swap out titles, photos, and descriptions. Publishing was a breeze. At the time, web design agencies still had plenty of business, but tools like Wix marked a shift: for many small business owners, it became easier to build their own site or hire a freelance designer, rather than working with a full dev team that might not even deliver something to their taste.

Thanks for reading! Subscribe for free to receive new posts and support my work.

Fast forward to today, and the trend has only accelerated. If you’re a local business—say, a small furniture store—all you really need online is your address, opening hours, maybe some sample photos. You can do that with a website builder, a no-code tool, or even just an Instagram page. For many, Instagram is the business’s digital storefront. And honestly, that’s a pretty solid approach.

But what about more complex functionality? Imagine a shop that wants to manage its inventory: different types of furniture, prices, specs, invoices, and analytics. Traditionally, this would require a backend with a database and a web server to handle CRUD operations (Create, Read, Update, Delete). You might hire a developer to build it from scratch or use a CMS like WordPress or PocketBase—tools that come preloaded with much of what you need.

But here’s the thing: even that might become obsolete.

With the rise of AI-driven tools and models, we’re entering a world where you might not need to write a single line of backend code or even set up a CMS. Instead, imagine telling an AI: “I want to keep a list of all the tables in my store, along with prices and quantities,” and having it generate a full application, including the database, the logic, and the interface, in seconds.

AI models can already understand user intent well enough to generate dynamic queries. So instead of building APIs with narrowly defined endpoints (which still require lots of work to get right), you can expose the database—securely—and let users ask exactly what they want. Privacy and access control can be enforced at the AI layer. As these primitives mature, they’ll make managing a business vastly simpler.

In this AI-first future, the barrier to building internal tools or customer-facing apps will collapse. The cost of development will drop dramatically, and the role of engineers will shift from building CRUD apps to designing smarter systems that orchestrate and safeguard AI.

We’re not just automating code—we’re automating decisions about code.

Thanks for reading! Subscribe for free to receive new posts and support my work.

Usually, communication between the application and kernel is done through system calls. However, Go employs channels that have different functions, one of which includes communicating signals to the application. Therefore, we will use channels to manage signals in Go.

Everything we need is in the built-in signal package. First off, we must redirect the signals to us via channels:

signalChannel := make(chan os.Signal, 1)
signal.Notify(signalChannel, os.Interrupt, syscall.SIGINT, syscall.SIGTERM)

The first line presented above creates a channel of os.Signal’s. Next, by calling the function Notify from package signal we redirect the os.Interrupt, SIGINT and SIGTERM to our channel. In order for the application to listen to the signal, simply wait for the channel to receive one:

sgn := <-signalChannel
log.Printf("Handling %s ...\n", sgn)
// Handle your service

The full example:

package main

import (
    "log"
    "os"
    "os/signal"
    "syscall"
)

func main() {
    signalChannel := make(chan os.Signal, 1)
    signal.Notify(signalChannel, os.Interrupt, syscall.SIGINT, syscall.SIGTERM)
 
    sgn := <-signalChannel
    log.Printf("Handling %s ...\n", sgn)
    // Handle your service
}

Run the program and then hit CTRL+C to terminate it and see the result.

If for your reasoning you want to hand over again the handling to the system you can simply call the Stop function and pass the channel as an argument.

Group: In mathematics, a group is a set equipped with a binary operation that combines any two elements to form a third element in such a way that four conditions called group axioms are satisfied, namely closure, associativity, identity and invertibility.

Subgroup: a subset H of G is called a subgroup of G if H also forms a group under the same operation.

(Left)Coset(Right): given an element g of a group G and a subgroup H of G, gH = { gh : h an element of H } is the left coset of H in G with respect to g, and Hg = { hg : h an element of H } is the right coset of H in G with respect to g.

Transversal: given a subgroup H of a group G, a right (respectively left) transversal is a set containing exactly one element from each right (respectively left) coset of H.

Problem: Let G be a finite group and let H<G(H is a subgroup of G). Show that there is a subset T of G which is simultaneously a left transversal for H and a right transversal for H.

Solution Let L be the set of left cosets of H and R set of right cosets of H, both of size |H|. Now define the bipartite graph with vertex set L+R with two vertices being adjacent if and only if sets have some element in common.

Suppose there is subset S of L such that |N(S)| < |S| (we are supposing that Hall’s assumption does not hold). Because all element of N(S) and S are different (intersection of cosets are either the whole set or empty) then |union N(S)| = |H| |N(S)| and |union S| = |H| |S| this implies that |union N(S)| < |union S| but this is not true because each element of union S is covered by some coset in N(S) so |S| <= |N(S)| for each S subset of L.

Now from Hall’s Marriage Theorem, there is a perfect matching. So we form the set T in this way: Add exactly one element from the intersection of cosets in each edge of the matching. And the result follows.

What is BDD?

Behaviour-Driven Development (BDD) is Agile software development, in which the participants are developers, testers, and clients(stakeholders). The main goals of BDD are to establish an easy way to communicate the idea to others and avoiding miscommunication between clients and the app developers, to do so everyone writes different stories on how should the app react in different scenarios and this would define what needs to be done for the client to find the application acceptable.

Cucumber

Cucumber is a software tool that supports BDD. It helps facilitate the discovery and use of a ubiquitous language within the team, by giving the two sides of the linguistic divide a place where they can meet. Working together to write tests not only creates a path for what should be implemented next but also describes the behavior of the application which can seem like living documentation.

Let’s build a calculator

Our client wants to build a calculator, and the first thing that comes to mind is the addition. The language in which we write BDD scenarios is called Gherkin. This is not a post about how to write Gherkin and in a way, this shouldn’t, everyone should be able to read and write tests easily, it is good especially for the developer side because they are speaking client language. Consider the following:

Scenario: Add two numbers
Given the input "2+2"
When the calculator is run 
Then the output should be "4"

It is clear what the calculator app is supposed to do. That is what the work of clients, testers, and developers should produce. With the help of cucumber, the testers should write the test to check if each step(line in the scenario), and after that, the developer should write the minimal code that passes this test. The developer here can do as little as just for any input, output 4 and the test is going to pass. That’s why everyone should think of edge cases of how should the app behave in different cases.

When Cucumbers go bad

Cucumber should be all about better workflow, cleaner code, good communication, etc. But it can be when Cucumber can go bad. Some of the most common problems are flickering scenarios, slow features, bored stakeholders. Flickering scenarios can be caught when your test fail randomly. I remember when using Cucumber in the beginning and re-running godog command would pass after failing, it was so hard to debug it. Usually, those flickering scenario happens race conditions, environment, etc. Slow features happen when testing some scenario takes minutes and it’s just frustrating to test, I had once some testing which took 10 minutes and it was a good reason for me to skip the test, which is definitely when cucumbers go bad. Bored Stakeholders is when the stakeholders(clients) don’t collaborate anymore in the reading or writing features, but then there is no much point in using it.

Tips

• Scenarios should be independent from each other.
• When dealing with asynchronous systems listen for events broadcast by the system or repeatedly poll the system. But don’t just sleep.
• If you use a database, then you have to make sure each scenario starts with a clean slate.
• When testing a REST web service with Cucumber, it’s generally preferable to run Cucumber in the same process as your application.
• In legacy application, use characterization tests to help you understand what the system is already doing and to give you some security before you make a change.