Spousta oprav

11.3.2007 12:50 | Abíčko |

O dnešní várku oprav jsem se podělil s Lubošem Doleželem, který se vrhnul na programování abíčka ve velkém.

681 - LD - správa obrázků v blogu
68 - LL - smazání fotky z profilu
512 - LD, LL - náhled ankety před odesláním
302 - LD, LL - systémové řešení duplicitních komentářů
658 - LD - javascriptový výběr datumu
720 - LL - bug v SQL při načítání FAQ sekce
619, 478 - LL - větší kontrola vstupních parametrů (asi stupidní boti)
574 - LL - hezčí stránka informující, že stránka neexistuje
698 - LL - přesměrovat stará URL mířící na Record na nadřazený objekt
647 - LL - snad konečně vyhovující podmínka pro report honorářů
686 - LL - chybka při náhledu vytvářeného inzerátu v bazaru

       

Komentáře

[trekker.dk]

574 - LL - hezčí stránka informující, že stránka neexistuje

Dokument se můžete pokusit najít pomocí našeho mocného fulltextového hledání.

Řekl bych, že to "mocné" je poněkud odvážné tvrzení. To hledání je dost pomalé a mám pocit, že Google se site:abclinuxu.cz dává lepší výsledky (ve smyslu že najde to, co jsem hledal)

[Leoš Literák]

Hledání je rychlé, pomalé je generování zvýrazněných částí nalezeného textu. Ten poměr je snad 1:10. Řešením bude zkusit upgrade na poslední verzi lucene.

Mocné je v tom, že můžete například omezit typ hledaných dat, to s googlem tak přesně neuděláte. Navíc se hledají skutečně jen data a ne marast ze šablony (ankety, zprávičky).

[Fuky]

Ábíčko je moc pěkně strukturované, takže i Google dokáže hledat jen v části, kterou zadám a je lepší mít více výsledků než, aby ten, o který stojím, nebyl nalezen:
site:www.abclinuxu.cz/blog
site:www.abclinuxu.cz/hardware
site:www.abclinuxu.cz/software
site:www.abclinuxu.cz/faq
site:www.abclinuxu.cz/poradna
site:www.abclinuxu.cz/ucebnice
site:www.abclinuxu.cz/zpravicky
site:www.abclinuxu.cz/clanky

Nebo ještě podrobněji:
site:www.abclinuxu.cz/clanky/programovani

Ale Ábíčko dokáže ve vyhledávání i selhat. Proč?

[Leoš Literák]

Protoze google ma vice programatoru nez abclinuxu

[Fuky]

Samozřejmě, že jsem to nemyslel jako buzeraci Vážím si Tě a toho co děláš pro Ábíčko... Zajímala mě odpověď na to v čem je v tomto případě problém. Ostatně zdrojáky jsou k dispozici a tam se odpověď najde

[trekker.dk]

Hledání je rychlé, pomalé je generování zvýrazněných částí nalezeného textu.

Aha.

[Leoš Literák]

Dal jsem treba hledat iso a hledani trvalo sest milisekund, pocet nalezenych dokumentu je pres tisic. To neni spatne, ze?

[trekker.dk]

Jo, to docela ujde. Dokonce je to lepší než Google se site:abclinuxu.cz (ten to má za 240ms).

Přes Rozšířené hledání to trvalo asi 300ms, takže mě napadl dotaz - které kategorie prohledává hledání přístupné ze všech stránek?

[Leoš Literák]

Vsechny.

[trekker.dk]

Tak to je zajímavé - jaktože hledání z hlavní stránky najde "iso" za 6ms a rozšířené vyhledávání ve všech kategoriích to má až za 250ms?

[Leoš Literák]

Rozsirene pridava dalsi field do hledani - kategorii. Nicmene pokud jsou vybrany vsechny kategorie, je tato dalsi podminka zbytecna a mohla by se odstranit => bugzilla

[pasmen]

Dolezel zni docela vtipne, chvalim.

[Leoš Literák]

PS aktualizoval jsem zdrojaky, doufam ze priste uz budu moci sdelit adresu CVS serveru

[trekker.dk]

Dopředu přiznávám, že ve verzovacích systémech se zase moc nevyznám, ale nebylo by lepší místo CVS nasadit SVN? Z toho, co jsem tady četl ve zprávičkách a v diskuzích, jsem pochytil, že CVS je považováno za zastaralé a dále se nevyvíjí.

[Leoš Literák]

Nejspise jo, ale ja jsem staromilec Navic casu mam tak malo, nechci jej travit experimentovanim s necim novym, kdyz to stare ovladam a vim, jak funguje.

[Filip Jirsák]

Nevím, zda se CVS nevyvíjí, zastaralé jsou spíš některé jeho principy – zejména to, že přejmenováním souboru se ztratí jeho historie. A pak to, že každý soubor je verzován zvlášť. Na druhou stranu, CVS má obrovskou podporu ve všech možných IDE a nástrojích, SVN je na tom znatelně hůř. Např. v eclipse je možné pracovat s CVS přímo z IDE naprosto bez problémů (checkout, commit, vytvoření branche, prohlížení historie atd.). Pro SVN existují minimálně dva pluginy do eclipse, ale každý má své mouchy. V poslední době se snad ledy hnuly a bude alespoň jeden normálně použitelný…

A pro Abíčko myslím nevýhody CVS oproti SVN nebudou moc znatelné, protože CVS pro Abíčko je důležité jednak proto, aby byly aktualizované zdrojáky brzy k dispozici a nedalo jejich zveřejnění moc práce, jednak se proti CVS daleko lépe dělají patche (třeba v eclipse je to pár kliknutí, udělat patch proti lokální kopii originálu se mi v eclipse nepodařilo).

