Stav vývoje této diskuse

Co popřemýšlet, zda by nešlo v nové verzi zakomponovat něco jako
http://pastebin.com/
do diskusí, kde se často posílají kusy kódu.

Tomáš Hanus
To, co nás brzdí, není preprocesor, ale databáze.

Reaguji na Kajmana:
Takových hraček by tu mohlo být po ruce víc. Ale na to je ještě brzo.

Reaguji na Yuhůa:
„proč se opravdu pustit do vývoje něčeho nového, tak je to vize systému, kde téměř všechno, co jde k uživateli na výstup (snad kromě registrace a hledání), je bráno ze statických souborů“
Tahle vize se mi též líbí, největší žrout půjde z kola ven. Kdybych uměl PHP, přiložil bych ruku k dílu.

„je těžké kešovat něco, co se téměř neustále mění (hlavní stránka)“
Nejčastěji se mění počet zobrazení, ten není tak důležitý, mohl by se vyhodit a místo něj ukazovat jméno zakladatele vlákna. Jinak se ten seznam mění jen při každém přidaném (či smazaném) příspěvku, což se sice děje často, ale samo načítání úvodní stránky probíhá určitě častěji, ne?

„nechci záplatováním rezavého traktoru ztrácet čas, sílu a motivaci“
Jmenuj zástupce pro traktor. Někoho tak deprimovaného a zničeného, že ho už taková drobnost, jako bude pozdější sešrotování opatrovaného traktoru, psychicky nesloží.

Ke statickým souborům - ono by to šlo udělat. Při každé změně příspěvku nebo přidání nového apod by se ale musel tento soubor znovu vyvořit. Pak je otázkou, zda se častěji mění obsah nebo se čte.

souki Pak je otázkou, zda se častěji mění obsah nebo se čte.
Odpoveďou je pomer Odpovědi/Zobrazení, ale treba zarátať editáciu príspevkov.

Už sa to pekne črtá - od zadania, cez špecifikáciu po riešenie konkrétnych problémov...

Já bych u cahování navrhoval následující postup - pro každou stránku každého topicu si držet txt verzi obsahové části. Uložit si jí nějak snadno dohledatelně (Id-strana.dat) a pak jí includovat (nutno odstranit nebezepčné konstrukce z obsahu). Při každé změně je pak ale nutné soubor změnit. U témat tipu HTML&XHTML je pak nutné při smazání příspěvku vytvořit znovu všechny stránky.
Toto řešení by mělo být rychlé, ale samozřejmě má i několik ošklivých nedostatků - např když z někoho uděláte moderátora, tak to bude vidět jen v nových vláknech.

Ještě k tomu API - myslel jsem to asi takhle:
Udělat pár veselých tříd, se kterými by se pracovalo asi takto -
$prispevek = new CPrispevek($id);
echo $prispevek->text;

Zkrátka jasně a čitelně. Třídy pak není problém problém prohnat třeba bcompilerem, aby si nikdo nestěžoval, že PHP brzdí. Veškerou funkční logiku bych pak držel v nich. Pokud se pak rozhodneme, že cachování nebyl dobrý nápad, tak stačí změnit pár drobností v třídě a jedeme dál. Pokud bude nějaký dobrák spravovat šablony a uživatelský výstup, tak ani nemusí vědět, že už nenačítá ze souborů, ale z databáze. U miniBB by to tak asi nešlo...

Ohledně cachování: možná by bylo lepší cache místo do souborů ukládat do paměti, nevím ovšem jak přesně to funguje a co se například stane, pokud paměť přestane stačit. I tak by se ta ale dalo použít pro stránky s nejfrekventovanější změnou, například pro úvodní stránku nebo pro stránky jednotlivých témat. Taky by bylo asi vhodné jednou za čas smazat v cache soubory, ke kterým se několik dní nepřistoupilo, aby Yuhů potom zase nemusel platit víc za diskový prostor.

