What I'm going to do here is show the complete code of, at a first glance, a very simple component - a text box character counter.

Co tu udělám je, že předvedu kód na první pohled velice jednoduché komponenty - počítadla napsaných znaků.

I'll show both the simple version and my version made into a reusable component.

Ukáži jak jednoduchou variantu, tak mou verzi naprogramovanou jako opakovatelně využitelnou komponentu.

I will be targeting any explanations mostly at lay people. I will show the complete code, but it is not important to understand the code itself at all. What I want to offer here is a comparison of the amount of effort needed between doing something very simply and making the same thing nice, reusable and intelligent.

Má vysvětlení budu pak směřovat na naprosé lajky, takže mému vyvětlení by měl rozumět každý. Nejde tu o to porozumět kódu, ale o získání představy o programování jako lidské činnosti obecně. Ukáži zde kompletní kód, ale není vůbec důležité mu rozumět. O to tu nejde. Co zde chci nabídnout je srovnání množství vyžadovaného úsilí potřebného mezi programováním čehosi co možná nejjednodušeji a toho samého tak, aby to vypadalo hezky a bylo to jednoduše využitelné znovu a znovu v dalších programech jako komponenta.

I will also show how the component looks, animate it to show its function and allow the user to interact with it as well, to appreciate the difference.

Také předvedu, jak moje komponenta vypadá, zanimuji jí, abych ukázal jak funguje a umožním vaší interakci s ní, abyste mohli ocenit ten rozdíl.

And yes, if you are a programmer and have a use case for this component, by all means go ahead and use my code.

A ano, pokud jsi sám/sama programátor(ka) a máš pro mou komponentu využití, klidně můj kód použij.

If you manage to read the article in its entirety, you will learn how easy some things can be to program but also how complicated the same things can get.

Když se vám podaří přečíst tento článek do jeho konce, uvidíte, jak jednoduché může být některé věci naprogramovat, ale také jak komplikovanými se ty samé věci mohou velice rychle stát, pokud chceme, aby se chovali a vypadali lépe.

Finally, I'd be happy if anyone - programmers or lay people - leave me a comment.

Nakonec, budu velice rád pokud mi kdokoliv z vás - jak programátoři tak lajci - zanecháte váš komentář.

The goal for our article's example is to add a visible character counter after a multi-line text box to show the user both the maximum number of characters allowed and the currently entered number of characters. Something like this:

Cílem v tomto článku bude ukázat na konkrétním příkladu, jak se věci programují. Budeme tu řešit přidání viditelného počítadla znaků za multi-řádkové textové pole, kde toto počítadlo slouží jako vizuální zpětná vazba pro uživatele k tomu, aby viděl, kolik znaků je celkem v daném poli povoleno a kolik už jich napsal. Něco jako toto:

For the start I disabled the field, until we have talked about the code that will make it interactive.

Pro začátek jsem tomuto poli zakázal interaktivitu, dokud nebudeme hovořit o kódu, který mu umožní mít zamýšlené chování.

You've seen it on every second website you've ever encountered, right? If there is a form with a multi-line textbox into which you are supposed to type your message, comments, suggestions etc. they usually, if they have the number of total characters you can enter limited, put a character counter below or above the box to let you know how close you are to the limit. At least any SEMI-DECENT website has this feature on their limited multi-line text boxes. In its simplest form this takes a programmer just a few minutes to write.

Podobné textové pole vídáte na každých druhých webstránkách na které jste kdy zabrouzdali. Jestliže na nich narazíte na formulář, který obsahuje multi-řádkové textové pole do kterého se očekává, že napíšete například svou správu pro danou firmu, komentář, doporučení atd., pak obyčejně takové počítadlo u takového pole mají, pokud mají omezenou maximální délku textu, který od nás uživatelů akceptují. To abyste věděli, pokud se budete blížit k tomuto jejich limitu a že takový limit vůbec existuje. Tuto "slušnost" vůči uživateli neposkytují úplně všichni, ale každá POŘÁDNÉJŠÍ firma ano. Ve své nejjednodušší formě trvá programátorovi něco takového napsat jen pár minut.

function Sanitize(text) {
    var forbiddenChars = ["'", "<", ">", "=", "*"],
        len = forbiddenChars.length,
        char;
    for (var i = 0; i < len; i++) {
        char = forbiddenChars[i];
        text = text.replace(char, "&" + char.charCodeAt(0) + ";")
    }
    return text;
}

function s(t){var f=["'","<",">","=","*"],l=f.length,c,i=0;for(i;i<l;i++){
c=f[i];t=t.replace(c,"&"+c.charCodeAt(0)+";")}return t;}

text = Sanitize(text);

<textarea id="userFeedback"></textarea>

<textarea id="userFeedback" maxlength="300"></textarea>

Again, you don't have to understand the following code at all. Just look at how long (or short) it is.

Zde znovu podotýkám, že nemusíte rozumět samotnému následujícímu kódu. Jen si všiměte, jak je krátký.

<textarea id="feedback" maxlength="500" onkeyup="Count(this)"></textarea>
<div class="counter"></div>

function Count(el) {
    $(el).next(".counter").text(el.value.length + " / " + el.maxlength);
}

And that my lady or sir is (almost) the smallest amount of code needed to solve the two related problems of:

A to, má milá dámo nebo pane je (téměř) nejmenší množství kódu potřebného k vyřesení těch dvou propojených problémů:

1. Limiting user input in a text box to a maximum number of characters.
2. And helping the user to know at the same time what the maximum is and how many characters they've written so far.

1. Omezení maximálního množství znaků, které je možné napsat do textového pole formuláře.
2. A zároveň pomoc uživateli tím, že mu dáme vědět, jaké to maximum je a kolik znaků dosud napsal.

Programming is easy and fast right? Well, hold your horses for a second...

Programování je jednoduché a ryhlé, že? No pozor, držte své koně na uzdě...

Even the above would need to have some associated styling* information so that it is positioned nicely and logically on the page and looks all right.

I tyto výše uvedené příklady by v reálném světě potřebovali související formátovací informace zvané "styly*", aby byly na stránce umístěny logicky a přehledně a vypadali, jako že tam patří.

Also, the code above does not solve all the possible interactions with the textbox and will not update the counter under all circumstances, so more code may need to be written even here. But it solves about a 99% big chunk of the desired basic behaviour.

Navíc ten kód výše neřeší všechny možné způsoby interakce s tím textovým polem and nebude aktualizovat to počítadlo za všech podmínek, takže i v tomto případě by bylo ve skutečnosti potřeba napsat o něco více kódu. Ale ten kód výše řeší zhruba 99% podíl požadovaného chování. Často právě to jedno zbývající procento zabere více času, než ta hlavní část.

* Styling is information about how a component should look visually on the page, how it should be positioned, how it should visually react to events like being clicked and thus receiving the active blinking cursor and many others as needed. An example for our text field and counter would look something like this:

* Styly jsou informace pro počítač o tom, jak má komponent vypadat vizuálně na stránce, kde má být umístěn, jak by měl vizuálně reagovat na události jako je kliknutí a tím obdržení tzv. "fokusu", kdy se daný prvek stává tím aktivním, zvoleným na stránce a třeba v případě textových polí v něm začne blikat kurzor. Styly dále definují mnohé další vizuální definice podle potřeby. Příklad pro naše textové pole a počítadlo znaků by vypadal nějak takto:

<style>
    textarea, input[type=text] {
        margin-top: 9px;
        background: #cfe8de;
        color: black;
        border: solid 2px #2b2d43;
        border-radius: 6px;
        display: block;
        width: 100%;
        padding: 10px 15px;
        font-size: 14px;
        line-height: 1.42857143;
        box-shadow: 5px 5px 9px 0 rgba(56, 51, 51, 0.5);
    }
    textarea:focus, input:focus {
        background: #d5e8cf;
        border:solid 3px rgb(89, 187, 69);
    }
    #feedback {
        height: 80px;
    }
    .counter {
        text-align: right;
        font-size: 0.8em;
        font-weight: bold;
    }
</style>

