Reakční doba
Náš dojem z aplikace se mění podle reakční doby:

Pod 0,1 s vnímáme reakci jako okamžitou. Aplikace reaguje na naše požadavky, přímo ji ovládáme.
Pod 1 s ztrácíme pocit okamžitosti, ale prodleva nepřerušuje naši práci.
Prodleva pod 10 s přerušuje uživatelovu práci, ale ten ještě dokáže udržet pozornost na úkol.
Reakce trvající déle než 10 s ztrácí lidskou pozornost.

Cíl je jasný: Reagovat pod desetinu sekundy.

Jaká kritéria optimalizovat
1. Co nejméně požadavků
Každý požadavek je drahý. Může obsahovat řadu zdržujících činností od překladu DNS, zahájení a ukončení TCP [neřkuli SSL] spojení po zbytečné chybové (4xx) a přesměrovávací (30x) stavy.
Je vhodné požadavky spojit, šetřit spojení – udržovat je otevřené pomocí Keep-Alive – a opakované požadavky úplně odstranit správným cachováním.

2. Rychlé odpovědi
Požadavky musí být vyřízené co nejdřív. Server je musí zpracovat rychle, výstup odeslat co nejdřív a odpověď musí cestovat co nejrychleji.

3. Malé odpovědi
Všechny odpovědi je důležité gzipovat a kód – HTML, JS, CSS – předtím minifikovat, pokud je to možné.
U kódu se objem přenášených dat po minifikaci a gzipování zmenší většinou na méně než 20%.

4. Feedback co nejdřív
Často můžeme dát uživateli feedback ještě před odesláním požadavku. Reakční doba je pak rozložená na okamžitý feedback a opožděné zobrazení odpovědi. Neurychlí se tím samotné provádění úkolu, ale zlepší se dojem z používání aplikace.

MySQL
Vlastně jsem na začátku neříkal úplně pravdu. Optimalizovat jsem začal už v zimě, kdy jsem se zakousl do užitečné knihy High Performance MySQL.

Autoři měli naprostou pravdu, když tvrdili, že správně navržené indexy a napsané dotazy dokáží urychlit zpracování dat o řády. Hlavní stránku Webtrhu jsem přepsáním několika dotazů a úpravou indexů zrychlil z několika sekund na desetiny.

Optimalizace nastavení SQL serveru a cachování výkon vylepšila přesně podle jejich předpovědi už „jen“ v desítkách procent.

Pokud má aplikace problémy v DB, je dobré začít právě tam. Optimalizace DB poskytne nejvíc muziky, protože nejvíc ovlivňuje Time To First Byte.

Server
Všechny odpovědi by se měly gzipovat a měly by mít správné hlavičky pro cachování. V Apache jednoduše pomocí mod_expires a mod_deflate:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/css\
 text/xml application/x-javascript text/javascript application/javascript
</IfModule>

<IfModule mod_expires.c>
  ExpiresActive on
  ExpiresDefault                          "access plus 1 month"
  ExpiresByType text/html                 "access plus 0 seconds"
  ExpiresByType text/xml                  "access plus 0 seconds"
  ExpiresByType application/xml           "access plus 0 seconds"
  ExpiresByType application/json          "access plus 0 seconds"
  ExpiresByType application/rss+xml       "access plus 1 hour"
</IfModule>

Víc komentované konfigurace je v ukázkovém .htaccess HTML5Boilerplate.

Až budeme cachované soubory měnit, klienty přinutíme stáhnout si novou verzi souboru změnou jména. Stačí upravit query za otazníkem:
external.js?20110721

Nezapomeňte zkontrolovat zapnuté Keep-Alive (Apache má defaultně zapnutý) pro udržování otevřených spojení.

Výstup bychom měli začít odesílat co nejdřív. Pokud se v requestu provádí nějaká údržba, je dobré postupovat takto:

1. Vytvořit výstup
2. Odeslat výstup
3. Provést údržbu (zvýšení čítačů, přepočet statistik apod.)

Nebo ještě čistěji – přesunout údržbu do pravidelně volaných procesů.

PHP v továrním nastavení odešle výstup až na konci běhu skriptu. Dá se přinutit k okamžitému odeslání pomocí flush(); (jednorázově), ob_implicit_flush(); (po dobu běhu skriptu) nebo příslušným konfiguračním příznakem.