Toto řešení by mělo být rychlé, ale samozřejmě má i několik ošklivých nedostatků - např když z někoho uděláte moderátora, tak to bude vidět jen v nových vláknech.
Řešení je v takových případech smazat cache, nový moderátoři se nepřidávají moc často.

Acci
S tou pamětí to není vůbec dobrý nápad :) Nedávno jsem si to bohužel ověřit. Zrovna hlavní strana se ale moc cahovat nedá. Tam bychbyl spíš pro zrušení počtu shlédnutí a např počet odpovědí bych zahrnul do sloupce "temata" at se nemusí spojovat. Nad trvalivostí jsem také přemýšlel - ale na durhou stranu - ono je taky dost možné, že díky google způsobují největší výtěž právě čtenáři starších topiců.

Spíš než mazání cache by to chtělo nějakou životnost. Když bude třeba 4 týdny téma bezezměny, tak se z cache vymázna a příštím přístupem uživatele se vytvoří nový soubor. Pokud uživatel nepřijde třeba dalších 6 měsíců, tak hurá - na 6 měsíců jsme ušetřili 30kB prostoru.

zobrazení jednotlivých threadů se v průměru pohybuje (odhadem) 100x (alespoň sekce PHP), někde to jde sice do tisíců, ale je to za několik let, skutečné počty zobrazení budou asi vyšší (uživatelé si 1 téma zobrazí několikrát), ale hlavní nápor bude IMHO na hlavní stránce
chtělo by to čísla, aby se dalo rozhodnou, jestli má smysl vytvářet cache hlavní stránky třeba na minutu

Alphard
IMHO je zbytečné jé cachovat na minutu. Spíš to chce nějak úsporně ji vytahovat z databáze

souki
důležitá jsou čísla, jestli se bavíme v řádu desítek, nebo možná i stovek ve špičce, tak si myslím, že to zbytečné není
naopak, jestli tak 20 a míň, tak asi ano
ta čísla neznám a netroufám si je odhadovat, píši to jako možnost

Alphard
Pokud se ale bude cachovat titulka na straně serveru, tak riskujeme skokovou zátěž - všem zároven se ukáže, že v jejich tématech jsou příspěvky.
Pokud na straně uživatele, tak zase riskujeme, že všichni budou mačkat ctrl+f5 a bud si nepomůžeme nebo bude zátěž vyšší

souki, Alphard
Nechápu, co řešíte. Nastavovat cachování po určitou dobu je IMHO blbost, prostě při přidání nějakého příspěvku by se cache hlavní stránky smazala a pokud by někdo tuto stránku navštívil a v cache by nebyla, vytáhla by se z DB a uložila zpátky do cache.

Když bude třeba 4 týdny téma bezezměny, tak se z cache vymázna a příštím přístupem uživatele se vytvoří nový soubor.
Jenže na této diskusi jsou témata, která se několik let nezměnila a přesto mají vysoký počet zobrazení. Například zvýrazněné příspěvky nebo některé zamčené, které jsou vysoko ve výsledcích vyhledávání.

Acci
Proto jsem pro nějakou speciální tabulku v DB. Měnit soubor při každém přidaném příspěvku je nesmysl, ptže to je asi každých 10 sekund.

Jedno z typických řešení výpisů, alá zdejší hlavní stránka je vytvoření "indexové" tabulky, ve které je udržován pomocí spouští aktuální obsah pouze pro tento problematický výpis. Počet zobrazení vlákna, dle mého názoru, je moudré vynechat - přeci jen je to nic neříkající údaj a zátež udělá znatelnou.

Koukám, že na hledání už hotového systému se rezignovalo?