And again, it could be (and usually is) a bit longer than that to also describe how the look changes not only when the box is focussed (that is when it is the active element in which the cursor is blinking) as done above in line number 20, but also when the mouse hovers over it, when it is active (which is similar to focus but yet happens under different conditions) etc.

A znovu, mohlo by tohle být (a většinou také je) trošku delší než náš příklad aby to pole vědělo, jak má vypadat ne pouze když má fokus, tak jak je to definováno výše v řádku 20, ale také když se nad tím polem objeví kurzor myši, když je to pole aktiví (což je podobné fokusu, ale stává se za rozdílných podmínek) atd.

The funny thing is that often, to also handle those less likely but possible types of user interaction and events happening on the page such a textbox is on - that is the remaining 1% of possible types of interactions - the programmer ends up having to write significantly more additional code than it is in the above example. Just how much that can easily be you'll see shortly in "The more complete solution".

Vtipné je, že často k tomu, abychom obsloužili tyto méně časté ale možné typy iterakce uživatelů a událostí stávajících se na stránce, na které se takové textové pole nachází - tedy to zbývající 1% možných typů interakcí - musí programátor napsat podstatně více přídavného kódu než je uvedeno v příkladu výše. O kolik více to klidně může být uvidíte za krátko pod hlavičkou "Kompletnější řešení".

But first, here is the result of the above code.

Ale ze všeho nejdříve, zde je výsledek toho kódu výše.

The following solution for the same problem as solved by the "Simple solution" will be more complicated. In fact, it will be vastly more complicated. But it will also be vastly more capable and "complete". It is done in a way to make a reusable component from the defined behaviours and visual presentation. This component accepts parameters to very easily define both its behaviour and visual presentation.

Následující řešení stejného problému, jaký byl vyřešen v sekci "To nejjednodušší řešení" bude komplikovanější. Tedy ve skutečnosti bude propastně více komplikované. Ale také bude zároveň propastně více schopné reagovat jednoduše na komplexní požadavky jeho chování a bude tím značně "kompletnější". Toto řešení vyúsťuje v komponentu, která je jednoduše využitelná kdekoliv jinde nejen v mé, ale jakékoliv jiné aplikaci. Komponenty se pak vyznačují tím, že jak jejich chování, tak vizuální prezentace jsou jednoduše nastavitelné.

When you click the below title you'll be shown the complete code. As I pointed out before twice already, you do not need to understand it. Just look at its size compared to the simple solution to the same problem, which had in total 32 lines of code.

Až kliknete na titulek níže, odhalí se vám kompletní kód této mnou naprogramované komponenty. Jak jsem předeslal už dvakrát v dřívějším textu, nemusíte tomu kódu rozumět. Jen koukněte na jeho množství a porovnejte ho s tím jednoduchým řešením stejného problému výše, které mělo všeho všudy 32 řádků kódu.

A spoiler: this one has 577 lines of code.

Prozradím předem, že toto řešení má 577 řádků kódu!

