Úpravy diskuse • 2010–2011 (hotovo)

Mohla by klávesa L generovat zkrácenou URL i s kotvou?

Nevím, jestli to tu už nebylo, ale našel jsem jeden topic, kde se řešilo, že by se odkaz na .sandbox automaticky přeměňoval na odkaz bez sandboxu. Já bych to ještě upravil tak, že pro ty v sandboxu by tam sandbox zůstal, ale na diskusi bez něho by se to gumovalo.

„Já bych to ještě upravil tak, že pro ty v sandboxu by tam sandbox zůstal, ale na diskusi bez něho by se to gumovalo.“

Tak by to mělo teď fungovat, nebo to tak není?

Str4wberry:
Aha, tak ono to je jinak, omlouvám se, moje chyba. Jen jsem mrknul, a ta adresa zůstavala stejná. Až po kliknutí to přesměruje.

Neblbne nám ten JUSH trochu?

habendorf:
Proč? Nic zvláštního nepozoruji. Akorát neobarvené </script> a </style>, ale to snad nebarvil nikdy.

Jan Tvrdík:
„Akorát neobarvené </script> a </style>“
Jo, to jsem měl na mysli.

„ale to snad nebarvil nikdy.“
Aha, já si toho dříve nevšiml.

Vím, že to není až tak podstatné, ale na druhou stranu to není ani nijak časově náročné.

Dnes tu přibylo další vlákno, v němž se vyskytuje (i v titulku) do očí nepříjemně bijící „mozzila“. Ptám se tedy, bylo by možné při odeslání příspěvku nahrazovat „mozzil_“ za „mozill_“?

Zdánlivě je to maličkost, ale nějak si na to nemůžu zvyknout. To jedno nahrazení by za to stálo, ne?

Děkuji.

panther:
Já bych to snad nahrazoval rovnou slovem Fiefox, protože nikdo už nepíše o prohlížeči Mozilla Suite a psát o prohlížeči Mozilla Firefox jako o Mozille mi připadá stejně nejapné, jako psát o někdejším Microsoft Internet Exploreru (dnes Windows Internet Explorer) jako o Microsoftu nebo o Internetu.

Reaguji na DoubleThinka:
„Předkládám k diskusi návrh zobecnit protivytahovací ochranu na všechny návštěvy, které přijdou z nějakého vyhledávače (kontrolou refereru).“
Dobrý nápad.


Reaguji na mylana:
„Ak má nejaké téma 11 strán, tak v stránkovaní je vidieť len 10 strán.“
Už jsem na to také upozorňoval. Moc to nevadí.


Reaguji na Lextera:
„Nebylo by možné barvit poslední diskuse na zebru?“
Bylo. Dokonce jsou na to v kódu i připravené třídy. Můžu to udělat nastavitelné.


Reaguji na panthera:
„To jedno nahrazení by za to stálo, ne?“
Ani ne. Vyrábět jednu kontrolu speciálně kvůli Mozzile je divné, ne?


Reaguji na Miloše:
„Já bych to snad nahrazoval rovnou slovem Fiefox“
Má jiný vzor i rod, s automatickým nahrazením by byl problém.

„psát o prohlížeči Mozilla Firefox jako o Mozille mi připadá stejně nejapné“
Já tedy nazývám Firefox v drtivé většině případů Mozilla, protože je to nadčasově stabilní pojem pro vykreslovací jádro. Netscape 8, Mozilla Suite, Seamonkey, Mozilla Phoenix, Mozilla Firebird, Mozilla Firefox, Flock, K-Meleon, Camino, Galeon — všechno hodím do jednoho pytle s cedulkou „Mozilla“. Nemá smysl je od sebe rozlišovat a technicky přesnější „Gecko“ není tak známé, krom User-Agenta se s ním člověk nepotká.
Mně zase připadají nejapné výkřiky „Firefox není Mozilla“.

Jenom bych chtěl připomenout téma http://diskuse.jakpsatweb.cz/?action=vthread&forum=18&topic=93866 o inline kódu. Tato funkce by se mi rozhodně líbila.

Reaguji na keeehiho:
Už je na seznamu.

Chamurappi:
Tak se omlouvám, ten seznam jsem četl, ale nějak jsem to přehlédl.

Napadlo mě rozlišovat témata, která už našla řešení a která ne. Často je v některém tématu mnoho příspěvků, ale autor stále nemá odpověď na první otázku, naopak někde už autor odpověď má, ale není to na první pohled vidět a bych zjistil, zda stále potřebuje pomoc nebo ne, musím se prostě podívat dovnitř :-).