Této techniky jsem se musel zříct, protože ve vBulletinu se HTML výstup generuje až úplně nakonec. Můžeme ji ale využít třeba u AJAX požadavků.

Nainstaloval jsem taky APC, opcode cache pro PHP, nakonec s touto konfigurací:

apc.shm_size="128" ; velikost cache v MB.
  ; Pokud APC nepoužívá mmap, nastavit podle tohoto
apc.stat="0" ; APC přestává při každém požadavku ověřovat, jestli se soubor nezměnil.
  ; Pro staging server zapnout
apc.ttl="86400" ; životnost opcode cache
apc.user_ttl="86400" ; životnost user cache (proměnných)
apc.lazy_functions="1"
apc.lazy_classes="1"
 ; Dvě nové featury přidané vývojáři Facebooku, lazy loading funkcí a tříd

HTML
Požadavky jsou drahé, takže pokud je to možné, spojte všechny JS soubory do jednoho, všechny CSS do jednoho, a všechny obrázky do jednoho image spritu.

HTML je možné minifikovat pomocí CSSMin nebo YUI Compressoru, ale pozor na signifikantní whitespace. Na Webtrhu minifikace začala žrát odstavce (oddělené novými řádky), kdykoliv jsem editoval příspěvek.

Javascript
Javascript blokuje render a načítání kvůli document.write. Proto se dřív doporučovalo: Přesuňte JS až na konec stránky. Dnes existuje lepší metoda.

Přestaňte používat document.write a načítejte JS asynchronně pomocí knihovny jako LABjs nebo Require.js. Pro Webtrh jsem zvolil LABjs, nedělá nic jiného a gzipovaná má jen 2,2 kB.
Javascript se pak načítá mimo ostatní requesty na stránce a neblokuje je.

Kód musí být připravený pro minifikaci. Minifikátory jsou různě agresivní, od extra agresivního Dean Edwards Packeru přes hodně doporučovaný YUI Compressor až po mírumilovný JSMin od Douglase Crockforda.

Kód zabalený Packerem nefungoval správně a jelikož rozdíl mezi minifikátory je zanedbatelný, nevěnoval jsem se tomu a zvolil JSMin.

Překvapivé překážky při přeskládávání JS
(V nouzi pomůže aliterace. :)

Při spojování souborů do jediného se vyskytla chyba v syntaxi, protože poslední deklarace v jednom ze spojovaných souborů nebyla ukončená středníkem. První deklarace z následujícího souboru se tedy stala součástí předchozí deklarace a syntax error byl na světě:
callMe()callMeToo();

Jakmile začnete načítat všechny skripty na stránce asynchronně a zároveň máte ve stránce inline skripty, začnou okamžitě v konzoli vyskakovat chyby. Inline skripty se totiž najednou rozběhnou PŘED načtením zdrojů.
LABjs poskytuje řešení ve formě metody wait():

$LAB
.script('external.js')
.wait( function() {
  // na předchozím souboru závislé inline skripty
});

To s sebou ale přineslo několik neočekávaných záludností, které mě přiměly k emotivním commitům v Gitu. :)

Problém č. 1: Pokud je external.js načtený z cache a je dlouhý, inline skripty se spustí dřív, než se interpretuje kód z externího souboru.
Řešení: setTimeout(executeInlines, 1);

Problém č. 2: Inline skripty ztratí globální scope, na kterém závisí. Zároveň jsou deklarované jako privátní proměnné a nelze je uchopit výčtem
for(var prop in this) {}
Čisté řešení: Zbavit kód závislosti na globálním scope. V ideálním případě bych skripty přepsal a zbavil chybné závislosti na globálním stavu. Protože legacy kód má ale několik tisíc řádků, použil jsem regex/eval hack zmíněný dál. Šlo o záměrné rozhodnutí ponechat technický dluh, abych se nezdržel na několik dnů až týdnů.
Rychlé řešení: Projít inline kód regexpem a vybrat všechny názvy funkcí a lokálních proměnných. Předat je JS proměnné, a zkopírovat eval()em do globálního scope.
Brutální, ale funguje.

