First I want to emphasize, that it is important to user the most recent version of clients libraries, because google protocol is still develeped and some version are quite insufficient (especially that included in debian linux).
Google data protocol currently have three versions. I have only considered using version 2 and 3. I suppose that version one is quite obsolete. Version 3 is based on JSON, which is great because no parsing is needed, but that version provides no support how to chain commands together in batches. Also the client libraries does not include the last version support. Running commands in batches is quite important because there is quite big net roundtrip for each request. So without batches you are forced to implement sending asynchronious requests. I am not sure if one batch request counts as one in google limits, but their are quite comfortable. Because I have been in developping the synchronization through the protocol version 2 when the next version was introduced I stucked with the older version so I hope that some information will hold even for next version.
Major obstacle in protocol version 2 is that recurrent events are represented in diffferent format than normal events. Normal events are represented in atom xml, which is parsed by GData library. Recurrent events is represented in iCalendar format and you have to parse it yourself. Therefore you have to implement two parsers and writers and not only one.
Next obstacle is that recurrent events can have exceptions. In iCalendar that exceptions is represented by EXDATE, what is sillently ignored by google. The Google calendar web aplication fortunately understands but fails to mark. So it is left to you. When you remove one occurance of event from recurrence or update it, the new event is created which has link to recurrent event which modifies. The original event is not modified - its etag remains same so without founding the recurrence exception you do not even know that, the original event recurrence does not hold. I came even to situation where the original event does not existed, but the recurrence exceptions was still accesible. Its up to you how you we will represent such behaviour in your data model. Moreover I forget to mention that when you delete original recurrence all exceptions are deleted as well and same hold even for some modifications of original event.
Third obstacle is that the google sometimes lies to you, so you have to learn to ignore problems with denied authorization for authorization values which does not changed and starts to work in the next request. Also sometimes you are redirected elsewhere, but stubborningly replying requests helps :).
The last small obstacle is that you cannot undelete or modify deleted items on Google. I am solving it by creating new ones instead of deleted ones.
So you can say, google also provides CalDAV access, why not go with it? Yeah good try, but you will also meet all previous mentioned obstacles. Not to mention that authorization will fail to work not for one request but for days and after some time it will start works without any change. And of course forget authorization with OAuth, you will have to send plain text password. A big "no way" for any server. At least the google will inform a user that your server tryies to access his account with his credentials. So prepare plausible explanation that you have not let his password to be stolen.
Should I write more about google calendar?
úterý 10. ledna 2012
sobota 7. ledna 2012
Limit výtahů na výšku mrakodrapů
Do vynálezu výtahu nebylo praktické stavět obytné budovy nad určitou výšku - někomu se nechtělo cestovat po schodech. Zajímavé je, že i výtah klade omezení na smysluplnou výšku obytné budovy. Čim výšší budova, tím větší část její plochy je věnované výtahovým šachtám. Od určitého patra výtahy zajištující dopravu do tohoto patra zabírají v budově větší plochu, než celá plocha patra a nemá tedy smysl snažit se další patro přidávat.
Plocha kterou sptřebují výtahy pro dané patro je dána počtem pater přes které se musí cestovat, což je většinou od paty budovy, a množstvím výtahů nutným pro dopravu lidí do tohoto patra ve špičce. Je zřejmé, že čím jde o vyšší patro, tak výtahu trvá déle překonat danou vzdálenost a pro dopravu stejného množství lidí za jednotku času je potřeba více výtahů (nebo jejich větší plocha).
Celkově lze tedy říci, že plocha zabraná výtahy pro patro P je kvadraticky závislá na P. Zajímavé je, že tohoto ekonomického limitu už dnešní budovy dosahují. A snaží se mu vyhnout rychlejšími výtahy, více výtahy v jedné šachtě a více patrovými výtahy. Přesto všechna tato zlepšení zvyšují kapacitu výtahů násobně a tedy pomáhají jen zvýšit limit o odmocninu koeficientu zlepšení účinosti výtahů. Tedy dva dvoupatrové výtahy v každé šachtě zvýší možný počet pater v budově maximálně dvounásobně. Zároveň je potřeba počítat i s dalšími limity. Jako je rychlost změny tlaku, během cestování výtahem, rychlost s jakou se lze dostat na vrchol budovy (a zároveň jak rychle lze budovu opustit) a dalšími produktovody v budově - jako je např. rozvod pitné vody a sběr odpadních vod.
Zajímavá čísla
Plocha kterou sptřebují výtahy pro dané patro je dána počtem pater přes které se musí cestovat, což je většinou od paty budovy, a množstvím výtahů nutným pro dopravu lidí do tohoto patra ve špičce. Je zřejmé, že čím jde o vyšší patro, tak výtahu trvá déle překonat danou vzdálenost a pro dopravu stejného množství lidí za jednotku času je potřeba více výtahů (nebo jejich větší plocha).
Celkově lze tedy říci, že plocha zabraná výtahy pro patro P je kvadraticky závislá na P. Zajímavé je, že tohoto ekonomického limitu už dnešní budovy dosahují. A snaží se mu vyhnout rychlejšími výtahy, více výtahy v jedné šachtě a více patrovými výtahy. Přesto všechna tato zlepšení zvyšují kapacitu výtahů násobně a tedy pomáhají jen zvýšit limit o odmocninu koeficientu zlepšení účinosti výtahů. Tedy dva dvoupatrové výtahy v každé šachtě zvýší možný počet pater v budově maximálně dvounásobně. Zároveň je potřeba počítat i s dalšími limity. Jako je rychlost změny tlaku, během cestování výtahem, rychlost s jakou se lze dostat na vrchol budovy (a zároveň jak rychle lze budovu opustit) a dalšími produktovody v budově - jako je např. rozvod pitné vody a sběr odpadních vod.
Zajímavá čísla
- cca 0.25m2 velikost podlahové plochy výtahu na osobu
- 0.057 počet osob na m2 patra kancelářské budovy (World Trade Center - Twins towers 25k osob na věž, 110 pater, 4020m2 podlahové plochy dle wikipedie).
- 60km/h rychlost výtahu v Petronas Towers v Malajsii.
pátek 15. dubna 2011
Výměna ložisek v bruslích Rollerblade
Včera jsem si v bruslích vyměnil ložiska. Při jízdě brusle už vydávali nemožné zvuky, tak jsem nakoupil ložiska s tím, že to pomůže. Ložiska SG7 nejsou všechna stejná - ta nová lze alespoň rozebrat a vyčistit (na rozdíl od těch co jsem koupil s bruslemi). Pro výměnu ložisek doporučuji zároveň koupit i nové šrouby. Po roce ježdění a pravidelném otáčení koleček se některé šrouby roztáhli a nešly rozumně vytáhnout, nebyl rozumný nápad je vyklepávat kladivem a znovu používat. Nakonec dva šrouby nešli vyrazit ani vyrážecím klíčem (doporučuji originální klíč na brusle od Rollerblade - je sice drahý, ale pěkně padne do ruky a dobře se s ním pracuje), ale musel jsem použít lis a svěrák. Takže jakmile šroub nejde hladce vyndat, tak ho ihned vyměnit.
Samozřejmě jsem po výměně zjistil, že určité skřípání způsobují i kolečka, tak uvidím jak se projeví až je dojedu a vyměním.
Samozřejmě jsem po výměně zjistil, že určité skřípání způsobují i kolečka, tak uvidím jak se projeví až je dojedu a vyměním.
středa 2. února 2011
Global game jam
Minulý víkend jsem ze zůčastnil malé zajímavé akce. Soutěže možná spíše hecu global game jam resp jeho místní buňky. Abych to vysvětlit, cílem soutěže bylo přemoci své limity a vytvořit počítačovou hru v krátkém limitu 48 hodin. Je zřejmé, že za tuto dobu mohou vzniknout jen jednoduché hry. O to víc mě překvapila kvalita her, jež byli nakonec v klání ukovány.
Ale abych nepředbíhal. Soutěž začla v pátek a tak jsem trochu unavený po celodenní práci vyrazil na křemíkový kopec vyzkoušet své schopnosti. Nejel jsem tam sám, ale s kamarádem, který se uvolil mi dělat grafiku a bral to též jako zajímavou zkušenost (sám je ostatně velký fanda do všech her).
V zasedací místnosti jsme si vyslechli organizační věci, téma a zkoukli motivační video se zívajícím japoncem (u kterého jsem měl správný pocit, že ho plně pochopím na konci soutěže). A pak začli vymýšlet...
Neřekli byste jak je těžké vymyslet originální a zábavnou hru (resp. něco o čem byste uvažovali jako o zábavném). V té chvíli si člověk plně uvědomí o čem je pozice herního návrháře, a že tento člověk není jen snílek, který neumí programovat ani kreslit a tak se rozhodl ostatní kybicovat. Po několika hodinách přemýšlení nám už jakýkoliv realizovatelný nápad přišel skvělý a začali jsme pracovat. Pak přišla noc, kterou jsme se rozhodli strávit na místě. Pár hodin spánku v umělém světle záářivek není odpočinek. Přesto jsme se ráno vzbudili s hrůzou co za tisíckrát ohranou trivialitu se to snažíme udělat.
A tak nastalo další přemýšlení, uvažování přemýlání. Kolem 10. dopolední jsme téma trochu modifikovali a řekli si že to zkusíme a začli opravdu pracovat. Druhou noc jsem strávil doma a celkem odpočatý hru v neděli v kvapném spěchu dokončil. Bohužel né vše se nám do hry vlezlo a něco jsme museli opustit. Celkově jsem však s naší hrou spokojený a na to že vznikla za 2 dni můžeme být právem hrdí,
Na konci jsme byli velmi příjemně překvapení, že úroveň her byla srovnatelná a že jsme nezapadli. Do budoucna se plánujeme soutěže účastnit znovu, protože mimo únavy, bolavých zad ze židle a unavených očich od monitoru nás hřeje pocit, že jsme udělali něco pěkného.
Na závěr bych chtěl ještě zapsat co jsme si ze soutěže odnesli pro příště.
Nápad je to nejdůležitější a příště budeme více odvážní. Hra je cenná kvůli nápadu protože ničim jiným nejspíš zaujmout nemůže a hratelnost je bonus, pokud se vše vydaří. Nebylo dobré se začátku omezovat představami o tom co je hratelné a co ne.
Dostatek kvalitního spánku je rozdíl mezi zombie vývojářem trčícím nad rozdělanou hrou a produktivním člověkem. Za neděli jsem naprogramoval podstatnou část hry a to za daleko kratší čas, jelikož jsem byl odpočat.
Znalost platformy je důležitá, v časovém kvapu se některé věci prostě nedají řešit - nás například nepříjemně překvapilo, že jsme neuměli přehrát muziku, kterou jsme ke hře vytvořili a, že se postavení windows distribuce hry zaseklo na několika problémech s knihovnou SDL_mixer. Exe soubor s hrou jsme vytvořili až po soutěži.
Distribuce hry je u malých her rozhodujícím prvkem toho, zda si hru někdo vyzkouší. Pokud se hra musí stahovat, rozbalovat nebo do konce instalovat je to problém. Tato nevýhoda při velkých hrách mizí. Příště by to chtělo pracovat buď ve flashi nebo javascriptu.
Zvuk je 50% hry, bez zvuku je hra plochá a hráč se do ní tolik nevcítí. Je chybou šidit hru v tomto směru. (spíš člověk odpustí jednodušší grafiku)
Rozdělení práce na hře není rovnoměrné. Je velmi těžké rozdělit si práci rovnoměrně mezi různé profese. Zatímco já jako programátor jsem se cítil pod tlakem deseti atmosfér kolega grafik/zvukař pracoval v klidu a pohodě. Zároveň je náročné koordinovat vlastnosti hry, potřebná doprovodná data a program. Zde je velká výhoda předchozích zkušeností.
Poslední radou je: nebuďte na sebe moc tvrdí, cílem je něco vytvořit něco se naučit, trochu se pobavit a ne změnit svět. To tvorbou hry za 2 dni opravdu nejde.
Ale abych nepředbíhal. Soutěž začla v pátek a tak jsem trochu unavený po celodenní práci vyrazil na křemíkový kopec vyzkoušet své schopnosti. Nejel jsem tam sám, ale s kamarádem, který se uvolil mi dělat grafiku a bral to též jako zajímavou zkušenost (sám je ostatně velký fanda do všech her).
V zasedací místnosti jsme si vyslechli organizační věci, téma a zkoukli motivační video se zívajícím japoncem (u kterého jsem měl správný pocit, že ho plně pochopím na konci soutěže). A pak začli vymýšlet...
Neřekli byste jak je těžké vymyslet originální a zábavnou hru (resp. něco o čem byste uvažovali jako o zábavném). V té chvíli si člověk plně uvědomí o čem je pozice herního návrháře, a že tento člověk není jen snílek, který neumí programovat ani kreslit a tak se rozhodl ostatní kybicovat. Po několika hodinách přemýšlení nám už jakýkoliv realizovatelný nápad přišel skvělý a začali jsme pracovat. Pak přišla noc, kterou jsme se rozhodli strávit na místě. Pár hodin spánku v umělém světle záářivek není odpočinek. Přesto jsme se ráno vzbudili s hrůzou co za tisíckrát ohranou trivialitu se to snažíme udělat.
A tak nastalo další přemýšlení, uvažování přemýlání. Kolem 10. dopolední jsme téma trochu modifikovali a řekli si že to zkusíme a začli opravdu pracovat. Druhou noc jsem strávil doma a celkem odpočatý hru v neděli v kvapném spěchu dokončil. Bohužel né vše se nám do hry vlezlo a něco jsme museli opustit. Celkově jsem však s naší hrou spokojený a na to že vznikla za 2 dni můžeme být právem hrdí,
Na konci jsme byli velmi příjemně překvapení, že úroveň her byla srovnatelná a že jsme nezapadli. Do budoucna se plánujeme soutěže účastnit znovu, protože mimo únavy, bolavých zad ze židle a unavených očich od monitoru nás hřeje pocit, že jsme udělali něco pěkného.
Na závěr bych chtěl ještě zapsat co jsme si ze soutěže odnesli pro příště.
Nápad je to nejdůležitější a příště budeme více odvážní. Hra je cenná kvůli nápadu protože ničim jiným nejspíš zaujmout nemůže a hratelnost je bonus, pokud se vše vydaří. Nebylo dobré se začátku omezovat představami o tom co je hratelné a co ne.
Dostatek kvalitního spánku je rozdíl mezi zombie vývojářem trčícím nad rozdělanou hrou a produktivním člověkem. Za neděli jsem naprogramoval podstatnou část hry a to za daleko kratší čas, jelikož jsem byl odpočat.
Znalost platformy je důležitá, v časovém kvapu se některé věci prostě nedají řešit - nás například nepříjemně překvapilo, že jsme neuměli přehrát muziku, kterou jsme ke hře vytvořili a, že se postavení windows distribuce hry zaseklo na několika problémech s knihovnou SDL_mixer. Exe soubor s hrou jsme vytvořili až po soutěži.
Distribuce hry je u malých her rozhodujícím prvkem toho, zda si hru někdo vyzkouší. Pokud se hra musí stahovat, rozbalovat nebo do konce instalovat je to problém. Tato nevýhoda při velkých hrách mizí. Příště by to chtělo pracovat buď ve flashi nebo javascriptu.
Zvuk je 50% hry, bez zvuku je hra plochá a hráč se do ní tolik nevcítí. Je chybou šidit hru v tomto směru. (spíš člověk odpustí jednodušší grafiku)
Rozdělení práce na hře není rovnoměrné. Je velmi těžké rozdělit si práci rovnoměrně mezi různé profese. Zatímco já jako programátor jsem se cítil pod tlakem deseti atmosfér kolega grafik/zvukař pracoval v klidu a pohodě. Zároveň je náročné koordinovat vlastnosti hry, potřebná doprovodná data a program. Zde je velká výhoda předchozích zkušeností.
Poslední radou je: nebuďte na sebe moc tvrdí, cílem je něco vytvořit něco se naučit, trochu se pobavit a ne změnit svět. To tvorbou hry za 2 dni opravdu nejde.
neděle 16. ledna 2011
Sorting with registers
Previous post was about sorting with no advanced functionality, which robot Emil also provides. I tried to rewrite it using memory registers and functionality for checking the height of stack of bricks in front of the robot. The result is terse and almost look like any procedural programming language. Take also a note to function CheckLength which returns value in special register called Counter (only register which can be used for function return value).
Bubble sort in Robot Emil which uses memory registers
Bubble sort in Robot Emil which uses memory registers
sobota 15. ledna 2011
Hey robot, sort this!
How to sort in Robot karel? Sorting algorithms are necessary part of any beginner programming lessons. Robot karel is educational programming language in which you control an robot, which can turn left, right, do steps, place bricks from nowhere and pick them up. The robot can also check if there is a wall or brick in front of him. Program structure contains repeating, checking for condition and repeating while some condition is met. So robot is only something like the Turing machine with two dimensional finite tape. The inner state of robot is only represented by instruction position in robot program. I have used extended version robot Emil which is able to stack brick on the floor, so it is possible to more easily organize memory.
In standard programming language bubble sort is quite easy algorithm e.g. in python it can be expressed like.
a = [3, 7, 6, 5, 1, 2, 0]
N = len(a)
while True:
is_sorted = False
for x in range(N-1):
if a[x] > a[x+1]:
a[x], a[x+1] = a[x+1], a[x]
is_sorted = True
if not is_sorted:
break
print(a)
Robot Karel is nothing like standard programming languages even x86 assembler is more advanced (processor has registers and a lot more instructions). So how to sort in it?
What are basic operations?
Comparing numbers, Swapping them..
The environment has two biggest disadvantages:
All memory is global and you have to make sure that some util will not overwrite something.
All addressing is relative, it is possible to store where have you been (usually by placing brick on some possition and going to a corner of a room, but it takes time).
Biggest strugles
Swithing columns is quite easy. Comparing columns is not. Because robot can see only if is a brick in front of him or not, but not their count. Comparing columns of bricks has to be done by removing brick from them so it is destructive. So we have subtask of cloning columns. Also all conditions in the program are atomic, therefore robot has to go to the right place to test it and even if the condition will fullfill the robot has to return back. So there is lot of moving. Program contains procedures, but there are no parameters and return values, so everything has to be stored on the room floor.
Cloning columns
Checking the height of column is also destructive operation, therefore robot has to enlarge two columns for each removed brick and one column move back to the original position.
Column comparsion
Robot removes bricks from each column until one column is empty according which it will clean used space and put or not put the brick on the floor. Then it only checks if the brick is on the floor and if so, it will swap columns.
Testing of ending condition
If the whole sequence was gone trough and no columns were swapped the algorihtm should end. Therefore if there was some column swapping robot will pull the brick on the floor and after each checking it will check if there is some brick from the previous step and moves it to the next position. When the robot reach the end of sequence it can decide according the brick by him if in the whole cycle was some swaping or not.
Memory representation
The sequence is in the first row the sequence is long as the floor minus one. One column at the end of room has to be free, because the robot cannot travel trough columns heigher then two so it has to goes arround them (and thanks to memory our representation has to have place trough which can go around for the last item in the cycle). Second row is used for robot movement and placing the bit brick, for checking if some swapping was done. Third row is sometimes used for storing result of comparsion and othertimes with other columns for other operations like for swapping and comparing columns. The robot uses columns in these rows relative to his own position.
The program source code
úterý 2. února 2010
Pragmatické programování
Před chvílí jsem smazal zas několik desítek řádků propracovaného kódu, kterým mě dal celkem práci napsat. Protože to není poprvé, a nejspíše ani naposled. Tak bych rád zformuloval své předsevzetí.
Pokud při programování narazím na problém,výzvu nebo úkol (nazvěte dle svého naturelu), tak prvním krokem by nemělo být přemýšlení jak ho vyřešit, ale přemýšlení zda je ho třeba řešit. Tím neříkám, že je dobré každý bug přejmenovat na feature. Ale zavazuji se promyslet zadání a zjistit, zda je řešení daného problému to co se po mě chce, zda by se problému nešlo vyhnout mírným přeformulováním zadání nebo vstupů.
Upravením vstupů lze program udělat mocnější, přehlednější pro uživatele a ušetřit si práci s psaním kódu a laděním chyb.
Pro ty co namítají, že už kecám podložím svá tvrzení dvěma příklady.
1) dal jsem si dost práce, abych vytvořil záložkové menu (oslí ucha nad stránkou) s libovolnou šířkou záložek, vytvořené pomocí CSS. Poté co jsem menu odladil, aby chodilo i v IE6 jsem zjistil, že stejná šířka záložek vypadá vizuálně mnohem lépe a je daleko jednodušší na vytvoření. V podstatě stačilo jen trochu upravit názvy záložek. Celé propracované menu šlo za měsíc při dalším redisignu pryč.
2) ve svém programu pro skládání obrázků do jednoho společného obrázku (sprite sheetu) jsem se rozhodl implementovat funkcionalitu, která zajistí, aby se stejný obrázek nevložil do společného obrázku znovu, ale namísto toho se použil už vložený obrázek.
Tato funkcionalita fungovala jen za omezených podmínek (nefungovala, pokud byly obrázky generovány rovnou do paměti).
Nyní jsem umožnil k danému obrázku nastavit kolekci vlastností, místo toho, aby se zadalo víc obrázků s podobnými vlastnostmi a teprve program hledal, které obrázky lze sjednotit do jednoho. Pro uživatele je to přehlednější (žádné skryté chování, neduplikují se vlastnosti) a kód se o dost zmenšil.
Pokud při programování narazím na problém,výzvu nebo úkol (nazvěte dle svého naturelu), tak prvním krokem by nemělo být přemýšlení jak ho vyřešit, ale přemýšlení zda je ho třeba řešit. Tím neříkám, že je dobré každý bug přejmenovat na feature. Ale zavazuji se promyslet zadání a zjistit, zda je řešení daného problému to co se po mě chce, zda by se problému nešlo vyhnout mírným přeformulováním zadání nebo vstupů.
Upravením vstupů lze program udělat mocnější, přehlednější pro uživatele a ušetřit si práci s psaním kódu a laděním chyb.
Pro ty co namítají, že už kecám podložím svá tvrzení dvěma příklady.
1) dal jsem si dost práce, abych vytvořil záložkové menu (oslí ucha nad stránkou) s libovolnou šířkou záložek, vytvořené pomocí CSS. Poté co jsem menu odladil, aby chodilo i v IE6 jsem zjistil, že stejná šířka záložek vypadá vizuálně mnohem lépe a je daleko jednodušší na vytvoření. V podstatě stačilo jen trochu upravit názvy záložek. Celé propracované menu šlo za měsíc při dalším redisignu pryč.
2) ve svém programu pro skládání obrázků do jednoho společného obrázku (sprite sheetu) jsem se rozhodl implementovat funkcionalitu, která zajistí, aby se stejný obrázek nevložil do společného obrázku znovu, ale namísto toho se použil už vložený obrázek.
Tato funkcionalita fungovala jen za omezených podmínek (nefungovala, pokud byly obrázky generovány rovnou do paměti).
Nyní jsem umožnil k danému obrázku nastavit kolekci vlastností, místo toho, aby se zadalo víc obrázků s podobnými vlastnostmi a teprve program hledal, které obrázky lze sjednotit do jednoho. Pro uživatele je to přehlednější (žádné skryté chování, neduplikují se vlastnosti) a kód se o dost zmenšil.
Přihlásit se k odběru:
Příspěvky (Atom)
