Dodatkowo zapraszam (w szczególności uczestników GTUG-a, na którym było więcej kodu) do projektu na Githubie, gdzie wgrałem źródła.

Na koniec chciałem jeszcze podziękować organizatorom za trud włożony w dogranie tych spotkań i Wam, uczestnikom, za przybycie i zadawanie ciekawych pytań :). Do zobaczenia na następnych imprezach.

Podobne wpisy:

1. Wrocław wita JavaScript – Meet.JS i Wrocław GTUG
2. meet.js – JavaScriptowe spotkanie w realu
3. Node.js i middle-end – przenośny kod i emulacja przeglądarki

Ekipa organizująca szkolenia zwróciła się do mnie z prośbą, bym zastąpił Davida, któremu wypadły pilne sprawy. Nie mogłem odmówić i zabrałem się za przygotowania. Czego możecie się spodziewać? Na pewno szkolenie będzie kręciło się w okół Node’a i middle-endu. W związku z obserwacjami dotyczącymi problemów, jakie z SSJS mieli uczestnicy warszawskiego meetingu, postaram się wyjaśnić, jak organizować kod, radzić sobie z asynchronicznością, czy pisać przenośne moduły w standardzie CommonJS. Poruszę więc kwestię odmiennych charakterystyk przeglądarkowego i serwerowego JavaScriptu. Wstęp ten przyda się do zadań praktycznych, które tak jak na pozostałych jesiennych meetingach będą kluczowym elementem Krakowskiego szkolenia.

Rejestracja jest darmowa i jeszcze otwarta. Do zobaczenia w Krakowie :)

Podobne wpisy:

1. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings
2. Moje prezentacje z DevMeetings i MeetJS
3. Node.js i middle-end – przenośny kod i emulacja przeglądarki

Kto nie był w zeszłym roku na konferencji Front Trends ten, czytając świetne recenzje jakie dostała, na pewno tego żałował. Sam byłem w Warszawie i wiem, że dobrze zainwestowałem swój czas i pieniądze, bo to jedyne tego typu wydarzenie w Polsce, jakie pamiętam. Wystarczy spojrzeć na listę prelegentów, którzy wzięli udział w konferencji. Douglas Crockford, Tantek Çelik, Peter-Paul Koch to bez wątpienia gwiazdy, których przedstawiać nie trzeba. Jednak bardzo dobre wrażenie zrobili na mnie również mniej znani prelegenci, jak Christian Johansen, Zbigniew Braniecki (jako moderator panelu dyskusyjnego), czy Andrea Giammarchi.

Jedyny zarzut (poza drobnymi problemami organizacyjnymi i kilkoma odstającymi poziomem prelegentami), jaki słyszałem w stosunku do zeszłorocznej konferencji to zbyt małe nastawienie na JavaScript. W tym roku Damian Wielgosik i Paweł Czerski, twórcy Front Trends, postanowili wyjść na przeciw krytykom i już za 2 tygodnie, w dniach 18-20 maja w Warszawie odbędzie się konferencja i 2 dni warsztatów pod nazwą Falsy Values. Tym razem, z pewnością, będzie to „True JavaScript Event”. W dodatku obsada zapowiada się jeszcze ciekawiej i równiej. Nie dość, że gościć będą wszyscy wielcy z Front Trends (poza PPK-em), to spotkać będzie można również kilku nowych, dobrze znanych, developerów, m.in. Dmitry’a Soshnikova, Juriy’a „kangax” Zaytseva oraz Kornela „porneL” Lesińskiego.

W chwili obecnej zakupić można jeszcze bilety wstępu (upoważniające również do udziału w konferencji) na wszystkie warsztaty poza jednymi prowadzonymi przez Tanteka Çelika. Do wyboru mamy więc node.js, wstęp do JavaScriptu, gry, ECMAScript 5, Test Driven Development i aplikacje desktopowe. Można zakupić też bilet jedynie na piątkową konferencję. Ceny wahają się w zależności od tematu warsztatów i długości (są jedno i dwudniowe) i wydaje mi się, że nie są wygórowane, w szczególności kiedy porównamy je z dotyczącymi podobnych eventów organizowanych za naszą zachodnią granicą.

