Příspěvky

1696

O serveru Root.cz / Re:Nový Root již dnes?

« kdy: 25. 04. 2016, 14:32:57 »

...

Osobne bych byl rad i za to "slepene" reseni*, pokud bude za 5 minut hotove a stejny tyden nasazene. Pak se muze za nekolik mesicu nasadit "profi" varianta - odstraneni popsanych pravidel.

PS: Ten hlavni CSS soubor je teda neco, kombinace dev kodu s komentari a minifikovaneho customizovaneho Bootstrapu. Hmm, verzovani trid, to urcite prinasi lepsi citelnost: .opinions-button--version-4, zvlast kdyz se pouziva v kodu zaraz vice verzi.

Já jsem se zařekl, že určité věci tady raději nebudu komentovat, protože to je děs a hrůza, jak je to splácané. Ale ta kombinace CSS do jednoho souboru je nejspíš zařízena programově. Méně souborů = méně navazování spojení. To bude asi v rámci nahánění optimalizace, protože to jakože má být pak rychlejší. Že to řeší z opačného konce a nedají si pořád říct, když se jim na to tady opakovaně upozorňuje, je jejich problém. Prostě stavějí barák od střechy a pořád se diví, že se jim to kácí.

Urcite je to soucast build procesu. Ale proc teda neminimifikuji vse, kdyz uz v jedne mensi casti to delaji? Nekde jsem cetl, ze v nekterych firmach pro produkci jen ocesou komentare, a to jen pokud jsou opravdu dlouhe, ale jinak se whitespace nechava, protoze pry kdyz se to v zaveru stejne prohani gzipem, tak se stejnak v podstate nic neusetri.

Já říkal, že to nechci moc komentovat. Ale nejspíše proto, že prostě bootstrap minifikovaný je a ten jejich CSS ne a prostě se to jen slije do jednoho souboru. Vážně to nechci komentovat

Jiste, mit to v jednom souboru (pripadne dvou - zvlast CSS knihoven a aplikace), cele minifikovane, je asi aktualni best practise. (No, pripadne na vetsi weby se pouziva webpack a je to rozsekane na mensi casti, aby se rychlej nacitalo.) S http2 to ale ztraci uplne vyznam, protoze tam lze v jednom spojeni zaraz (prokladane, bez HOL blokovani) posilat vice souboru. A teda i nyni prohlizece bezne pouzivaji nekolik spojeni zaroven, takze problem by byl jen u opravdu velikeho poctu souboru (tusim ze FF melo omezeni na 16 paralelnich spojenich?). Napr. trosku slozitejsi aplikace v Angularu, pokud by se nepouzivala primo plnena template cache, ale tahaly by se html sablony hezky ajaxem, by to v pohode vycerpala instantne.

Vážně to raději nechci moc komentovat, třeba by se mi zvedl tlak. Root.cz je sbírka příkladů jak to nedělat. Patláma, patláma, paprťála žbrluch...

1697

O serveru Root.cz / Re:Nový Root již dnes?

« kdy: 25. 04. 2016, 13:21:10 »

Raději bych se s dovolením přimlouval za odstranění následujících definic, místo zavádění nové jak píšete:

Jiste, to moje "reseni" je hotfix splacany pod 5minut, ktery pouzivam lokalne, ne reseni na porad, ktere ma servirovat web server. Jelikoz netusim, kde se ta pravidla vsude pouzivaji, tak jsem si nedovolil do nich drbat (to ale samozrejme origo vyvojar vi, ze ano).

Koukal jsem a nevypadá, že by se používaly jinde. Ale vývojář to opravdu ví na beton (nebo by alespoň měl vědět).

Osobne bych byl rad i za to "slepene" reseni*, pokud bude za 5 minut hotove a stejny tyden nasazene. Pak se muze za nekolik mesicu nasadit "profi" varianta - odstraneni popsanych pravidel.

PS: Ten hlavni CSS soubor je teda neco, kombinace dev kodu s komentari a minifikovaneho customizovaneho Bootstrapu. Hmm, verzovani trid, to urcite prinasi lepsi citelnost: .opinions-button--version-4, zvlast kdyz se pouziva v kodu zaraz vice verzi.

