V čem vyvíjet webové aplikace (diskuse)

[asfeqwgwegf]

Promin mi že píšu zrovna do tvého blogu, ač neprogramátor. Ale z tvého dnešního blogu cítím volnost, uvolnění a osvobození!

[kralyk z abclinuxu]

Chci (si) dokázat, že Abíčko nebyla náhoda.

No jo, ale co ta zmínka z minulého blogu o tom, že podníkání "vyžaduje 100% nasazení a soustředění?"

[Leoš Literák]

Dobrá poznámka. Proto to nebude podnikání, ale časové omezený krátkodobý projekt. Buď vyjde nebo ne. A nechci do něj jít sám.

[A]

Proto to nebude podnikání, ale časové omezený krátkodobý projekt.

A co si pocnu tie tisice ludi ktore na nom zacnu byt zavisle ?

[HS]

V tom pripade bych ti doporucoval tvorit v tom, co umis. Vetsinou u takovych projektu jsou naklady na uceni novych veci priliz drahe.

[pavlix]

Náklady je potřeba porovnávat s výsledkem. Pro jednotlivce je ve výsledku velmi výhodné učit se pořád něco nového.

[Max]

Já jsem sice amatér v programování, ale vím, že php jednoznačně ne. Je pomalé, dalo by se říci, že skoro všechno je rychlejší, jak php.
Ohledně pythonu nemám zkušenosti s programováním, ale jen s finálními projekty. Třeba Plone CMS je jeden z nej CMS, co jsem kdy viděl a jeho rychlost je vskutku ohromující.
Podobné zkušenosti mám s Ruby, kde provozuji redmine, které je také velmi dobrým kusem SW.
Nic z toho ovšem nejsou programátorské zkušenosti, jen se dělím o nadšení z obou projektů :)

Já osobně vidím javu ve stále dobré pozici. Běží to všude a pomalé to také není. Dobrá spolupráce se všemi možnými db. Ty osobně s ní máš nemalé zkušenosti. Nechápu, proč se uchylovat někam jinam. Dále jsem měl vždy pocit, že javistů je jak máku. Deployment snad závisí natom, co se použije za aplikační server, ne? Je tedy pravda, že osobně s moc aplikáči pro javu zkušenosti nemám.
Jinak pak je tu ještě céčko a na druhé straně barikády ".net".
Otázkou tedy není, "co použít místo javy", ale "proč nepoužít javu"?
Zdar Max

[Max]

Teď jen čekám, až mně někdo vyvede z omylu :)
Zdar Max

[Bedňa]

Stačí že nebudeš v PHP používať objekty a môžeš to s kľudom benchmarkovať s hocičím.

[pavlix]

Vidíš a já měl za to, že pokus o objekty v PHP je to jediné, co ho dokázalo udržet v provozu mimo jeho původní účel (personal homepage), když existuje tolik jiných, schopnějších, nástrojů.

[chrono]

Skúšal si v Php niekedy použiť eAccelerator, alebo niečo podobné?

[Max]

Kompilace skriptů? Něco jako HipHop, který má FB? Nezkoušel. Ale pravda, vše se pak hodně zrychlý. Ty s tím máš zkušenosti? Zajímalo by mně, jaká je podpora. Asi to nezvládá všechno, ne?
Zdar Max

[VSi]

Advanced PHP Cache nebo eAccelerator jsou tzv. "opcode cache". Funguje to úplně transparentně, žádná omezení nejsou (běžně to používají hostingy). Princip je, že se při každém requestu nemusí provádět parsování všech souborů, ale "zkompilovaná" verze (opcode) se uloží do RAM. Nevýhoda je vyšší spotřeba RAM, pokud se tohle využívá pro větší množství málo zatížených virtualhostů. Pro jednu velkou aplikaci na serveru se to neprojeví.

Pak PHP zas tak pomalé být nemusí. Záleží na tom, kde konkrétní aplikace nabírá největší zpoždění - jestli nějaká práce s daty, dotazy na SQL apod. S FastCGI a opcode cache je samotné zpracování requestu rychlé, vč. spojení s DB a pár dotazy se vejde do 100 ms. Oproti Javě nejsou k dispozici takové vychytávky jako DB Connection Pool nebo Message Queue. Pro více zatíženou aplikaci se může hodit memcached, protože v PHP nelze nic držet v paměti mezi requesty.

Pro práci v PHP se skoro vždy vyplatí použít nějaký framework. Zend je dobrý jako rozsáhlá knihovna jednotlivě použitelných věcí, ale jeho MVC se mi zrovna nelíbí. Na to bych doporučil Nette.

[pavlix]

Bohužel to řeší jenom část problému, špatný návrh jazyka a deploymentu (můj názor na php) se tím nespraví.

[rADOn]

Deployment je dobre navrzeny, ale pro uplne jine zadani - jednoduche skriptovani pro jednoduche stranky. Dnes to mozna bude znit neuveritelne, ale proti psani CGI skriptu v perlu kvuli kazde volovine bylo php velke zlepseni. Kdyz nekdo dobrovolne pouzije php na slozitejsi veci nez voloviny, tak je to chyba cloveka a ne jazyka.

[Josef Kufner]

I složitější věci se dají v PHP psát a to velmi lehce. Jen si musíš deployment pořešit sám. Většinou stačí vhodné uspořádání repositářů a hooků. Občas je potřeba nějaké udělátko na správu databáze. Ale nic z toho není nijak velký problém, který by nějak zdržoval vývoj. Naopak, uspořádáš si to podle potřeb konkrétního projektu a není problém to doplnit o nějakou funkci.

[pavlix]

Deployment je dobre navrzeny, ale pro uplne jine zadani - jednoduche skriptovani pro jednoduche stranky.

Máme asi jiná hodnotící kritéria, podle mě je pro tento účel CGI navrženo daleko lépe. Ale je to subjektivní hodnocení, vycházející z mojí vlastní praxe.

Dnes to mozna bude znit neuveritelne, ale proti psani CGI skriptu v perlu kvuli kazde volovine bylo php velke zlepseni.

