« 1 2 3 4 5 6 7 8 9 10 11
Autor Zpráva
Alphard
Profil
Kajman:
Mně by stačilo tak 150 dní, možná i míň. Spíš by se ale pak do dobudoucna hodil odkaz vedoucí zároveň na další stránku a prodloužení časového intervalu.

Chamurappi:
Přejmenování dle číslování verzí by mohlo pomoci, ale v převedení pod účet Admina kromě lepší dohledatelnosti (kterou lze řešit jinak) moc výhod nevidím.
Jan Tvrdík
Profil
Chamurappi:
Měl by někdo námitky proti nabarvení textových formulářových prvků?
Nevidím sice důvod, ale proti nejsem.

Kajman:
Líbilo by se mi něco jako TODO
Na SourceRepo mám možnost doinstalovat Trac nebo Redmine. Osobní zkušenost nemám ani s jedním z nich.
tiso
Profil
Chamurappi: na tie verzie ideš trošku zle...
Ideálne celý vývoj prebieha v trunk-u, z neho občas spravíš branch (paralelnú vetvu vývoja, s názvom, ktorý ho čo najlepšie vystihuje), ktorý sa časom buď ukončí, alebo pripojí naspäť do trunk-u. Pokiaľ robíš nejaký release, tak ten commit otaguješ číslom verzie, takže ho vieš ľahko nájsť a máš k dispozícii všetky releasy ktoré sa kedy robili.
V tom tvojom nevidím trunk a branchom dávaš názvy vhodné pre tagy...

Otázka znie ako tento systém práce nasadiť na terajší stav vývoja diskusie. Ideálne by bolo poskladať cestu od originálnej inštalácie miniBB cez najstaršie úpravy po stále novšie a novšie (všetky, ktoré sú doteraz nasadené na live), a toto dať ako trunk... Samozrejme treba otagovať dôležité medzníky. Z tejto hlavnej vetvy odbiehajú branche ako zmeny, ktoré sa postupne skúšali v sandboxe, bod, keď sa sandbox nasadil na live by mal byť merge do trunk-u.

Ešte jedna vec: vyrábať branch-e, na ktorých sa nepracuje, nemá zmysel, je lepšie počkať s nimi až keď sa na nich skutočne začne pracovať (medzitým sa nejaký iný branch môže pripojiť naspäť k trunk-u). Keďže sandbox je len jeden, tak v podstate by mal byť len jeden branch v čase... Veci, čo sa budú rovno nasadzovať, by sa mali comitovať rovno do trunk-u. Druhá možnosť je na live dávať releasy a do sandboxu trunk.
Kajman_
Profil *
Alphard:
Mně by stačilo tak 150 dní, možná i míň.

150 mi přijde celkem optimální.

Chamurappi:
Když je to v setupu, tak to asi není třeba hrnout do SVN, ne? To by se mohlo upravit růčo. Ten druhý výskyt této proměnné je pro nastavení proměnné, která je zapoznámkovaná, takže se to používá jen pro to vyhledávání.

Alphard:
Spíš by se ale pak do dobudoucna hodil odkaz vedoucí zároveň na další stránku a prodloužení časového intervalu.

Vyhledávání je asi jediná věc, co bych tu chtěl více pošolichat. Můžu to tam nachystat - a třeba jen tam, kde bylo nalezeno málo příspěvků nebo jen na poslední stránce vyhledání - což je vlastně i stránka s málem příspěvků :-) Ale tohle, až na to bude ten správný čas.
Alphard
Profil
Kajman:
a třeba jen tam, kde bylo nalezeno málo příspěvků nebo jen na poslední stránce vyhledání - což je vlastně i stránka s málem příspěvků
Nějak tak jsem to myslel, nejdříve jsem to měl popsané ve složitém souvětí, ale pak jsem to osekal.

Ale tohle, až na to bude ten správný čas.
Nenastal už teď? Máme SVN, tak můžeme pracovat na více vylepšeních najednou. Vím, že je cílem stihnout to nejdůležitější co nejrychleji, ale mám trochu strach, že omezíme funkčnost a pak se bude půl roku čekat na novou verzi. Tohle je docela triviální úprava, tak bych ji možná ani neodkládal.
Chamurappi
Profil
Brrr, teď byl ale ošklivý výpadek (tři čtvrtě hodiny).