Jeśli o mnie chodzi, to ze względu na studia pojawię się tylko w piątek na konferencji (dziękuję tutaj Damianowi za zaproszenie). Zapowiada się wspaniały dzień, ponieważ plan prelekcji jest wyśmienity. Wiem, że ani nie będę mógł się spóźnić (Douglas Crockford na początek), ani wcześniej wyjść (Tantek Çelik na koniec), ani nawet przysnąć w środku (Dmitry Soshnikov). W szczególności nie mogę doczekać się występu tego trzeciego, ponieważ będzie mówił o ECMAScript 6, a kto czytał mnie wcześniej, wie, że interesuje mnie rozwój tego standardu.

Tak więc, do zobaczenia w Warszawie!

Podobne wpisy:

1. JavaScript na jesień 2011
2. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings
3. Obiektowy JavaScript i właściwości chronione – w poszukiwaniu Świętego Graala

Ostatnimi czasy wykonałem na zajęcia ze sztucznej inteligencji symulację algorytmów genetycznych w JavaScriptcie. Nie lubię standardowych tematów jakie wybierają zazwyczaj studenci, więc kiedy przyszło do podejmowania decyzji jaki problem rozwiążę przypomniała mi się prelekcja Krzystofa Szafranka na meet.js w Poznaniu. Opowiadał on o silniku Box2D przeportowanym z ActionScriptu do JavaScriptu, a jako ciekawostkę pokazał symulację we Flashu wykorzystującą tę bibliotekę. Polegała ona na ewolucyjnej optymalizacji „rowerka”, który miał za zadanie przebyć jak największą odległość po pagórkowatej planszy (możliwe że był jeszcze dodatkowy warunek, a mianowicie pakunek musiał pozostać na rowerku). Ja niestety w momencie formułowania tematu swojej pracy nie mogłem znaleźć tego przykładu (możliwe, że w ogóle znikł z internetu, bo wszystkie linki prowadziły do nieistniejącej domeny), dlatego mój pomysł mocno się różni. Gdyby ktoś jednak znalazł adres do tej symulacji, to proszę o komentarz pod wpisem.

Postanowiłem, że mój stworek (kreatura brzmi jakoś pokracznie :) składać się będzie z patyczków połączonych między sobą ruchomymi stawami. Jego zadaniem (czyli wartością funkcji celu bądź przystosowania) również będzie przebycie w określonym czasie największej odległości po planszy (ze względów oszczędności mojego czasu – płaskiej), czyli innymi słowy uzyskanie jak najwyższej średniej prędkości. W genotypie zapisałem następujące informacje:

• rozmiar (długość, szerokość), gęstość, sprężystość i współczynnik tarcia patyków (członów),
• istnienie (bądź nie) kończyny – przyjąłem że mamy główne „ciało”, które ma maksymalnie 4 kończyny, a każda z nich jeszcze po jednej ruchomej części,
• położenie kończyny względem rodzica oraz położenie stawu względem części wspólnej rodzica i kończyny (ileż ja się tu naliczyłem…),
• moc silniczka w stawie, zakres ruchu, prędkość ruchu (ruch ma stałą prędkość, a kiedy wychylenie dociera do granicy zakresu zmieniam zwrot prędkości).

Symulację zaczynam z całkowicie losowymi (ale z ustalonych zakresów) wartościami genów. Przyjąłem ze względów wydajnościowych dosyć niewielką populację 100 stworków i każdemu daję na jego podróż 15 sekund. Selekcji dokonuję przy pomocy metody ruletki, a genotypy krzyżuję z losową ilością punktów przecięć i równym prawdopodobieństwem co do obu rodziców. Z każdą populacją zachowuję stała liczbę osobników – czyli 100.

Instrukcja użycia symulatora

Po pierwsze zalecam odpalenie symulatora w Chrome’ie. Działa jeszcze pod Firefoksem, ale ten jest zbyt powolny (co mnie aż trochę zdziwiło). Pod Operą nie zadziała, bo ta ciągle nie ma zaimplementowanej metody Function.prototype.bind (innymi słowy – focham się). Po drugie polecam otworzyć sobie konsolę JavaScriptu (ctrl+shift+j), ponieważ wypisuję tam trochę przydatnych informacji.