Pokud nevíte, o co mi jde, tak aby kromě tlačítka zamknout téma existovalo i tlačítko problém vyřešen nebo tak něco. Pak bylo na první pohled (třeba z ikony tématu) vidět, jestli mám otevírat téma nebo ne.

Zamknutí tématu je sice také řešení, ale:
(1) Nikdo to nepoužívá
(2) I přesto, že autor už zná odpověď, může mu někdo chtí něco doporučit, nebo nabídnout lepší řešení.

Omlouvám se, jestli se to tu už řešilo, všechno jsem nečetl.

nešel jsem problém při vytváření odkazů
pokud zadám adresu pčes to tlačítko nahoře v tomto tvaru: http://diskuse.jakpsatweb.cz/?action=vthread&forum=9&topic=2111#najdi(headers) tak je to vpořádku.
Pokud zadám jenom adresu http://diskuse.jakpsatweb.cz/?action=vthread&forum=9&topic=2111#najdi(headers) udělá to to, co to udělalo (vynechá to závorku na konci)
ale hlavně pokud chci zdat [url=http://diskuse.jakpsatweb.cz/?action=vthread&forum=9&topic=2111#najdi(headers already sent)]odkaz[/url]
tak se na to "already sent" vykašle nebo to nevytvoří odkaz vůbec, ať to dělám jakkoliv.

Dodělal jsem v sobotu do tabulky s příspěvky řádek upozorňující na délku časové prodlevy, která uběhla mezi odesláním příspěvků. Co na to říkáte? (V sandboxu.)


Další úpravy, které jsem udělal:
(K3.4) √ Zlikvidovat <br> za blokovými elementy (výpisy kódů, <hr>, moderátorská poznámka).
(K3.7) √ Dovolit moderátorům přispívání do zamčeného vlákna.
(K3.15) √ Upravit [pre], aby dokázalo tvořit řádkový <code>.

Nečíslované:
• Listování - pevně nastavené řazení — opravil jsem sortBy.
• Problém s registrací jména Šůběrťáďa Žéňačíř Úďošťrócký — přidal jsem znaky s diakritikou.

Myslím, že by řádek s ní mohl mít bílé pozadí, čímž by se výrazněji oddělily příspěvky zaslané po delší době.

Chamurappi: pekné, rozmýšľal som kde sa to tu vzalo... Čo takto natiahnuť to na celý riadok (colspan="2")?
Str4wberry: +1

Návrh:
Vizuálně odlišit téma v seznamech vláken, pokud se poslední přispívající shoduje se jménem uživatele. Případně ho i (volitelně) nezobrazovat.

Motivace:
Téma, ve kterém jsem posledním přispívajícím, je pro mě zpravidla nezajímavé, protože jsem tam řekl, co jsem chtěl. Při zobrazení nových příspěvků takové téma bývá nahoře a musím porovnávat jméno posledního přispívajícího, abych zjistil, jestli už mi někdo odpověděl (a tedy je téma pro mě opět zajímavé).

Zdá se mi to přínosné a implementačně snad poměrně jednoduché. Zběžně jsem to tu pročetl a nenašel jsem stejný návrh.

Když už se tu "3m" stalo defacto standardem pro přivolání moderátorů, nemělo by se to zakázat v přezdívkách?
Viz Přípočet hodiny k datu

Reaguji na Str4wberryho:
„by řádek s ní mohl mít bílé pozadí“
Kdyby měl vždy bílé pozadí, asi by to zbytečně bilo do očí, pokud je prodleva malá. Ale jelikož nastavuji třídu odstupňovaně podle délky — víc jak rok, víc jak měsíc, víc jak týden, víc jak den — můžu velké prodlevy snadno odlišit. Bílé pozadí je u prodlev delších jak rok, skoro-bílé pozadí u prodlev delších než měsíc (k vidění na první stránce tohoto vlákna).


Reaguji na tisa:
„Čo takto natiahnuť to na celý riadok (colspan="2")?“
Zkoušel jsem, ale informace o prodlevě nalepená nad jménem dalšího přispěvatele mi připadala rušivá. Zkoušel jsem ten text zarovnat i doprostřed a pak i doprava, ale ze všech možností mi nejlepší připadá tato.


Reaguji na Jokera:
Viz návrh K3.1.b.

Nevím, zda někdo něco dělá v SVN. Dohodli jsme se, že sem budeme psát, kdo co udělá, ale nikdo nic nepíše. Chtěl bych proto trochu přeorat harmonogram verzí — odložit velká rozhodnutí do dalšího balíku úprav a tu hromadu drobností, které jsou na seznamu a z nichž jsem už část udělal, nasadit nejpozději někdy během dubna či května. Říkejme tomu třeba verze 1.7.

Nevím, zda někdo něco dělá v SVN.

Letos žádná změna. Naposledy na Vánoce.

Já vyčkávám. Nevím, jak dopadne nynější trunk. Honza tam tenkrát udělal změny, aby se dobře ladily dotazy, ale také se mu podařilo místo přesunutí souboru je nejdřív smazat a udělat nový, čímž se rozbořila jejich vazba. Umíte to někdo napravit? A ani nevím, na které verzi se počítá stavět.

Ale osobně bych tam chtěl upravit asi jen
jush - Jakub má pár změn + obarvení code, pokud to je žádoucí
sitemapa - mapu kategorií, tak aby se dala nastavit pro listování malá priorita (malou bych dal i pro u ledu)
link canonical - pro vlákna s parametrem page=-1 znamenající poslední stránku
při nesmyslném action vracet 404
A možná bych zkusil implementovat K3.16.

Další spíš, když budete chtít. Abych tam nenadělal víc škody než užitku :-)