Problém č. 3: Protože se asynchronní skript načítá nezávisle, je nutné explicitně stanovit závislosti všech událostí.
Tohle zní nevinně, ale zabralo mi to celý den. vBulletin definuje dvě vlastní události, které se musí odpálit v určitém pořadí. Nikde to ale není explicitně napsané, natožpak nakódované.
Protože na sebe skripty a DOM přestaly čekat, události se spouštěly v náhodném pořadí.
Řešení: Identifikovat závislost a explicitně ji uvést do kódu:
Událost č. 2 musí počkat na událost č. 1.

Rozhraní
Pokud má akce jasný výsledek (jeden stav), můžeme zareagovat ještě před odesláním požadavku. Rozhraní se pak chová responzivněji, ačkoliv se reakční doba nezkrátila.

Okamžitý feedback jsem aplikoval v hlavním navigačním menu Webtrhu. Menu zareaguje na kliknutí ihned, ještě předtím, než se začne načítat nová stránka. Vyzkoušejte to.

Co dál
Zrychlování stránky se odehrává na mnoha úrovních a je to hodně zajímavá a uspokojující činnost. :)
Nepodařilo se mi zatím ale dosáhnout původního cíle a zrychlit stránky pod desetinu sekundy.

Jak zrychlit načítání dál? Použít pro statický obsah doménu bez cookies. Zvětšit initial TCP congestion window. Dál optimalizovat databázi. Agresivněji cachovat části stránek, alespoň pro nepřihlášené návštěvníky.

Jaké máte další nápady?

Další čtení

• Web Performance Best Practices
• Best Practices for Speeding Up Your Web Site

Předpoklady

• Minimalizujte závislosti na globálních sdílených datech.
• Vytvářejte v kódu švy (seams), na které se testy napojí.

Konkrétně

• Nepoužívejte statické metody a singletony. Kód, který je využívá, se špatně testuje.
• Když už používáte statickou metodu, nevolejte ji přímo, ale přes pomocnou nestatickou metodu, kterou lze přepsat potomkem.
• Když už používáte singleton, oddělte od sebe samotný kontejner singletonu a jeho logiku. Tak můžete v testu přepsat logiku.
• Neinstancujte objekty v metodách s logikou. Použijte jednoduchou tovární metodu, nebo objekt předejte klientovi přes konstruktor nebo pomocnou metodu (použijte Dependency Injection).
• Spoléhejte se na rozhraní, ne na konkrétní třídy.

Best practices

• Testujte veřejný interface, ne implementaci.
• Použijte jeden assert na test.
• Pište testy nezávislé na sobě. Testy se nesmí volat navzájem, sdílet proměnné a nesmí spoléhat na pořadí.
• Testy nemají obsahovat žádnou logiku. Žádné řídící prvky typu if, switch, while, for atd.
• Testy musí být velmi jednoduché spustit a musí běžet automaticky – při buildu nebo pravidelně.
• Testy musí být spolehlivé a spravovatelné, jinak přestanou plnit svoji roli.
• Autor doporučuje testovací metody pojmenovávat podle vzoru
  MethodUnderTest_TestingScenario_ExpectedResult();
  Neboli podle mnemotechnické pomůcky: Když volám metodu X s Y, musí vrátit Z:
  X_Y_Z();

Na čem vlastně děláme?
Všechny změny hlavně vylepšují uživatelský zážitek při obchodování – něco, co jsme dlouho a moc zanedbávali.

První update překopal od základů rozhraní obchodů (příhozy, editace). Druhý zpřehlednil centrum obchodů (přehled, čeho se kde účastním a jak si vedu). V posledním updatu jsme úplně přepsali notifikace (zprávy typu Ztratili jste vedení v aukci, Vyhráli jste). Přepsáním myslím texty, situace, ve kterých se posílají, i kód, který je obsluhuje.

Notifikace jsme psali s těmito pravidly na mysli:

1. Předej informace co nejrychleji
2. Buď stručný
3. Buď přátelský
4. Vyzvi k akci

