Příspěvky

76

Software / Re: KDE4 kompilace a cmake - volitelné parametry

« kdy: 26. 07. 2011, 16:03:16 »

Asi jsem se dostatecne spravne nevyjadril.
Nehledam obecne parametry (variables) pro cmake.
Hledam takova nastaveni, ktere mi umozni (napriklad) vyhodit z kompilace kde-workspace cokoli co chce python (neb ho nemam a nechci).

77

Software / Parametry pro cmake a KDE 4

« kdy: 26. 07. 2011, 12:46:26 »

KDE4 používá při kompilaci systém cmake, zatímco staré KDE3 používalo configure.
Otázka: existuje nějaký seznam parametrů, které je možné při kompilaci s cmake použít? Nebo způsob jak si ten seznam vygrepovat?

Dřív stačilo napsat ./configure --help a člověk hned věděl.
S tímhle cmake si nějak nevím rady.

Obecně jsem narazil na syntaxi typu cmake -Daaa=bbb, ale nikde žádný seznam použitelných parametrů.

Za jakékoli nakopnutí dík!

78

Vývoj / Re: Fotky do databáze nebo souboru?

« kdy: 09. 07. 2011, 16:09:53 »

Varianta A, ukladani do filesystemu:

pokud bude mit web 10 000 uzivatelu, bude ve filesystemu v jednom adresari 10 000 souboru. To nektere filesystemy dost brzdi. Jak uz bylo receno, cas od casu muze dojit k vytvoreni nejakeho odpadu (soubory ktere uz nemaji odkaz v DB, nebo obracene radky DB ktere nemaji soubory). K tomu muze dojit proto, ze ulozeni do databaze a ulozeni do filesystemu jsou 2 operace ktere neprobehnou atomicky - pri vypadku se proste udela jen jedno (treba ulozeni radku do databaze) ale ne to druhe (ulozeni souboru na disk). Jsou tedy nutne dalsi tools na detekovani a opraveni techto vadnych stavu. Dalsi nevyhodou je, dospeje-li aplikace do stavu, kdy je nutne ji nechat bezet z vice serveru - pak je nutne synchronizovat fotky z disku nejak mezi jednotlive nody, pokud tedy nejsou ukladane na nejaky sitovy disk.

Varianta B, ukladani do DB:

Obecne nehrozi nekonzistence dat jako v predchozim pripade, pri prechodu na vic serveru je mozne databazi jednoduse replikovat, nebo servirovat z centralni vykonne masiny. Pro velke zatizeni je samozrejme nedobre, kdyz mi nacitani profilovych fotek zpusobi dalsi zatizeni databaze, ale jak uz bylo receno, je mozne profilove fotky cachovat, aby se databazi ulevilo. Jedine co je asi nevyhoda je celkova velikost databaze, neb bude obsahovat i ty fotky, ale tohle je dost relativni, pro nekoho je uz 1GB moc, pro nekoho je 1TB malo...

Doporucuji tedy profilove fotky ukladat do databaze, ale ja sam z pohodlnosti (a ze zvyku) ukladam do filesystemu, nicmene do vetsiho stromu, typu
images/b/a/b/babicka.jpg
images/k/a/r/karkulka.jpg
atd

79

O serveru Root.cz / Re: Blog root.cz

« kdy: 09. 06. 2011, 19:03:26 »

Tam se to dostane az pokud to manualne schvali nejaky redaktor.

80

O serveru Root.cz / Re: Jak si založím blog?

« kdy: 01. 06. 2011, 13:33:33 »

Odpovim si sam, jde staci to pojmenovat JPG ale dovnitr ulozit PNG a ono to funguje ;-)

81

O serveru Root.cz / Re: Jak si založím blog?

« kdy: 01. 06. 2011, 13:30:58 »

BTW: jpg nepodporuje pruhlednost, to je hruza, nejde tam nejak dat PNG?

82

O serveru Root.cz / Re: Jak si založím blog?

« kdy: 01. 06. 2011, 13:30:19 »

Aha, tak to je pekne divne teda, to snad nenapadne nikoho ... kolikrat uz jsi na takovouhle otazku odpovidal? :-)

83

O serveru Root.cz / Re: Jak si založím blog?

« kdy: 01. 06. 2011, 13:13:47 »

A jak si nastavim fotku profilu? Jsem asi slepy

84

O serveru Root.cz / Re: Jak si založím blog?

« kdy: 01. 06. 2011, 12:54:47 »

Na základě jakých kriterií jsou vybírány zápisky z blogů na titulní stránku root.cz?
Je to manuální volba redaktora nebo v systému naprogramovaný algoritmus?

85

Sítě / Re: u koho registrovat domenu?

« kdy: 13. 05. 2011, 20:28:17 »

Pouzivam subreg.cz, DNS davaji zdarma pro domeny ktere se u nich registruji, umoznuji i spravovat GLUE records. Ceny si porovnej sam, to sem nikdy nezkoumal, jestli zaplatim za domenu 200 nebo 350 korun rocne to je mi fakt jedno (rozdil desetikoruny mesicne fakt neresim)

86

Vývoj / Re: MySQL a použití sloupce ID

« kdy: 08. 05. 2011, 18:40:14 »