Z mého pohledu to SVN nebyl nejlepší nápad. Pro mě to znamenalo, že jsem od DJPW 1.5, čekaje na synchronizaci ostré verze, sandboxu a SVN, neudělal snad nic. A teď mi přijde, že nejvíc úprav udělal Chamurappi až teď, když začal upravovat diskusi jako dříve, kdy jsme neměli SVN.

Dále si říkám, jestli je pro náš vývoj skutečně nutné mít více vývojových verzí. Příklad: Jan Tvrdík předělal většinu PHP skriptů, takže se nedají jednotlivě nahrát do sandboxu. No, a když v jednom (např. bb_func_ldisc.php) chci provést nějaké vylepšení diskuse, tak to musím provádět ve dvou souborech — tedy v sandboxu a stejně tak ve vývojové verzi na SVN, ne?

Problém SVN je, že se nepoužívá. SVN musí být primární a sandbox sekundární. Naopak to fungovat nebude. Pokud se tedy nějaká úprava objeví v sandboxu dříve, než na SVN, je něco špatně. (Změny v sandboxu jsou nedohledatelné, změny v SVN dohledatelné jsou.)

Na SVN je v současnosti trochu zmatek v adresářích, ale jediný adresář, kam má v současnosti smysl sahat a kam posílat změny je branches/1.5.2-dev. Adresář trunk (2.0-dev) čeká na mě, ale v žádném případě by neměl být důvod k zastavení nebo zpomalení vývoje. Kdybych v době jeho tvorby věděl to, co vím dnes, tak bych si ho asi nechal na disku, bylo by s tím méně zmatků.

„Jan Tvrdík předělal většinu PHP skriptů“
Myslel jsem, že to zvládnu dodělat dříve. V současnosti je nejlepší adresář trunk přehlížet.

„když v jednom chci provést nějaké vylepšení diskuse, tak to musím provádět ve dvou souborech“
Nejprve musí být změna vždy na SVN. Překopírování změněných souborů do sandboxu trvá tak minutu (= maximálně 5 minut) a spočívá v zjištění změněných souborů (pár kliků v Tortoise SVN), připojení na FTP a překopírování.


V trunku bych chtěl dodělat ještě 2 zásadní věci týkající se bezpečnosti, protože v současnosti diskuse pracuje s hesly téměř jako s plain textem.

„Nejprve musí být změna vždy na SVN.“

Mně šlo o to, že až doděláš trunk do nasaditelné podoby, tak se do jeho souborů budou muset ručně doplňovat a upravovat novinky, které už teď jsou v jiné větvi — ty v sandboxu. To se žádnými pár kliknutími v Tortoise SVN nevyřeší, nebo ano?

Reaguji na Alpharda:
„Nezkoušel jsi třeba u starších vláken nějak výrazněji odlišit nové příspěvky (nově přidané třeba po týdnu od předchozích)?“
Nezkoušel. Co konkrétně by sis představoval? Nechtěl bych zasahovat do řádků s příspěvky. Pokud přidám nějaký druh čáry, objeví se lidé (nebo alespoň _es :-)), kteří se budou ptát, co má tato čára společného se všemi ostatními čárami.

„Bylo by moc agresivní zesvětlit pozadí buňky se jménem autora?“
Myslím, že bylo. Mám to zkoušet? Existují i vlákna, u kterých časové prodlevy nejsou vůbec důležité — třeba zrovna tohle.


Reaguji na Kajmana:
„obarvení code, pokud to je žádoucí“
S tím budou problémy, protože do <code> se budou obalovat i kousky kódu, u kterých JUSH nemůže snadno uhodnout kontext. Budeme zavádět i [prehtmlattr], [precssprop] atd.? (Toto by bylo lepší řešit jinde.)