Ad 1. Notifikace chodí nově preferenčně na email (místo do pošty) a nejdůležitější informace jsou už v předmětu. Není ani nutné je otvírat (srovnej lákavé předměty typu „Newsletter 04/11″).
Ad 2. Čas je drahý, takže žádné zbytečné fráze. Všechno je jasné na první pohled.
Ad 3. Stručnost ale nevylučuje přátelský tón. Nemá smysl někomu kazit den, když už prohrál v aukci. Popřejeme mu víc úspěchů do budoucna a dáme nějaký krátký tip.
Ad 4. Všude, kde to dává smysl, rovnou píšeme, co uživatele čeká, co může nebo musí udělat. Jsou to většinou banální rady typu „Vyhráli jste aukci: Zkontaktujte prodávajícího v poště nebo emailem, pošlete mu platbu a dokončete obchod.“ Nicméně věřím, že každá taková drobnost pomáhá uživatelům snížit kognitivní zátěž. Nemusí ani na chvíli přemýšlet, jaký je další postup, protože jim to rovnou píšeme.

Updaty jsou víceméně neviditelné, ale přesto mají obrovský vliv na naši morálku.

Získali jsme setrvačnost a jedeme!

Na Webtrhu jsme přešli od nerozhodnosti k umíněnosti už před několika měsíci. Nejlépe je to vidět na aukcích. Dřív bylo možné schvalovat příhozy, automaticky schvalovat příhozy některých přihazující, naopak vylučovat přihazující z aukce, přihazovat veřejně nebo privátně, ručně nebo automaticky.

Všechny volby jsme v posledních měsících zrušili. A co se stalo?

Nic. Nedostali jsme jedinou stížnost a mohli jsme radikálně zjednodušit rozhraní pro prodávající i přihazující.

Nestavíme švýcarský nůž, ale aplikaci s vlastním názorem na obchodování přes internet. Je jasné, že tento přístup nám ztratí nějakou malou část uživatelů, kteří bez neexistující volby prostě nemůžou být, ale většina uživatelů díky tomu bude mít podstatně lepší uživatelský zážitek.

Nezahlťte uživatele volbami. Stavte umíněný software.

Doplnění: Článek Kill The Settings, Build Opinionated Software obsahuje odkaz na tento neuvěřitelný screenshot. Nastavení před redesignem a po něm. :)

Číst katalog celý je nuda, takže si vybírám hlavně části popisující úmysl a snažím se pochopit, jak Martin Fowler přemýšlí. Hodně témat se opakuje z Code Complete:
Úpravy programu tvoří mnohem větší část celého životního cyklu než samotné psaní.
Kód se píše pro lidi, ne pro počítač.
Hlavním způsobem snižování složitosti je schovávání informací.

Fowler má nějaké užitečné postupy. Například se snaží místo komentářů používat názvy metod. Pokaždé, když má potřebu něco okomentovat, se podívá, jestli komentovaný blok nemůže raději extrahovat do nové metody a dát mu jméno, které by jeho záměr popisovalo místo komentáře.

Ukázka je vidět přímo v popisu Extract Method.

Původní kód

void printOwing() {
    printBanner();

    //print details
    System.out.println ("name:	" + _name);
    System.out.println ("amount	" + getOutstanding());
}

přepíše na

void printOwing() {
    printBanner();
    printDetails(getOutstanding());
}

void printDetails (double outstanding) {
    System.out.println ("name:	" + _name);
    System.out.println ("amount	" + outstanding);
}

Jiný postřeh: Jediné místo, kam podle něj (v kontextu OOP/Javy) patří switch, je tovární metoda. Všude jinde by měl být nahrazený právě factory method a polymorfismem.

Technický dluh
Refactoring mě přiměl k zamyšlení nad technickým dluhem. Rozhodnutí odbýt návrh a vývoj bude mít důsledky v budoucnu, až program budeme chtít upravit, přidat novou platební metodu, upravit formulář apod.

Srozumitelnější kód se lépe spravuje, tak proč jej nepsat rovnou? Můžou k tomu vést různé úmysly. Fowler má moc pěkný kvadrant důvodů pro vznik technického dluhu:

Technický dluh může vzniknout záměrně nebo neúmyslně, z ledabylého nebo rozvážného přístupu. Je nutné snažit se učinit veškerá rozhodnutí o technickém dluhu explicitně, s vědomím budoucí zátěže.

Refaktoring je vylepšování existujícího kódu, jak zní podtitul knihy, a to vlastně není nic jiného než splácení technického dluhu. Nižší technický dluh (tedy lepší návrh) vede k nižším splátkám, tj. levnějším modifikacím a opravám.