(function (win) {
    function Dummy() { }

    var m_oCallbacks = {
        countChanged: Dummy,
        stateChanged: Dummy,
        shown: Dummy,
        basic: Dummy,
        highlighted: Dummy,
        warn: Dummy,
        max: Dummy,
        exceeded: Dummy
    },
        m_oPrevData = {},
        _;

    win.CharCounter = _ = {
        /**
            * This initializes the component, either binding all text boxes and text areas with a class of "counter" directly to each such element's event handlers OR INSTEAD using a global event handler registration function which causes any text box or textarea element that has the "counter" class to be called.
            * @param {any} globalEventHandlerRegistrationFunction An optional global event registration function, if you have one, with a signature of (eventType, handlerFunction, elementClass) (where elementClass is the class a component must have if the handler is to be called for it) and which calls the handlers with (event) as the signature.
            * @param {any} eventCallbacks An optional object containing one or more of the following properties: {
            *      countChanged (el, data)
            *      stateChanged (el, data)
            *      shown (el, data)
            *      basic (el, data) // Basic (non-highlighted) version of the counter is shown or hidden.
            *      highlighted (el, data)
            *      warn (el, data)
            *      max (el, data)
            *      exceeded (el, data)
            *    }
            *    where those should contain callback functions the user of the component wants to be called when.. characterCount is changed, or counter is shown, highlighted, changes to warn or max states or when the count is exceeded.
            */
        Init: function (globalEventHandlerRegistrationFunction, eventCallbacks) {
            if (globalEventHandlerRegistrationFunction) {
                var cls = "counter";
                globalEventHandlerRegistrationFunction("keyup", onKeyUp, cls);
                globalEventHandlerRegistrationFunction("focusin", onFocusIn, cls);
                globalEventHandlerRegistrationFunction("focusout", onFocusOut, cls);
            } else {
                $("input.counter")
                    .not(".counter-init")
                    .addClass("counter-init")
                    .keyup(ShowCounter)
                    .focus(ReShowCounter)
                    .blur(HideCounter);
                $("textarea.counter")
                    .not(".counter-init")
                    .addClass("counter-init")
                    .keyup(ShowCounter)
                    .focus(ReShowCounter)
                    .blur(HideCounter);
            }

            AssignCallbacks(eventCallbacks);
        },

        StateEnum: {
            notInitialized: 0,
            notShown: 1,
            basic: 2,
            highlighted: 3,
            warn: 4,
            max: 5,
            exceeded: 6
        },

        AssignEventCallback: function (eventName, callbackFunction) {
            if (eventName) {
                var obj = {};
                obj[eventName] = callbackFunction;
                AssignEventCallbacks(obj);
            }
        },

        Refresh: function (element) {
            if (typeof element == "string" && element.length && element.substr(0, 1) != "#")
                element = "#" + element;
            element = $(element || $("body"));
            var tag = element[0].tagName.toUpperCase(),
                list;

            if (((tag == "INPUT" && element.attr("type") == "text") || tag == "TEXTAREA") && element.hasClass("counter"))
                list = [element];
            else
                list = element.find("input[type=text].counter,textarea.counter");

            if (list.length) {
                $.each(list, function () {
                    var el = $(this);
                    ShowCounter(el);
                    if (!el.is(":focus"))
                        HideCounter(el, true);
                });
            }
        }
    };

    $.fn.extend({
        hasClasses: function (selectors) {
            var self = this;
            for (var i in selectors) {
                if ($(self).hasClass(selectors[i]))
                    return true;
            }
            return false;
        }
    });

    function onKeyUp(ev, el, id, tgt) {
        ShowCounter(el);
    }

    function onFocusIn(ev, el, id, tgt) {
        ReShowCounter(el);
    }

    function onFocusOut(ev, el, id, tgt) {
        HideCounter(el);
    }

    function AssignCallbacks(defObj) {
        if (defObj) {
            var obj = m_oCallbacks,
                p;
            for (p in defObj) {
                if (typeof obj[p] == "function")
                    obj[p] = defObj[p] || Dummy;
            }
        }
    }

    function HideCounter(el, skipEvent) {
        var data = el.data("counter-data"),
            cbk;
        if (data && data.isShown && (
            (!data.isTextArea && !el.hasClass("counter-keep-on-blur"))) ||
            (data.isTextArea && el.hasClass("counter-hide-on-blur"))) {
            el.css("padding-right", data.origPadding);
            el.next().hide();
            data.hidden = true;
            cbk = m_oCallbacks;
            if (cbk.shown && !skipEvent)
                cbk.shown(el, data);
        }
    }

    function ReShowCounter(el) {
        var data = el.data("counter-data"),
            counter = el.next(),
            cbk;
        if (data) {
            ShowCounter(el);
            el.css("padding-right", data.padding);
            if (counter.length)
                counter[0].style.removeProperty("display");
            data.hidden = false;
            if (data.isShown && (!data.isTextArea || el.hasClass("counter-hide-on-blur"))) {
                cbk = m_oCallbacks;
                if (cbk.shown)
                    cbk.shown(el, data);
            }
        }
    }

    function ShowCounter(el) {
        var counter = el.next(),
            origData = el.data("counter-data"),
            prev = PrevData(origData),
            data = CharThresholds(el, origData),
            count,
            divs,
            parent;

        if (!counter.length) {
            parent = el.parent();
            if (parent.css("position") == "static")
                parent.css("position", "relative");
            counter = $("
" + data.maxAt + "
");
            if (data.isTextArea)
                counter.addClass("counter-area");
            el.after(counter);
            count = counter.find(">div");
            divs = count.find("div");
            if (!data.isTextArea && el.hasClass("counter-vertical")) {
                counter.addClass("counter-vertical");
                divs.css("display", "block");
            } else {
                divs.css("display", "inline-block");
            }
        } else {
            count = counter.find(">div");
            divs = count.find("div");
        }

        var v = el.val(),
            len = v.length,
            hasMax = data.maxAt != 0,
            hasWarn = data.warnAt > -1,
            hasHl = data.highlightAt > -1,
            hasBasic = data.basicAt > -1,
            add = data.stopAtMax ? 0 : 1,
            showMax = hasMax && len >= (data.maxAt + add),
            showWarn = !showMax && hasWarn && len < (data.maxAt + add) && len >= data.warnAt,
            showHl = !showMax && !showWarn && hasHl && ((hasWarn && len < data.warnAt) || (!hasWarn && hasMax && len < (data.maxAt + add))) && len >= data.highlightAt,
            showBasic = !showMax && !showWarn && !showHl && hasBasic && ((hasHl && len < data.highlightAt) || (!hasHl && hasWarn && len < data.warnAt) || (!hasHl && !hasWarn && hasMax && len < (data.maxAt + add))) && len >= data.basicAt,
            classes = [data.basicClass, data.hlClass, data.warnClass, data.maxClass],
            wasShown = counter.hasClasses(classes),
            showAny = showBasic || showHl || showWarn || showMax,
            visibilityChange = showAny != wasShown,
            states = _.StateEnum,
            state;

        if (data.remainingCount < 0)
            state = states.exceeded;
        else if (showMax)
            state = states.max;
        else if (showWarn)
            state = states.warn;
        else if (showHl)
            state = states.highlighted;
        else if (showBasic)
            state = states.basic;
        else
            state = states.notShown;

        data.curState = state;

        if (!data.maxAt || data.maxAt < 0)
            return; // Do not show the counter as the required max length has net been defined.

        data.isShown = showAny;
        data.isBasic = showBasic;
        data.isHighlighted = showHl;
        data.isWarn = showWarn;
        data.isMax = showMax;

        data.prevCount = prev.count;
        data.prevRemainingCount = prev.remaining;
        data.prevState = prev.state;

        ExecuteCallbacks(el, prev, data, showAny, showBasic, showHl, showWarn, showMax);

        divs.eq(0).text(data.curCount);

        if (!data.isTextArea || !visibilityChange || showAny) {
            if (data.isTextArea && showAny)
                counter.slideDown();

            counter
                .toggleClass(data.maxClass, showMax)
                .toggleClass(data.warnClass, showWarn)
                .toggleClass(data.hlClass, showHl)
                .toggleClass(data.basicClass, showBasic);
        }

        if (data.isTextArea) {
            if (wasShown != showAny) {
                if (showAny)
                    counter.hide().slideDown();
                else
                    counter.slideUp(function () {
                        counter.removeClass(classes);
                    });
            }
        }

        if (!data.isTextArea) {
            data.padding = counter.width() + 20;
            el.css("padding-right", data.padding);
        }
    }

    function CharThresholds(el, data) {
        var len = el.val().length;
        if (!data) {
            var def = el.data("counter-def"),
                vals,
                max = el.attr("maxlength"),
                isTextArea = el[0].nodeName.toUpperCase() == "TEXTAREA";
            if (max)
                max *= 1;

            if (def)
                vals = def.split(",");
            else
                vals = [];

            data = {
                id: el.attr("id"),
                basicAt: CalcThreshold(max, vals, 0, isTextArea ? "50%" : "x"),
                highlightAt: CalcThreshold(max, vals, 1, "80%"),
                warnAt: CalcThreshold(max, vals, 2, isTextArea ? "90%" : -5),
                maxAt: CalcThreshold(max, vals, 3, max),
                stopAtMax: max || (vals && vals.length && vals.length > 3 && vals[3] && vals[3] > 0),
                basicClass: CounterClass(vals, 4, "counter-basic"),
                hlClass: CounterClass(vals, 5, "counter-hl"),
                warnClass: CounterClass(vals, 6, "counter-warn"),
                maxClass: CounterClass(vals, 7, "counter-max"),
                isTextArea: isTextArea,
                origPadding: el.css("padding-right"),
                prevCount: -1,
                prevRemainingCount: 0,
                remainingCount: 0,
                prevState: _.StateEnum.notInitialized,
                curState: _.StateEnum.notInitialized,
                isShown: false,
                isBasic: false,
                isHighlighted: false,
                isWarn: false,
                isMax: false
            };

            el.data("counter-data", data);

            if (data.stopAtMax)
                el.attr("maxlength", data.maxAt);
        }

        // The following check is here for when the box is filled programmatically, which ignores the "maxlength" setting.
        if (data.maxAt > 0 && len > data.maxAt && data.stopAtMax) {
            len = data.maxAt;
            el.val(el.val().substr(0, len));
        }

        data.curCount = len;
        data.remainingCount = data.maxAt - len;
        data.isExceeded = data.remainingCount >= 0;
        return data;
    }

    function CounterClass(vals, idx, defaultVal) {
        return vals && vals.length > idx && vals[idx].trim().length ? vals[idx].trim() : defaultVal;
    }

    function CalcThreshold(max, vals, idx, defaultVal) {
        if (!vals)
            return (defaultVal * 1) || -1;
        else {
            if (vals.length < (idx + 1) || !vals[idx].length)
                vals[idx] = defaultVal + "";

            var val = vals[idx].trim(),
                neg = false,
                m = max || Math.abs(!isNaN(vals[3]) ? vals[3] * 1 : 0);

            if (val.substr(0, 1) == "-") {
                neg = true;
                val = val.substr(1);
            }
            if (val.substr(val.length - 1) == "%") {
                val = val.substr(0, val.length - 1);

                if (isNaN(val))
                    return -1;

                if (m > 0) {
                    val = Math.round(m * (val / 100));
                } else {
                    return -1;
                }
            }
            if (isNaN(val))
                return -1;

            if (neg && idx < 3) { // idx == 0 means that val is the max value which, if negative, just means that it is a hard stop and we still return the absolute value of
                if (m > 0)
                    return m - val;
                else
                    return -1;
            } else
                return val * 1;
        }
    }

    function PrevData(data) {
        var prev = m_oPrevData;

        if (data) {
            prev.count = data.curCount;
            prev.remaining = data.remainingCount;
            prev.state = data.curState;
            prev.shown = data.isShown;
            prev.basic = data.isBasic;
            prev.hl = data.isHighlighted;
            prev.warn = data.isWarn;
            prev.max = data.isMax;
            prev.exceeded = data.isExceeded;
        } else {
            prev.count = -1;
            prev.remaining = -1;
            prev.state = _.StateEnum.notInitialized;
            prev.shown = false;
            prev.basic = false;
            prev.hl = false;
            prev.warn = false;
            prev.max = false;
            prev.exceeded = false;
        }

        return prev;
    }

    function ExecuteCallbacks(el, prev, cur, showAny, showBasic, showHl, showWarn, showMax) {
        var cbk = m_oCallbacks,
            count = prev.count != cur.curCount,
            state = prev.state != cur.curState,
            shown = showAny != (prev.basic || prev.hl || prev.warn || prev.max),
            basic = prev.basic != showBasic,
            hl = prev.hl != showHl,
            warn = prev.warn != showWarn,
            max = prev.max != showMax,
            exceeded = prev.exceeded != cur.isExceeded;

        if (count)
            cbk.countChanged(el, cur);
        if (state)
            cbk.stateChanged(el, cur);
        if (shown)
            cbk.shown(el, cur);
        if (basic)
            cbk.basic(el, cur);
        if (hl)
            cbk.highlighted(el, cur);
        if (warn)
            cbk.warn(el, cur);
        if (max)
            cbk.warn(el, cur);
        if (exceeded)
            cbk.exceeded(el, cur);
    }
})(window);
    

.counter-container {
    &::after {
        content: "";
        clear: both;
        display: table;
    }
}

div.counter {
    background: transparent;
    border-top-right-radius: 3px;
    border-bottom-right-radius: 3px;
    position: absolute;
    padding: 5px;
    top: 2px;
    bottom: 2px;
    right: 2px;
    font-size: 0.7em;
    font-family: "Courier New", Courier, monospace;
    display: none;
    align-items: center;
    justify-content: center;

    > div {
        > div {
            &:nth-child(2) {
                /* To display a slash as the divider. */
                &::before {
                    content: "/";
                }
            }
        }
    }

    &.counter-basic,
    &.counter-hl,
    &.counter-warn,
    &.counter-max {
        display: flex;
        transition: background-color 100ms ease-in, color 50ms ease-in 50ms;
    }

    &.counter-area {
        position: relative;
        float: left;
        justify-content: flex-end;
        align-items: center;
        border-top-right-radius: 0px;
        border-top-left-radius: 0px;
        border-bottom-left-radius: 3px;
        border-bottom-right-radius: 3px;
        padding: 1px 5px;
        top: -2px;
        right: inherit;
        left: 2px;
        box-shadow: inset 2px 9px 4px -7px rgba(0,0,0,0.2);

        &.counter-basic,
        &.counter-hl,
        &.counter-warn,
        &.counter-max {
            transition: background-color 900ms ease-in, color 200ms ease-in 200ms;
        }
    
        > div {
            > div {
                &:nth-child(1) {
                    /* To display a slash as the divider. */
                    &::before {
                        content: "Typed ";
                        padding-right: 0.5em;
                    }
                }

                &:nth-child(2) {
                    /* To display a slash as the divider. */
                    &::before {
                        content: "of max.";
                        padding: 0 0.5em;
                    }
                }

                &:nth-child(3) {
                    /* To display text after max. */
                    &::after {
                        content: "characters.";
                        padding-left: 0.5em;
                    }
                }
            }
        }
    }

    &.counter-vertical {
        > div {
            > div {
                width: 100%;
                text-align: right;

                &:nth-child(2) {
                    /* To display a vertical divider */
                    width: 100%;
                    margin: 0 auto;
                    border-top: solid 1px;
                    margin-bottom: 1px;

                    /* To display a slash as the divider. */
                    &::before {
                        content: "";
                    }
                }
            }
        }
    }

    &.counter-basic {
        background: transparent;
        color: #999;
    }

    &.counter-area {
        &.counter-basic {
            background: white;
            color: inherit;
        }
    }

    &.counter-eager {
        background: lightskyblue;
    }

    &.counter-hl {
        background: yellow;
    }

    &.counter-warn {
        background: #ffa443;
        //color:white;
    }

    &.counter-max {
        background: rgb(253, 21, 21);
        color: white;
        transition: background-color 0ms ease-in, color 0ms ease-in 0ms
    }
}

So that is 18 times more code than then the previous solution with just 32 lines!

Tak to je 18 krát více kódu, než toho v předchozím řešení s pouhými 32 řádky!

Why write so much code if the simple solution was kind of fine? Well, simply, because we want to build better products for our users. We want to sell these products so they must be capable of solving the user's problems and possibly not be annoying while doing it. It also helps, of course, if on top of being helpful and not annoying they also are actually pretty. People like pretty. That's the only purpose of jewelry for example and also the main one behind the fashion industry.

Proč psát o tolik více kódu když to jednoduché řešení bylo celkem dobré? No jednoduše řečeno, protože chceme vytvářet lepší produkty pro naše uživatele. Chceme naše produkty prodávat, takže musí být schopné řešit uživatelovi problémy a pokud možno nebýt u toho iritující. Také samozřejmě pomáhá, když navrch k tomu, že náš produkt uživateli s něčím pomáhá a neirituje, je navíc hezký na pohled. Lidé mají rádi hezké věci. To je jediný důvod, proč se například prodávají šperky a hlavní důvod stojící za celým módním průmyslem. To samé tedy platí i pro softwér.

We also do it because it is the right thing to do. We could write the same few lines of code as in the simple example every time we put a text box on a page. Yes we could. Or we can write something that behaves as a complete component, gives us all the necessary options and offers us different looks automatically so that the next time we need it on a page we just tell the textbox to simply display a counter in this case and tell it very simply how and when to display it and possibly what events to announce to the other elements on the page so that they can react to those events.

Také to děláme protože je to tak správné. Mohli bychom psát stejných pár řádků kódu jako v našem jednoduchém případě vždy, když potřebujeme zobrazit počítadlo znaků. Ano, mohli bychom. Ale také můžeme napsat jednou jedinkrát něco, co se chová jako kompletní komponenta, která nám dává veškerá možná požadovaná chování a vzhledy automaticky, takže až budeme příště potřebovat zobrazit počítadlo znaků, které, když budeme potřebovat, se navíc může chovat a vypadat dle přání, kdy se tato nadefinují jednoduchými parametry, už ho máme a můžeme ho využít znovu a znovu a znovu, s nutností pouze sdělit přídavným parametrem danému textovému poli, že chceme, aby navíc zobrazovalo počítadlo a taky kdy a jak. To vše jen přidáním v tomto případě většinou jediného parametru!

Navíc, tato komponenta umí ohlašovat jakýmkoliv jiným komponentám či ostatnímu kódu, když se stanou určité události, jako například "počet znaků v textovém poli dosáhl 80ti procent maxima". A ty ostatní komponenty mohou na takovou událost v daném programu po svém nějak reagovat. To všechno umí tato komponenta díky tomu množství kódu, který byl potřeba k jejímu vytvoření.

To demonstrate this, using the advanced code presented above, I can only add a data-counter-def attribute to an existing text box like so:

Pro demonstraci, s využitím toho pokročilého kódu výše, mohu pouze přidat data-counter-def atribut k existujícímu textovému poli takto:

<textarea id="feedback" class="counter" data-counter-def="0,400,-30,500"></textarea>

and it will not only display a much nicer looking counter, but also

a to pole mi nejen zobrazí mnohem hezčeji vypadající počítadlo, ale také

• display 5 different stages of it,
• will hide and show itself when needed,
• will stop the user from typing more than the maximum allowed number of characters (500 here),
• and also announce to the other components on the page when its stages have changed, that the number of characters changed etc. so that they can react to it if and how they need to.
• It will also work automatically if my other code programatically adds any number of new text boxes to the page
• and it is now reusable in any other projects I or others may need a nice and capable counter for.

• zobrazí 5 různých fází,
• skryje samo sebe když je potřeba,
• zastaví uživatele když napíše maximální definované množství znaků (500 v našem příkladě),
• a také oznámí ostatním komponentám v programu, když se jedna fáze změní v druhou, že se změnil počet zadaných znaků atd., takže tento okolní kód může na tyto události reagovat pokud a jak potřebuje
• Také toto bude fungovat automaticky když jiný kód programaticky* přidá jakékoliv množství nových textových polí na stránku
• a je též od teď použitelný v jakýchkoliv dalších projektech, kde já nebo jiní potřebují dobře vypadající a schopné počítadlo znaků.

*Programmatically means, that the program itself will add a beforehand unspecified number of text fields (or other components) as opposed to components directly specified by the programmer in code. In other words, we don't know beforehand how many of those components it will be necessary to display to the user so we write the program in such a way that it dynamically reacts to the needs of the situations and adds necessary components as needed.

*Programaticky znamená, že samotný program přidá dříve programátorem konkrétně nespecifikovaný počet textových polí (nebo jiných komponent) na rozdíl od programátorem přesně v programu předem nadefinovaných komponent. Tedy jinak řečeno, předem dopředu nevíme, kolik daných komponent bude nutné zobrazit a proto napíšeme danou část programu tak, aby je doplňoval automaticky dle potřeby.

All that with less code than presented in the simplest example. In fact, all I needed to do was replace the previously mentioned maxlength='500' attribute in the otherwise already existing textarea component with a data-counter-def='0,400,-30,500' attribute by which I have told it both when to stop the user as well as when to show its different visual stages.

Všechno toto s méně kódem než bylo ukázáno v tom nejjednodušším možném příkladu. Celé, co musím udělat je vyměnit dříve popsaný atribut maxlength='500' v tom jinak již existujícím kódu definujícím textové pole textarea tímto atributem: data-counter-def='0,400,-30,500' kterýmžto jsem tomu textovému poli řekl, že má použít mou komponentu počítadla, kdy má uživatele zastavit a také kdy má uživateli ukázat své jednotlivé fáze. Jak je toto najednou jednoduché a ukrutně schopné zároveň.

<input type="text" class="counter" maxlength="30" />

<input type="text" class="counter" data-counter-def="0,-10,-3,-35,counter-blue" />

<input type="text" class="counter counter-vertical" data-counter-def="1,50%,80%,40" />

<input type="text" class="counter " data-counter-def="1,25,x,50" />

<textarea  class="counter" maxlength="120">

<textarea  class="counter counter-hide-on-blur" data-counter-def="1,20,60%,-120">

So now you can imagine (a little) better what programming is about and that great results cannot be churned out like on a conveyor belt. Every problem is different and the one presented on this page was in fact really quite a simple one. There are hundreds or more likely thousands of problems like this and bigger, much bigger, to solve in a software of any decent size.

Tak a teď si umíte (trochu) lépe představit, o čem programování je a že skvělé výsledky se nedají chrlit jako na běžícím páse. Každý problém je jiný a ten, který jsem prezentoval na této stránce byl ve skutečnosti z těch jednoduchých. V sofwéru jakékoliv solidnější velikosti je k vyřešení takových a mnohem, mnohem složitějších stovky, nebo spíše tisíce.

I'm sure that it is still pretty hard to imagine how code is written, but then just imagine yourself writing it like a book (which I already explained is really NOT like programming at all, but imagine just that).

Jsem si jist že je pro většinu NEprogramátorů pořád docela těžké si představit, jak se píše kód, ale pak si prostě jen představte psát ho jako knihu, což, jak už jsem vysvětlil dříve, tak opravdu NENÍ, ale pro zjednodušení si to tak představte.

And imagine you simply knew what to write in those lines from the top of your head. You would not have to stop and think about it first, you would not have to first imagine the visual layout of things, than maybe design them in a mock-up software and then you would not have to replicate the intended visual look by precisely describing it in code while keeping in mind that many of those visual elements need to be able to resize themselves correctly in harmony with all the other elements on the page etc. You would also not have to first thing about the logic of it, how it should behave by itself, how it should behave in relation to other related data that is being processed and the thinking of the logic would not be stopping you on every n-th line etc. etc.

A představte si, že byste rovnou věděli, co v těch řádcích psát. Nemuseli byste se zastavovat a první o tom přemýšlet, nemuseli byste si první představovat vizuální uspořádání komponent, pak je třeba ještě navrhovat v nějakém návrhovém softwaru a nakonec je replikovat v kódu aby vypadali tak, jak jste je navrhli. Nemuseli byste přemýšlet nad tím, jak se tyto vizuální komponenty musí přizpůsobovat automaticky změnám ve velikosti oken, ve kterých jsou na počítači zobrazeny, nebo různým velikostem displejů, v souhře s ostatními komponenty na dané stránce. Také byste nemuseli první přemýšlet o logice všech těch věcí, jak by se měli chovat vzhledem k ostatním a vzhledem k měnícím se vstupním údajům a přemýšlení o logice celé vaší knihy by vás nezastavovalo na každém n-tém řádku atd.atd.

You would also not have to spend any time debugging what you wrote.

Také byste nemuseli trávit žádný čas "odhmyzováváním" toho, co jste napsali.

You would just write it once and it would just magically work the first time you ran it. Even then you would have to write all that code similar to what was presented earlier times hundreds or thousands or more.

Jen byste to jednou napsali a ono by to zázračně hned fungovalo poprvé, co byste to spustili. I tak byste museli napsat všechen ten kód podobný tomu, co jsem zde prezentoval, krát stovky či tisíce a víc.

Can you imagine? Do you still think that it does not make sense that software development is so slow? And I have not even mentioned everything yet. Read on.

Umíte si to představit? Jste pořád toho názoru, že nedává smysl, že vývoj sofwaru je tak pomalý? A to jsem ještě ani kompletně vše nezmínil. Pokračujte ve čtení.

Even after you've finished coding and debugging your code, you are not done if your code is intended to run in an Internet browser like Firefox, Google Chrome, Edge and others. Nowadays that's most of the software being written. Each one of these browsers is created by a different company and implements certain level of compliance with the continually improving standards for HTML (that is the language that describes the content of any page), CSS (that is the "language" that describes the position and visual appearance of things on the page) and JavaScript (which is the actual programming language thanks to which web pages seem pretty intelligent nowadays). And each of these browsers have many versions with the newer ones being more compliant to the current standards and the older ones, understandably, less compliant.

I poté, co jste zkončili psaní a odhmyzování vašeho kódu, nejste hotovi, pokud váš program má běhat v Internetovém prohlížeči jako je Firefox, Google Chorme, Edge a další. V současnosti to je většina sofwaru, který je vyráběn. Každý jednotlivý z těchto prohlížečů je vytvořen jinou firmou a implementuje různou úroveň dodržovaní dohodnutých a průběžně doplňovaných standardů pro HTML (to je "reč", která popisuje obsah jakékoliv webové stránky), CSS (což je zase "řeč", která popisuje umístění a vizuální prezentaci komponentů na stránce) a JavaScriptu (což je programovací jazyk, díky kterému se jeví současné webové stránky poměrně inteligentní a nejsou jen statické). A každý z těchto prohlížečů má mnoho verzí, kde ty novější dodržují více těchto standardů a starší pochopitelně méně.

The result is that what you just programmed may (and will) look and behave differently in different browsers and different versions of those browsers, all of which being in use by the Internet users of the world. Often, the differences may only be visual and in a way that does not affect usability of the web application. But sometimes even pixel-level (a pixel is one light dot on your screen that, together with millions of its brothers and sister, helps to make up what you see on it) can break the whole layout. It should not, but again, knowing the right way to do things is important here. Often, too, some features are completely broken on some browsers since those may not support an important feature that the developer used in creating his application.

Výsledkem je, že to, co jste právě naprogramovali může (a bude) vypadat a chovat se jinak v rozdílných prohlížečích a v rozdílných verzích těch samých prohlížečů, přičemž všechny ještě stále někde na světě někdo používá. Často jsou ty rozdíly jen vizuální a neovlivňující funkčnost dané aplikace. Ale někdy i rozdíl na úrovni pixelu (pixel je jedna z těch milionů světelných teček, které tvoří obraz na displeji), může rozhodit celé vizuální rozložení aplikace. Nemělo by, ale znovu i zde je důležité vědět, jak dělat věci správně. Často jsou také některé schopnosti kompletně pokažené v určitých prohlížečích, protože ty nemusí všechny podporovat nějakou modernější důležitou funkci, kterou programátor ve svém produktu využil a bez níž jeho aplikace není schopná poskytovat zamýšlené služby.

So now we, additionally, have to test extensively in many different browser / version combinations and try to fix what's broken. That entails programmatically* testing if a particular feature is available in the browser our application is currently running in and if not, either omit the advanced behaviour there, or, if it is vital to the program as a whole, we must come up and code a specific work-around solutions for such cases. These by themselves can be pretty long. As you can probably imagine by now, this can be a very time consuming exercise by its own right as well. We have to deal with visual inconsistencies, behaviour inconsistencies and completely unavailable features in older browsers.

Takže teď navíc musíte ještě testovat velice důkladně vše znovu a znovu v různých prohlížečích a kombinací jejich různých verzí a pokoušet se opravovat nalezené problémy tak, abyste naopak nepokazili něco, co v jiných prohlížečích už dobře funguje. Spravovat takové problémy pak obnáší přidání podmínek do programu, kde musí program testovat, jestli je daná požadovaná funkce vůbec dostupná v prohížeči, kde naše aplikace u uživatele na počítači právě běží a buď v takovém případě skrýt část funkčnosti našeho programu, která využívá té funkce, kterou daný prohlížeč neumí, nenabízí, a nebo musíme vymyslet, jak stejného, nebo alespoň podobného výsledku můžeme v naší aplikaci dosáhnout s tím, co máme ve starším prohlížeči k dispozici. Tyto programové "náhražky" jsou kolikrát mnohem složitější na naprogramování, než naše původní řešení a musí běžet paralelně s ním. A doufám, že si teď umíte představit, že tohle může samo o sobě být hodně časově náročné "cvičení". Musíme se vyrovnávat s vizuálními nesrovnalostmi, s nesrovnalostmi v chování a s kompletně nedostupnými funkcemi starších prohlížečů.

Also, I put an asterisks after the word programmatically. That's because what I'm talking about there is that we must often write in a way of additional code. Completely separate to that, there is "user testing", which involves running the component or the complete program through its paces as its ordinary users will when it is release to them. This different, additional and important kind of testing should be done thoroughly, involving hundreds of different tests (or at least dozens for a simple component) confirming inside a real system that it does what it is designed to do and that it reacts correctly to all the different ways different users can interact with it. User testing itself would warrant its complete separate article on its own and any software company of any decent size has a whole team(s) of people dedicated to just doing that. A lone programmer working on his or her own software has to do that on top of all the already described necessities in this job / science / art.

Také, kromě programatického testování, musíme testovat uživatelsky, tak, jak daný software budou používat obyčejní uživatelé. Tento typ testování je také velice důležitý a měl by být dělán důkladně, což zahrnuje stovky různých testů (nebo minimálně desítky pro jednoduché komponenty), které musí potvrdit uvnitř skutečného systému, že to celé dělá, co to dělat má a že to reaguje správně a předvídatelně na všechny možné způusoby, kterými uživatelé kdy mohou s daným programem interagovat. Uživatelské testování by si zasluhovalo samostatný článek a každá sofwérová firma jekékoli solidnější velikosti má celé týmy lidí určených jen na uživatelské testování. Samotný programátor pracující na jeho vlastním programu to musí dělat navrch všech už zmíněných nezbytností této práce / vědy / umění.

We also have to cater for the many screen sizes that are being used nowadays going from a small mobile phone to large desktop screens. For an application to look right and be user friendly the whole layout as well as some behaviour of the page must change, sometimes drastically. That results in yet more complexity and therefore work for us to create the same thing to behave appropriately on all these screen sizes.

V dnešní době musíme také vytvářet softwér, který vypadá dobře na všech různých velikostech obrazovek a displejů od mobilních po velké desktopové. Aby dnes jakákoliv aplikace vypadala dobře a byla uživatelsky přívětivá, musí umět změnit celé své rozvržení v závislosti na tom, kolik místa na své zobrazení má. Toto rozvržení je nutné v některých případech změnit poměrně drasticky. A to znovu přídává jen další úroveň komplexnosti a tím tedy práce pro nás programátory a softwarové designery.

And we are still not done! Operating an application on a desktop with a mouse actually behaves quite differently when you swap the mouse for your fingers and use a touch screen instead. Suddenly we also have to react differently to figure out if the user wants to scroll, or is pinching to zoom, or is doing a different touch gesture. We receive different events with different values from the system to inform us about what the user is doing in our program and we have to programmatically decide what it means and make it match the same behaviour as if the mouse was used.

A pořád ještě nejsme hotovi! Ovládání operace na desktopu mýší se ve skutečnosti značně liší od chování a ovládání, když je ta myš vyměněna za prsty a dotykový displej. Najdenou musíme reagovat jinak abychom zjistili, jestli uživatel chce posunout obraz, či chce dvěmi prsty zvětšovat či zmenšovat, nebo dělá jiné dotykové gesto. Od systému obdržíme jiné hodnoty a jiné události v závislosti na tom, jak a čím s počítačem uživatel komunikuje. A náš program se musí rozhodnout, co to znamená a musí provést stejné úkony nezávisle na tom, jestli ta komunikace probíhá přes myš a klávesnici, nebo přes dotyk.

So here I should point out that the advanced code for the simple component presented earlier does not even deal with any of these just mentioned issues. That has two reasons:

1. The component itself is not really interactive,
2. and for now I only need to use it in an application that I'm building for other developers who I can just inform to use a particular browser (Google Chrome in this case) if they want to use it. Most of us developers have multiple browsers installed on our machines since we need to test in them, so it should not present a big usability problem for version 1.0 of my application. It is not ideal, but it is a very advanced application whose advanced functionality partly relies on the latest HTML and CSS standards. But it is not ideal nevertheless and later versions will be tested and fixed to run in other browsers as well.
   
   There is just not ever enough time to do everything in version 1 (or 2, or 3 or 4 for that matter) and that si why applications have versions as features and capabilities are added with more development time being able to be invested in them).
   
   Also, by the time the higher versions are to be released, more and more people will be using more and more of the latest browsers whose development teams will have had by then more time to implement more of the latest standards specifications into their browsers themselves. And that will save lots of my development time on this particular piece of software I'm building.
   
   There will of course always be people who are using some very old browser versions and such people will unfortunately have more and more problems using the web as we developers have to set somewhere the limit of how far into the past we want to support our products. We cannot write hundreds of workarounds involving thousands lines of code and making it more complicated just to support the let's say 0.5% of users who still live in the year 2005 as far as their browser version is concerned and take that time from working on new, actually exciting features. IT technology is and has been developing very rapidly and we now have hundreds and hundreds of new features that we can use in our development that we could not use back then. And the further back in time it is the more impossible it is to emulate those new features in old browsers. So we simply must stop supporting the old browsers at some point.