habendorf
No já nevím, jsem tu už delší dobu a docela často, ale nějak omezovaný se necítím.
Tak jako já bych pár zlepšení vyjmenovat dokázal :-) Krom toho co napsal Yuhů bych jako uživatel zmínil odstranění stávajících chyb (zpětná lomítka, rozhození odkazů) lepší zobrazování zdrojového kódu a šlo by trochu vylepšit skriptování zasílání odpovědí- například když označím text a vložím nějaký tag, aby se tag vložil kolem toho označeného textu. Jo a mohly by i nám Operákům fungovat citace :)

Ad cache hlavní stránky: teď je otázka, jakým způsobem tu cache udělat. U klasického vygenerování hlavní stránky do souboru se bojím, že to bude mít větší režii, než kolik to ušetří výkonu.
Mimochodem, pro představu, příspěvky aktuálně na hlavní stránce mají poměr zhruba 15,46 zobrazení stránky na jednu odpověď. Ještě je potřeba připočítat editace a mazání příspěvků, ale podle mě to moc nebude, takže řekněme zobrazení:aktualizace 15:1.

Chamurappi
Nejčastěji se mění počet zobrazení, ten není tak důležitý, mohl by se vyhodit a místo něj ukazovat jméno zakladatele vlákna.
...a potom by šlo udělat cache hlavní stránky jako databázovou tabulku: id tématu, název, odpovědi, autor, poslední přispívající, datum-čas tématu, datum-čas posledního příspěvku.
A podle výše uvedeného by taková tabulka měla mít poměr zhruba 15 čtení na jednu aktualizaci. Navíc by šlo pravidelně odmazávat staré záznamy, takže další zrychlení.

Joker
Ten poměr zobrazení a zápisu bereš z hlavní strany. Ale u straších témat bude výrazně vyšší počet zobrazení

Co se týče počtů zobrazení, tak jsem si všiml, že tato verze miniBB započítává jen zobrazení první stránky vlákna. Hodně na tom tratí zdejší dvacetistránkové debaty :-)


Reaguji na soukiho:
„Uložit si jí nějak snadno dohledatelně (Id-strana.dat) a pak jí includovat (nutno odstranit nebezepčné konstrukce z obsahu)“
Nebo id-strana.xml a transformovat ji skrze XSLT přímo do HTML kódu.

„Ještě k tomu API - myslel jsem to asi takhle: Udělat pár veselých tříd“
API je docela divná přezdívka pro OOP :-)

„S tou pamětí to není vůbec dobrý nápad [...] Zrovna hlavní strana se ale moc cahovat nedá“
Zrovna u úvodní stránky by to myslím dobrý nápad byl, protože ta neroste.

Chamurappi
Hlavní strana se ale moc mění. Osobně si myslím, že daleko větší úspory dosáhneme cahováním statických starších vláken. Hlavní strana vlastně ukazuje poslední nejživější vlákna. Zde se chováním moc nezíská, protože seto musí pořád měnit. Naopak v prvních 20ti stránkách HTML&XHTML už se toho moc nezmění, ale hodně se to čte. Minimálně google by mohl. Stejně tak různá stará témta, která lidi vygooglí při hledání uploadu obrázků atd

K API - terminologie mi nikdy nešla :) Doplním si vzdělání

souki
Tahle cache by se měla používat na hlavní stránku, tak proto. Starší témata v tom nebudou hrát roli.

Jinak starší témata by se IMHO dala s výhodou generovat do souborů. Minimálně například kompletní stránky... navíc zhruba po dni nebo tak se tady zablokuje editace příspěvků, takže asi jediná možná změna je vymazání příspěvku moderátorem anebo změny v popiscích autorů (např. nový moderátor, někomu se dá popisek "hosting" a podobně). To se děje (ve srovnání s odesíláním/čtením příspěvků) málokdy, neměl by být problém, kdyby to prostě zneplatnilo cache dotčených vláken a kdyby si je někdo příště prohlédl, vygenerovaly by se znovu.

Joker
Ano. Tak jsem to myslel - starší témata do souborů. Příště budu popisnější.

Jak si tehcnicky představujete to udržování v paměti? Nevím jestli se úplně chápeme