[petr_p]

Vyvracet kvalitu verzovaciho systemu (ne)schopnosti nejakeho IDE se mi zda ponekud nestastne.

[Filip Jirsák]

Psal tady někdo něco o kvalitě verzovacího systému? Já jsem psal pouze o tom, proč je v tomhle konkrétním případě asi lepší použít CVS, i když je v něčem horší, než SVN. Pro programátora je to "nějaké IDE" daleko podstatnější, než rozdíl mezi CVS a SVN.

[petr_p]

Aha. Chapu. Ale stejne si rypnu: Az nekdo forkne Abicko, tak budou ten i Leos CVS proklinat :)

[Leoš Literák]

Spustil jsem jstat na jetty a koukam na jednotliva vlakna. Spousta jich ceka v poolu, dalsi cekaji v IO operacich, ale nezanedbatelne mnozstvi spi zde:

Thread 10561: (state = BLOCKED)
 - java.util.Collections$SynchronizedMap.get(java.lang.Object) @bci=7, line=1979 (Interpreted frame)
 - org.dom4j.tree.QNameCache.get(java.lang.String) @bci=11, line=88 (Interpreted frame)
 - org.dom4j.QName.get(java.lang.String) @bci=4, line=86 (Interpreted frame)
 - org.dom4j.QName.get(java.lang.String, java.lang.String, java.lang.String) @bci=16, line=95 (Interpreted frame)
 - org.jaxen.dom4j.DocumentNavigator.getChildAxisIterator(java.lang.Object, java.lang.String, java.lang.String, java.lang.String) @bci=19, line=241 (Interpreted frame)
 - org.jaxen.expr.iter.IterableChildAxis.namedAccessIterator(java.lang.Object, org.jaxen.ContextSupport, java.lang.String, java.lang.String, java.lang.String) @bci=17, line=100 (Interpreted frame)
 - org.jaxen.expr.DefaultNameStep.evaluate(org.jaxen.Context) @bci=348, line=231 (Interpreted frame)
 - org.jaxen.expr.DefaultLocationPath.evaluate(org.jaxen.Context) @bci=87, line=151 (Interpreted frame)
 - org.jaxen.expr.DefaultAbsoluteLocationPath.evaluate(org.jaxen.Context) @bci=90, line=117 (Interpreted frame)
 - org.jaxen.expr.DefaultXPathExpr.asList(org.jaxen.Context) @bci=7, line=108 (Interpreted frame)
 - org.jaxen.BaseXPath.selectNodesForContext(org.jaxen.Context) @bci=5, line=687 (Interpreted frame)
 - org.jaxen.BaseXPath.selectNodes(java.lang.Object) @bci=8, line=233 (Interpreted frame)
 - org.jaxen.BaseXPath.selectSingleNode(java.lang.Object) @bci=2, line=252 (Interpreted frame)
 - org.dom4j.xpath.DefaultXPath.selectSingleNode(java.lang.Object) @bci=10, line=159 (Interpreted frame)
 - org.dom4j.tree.AbstractNode.selectSingleNode(java.lang.String) @bci=8, line=185 (Interpreted frame)

Zkusim se poptat v DOM4J komunite nebo nastudovat zdrojaky. Mozna zkusim pouzit whirlycache mapu na synchronizaci.

[Filip Jirsák]

Nejjednodušší řešení bez zásahu do zdrojáků dom4j je použít org.dom4j.util.PerThreadSingleton místo org.dom4j.util.SimpleSingleton. Sice se nebudou cache používat napříč thready, takže bude o něco větší spotřeba paměti i bude nutné některé objekty znovu vytvářet, ale to asi bude pořád lepší, než vzájemné zdržování vláken. Mělo by fungovat nastavit systémovou vlastnost org.dom4j.QName.singleton.strategy=org.dom4j.util.PerThreadSingleton.

Další řešení (spíš hack) by bylo oddědit z org.dom4j.util.SimpleSingleton vlastní SingletonStrategy, který bude natvrdo pro třídu org.dom4j.tree.QNameCache vracet jejího potomka, který by byl postaven na jiné cache (přímo určit, která implementace cache se použije nejde, ve zdrojáku je natvrdo singleton.setSingletonClassName(QNameCache.class.getName())).

Nejčistší řešení je upravit dom4j tak, aby bylo možné přes systémovou vlastnost určit třídu místo defaultní QNameCache, a QNameCache přepsat s využitím nové ConcurrentHashMap z Javy 5. S protlačením takové změny do dom4j 1.7 asi problém nebude, protože 1.7 už má být pouze pro Javu 5, ale ofifiální verze 1.7 asi jen tak brzy nebude.

[Leoš Literák]

Diky, ani jsem se nestihl podivat do zdrojaku dom4j a ty uz mas tolik variant Pokud jde o DOM4J, myslel jsem, ze projekt zamrznul, kdyz jsem jej naposledy kontroloval, nevidel jsem zadnou aktivitu.

[Filip Jirsák]

DOM4J zamrznul, pak se toho někdo chopil, že se bude vyvíjet verze 1.7, která už bude jen pro Javu 5 a bude podporovat generiky, nové iterátory atd. Ale nějak moc to kupředu nejde. Je to škoda, protože DOM4J je dobrá knihovna. Nějaké změny do ní budu mít, tak aspoň otestuju, jak reaguje nový správce projektu Fork se dá udělat vždycky…

[Leoš Literák]

Nastaveno, restartovano. Zatim se abicko zda bleskove, ale zdani casto klame a navic je ted cerstve zrestartovane, takze nemelo cas se zadychat. Uvidime zitra dopoledne