Tak a na tomto místě bych měl zdůraznit, že aní můj pokročílý kód pro to jednoduché počítadlo, který jsem zde prezentoval, se vůbec nezabývá těmi probémy, které jsem právě zmínil. To má dva důvody:

1. Ta komponenta ve skutečnosti nevyžaduje přímo žádnou interaktivitu. Ta je zařízena souvisejícím textovým polem.
2. A pro teď já ji pouze potřebuji použít v aplikaci, kterou programuji pro ostatní programátory, které prostě mohu jen informovat aby používali konkrétní Internetový prohlížeč, pokud jí chtějí používat. Většina programátorů má nainstalovány všemožné prohlížeče, protože jak už jsem napsal, musíme v nich naše produkty testovat. Takže takový požadavek by neměl představovat žádný problém v použitelnosti verze 1.0 mé aplikace. Není to ideální, ale má aplikace je velmi pokročilá a její funkčnost částečně záleží na nejposlednějších standartech HTML a CSS. Nicméně není to ideální a další verze mé aplikace budou testovány a poběží i na jiných prohlížečích.
   
   Prostě člověk nemá nikdy tolik času, aby udělal vše už ve verzi 1 (nebo 2, nebo 3, když už jsme v tom). A proto mají aplikace více verzí tak, jak jsou jednotlivé funkce a schopnosti prostupně přidávány s narůstající dobou, jakou jim můžeme věnovat.
   
   Jistě budou vždy existovat lidé, kteří používají velmi staré prohlížeče a tito lidé budou mít bohužel více a více problémů v používání Internetu, neboť my vývojáři sofwéru musíme někde stanovit limit, jak daleko do minulosti jsme ochotni podporovat naše produkty. Není v našich silách psát stovky a stovky oklik obsahující tísíce řádků kódu, které náš softwér dělají mnohem komplikovanější, než už tak je jen proto, abychom umožnili řekněme půl procentu uživatelů, kteří žijí stále ještě v roce 2005 používat náš softwér. Čas strávený na podpoře starých systémů ubírá z toho, který jinak můžeme věnovat vývoji nových funkcí, které ocení většina uživatelů.
   
   Počítačové technologie se vyvýjejí velmi vysokým tempem a my máme k dispozici stovky a stovky nových funkcí, které můžeme použít k vytváření lepších a lepších vlastních produktů a které jsme neměli k dispozici dříve. A čím dále do minulosti jsme ochotni zajít, tím více nemožné je emulovat tyto nové funkce ve starých prohlížečích. Takže prostě musíme přestat v určitém bodě podporovat zastaralé verze.