Tak se kvůli každé volovině napíše CGI PHP skript v PHP...

[moira]

Já mám trochu zkušenost s Apache Wicket (komponentově orientovaný framework), ale určitě se nehodí na všechno... Já jsem s ním ale byl spokojený a hodně mi usnadnil práci.

[m]

> Důležitá je efektivita vývoje

afaik nejlepe znas ten jazyk od Oracle, takz imho je pro tebe nejefektivnejsi vyvoj v Jave

[A]

Gmail je napisany v Jave.
Wikipedia je napisana v PHP.
Mnohe casti Google.com su napisane v Pythone
Slashdot je napisany v PERLe.
Twitter je napisany v RUBY.
Stackoverflow je napisany v C#.
A tak dalej...

Ako vidis, niet najlepsieho jazyka... Jazyk totiz je len nastroj na tvoje myslienky a tie dokazes urobit v hocicom...

[AsciiWolf]

+1

[Vykook]

Twitter je napsany v Scala v RoR je jenom frontend.

[Whoever]

Gmail je napsaný v Javě zkompilované do JavaScriptu.

[Ladicek]

Klient Gmailu, pokud vím, není v GWT, ale v "normálním" JavaScriptu (který samozřejmě projde nějakým dalším zpracováním). Tou Javou je v tomhle případě asi míněna serverová část (předpokládám, že by to Java mohla být, když je v ní třeba Google Calendar).

[Martin Mareš]

Samozřejmě Perl6, až tu bude

Jenže to ještě nějaký čas potrvá, tak je potřeba se uchýlit k něčemu méně dokonalému :)

Své webové aplikace píši v Perlu5, ten mi do ruky padne nejlépe. Uznávám ale, že to není zrovna skvělá volba pro někoho, kdo chce spolupracovat s více lidmi, kteří nejsou zase tak zkušení programátoři (málokdo v Perlu programuje hezky za méně než rok praxe).

Python a Ruby mi přijdou jako daleko lepší volby než Java z toho prostého důvodu, že si nehrají na to, že jsou celým vesmírem, vně kterého nic neexistuje. Například když seženu novou krásnou knihovnu a chtěl bych ji použít, napsat na ni bindingy pro Python je velmi snadné. U Javy mi to nikterak snadné nepřijde.

[xvasek]

Přesně tak, někdo to napsat musel. Chlapi dělají v Perlu a když je to moc pomalé, tak si kritické kousky dopíšou v céčku.

[Martin Petr]

Já proti Perlu tak nějak nic nemám, ale ještě mě nikdo nepřesvědčil, proč bych měl psát zrovna v něm. Podle mě jazyk jako každý jiný, jen má docela velkou tradici v jistém specifickém okruhu programátorů/adminů. Setrvačnost, zejména tu bych za tím viděl.

[xvasek]

Ono s Perlem se to má (aspoň u mě) tak, že za čas, než najdu nějaké řešení a trochu ho přiohnu tak, aby mi to vyhovovalo, tak už to v Perlu mám dvakrát napsané. Třeba onehdá mě kamarád poprosil, jestli bych mu neudělal systém pro autoservis, aby si tam mohl založit kartu auta, kartu zákazníka, vést si tam záznamy o servisních úkonech, vyhledávat, nic složitého. Vypadá to primitivně, tak jsem si říkal, že na toto prostě musí být nějaký framework (já takové věci nedělám). Ono jo, půl dne jsem hledal, pak jsem to našmrdlal v Oracle APEXu, ale aby to trochu bylo k světu, tak jsem s tím trávil asi další dva a půl dne. Zpětně to proberu a myslím, že v Perlu bych měl funkční řešení v řádu hodin, za den i TK ksichtem (aby to byla standalone aplikace bez závislostí provozovatelná i pod Windows).

Na druhou stranu musím pokorně přiznat, že jít do něčeho jako portál, bych se s tímto nástrojem trochu bál. Ale obdivuji lidi, kteří se toho (s Perlem) nebojí.

[Yenya]

Ja myslim ze s Perlem neni v tomto problem. Urcite je nejrychlejsi na psani, a pokud clovek neni prase, tak i na cteni a debugovani (na rozdil treba od C++)[*].

Java ma oproti Perlu jednu znacnou vyhodu - i velmi podprumerny programator je schopen za tvrdeho dozoru prislusneho IDE produkovat relativne citelny kod. Takze pokud je cilem delat projekt ve 100 levnych programatorech, asi bych zvolil Javu (kdyz uz bych do toho musel jit). Na druhou stranu javu nejde bez IDE cist ani ji psat ve vimu. Pokud je cilem udelat projekt ve 20 prumernych nebo 10 nadprumernych programatorech, Perl vede.

-Yenya

[*] Doporucena literatura:

