Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - eMko

Stran: 1 ... 24 25 [26] 27 28 ... 31
376
Server / Re:php a upload soborů
« kdy: 11. 05. 2013, 14:33:42 »
Nějak se mi nezdá druhý argument move_uploaded_file. Máš v proměnné $_FILES["file"]["name"] celou cestu? (např. "/home/web/uploads/Hare Kršna.pdf")? Kromě toho bys tu cestu neměl číst ze vstupu od uživatele.

Viz příklad v http://php.net/manual/en/function.move-uploaded-file.php - cestu tam mají někde v konfigurační proměnné a move_uploaded_file volají s '$cesta/$_FILES["file"]["name"]' .

377
Vývoj / Re:Proč je JavaEE nepopulární?
« kdy: 11. 05. 2013, 13:29:13 »

Dobře, že jsi zmínil alternativní jazyky, které se provozují nad JVM – to v podstatě odpovídá na výtky v prvních dvou odstavcích.

Ano, Javu jako jazyk používám jen když musím :)

Jinak když se v tomto threadu zmínil OpenShift, nevšiml jsem si zmínky o Cloud Foundry. Na mission-critical projekty to asi není, ale "hraní si" ... mají nativní podporu pro Grails (Groovy) a Play (Scala).

378
Vývoj / Re:Proč je JavaEE nepopulární?
« kdy: 11. 05. 2013, 12:35:17 »
Java je neoblíbená především u lidí, kteří "programují pro zábavu". Ten jazyk je sice čistý, ale programy v něm jsou pohádka na dobrou noc. V C# a v PHP např. můžu předat anonymní funkci jako argument do jiné funkce, v Javě musím vytvořit novou třídu (naštěstí stačí anonymní), která implementuje rozhraní IRunnable a tu teprve předat.

V C# můžu vzít kolekci a transformovat ji na jinou (kolekce.Select(...)), stejně tak v PHP (array_map(...)). V Javě to udělat nelze - je třeba vytvořit instanci nové kolekce, foreachem projít původní a přidávat prvek po prvku do té nové.

Místo použití .Net třídy ObservableCollection, která všem objektům, které o to mají zájem, dá pomocí eventů echo o tom, že se do ní přidaly / z ní odebraly prvky, musím v Javě řešit přes ObserverPattern. Srovnej třídu přímo v .Netu http://msdn.microsoft.com/cs-cz/library/ms668604.aspx a v ApacheCommons (která sice není součástí Javy, ale mnoho lidí ji bere jako "základní knihovnu", asi jako boost u C++) http://commons.apache.org/dormant/events/apidocs/org/apache/commons/events/observable/ObservableCollection.html

 Atd... je toho hodně.