So no, I am not lazy or slow. Programming anything meaningful and doing it well simply takes a bloody long time. And the wider audience of users you are making the software for the more time it takes.

Takže ne, nejsem ani líný, ani pomalý. Naprogramovat cokoliv, co má význam a udělat to dobře prostě zabírá zatraceně hodně času. A čím širší obecenstvo uživatelů, pro které se daná aplikace programuje, tím více času to zabere.

But...

Ale...

...Try to explain this to someone who never programmed anything. Even us programmers, we are pretty bad in estimating how long programming a particular feature of any significant complexity will take us.

...Zkuste to vysvětlit někomu, kdo nikdy nic nenaprogramoval. I my, programátoři, jsme poměrně špatní v odhadování toho, jak dlouho bude něco určité solidní komplexnosti trvat udělat.

Actually, it is not necessarily that we are bad in it, but that it is really almost an impossible thing to pull off right most of the time. The times an estimate actually works are usually either because:

• We simply were pretty lucky to get this one right, which is really rare.
• We are one of the faster members of our team so we can afford estimating longer than we think since at the end of the day the estimate is about similar to what some of the slower members would come up with, except its done by the deadline.
• Or it was a small thing without much likelihood to get more complicated than we originally thought.
• Or we were pushed by a hard corporate or client-promised deadline and had to compromise on many things, cut down features and generally do things more in a quick-and-dirty way instead of doing them right as we would prefer.

  And this is the one most likely reason enabling us to actually hit the deadline. This is, unfortunately, the mode most corporate programming jobs end up in sooner or later (usually sooner). And it does not make us programmers very happy. Most of us anyway, I'd hope. I, for one, want to be proud of my work, not ashamed for it. It is great to do something quickly - and I've been usually (and also unfortunately) the one who is asked to do it in such cases - but it is even greater to do them also right. And that usually cuts into the "quick" part.

  Sure, the client does not usually know it could have been so much better or that we were forced to take a shortcut that may result in limited future extensibility of the system we built for them. But we know! And it makes it, at least for some of us, so much harder to work for a particular corporation long-term.

  In case of corporations the bosses often actually realise what they are asking us to do but "it is OK, do it quick-and-dirty now and there will be budget in the next budgeting period to do it better all over again". Sometimes that really means re-doing the whole thing almost from scratch. Overall, it does not make sense, but it does in the realm of constraints of corporate budgets. I guess.