Damian Conway: Perl Best Practices (http://oreilly.com/catalog/9780596001735)

C++ Frequently Questioned Answers (http://yosefk.com/c++fqa/)

Defective C++ [C++ FQA Lite] (http://yosefk.com/c++fqa/defective.html)

[tomm]

Grails.org - myslenka RoR postavena nad Groovy, Springem a Hibernate. Vyhoda je, ze nemusis ovladat ani Spring, ani Hibernate, ale pokud umis, muzes vyuzit. Efektivita vyvoje je obrovska. Mame ted cca 2-lete zkusenosti a jsme spokojeni.

Druha cesta: Wicket, my ho mame - opet - nad Springem a Hibernate, ale tentokrat uz je to na znalost vseho.

Drzim pesti!

[kouba159]

Grails.org můžu také doporučit, ale to jsme pořád tak trochu u té javy.

[kralyk z abclinuxu]

Mimochodem, existují nějaké možnosti dělat výkoný engine webu v kompilovaných jazycích jako C/C++, Objective-C, D, Lisp, Pascal, Haskell, apod.? Vzpomínám si na CGI, jsou případně jiné možnosti?

[V]

Hele

[Douglish]

Co se tyce toho Lispu, Yahoo store (drive viaweb) byl kompletne napsany v Lispu.

Nevim, jestli existuje nejaky konkretni framework, ale nejake info http://www.adampetersen.se/articles/lispweb.htm

[Jendа]

Tak ono do webového serveru narveš přes CGI v podstatě cokoli… jednu dobu jsem tahkle provozoval skript v Bashi. Nevýhodou „normálního“ CGI je pomalost - pro každý požadavek se musí udělat fork. Ale pokud se ti nějak podaří implementovat FastCGI, mohlo by to být i docela rychlé.

[frEon]

pokud mas web v cecku, na webac mpm-worker, tak si myslim, ze ten jeden fork + vykonani webu, bude ve vysledku rychlejsi nez prefork + mod_php...

cgi v bashi je ovsem jina - tam tech forku udelas hromady...

[pavlix]

Jen doplním. Ono nezáleží jenom na jazyku. Pokud v tom céčku potřebuješ inicializovat spoustu hovadin, tak dopadneš podobně. Příklady jsou pomalá SQL databáze apod.

[xkucf03]

Např. v Javě si spojení do databáze běžně drží aplikační server – a nemusí se tak připojovat při každém HTTP požadavku

[pavlix]

Jednak to byl jenom příklad, jednak se dá nějaké persistence spojení využít i v PHP. Vtip je v tom, že stále-běžící aplikace přesně ví, kdy si chce jaké prostředky držet.

[pavlix]

Toho forku si ani nevšimneš. Podle mě hledáš problém jinde než je.

Co tě zdrží, je inicializace těch různých interpretů, ať už skriptů nebo bajtkódu, a inicializace použitých knihoven. Příklad, templatovací systém kid na pythonu se mi inicializoval (na pomalém stroji) asi tři vteřiny. To znamená, že u CGI se čekalo tři vteřiny na stránku, ale u HTTP/FastCGI/SCGI/WSGI, prostě čemkoli, kde aplikace stále běží, se zdržoval pouze start a stránky šly bleskově.

[Karel Zak]

Za pouziti Cecka jde celkem snadno napsat modul do Apache. Neni pak problem hrat si s vecmi jako je perzistentni spojeni s DB, cachovani apod. Pred cca 6 lety jsem neco takoveho delal a bylo to vcelku pouzitelne (jen bych asi v soucasne pouzil nejakou XML (DOM) knihovnu).

[xkucf03]

Neni pak problem hrat si s vecmi jako je perzistentni spojeni s DB, cachovani apod.

Jenže proč vynalézat kolo a řešit tyhle základní věci, které jsou jinde už hotové a stačí je použít? Člověk se pak může víc soustředit na vlastní aplikaci.

[kralyk z abclinuxu]

Jenže proč vynalézat kolo a řešit tyhle základní věci, které jsou jinde už hotové a stačí je použít?

Například?

[xkucf03]

např. Connection Pooling, cache, hibernate… Opravdu nevím, proč bych si kvůli takovým věcem měl psát v céčku nějaký speciální modul pro Apache. V nějakých výjimečných případech možná, když má aplikace jedinečné požadavky, ale jinak je lepší použít pro tyhle infrastrukturní věci hotové řešení.

[kralyk z abclinuxu]

No jo, ale ty běží v Javě a jsou použitelné jen z Javy, ne?
Jinak samozřejmě souhlasim, že vynalézat kolo není dobrý nápad - pokud už kolo existuje...

[Martin Mareš]

Jen mám někdy pocit, že všechna kola, která mi zrovna kdo nabízí, jsou poněkud hranatá

[pht]

V software je na začátku každé kolo hranaté. Kola javy a dotnetu se postupným používáním dobrousily do nějakého bramboroidu, který není dokonalý ale je "dost dobrý". Kola perl5 a php byly od začátku navrženy z gumy takže se za použití dostatečné Síly dají zkrotit. Kolo perl6 bylo navrženo jako přesná kružnice a jako takové zůstává abstraktní. Kola jiných technologií (např. VRML) se při svém nasazení zlomily.

[Martin Petr]

Krásně řečeno.

[kralyk z abclinuxu]

Často s tebou nesouhlasim, ale tohle bylo skvělé!

[Dan Ohnesorg]

Ja bych doporucoval podivat se na to Django, mam pro nej slabost. Ale zrovna deployment neni rozhodne tak plynuly jako u PHP, nebo dokonce i u te javy, pri pouziti slusneho aplikace. V podstate ho muzu bez potizi pouzivat jen protoze nic nehostuji na cizich strojich.

Python lze s klidnym svedomim doporucit pro nejakou virtualizovanou masinu, ale pro sdileny hosting to neni uplne nejhladsi. Pokud to ovsem hosting nema vyresene tak jako appengine. Coz je mimochodem pro novy projekt taky vec, ktera stoji za pruzkum.

[Whoever]

Django není dokonalý, ale velice příjemný framework s ochotnou komunitou. Určitě doporučuju.

Proč by deployment nebyl plynulý? Když chcete hosting, kupte si ho u webfaction nebo djangoeurope, není to drahé a dostanete u nás nevídané služby, jako shell nebo postgres. Během pár minut můžete být online klikáním myší.

[Dalibor Smolík]

Django je zajímavé, zejména sekce "admin" je velmi šikovná, avšak při provádění složitějších výpočtů z tabulek mi php připadá operativnější, ale je to jen o zvyk .

[pavlix]

Tomu se mi nechce věřit, o těch tabulkách.

[Dalibor Smolík]

Dám příklad: je tabulka s uvedením data záznamu, množstvím a cenou. Vytvoření sloupce s celkovou hodnotou za vložený údaj samozřejmě není problém, ale již není jednoduché vyhodit součet celkových hodnot za určené období (např. od 15.4. do 19.8. - datumy se zadávají z formuláře).Řešení se najít dá, ale v php to mám za dvě minuty sestavené .

[pavlix]

Jasně, chápu. Já jsem podrobně django nezkoumal, docela dobře to má udělané SQLAlchemy (i když taky člověk pákrát zakopne, než se to naučí), to obdivovali i Rubysti.

SQLAlchemy se používá mmj. jako součást frameworku TurboGears, ale nikdy jsem s tím jako s celkem nedělal. Vždycky jsem si vzal jen ty části, co jsem potřeboval.

Takže pokud django, tak se naučit jak to řešit (holt SQL není všechno), nebo pojmout django trošku volněji. Zkoušel bych to první.

[xkucf03]

To bych spočítal v SQL:

SELECT	sum(cena*mnozstvi) 
FROM	zbozi
WHERE   datum BETWEEN ? AND ?;

a pak je mi jedno, jestli je nad tím PHP, Python, Java nebo cokoli jiného.

[Dalibor Smolík]

Jasně, klasický sql dotaz .. Django funguje trochu jinak a snaží se přímým sql dotazům vyhnout kvůli sql injection ...

[xkucf03]

OMG Základní ochranou proti SQL injekcím jsou parametrizované/připravené dotazy – vždyť to umí i PHP. Dotaz se pak „nelepí“ z kousků textu, ale dají se do něj otazníky (nebo pojmenované parametry – např. :a, :b). Dotaz se pak naparametrizuje pomocí metody, např. setString(1, $_GET("jmeno")), a ať uživatel do GET parametru zadá cokoli, máme jistotu, že nám SQL dotaz nerozbije.

P.S. jednou mi dokonce někdo tvrdil, že SQL je špatné, protože tam jsou SQL injekce, a že mám používat noSQL databáze, protože tam nejsou

[Dalibor Smolík]

Určitě ochrana v PHP proti injection je (dá se to ošetřit), netvrdím, že není. Chtěl jsem vyzkoušet jen jinou technologii a v djangu jsem narazil na problém, který jsem popsal..

[Jendа]

Není SQL, není SQL injekce. Ze stejného důvodu na Windows nejsou rootkity, ale Administratorkity.

NoSQL injekce?

[Ladicek]

Jasně. Třeba do MongoDB se dá poslat k vykonání kus kódu v JavaScriptu, takže to je JS injection (A stejně jako u SQL, namísto slepování toho kódu se mají vstupy od uživatele předat v samostatném poli, tuším se mu říká "scope".)

[Dan Ohnesorg]

Tohle django samozrejme umi take.

Ma dve moznosti pristupu do databaze, bud pres jakysi metajazyk, ktery mi ale ani trochu nesedl, kde se pisi podminky, spojuji se opratory a system to potom do SQL prelozi. Mozna je to uzitecne pro lidi, kteri SQL neumi. Melo by i zarucit, ze se tam zadna SQL injection neudeje, jednak escapovanim a jednak bindovanim (coz se tam pridavalo pozdeji a nejsem si jisty, jestli uz je to kompletne vsude).

Druhy moznost se jmenuje raw sql a tam si jen vezmete spojeni do databaze, ktere je stale pristupne, a pres nej posilate dotazy. Jestli to delate skladanim SQL nebo bindovanim je uz odpovednost programatora.

Treba ted mam pred sebou:

sql = ("UPDATE %s SET %s = %%s, %s = %%s WHERE %s = '%s'"%(self.db_table,self.blob_column,self.size_column,self.fname_column,name))
self.cursor.execute(sql, (binary, size))

kod na vlozeni obrazku do databaze, protoze to django nativne neumi. Je to uplne stejne snadne jako v php.

[Dalibor Smolík]

nějak si s tím pohraju . Právě "raw sql" jsem se chtěl primárně vyhnout.

[pavlix]

nějak si s tím pohraju . Právě "raw sql" jsem se chtěl primárně vyhnout.

Pak je potřeba místo SQL vybrat jiný, dostatečně silný a pohodlný, prostředek.

[xkucf03]

Ne že bych chtěl to SQL všude cpát ale v čem jiném bys to (#110) chtěl napsat, aby to bylo kratší nebo srozumitelnější?

[Dalibor Smolík]

Také si nedovedu nic jiného představit, protože jde především o ekonomický systém - výpočty, procenta, porovnávání a statistiky..

[msk]

<flame> Spravny javista by ziskal cez hibernate list objektov ( kludne milion ) a nad nim by iteroval a v lokalnej premennej si to nasobil </flame>

[BlackShark]

V práci dělame v Javě + Spring MVC. Doma si občas hraji s Grails,ale prvotní dojem efektivity se u většího projektu dost rychle ztrácí.

[Cervajz]

Za mne můžu říct, že Ruby on Rails je, co se týká efektivity vývoje, na prvním místě. Nikdy jsem neměl rád "programování pro web" a vždycky to bylo utrpení (v PHP). Ale s RoR je to jedna báseň a dost si to užívám. Kdo nezkusil, tak nepochopí :o)

Deployment řeším přes git.

[trekker.dk]

K tomu bych se asi přidal - k RoR jsem jenom tak přičuchnul a udělal něco málo, ale líbí se mi, že to šlo skoro samo

[Limoto]

+1

[retroslava]

'/s/git/capistrano/g' && +1

[pavlix]

Deployment si představuju dost zautomatizovaný, docela hodně používám hook skripty v gitu. K jazyku radši nic říkat nebudu, sám tak trochu hledám a asi se přiučím u MJe a podívám se na perl.

Současný web mám přes shell a awk generované statické stránky a i když to bylo bleskové řešení ve chvíli, kdy jsem to dělal, tak počítám, že perl bude o něco univerzálnější.

[minix]

pouzivam YUI2 a Perl. Engine projizdi predlohu (template), ktery si necham vytvorit na strance YUI (2,3,4 sloupcovy, header, subheader, full width...). Do te predlohy zadam klicova slova pro akce a perl engine (100 radek) nad tim pracuje a pro akci vola perlovske moduly. Tu YUI pouzivam ale hlavne na ty ajax-libustky upload, animace, drag/drop,autocomplete a komplikovane widgety. Pro fulltext pouzivam mnogosearch.

Deployment resim pres rsync.

[Dalibor Smolík]

PHP .. ano, tenhle skriptovací jazyk je poměrně jednoduchý (pro jednoduché úkony, ovšem), tak ho mohou používat i laici, díky němu mám svůj evidenční a ekonomický systém. Ale zajímám se též o django, časem možná přejdu .. člověk se má učit stále něco nového.

[pavlix]

PHP .. ano, tenhle skriptovací jazyk je poměrně jednoduchý

Tak na použití mi přijde tento CGI-like deployment (u PHP asi nejčastější), daleko složitější než CGI skripty v jakémkoli běžně používaném skriptovacím jazyce.

[Josef Kufner]

Psal jsem bakalářku v PHP. Dostal jsem za ni jedničku. Bylo to o návrhu aplikace – výsledkem je celkem pěkné jádro aplikace (v podobě knihovny) a podrobný popis jak to funguje uvnitř.

Výkon problém není. V PHP se píše velmi dobře a rychle, řekl bych, že na web se to hodí líp než Java. Jen je třeba se trochu hlídat a neprasit (asi víc než jinde). Knihovny jsou vyhovujcí na většinu věcí.

[User682]

zdravim,

osobne mam odpor k cemukoli skriptovacimu, co se vice pouziva.

Zajedno ma malokdo vuli neco "neojebat", kdyz je malo casu, unava a tak.

Za dalsi: vazne uvazuju o koupi nejakeho CASE nastroje z mensi penize a kdyz bude treba, tak se dokoupi nebo vezme nejaka hotova knihovna. Vcelku zacinam sazet na generovani zdrojaku - mam uz proslaplou cestu.

Mozna Te zajima efektivita vyvoje, jak rychle udelat prvni nastrel. Chces -li opravdu usetrit cas, tak 1/3 ztrat tvori analyza, dalsi mensi dily je cas na nejake drobne doplnovani+udrzba a osobne bych se spise zameril na efektivitu udrzby a rozsirovani aplikace. U me vede v tomto Java.

Tak nejak si vetsinou rikam, ze kdyz neco pisi, tak ze to bude mala aplikace a ze kdyz se k tomu pouzije nejaky "efektivni" jazyk, tak ze to bude rychleji. V 90% je to vetsi aplikace (najednou se to "zlomi") a jazyky, kde rychle tvoris a pises, co nejmene, jdou do haje. Nejlepsi produkt a nejrychlejsimi opravami a nasazenim za posledni roky je kupodivu HSM delane v Jave.

Uz jsem si jako javista zkusil skriptovaci jazyky(python, php). Ne -li, ze delam ted na stara kolena C-ecko. Je to peklo a efektivita prace jde do haje.

Jednou za cas mi muj zkusenejsi kolega vzdycky rekne nejake novinky okolo skriptovacich jazyku a jak je to skvele. Kolik usetri psani. Vydrzi mu to par tydnu.

gf

[User682]

>tak 1/3 ztrat tvori analyza

drobna oprava: tak 1/3 ztrat tvori __nedostatecna__ analyza

[DRo]

Maximální souhlas. Mít kvalitně zanalyzovaný projekt. Kvalitního analytika, který umí UML,... to je vzácnost.

[Jakub Suchy]

Pisete i o "merku" - jako nastorj na velmi rychly vyvoj je jednim z nejlepsich Drupal - velmi rychla moznost proof of concept reseni, nasledne dotazitelna do vysledne podoby

[xkucf03]

Jasně, Drupal se dá použít jako* framework pro vývoj prakticky jakékoli webové aplikace, jenže ty jsi přes něj machr, takže ti to jde rychle od ruky. Ale když k tomu přijde někdo jiný, tak musí věnovat nějaký čas učení. To sice platí u všeho, ale u toho Drupalu mi to přišlo trochu víc práce než u jiných frameworků – přeci jen než je člověk schopný psát vlastní moduly a šablony tak, aby to nebylo zprasené a dělalo to přesně** to, co chce, chvíli to trvá. Pokud se někdo nechce stát drupalistou, ale chce prostě jen aplikaci podle svých představ, rychle a bezbolestně, tak bych spíš doporučil zvolit nějaký jiný obecný framework.

*) resp. on to je framework, kromě toho, že je to v základu i webové CMS.

**) aby se nemusela aplikace přizpůsobovat Drupalu, aby nevypadala jako blog a aby ten Drupal byl pro uživatele více méně neviditelný a v pozadí – prostě pomoc vývojářům, která ale neomezuje aplikaci ani uživatele.

[Max]

Na toto je dobrá joomla, jen ta svinská náročnost je pěkně nahovno :(. A kdo oželí komfort, tak použije dokuwiki :)
Zdar Max

[pavlix]

Nevím, dostal jsem to do ruky a přišlo mi to strašně neohrabané... ale posuzoval jsem to hlavně jako CMS a možnosti použití ze strany uživatele. O uživatele mi šlo především, protože uživatel nebyl technik ani programátor.

[Max]

Jojo. To je pravda. Joomla, když jí člověk zná, tak je rozjetá hned + několik pluginů na požadovanou funkčnost. Najít podobné téma, které se pak jen přiohne také není problém. Ale samotné vkládání článků, stránek atd. mi uživatelsky přijde velmi nepřehledné.
Zdar Max

[Jakub Lucký]

Pod to se můžu podepsat... Přidat článek a dostat ho do menu je občas nadlidský úkol... A mají pěkně hloupě (aspoň na webu, kde se s Joomlou potkávám) udělané vkládání obrázků

[|🇵🇸]

Python (Django), možná* i Ruby (RoR) -- ale může být problém s hostingem, pokud to nepoběží na vlastním serveru. Případně něco v PHP, ale to už jsem neviděl několik let. Ale na druhou stranu, pokud umíš v Javě (umíš), proč hledat něco jiného?

* se snad každou novou verzí Ruby rozbijou RoR, přitom je to ta hlavní věc, co Ruby má

[pavlix]

Problémy s hostingem jsou čím dál tím menší, v době kdy virtuální servery jdou sehnat v řádech do stovek korum měsíčně.

[lcf]

Perl alebo Pyhton v spojeni s GITom...

[dementni.lojzik]

v čem vyvíjet webové aplikace?

IMHO zalezi na tom, jake ... u malych (MVC s par use case) je IMHO vcelku jedno, co to bude, zkratka to, co clovek umi U vetsich bych si prvne dal (pokud mozno peclive) dohromady, co vsehcno by to melo umet, co bude potreba a vybiral podle toho... (se mi kdysi stalo, ze jsem bezhlave vybral Groovy, ze se neco noveho naucim, a ve chvili, kdy jsem zjistil, ze tam neni podpora XML-RPC pres HTTPS (nebo neco podobneho, nejsu si uz uplne jisty), tak jsem musel resit, jestli to prepisovat do Javy nebo si to tam sam dodelat ... takze misto efektivniho vyvoje jsem venoval relativne dost casu reseni tohoto problemu a nadavani si, jaky su dement)

[Vskutečnosti Saýc]

Zni jako dobrej pristup.

Jenom doplnim, ze v dnesni dobe se snadno muze stat, python nebo ruby budou levnejsi, ac jsou pomalejsi, pac cas programatora stoji min jak koupit dalsi tri servery.

[bazil]

PHP frameworky sou vcelku hezká věc, například takový CakePHP ... rychlost vývoje je vskutku veliká a křivka učení mi připadá taky strmá. Prasit to člověka až tak moc nenechá, jen občas kulhá dokumentace a některé špeky si člověk musí vyčíst s kodu jádra frameworku.

[__dark__]

Pokud jde o aplikace používající DB, tak mám zkušenost s Java+Hibernate a Python+SqlAlchemy. Druhá varianta u mě vyhrála. Java pro me znamenala asi 10x víc kódu a doba restartu serveru i u velmi malého projektu začala být nesnesitelná.

[Ondrej]

PHP 5.3 v kombinaci se Zend Frameworkem je bezproblemova kombinace. Deployment se da resit pomoci postcommitu v SVN/Gitu plus vetve pro devel/testing/stable.

V pripade vykonnovych problemu pouziti memcached pro data, opcache pro skripty, cachovat DB dotazy.

[Karel]

My na webove aplikace v prostredi SAP vyuzivame Web dypro ABAP, technologii, ktera umozuje vyvyjet webove aplikace postavene na SAP Web application server. Muzeme tak snadno vyuzivat celou business logiku SAPu....

[Miloslav Ponkrác]

Na nepřesnou otázku dostaneš nepřesnou odpověď. Omlouvám se, ale je to nejlepší, co jde na Tvůj blog říci.

Každý nástroj pro web má své plusy a mínusy – je třeba je zvážit. Je třeba zvážit vhodnost každého pro konkrétní věc, kterou hodláš dělat a konkrétní podmínky, které máš.

Java je dobrý nástoj – někde a někde ne. PHP je dobrý něstroj – někde a někde ne. Atd.

V každém z jazyků se dá rozumně napsat framework a rozumně vyvíjet.

Pokud nehodláš nic prozradit, nemůžeš dostat dobrou odpověď v blogu.

[Leoš Literák]

Jedna z otazek byla konkretni - v cem vyvijeji velke firmy sve stranky.

[pht]

v cem vyvijeji velke firmy sve stranky.

Z mých zkušeností je to v pořadí popularity java, .net, php.

[pavlix]

Velcí hráči se tuším Javy docela drží.

[insider]

Třeba internetové bankovnictví ČS je napsané v Javě. Pohání jej 4 aplikační servery BEA WebLogic běžící na HP-UX, databáze Oracle RAC a představené tomu jsou Apache jako proxy. Infrastruktura skoro k nezaplacení a celé je to dimenzované jen pro 2500 uživatelů.

[rastos]

U nás: Java. Ale je pravda, že znalcami PHP/Pythonu/Ruby sa to tu nehemží a aj projekt už existuje asi dlhšie, ako tieto jazyky .

[|🇵🇸]

Moment, Python je AFAIK z roku 1991, ale to Java jaksi ještě nebyla...

[rastos]

Dobre Python existoval skôr. Bol pred rokom 2002 aj použiteľný (a to nie len technicky, ale aj dostupnými programátormi a nástrojmi) na rozsiahly projekt siahajúci od webových služieb až po komunikáciu s databázou ?

[Sajfi]

Záleží, co je definice velké firmy, ale konkrétně homepage www.centrum.cz a rodina webů zena.centrum.cz je stavěná nad Pythonem a Djangem.

[msk]

Bavime sa tu o weboch, alebo webovych aplikaciach? Pretoze ja si pod slovom "webova aplikacia" predstavujem cosi v javascript-e, vaadin, eclipse rap a podobne. Ale moc sa v tejto problematike neorientujem, len sa rozkukavam.

[stanger]

Muzu z praxe srovnat Wicket+Spring+JPA (+ tuna dalsich Java frameworku) VS RoR. RoR svoji jednoduchosti u me suverene jede. Samozrejme by to chtelo konktretnejsi informace.

[Cervajz]

+1

[msk]

Teda musim povedat, ze po zhliadnuti http://rubyonrails.org/screencasts som dost silne nechapal. Na druhu stranu je to pre mna tazke pochopit, pretoze miera abstrakcie mi na prvy pohlad pride hrozne vysoka. Skusim sa na to pozriet, ked mi zostane trocha casu ...

[pht]

Java má výhodu, že je strong typed a je pro ni hromada knihoven. Deployment je ale složitější, špatně se nahrávají na server změny.

Deployment se v optimálním případě dělá jedním příkazem, a je dost jedno v jakém jazyce je to celé napsáno.

Dále je problém v dostupnosti programátorů. U linuxáků je obvzláště neoblíbená. Dále jsem znal PHP, kde lidí dělajících v PHP je hromada, ale bohužel procento programátorů je mezi nimi celkem nízké.

Nezávisle na tom jaký zvolíte jazyk bych se na OS vůbec nedíval. Všechna jmenovaná prostředí jsou více-méně multiplatformní a webový server na kterém to pojede je také multiplatformní. Mnohem víc se vyplatí sehnat pořádného programátora a naučit ho nějaký OS než naopak.

[rADOn]

Co byste vybrali?

Nevěřím na žádné "jeden jazyk vládne všem, jeden všem jim káže…" Já bych si vybral podle zadání. Když to bude nějaká bankovni megaaplikace, kde na každý řádek kódu připadá stránka analýzy, tak Javu. Když půjde by šlo prevážně o práci s textem, tak perl. Když by to mělo být hodně flexibinlí, tak Ruby nebo Python. Jednoduché věci je nejrychlejší zbastlit v php. A na extrémní výkon samozřejmě C, ale to bych asi šel cestou prototypování v pythonu a následného přepisu jen toho nejdůležitějšího do C.

[Martin Mareš]

Mimochodem, na tu bankovní megaaplikaci (stejně jako na cokoliv, kde je kód míněn hlavně jako odraz komplikované specifikace) by se mohla daleko víc hodit Ada.

[pht]

Jo Ada, to je další potápějící se loď.

[Leoš Literák]

Upřesním:

• pod složitým deploymentem si představuji javu, kde mám vycheckoutovaný adresář se zdrojáky, ten musím zbuildovat a výsledek nahrát do aplikačního serveru, který (někdy) musím restartovat. Těžko ale říci, jak to bude vypadat u jiných programovacích jazyků. I u skriptovaného PHP je asi dobré odpojit deploy adresář od checkoutu, aby se uživatelům zbytečně neobjevovaly .scm adresáře (nebo je skrýt v apachi).
• u abíčka jsem měl problém, že javy se každý bojí. Designerovi těžko mohu dát do ruky freemarker šablony nebo rozsekané jsp. Ideální je, pokud mohu provozní věci (třeba úpravy designu nebo nasazení reklam) delegovat do rukou někomu cizímu, kdo nemusí být programátor. Robert to zvládal, ale IMHO byl světlá výjimka.

[jehovista]

Tak nahrani do aplikacniho serveru muze byt soucasti buildu.

[pht]

pod složitým deploymentem si představuji javu, kde mám vycheckoutovaný adresář se zdrojáky, ten musím zbuildovat a výsledek nahrát do aplikačního serveru, který (někdy) musím restartovat. Těžko ale říci, jak to bude vypadat u jiných programovacích jazyků. I u skriptovaného PHP je asi dobré odpojit deploy adresář od checkoutu, aby se uživatelům zbytečně neobjevovaly .scm adresáře (nebo je skrýt v apachi).

A co je jednodušší než

git pull
mvn clean deploy

Nebo snad chcete říct že byste rád dělal deployment tak, že prostě vyeditujete pár .php souborů pod rukama běžícího serveru?

Designerovi těžko mohu dát do ruky freemarker šablony nebo rozsekané jsp.

Tohle nechápu - šablony jsou právě od toho aby se dávaly do ruky designérům. To že je někde napsáno něco jako $obsahčlánku to dnešní designery nerozhodí.

[pavlix]

Nebo snad chcete říct že byste rád dělal deployment tak, že prostě vyeditujete pár .php souborů pod rukama běžícího serveru?

To je na PHP běžný standard.

[Leoš Literák]

Deploy na abíčku je poměrně jednoduchý: svn up && ant. Nicméně mám exploaded war. A je nutné restartovat jetty, když se mění java.

[pht]

Tahat vývojářské SCM do produkčního prostředí je něco co se dělat nemá, a to asi z milionu dobrejch důvodů.

Normální postup je ten war (nebo cokoliv co je ta produkční věc) vybuildovat u sebe a nakopírovat ho tam kam patří (což přesně dělá funkce deploy).

[pavlix]

pod složitým deploymentem si představuji javu, kde mám vycheckoutovaný adresář se zdrojáky, ten musím zbuildovat a výsledek nahrát do aplikačního serveru, který (někdy) musím restartovat. Těžko ale říci, jak to bude vypadat u jiných programovacích jazyků. I u skriptovaného PHP je asi dobré odpojit deploy adresář od checkoutu, aby se uživatelům zbytečně neobjevovaly .scm adresáře (nebo je skrýt v apachi).

Ať už vybereš cokoli, navrhuju zautomatizovat. U svých věcí používám make a shell skripty plus mínus nějaké to awk, které pravděpodobně v budoucnu nahradím perlem.

u abíčka jsem měl problém, že javy se každý bojí. Designerovi těžko mohu dát do ruky freemarker šablony nebo rozsekané jsp. Ideální je, pokud mohu provozní věci (třeba úpravy designu nebo nasazení reklam) delegovat do rukou někomu cizímu, kdo nemusí být programátor. Robert to zvládal, ale IMHO byl světlá výjimka.

Joo, doupravování šablon je velký problém... zatím jsem byl jenom u metody, kdy se vezme statická stránka, v té se udělají úpravy, a programátor ty úpravy dolepí do šablon. Pořád jsem se poohlížel po šablonovacím systému, ke kterému budou nástroje pro designéry.

[Josef Kufner]

Joo, doupravování šablon je velký problém... zatím jsem byl jenom u metody, kdy se vezme statická stránka, v té se udělají úpravy, a programátor ty úpravy dolepí do šablon. Pořád jsem se poohlížel po šablonovacím systému, ke kterému budou nástroje pro designéry.

A co to vyřešit jednoduše: Nepsat HTML.

[pavlix]

A co to vyřešit jednoduše: Nepsat HTML.

Tohle řešení tak úplně nefunguje.

Jistě, máme různé wikitexty a podobné... ale ty jsou na články, ne na layout (na který mimochodem ani HTML není žádný zázrak). Navíc někdo musí napsat konvertor... a někdo musí napsat stylopis.

No a pokud jde o různé frontpage a composery, tak to nelze seriózně vůbec uvažovat.

[Josef Kufner]

Na texty je wysiwyg. Mluvím o layoutu – udělat (polo)klikátko na návrh layoutu a k tomu vygenerovat kostru pro CSS je hračka.

[pavlix]

Na texty je wysiwyg. Mluvím o layoutu – udělat (polo)klikátko na návrh layoutu a k tomu vygenerovat kostru pro CSS je hračka.

Praxe mluví jinak.

[Josef Kufner]

Kdepak, tohle z praxe je

[pavlix]

Jako jo, znal jsem dokonce i učitelku, která dělala *webovou stránku v excelu :).