Ze širšího pohledu je Code Complete (a Clean Code) o tom, jak psát software s co nejnižším dluhem (tedy dobře spravovatelný), Refactoring je o splácení existujícího dluhu.

Někteří šli ještě dál a tvrdili, že schovávání je v interpretovaných jazycích úplně k ničemu. Když někdo bude chtít zavolat metodu, zavolá ji přes reflection či podobnou vlastnost jazyka, nebo ji natvrdo prohlásí za public, protože má k dispozici zdroj.

Ale o to přece vůbec nejde.

Schovávání implementace a členů není důležité proto, aby na ně nikdo nesahal, ale proto, aby na ně nikdo, kdo s třídou pracuje, nemusel myslet! Aby si mohl uvolnit omezenou kapacitu lidského mozku pro důležitější úkoly. Aby viděl jen interface a nemusel zároveň přemýšlet o implementaci. Aby mohl přemýšlet – místo o datových typech, algoritmech a databázi – o problému v jazyce reálného světa – „zákazník, faktury, doba dodání, DPH, reklamace“.

Každý prvek v programu by měl obnažovat jen minimální sadu vlastností, potřebnou pro komunikaci se světem.

Skrývání je sexy.

Uvolnění mozkové kapacity pro vyšší úroveň abstrakce je nejdůležitější důvod pro schovávání informací (a psaní tříd a metod s jednoznačným účelem, psaní metod s nízkou cyklomatickou komplexitou, automatizované testy a…). Koneckonců to je hlavní důvod, proč se neustále pohybujeme k vyšším jazykům (ASM k C k Pythonu) a ne naopak.

P.S.: To není článek proti Pythonu.

CoffeeScript
CoffeeScript je jazyk inspirovaný Ruby a Pythonem, odstraňuje nedostatky JS a přidává některé užitečné nové funkce. Namátkou
Comprehensions

countdown = (num for num in [10..1])

Nové operátory is, isnt, not, and, or, existenční operátor ?

if band?
    volume = 10 if band isnt SpinalTap

Pohodlnější práci s třídami a objekty, bezpečnější deklaraci proměnných (globální proměnné už nelze deklarovat omylem, zapomenutím var, ale pouze explicitně) atd.

CoffeeScript se překládá přímo do JS.

Sass
Sass je nadmnožina CSS, která z čistě deklarativního CSS dělá procedurální jazyk s proměnnými a funkcemi. Umožňuje třeba definovat základní hodnoty do proměnných a provádět s nimi psí kusy pomocí specializovaných funkcí

$margin: 16px;
$blue: #3bbfce;
.border {
  padding: $margin / 2;
  margin: $margin / 2;
  border-color: darken($blue, 9%);
}

Vytvořit základní, opakující se deklarace a měnit je

@mixin left($dist) {
  float: left;
  margin-left: $dist;
}

#data {
  @include left(10px);
}

Nebo dědit vlastnosti od dřív definovaných selektorů

.error {
  border: 1px #f00;
  background: #fdd;
}
.badError {
  @extend .error;
  border-width: 3px;
}

Sass se překládá do CSS.

Nepřehání ale zprávy o smrti JS a CSS?
Rails, jeden z významných frameworků pro tvorbu webových aplikací, se rozhodl ve verzi 3.1 přejít právě na CoffeeScript a Sass. Tím jsou obě nadstavby definitivně legitimní součástí vývojářských nástrojů.

Nahrazení JS a CSS začíná.

Na necelých devíti stech stránkách se McConnell věnuje třem velkým tématům – řízení softwarového projektu (vytvoření požadavků, design, konstrukce, management), psychologii programování a především psaní kódu, který je čitelný, spravovatelný a snižuje složitost programu.

The first goal of programming is managing complexity
Tuto větu čtete mnohokrát a McConnell zkoumá krocení složitosti z mnoha úhlů – jak správně navrhovat třídy, jejich rozhraní a implementaci, jak rozvrhnout kód do funkcí, jak používat a nazývat proměnné (4 úžasné kapitoly), jak organizovat příkazy a deklarace a používat řídící struktury (6 kapitol) a k čemu používat komentáře v kódu.

Věnuje se i vyšším, nekódovacím procesům, které ovlivňují konečnou kvalitu programu – programování v páru, revizím kódu, testování, debuggování, refaktorování, ladění a integraci.