Vlastně to možná ani není proto, že jsme v odhadování času špatní, ale prostě je správné odhadnutí času prakticky většinou téměř nemožné. Jediné případy, kdy časový odhad na softwér nakonec jakž takž sedí jsou:

• Jednoduše jsme měli v tomto případě štěstí, že jsme se trefili, což je opravdu řídký případ.
• Jsme jedním z rychlejších členů našeho týmu, takže si můžeme dovolit odhadnout delší čas, než si ve skutečnosti myslíme, protože nakonec je ten odhad podobný těm, co by udělali pomalejší členové našeho týmu, jen s tím rozdílem, že to je hotové do stanovené lhůty.
• Nebo to byla malá věc bez velké šance na to, že se zkomplikuje.
• Nebo jsme byli tlačeni tvrdou firemní, nebo klientovy slíbenou lhůtou a museli jsme díky tomu nakonec udělat kompromis u mnoha funkcí, vypustit některé funkce kompletně a obecně dělat věci více "rychle a špinavě" místo dělat je dobře, tak jak bychom sami chtěli.

  A toto je ten jenpravděpodobnější důvod, který nám umožňuje dodržed lhůtu. To je, bohužel, mód, ve kterém skončí většina korporátních programovacích zaměstnání dříve nebo později (obyčejně spíše dříve). A nedělá to nás programátory zrovna šťastnými. Vetšinu z nás, doufal bych. Každopádně já, pokud mám mluvit sám za sebe, chci být na svou práci pyšný, ne se za ní stydět. Je skvělé být schopen udělat něco rychle - a já jsem byl obyčejně (a také naneštěstí) tím, kdo je pověřen uděláním takových věcí - ale je ještě skvělejší dělat ty věci také správně. A to většinou ubírá na té "rychlé" části.

  Samozřejmě, klient většinou ani neví, že produkt pro něj udělaný mohl být mnohem lepší, nebo že jsme byli nuceni vzít to zkratkou, která může vyústit ve sníženou rozšiřitelnost toho systému, který jsmě pro ně udělali. Ale my víme! A to takovou práci dělá, alespoň pro některé z nás, o tolik těžší, abychom vydrželi pracovat dlouhodobě pro nějakou korporaci.

  V případě větších korporací si šéfové dokonce jasně uvědomují, o co nás programátory žádají, ale "Je OK udělat to rychle a špinavě pro teď a příští rok či pololetí budeme mít peníze z nového rozpočtu abychom to celé předělali tak, jak to mělo být od začátku. Teď ale na 'správně' nemáme rozpočet." Někty to opravdu znamená udělat celý ten sofwér úplně od začátku. Obecně to nedává žádný smysl, ale dává ho to v prostředí korporátních rozpočtů. Hádám...