Takto se dá pokračovat. Zatímco jazyk PHP je prasárna a nic víc než zpropadená prasárna, rychlost vývoje je vyšší a u drobných aplikací máš menší paměťové nároky a kratší (= čitelnější a přehlednější) kód. Upřímně (přestože jsem full-time C# vývojář), PHP jsme na jeden projekt použili taky: Win8 Store aplikačka si potřebuje zjistit, odkud si stáhnout data a někam uložit adresu notifikačního kanálu. Nemá smysl kvůli tomu rozbíhat JavaEE server nebo platit za další Azure server, když pro těch pár tisíc uživatelů stačí malá databáze a něco, co může komunikovat přes REST "protokol". A strčit "ven" další linuxový server s PHP a deploynout projekt je téměř zadarmo. O Javu se musíš starat přece jenom víc. Výhody Javy se projeví až na větších projektech, které ale většina nadšenců nedělá, neb by jim to zabralo víkendy na několik let dopředu. A právě tito lidé (často to ani nejsou profi programátoři; mnozí z nich ani nepracují v IT a nemají IT vzdělání) jsou nejvíce vidět na diskusních fórech. Pro ně je ideální právě PHP a proto to vypadá, že JavaEE je neoblíbená a PHP velmi oblíbené, ačkoliv u profesionálů je pravdou přesný opak.

Pokud Ty se nechceš JavouEE živit, tak spíš než na JSP, které jsou hodně low-level (podobně jako čisté PHP bez frameworku), se můžeš zkusit zaměřit na nějaký high-level framework: mně na školní projekt kdysi celkem sedlo tohle: http://wicket.apache.org/ . Případně na Grails (http://www.grails.org/), což je framework pro Groovy. Groovy je druhý ze dvou oficiálních jazyků pro Java Virtual Machine (první je samozřejmě Java), jedná se o dynamický jazyk, ve kterém se mně osobně pracuje podobně (ne)příjemně jako v C#. Java je opravdu velmi rozvláčná a existuje jedna pravda, že programový kód je to místo, kde jsou chyby. Proto ho piš co nejméně, k čemuž Groovy pomůže. Případně můžeš zkusit jazyk jménem Clojure (taky běží na JVM) - získáš ještě přehlednější a kratší kód (byť si na ten jazyk musíš nejprve zvyknout, přeci jen je to odnož LISP-1) a webové framewroky jsou pro něj taky.

A přestože si na to mnoho vývojářů-nadšenců nepotrpí, tak pro Javu/Groovy lze sehnat lepší vývojová prostředí. NetBeans je dobrý základ, Eclipse má pluginy pro všechno (i když pohodlnost použití pro vývojáře pokulhává) a hlavně IntelliJ IDEA, za kterou se sice platí, ale je úplně the best. Nic takového pro PHP neseženeš a usnadní to hodně práce.

379
Vývoj / Re:Jak se naučit PHP frameworky?
« kdy: 11. 05. 2013, 11:38:07 »
Jinak ty lidi na optimalizaci budes potrebovat na kazdym vetsim projektu.

Přestože se z PHPčka dá vymlátit hodně, neustálé optimalizování není samospásné. Časem stejně zjistíš, že na každý větší projekt je PHPčko málo (ten interpret je relativně pomalý a věci typu Zend Server nemusí vždy pomoct) a skončí to tím, že v PHP bude jen menší část projektu. Zbytek bude buď v javascriptu na straně klienta nebo v C na straně serveru (případně se něco dá přesunout na stranu databáze, tím se ušetří taky dost).

380
Vývoj / Re:Jak se naučit PHP frameworky?
« kdy: 10. 05. 2013, 22:32:47 »
V prvé řadě je blbost "učit se frameworky". Zabiješ nad tím spoustu času a za 2-3 roky jsou znalosti k ničemu. 2 roky jsem nesáhl na Nette a koukal jsem, jak pokročilo. To samé MS MVC framework - v práci jsem používal verzi 2; nedávno jsem narazil na verzi 4 a přímo jsem čučel. Zatímco na desktopu se celkem nic neděje (Swing, WinForms a WPF je furt skoro stejný), webové frameworky se mění neustále.

Každý framework by měl mít za sebou nějaký teoretický základ, architekturu. Chceš mít pasivní pohledy na data, nebo skládáš stránku z komponent s vlastím chováním? Chceš MVC architekturu? Má aplikace běžet spíš na straně klienta, nebo serveru? Mají být pohledy defaultně stavové (automatická správa session), nebo bezstavové (ruční)? ... Tyto otázky je potřeba nejprve zodpovědět a vybrat k nim vyhovující framework. Rozhodně není dobrá cesta si nejprve pročítat tutoriály - těžko se budou dát rozumně pochopit, pokud nechápeš myšlenku, která za tím frameworkem je a nevíš, jak má vlastně výsledek vypadat. Mnoho PHP frameworků vzniklo tak, že nějaký borec začal tvořit web, všiml si, že spousta věcí se neustále opakuje, tak je nějak naházel do knihoven, postupně tu a tam něco přidal a nazval to framework. To je špatně a od takových věcí je lepší dát ruce pryč; bohužel v PHP světě je takových frameworků mnoho - ostatně sám jazyk PHP se takto "vyvíjí".

Pokud nevíš, co přesně chceš dělat, pak je zbytečné vybírat framework. To je jako jít někam a nemít definovaný cíl. Může to být zajímavé dobrodružství, můžeš si užít srandu, ale úspěch na trhu to nepřinese. Pokud máš jasný cíl a zvolenou cestu, může Ti vhodný framework hodně pomoct, jinak to bude spíš přítěž. Pro větší projekty, např. rozsáhlý podnikový informační systém, třeba vhodné frameworky ani neexistují a buď je potřeba si vytvořit vlastní (což je hodně drahá varianta, neboť se tím zabije spousta času, která by se dala věnovat tvorbě samotné aplikace) anebo si přiohnout již existující (tam zase hrozí "nejistý výsledek" a nemožnost upgradu na novou verzi).

A co se týče kvality frameworků, hodně napoví pohled na seznam vývojářů (čím víc aktivních lidí, tím lépe; One-man-show = riziko. Viz http://en.wikipedia.org/wiki/Bus_factor), čichnutí k bugzille (smrdí to hnilobou, i.e. je tam spousta starých bugů na "vyhnití"?), jak je dobrá vývojářská dokumentace (je alespoň popsané veřejné API?), diskusní fóra (existují veřejná místa, kde lze hledat pomoc přímo od vývojářů?), organizace a kvalita zdrojového kódu (jsou API tvořená tak, aby výsledný kód byl dobře čitelný (např. Fluent interface)?, jsou alespoň veřejné funkce dobře okomentované?, je jasné, s jakými datovými typy funkce pracují?, je možné při pohledu na zdrojový kód funkce bez dlouhého přemýšlení říct, jaké má vstupy a co je její výstup?) a v neposlední řadě rychlost a paměťová náročnost výsledné aplikace.

381
Vývoj / Re:Lokalizovat výjimky nebo ne?
« kdy: 09. 05. 2013, 12:42:12 »
moznost ze je muze c&p a posalt nam je jako bug je samozrejma

Ze zkušeností, pokud uživateli zobrazíš pouze text (message) výjimky, který Ti pošle, bude Ti takové hlášení celkem naprd, neb z něj nic nepoznáš. V mnoha případech se Ti totiž nepodaří tu chybu reprodukovat u sebe, ani kdyby Ti uživatel napsal přesný postup, kterým ji vyvolal. A to se nestane, s tím mají potíže i někteří testeři.

Pokud chceš, aby v textu, který Ti uživatel pošle, byly všechny možné údaje, které by Ti nějak mohli pomoct odhalit problémové místo, pak tam těch údajů bude fakt hodně. A většina uživatelů se dlouhého textu (byť srozumitelného a v jejich jazyce) lekne, hlášku odklepne a možná za týden Ti dá hlášení. Když na něj vyhodíš stack trace, tak jaká bude reakce? "Vypsalo mi to nějaký nesmysly" "Jaký, potřebuju ty nesmysly vidět" "Vám říkám, vole, že to byly totální nesmysly"

382
Vývoj / Re:Lokalizovat vyjimky nebo ne?
« kdy: 09. 05. 2013, 09:24:16 »
My je nelokalizujeme. Důvod je ten, že pokud se uživateli vypíše nějaká hláška, která dle jeho názoru s provedenou akcí nesouvisí, tak Ti akorát sdělí, že "to vypsalo nějakou chybu". U každé akce sdělujeme uživateli obecnější hlášku šitou na míru dané akci a tu výjimku jako takovou buď zalogujeme nebo (je-li uživatel online) přes webovou službu pošleme k nám. Tím pádem je nepotřebné ty hlášky lokalizovat, bylo by to spíš na škodu; zkus si luštit nějakou hlášku v maďarštině.

383
Odkladiště / Re:Outsourcing developingu
« kdy: 26. 04. 2013, 06:21:50 »
Jinak brigádníka si myslím, že je možno najmout i levněji než za 10€, takový plat často nemají ani zaměstnanci, tedy pokud se bavíme o "hrubé" a ne "superhrubé" mzdě (hrubá + odvody, které platí změstnavatel). Nicméně za freelancera s adekvátními zkušenostmi a dobrou kvalitou práce je to málo.

384
Odkladiště / Re:Outsourcing developingu
« kdy: 26. 04. 2013, 06:15:57 »
Jenom to ne, jestli někdo chce mít funkční kód a ne neudržovatelný bo.del, pak brigádník ne.

Celkově je rozšířený názor, že "chci ušetřit, najmu studenta - však on to zvládne, je ve vyšším ročníku, většinu už umí". Jenže ona škola dává teoretické základy s možností si něco "osahat" (= proto je každý semestr X samostatných projektů; stolař taky neprojde učilištěm, aniž by věděl, jaký je to pocit položit ruku na dřevo nebo jak těžká je pila), ale rozhodně člověka nenaučí být dobrý programátor. Proto také existuje pracovní pozice "developer junior", charakteristická tím, že junioři se zásadně nepouští k samostatné práci nebo na kritické projekty. Vždy je nad nimi nějaký dohled. Ten jim sice většinou nemusí celou pracovní dobu čumět přes rameno, ale kontroluje, co dělají, upozorňuje je na prasárny a na to "jak to napsat líp". Samostatná práce zde, stejně jako v každém jiném odvětví techniky, vyžaduje zkušenosti, které na škole ajťáci nedostanou (ani nemohou, protože ty zkušenosti na škole nejsou). Nezkušený člověk na samostatném projektu = cesta do pekel.

Neříkám, že každý junior/čerstvý absolvent je lempl a jeho práce za nic nestojí (ostatně, každý nějak začíná), ale z nedostatku zkušeností jsou takoví lidé schopni zvolit řešení, které jim nyní připadá v pohodě, aby je za měsíc vyliskalo a museli kvůli tomu přepsat polovinu aplikace. Tomu právě zkušenosti nebo zkušený dohled zabrání.


385
Odkladiště / Re:Outshourcing developingu
« kdy: 25. 04. 2013, 08:44:52 »
Pokud je to "váš první" outsourcing, určitě berte evropana nebo někoho z USA (kde je ale zhoršená komunikace kvůli časovému posunu - ze začátku to sice vypadá, že je to drobnost, ale může to po čase začít pěkně s...t). Indové bývají relativně levní (i když už to není co bývalo), anglicky umí obstojně, ale jejich mentalita a styl práce je velmi odlišný, stejně jako u ostataních asiatů. Ostatní evropani nebo Amíci jsou smýšlením/kulturou/stylem práce/stylem používání PC velmi podobní nám.

Jinak jestli sídlíte v nějakém větším městě (Praha, Brno, Ostrava, Bratislava), co se zkusit rozhlédnout po okolí a zadat to nějaké ne-zcela-nové-a-malé firmě? Větší firmy, které jsou na trhu nějaký ten rok, si většinou drží nějakou kvalitu, mají více lidí (není problém se pro ně otočit v kanclu na židli a zeptat se "Hele, Zdeno, jak bys nejlíp řešil ..., já si nejsu jistej", přestože ti dva nedělají na stejném projektu), byť to bude asi trochu dražší než freelancer. U freelancerů/malých startupů je problém dost kolísavá kvalita nejen napříč trhem, ale i mezi dvěma různými projekty. Vyplatí se zeptat se i firem, které "outsourcing" běžně nenabízí.

Navíc Češi (Slováci) budou mít výhodu, že se s nima domluvíte česky (byť kód, komentáře nebo zadávací dokumentace může být anglicky (což běžně bývá)).

386
Software / Re:Evidence odpracovaných hodin
« kdy: 18. 04. 2013, 23:06:15 »
Dobrý program na sledování práce je https://wosc.cz/cs/ .

387
Vývoj / Re:K čemu programování v BASH?
« kdy: 19. 03. 2013, 12:14:28 »
Bash používám na to, na co bych na Windows použil Powershell

388
Odkladiště / Re:Notebook do bazaru
« kdy: 25. 12. 2012, 22:50:20 »
V bazáči za to dostanete dost málo peněz (je to stejné jako s auty). Aukční server (e-bay, aukro) je mnohem lepší nápad.

389
Windows a jiné systémy / Re:Kde koupit nejlépe SW ?
« kdy: 05. 11. 2012, 11:46:51 »
DK: K tomu ještě připočítej za ReSharper ;-)

Ano, je to hodně a taky mě to štve, ale co už...

390
Vývoj / Re:Vybíráme programovací jazyk
« kdy: 04. 11. 2012, 21:48:50 »
Bohužel to je normální (a myslím, že zcela správně).

(Téměř) libovonou funkci si můžeš volat v kombinacích jako Java/Scala, Java/Clojure, C#/F#... prostě tam, kde na snadnou integraci bylo při vývoji daných platforem myšleno. Ale ani třeba u C#/F# se člověk občas nevyhne "boiler-plate" kódu nebo nějakým omezením, protože v F# chce člověk spíš pracovat s neměnnými daty a v C# s "živými" měnitelnými objekty, z čehož v praxi plyne celkem dost starostí.

Stran: 1 ... 24 25 [26] 27 28 ... 31