Przejdź do głównej zawartości

Barbarians will take it all

A barbarian is a human who is perceived to be uncivilized (...)

(...) Barbarian Invasions, was a period of intensified human migration in Europe, often defined from the period when it seriously impacted the Roman world.

We (professional software developers) are the Roman world. You who read this post, are most likely part of the Roman world.

Who are barbarians? Barbarians are all of those people who do not have the background (both in terms of education and experience) that the Roman world perceives as necessary to do a job in software development field.

Barbarians have lower expectations when it comes to salary, office and tools standard, fancy titles, etc.

They use a lot of stuff invented by the "real" developers so far. They may not have profound understanding of how this stuff works in details, but they are very skillful in using it for specific purposes. More often than not, Barbarians do not build excellent, fault tolerant software, but rather software that is good enough. And their customers are happy with that which is good enough.

Barbarians have a very strong drive for getting things done and strong focus on work. They are very often able to complete an assigned piece of work much quicker than the Romans.

The Romans detest everything the Barbarians develop, even the greatest products that some of the Romans would not be able to do themselves. At the same time, Barbarians admire many of the works of the Romans.

How did it start? I think some smart folks just figured out that creating a small nice web service is not that hard. Then, they learned how to do some fancy scripting on a web site. Then, they figured out how to do things on the server side. Next, they realized they have skills to do similar things when it comes to a standalone application or a different application server, etc. They got better and better at it. And they do not need all the overheads that the Romans do: they do not need architects or analysts to do their job. They just go ahead and do it. Would you hire them for a project? I would certainly do. NASA wouldn't. But NASA can afford to hire the Romans.

I am with the Barbarians. I think they will take most of the IT marketshare within the next 10+ years. I don't think this is anything bad. This is just a bucket of cold water to those that are too nosy.


Popularne posty z tego bloga

Unit Testing code with IO file operations (in Python)

We may often come across a piece of code that was written without Unit Tests at all. In addition, the piece of code may be dealing with IO like file writing and reading, which makes it more difficult to Unit Test it when we are trying to refactor and modify. Let's suppose the code in question looks like this:

def writeInitialsToFile(filename, name, surname):
    initials = name[0] + '.' + surname[0] + '.'
    with open(filename, 'w') as file:

def readInitials(filename):
    initials = None
    with open(filename, 'r') as file:
        initials = file.readline()
    return initials

A straightforward and bad idea would be to write a couple of Unit Tests that make use of a real file and simply test the reading and writing. Is therea a better way to test this code?

First of all, we need a way to replace the real file with something else. For both reading and writing we will now have a couple of functions, one that expects a stream fo…

Piotr's Less Obvious Advice on Google Mock: State maintenance

Google Mock provides several ways to maintain state inside mock objects. One way of implementing state maintenance is with SaveArg. Consider the following example.

We have a class Configurator, which allows a caller to set and get values of a parameter:

class Configurator

    virtual ~Configurator() {}

    virtual void setParamX(int n) = 0;
    virtual int getParamX() = 0;

And we have a class Client that calls Configurator's methods and it also has a method incParamXBy, that can be used to increase the current value of paramX by a certain value.

class Client

    Client(Configurator & cfg);
    virtual ~Client() {}

    void setParamX(int n);
    void incParamXBy(int n);
    int getParamX();


    Configurator & _cfg;

incParamXBy internally calls setParamX and getParamX on Configurator:

void Client::incParamXBy(int n)
    _cfg.setParamX(_cfg.getParamX() + n);

Let's assume that the initial value of paramX is A and that we want to increase paramX by…

Piotr's Less Obvious Advice on Google Mock: Returning new objects from a mock

Google Mock provides a way to return newly created objects from a mock method. Suppose we have a  Generator class that is supposed to generate new objects when createNewRecord method is called:

class Generator
    virtual ~Generator() {}
    virtual Record * createNewRecord() = 0;

...and suppose we want to mock this class:

class MockGenerator : public Generator
    MOCK_METHOD0(createNewRecord, Record * ());

Suppose the caller class Client has run method defined as follows:

void Client::run()
    for(int i = 0; i < 3; i++)
        rec_tab[i] = gen.createNewRecord();

We want the mock to return a pointer to a new object each time createNewRecord is called. This is how we can express this in the test code:

TEST(ClientTest, CanRun)
    MockGenerator gen;
    Client c(gen);

    EXPECT_CALL(gen, createNewRecord())
                 //this is equivalent of returning new Record(1,2,3)