There is a kind of a maxim in programming world regarding time estimation that goes something like this:

V programátorském světě existuje na odhadování délky doby potřebné k vývoji poučka, která zní nějak takto:

First estimate the time needed to implement a feature to the best of your knowledge, ability and experience. Then multiply the time you came up with by 3.
And do that multiplication even if you've already taken this maxim into consideration when creating your original estimate to start with.

Nejdříve odhadni dle své nejlepší zkušennosti délku času, který bude potřeba k implementování určité funkce sofwaru. Pak tento odhad znásob třemi.
A to znásobení proveď i v případě, že jsi měl tuto poučku na mysli už při dělání svého původního odhadu.

And it's true most of the time. (That is if you want to keep all the planned features and implement them correctly with future in mind*.) Most programmers usually get much closer in their estimate to the actual time that turns out to be needed to implement a new feature if they do multiply their original estimate by 3, however ridiculous that sounds even to themselves.

A toto většinou opravdu funguje. (Tedy pokud chce programátor dodat všehny plánované funkce a implementovat je správně, s budoucností na mysli*.) Většina programátorů se obyčejně přiblíží mnohem blíže v jejich odhadu ke skutečně potřebnému času na implementaci, když opravdu znásobí svůj původní odhad třemi, jakkoliv šílené se jim to samotným může zdát.

* You should further know that once a piece (any piece) of code is written, that does not mean it is done and nobody will ever have to touch it again. It is actually quite likely that any code will be continuously improved and extended to serve newly added features and before ignored or unknown requirements, as well as to improve its clarity. If it is written well, this is much easer to do. And writing code with that in mind also makes the whole process longer as one has to always think about whether it is clear what the code is doing for when other programmers or even yourself might be reading it again in the future, maybe because it needs to be edited.

* Měli byste dále vědět, že jakmile je nějaký kus (jakýkoliv kus) kódu napsán, neznamená to, že je hotový a nikdo nikdy už se ho nebude muset znovu dotknout. Je naopak velmi pravděpodobné, že jakýkoliv kód bude průběžně vylepšován a rozšiřován, aby nabízel nově přidané funkce a dříve ignorované nebo neznámé požadavky, ale také aby byla zvýšena jeho čistota a čitelnost. Když je napsán dobře, je toto mnohem jednodušší dělat. A psaní kódu s tímto na mysli také činí tento proces delší, neboť programátor musí stále přemýšlet, jestli je jasné, co jím psaný kód dělá, aby v budoucnu jiní, nebo i on sám, mu byl schopen znovu porozumět a byl schopný ho efektivně upravit.

The same problem can be solved in code thousand and one ways, some of which are clearer to read, some of which are quicker to write, some of which are more extensible in future, some of which will execute faster, but may take more memory, others slower but take less memory etc. and all this needs to be considered. And that does what? It again can extend, but sometimes also shorten, the time needed to deliver the result.