Developer, diky za namahu, me se nechtelo
USING WHERE v tom explainu znamena, ze se pouzil jeden z indexu na vytvoreni podmnoziny dat, a zbytek filtru se vyhledal hrubou silou v te podmnozine. Tudiz optimalizace neni nulova, bude to rychlejsi nez kdyby index nebyl zadny, ale nikdy to nebude tak dobre jako slozeny index (nejlepe UNIQUE) na obou sloupcich (paklize filtr v selectu hodnoti oba sloupce).

Pecko, ja nezpochybnuju uzitecnost studovani teoretickych znalosti, ale veskera normalizace je k nicemu kdyz nevis, ze select na 2 samostane indexy je neoptimalni v porovnani se selectem na 1 slozeny index, a troufam si tvrdit, ze v tomto pripade NEZALEZI na databazi. Argument "urcite to fungovalo" je smesny.

87

Vývoj / Re: Úkol v Bashi: vykreslení teček

« kdy: 06. 05. 2011, 10:08:43 »

Pokud to mas do skoly, tak tvuj vyucujici bude mit asi nejvetsi radost z tohohle:

Kód: [Vybrat]

#!/bin/bash
function ukaz_tecky()
{
   local MAX=$1

   for i in $(seq 1 $MAX); do
      for j in $(seq 1 $i); do
         echo -n ..
      done
      echo ""
   done

   for i in $(seq 2 $MAX); do
      for j in $(seq $i $MAX); do
         echo -n ..
      done
      echo ""
   done
}

ukaz_tecky 5


88

Vývoj / Re: MySQL a použití sloupce ID

« kdy: 06. 05. 2011, 10:01:13 »

zaujimave, ze mne vzdy druhy zaberal a explain mi to potvrdil.

Takovy explain bych chtel videt. Typuju ze ukazoval USING WHERE, coz je chyba pokud chces selektovat pomoci indexu. Zalezi ale jake dotazy jsi s tim provadel, no

to je prave ten najvacsi problem 98% webovych aplikacii. ze kaslete na normalizaciu a riadite sa len sedliackym rozumom:) a potom databazy vyzeraju, ako vyzeraju a vsetci kydaju na mysql, ako keby ono mohlo za to, ze pouzivate iba sedliacky rozum namiesto pravidiel tvorby datoveho modelu. mysql mozno neni mega db. mozno neni vobec db, to nech si riesi ini inde. urcite to ale je nastroj, ktory si vie poradit datami a pokial dodrziavas iste pravidla (napr. normalizacia), vie to byt aj vykonny nastroj. ja by som sa teda v pripade databaz stranil sedliackeho rozumu, lebo to je najvacsi a najcastejsi zabijak databaz a je to najsignifikantjesi markant toho, ze autorom db je neskuseny amater, ktory je len mudry vo forach:)

Nevim jestli ted myslis me osobne, v kazdem pripade ja jsem zastance MySQL a mam stejny nazor jako ty - pokud nekdo spatne navrhne databazi a pak mu to nefunguje poradne a nadava na MySQL, tak je to spatne.

Tim selskym rozumem jsem mel na mysli predevsim to, pochopit jak databazovy server funguje a podle toho psat SQL dotazy a delat navrh db, a ne jen vzit nejakou teoretickou prirucku o 'normalizaci' (coz ja ani poradne nevim co je) a ridit se podle nejake prirucky.

A pokud mi je sloupec s auto increment ID k nicemu a v aplikaci ho nepouziju a mam moznost jednoznacne identifikovat radek tabulky pomoci jineho klice (treba slozeneho z vice sloupcu), tak se muzu na ID vykaslat a MySQL s tim NEMA nejmensi problem. A pokud nekdo tvrdi ze ma, tak at laskave odkaze na nejakou analyzu.

89

Vývoj / Re: MySQL: kedy používať ID stĺpec ako PRIMARY KEY s auto_increment a kedy nie

« kdy: 05. 05. 2011, 18:25:33 »

Co se tyce ID cloupecku na kazde tabulce, neexistuje nic co by me (nebo autora dotazu) prinutilo cpat id tam kde to neni potreba. A v dany moment nemusi nikoho zajimat 'normalizace' nebo co, zdravy selsky rozum rika, ze pokud auto increment id nebudu pouzivat, tak ho tam prece nedavam.

BTW je zcestne definovat ID jako AUTO INCREMENT INT, protoze tam vzdy budou ulozene jen kladne hodnoty, takze UNSIGNED INT je optimalnejsi; pro rozsahle tabulky ale nemusi stacit a je lepsi treba BIGINT. U mensich tabulek zas bigint je zbytecne velky. Zalezi kolik radku v tabulce kdo ocekava.

90

Vývoj / Re: MySQL: kedy používať ID stĺpec ako PRIMARY KEY s auto_increment a kedy nie

« kdy: 05. 05. 2011, 18:23:16 »

tusim sa mylis:) ak mas tie indexy spravene dobre, musi sa ti uplatnit aj ten druhy

Tusis absolutne spatne.

Staci si nechat ukazat EXPLAIN a uvidis, ze pokud mas 2 indexy tak je to neco uplne jineho nez kdyz je 1 index na obou sloupcich.