Reaguji na Kajmana:
Když je to v setupu, tak to asi není třeba hrnout do SVN, ne?
Myslíš ten $defDays=365?
Já bych ho klidně snížil ještě víc. Sám hledám buď v posledních 10 dnech, nebo v 3650 dnech, na cokoliv jiného používám Google, Seznam a Bing.

ta konstanta se tuším používa i u posledních témat či příspěvků ve statistikách uživatele
Myslím, že ne. O $defDays je zmínka jen v zakomentované části bb_func_stats.php.

Líbilo by se mi něco jako TODO, aby se ty nápady, co se trousí ve vláknu o nové verzi, byly asi v SVN sesumírované.
Nemůžou být sesumírované na diskusi? (Všem na očích.)


Reaguji na tisa: (a dodatečně doplňuji čísla)
1.na tie verzie ideš trošku zle...
Vyšel jsem z toho, co psal Jan Tvrdík. Paralelní vývoj více verzí naráz je možný, ne?

2.V tom tvojom nevidím trunk a branchom dávaš názvy vhodné pre tagy...
Nemyslím si, že jsem něco nějak nazval. Všehovšudy jsem udělal jeden commit :-)

3.ten commit otaguješ číslom verzie, takže ho vieš ľahko nájsť a máš k dispozícii všetky releasy ktoré sa kedy robili
To je sice hezké, ale pro nás nepříliš potřebné.

4.Ideálne by bolo poskladať cestu od originálnej inštalácie miniBB cez najstaršie úpravy po stále novšie a novšie
Za sebe mohu klidně dodat všech 40 verzí djpw.js od 1. ledna do dneška :-)
Ovšem nenapadá mě, k čemu by to bylo.

5.vyrábať branch-e, na ktorých sa nepracuje, nemá zmysel
Chtěl bych vyrobit další javascriptové vychytávky, ty budou nezávislé na změnách v PHP, takže se mohou nasadit dřív. Stejně tak lepší verze bb_codes.php (s řádkovým [pre]/[code]) by nemusela čekat na dodělání úprav v databázi.

6.Keďže sandbox je len jeden, tak v podstate by mal byť len jeden branch v čase...
To je fakt. Nicméně počet sandboxů není ničím omezen, ne? :-)


Reaguji na Alpharda:
Spíš by se ale pak do dobudoucna hodil odkaz vedoucí zároveň na další stránku a prodloužení časového intervalu.
Současné rozhraní pro vyhledávání bude v budoucnu používané ještě méně než teď.
Kajman_
Profil *
Chamurappi
Myslíš ten $defDays=365?
Přesně ten :-)

A SVN bych nedělal teď moc paralelně. HT dal delete insert místo move a teď mi to nejde zmergovat. Chtělo by to někoho, kdo tomu rozumí, jestli by se to nějak přes konflikty nedalo opravit.
Jan Tvrdík
Profil
Kajman:
A co chceš vlastně mergnout?
tiso
Profil
Chamurappi: skáčeš z jednej veci na druhú... V prvom odstavci som popísal ako sa bežne pracuje s SVN, v druhom návrh ako poskladať doterajší vývoj do SVN a v treťom ďalšie návrhy na prácu s SVN...
[#6] reakcie na tvoje reakcie na mňa:
1. Paralelný vývoj je možný, ale diskusia je len jedna... Paralelný vývoj so sebou prináša zbytočné problémy pri spájaní vetiev, riziko duplikovania funkcií, ... Pri sériovom vývoji sa každý opiera o kmeň (=využíva spoločný hotový kód) a nemusí si na všetko písať vlastný, ktorý nikto druhý nevyužije, lebo ňom nevie...
2. doplním svoju vetu: ...v tvojom návrhu na premenovanie...
3., 4. bol to návrh, samozrejme že nemá zmysel dávať dokopy všetky postupné zmeny, išlo mi skôr o niečo iné - spraviť strom miesto trsu trávy (samostatné paralelné vetvy), viď 1.
5. ešte raz: ...na ktorých sa nepracuje...
6. opäť: bol to len návrh.
Kajman_
Profil *
Jan Tvrdík:
A co chceš vlastně mergnout?
Změny mezi 1.5 a 1.5.1 přidat do trunku. Hlásí to kolize na těch souborech, co byly špatně přejmenovány. Nevím, jak na to, taky jsem svn začátečník.

A až později mi došlo (asi po tisově příspěvku), že v tom tags by vlastně se nemělo nikdy nic upravovat. Příště si asi dát verzi do branches a až bude otestovaná a nasazená, tak ji označit tagem s verzí do toho tages. Pardon, že dělám zmatky :-)
Chamurappi
Profil
Reaguji na tisa:
skáčeš z jednej veci na druhú
Pardon.