Kiedy już wszystko jest przygotowane można kliknąć start. Jak widać miota nam się jakiś stworek. Z początku wartości genów są losowe, więc musimy mieć dużo szczęścia aby trafić na jakiegoś, który ruszy się gdzieś dalej. (Przy okazji – każda kreska na podłożu to 5 metrów). Widać jednak jaki jest punkt wyjścia.

Teraz możemy przełączyć się do trybu szybkiego. W tym trybie wstrzymane jest renderowanie, a pomiędzy kolejnymi setTimeoutami wywoływanych jest 1000 kroków animacji (czyli jakieś 33 sekundy z życia stworków). W tym właśnie miejscu nie daje rady Firefox, dla którego 1000 iteracji trwa tak długo, że blokuje się interfejs. Dla Chrome’a na moim sprzęcie mogłem spokojnie dać 5000 i nadal zachować przyzwoitą responsywność GUI.

Symulator sprawdzi nam jaki dystans przebyły wszystkie 100 stworków, po czym stworzy następną populację krzyżując pomiędzy sobą wybrane osobniki. W tym momencie na konsoli pojawią się statystyki dotyczące najlepszego rezultatu oraz średniej dla wszystkich stworków. W każdym momencie możemy podejrzeć stworki wracając do trybu powolnego symulacji.

W momencie utworzenia nowej populacji symulator uaktualnia też pola tekstowe z genotypami populacji odpowiednio dla całej aktualnej populacji, 10 najlepszych stworków w całej historii oraz 10 najlepszych z ostatniej populacji. Genotypy te (jak i przykłady wyników działania symulatora) można wkleić w najwyżej znajdujące się pole i przeprowadzić symulację dla zadanej populacji. Przy czym mam trzy uwagi: genotypy zapisane są bardzo nieoptymalnie, więc są długie i próba ich skopiowania, czy wklejenia może przymulić przeglądarkę; w tej chwili symulacja dla 10 najlepszych stworków zawiesi się i nie wygeneruje następnej populacji; użycie najlepszych 10 stworków może trochę zdziwić, ponieważ niektóre z nich mogą nie osiągnąć tak dobrych rezultatów jak za pierwszym razem. Wydaje mi się, że wynika to z ziarna losowości w granicznych sytuacjach w silniku Box2D, dlatego jeśli stworek przypadkiem osiągnął dobry rezultat, to za drugim razem tak być nie musi. Ewentualnie mam gdzieś w momencie publikowania najlepszych stworków błąd, ale nie chce mi się go szukać.

Obserwacje i wnioski

Kiedy pisałem ten symulator byłem pełen wątpliwości co do tego czy tego typu ewolucja, w której jest przecież tyle losowości dotyczącej krzyżowania genotypów, zda egzamin. Wydawało mi się, że skoro moje losowe stworki tak sobie plumkają w miejscu, to ich dzieci po wsze czasy również będą tylko plumkać. Przecież każdy z silniczków jest niezależny od drugiego, porusza się w innej fazie, z inną prędkością i z innym zakresem ruchu. Niemożliwe by przy takiej losowości ułożył się z tego jakiś skoordynowany organizm.

A jednak! Kiedy skończyłem metody odpowiedzialne za selekcję i krzyżowanie osobników i odpaliłem symulację pierwszy raz na czas potrzebny do wygenerowania kilkudziesięciu pokoleń, po czym zatrzymałem ją aby obejrzeć dotychczasowe wyniki nie mogłem wyjść z podziwu. Jednym z pierwszych rezultatów (i to całkiem szybkim – już po około 100 pokoleniach) była populacja z przykładu pierwszego, która zatrzymała się na 28 metrach. Zobaczcie sobie jak niesamowicie skoordynowane są te stworki. Na mnie to naprawdę zrobiło wrażenie, a moją dziewczynę wręcz przeraziło :).

Napisałem przed chwilą, że populacja zatrzymała mi się na 28 metrach. Okazało się mianowicie, że stosunkowo szybko spada presja selekcyjna i wszystkie osobniki upodobniły się do siebie. Jest to po części wina metody ruletki, która powoduje, że wiele osobników ma niemal zerową szansę stania się rodzicami. Drugim powodem tak szybkiego spadku różnorodności był brak mutacji, którą co prawda zaimplementowałem, ale jak się dużo później okazało, z błędem, który powodował, że w ogóle nie działała. Po jej naprawieniu wydaje mi się, że symulacja zachowuje się o wiele lepiej, choć pewnie mógłbym jeszcze poprawić metodę selekcji, czego jednak z braku czasu pewnie nie zrobię.