Ono záleží taky na tom jaká praxe a na jaké úrovni, že.

* Abych byl spravedlivý, byl to export excelské tabulky a plácnutí do textu stránky.

[Josef Kufner]

Excel a podobný blbosti do toho netahej. Mluvím o tom, že si v CMS naklikáš šířky a uspořádání sloupečků a ono to vygeneruje slušný layout postavený na pár divech a CSS. K tomu ti z toho vypadne i základ onoho CSS, kam dopíšeš jak ty sloupečky mají vypadat. Žádný prasárny. Jen strávíš tvorbou layoutu desetinu času a máš jistotu, že to bude i v IE dobře.

Ten wysiwyg se používá až na vlastní texty, které tam vkládají uživatelé a CMS to jen důkladně pročišťuje.

[pavlix]

Mluvím o tom, že si v CMS naklikáš šířky a uspořádání sloupečků a ono to vygeneruje slušný layout postavený na pár divech a CSS.

To jsi neřekl. On ty divy a cssko ale vždycky musí někdo připravit.

Já jsem v poslední době spíš viděl takovýten klasický webový cyklus, který začíná grafickým návrhem, ne výběrem z připravených layoutů. Prostě klasické firemní prezentace.

Ale i v případě různých hotových CMS musel někdo ty divy předpřipravit, tzn někdo musel to HTML umět a pokud něco nevyhovuje, někdo musí do toho CMS hrábnout a změnit to.