Já jsem se zařekl, že určité věci tady raději nebudu komentovat, protože to je děs a hrůza, jak je to splácané. Ale ta kombinace CSS do jednoho souboru je nejspíš zařízena programově. Méně souborů = méně navazování spojení. To bude asi v rámci nahánění optimalizace, protože to jakože má být pak rychlejší. Že to řeší z opačného konce a nedají si pořád říct, když se jim na to tady opakovaně upozorňuje, je jejich problém. Prostě stavějí barák od střechy a pořád se diví, že se jim to kácí.

1698

O serveru Root.cz / Re:Nový Root již dnes?

« kdy: 25. 04. 2016, 12:52:59 »

Problém je, že na celou firmu je jen jeden kodér

Jistě, když máte na jednoho kodéra dvacet "nepostradatelných" v marketingu a pět managorů, tak máte opravdu problém. Obávám se ale, že to lidi mimo firmu příliš nezajímá.

Tak posli p. Krcmarovi zivotopis a mozno ti dovoli sa pridat do timu a pomoct Rootu v tejto situacii. Isto by ta to bavilo viac, nez len sediet na fore a frustrovane nadavat.

Vzpamatujte se! Tohle není komunitní web, ale komerční záležitost, komerční firmy.

Cesticka sa vzdy moze najst, ak sa chce. Ale prave na webe, ktory sa venuje aj open-source by som taketo kategoricke odmietnutie ponuknutia pomoci necakal.

Mna tieto bugy nebolia a nemam dovod tlacit na p. Krcmara, narozdiel od vas.

Bež si trollovat jinde, hlásím bugy, radím, posílám patche, takže je tvůj příspěvek mimo.

1699

O serveru Root.cz / Re:Nový Root již dnes?

« kdy: 25. 04. 2016, 12:51:49 »

Root pro ne asi neni moc vysoko v seznamu priorit, kdyz bug, ktery je tu snad od nasazeni, o kterem se vi od nasazeni (mozna +- nejaky ten tyden) a ktery ma fix na jeden radek jeste neni opraveny.

Snippet nize vypada, ze funguje, ale nejak detailne jsem nezkousel, jestli to nerozbiji neco jineho (ale to by pro originalni vyvojare nemel byt problem, pokud maji automatizovane testy).

Kód: [Vybrat]

.article-discussion.container.reply { width: auto; }

PS: Byla to prace ani ne na 5 minut.

Raději bych se s dovolením přimlouval za odstranění následujících definic, místo zavádění nové jak píšete:

Kód: [Vybrat]

@media (min-width: 1330px)
.container {
    width: 1160px;
}
@media (min-width: 990px)
.container {
    width: 960px;
}
@media (min-width: 770px)
.container {
    width: 740px;
}

Chová se to pak správně ve všech velikostech, dle responsivních pravidel, protože se to správně "rozlije" do velikosti definovanou rodičem - odzkoušeno. A opravdu to není ani na 5 min, včetně hledání, opravy a odzkoušení.
Vzhledem k tomu, že chyba vzniká definicemi navíc, které tam vůbec být nemají, nepřijde mi to jako školácká chyba, ale spíš jako záměr něco rozbít. Třeba si někdo takhle buduje u nadřízených pocit nepostradatelnosti.

PS: Pokud jsou ty definice potřeba pro jiné místa, které mají class .container, tak je selectujte přesně, nebo nepoužívejte stejné názvy tříd! Tohle je pak jak od studenta ze základky!
PPS: To odhlašování z fóra v průběhu psaní je příšernost. Píšu tenhle příspěvek podruhé. Náhled bez potíží a odeslání o půl sekundy později už selže. Máte to rozbité!

1700

O serveru Root.cz / Re:Nový Root již dnes?

« kdy: 25. 04. 2016, 12:28:40 »

Problém je, že na celou firmu je jen jeden kodér

Jistě, když máte na jednoho kodéra dvacet "nepostradatelných" v marketingu a pět managorů, tak máte opravdu problém. Obávám se ale, že to lidi mimo firmu příliš nezajímá.

Tak posli p. Krcmarovi zivotopis a mozno ti dovoli sa pridat do timu a pomoct Rootu v tejto situacii. Isto by ta to bavilo viac, nez len sediet na fore a frustrovane nadavat.