Inna ciekawa obserwacja, to formy do jakich ewoluują stworki. Ja zauważyłem dwie – stworek kroczący na dwóch nóżkach i stworek skaczący ze skręcenia (robiący fikołki). Pierwszy występuje dość rzadko, drugi o wiele częściej i w dodatku notuje dużo lepsze wyniki. Od prowadzącego zajęcia, który okazało się robił pracę magisterską właśnie o patyczakach, dowiedziałem się, że przewroty to nie tylko w moim przypadku najpopularniejsze rozwiązanie.

Zastanawiałem się też, co trzeba byłoby zmienić, aby uzyskać bardziej ludzkie formy ruchu, czyli aby przeważały formy kroczące. Chciałem zmienić maksymalne prędkości silników, ale to chyba nic by nie dało. Wydaje mi się, że trzeba było by wprowadzić dodatkowy warunek – na przykład stworek musiałby przenieść na swoim korpusie jakiś pakunek. Jestem bardzo ciekawy w jaką stronę wtedy poszłaby symulacja, choć wydaje mi się, że aby uzyskać ciekawe wyniki należałoby zwiększyć ilość osobników w populacji. Obym kiedyś wrócił do tego zagadnienia.

PS

Kod symulatora trzymam na Githubie. Gdyby komuś wpadło do głowy zaglądanie do niego, to proszę wziąć pod uwagę, że pisałem go pod dużą presją czasową. Skończyłem symulator w środku nocy, 4 godziny przed zajęciami :). W dodatku ciągle uczę się współgrania JavaScriptu z modelem MVC, a kiedy o jakiejś późnej godzinie trafiłem na kilka problemów projektowych, to postanowiłem je po prostu zignorować :>. Może powstanie kiedyś na ten temat jakiś artykuł.

Najlepszy wynik jaki uzyskał mój stworek to 48.31 metrów :).

Podobne wpisy:

1. Co lepiej wiedzieć o JavaScriptcie cz.1.: typy zasięgu i domknięcia
2. Co lepiej wiedzieć o JavaScriptcie cz.2.: hoisting, deklaracje funkcji i wyrażenia funkcyjne

Najgłupsze, najśmieszniejsze, najbardziej bezsensowne, najciekawsze pełne opisy zmian wgranego kodu w Subversion jakie udało nam się przyuważyć:

• poprawka po zergu. Wstydź się :P
• cos
• refaktoryzacja hahaha
• nie pamiętam co to
• tagusie na dole
• coby hmora taguf smigala jak na waSseLinie
• Debile z PHP nie potrafią nawet gramatyki języka sensownie zrobić.
• coby sie firebug nie denerwowal
• Cichaczem zmieniłem Reinmarowi CSS-a.
• redesign layoutu. O kurwa
• dopieszczanko
• Fix Knorra
• Firefix.
• cosie
• haaa!
• jkopytko
• stylusie dla panelusia administratorka
• dopieszczanie zdzicha
• 3h meki z textilem i nadal nikt nie wie dlaczego niedziala. Ihaha
• Szukarko
• Polska sie pisze z duzej litery
• musk mię boli
• glupia opera
• Zergu, kocham Cię
• +glebogryzarka
• Forms w Syffony to jakiś żart.
• boze , ja nie moge =)
• kod :)
• la la la layout
• Ominięcie buga PHP, który autorzy nazywają ficzerem.
• Tao w kodzie
• Teraz jest dobrze

Podobne wpisy:

1. SVN: Wycofywanie (zatwierdzonych) zmian

Lena - obiekt naszych testów

Na potrzeby wypisu założmy, że zajmujemy się przeskalowaniem powyższego obrazka z rozmiarów 300 x 300 px na 200 x 100 px. Można pomyśleć o najprostszym rozwiązaniu, czyli przeskalowaniu albo wycięciu odpowiedniego kawłka z oryginalnego obrazka. Żadne z tych rozwiązań nie jest jednak dobre, pierwsze nie poradzi sobie z plikami, w których stosunek szerokości do długości jest inny niż docelowy, drugą metodą wytniemy jedynie fragment z obrazka pomijając być może istotną część interesującą użytkowników naszego serwisu. (W szczególności problem pojawia się problem przy dużych obrazkach, którą część wycinać? Przedstawiony poniżej przykład jest nieco tendecyncyjny ze względu na małą wielkość obrazka.)