Ale pokud se pohybuješ mezi odborníky, kteří často používají slovo "nejde" místo "stálo by to o tisícovku víc", tak to pak jo.

Ten wysiwyg se používá až na vlastní texty, které tam vkládají uživatelé a CMS to jen důkladně pročišťuje.

Na toto jsem už odpověděl. Jestli se použije wikitext nebo tlačítkový editor je v podstatě jedno. Wikitext má výhodu přesnějšího ovládání, wysiwyg má výhodu větší myšovitosti.

[Josef Kufner]

S klasickým webovým cyklem se to nevylučuje... vlastně to s ním funguje velmi dobře: Dostaneš obrázky, nařežeš obrázky, naklikáš sloupečky/řádky, umístíš obrázky.

Jinak jo, na začátku to musel někdo připravit, ale pak už to jde rychle. A ty layouty připravené nejsou, připravený je jen nástroj na jejich tvorbu (a ten je dosti univerzální).

[pavlix]

(a ten je dosti univerzální).

Tady bych právě čekal to slabé místo.

[xkucf03]

BTW: nebyl jste někdo včera na setkání drupalistů? Řešilo se tam podobné téma – jak udělat web zároveň flexibilní a zároveň tak, aby ho BFU nemohli rozbít.

[Josef Kufner]