Paralelný vývoj so sebou prináša zbytočné problémy pri spájaní vetiev, riziko duplikovania funkcií,
Pokud se pracuje na různých částech, je riziko malé. Tato diskuse jako celek nemá jeden kmen. JavaScript má svůj kmen, HTML/CSS má svůj kmen, PHP má svůj kmen. Musíme si dát bacha na styčné plochy, ale jinak není paralelní vývoj až tak nemožný.

v tvojom návrhu na premenovanie...“ „nevidím trunk a branchom dávaš názvy vhodné pre tagy...
Asi nerozumím. Řeč byla o názvech vláken, chtěl jsem, aby nesla název podle cílové verze. Žádné trunk-vlákno nemáme a nebudeme mít. (Asi.)


Reaguji na Kajmana:
v tom tags by vlastně se nemělo nikdy nic upravovat
SmartSVN mi tvrdil totéž, když jsem tam commitoval.
tiso
Profil
Chamurappi:
Tato diskuse jako celek nemá jeden kmen. JavaScript má svůj kmen, HTML/CSS má svůj kmen, PHP má svůj kmen.
Že sú tieto veci fyzicky oddelené (iné súbory, iné adresáre) neznamená že sú samostatné. Potrebuješ ich meniť naraz.
edit: nie je problém meniť ten istý súbor, len je aby sa zmeny navzájom neovplyvňovali nežiadaným spôsobom.

Řeč byla o názvech vláken, chtěl jsem, aby nesla název podle cílové verze.
[29] „Možná by bylo dobré, kdyby zde každá verze měla své vlákno. Též bychom měli všechno číslování podřídit číslům verzí.
Cieľové verzie existujú len na papieri, nevieš zaručiť že 1.5.1 bude 1.5.1 a 1.5.2 bude 1.5.2, lebo to, čo chceš nazvať 1.5.2, môže byť hotové skôr, alebo príde nová vec, ktorá ju predbehne. Poznáš iba verzie ktoré už sú otagované.
Ďalej je rozdiel medzi nápadmi na úpravy diskusie a skutočne realizovanými úpravami. Takže zmysel má označiť tie nápady, ktoré sú realizované/zamietnuté, buď priamo vo vlákne s nápadmi, alebo dať dokopy changelog, kde by sa písalo čo bolo spravené, prípadne oboje. Vzory: http://diskuse.jakpsatweb.cz/?action=vthread&forum=18&topic=87504&page=0#4 http://diskuse.jakpsatweb.cz/?action=vthread&forum=18&topic=87504&page=0#4 http://diskuse.jakpsatweb.cz/?action=vthread&forum=18&topic=87504&page=2#9
Joker
Profil
Vypadá to, že se tluče rušení BBCode formátování a barvení kódu (JUSH)- po obarvení kódu se v textu objeví většítko navíc.

Ukázka:
$pole[b];
$text = "[b]";


Bez obarvení to funguje správně
chyba syntaxe $pole[b];
$text = "[b]";
Kajman_
Profil *
Joker:
Když si vypnu barvení, tak nevidím, žádnou změnu, to asi jush neovlivňuje. Prostě tam je kód, kde jsou napsány bb značky, ale nejsou tak zamýšleny. To nikdo nepozná, jestli jsou zamýšleny nebo ne. Musí se zapsat tak, aby nebyly brány jako bb značky.
Jan Tvrdík
Profil
Kajman:
Když si vypnu barvení, tak nevidím, žádnou změnu
Já ano, zkus to znova :)
EDIT: Tak to vypadá, že se jedná o chování specifické pro Operu, ve FF se problém neprojeví.
Kajman_
Profil *
Myslím, že se to tu už kdysi někde řešilo. Jsou tam asi křížené tagy. Nejjednodušší bude použít prenone.
Chamurappi
Profil
Reaguji na Kajmana:
Jsou tam asi křížené tagy.
Nejsou. Ono se nadbytečné většítko zjevuje v innerHTML, zkus si na čisté stránce tohle:
<div onclick="alert(this.innerHTML)"> cokoliv, minikomentář: <!>, cokoliv </div>
Vypadá to na chybu Opery. Asi je na ni ten minikomentář příliš exotické žrádlo.