Kdyby se přistoupilo k tomu, že se bude vyvíjet vlastní systém pro diskusi, tak
navrhují následující konkrétní kroky:

1) Svolání vývojářů pomocí diskuse. (Což se vlastně děje právě tady a teď, takže
hlaste se.)
2) Ustanovení vedení týmu.
3) Brainstorming, z něhož by vzešel návrhu programu (a řešily by se kravinky, co
tady teď řešíte, jako je cache apod.) a určil by se jazyk, v jakém se to bude psát.
PHP rozhodně není jediná možnost. Zvažoval bych Python.
4) Zřízení IRC, CVS, bugzilly a podobných hraček. Dohodnutí se na coding
standards a dokumentaci.
5) Rozdělení práce.
6) Stanovení plánu.
7) Vlastní vývoj systému, testování atp.

Viděl bych to tak na rok nebo dva a muselo by se najít pár lidí, kteří by měli
čas a chuť se tomu věnovat.

Já osobně na tohle čas nemám, a tak bych pracovat asi jenom na nějaké malé
části.

Polaroid
Připomíná mi to přednášku Seznamu "projektové řízení"....
Ten čas bych neviděl tak špatně. Osobně to vidím tak na 1-2 týdny veřejné diskuse. Pak tak týden multichatu v úzkých skupinkách nebo rovnou instantně. Pak tak měsíc vypracování do bety. Následně bude nějaká dlouhá oponentura kdy se budeme dohodovat co bude lepší. Pak sebereme odvahu a spustíme to. Během následujícího týdne se sejde tolik návrhů na změny, že brzy bude takřka dokonalá verze :)

souki
Mno, uvidíme. Já si myslím, že 2 týdny na vymyšlení všeho a 4,5 na napsání je
nereálné.

Chtěl jsem ale říct svým příspěvkem spíš to, že je třeba začít plánovat a
podniknout jasné kroky místo zbytečného tlachání.

Mějte prosím na paměti, že vytvoření nového enginu je jedna nikoliv jediná varianta. Pořád je ve hře adaptace miniBB2 nebo jiného fóra.

V každém případě, s Yuhůem se shodujeme na tom, že vytvoření základního jádra nové diskuse by byla s největší pravděpodobností one-man-show. Tomu by pochopitelně předcházela diskuse vnitřího okruhu vývojářů ohledně stanovení priorit a konvence. Až vytváření periferií by pak přešlo do širšího okruhu programátorů.

Tebou nastíněné rozložení projektu do velké šířky a délky, Polaroide, je cesta rovnou do pekel, to ti garantuju. Většina lidi spolu bude dělat poprvé a všechno tak půjde pomalu ale jistě do prdele. 90% práce budou muset udělat dva, maximálně tři lidi.

PHP rozhodně není jediná možnost. Zvažoval bych Python.
Opakuju, otázka interpreta nás netíží - engine vlastně nedělá nic jiného, než že posílá do výstupu databázové data obalené html tagy, Python není protřeba.

DoubleThink
Souhlas. Nejdřív by se mělo tlachat jak nejlépe vyřišit logiku jádra. Pak by měl jeden obětavec vyrobit nějakou OOP strukturu. Následně už se to může dělit na několik souběžných - ajax, mailování, rss, ...

DoubleThink
Bude to hodně práce, bude na to tedy potřeba hodně lidí a hodně času,
tak to vidím já. Časový odhad jsem možná trochu přehnal, protože je
to lepší, než si mazat med kolem huby a myslit si, že to bude hotovo za
dva měsíce; nebude. Snad jen kdyby tady byl někdo, kdo nemá na práci
nic jiného; je tady někdo takový?

Na zbytek tvého příspěvku reaguji mlčením však s lehkým úsměvem na
tváři a docela drobnou vráskou zloby na čele.

Yuhů - písal som ti na mail pred dvomi dňami... Daj mi vedieť či to k tebe dorazilo.