Tak vždycky je dobré si tam nechat cestičku, jak tam nacpat i něco jiného, ale jakmile se jednou vychytá floatící div tak, aby se choval slušně a všude stejně, tak je to pohodička.

[Josef Kufner]

Co jsem dělal jeden větší projekt, tak tam byl deployment řešen dvěma způsoby:

1. Testovací (vývoj): Script v bashi, který rsyncnul lokální pracovní kopii se serverem.
2. Produkční (zdrojáky otestované): Instalátor napsaný v PHP, který běžel na cílovém hostingu a stahoval z repositáře automaticky připravované balíčky s aplikací, které nainstaloval, provedl kontroly, zapracoval změny v databázi a nakonec přihlásil admina do administrace. Navíc se instalátor spouštěl z administrace a upgrade je mnohdy otázkou pár kliknutí na "pokračovat". Žádné ssh, příkazy, nic, jen klikání v browseru. Velmi praktické a jednoduché, zvládá to i manager/obchodník.

Takže ono je nakonec stejnak nejlepší tohle integrovat přímo do aplikace a nechat ji ať si to pořeší sama.

[PMD]

Samozřejmě v JavaScriptu. Těžiště úspěchu je ve frontendu, co běží vzadu už je jen o zdravém úsudku a osobních preferencích.