Ten samý problém je možné v kódu vyřešit tisíci a jedním způsobem, z nichž některé jsou jasnější na přečtení, některé jsou rychlejší na napsání, některé jsou více rozšiřitelné v budoucnosti, některé budou počítačem vykonávány rychleji, ale mohou potřebovat více paměti, jiné pomalejší, ale s nižší potřebou paměti atd. A všechno toto musí být zváženo a zvolen ten nejvhodnější přístup k danému problému. A to co? Zase jen dále prodlužuje, ale někdy naopak urychluje, dobu potřebnou na doručení výsledku.

Programming is an engineering job and as such involves lots of decisions about what property of the final product is more important than another as implementing both may be physically impossible. Think for example power versus size of a motor. It would be ideal if a motor would have unlimited power and was infinitely small at the same time, but that is clearly not possible. We need to know how much power we need and that will result in a motor of a certain size and weight. We can make it lighter by using more expensive, but lighter materials, but then we may be also limited by the maximum tolerable cost. We may also make it smaller if we come up with some new, maybe never-tried-before solutions. Then we are risking its reliability. Maybe we can make it smaller by just using thinner wire for its coils but in that case its longevity may be severely negatively affected. But maybe that's fine for the use case for which it is needed. Engineering is all about balancing such conflicting requirements. And software engineering is no different.

Programování je inžennýrská práce a jako taková obsahuje velké množství nutných rozhodnutí o tom, jaká vlastnost finálního produktu je v daném kontextu důležitější než jiná, protože není fyzicky možné implementovat obě zároveň. Můžeme se o to jen snažit. Představte si například sílu motoru versus jeho velikost. Ideální by samozřejmě bylo, kdyby motor měl nekonečnou sílu a byl zároveň nekonečně malý. My ale v reálném světě musíme předem vědět, jak silný motor potřebujeme a to se promítne do toho, jak velký a jak těžký bude. Můžeme ho udělat lehčí tak, že použijeme lehčí, ale dražší materiál, ale zde zase můžeme být limitování maximální přípustnou cenou. Také se můžeme pokusit ho udělat menší, pokud použijeme nějaké nové, nikdy předtím nevyzkoušené řešení. Pak riskujeme jeho spolehlivost. Možná ho můžeme udělat menším, když (u elektromotoru) použijeme hubenější drát na jeho cívky, ale v tom případě může zase být ohrožena jeho dlouhověkost. Ale možná to je v pořádku pro to použití, pro které má sloužit. Třeba ostatní součásti toho celku vydrží beztak ještě kratší dobu. Inženýrství je celé o balancování takových protichůdných požadavků. A softwérové inženýrství není v tomto odlišné.

So we must constantly ask ourselves lots of questions that we need to find the best possible answers for. We have to devise solutions that must often sacrifice some part of one ability in order to gain on another, more important aspect. You can't have everything in life and you can't have absolutely everything in a computer program either. But you can try to get as close as possible. And that is hard.

Takže sami sobě musíme stále pokládat spousty otázek, pro které musíme nalézt ty nejlepší odpovědi. Musíme přicházet s řešeními, která musí často obětovat část jedné schopnosti aby se posílila jiná, důležitější schopnost. Není možné mít vše v životě a není možné mít absolutně všechno ani v počítačovém programu. Ale můžeme se pokusit dostat se tak blízko, jak to jen jde. A to je těžké.

It is not unusual to see me just looking at the screen for extended periods of times. Sometimes even hours. And it's not just me. It does not mean that I'm not working. In fact I'm probably stretching the capabilities of my brain to the limit trying to design things in my head, doing virtual tests and trying to figure out the best way forward, attempting to consider unspecified future needs. Some people may not do that and those are usually the "not so good" programmers who often produce code that is very confusing, unreadable and complicated and the product for the user is much less useful if not straight away terrible. In the end, spending a couple of hours just thinking through a problem properly more often than not can save many more hours, or even weeks or month in the future on writing, extending and maintaining badly written code.

Není úplně neobvyklé vidět mě pouze hledícího do obrazovky po docela dlouhou dobu. Někdy i hodiny. A to nejsem jen já. Neznamená to ale, že nepracuji. Velice pravděpodobně natahuju závity svého mozku až na hranice jeho možností, pokoušejíc se designovat věci v mé hlavě, provádějíc virtuální testování a zkoušíc nalézt tu nejlepší cestu kupředu, pokoušejíc se brát v úvahu i nespecifikované budoucí potřeby uživatele / zákazníka. Někteří programátoři toto možná nedělají a to jsou právě většinou ti "ne tak dobří", kteří často vyprodukují kód, ktrý je matoucí, nečitelný a komplikovaný a výsledný produkt pro uživatele je mnohem méně použitelný, pokud není vyloženě hrozný. Ve výsledku je lepší strávit pár hodin hlubokým přemýšlením o problému, než se pustit bezhlavě do chrlení co největšího množství zmateného kódu. Často těch pár hodin čistého přemýšlení ušetří v budoucnu mnohem více hodin, nebo kolikrát i týdnů či dokonce měsíců práce při psaní, rozšiřování a udržování špatně napsaného kódu.

And, then there is something called "scope creep". Those are the hundreds of little or even more significant features that neither the client originally realized they wanted nor the programmer realized would be "nice", or helpful or actually necessary to implement in the program.

A pak je tu něco, čemu se anglicky říká "socpe creep". Přeložil bych to asi něco jako "nabalování požadavků". Těch stovek různých malých nebo i podstatnějších vlastností, které si ani zákazník původně neuvědomil, že chce a ani programátor, že by byly "příjemné", nebo nápomocné, nebo dokonce nezbytné, aby byly do programu implementovány.

Being able to keep the project scope strictly only to features originally intended is therefore also hard. But it more or less always has to be done. However, it probably never can be done 100%. Some features just simply must be there if we don't want to look like amateurs, regardless of the fact that they were not in the original scope of the project.

Tudíž být schopen držet rosah projektu striktně na pouze těch funkcích, které byly zadány v původním záměru, je také velice těžké. Ale více méně to musí tak být. Avšak téměř nikdy to tak nemůže být na 100%. Některé funkce prostě a jednoduše implementovat musíme, pokud nechceme vypadat jako amatéři, přestože nebyly udány v původní specifikaci.

There is probably yet more that actually comes into play (like internationalization = translation to other languages, programmatic testing, or in our lingo test-driven-development, where we first program tests for the code we intend to write etc.) but these are some of the things I remembered from the top of my head and felt I could explain to a lay person. Hopefully I managed to achieve that goal to a good degree.

Těch věcí, co děljí z vývoje softwéru běh na dlouhou trať je pravděpodobně ještě znatelně více, než co se mi vybavilo při psaní tohoto článku (jako třeba internacionalizace, tedy překlad sofwéru do dalších řečí, test-driven-dvelopment, neboli psaní samotného programu až po napsání testů, které musí splňovat atd.), ale to co jsem napsal jsou aspekty, které se mi vybavily a které jsem cítil, že snad jsem schopen vysvětlit nějak i lajkovi. Snad se mi to alespoň trošku povedlo.

And there you have it - a bit better idea about what us software developers actually do and have to deal with. Let me know what you think if you feel like it.

A tady to máte - trošku lepší představa o tom, co my softwéroví vývojáři vlastně děláme a s čím se musíme ve své práci vypořádávat. Dejte mi vědět, co si o tom myslíte, když se vám bude chtít.

Just by the way, this very page, as I'm looking at it now, has almost 2 500 lines of code and text if I subtract the presented final code and documentation lines for the presented component itself. However, each paragraph of this text is only counted as one programming line, so the actual length comparable to an article, or a book, would be much longer. Trying to copy and paste it into a Word document results in 109-page long document :). Well, it is also written in two languages, so that makes it significantly longer.

Jen tak mimochodem, tato stránka samotná má, jak na to teď tak koukám, téměř 2 500 řádků kódu a textu, když odečtu ty řádky prezentující kód té mé komponenty a řádky té dokumentace k ní. Avšak navíc každý odstavec textu je počítán jen jako jeden jediný řátek kódu, takže opravdová délka srovnatelná s jiným článkem, nebo spíše už knihou, by byla značně delší. Zkusil jsem zkopírovat a vložit HTML obsah této stránky do Wordu a tam to vychází na 109 stránek dlohý dokument :). No je také psaný na této stránce ve dvou řečech.