Skalowanie

Wycinanie

Potrzebujemy więc rozwiązanie, które pozwoli uwzględnić różny stosunek wysokości do szerokości obrazka dostarczonego przez użytkownika, oraz umożliwi pokazanie jego jak największej zawartości. Najlepiej więc będzie jeżeli będziemy tylko ścinać obraz z góry i dołu, lub lewej i prawej a następnie skalować go do żądanego rozmiaru. Niech i_w i i_h oznaczają odpowiednio szerokość i wysokość obrazka wejściowego, natomiast o_w i o_h analogicznie dla obrazka wyjściowego. Obliczamy stosunki szerokości do wysokości dla obrazków:

• R_i = i_w/i_h – w naszym przypadku wynosi on 300/300 = 1
• R_o = o_w/o_h – w naszym przypadku wynosi on 200/100 = 2

Ponieważ R_o jest większy niż R_i, czyli w obrazku wyjściowym przypada więcej pikseli szerokości na piksel wysokości, to powinniśmy wyciąć możliwe najmniejszy kawałek góry i dołu z oryginalnego obrazka tak aby uzyskać w nim współczynnik R_o. Wymiary pasów, które powinniśmy wyciąć obliczamy następująco:

• d_h = i_w/r_o – w naszym przypadku 300/2 = 150

Ponieważ sumaryczna szerokość pasa wynosi 150, to przytniemy z góry i dołu pasy o szerokości 300 i wysokości 75 i skalujemy to co zostało do rozmiaru 200 x 100 px, przyjmując optymistycznie, że na skraju obrazka znajdują się zawsze najmniej istotne treści.

Fragment obrazka do przeskalowania

Wynik działania metody

Sytuacja gdy R_o jest mniejsze od R_i jest analogiczna, nie będę więc jej omawiał. Przedstawiony algorytm jest bardzo prosty i w pseudokodzie wygląda następująco:

Ri = iw / ih
Ro = ow / oh

if (Ri  <= Ro)
{
  new_h = iw / Ro
  segment = (ih-newh)/2
  zetnij pas o wysokości segment z góry i dołu
  i przeskaluj do rozmiarów ow x oh px
}
else
{
  neww = Ro * ih
  segment = (iw - neww) / 2
  zetnij pas o szerokości segment z lewej i prawej
  i przeskaluj do rozmiarów ow x oh px
}

Przy implementacji  powyższego rozwiązania w języku PHP do ścinania i skalowania przydatna może okazać się funkcja imagecopyresampled().

Podobne wpisy:

1. Refaktoryzacja CSS — jednak coś można
2. Dwukolumnowa lista definicji (edit: w HTML5 lista opisów (?))

Dust-Me Selectors robi właściwie „tylko” jedną rzecz — znajduje nieużywane selektory CSS. Jednak właśnie jest to jedna z najtrudniejszych rzeczy do wykonania manualnie, szczególnie w przypadku dużych, długo rozwijanych projektów.

Rozszerzenie może działać na dwa sposoby:

• przeszukiwanie jednej strony (przydatne raczej w niewielu przypadkach),
• tzw. Spider Search, czyli przeszukiwanie wszystkich linków z mapy strony.

Mapa strony może być stroną HTML lub sitemapą w XML zgodną ze standardem. W tym pierwszym przypadku są pewne ograniczenia. Otóż domyślnie potrafi on wyskoczyć na inne, zewnętrzne domeny i je sprawdzać. Nie udało nam się znaleźć opcji zabraniającej tego, jedynie da się ograniczyć omijanie odnośników z rel=”external” i/lub rel=”nofollow”. Problem jest, gdy nasz serwis na to nie jest przygotowany. Wtedy pozostaje wygenerowanie lub napisanie sitemapy (która przecież i tak się przyda).

Samo działanie programu już jest bardzo proste. Wybieramy „Automation → Spider Search”, podajemy adres sitemapy lub strony HTML i czekamy na wyniki, które wyglądają na przykład tak:

Okno wyników Dust-me Selectors

