Techi's Weblog

6. listopadu se v Pražském Kongresovém centru uskutečnil již druhý ročník akce Google Developer Day, kterou jsem si jako vývojář webových aplikací a fanoušek Google nemohl nechat ujít.

Během úvodního keynote byly stručně představeny novinky v Google produktech. Následně probíhaly každou hodinu současně 4 přednášky tematicky rozdělené na vývojářské produkty Google, mobilní platformy, vývoj webu a entrepeneur, celkem 6 hodin přednášek spolu se zajištěným občerstvením.  Není nutno podotýkat, že Google není žádný troškař. Přednášky probíhaly většinou v angličtině a jejich úroveň byla velmi dobrá. Vývojářům Google není cizí smysl pro humor.

Většinu času jsem strávil na přednáškách ohledně vývoje webu. Zde je pár mých postřehů:

Bylo představeno HTML 5, ke kterému jsem trochu skeptický. Byla demonstrována snadná práce s videem na webu, canvas, díky kterému můžete kreslit na webu v reálném čase složité animace bez nutnosti používat obrázky nebo Flash. Javascript, který běží ve vlastním vláknu a nebrzdí tak reagování stránky. HTML5 je samozřejmě nepoužitelné dokud bude existovat Internet Explorer. Google si je toho vědom a proto usilovně vyvíjí Google Chrome Frame, což je obyčejný plugin pro Internet Explorer 6 a výše, který vlastně nahrazuje renderovací jádro exploreru chromem. Dalším problémem je nejednotná podpora kodeků videa. Safari umí jen H.264 + AAC, Firefox a Opeera Ogg Theora, Google Chrome obojí a IE pro změnu žádný

Byl představen Google Wave. Podívejte se na demonstraci Google Wave PULP FICTION.

stojí to zato, kde se přednášející snažil vyvrátit, že Google Wave je náročný na používání. Něco na tom bude.

Google App Engine a podpora offline aplikací s HTML5. Google usiluje o naprosté propojení webových a desktopových aplikací. A snad posledním krokem je to, abyste si mohli pustit vaší aplikaci z prohlížeče, ikdyž nemáte připojení k internetu. Podporováno kromě Google Chrome i iPhoneOS.

Zajímavou technologií je PubSubHubbub, což je (zjednodušeně) server-server protokol, který řeší nevýhody, kdy např. obrovský RSS feed je posílán znovu a znovu, ikdyž se v RSS nic nezměnilo a zbytečně tak zatěžuje traffic. Namísto toho se posílají pouze ta data, která se od minule změnila pro daného klienta. Také řeší funkci Observera, kdy se změny ve feedu promítnou v reálném čase.

Představeny soubor tipů a triku, jak optimalizovat načítání webových stránek. Informace a články lze nalézt na Google Code

Zajímavou přednáškou byly nástroje pro vývojáře v Google Chrome, kde je vlastně také implementována web developer toolbar - tedy obdoba Firebugu. Byly představeny i novinky ve Firebugu 1.5, který bude připraven k použití spolu s Firefoxem 3.6

Na dalších přednáškách už jsem usínal, protože už toho bylo na mě moc Nakonec jsem si osobně popovídal nad mým oblíbeným pivem o chystaných novinkách. Google připravuje novou službu Google Boobs, která se soustřední pouze na vyhledávání pornografického obsahu

Vložil Techi

Většina programátorů nahrává zdrojové kódy na web přes FTP pomocí nějakého obyčejného FTP klienta. Na tom samozřejmě není nic špatného. Pokud ale spravujete rozsáhlejší aplikaci, mohou nastat problémy. Buď chcete nahrát pouze změněné soubory a na některý zapomenete nebo pro jistotu chcete nahrát všechny, což může trvat i několik desítek minut (pro nás co nemáme optická vlákna) a spojení se může uprostřed přenosu souboru přerušit a tím pádem může přestat fungovat i celá aplikace. Pokud nahráváte aplikaci takto ručně několikrát za den, je to opravdu utrpení.