Nejjednodušší bude použít prenone.
Chyba se objevuje jen v jednom prohlížeči, takže ji část těch, kdo pro ni vytvoří podmínky, ani neodhalí a nenapadne je užít [prenone]. Smutné je, že neexistuje snadný způsob, jak toto vyřešit v JUSHi. Leda podívat se na innerText a porovnávat jej s innerHTML.

Lepší bude, když upravím bb_codes.php — místo <!> bude generovat <?>, tedy procesní miniinstrukci :-) (Ale do SVN půjde nejdříve v pondělí.)
_es
Profil
Joker:
Nesúvisí to s Lov kurzívy pozpátku regulárním výrazem?
Je teraz rozdiel vo funkčnosti medzi sandboxom a normálnou verziou.
Chamurappi
Profil
Reaguji na tisa:
Potrebuješ ich meniť naraz.
V DJPW 1.5 byly změny 14 až 30 (vyjma 27 a 29) nezávislé na úpravách v PHP. Mám v hlavě pár dalších věcí, které bych mohl nasazovat do ostré verze už teď, kdybych je měl naskriptované.

Cieľové verzie existujú len na papieri
Připadá mi to lepší, než mít na papíře cílové roky, které pak nestihneme. Jak bychom tedy podle tebe měli epochy vývoje (předchozí i budoucí) značit?
Je mi celkem fuk, jaký tu bude pořádek, dokud to půjde nazvat pořádkem.


Reaguji na _es:
Nesouvisí, problém nebyl s [b] a s [i], ale s [pre]. Fakt je to chyba Opery.



Nasadil jsem DJPW 1.5.1 do ostrého provozu.
• Upravil jsem bb_codes.php, aby se místo <!> používal <?>.
• Přidal jsem možnost odkázat na kotvu v rámci stránky pomocí [url=#něco].
• Zrušil jsem odtučnění odkazů ve [small], aby člověk z odtučněnosti odkazu na prvního pohled poznal, že vede na kotvu.
• Změnil jsem podmínku na rozpoznání starého vlákna. Místo 31 dnů bude 14.


Zkusím vyrobit vlákno s očíslovaným přehledem plánovaných změn, rozděleným podle priorit, atd.
Joker
Profil
Chamurappi:
Fakt je to chyba Opery.
Poslal jsem jim hlášení o chybě, snad to časem spraví :-)
Str4wberry
Profil
Přidal jsem možnost odkázat na kotvu v rámci stránky pomocí [url=#něco].

To je hezké, ale chtělo by to možná nezobrazovat „V adrese odkazu musí být i ‚http://‘.“, když v příspěvku je [url=#19].
tiso
Profil
Chamurappi:
Jak bychom tedy podle tebe měli epochy vývoje (předchozí i budoucí) značit?
Tak ako som písal v [#3]: výstižne a logicky. Napríklad balíky úprav ako "úpravy diskusie I-III", rok tam môže, nemusí byť, po nasadení sa môže pridať tag verzie, Kajmanov-e úpravy ako "optimalizácia dotazov" a podobne...

Otázne je čo je vlastne epocha vývoja? Čím začína a čím končí? Aký je jej cieľ? Vývoj je skôr kontinuálny, nedá sa poriadne rozdeliť na epochy. Je treba rozlišovať medzi nápadmi na úpravy a samotnými úpravami diskusie. Proces by mal vyzerať nejak takto: nápad -> bude sa robiť? -> realizácia -> nasadenie do sandboxu, testovanie -> nasadenie na live. S tým, že nasadzovať na live sa môže po väčších balíkoch úprav.
mylan
Profil
Jedna drobnosť: nešlo by v ďalšej verzii, aby si fórum pamätalo hodnotu checkboxu "Googlem" pri hľadaní hore? Google hľadanie na diskusii nevyužívam vôbec, viac mi vyhovuje štandardná minibb funkcia vyhľadávania a za každým tak musím odškrtávať daný checkbox.
Str4wberry
Profil
Můžeš nám prozradit, co Tě vede k používání zdejšího hledání místo Googlu?
mylan
Profil
Najčastejšie hľadám tému, ktorá sa na diskusii objavilo nedávno. Často tak zadám obecnú frázu, o ktorej viem, že sa v danej diskusii vyskytla a pri klasickom minibb hľadaní mi vyskočí medzi prvými, pretože výsledky sú radené podľa času, nie relevantnosti (špecificky teda hľadám väčšinou konkrétnu tému, nie riešenie obecného problému).
« 1 2 3 4 5 6 7 8 9 10 11

Vaše odpověď


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0