Vzpamatujte se! Tohle není komunitní web, ale komerční záležitost, komerční firmy.

1701

O serveru Root.cz / Re:Nový Root již dnes?

« kdy: 25. 04. 2016, 12:10:51 »

Problém je, že na celou firmu je jen jeden kodér a ten má takových drobností na seznamu asi 80 na 10 serverech. Do stejné kapitoly patří třeba vypnutí statické sociální lišty, je to drobná úprava a bohužel to trvá měsíc.

Problém je hlavně v tom, že tyhle "školácké" (to já na to mám teda jiný název) chyby taky někdo udělal. Kdyby rozuměl své práci, tak ani nevzniknou.

A pokud je 8 drobností per server, tak za šichtu max dvě, když se vyloženě nedaří, není co dělat. Vlastní zkušenost.

1702

O serveru Root.cz / Re:Nový Root již dnes?

« kdy: 23. 04. 2016, 21:28:17 »

Chyba bude mozno u teba. Na Chrome 50.0.2661.75 sa spravicky zobrazuju v poriadku, bez rozbiteho layoutu.
Firefox nainstalovany nemam, nechce sa mi.

Zlaté oči...

Google Chrome 50.0.2661.86 (64-bit):



Sejmuto právě teď.

PS: Není to zobrazení zprávičky, ale odpověď na názor...

1703

O serveru Root.cz / Re:Nový Root již dnes?

« kdy: 23. 04. 2016, 14:06:19 »

Opraví někdo KONEČNĚ tuhle lemplovinu, kterou by nikdo soudný nevypustil ani do beta verze?

 

Proč by to dělali? Nadávání na rozbitý web generuje více hitů

Upozorňujeme na to tak dlouho a tolikrát, že je jasné, že to někomu prostě vyhovuje.

1704

Software / Re:MC: pořadí kopírování souborů

« kdy: 21. 04. 2016, 19:01:43 »

Mluvilo se tady o potřebě defragmentace. Chápu, že Lael zatlačený do kouta kolem sebe kouše jako divoké raněné zvíře, ale tím ukazuje, že neumí ani uznat, že je mimo, když se mu to prokáže.

Aha

Je to vývojářský stroj, MySQL tam mám a hromadu databází a tabulek taky. Fragmentace tam není.

BTW to že vám defrag po analýze napíše že defragmentace volume není potřeba není nic zvláštního. Mě to píše na mých Windows také. A pokud je FS ve Windows fragmentovaný, většinou jsou fragmentovaná instalační média (třeba záloha souborů pro odinstalování service packu), která se minimálně ve Windows XP komprimují na úrovni FS. Komprese na úrovni FS zvýší fragmentaci, ale to se týká jen daných souborů, které uživatel interaktivně nepoužívá.

Opět se snažíte navlékat poznatky a informace ze světa Windows na zcela odlišné OS a opět jste za pitomce. V jiných OS to funguje jinat, to že vám něco vypisuje defrag na Windows je v Linuxu úplně irelevantní. Diskuze s vámi o ničem. Nevidíte nic než Windows a ještě blbě a myslíte si, že díky tomu víte vše o všem. Klasika. Tímto s vámi hovor opět končím, s psychopatem co si pořád mele svou i přes předložené data a informace se bavit nehodlám.

1705

Software / Re:MC: pořadí kopírování souborů

« kdy: 21. 04. 2016, 12:20:08 »

Strčte si ty své teorie někam. Je to vývojářský stroj, MySQL tam mám a hromadu databází a tabulek taky. Fragmentace tam není. Přestaňte navlékat (špatné) zkušenosti a vlastnosti Windows na OS, který očividně neznáte.

Fragmentace je funkční vlastností všech běžných FS. Mohlo by vám to dojít i z toho že jste sám postnul výstup z e4defrag, kde máte na jednom FS Total/best extents 740057/738878, tj. 1179 zbytečných fragmentů, a na druhém Total/best extents 1128887/1108381, tj. 20506 zbytečných fragmentů. Ale hlavně že vám to magicky nefragmentuje, protože Tux. Mimochodem tohle vám měli vysvětlit ve škole v modulu Operating System Concepts, případně jste si to měl nastudovat sám, pokud chcete dělat v IT a vědět co vlastně děláte.