Na archivování zdrojových kódů všech aplikací používám subversion a všem radím totéž. Setkal jsem se s tím, že
i ve větší firmě se žádný program na správu verzí nepoužíval a programátoři i kodéři házeli soubory na web pátý přes devátý a pořád se rozčilovali: "kterej vůl mi přepsal muj soubor, vždyť jsem to tam včera nahrával!?". V této situaci jsem musel taktně podotknout, že volové jsou všichni.
Díky subversion je vidět kdo, kdy a jaké soubory upravoval, přidal nebo smazal a je vždy možné získat předchozí verzi souboru. Pokud editujete stejný soubor jako váš kolega, soubory se pokusí slít dohromady (merge), v opačném případě jste na konflikt upozorněni. A k aktualizaci všech souborů stačí jedno kliknutí myši. Alespoň pokud nepracujete pouze v shellu

Pokud spravujete více webů, je výhodné mít vlastní linuxový server na
hraní s vysokou konektivitou. Na něm budete mít archivované všechny zdrojáky a zároveň deployment skripty napsané v shellu, které nahrají soubory na web za pár vteřin. Serverhosting je sice trochu dražší než obyčejný webhosting, ale zase vám ušetří čas. A čas jsou peníze


# aktualizujeme soubory v repository
svn update /opt/repository/myapp

# pripravime exportni adresar, kam se nahraji ciste soubory. (V repository jsou totiz skryte .svn soubory)
rm -R -f /opt/deploy
mkdir /opt/deploy
cd /opt/deploy
svn export /opt/repository/myapp

# upravime adresar pokud je potreba
mv /opt/deploy/myapp /opt/deploy/httpdocs

# a nahrajeme na FTP
ncftpput -R -v -u username -p password ftp.example.com / /opt/deploy/httpdocs


 

Vložil Techi

Při testování SDL knihovny pro Pocket PC jsem zkompiloval demo aplikaci, která softwarově renderuje oheň. Napadlo mě, že by se někomu tato blbůstka mohla líbit. Po spuštění promění váš telefon/PDA v příjemný krb s plápolajícím ohněm. Zvuk na pozadí jsem nedával, aby se nevytěžovalo CPU. Testováno na PPC2003/WM5/6/6.1. Licence GPL

Stáhnout XflameCE 1.0

Vložil Techi

U čtenáře sepředpokládá základní znalost programování, angličtiny, jazyka C, Windows API a orientace v mobilních platformách

Po delší době jsem se vrátil k programování her, tentokrát pro platformu Pocket PC 2003 / Windows Mobile. Nejsem žádný profesionální herní vývojář, je to spíš hobby. Každopádně už jsem starý na to abych hry vymýšlel a programoval. Jednodušší je vzít existující oblíbenou hru s otevřeným zdrojovým kódem a upravit jí pro Windows Mobile.
Chvíli mi trvalo než jsem se zorientoval okolo dostupných knihoven pro vývoj her, ale pokud máte podobný záměr, tak vám snad usnadním trochu práce.

Grafika

Podívejme se nejprve na možnosti zobrazování grafiky na platformě Pocket PC