[|🇵🇸]

Počkat, ty myslíš, že VBScript není to pravé? ^__^

[PMD]

Hnedle za Flexem.

[alblaho]

Na jazyce až tak nezáleží a různé velké systémy jsou v lecčem.

NASA docela používá Plone (nad Zope, Python), někdy bych to chtěl prokopnout. Já se bojím té custom objektové databáze, tak jsem to zatím nikde nenasadil a šel jsem spíš do věcí jako DjangoCMS.

Jinak osobně mám rád Python a Django je docela OK. RoR jsem prakticky nezkoušel. Java je sice ze začátku neohrabaná, ale zase jsou pro ni IDE s refaktoringem. PHP a Perl jsou hnusy, ale i v nich se dá napsat dobrý soft.

[xvasek]

PHP a Perl jsou hnusy, ale i v nich se dá napsat dobrý soft.

Stejně tak jistí programátoři umí psát Fortran v jakémkoli programovacím jazyce.

[mess]

Mám zkušenosti s Rails a musím říct, že se v to vyvíjí skoro samo. Problémy ale můžou nastat (a u nás ve firmě nastaly), pokud bude větší návštěvnost. Zejména stabilita a paměťová náročnost byly největší problémy. Vyzkoušeli jsme kde co a nakonec jsme se rozhodli napsat nový systém v Javě.