Kód: [Vybrat]

Fragmentation score                            0
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]

Mluvilo se tady o potřebě defragmentace. Chápu, že Lael zatlačený do kouta kolem sebe kouše jako divoké raněné zvíře, ale tím ukazuje, že neumí ani uznat, že je mimo, když se mu to prokáže.

1706

Hardware / Re:Výpadky síťového rozhraní po update na Debian Jessie

« kdy: 21. 04. 2016, 12:08:57 »

Tak po dalsim dni googleni, jsem se dostal k tomu, ze by za tim mohlo byt povolene TSO (tcp segmentation offload) na sitovce, kde novy kernel s tim ma udajne u nekterych sitovek problem.

Je tu nekdo s hlubsi sitovou znalosti (TCP) a mel nervy a case me trosku "cesky"objasnit k cemu presne je TSO potreba, jak funguje, a pripadne jak moc jeho vypnuti muze treba snizit vykon systemu? :-)

Diky.

Novější kernel a případně firmware z Debian Backports nepomůže?

1707

Software / Re:MC: pořadí kopírování souborů

« kdy: 21. 04. 2016, 01:45:38 »

Toto je myslím si důkazem, že v Linuxu se, jak tady již bylo řečeno, defragmentace běžně neřeší. V jakém stavu by byly disky pokud by tam byly Windowsy a NTFS všichni víme, děkujeme, že nám to potvrzujete. Ale myslím si, že to je hodně off-topic.

To záleží na tom jak s FS pracujete. Když tam budete mít MySQL databázi (dá-li se tomu říkat databáze) s modelem soubor per tabulka, a budete do těch tabulek cpát spoustu dat, tak se to samozřejmě fragmentovat bude.

Strčte si ty své teorie někam. Je to vývojářský stroj, MySQL tam mám a hromadu databází a tabulek taky. Fragmentace tam není. Přestaňte navlékat (špatné) zkušenosti a vlastnosti Windows na OS, který očividně neznáte.

1708

O serveru Root.cz / Re:Formátování diskusí

« kdy: 20. 04. 2016, 18:39:52 »

K tomu sekani - zkusil jsem si hlavni stranu s raklamami a bez prebarveni a dokud se nacitaji reklamy, tak se mi to taky seka. Po nacteni reklam (coz trva celkem dlouho - nekolik vterin, viz blog post) zadne seky na starsi i5 neregistruji.

Tak k čemu je to vychvalované asynchronní načítání reklam, když je web po relativně rychlém zobrazení stránky stejně ještě 5-10 s nepoužitelný?

A mimochodem, vzhledem k tomu, že se tady objevují čím dál častěji reklamy, které dost zhusta vyžírají procesorový čas (viz mé příspěvky v téhle diskuzi) a to i takové, které jsou schopny zaměstnat daným vláknem jedno procesorové jádro na 100%, tak se pak trhavému posouvání nedivím. Takže hodně záleží taky na tom na jakou reklamu narazíte. Ono se to sice třeba v Chrome dá poladit v about:flags tím, že třeba rolování dám vlastní vlákno, ale mezi námi AdBlock je výrazně efektivnější řešení. Skoro mám pocit, že si poskytovatelé obsahu spolu s poskytovateli reklamy nepřejí nic jiného, než aby si co nejvíce uživatelů tyhle blokovací pluginy nainstalovalo, ten tlak na to je znatelný, nikdy jsem neměl tolik požadavků z řad běžných uživatelů na radu jak takovou věc získat, jako teď v poslední době.

Komu není rady... C'est la vie!

U me je ten overhead "pouze" ~2s, ale rekl bych, ze vetsina lidi na stranky neleze s mid-range herni masinou. Navic kdyz jsem to zkousel, tak je mozne, ze jsem schytaval ty lepsi (=mene narocne) reklamy.

No u mě je 2 s občas taky. Na výkonu stroje to moc nezáleží. Zkoušeno na osmijádru FX9590, čtyřjádru A10 7800, dvoujádru C2D, jednojádru Atom 720. Vše 40 Mbit internet. Hnije to někde po cestě. Jiné weby jsou OK. Možná máte jen jinou tzv. cílenou reklamu .

1709

Software / Re:MC: pořadí kopírování souborů