GAPI
Kdysi v počítačovém středověku (cca rok 2001) Microsoft uvolnil "herní" knihovnu nazvanou GAPI neboli Game API. V ROM jí najdete jako knihovnu gx.dll.  Nejvtipnější ovšem je, že tuto knihovnu Microsoft za těžké peníze odkoupil od firmy
Revolutionary Software Front, která tuto knihovnu původně vytvořila, když portovala legendární hru Doom pro Pocket PC. Jedná se přitom o velice low-level knihovnu, která vám dá jenom přístup k ukazateli na displej. Je to samozřejmě velice rychlé, ale knihovna samotná neumí vykreslit čáru ani obrázek. Vše ostatní si (ne)musí programátor napsat sám, ale k tomu se dostanu později. Knihovna je napsána v čistém C, ale existuje i wrapper pro .NET CF (C# a Visual Basic). Když jsme u programovacích jazyků, tak za ideální programovací jazyk pro psaní her považuji C++, resp. C pro malé hry. Jazyky C# a Visual Basic jsou závislé na .NET, který je přece jenom těžkopádný. Aplikace reaguje pomaleji a zabere více paměti, také není (snadno) přenositelná na jiné systémy, ačkoliv uznávám, že vývoj programu postaveném na .NET je pohodlnější a rychlejší.

DirectDraw
S příchodem Windows Mobile 5 Microsoft zabudoval do systému podporu pro DirectX. Konkrétně DirectDraw a Direct3D (tedy herní knihovna původně pro stolní Windows), aby tak usnadnil port stávajících her ze stolních Windows. Zároveň označil GAPI jako deprecated, aby donutil vývojáře her přejít na DirectX. Microsoft se tak oprávněně setkal s vlnou kritiky.

RAWFRAMEBUFFER
Další alternativou je technika RAWFRAMEBUFFER, která obdobně pracuje s displejem jako GAPI. Tj. s ukazatelem na displej. Tato technika ale není moc rozšířená. Používá se třeba, když zařízení pracuje s webkamerou.

GDI
Je grafická knihovna dostupná ve všech verzích Windows. Dovoluje kreslit základní obrazce jako elipsy, polygony, zobrazovat bitmapy. Nevýhodou je blikání obrázovky při překreslování a velmi nízká rychlost renderování oproti ostatním technikám. Proto se GDI na vytváření her nehodí.

OpenGL ES
OpenGL není ve Windows CE podporováno. Existuje však pokus o port 3. strany nazvaný OpenGL ES. Nicméně u zařízení je vyžadována HW akcelerace, bez které se mi žádný program nepovedl spustit. Proto tedy nepřipadá v úvahu. Stránky knihovny zde: http://www.khronos.org/opengles/

GAPI vs. DirectDraw

1. GAPI je mnohem rychlejší než DirectDraw resp. Direct3D (alespoň pokud se používá SW rendering) Navíc co se týče grafických čipů tak je to bída na druhou. Modelů s grafickým čipem (DELL Axim) spočítáte na jedné ruce.  Místo abych jich postupně přibývalo tak jich spíš ubývá. Distributoři používají levnější grafické čipy v nových zařízeních než se používaly předtím. Navíc grafický čip (i přes velké snažení výrobců) je stále velmi energeticky náročný. Chcete aby vám telefon vydržel na hraní her jenom pár hodin?
2. DirectDraw není podporováno v Pocket PC 2003 a starších!
3. Na GAPI je postavena skoro každá "fullscreen" hra. (několik tisíc! her)
4. Na GAPI jsou postaveny i herní frameworky a enginy
5. Aplikace běžící ve fullscreen v DirectDraw nedokáže přepnout na aktivní okno. Např detekovat příchozí hovor a minimalizovat se. Prostě musíte nejdřív ukončit aplikaci a potom zvednout hovor.
6. DirectDraw má také problémy s překreslováním. Např. právě při příchozím hovoru nebo když vyjede start menu. Na displeji zůstanou "mrtvé body"
7. Dokumentace k DirectDraw na Windows Mobile je stručně řečeno ubohá.

A to nemluvím o tom, že tutorial aplikaci k DirectDraw nešla spustit na žádných z 3 systémů s Windows Mobile 5/6/6.1 ani na emulátoru. Aplikace skončila chybou typu nelze inicializovat bla bla bla. Musí se pracně měnit nějaké nastavení v registrech. Navíc dal Microsoft také jasně najevo, že o OpenGL ve Windows Mobile nemá zájem.  Abych to shrnul. Microsoft se může jít s DirectDraw vycpat. <flame>Zkrátka nemá dost inteligentních vývojářů a musí software jenom kupovat od jiných. Takto de facto vzniknul už MS-DOS, ale to je jiný příběh.</flame>
Podle mě GAPI ještě dlouhou dobu zůstane jedinou funkční a podporovanou knihovnou pro grafiku. Ať už to bude oficiálně podporován nebo ne. Vždy se dá do zařízení přidat knihovna gx.dll optimalizovaná pro konkrétní hardware, díky které bude GAPI šlapat jak má i na nestandardních rozlišeních. Nevýhodou GAPI zůstává, že nedokáže využít grafickou akceleraci.

Nicméně na každém zařízení se rychlost DirectDraw, GAPI a RAWFRAMEBUFFER projevuje jinak. Zpravidla jde však o rozdíly v desítkách procent.

Zvuk

Tak podpora zvuku je u Windows CE snad ještě horší než podpora grafiky Jediné na co se Microsoft zmohl implementovat do svého operačního systému je přehrávání WAVE a to pouze bezkanálový zvuk. (Klasická funkce z Windows API - PlaySound() ) Žádné další nastavení. Prostě nic. Abych nelhal, CE samozřejmě vícekanálový zvuk podporují, ale API je velmi těžkopádné. Teprve až ve Windows Mobile 6 (rok 2007!) implementoval jednoduché API pro přehrání běžně podporovaných formátů pro které jsou dostupné kodeky (MP3, WMA a MID) a multikanálový zvuk. Kdyby si to odpustil asi by udělal líp, z důvodu zpětné kompatibility
. Vtipné také je, že Windows CE do verze 4.2 podporovali DirectSound (pouze pro přehrávání WAVE). Ve verzi 5.0 byl DirectSound ze systému odstraněn a ve verzi 6.0 přepsáno celé API pro práci se zvukem. Tomu říkám programátorská ZOO. Pro zvuk samozřejmě existují knihovny 3. stran. Samozřejmě komerční. Nejlepší z nich je pravděpodobně

FMOD 3 (100 USD)

Velmi precizní multiplatformní knihovna pro přehrávání zvuků a hudby navíc s podporou MP3, OGG/VORBIS, S3M, MOD a hromadu dalších blbostí jako nahrávání, streaming nebo ripping. Umí snadno přizpůsobit kvalitu zvuku, mono/stereo a další věci potřebné pro práci s mobilním zařízením. Pro nekomerční využití poskytována dokonce zdarma. Pro komerční využití od 100 USD což je v porovnání s ostatními knihovnami velmi slušná cena. FMOD 3 byla naprostá špička co se dá na nejen-kapesních Windows použít dokud se právě neobjevil Windows Mobile 6 s přepsaným API - ve kterém má FMOD problémy s některými formáty.  Oficiálně má FMOD podporovat pro přehrávání hudby

• MOD
• S3M
• XM
• IT
• MID
• RMI
• SGT
• FSB

a pro přehrávání zvuků

• WAV
• MP2
• MP3
• OGG
• RAW

Nicméně z hudebních formátů se mi podařilo na WM6.1 přehrát pouze XM a ze zvukových WAV a MP2.

MIDI

Zde je návod přímo z MSDN jak převést MIDI do WAVE a přehrát standardními funkcemi.

Pokud se tedy nespokojíte s trapným WAVE musíte napsat podporu pro zvuk zvlášť pro Pocket PC 2003 + Windows Mobile 5 a zvlášť pro Windows Mobile 6/6.1 - Na žádný wrapper, all1one řešení nebo jinou použitelnou knihovnu jsem zatím nenarazil. Pokud o něčem víte, tak se prosím podělte.

Ještě bych zmínil, že MP3 není vhodný formát z licenčních důvodů. Nevím jak u non-commercial produktů, ale pokud má hra nad 5000 kopií (což nevím jak se u online prodeje dá zjistit) musíte si zakoupit licenci za 2500 USD Osobně tak preferuji Ogg/vorbis. <flame>Je to ironie, že z formátu původně vytvořeným pro kradení hudby se stane licencovaný produkt. Někdy je mi z těch licencí opravdu na blití.</flame>

Herní Knihovny

Aby si programátor zjednodušil práci často sáhne po hotových odladěných knihovnách. Multiplatformní knihovny Vám dovolí s minimálním úsilím vytvořenou hru distribuovat na řadě různých mobilních platforem.

EDGELIB (950 USD)

Je asi nejkomplexnější knihovnou s podporou WM, Symbianu, GP2X a Gizmondo s podporou 3D, zvuku, sítí, utilit, zkrátka všeho co je potřeba. Pro nekomerční použití je zdarma (ale s logem na obrazovce)

GAPIDRAW (995 USD) (source code licence 3495 USD)

Toto je 2D grafická knihovna pro Pocket PC / Windows Mobile. Ovšem zato velmi vyspělá s vysokou mírou optimalizace podporující všechny možné grafické operace. Podpora jak pro GAPI tak i DirectDraw. Pro nekomerční použití je sice také zdarma, ovšem na displeji bude napsáno, že se jedná o evalution verzi.

SDL (LGPLv2)

SDL
je můj osobní favorit. Jedná se o multiplatformní herní knihovnu (soubor knihoven), původně určenou pro Linux ovšem podporuje celou škálu mobilních zařízení  jako Symbian, GameBoy Advanced i právě Windows CE, neoficiálně PalmOS a dokonce iPhone. (Kromě řady UNIXových odrůd jsou podporovány i exotické systémy jako AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS a OS/2) Asi nemusím říkat, že práce s grafikou pro Windows CE je právě řešena přes GAPI. (V budoucnu je možné nahradit video wrapper třeba DirectDraw nebo si třebanapsat vlastní) SDL je standartně napsaná v C, ale je dostupná snad v každém trochu známém programovacím jazyce. (Dokonce i PHP!) SDL byla napsána zkušenými herními programátory pro herní programátory. Autorem této knihovny je Sam Lantinga - Vedoucí softwarový inženýr v Blizzard Entertainment.  Je to sada více knihoven pro práci s 2D/3D grafikou/vstup/výstup/sítěmi/ulitami/hudbou. Existují další knihovny, které samotné SDL rozšířují, nejpoužívanější je SDL_image pro načítání různých formátů obrázků, SDL_ttf pro práci TrueType písmy,  SDL_net pro práci se sítí a SDL_Mixer pro přehrávání hudby a zvuků - bohužel bez podpory Windows CE.(Většina lidí sáhne po FMOD, ačkoliv si můžete napsat wrapper pro SDL_Mixer a udělat tak aplikaci úplně nezávislou na platformě) Nicméně je SDL knihovna prověřena několika lety usilovného vývoje. Existuje celá řada tutoriálů a open source her a knihoven (herních enginů) rozšiřující možnosti SDL. Současná verze SDL 1.2 je pod GPL licencí. Můžete jí použít pro komerční účely pokud přilinkujete knihovnu jako DLL. Nová SDL 1.3 beta je možno volně distribuovat pro komerční účely. Všechny potřebné DLL knihovny pro SDL zaberou v paměti něco mezi 500kB až 1MB. Pokud je aplikace dobře napsaná není problém jí portovat pro libovolnou platformu. Jediná věc, která vás v portování omezuje jsou různá rozlišení a hlavně konfigurace vašeho vývojového prosředí Všem zájemcům vřele doporučuji 
Seriál o programování v SDL na serveru root.cz

Proč Windows CE

Windows CE je i přes pár nedostatků velmi dobrou platformou co se týče vývoje aplikací. Narozdíl například od PalmOS nebo Symbianu. PalmOS je velmi časově náročný na psaní a ladění aplikací a Symbian má velký handicap při portování aplikace na různé verze systému mezi sebou jako EPOC, S60, S60v1, S60v2, S60v3, S70, S80, UIQ, různé feature packy z toho by se člověk zbláznil. Na rozebírání nevýhod J2ME a Linuxu tu už není místo, zkrátka Windows CE vítězí U Windows máte verzi pro Pocket PC (dotykový displej), Handheld PC = Pocket PC s větším displejem a pro Smartphone (bezdotykový). Windows CE má velmi dobrou zpětnou kompatibilitu. V podstatě není velký problém přenést aplikaci ze stařičkých Windows 3.11 pro Windows CE Dříve byl problém s architekturou procesorů (SH3, SH4, MIPS, ARM, XSCALE). Dnes se používá (od Windows CE 3.0) výhradně architektura StrongARM. (XSCALE je kompatiblní s ARM), takže už se architektura procesoru řešit naštěstí nemusí.

Windows CE a kompatibilita s ANSI/ISO C

Drtivá většina her s otevřeným zdrojovým kódem je napsaná v C. Proto je C ideální jazyk pro port těchto her. Nicméně Windows CE trpí menším nedostatkem, protože nepodporují všechny standardní funkce jazyka C. Například úplně chybí <signal.h> a <errno.h> a chybí implementace funkcí z <time.h>. Dále chybí náhodně různé funkce (rewind, asprintf, vasprintf, strcoll, tmpfile, getenv, setbuf) a pro Windows např. GetVersion()
Naštěstí chybějící podporu pro <time.h> lze vyřešit díky knihovně
OpenTimeCE a případně dopsat makra. Nicméně SDL nabízí vlastní funkce pro práci s časovačem nezávislé na platformě
K dispozici je jednoduchý návod na některé chybějící funkce jazyka C ve Windows CE - jiné funkce je možno ignorovat
Dále se určitě hodí implementace zlib pro Windows CE pro práci s archivem 

Poměrně závažným rozdílem Windows CE je absence relativních adresářů. Tzn. například kód fopen("score.txt", "r") vrátí NULL i pokud bude soubor ve stejném adresáři jako program. Ve Windows CE se vždy musíte odkazovat absolutní cestou. Já to řeším tak, že si z funkce GetModuleFileName() vyparsuji aktuální cestu a tu všude přidám před každý otvíraný soubor.

Co se týče síťové komunikace podporováno je samozřejmě i standardní API pro práci se sockety <winsock.h>. Pozor jenom na funkce close() v Linuxu a closesocket() ve Windows. Dobrou alternativou je opět SDL_net zapouzdřující práci se síti (netestováno)

Windows CE samozřejmě nepodporují příkazovou řádku, ale pokud program vypisuje na standardní výstup STDOUT např. funkcí printf(), tak se výstup automaticky uloží do souboru stdout.txt ve stejném adresáři. Alespoň u programů zkompilovaných ve Visual Studiu. Bohužel výstup na stderr se mi nepodařilo zachytit

Vývojová prostředí pro Windows CE a Windows Mobile

Za nejlepší vývojové prostředí považuji Microsoft Visual Studio 2005. Umožňuje programování v C++/C# a Visual Basicu. To je samozřejmě komerční a občas se trochu vyblbnete když musíte nastavovat různé záludnosti jako linker a compiler, buffer overflow chyby atp. Microsoft však zdarma uvolnil straší Embeded Visual C++ 4.0 pro vývoj Windows CE. Musíte si však stáhnout a nakonfigurovat několik balíků.
Pro Linux existuje projekt ce-xcompile, které umožní kompilovat programy v C/C++ v běžném gcc kompilátoru pro architekturu StrongARM. Vývojové prostředí si každý Linuxák určitě zvolí sám.

 

 

Článek může být průběžně aktualizován a rozšiřován

Veškeré vaše postřehy a komentáře uvítám tady v diskuzi nebo na adrese techi zavináč techi tečka name

Vložil Techi

Čas od času reaguji na nějaký post na serveru builder.cz - ano není to často, jenom když neodpoví nikdo přede mnou a jsem si jistý, že můj příspěvek bude přínosný. Ale někdy to prostě nedokážu. Ne proto, že bych neměl dostatek znalostí, ale protože stupidita tazatelů přesahuje veškeré meze.

Velmi kvalitní stránka s českým překladem o tom, jak se správně ptát, abyste dostali požadovanou odpověď naleznete na http://exploited.cz/otazky/

Pokračovat ve čtení "WTF? RTFM!"

Vložil Techi

Protože jsem nenašel vhodný freeware prográmek pro telefon, který by uměl pracovat s aktuálními kurzy, rozhodl jsem se ho napsat sám Pracuje s online kurzy Centrální Evropské Banky a umí spočítat kurz pro libovolnou částku a měnu. Program si kurzy stáhne buď sám a nebo je stáhnete ze svého počítače zde

Pro spuštění na Vašem telefonu je potřeba mít nainstalovaný .NET Compact Framework 2.0 (program lze spustit i ze stolního počítače)

Stáhnout zde [7kB]

Vložil Techi

Pro PHP existuje řada hotových tříd a je nesmyslné znovu objevovat ameriku a radši se podívat, jestli jí někdo neobjevil před Vámi. Proto existuje server phpclasses.org kde se soustředí užitečné i neužitečné třídy od programátorů z celého světa. Tudíž, pokud jste vytvořili užitečnou třídu, tak se s ním můžete také pochlubit. Sám jsem pár (použitelných) tříd také publikoval.

Nicméně mě zaskočilo, že moje třída Observerable (klon stejnojmenné třídy v Javě) byla nominována na cenu. Přitom třída není nijak zvláštní. Jenom implementuje návrhový vzor observer, protože v PHP 5.0 pro něj chyběla nadstavba. Nicméně i tak pro mě můžete hlasovat

Vložil Techi

V poslední době jsem zjistil, jaký je problém sehnat schopného PHP programátora do týmu. Asi je to tím, že spousta nováčků, kterým se povede spustit tutoriál „hello world“ se samozvaně prohlásí za programátora.


Ale co mě nejvíc doráží jsou životopisy programátorů a jiných takzvaných IT profesionálů. Ani mi tak nevadí hrubé gramatické chyby cizinců v životopisech jako umym webovi stranki nebo Kurz českeho jazika (Vysoki školi podnikany Czech republic,Ostrava). Ale že tito IT profesionálové vytvářejí dojem formátování svého životopisu pomocí mezerníků a jejich životopis vypadá, jako by se chtěli pochlubit, že vytvořili svůj první dokument ve Wordu v životě. (Samozřejmě je vždy uvedena perfektní znalost MS Office)


No trochu jsem se nechal unést...
No podívejme se na několik bodů, které by měl splňovat programátor webových aplikací (kromě elementárních znalostí programovacího, skriptovacího a databázového jazyka)

Pokračovat ve čtení "Co by měl znát (nejen) webový vývojář"

Vložil techi