Všechna témata kulminují v posledních třech kapitolách. Self-Documenting Code shrnuje mikrotechniky důležité pro psaní čitelného a samovysvětlujícího kódu. Personal Character mluví o vlastnostech a návycích důležitých pro to, aby se programátor neustále zlepšoval, a Themes in Software Craftsmanship je shrnutí těch nejdůležitějších principů z nadhledu.

Bohatá bibliografie
Nemůžu opomenout bohatou bibliografii, která je uvedená v každé podkapitole. Nejde o suchý výčet knih podle klíčových slov, ale o komentovaný výběr toho nejpřínosnějšího, co si o daném tématu můžete přečíst (do 2004, roku vydání druhé edice).

Na konci knihy McConnell shrnuje nejdůležitější knihy, které by podle něj měl přečíst každý programátor.

V češtině jako Dokonalý kód
Code Complete vyšel v češtině jako Dokonalý kód. Podle zběžného zhlédnutí ukázek a porovnání s originálem se mi překlad zdá trochu těžkopádný, občas zavádějící a nepříliš dobře vysázený. Bubliny v bočním sloupci, které v originále upozorňují na důležitá místa v ukázkách kódu, český vydavatel převedl do inline komentářů, což jednoznačně snížilo přehlednost.

Některé věty jsou v češtině méně srozumitelné či nepřesné:

Using > instead of >= or < instead of <= is analogous to making an off-by-one error in accessing an array or computing a loop index.

Operátor > místo operátoru >=, či operátor < místo operátoru <= je stejnou chybou jako nepozorné překročení mezí pole při opakovaném zvyšování hodnoty cyklu.

Některé jsou přeložené chybně.

This ordering convention conflicts with the C-library convention of putting the modified parameter first.

Tato konvence uspořádání parametrů je v rozporu s konvencí pro upravované parametry.

A narazil jsem i na větu, která z originálu vypadla úplně:

Put the case you normally expect to process first. This is in line with the general principle of putting code that results from a decision as close as possible to the decision. Here’s a code example…

Nejprve vždy uvádějte příkazy, které zpracovávají běžné alternativy. Následující ukázka…

Pokud volíte mezi překladem a originálem, sáhněte jednoznačně po originálu. Kniha je opravdu čtivá a srozumitelná.
Pokud ale volíte mezi překladem a nepřečtením, sáhněte po překladu.

Pro koho kniha je?
Je kniha i pro pokročilé programátory? Správný návrh rozhraní třídy, pojmenovávání proměnných, používání if, to už mám přece dávno za sebou.

Existuje velká šance, že jste se některými otázkami, o kterých se mluví v Code Complete, nezabývali explicitně. Buď jste přejali postupy a konvence z nějakého velkého projektu, nebo si potichu nacházeli vlastní. Některá z vašich rozhodnutí mohla být podvědomá. Code Complete ty otázky zdůrazní a umožní vám si na ně znovu, tentokrát vědomě odpovědět.

McConnell každopádně počítá i s pokročilými programátory a pravidelně upozorňuje na podkapitoly, které je nejspíš nebudou zajímat a na podkapitoly, které pro ně budou užitečné.

Já knihu přečetl od začátku do konce a během čtení jsem doslova cítil, jak se můj kód a mé uvažování o programech zlepšuje.

Rozhodně Code Complete doporučuju programátorům všech úrovní, ale kvůli kapitolám a bibliografii o vedení projektu, psychologii programování a o vlivu pracovního prostředí na výkonnost i všem projektovým a softwarovým manažerům a majitelům firem, které programátory zaměstnávají.

Vyřešili jsme to zavedením volitelných anonymních příhozů, při kterých je identita přihazujícího úplně skrytá.

Uvažujeme ale o lepším řešení – pseudonymních příhozech. Jméno přihazujícího by bylo schované před vyhledávači, třeba bychom zobrazovali jen první a poslední písmeno. A vedle pseudonymu obchodní hodnocení a datum registrace. S trochou práce by samozřejmě bylo možné identitu odhalit, ale už by nešlo zkoumat aktivitu křížově.

Učinili bychom tak zadost soukromí přihazujících i transparentnosti aukce.

Za čtyři roky Webtrhu si lidé poslali jen necelých 5 000 hodnocení. Uvidíme, jak se to změní s novým systémem bodování.