Portál AbcLinuxu, 1. května 2025 04:08
30.9.2006 18:03
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
Jestli máš na mysli to, „jak se v něm dělá ta stránka“, tak o „embedded Pythonu“ nevím. Třeba k Ruby se dodává binárka eruby (případně modul eruby pro použití z programu), která spouští kód z dokumentu – tedy dělá z něj „něco jako PHP“. To ale není obvyklý modus operandi slušných webových aplikací, které používají nějaké ty šablonovací nástroje nebo něco na ten způsob. Snad jen Rails běžně používají přímo Ruby jako šablonovací jazyk, ale to není takové zlo, jak by se mohlo na první pohled zdát, protože se v těch výsledných šablonách typicky používají jen accessory controlleru, a slušný člověk tam žádné výpočty necpe. 
V konečném důsledku na tom tedy nesejde, prostě z programu vyvoláš šablonu nebo jiný kód, který narve response zpátky do socketu. A protože Python by jako šablonovací jazyk mohl fungovat docela obtížně, tak se v téhle roli nepoužívá, a mimo šablony je Python Pythonem.
Perl Výhody - obrovská podpora. Nevýhody - snad všechno. Nečitelná syntaxe, nedokážu si ho představit v projektu nad několik tisíců řádek.Zajimave, o nevyhodach takhle premyslim u php.
Navic resit, proc skripty s prechodem mezi verzemi prestanou fungovat a jestli budou fungovat i v dalsi verzi... Navic potrebuji provedet i "newebove" cinnosti.
Naopak s Perlem problem nemam. Navic mam tu cest pracovat s prostredim, ktere cita radove stovky tisic radku perloveho kodu.
Cčko zase nebylo navrženo na miliónořádkové programy, kdyby ano, mělo by aspoň namespaces. Holt evoluce.
Navic resit, proc skripty s prechodem mezi verzemi prestanou fungovat a jestli budou fungovat i v dalsi verzi... Navic potrebuji provedet i "newebove" cinnosti.Uvážím-li, že chování perlu se také může lišit ($#pole u prázdného pole může být -1 nebo 0, viděl jsem oboje), tak se perlu raději vyhýbám.
Ale to len aby reč nestála
(a precitat na kazdy riadok kodu 10 riadkov mudrych knih )co sa tyka db, jednoznacne postgresql
a btw, webove stranky vy som urcite pisal v HTML
30.9.2006 17:59
Jardík | skóre: 40
| blog: jarda_bloguje
přešel s windows na LinuxAle fůj: s/s/z/g
30.9.2006 18:06
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
30.9.2006 18:27
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
. Potom jsem to přepsal jako cgi skript, takže web se skládal s jedné binárky a souboru s daty (BDB). Zlaté časy.
30.9.2006 18:31
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
A pokud planujes vlastni hosting, tak jsi dvakrat stastny, protoze si muzes delat co chces
Ja jednoznacne doporucuju Python. Jednak jako jazyk a za druhe pro kvality web frameworku pro nej dostupnych.
Je dobre se podivat na mod_python a ten jednoduchy templatovaci engine co obsahuje, prip. PSP kdyby se ti styskalo po PHP a matlani aplikacni logiky do vzhledu
Znalosti mod_pythonu pak muzes vyuzit pri zprovoznovani ruznych frameworku za Apachem (i kdyz to jde i jinak, typicky pres FastCGI - nebo uplne bez Apache samozrejme...). Doporucil bych ti mrknout na CherryPy a Kid templates - to jsou fajn veci, prip. TurboGears, ktere predchozi dva produkty kombinuji a pridavaji jeste par blbosti. Podobne funguje Django. Na me jsou tyhle frameworky ale uz moc uzce profilovane. Na nektere veci jsou ale jak delane...
Moc doporucuju video, ve kterem nejaky typek srovnava Rails, TurboGears, Django, Plone, Java Sevlets/JSP, a plne vyzbrojene J2EE.
30.9.2006 18:52
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
Zjistil jsem, že po dvou měsících učení jsem v Rails asi 2x efektivnější než v PHP.
Výhody Ruby:
30.9.2006 18:52
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
30.9.2006 18:52
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
30.9.2006 19:51
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
).
Už jen příchod YARVu by měl hodně změnit a ten druhý odkaz ukazuje, že není dobré dělat předčasné závěry, když tomu pánovi jeden diskutující vytáhnul kód v Ruby skoro na rychlost Javy. Je pravda, že mě překvapuje, že by dual Opteron zvládal jen 60 hitů/s, a to i včetně Rails. Ono dost záleží i na aplikaci, někdy kešovat jde, někdy to nejde vůbec, a dá se čekat, že v náročnější aplikaci by se to trošku tou srovnalo i vlivem databáze.
Co se týče dotazu níže, tak scalability RoR by měla být dobrá, ostatně jako každé jiné FastCGI aplikace. Ale zatím jsem to nepotřeboval.
?
.
Ano, ukázat "dump" relační databáze na webu, k tomu se RoR hodí, a párkrát za minutu to zpravidla dovede...
Spousta lidí si to zřejmě dokáže vyladit tak, že jim to stačí a jsou s tím spokojení. Jsme snad všichni svéprávní lidé a každý použijeme to, co uznáme za vhodné a o čem se přesvědčíme, že nám to nejlépe vyhovuje.
(BTW, předvedené benchmarky ukazují výkon referenční implementace, kterou do dvou let velká část lidí již nejspíš nebude používat, protože jednu implementaci má teď Sun, druhou vyvíjí Sasada Kóichi a třetí s velkou pravděpodobností vznikne na základě Strongtalku, už teď se k tomu v mailing listu Strongtalku někteří hlásí. Python je na tom přesně stejně, máme Python, Python+Psyco, IronPython, Jython a PyPy. Do pár let budou všechny ty benchmarky neplatné …)
. Škoda, že se nejdříve nevrhli na dokončení Parrotu (jaký máš vlastně názor na register-based virtuální stroj?) a jako prozatímní řešení mohli použít Pugs s Parrot backendem.
Jinak, autoři onoho projektu s tím tak nějak počítají, protože je na titulce
Contribute: you can make a difference
- you can contribute faster more-elegant programs (FAQ)
- you can suggest new benchmark comparisons (FAQ)
Rubisté se shodují v tom, že je třeba rozhodně napsat lepší řešení. Přiznám se, že mi optimalizace kódu v Ruby přijde taky netriviální, začíná to připomínat Lisp, ale vyplatí se to. (To, co napíšu, se nemusí mapovat 1:1 s tím, co se přesně provádí, a to i sémanticky – třeba GO v Lispu, ekvivalent GOTO, taky není „obyčejné goto“, díky lexikálnímu scopingu se dá vyskočit z vnitřní funkce do vnější včetně stack unwindingu a pořešení veškerého cleanupu, třeba i výjimek, a to rozhodně není „jednoduchý skok“. Takže takový vysokoúrovňový jazyk jako je Common Lisp – rozhodně o kilometry výš než třeba Java, v tom smyslu, že konstrukce jazyka vyjadřují spíš sémantiku než implementaci – může člověku přichystat nejedno překvapení. )
Registrové VM? Pořád čekám, až mi někdo hodí link na studii, ...Uf, to jsem rád, že nejsem jediný, komu připadá mapování virtuálních registrů VM na skutečné registry, v těch neskutečných počtech platforem, které máme, jako prakticky nemožné
. Respektive, možné to asi bude, ale složité.
Takže jazyk nad Parrotem bude přiřazovat lokální proměnné 32 registrům (beru teď jen ty celočíselné), které by JIT kompilátor přejmenovával na jeden ze sedmi dostupných GPR registrů IA32, které následně register renaming unit v CPU přejmenuje na jeden z několika desítek fyzických registrů procesoru, a pak se zase výsledek proodpřejmenuje zpátky … Aha, teď už chápu, proč na tohle člověk potřebuje dva doktoráty, aby ho zaměšstnali.
. Nejvíce mi u Ruby chybí UTF-8.
). Nezanedbatelné je i množství hotových aplikací a tříd a fakt, že PHP5 už má konečně trochu slušný objektový model, takže se ten jazyk vyvíjí k lepšímu. Nicméně debugger mi opravdu chybí. Naopak hláška o chybějícím kompilátoru mi připadá poněkud nesmyslná. PHP není programovací, ale skriptovací jazyk. Proto se aplikacím v PHP říká skripty a ne programy a tudíž nemá smysl mluvit o kompilátoru.
Pokud bych měl dneska volit jiný jazyk na tvorbu webu, pak bych asi zvolil Javu. Velmi slibně se rozvíjí a je pro toto použití už teď poměrně oblíbená. Python se mi taky nezdá špatný, ale jsem zatím příliš líný se ho učit. Perl je IMHO natolik obskurní jazyk, že si nejsem jistý, jestli čas věnovaný jeho pochopení by se mi nějak vrátil, čímž mu nechci ubírat zásluhy a tvrdit, že není vhodný pro web. No a Ruby a spol. jsou věci o kterých sice často slyším, ale v praxi jsem je neviděl
Ad databáze:
Zatím zůstávám u MySQL. Dřív byly její možnosti dost omezující (ve srovnání s PostgreSQL), ale prokazatelně se "blýská na lepší časy", takže jsem zatím neměl důvod ji opouštět.
30.9.2006 19:57
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
30.9.2006 22:00
Dalibor Smolík | skóre: 54
| blog: Postrehy_ze_zivota
| 50°5'31.93"N,14°19'35.51"E
1.10.2006 14:28
Dalibor Smolík | skóre: 54
| blog: Postrehy_ze_zivota
| 50°5'31.93"N,14°19'35.51"E
1.10.2006 16:49
Dalibor Smolík | skóre: 54
| blog: Postrehy_ze_zivota
| 50°5'31.93"N,14°19'35.51"E
Zdrojáky included
MySQL odsunuji do pozadí kvůli lincenci a hledám jinou databázi, kterou lze používat zdarma. Na malé jednouživatelské projekty jsem našel - sqlite a na Windows access. Na střední uvažuji o Firebirdu, ale dokumentace chybí, takže Firebird to asi nevyhraje. PostgreSQL nechci, nemám s ní dobré zkušenosti na Windows.
Jsou-li nějaké tipy na další náhradu MySQL, sem s nimi.
Potřeboval jsem vypočítat celočíselný podíl dvou časů - provolaný čas / délka tarifní jednotky. Takže jsem prostě v cyklu přičítal délku tarifní jednotky, počítal počet proběhlých cyklů a cyklus se ukončil v okamžiku, kdy tahle suma byla větší než provolaný čas.
Bohužel pro bezplatné terify jsem jako délku tarifní jednotky zvolil 0:00, takže se pořád přičítala 0, a pořád ta 0 nechtěla být větší než ta délka hovoru.
Takže jsem si pro sebe poučku "nulou dělit nelze" poupravil na "nulou dělit samozřejmě lze, nikdo vám v tom nezabrání, ale nebere to konce"
COALESCE (delka_jednotky, konstanta_pre_null), a pre bezplatne tarify nastavoval stlpec na null, to by mozno slo
time / time není v PostgreSQL definován. Když mi došlo, že jsem do té tabulky před pěti minutami vložil nulu jako speciální případ, tu funkci jsem samozřejmě upravil tak, aby pro tento případ vracela nulu. NULL jsem z nějakého důvodu nechtěl použít, ten samý sloupeček se používal ještě v dalších pohledech, nebo se podle něj třídilo nebo něco na ten způsob…
coalesce (nullif (col, '0:0:0'), a/b, KONSTANTA)
N×M (volané číslo × zpoplatnění = jiný tarif je za volání na mobil, jiný místně, jiný dálkový hovor) udělat N×1 tak, aby se ze způsobů zpoplatnění vybral ten, který nejlépe pasuje na volané číslo…
k tomu N*M dve view "za sebou", tam snáď niet čo vymýšlať
z hladiska logiky pre bezplatný interval je správnou dĺžkou intervalu hodnota nekonečno, resp. maximum.No vida, to mě nenapadlo. Jenom jestli PostgreSQL nějakou použitelnou hodnotu pro maximální interval má. No ale hlavně doufám, že rozúčtování telefonních hovorů podnikové ústředny už nikdy dělat nebudu
ok, nabudúce sa pokúsim nezabudnúť explicitne deklarovať vtipný obsah
1.10.2006 21:41
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
A naopak jsem rád, že se se vším, včetně seznamů i map, zachází stejně, připadá mi to přehlednější. Ale přiznávám se rovnou, že jsem si nebyl ani v Perlu ani v Pythonu nikdy schopen zapamatovat, které závorky se používají na vytvoření jakého druhu kolekcí…
int je objekt?
Object get_xyz (Hashtable hash, Int key1, Int key2) {
sum = key1.intValue() + key2.intValue();
return new Int (
( ((Int) hash.get (key1)).intValue()
+ ((Int) hash.get (key2)).intValue()
) / sum);
}
oproti Perl-u
sub get_xyz ($$$) {
my ($hash, $key1, $key) = @_;
return ($hash->{$key1} + $hash->{$key2}) / ($key1 + $key2);
}
# a trochu menej čitateľne
sub get_xyz ($$$) {
($_[0]{$_[1]} + $_[0]{$_[2]}) / ($_[1] + $_[2])
}
ad zátvorky v perli, je to jednoduché, aký index chces použiť, tak referenciu vytvoríš. Nevravím o pseudo-hashes, tam je to inak.
ad Java, aj int je objekt?To skoro v mé věte bylo záměrně
a kde má overloadovanie operátorov?To je nějaká nutná podmínka?
daľšia vec, ktorá mi v Jave vadí, chýbajúca multiple inheritanceA co interfacy? Vícenásobnou dědičnost od různých tříd jsem nikdy nepotřeboval, takže mi nechybí.
potom ešte Hashtable (a tým asi celý príslušný koncept. Vadí mi, že pre každý objekt vytiahnutý z Hashtable musím robiť explicitné pretypovanie, vadí mi, že kľúčom môže byť len Object.Podívejte se na Javu 5 a generiky. Ale účelem této diskuze myslím nebylo sepisovat, co na Javě vadí někomu, kdo v ní neprogramuje…
3.10.2006 09:48
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
daľšia vec, ktorá mi v Jave vadí, chýbajúca multiple inheritance
Tohle je jedna z nejhorších věcí v C++. Vícedědení nemá např. ani C# a je to jen dobře.
a potom ešte Hashtable (a tým asi celý príslušný koncept. Vadí mi, že pre každý objekt vytiahnutý z Hashtable musím robiť explicitné pretypovanie, vadí mi, že kľúčom môže byť len Object.
Cože? Jaké přetypování? Při vytváření hashmapy (a obecně všech kolekcí) si přece určujete typy klíče (a tedy neplatí, že to může být jen Object) a hodnoty, např: HashMap<Integer, String> h = new HashMap...
Dále. Co je to proboha za kód? Když už nic menšího, proč je definovaná návratová hodnota Object a přitom vrací Int? Pokud píšete takhle, tak se nedivím, že jste Javu zavrhl.
ten kód je z roku 1998, kedy podobnými vymoženosťami disponovalo akurát tak C++. Tá inkriminovaná metóda bola implementáciou z Interface (a samozrejme som nepastol inú, ktorá pracovala s náročnejšími datovými štruktúrami.
3.10.2006 10:14
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
viacnasobná dedičnosť je vec, ktorá (v špecifických projektoch) ušetrí množstvo copy-paste
Copy-paste v OOP? V tom případě je špatně navržená hierarchie. Pokud jsem se (jednou), dostal do situace, že jsem "chtěl/musel" okopírovat kód z jiné třídy, kterou jsem nemohl použít rovnou (už tohle je znak, že je něco špatně), tak jsem se zamyslel a změnil hierarchii tak, aby to provést šlo. (Prostě refaktoring.) Což jako důsledek celkově vyčistilo kód.
Chcete naznačiť, že ste sa nikdy nestretli so situáciou, ked existoval Interface, ktorého jedna metóda mala rovnaké chovanie nezávisle na implementáci zvyšku ?
Ne. A zrovna Interface vícedědičnost umožňují.
Nehledě na to, že když 1. třída má 150 metod, 2. třída 70 metod a pak chcete obě podědit, to se Vám to opisování přes dva datové členy a delegování metod trochu natáhne.Myslím, že v eclipse IDE to budou tři, maximálně čtyři kliknutí myší
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.