„sitemapa - mapu kategorií, tak aby se dala nastavit pro listování malá priorita (malou bych dal i pro u ledu)“
Bude-li vlákno u ledu a robot ho tam zaindexuje, pak ho smažeme/přesuneme jinam, bylo by dobré, kdyby si toho vyhledávač všiml co nejdřív => kategorie, ve které je největší pravděpodobnost velkých změn, by měla mít naopak vysokou prioritu. Nebo ne?

„link canonical - pro vlákna s parametrem page=-1 znamenající poslední stránku“
Jestli známe správné číslo poslední stránky, tak bychom na ni měli spíš přesměrovávat, ne záplatovat duplicitu.


Reaguji na Str4wberryho:
„jsem od DJPW 1.5, čekaje na synchronizaci ostré verze, sandboxu a SVN, neudělal snad nic“
Také jsem se cítil paralyzován. Nevěděl jsem, co se má dít dál, brzdila mě obava, abych neudělal něco nesystémového. Nakonec ale zvítězila chuť se v tom vrtat :-)

„Dále si říkám, jestli je pro náš vývoj skutečně nutné mít více vývojových verzí.“
Tahle otázka už visí ve vzduchu delší dobu. Problém velkých změn je, že trvají moc dlouho. A navíc s nimi od Vánoc nikdo nehnul — což je přesně ten stav, kterého jsem se bál v listopadu, kdy jsem říkal, že chci nasazovat do ostrého provozu drobné úpravy nezávisle na tom, co se děje v té skvěle překopané verzi 2.0. Mnoho lidí mi tenkrát oponovalo, že správa více verzí bude problematická a že nikdo nebude chtít řešit kolize. Dobře. Tak jsem si dal (další) několikaměsíční pauzu — tentokrát ne kvůli čekání na nasazení sandboxu do ostré verze, ale kvůli čekání na nasazení 2.0-dev do sandboxu. Netušil jsem vůbec, co přesně a jak se má změnit ve 2.0-dev. Místo velké sněhové koule jsme měli u nohy vězeňskou.


Reaguji na Jana Tvrdíka:
„SVN musí být primární a sandbox sekundární“
Sandbox je pro mě jediné místo, kde můžu zkoušet upravené PHP skripty. (Nicméně nechci se v úpravách PHP nadále angažovat.)
Na mém místě bych se raději neomezoval, sandbox je přeci pískoviště, nechal bych mě, ať si hraju. Opatrně a nekonfliktně.

„(Změny v sandboxu jsou nedohledatelné, změny v SVN dohledatelné jsou.)“
Před každou úpravou sandboxu si dělám kopii minulé verze a ty jsi u změn v SVN rozbořil vazbu, takže sice chápu, o co ti jde, ale jsme v podobné situaci.
Své úpravy sandboxu můžu zítra nahrát do SVN.

„branches/1.5.2-dev“
Neznačí setinky u verzí obvykle jen minimální úpravy, respektive opravy chyb? Verze 1.5.1 byla pouze servisní, ta následující ovšem přidá řadu novinek. Lépe by na ni asi sedělo číslo 1.6-dev nebo 1.7-dev.

„V současnosti je nejlepší adresář trunk přehlížet.“
Beru to jako rozhřešení. Děkuji :-)
Takže stejně máme na stole paralelní vývoj více verzí, se všemi jeho neduhy, na které jsem byl ze všech stran upozorňován.

Str4wberry:
„To se žádnými pár kliknutími v Tortoise SVN nevyřeší, nebo ano?“
Teoreticky by to při správném namapování (to tam teď není) mělo jít sloučit automaticky, ale v praxi to budu muset poslučovat ručně, protože ty změny nejsou vždy 1:1. Až bude jádro 2.0 stable, tak to udělám (když jsem si ty úpravy taky vymyslel, že).

Chamurappi:
„Své úpravy sandboxu můžu zítra nahrát do SVN.“
Budu se těšit.

„Lépe by na ni asi sedělo číslo 1.6-dev“
Máš pravdu, aktualizoval to v SVN.

Nebolo by lepšie, ak by boli značky pre kód s definovaným jazykom napríklad [prejs] radšej v tvare [pre js]?
Potom by to bolo viac podobné používaniu html značiek a nevyzeralo by čudne, že sa [prejs] ukončuje [/pre].
A na prvý pohľad by bolo vidno, že to je len upresnený tvar značky [pre].
Alebo by sa, zrejme z tohoto dôvodu, nemuseli dodatočne vymýšľať dva tvary uzatváracích značiek.
Asi by to aj v niektorých prípadoch uľahčilo prácu s regulárnymi výrazmi.
A mohlo by to aj do budúcnosti umožniť ľahšie zavádzanie nejakých ďalších príznakov značiek.