« kdy: 20. 04. 2016, 14:36:09 »

Hele luliku, to tu nemusis vypislovat ze fs z dilny M$ stojej zahovno, to vsichni vime. Problemy s fragmentaci sem jinde nez na widlich nikdy neresil.

Všechny běžné FS trpí fragmentací. Jedním ze scénářů je paralelní zápis více souborů. FS samozřejmě neví jak budou velké. V takovém případě můžete naivně zapisovat obsah do prvního volného bloku, takže ze souborů vznikne fragmentovaná "ideální řezanka" už při zápisu.

Vážně by bylo fajn, kdyby jste chování FS z díly Microsoftu nenavlékal na chování jiných FS, které jsou běžné v Linuxu.

Mé disky (/ a /home) po hodně dlouhém používání, paralelních zápisech, aktualizacích, mazání a novému nahrávání spousty dat, bez defragmentování (ext4):

Kód: [Vybrat]

<Fragmented files>                             now/best       size/ext
1. /var/log/wtmp.1                              26/1              4 KB
2. /var/log/wtmp                                15/1              4 KB
3. /var/log/clamav-unofficial-sigs.log          41/1              4 KB
4. /var/log/ConsoleKit/history.1                10/1              4 KB
5. /var/log/debug.1                              7/1              4 KB

 Total/best extents                             740057/738878
 Average size per extent                        75 KB
 Fragmentation score                            0
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
 This device (/dev/sda2) does not need defragmentation.
 Done.

a

Kód: [Vybrat]

<Fragmented files>                             now/best       size/ext
1. /home/jarda/.Skype/DataRv/offline-storage.data
                                                96/1              4 KB
2. /home/*censored*/.Skype/*censored*/chatsync/a3/a3753d88fe62e873.dat
                                                16/1              4 KB
3. /home/*censored*/.Skype/*censored*/chatsync/ff/ffc4dbedaa6ee36c.dat
                                                11/1              4 KB
4. /home/*censored*/.Skype/*censored*/chatsync/e0/e04921a91279e418.dat
                                                10/1              4 KB
5. /home/*censored*/.Skype/*censored*/chatsync/ea/ea920899646cf6c8.dat
                                                10/1              4 KB

 Total/best extents                             1128887/1108381
 Average size per extent                        1208 KB
 Fragmentation score                            0
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
 This device (/dev/sdb1) does not need defragmentation.
 Done.

Toto je myslím si důkazem, že v Linuxu se, jak tady již bylo řečeno, defragmentace běžně neřeší. V jakém stavu by byly disky pokud by tam byly Windowsy a NTFS všichni víme, děkujeme, že nám to potvrzujete. Ale myslím si, že to je hodně off-topic.

1710

O serveru Root.cz / Re:Formátování diskusí

« kdy: 20. 04. 2016, 13:16:56 »

K tomu sekani - zkusil jsem si hlavni stranu s raklamami a bez prebarveni a dokud se nacitaji reklamy, tak se mi to taky seka. Po nacteni reklam (coz trva celkem dlouho - nekolik vterin, viz blog post) zadne seky na starsi i5 neregistruji.

Tak k čemu je to vychvalované asynchronní načítání reklam, když je web po relativně rychlém zobrazení stránky stejně ještě 5-10 s nepoužitelný?

A mimochodem, vzhledem k tomu, že se tady objevují čím dál častěji reklamy, které dost zhusta vyžírají procesorový čas (viz mé příspěvky v téhle diskuzi) a to i takové, které jsou schopny zaměstnat daným vláknem jedno procesorové jádro na 100%, tak se pak trhavému posouvání nedivím. Takže hodně záleží taky na tom na jakou reklamu narazíte. Ono se to sice třeba v Chrome dá poladit v about:flags tím, že třeba rolování dám vlastní vlákno, ale mezi námi AdBlock je výrazně efektivnější řešení. Skoro mám pocit, že si poskytovatelé obsahu spolu s poskytovateli reklamy nepřejí nic jiného, než aby si co nejvíce uživatelů tyhle blokovací pluginy nainstalovalo, ten tlak na to je znatelný, nikdy jsem neměl tolik požadavků z řad běžných uživatelů na radu jak takovou věc získat, jako teď v poslední době.

Komu není rady... C'est la vie!