Oczywiście znalezione selektory nie powinny trafiać od razu do kosza, bo narzędzie nie potrafi (i raczej wątpliwe żeby kiedykolwiek potrafiło) wziąć pod uwagę manipulacji dokonywanych przez JavaScript. Ponadto mogą istnieć specyficzne widoki, które nie będą mogły się znaleźć w mapie strony. Dlatego też wyniki należy traktować tylko jako listę podejrzanych. Warto dodać, że narzędzie pomogło nam szybko pozbyć się prawie dwustu linii z arkuszy CSS (przy kolejnych do dokładniejszego sprawdzenia).

Podobne wpisy:

1. Jak przycinać i skalować obrazki?

Jednak, jak każde narzędzie, warto go dostosować do własnych potrzeb. Ja najczęściej stosuję go do przeszukiwania projektów będących pod kontrolą Subversion (SVN), poprzez taką instrukcję:

grep -RIin "szukane" * --exclude-dir=\.svn

Dla wyjaśnienia: -R — szukanie rekursywne w podkatalogach, -I — pomijanie plików binarnych, -i — niewrażliwość na wielkość znaków, -n — wyświetlenie nr linii w wyniku.

Oczywiście wpisywanie tego za każdym razem nie ma nic wspólnego z wygodą, dlatego warto sobie utworzyć funkcję dla powłoki np. w pliku .profile (średniki na końcu są wymagana dla Basha, Zsh ich nie potrzebuje):

function g { grep -RIn $1 * --exclude-dir=\.svn ; }
function gi { grep -RIin $1 * --exclude-dir=\.svn ; }

Dzięki czemu wystarczy wykonać:

[src]> g fuck
arch/i386/kernel/cpu/cpufreq/powernow-k7.c:558: * Some Athlon laptops have really fucked PST tables.
arch/i386/kernel/cpu/mtrr/generic.c:70:/*  Some BIOS's are fucked and don't set all MTRRs the same!  */
…

Z racji tego, że większość projektów piszę w Symfony, stworzyłem sobie dodatkową wersję tej funkcji:

function sfg { grep -RIn $1 lib/model apps/ --exclude-dir=\.svn ; }

Odpalając ją w głównym katalogu projektu, można łatwo przeszukać wszystkie warstwy aplikacji (model, widoki, kontrolery i przy okazji parę innych).

Jest też możliwość włączenia „na stałe” niektórych opcji, poprzez wyeksportowanie zmiennej środowiskowej o nazwie GREP_OPTIONS, np.:

export GREP_OPTIONS="--exclude-dir=\.svn"

Ale ja osobiście tego nie stosuję.

Podobne wpisy:

1. Formularze Symfony: select ograniczony przez wartość innego pola

Testowanie apache-benchmarkiem (/usr/sbin/ab) jest niewątpliwie łatwe, proste i przyjemne, nie licząc rozczarowania wynikami. Znakomicie spisuje się w przypadku Rails (nie mam pojęcia dlaczego), ale w aplikacyjach PHP może nieco zaskoczyć.

Też nie wiem dlaczego, ale wydaje mi się, że jest prawdopodobnym iż…

Otóż PHP, słusznie zresztą, przy braku nagłówka Connection czeka na kolejne zapytania na tym samym połączeniu (zakłada domyślnie: keep-alive), a ab sam z siebie go nie wysyła i… zwiesza się na iluś tam otwartych połączeniach, na których nic się nie dzieje (ab chyba czeka aż to serwer się rozłączy). Niezbyt miło, bo to zaniża wyniki benczmarku i pogarsza i tak już złe samopoczucie.

Dlategoż zawsze dla pewniejszych wyników (i dobrego samopoczucia) warto dodawać ab opcje -H 'Connection: close'. Manual mówi nawet, że przełącznikiem -H można też inne nagłówki wysyłać, gdyby komuś zależało.

Czy to jednak znaczy, że Rails w wersji cokolwiek starej, bo 2.1.1, domyślnie zakłada Connection: close? To by było niesłuszne, lecz może być wytłumaczone jednowątkowością Rails. Tego niestety, już mi się nie chciało inwestygować, bo święta idą.

Tak więc szczęśliwego nowego jajka i co tam jeszcze!

Podobne wpisy:

1. Aktualizacja oprogramowania a wydajność
2. Refaktoryzacja CSS — jednak coś można