Re: [python] Roboti, REST, Flask?

[Petr Messner]

Zajímavý kus kódu. Co se stane, když se server restartuje, zůstane stav
zámků zachován? Co se stane, když klient požádá o acquire a musí čekat,
protože zámek má již někdo jiný, ale zrovna v tu chvíli vypadne síť,
spojení se ukončí a recv() vrátí prázdný řetězec?

Když už řešit zamykání takhle síťově, tak aspoň pořádně :) Viz např. Redis (
http://antirez.com/news/77) Apache Zookeeper, Apache Helix...

Bohužel, distribuované algoritmy nejsou tak jednoduché, že by do
"normálního" algoritmu stačilo přidat sokety.

PM

Dne 29. září 2015 15:30 Pavel Schön  napsal(a):

> Ahoj,
>
> dovolim si navrhnout pure python reseni na strane serveru zalozene na
> threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:
>
>
> http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/
>
> Ve zkratce:
>
> - na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje klienty.
> - na klienty umistis tentyz soubor dlm.py, ktery si klientska aplikace
> importne a vola podle potreby.
>
> Aplikace potom funguje velmi podobne, jako bys programoval s mutexy.
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
>
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Pavel Schön]

Ahoj,

dovolim si navrhnout pure python reseni na strane serveru zalozene na 
threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:

http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/

Ve zkratce:

- na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje klienty.
- na klienty umistis tentyz soubor dlm.py, ktery si klientska aplikace importne 
a vola podle potreby.

Aplikace potom funguje velmi podobne, jako bys programoval s mutexy.
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Honza Král]

Psal jsem to tehdy, pisu to i ted - tohle reseni je naprosto nevhodne,
nema zadne reseni konkurentniho pristupu. Neni thread safe napriklad,
coz ho naprosto diskvalifikuje jako implementace zamku. Nehlede na to,
ze je to reimplementace kola.
Honza Král
E-Mail: honza.k...@gmail.com
Phone:  +420 606 678585


2015-09-29 15:30 GMT+02:00 Pavel Schön :
> Ahoj,
>
> dovolim si navrhnout pure python reseni na strane serveru zalozene na 
> threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:
>
> http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/
>
> Ve zkratce:
>
> - na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje klienty.
> - na klienty umistis tentyz soubor dlm.py, ktery si klientska aplikace 
> importne a vola podle potreby.
>
> Aplikace potom funguje velmi podobne, jako bys programoval s mutexy.
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Pavel Schön]

Moje knihovna nikdy nebyla nasazena v produkci, je to ciste experimentalni 
zalezitost, hricka pro studijni ucely. Autor puvodniho dotazu hleda neco pro 
studijni a vyukove ucely, pokud se nepletu.

Server si v zadnem pripade nepamatuje stav zamku pri restartu, klientska cast 
neresi vypadky spojeni, neimplementuje reconnect apod. Pokud nastane chyba v 
TCP, na strane klienta se vyhodi vyjimka socket.error a je jen na nem, jak se 
zachova. 

Knihovna take neresi deadlock, ale to ani normalni threading neresi deadlocky. 
Jejich predchazeni je uz mimo ramec teto diskuze.

BTW, nad jednoduchym lockem lze stavet vyssi primitiva, semafory apod.


Dne úterý 29. září 2015 15:51:15 UTC+2 Petr Messner napsal(a):
> Zajímavý kus kódu. Co se stane, když se server restartuje, zůstane stav zámků 
> zachován? Co se stane, když klient požádá o acquire a musí čekat, protože 
> zámek má již někdo jiný, ale zrovna v tu chvíli vypadne síť, spojení se 
> ukončí a recv() vrátí prázdný řetězec?
> 
> 
> Když už řešit zamykání takhle síťově, tak aspoň pořádně :) Viz např. Redis 
> (http://antirez.com/news/77) Apache Zookeeper, Apache Helix...
> 
> 
> Bohužel, distribuované algoritmy nejsou tak jednoduché, že by do "normálního" 
> algoritmu stačilo přidat sokety.
> 
> 
> PM
> 
> 
> Dne 29. září 2015 15:30 Pavel Schön  napsal(a):
> Ahoj,
> 
> 
> 
> dovolim si navrhnout pure python reseni na strane serveru zalozene na 
> threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:
> 
> 
> 
> http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/
> 
> 
> 
> Ve zkratce:
> 
> 
> 
> - na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje klienty.
> 
> - na klienty umistis tentyz soubor dlm.py, ktery si klientska aplikace 
> importne a vola podle potreby.
> 
> 
> 
> Aplikace potom funguje velmi podobne, jako bys programoval s mutexy.
> 
> 
> 
> ___
> 
> Python mailing list
> 
> pyt...@py.cz
> 
> http://www.py.cz/mailman/listinfo/python
> 
> 
> 
> Visit: http://www.py.cz

___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Honza Král]

2015-09-29 16:28 GMT+02:00 Pavel Schön :
> Moje knihovna nikdy nebyla nasazena v produkci, je to ciste experimentalni 
> zalezitost, hricka pro studijni ucely. Autor puvodniho dotazu hleda neco pro 
> studijni a vyukove ucely, pokud se nepletu.

Obzvlast pro vyukove ucely je skutecne vhodne vybrat dobra reseni, v
tomto pripade tedy neco ze std knihovny nebo neco co funguje a plni
sliby

Nejhorsi co se muze stat je, ze se nekdo nauci spatne postupy a
principy, proto je vzdy dulezite, obcas i za cenu komplexity (django
vs flask) nebo extra zavislosti (gunicorn nebo twisted na normalni
server vs custom tcp socket), zvolit reseni ktere podporuje dobre
navyky. V tomhle pripade je dobry navyk i nevynalezat kolo.

> Server si v zadnem pripade nepamatuje stav zamku pri restartu, klientska cast 
> neresi vypadky spojeni, neimplementuje reconnect apod. Pokud nastane chyba v 
> TCP, na strane klienta se vyhodi vyjimka socket.error a je jen na nem, jak se 
> zachova.
>
> Knihovna take neresi deadlock, ale to ani normalni threading neresi 
> deadlocky. Jejich predchazeni je uz mimo ramec teto diskuze.
>
> BTW, nad jednoduchym lockem lze stavet vyssi primitiva, semafory apod.
>
>
> Dne úterý 29. září 2015 15:51:15 UTC+2 Petr Messner napsal(a):
>> Zajímavý kus kódu. Co se stane, když se server restartuje, zůstane stav 
>> zámků zachován? Co se stane, když klient požádá o acquire a musí čekat, 
>> protože zámek má již někdo jiný, ale zrovna v tu chvíli vypadne síť, spojení 
>> se ukončí a recv() vrátí prázdný řetězec?
>>
>>
>> Když už řešit zamykání takhle síťově, tak aspoň pořádně :) Viz např. Redis 
>> (http://antirez.com/news/77) Apache Zookeeper, Apache Helix...
>>
>>
>> Bohužel, distribuované algoritmy nejsou tak jednoduché, že by do 
>> "normálního" algoritmu stačilo přidat sokety.
>>
>>
>> PM
>>
>>
>> Dne 29. září 2015 15:30 Pavel Schön  napsal(a):
>> Ahoj,
>>
>>
>>
>> dovolim si navrhnout pure python reseni na strane serveru zalozene na 
>> threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:
>>
>>
>>
>> http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/
>>
>>
>>
>> Ve zkratce:
>>
>>
>>
>> - na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje klienty.
>>
>> - na klienty umistis tentyz soubor dlm.py, ktery si klientska aplikace 
>> importne a vola podle potreby.
>>
>>
>>
>> Aplikace potom funguje velmi podobne, jako bys programoval s mutexy.
>>
>>
>>
>> ___
>>
>> Python mailing list
>>
>> pyt...@py.cz
>>
>> http://www.py.cz/mailman/listinfo/python
>>
>>
>>
>> Visit: http://www.py.cz
>
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Pavel Schön]

V tom se asi neshodneme. Nespatřuji nic špatného na tom napsat si vlastní TCP 
protokol založený na socketu z stdlib.

Zastávám názor, že je dobré rozumět a učit se věci pěkně odspodu. Ono i to 
Django nebo Flask takto vznikl. Na začátku nebylo nic a potom byl framework.

Uvedu vlastní zkušenost. Ve svém stávajícím zaměstnání jsem čekal několik 
měsíců na memcached (z legal důvodů). Bylo rychlejší napsat si vlastní 
memcached-like service (dva dny práce) a až mi byl memcached dodán, bylo snadné 
je prohodit.

Nechme na tazateli, jestli si vybere all-in-one řešení na jednoduchou věc, nebo 
si vytvoří vlastní "from scratch" a přitom se třeba i něco naučí. Ani jedna 
cesta není špatná.


> Obzvlast pro vyukove ucely je skutecne vhodne vybrat dobra reseni, v
> tomto pripade tedy neco ze std knihovny nebo neco co funguje a plni
> sliby
> 
> Nejhorsi co se muze stat je, ze se nekdo nauci spatne postupy a
> principy, proto je vzdy dulezite, obcas i za cenu komplexity (django
> vs flask) nebo extra zavislosti (gunicorn nebo twisted na normalni
> server vs custom tcp socket), zvolit reseni ktere podporuje dobre
> navyky. V tomhle pripade je dobry navyk i nevynalezat kolo.
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Jan Bednařík]

2015-09-11 10:29 GMT+02:00 Marek Nožka :

> Ahoj
>
> Potřeboval bych malou radu. Učím programování(Python) na SŠ. Takže jsem
> vymyslel(okoukal), že si budeme hrát na Roboty. Bude to tahová hra.
> Jednotliví roboti(studenti) se připojí k serveru a budou mezi sebou
> soutěžit
> o nejlepší algoritmus, který projde bludištěm podle zadaných pravidel.
>
> Na serverovou část jsem chtěl použít Flask a vytvořit jednoduché REST API.
> Řeším ale jak mám obsloužit více klientů tak, aby na sebe navzájem počkali.
> Každý klient by měl říct, kam táhne. Ale odpověď můžu poslat až potom, co
> všichni pošlou požadavek. Napadli mě dvě řešení.
>
> 1) Klient pošle požadavek a čeká na odpověď. Stream odpovědi se ale zastaví
>a čeká se až se ozvou další klienti. Tohle nevím jak bych ve Flasku
>udělal -- pokud to tedy vůbec jde. Pokoušel jsem se to vygooglit ale na
>nic kloudného jsem nepřišel.
>


Ahoj. Tohle se ti ve Flasku, Djangu, aj. synchronních frameworcích bude
dělat špatně. Použiješ-li asynchronní aiohttp, můžeš efektivně obsluhovat
všechny requesty z Robotů "paralalně" (můžou paralelně čekat s odpovědí).
Složitost implementace s aiohttp je zhruba stejná jako ve Flasku.

http://aiohttp.readthedocs.org/en/stable/



Nicméně na tento problém se REST, respektive HTTP, zrovna moc nehodí (leda
ty websockety). Vhodnější by bylo použít Pub/Sub. Měly by stačit dva topicy
(channely), něco jako:

1. Round
 - hra na něj dělá publish povelu, že je možné táhnout další kolo
 - všichni roboti sem dělají subscribe a reagují na povel

2. Move
 - hra se sem dělá subscribe a reaguje na tahy robotů
 - roboti sem dělají publish tahů

Pro jednoduchost rozchození můžeš použít jako Pub/Sub broker třeba Redis.
Má dobrou knihovnu jak pro asynchronní Pyhon aioredis, stejně tak pro
klasický synchronní přístup redis-py.

https://github.com/aio-libs/aioredis
https://github.com/andymccurdy/redis-py

Honza



2) Klient pošle požadavek a za nějakou chvilku se zeptá jestli má
>server už odpověď. To je zase více složitosti na straně klienta.
>
> Protože jsem nic podobného zatím nikdy nedělal, budu vděčný za každou
> připomínku, poznámku nebo radu. Co za knihovnu/framework byste mi
> doporučovali.
>
> Dky
>Marek
>
> --
>  @ @ @ Marek Nožka
>  '.@
>  :*`@   email: marek <@t> tlapicka  net
>  `*'   jabber: tlapicka <@t> mitranet  cz
>   ::  web: http://tlapicka.net/
>   `'
>   `'   Powered by Debian GNU/Linux
>   `.**'
> ¨¨
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
>
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Marek Nožka]

Moc, moc dík, za vyčerpávající odpověď.

Marek
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Marek Nožka]

On Wed, 16 Sep 2015 09:37:41 +0200 Petr Viktorin  wrote
to Konference PyCZ :

> ale neměl bys zapomenout na to, že *učíš*
> lidi používat HTTP. Nauč je to prosím správně.

... právě proto se ptám. Díky všem za poučení, budu se tím řídit.

Marek
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Petr Viktorin]

2015-09-16 7:45 GMT+02:00 Petr Blahos :
> Ještě poznámečka: Pokud bude GET měnit vnitřní stav aplikace, a povede k
> němu
> nějaký link, tak ho Google klidně navštíví při indexování :-) Nebo jak měl
> kdysi takové
> to přednačítání odkazů...

Je psáno [1], že GET nemá měnit stav, a spousta nástrojů to předpokládá.
Kromě robotů to předpokládají třeba různé keše nebo load balancery. Ty
sice teď asi nepoužíváš, ale neměl bys zapomenout na to, že *učíš*
lidi používat HTTP. Nauč je to prosím správně.

[1] ve specifikaci HTTP: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
> the GET and HEAD methods SHOULD NOT have the significance of taking an action 
> other than retrieval. These methods ought to be considered "safe".

> 2015-09-15 22:33 GMT+02:00 Ales Zoulek :
>>
>> Technicky rozdil mezi PUT a GET je minimalni. Je ale konvence, aby akce
>> odpovidala tomu HTTP "slovesu".
>>
>> Uplnym minimem je rozliseni mezi GET a POST. Tzn. GET (narozdil od POST)
>> by nemel menit vnitrni stav serveru, pouze ten stav cist.
>>
>> HTTP REST uz je striktnejsi a popisuje presnejsi pouziti i DELETE, PUT,
>> PATCH, etc.
>>
>> Pokud nemas vylozene duvod to nedodrzovat, tak je lepsi se te konvence
>> drzet.
>>
>>
>> A.
>>
>> On Tue, Sep 15, 2015 at 9:54 PM Marek Nožka  wrote:
>>>
>>> Ahoj
>>>
>>> On Tue, 15 Sep 2015 08:40:33 +0200 Honza Javorek 
>>> wrote to Konference PyCZ :
>>>
>>> > Jestli mají posílat nějaké informace a těma měnit stav na serveru, tak
>>> > musíš použít i něco jiného než GET, pokud se budeme bavit aspoň o
>>> > samotném
>>> > blbém HTTP, když už ne o RESTu.
>>>
>>> To je právě to, co nechápu. Pokud vezmu množinu jednoduchých akcí jaký je
>>> rozdíl mezi
>>>
>>> GET /123acb/krok
>>>
>>> a mezi
>>>
>>> PUT
>>> id = "123abc",
>>> akce = "krok"
>>>
>>> Chápu, že když chci poslat nějaký větší objem dat je PUT jistě lepší, ale
>>> pokud jde jen o jednoduché povely, co mi PUT nebo DELETE přináší za
>>> výhodu?
>>>
>>> > Já bych ti to klidně nějak zkusil namodelovat, ale k tomu by se hodila
>>> > komplet pravidla té hry a možné stavy, do jakých se lze dostat a jak se
>>> > do
>>> > nich lze dostat.
>>>
>>> Pravidla jsou zatím velice jednoduchá:
>>> Server umístí hráče na hrací pole a ukáže jim, kde je poklad. V každém
>>> kole
>>> lze provést jednu z akcí:
>>>   * otoč se o 90° doleva
>>>   * otoč se o 90° doprava
>>>   * udělej krok
>>>
>>> Cílem je, za co nejmenší počet kol dosáhnout cíle. Server upozorní pokud
>>> by klient šel do zdi nebo pokud chtějí dva hráči vejít na stejné políčko.
>>> Počítám, ale časem s rozšířením pravidel o časované bomby, střílení,
>>> dobíjení
>>> a vybíjení baterií, práce v týmu. Uvidíme jak nám to půjde.
>>>
>>> Díky
>>>   Marek
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Honza Javorek]

Ahoj,

Petr byl rychlejší. Rozdíl mezi GET, PUT, POST, atd. je v tom, že je přesně
ve specifikaci řečeno, co může nebo nemůže způsobit, např. opakovaným
zavoláním.

> HTTP REST uz je striktnejsi a popisuje presnejsi pouziti i DELETE, PUT,
PATCH, etc.

To není úplně přesné. HTTP je protokol a má svoje specifikace. REST je
nějaký styl architektury aplikace, se slovesy v HTTP nemá až tak moc
společného a nemusíme jej tady asi ani řešit (jo, vím že jsem to sám dřív
taky motal do sebe). Úplně pro tento případ postačí, pokud se budeme držet
toho, co nám radí (či specifikací přikazuje?) HTTP samotné.

Jsou na to v zásadě dvě RFC:

- základ v https://tools.ietf.org/html/rfc7231
- PATCH dodělaný a dolepený v http://tools.ietf.org/html/rfc5789

Nebát se číst specifikaci! Je to lidsky psané. Tady přesně se mluví o tom,
jaký je rozdíl mezi metodami, co jaká znamená a co přináší jejich použití a
je tam i pěkná tabulka: https://tools.ietf.org/html/rfc7231#section-4.1

GET je jen čtení, akce, která neublíží. Když budeš při GET mazat, projede
ti odkazy Google nebo kdokoliv jiný a smaže ti cokoliv co tam zrovna mažeš.
Tzn. vše podle specifikace předpokládá, že GET by neměl nic měnit. Taky to
znamená, že cokoliv co je GET se může kdekoliv po cestě kešovat.

PUT je nějaká změna, která je tzv. idempotentní, tzn. když ji pošleš
několikrát za sebou, tak se pak už nic nezmění. Typicky když něco nastavíš
na "vypnuto", tak stejný request můžeš poslat třeba tisíckrát po sobě a ta
věc bude mít nakonec stále "vypnuto". Abych dal protipříklad, nehodí se to
na věci, které jsou např. "přepni" ve stylu vypínače na světlo - když ho
pošlu jednou tak vypne, podruhé zapne, atd. Aby to mělo danou vlastnost,
implementace PUTu vypadá tak, že sestrojíš celou novou reprezentaci a tou
"přeplácneš" tu starou. Takový "replace". Když v cíli nic není, tak se to
při PUTu na dané URL vytvoří, tzn. vhodné i pro vytváření, pokud víš "ID"
předem.

DELETE maže, následně by po něm nemělo nic zůstat.

PATCH je speciál na částečné změny, tzn. že pošleš nějaký diff, kterým
řekneš co se má změnit a server to podle toho diffu nějak změní. Záruky
neveliké, všelijaké, a tak dále.

POST je nějaká změna, která ale nemusí být nutně idempotentní. Je to
základní způsob, jak udělat změnu stavu na serveru. Nedá se to kešovat a
tak dále.

Pozn.: HTML formát a klienti kolem něj (typicky prohlížeče atd.) podporují
často jen GET a POST. S tím si vystačí, protože to hlavní co je potřeba
rozlišit je kešovat/nekešovat a bezpečné/nebezpečné. POST má myslím ve
specifikaci někde taková "zadní vrátka", že kromě toho, že je určen k tomu
co jsem napsal výše, tak může být použit i na "cokoliv jiného". V důsledku
je tedy i HTML s formulářem na mazání osedílaným přes POST udělán správně
podle HTTP specifikace. Klidně můžeš udělat všechno přes POST a bude to
jakože správně, ale tím se připravuješ o to, že GET je pro čtení
efektivnější. Udělat ale všechno v GET místo POST je špatně a koleduješ si,
protože označuješ "nebezpečné" akce jako "bezpečné" (stejně tak s
kešovatelností).

Sorry že jsem se tak rozepsal. Hlavně mi moc nevěřte a přečtěte si to
raději v té specifikaci. Já jsem taky jenom člověk, ale tam je to prostě
vysvětlené a napsané, tak jak to má být.

Honza


2015-09-16 9:37 GMT+02:00 Petr Viktorin :

> 2015-09-16 7:45 GMT+02:00 Petr Blahos :
> > Ještě poznámečka: Pokud bude GET měnit vnitřní stav aplikace, a povede k
> > němu
> > nějaký link, tak ho Google klidně navštíví při indexování :-) Nebo jak
> měl
> > kdysi takové
> > to přednačítání odkazů...
>
> Je psáno [1], že GET nemá měnit stav, a spousta nástrojů to předpokládá.
> Kromě robotů to předpokládají třeba různé keše nebo load balancery. Ty
> sice teď asi nepoužíváš, ale neměl bys zapomenout na to, že *učíš*
> lidi používat HTTP. Nauč je to prosím správně.
>
> [1] ve specifikaci HTTP:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
> > the GET and HEAD methods SHOULD NOT have the significance of taking an
> action other than retrieval. These methods ought to be considered "safe".
>
> > 2015-09-15 22:33 GMT+02:00 Ales Zoulek :
> >>
> >> Technicky rozdil mezi PUT a GET je minimalni. Je ale konvence, aby akce
> >> odpovidala tomu HTTP "slovesu".
> >>
> >> Uplnym minimem je rozliseni mezi GET a POST. Tzn. GET (narozdil od POST)
> >> by nemel menit vnitrni stav serveru, pouze ten stav cist.
> >>
> >> HTTP REST uz je striktnejsi a popisuje presnejsi pouziti i DELETE, PUT,
> >> PATCH, etc.
> >>
> >> Pokud nemas vylozene duvod to nedodrzovat, tak je lepsi se te konvence
> >> drzet.
> >>
> >>
> >> A.
> >>
> >> On Tue, Sep 15, 2015 at 9:54 PM Marek Nožka  wrote:
> >>>
> >>> Ahoj
> >>>
> >>> On Tue, 15 Sep 2015 08:40:33 +0200 Honza Javorek  >
> >>> wrote to Konference PyCZ :
> >>>
> >>> > Jestli mají posílat nějaké informace a těma měnit stav na serveru,
> tak
> >>> > musíš použít i něco jiného než GET, 

Re: [python] Roboti, REST, Flask?

[Petr Viktorin]

2015-09-16 9:56 GMT+02:00 Marek Nožka :
> On Wed, 16 Sep 2015 09:37:41 +0200 Petr Viktorin  wrote
> to Konference PyCZ :
>
>> ale neměl bys zapomenout na to, že *učíš*
>> lidi používat HTTP. Nauč je to prosím správně.
>
> ... právě proto se ptám. Díky všem za poučení, budu se tím řídit.

Když to teď po sobě čtu, vidím že můj příspěvek mohl lehce vyznít
nepřátelsky. Omlouvám se, tak jsem to nemyslel.
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Petr Blahos]

Ještě poznámečka: Pokud bude GET měnit vnitřní stav aplikace, a povede k
němu
nějaký link, tak ho Google klidně navštíví při indexování :-) Nebo jak měl
kdysi takové
to přednačítání odkazů...
--
Petr


2015-09-15 22:33 GMT+02:00 Ales Zoulek :

> Technicky rozdil mezi PUT a GET je minimalni. Je ale konvence, aby akce
> odpovidala tomu HTTP "slovesu".
>
> Uplnym minimem je rozliseni mezi GET a POST. Tzn. GET (narozdil od POST)
> by nemel menit vnitrni stav serveru, pouze ten stav cist.
>
> HTTP REST uz je striktnejsi a popisuje presnejsi pouziti i DELETE, PUT,
> PATCH, etc.
>
> Pokud nemas vylozene duvod to nedodrzovat, tak je lepsi se te konvence
> drzet.
>
>
> A.
>
> On Tue, Sep 15, 2015 at 9:54 PM Marek Nožka  wrote:
>
>> Ahoj
>>
>> On Tue, 15 Sep 2015 08:40:33 +0200 Honza Javorek 
>> wrote to Konference PyCZ :
>>
>> > Jestli mají posílat nějaké informace a těma měnit stav na serveru, tak
>> > musíš použít i něco jiného než GET, pokud se budeme bavit aspoň o
>> samotném
>> > blbém HTTP, když už ne o RESTu.
>>
>> To je právě to, co nechápu. Pokud vezmu množinu jednoduchých akcí jaký je
>> rozdíl mezi
>>
>> GET /123acb/krok
>>
>> a mezi
>>
>> PUT
>> id = "123abc",
>> akce = "krok"
>>
>> Chápu, že když chci poslat nějaký větší objem dat je PUT jistě lepší, ale
>> pokud jde jen o jednoduché povely, co mi PUT nebo DELETE přináší za
>> výhodu?
>>
>> > Já bych ti to klidně nějak zkusil namodelovat, ale k tomu by se hodila
>> > komplet pravidla té hry a možné stavy, do jakých se lze dostat a jak se
>> do
>> > nich lze dostat.
>>
>> Pravidla jsou zatím velice jednoduchá:
>> Server umístí hráče na hrací pole a ukáže jim, kde je poklad. V každém
>> kole
>> lze provést jednu z akcí:
>>   * otoč se o 90° doleva
>>   * otoč se o 90° doprava
>>   * udělej krok
>>
>> Cílem je, za co nejmenší počet kol dosáhnout cíle. Server upozorní pokud
>> by klient šel do zdi nebo pokud chtějí dva hráči vejít na stejné políčko.
>> Počítám, ale časem s rozšířením pravidel o časované bomby, střílení,
>> dobíjení
>> a vybíjení baterií, práce v týmu. Uvidíme jak nám to půjde.
>>
>> Díky
>>   Marek
>> ___
>> Python mailing list
>> python@py.cz
>> http://www.py.cz/mailman/listinfo/python
>>
>> Visit: http://www.py.cz
>>
>
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
>
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Honza Javorek]

> No...já měl v úmyslu použít spíš, "něco jako REST". Počítám spíš s tím, že
> se bude používat jen GET a požadavky budou jako součást URL: ///
> Nebo tak nějak. Jak bys to udělal ty?

Jestli mají posílat nějaké informace a těma měnit stav na serveru, tak
musíš použít i něco jiného než GET, pokud se budeme bavit aspoň o samotném
blbém HTTP, když už ne o RESTu.

Já bych ti to klidně nějak zkusil namodelovat, ale k tomu by se hodila
komplet pravidla té hry a možné stavy, do jakých se lze dostat a jak se do
nich lze dostat.

Honza



2015-09-11 15:59 GMT+02:00 Marek Nožka :

> On Fri, 11 Sep 2015 08:47:33 + Ales Zoulek 
> wrote
> to Konference PyCZ :
>
> > Pokud ale opravdu musi vsechny tahy synchronisovat, pak bych rekl, ze
> > implementacne bude lehci 2). Tak jak tak se zda rozumny, aby studenti
> > nepsali vlastniho rest klienta a dostali se zadanim i malou knihovnu,
> ktera
> > s tim flaskem komunikuje.
>
> Ano, hráči nemůžou stát na jednom políčku a měli by na sebe reagovat. Ta
> knihovna je dobrý nápad.
>
> Díky
> Marek
>
> --
>  @ @ @ Marek Nožka
>  '.@
>  :*`@   email: marek <@t> tlapicka  net
>  `*'   jabber: tlapicka <@t> mitranet  cz
>   ::  web: http://tlapicka.net/
>   `'
>   `'   Powered by Debian GNU/Linux
>   `.**'
> ¨¨
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
>
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Marek Nožka]

Ahoj

On Tue, 15 Sep 2015 08:40:33 +0200 Honza Javorek 
wrote to Konference PyCZ :

> Jestli mají posílat nějaké informace a těma měnit stav na serveru, tak
> musíš použít i něco jiného než GET, pokud se budeme bavit aspoň o samotném
> blbém HTTP, když už ne o RESTu.

To je právě to, co nechápu. Pokud vezmu množinu jednoduchých akcí jaký je
rozdíl mezi 

GET /123acb/krok

a mezi 

PUT
id = "123abc",
akce = "krok"

Chápu, že když chci poslat nějaký větší objem dat je PUT jistě lepší, ale
pokud jde jen o jednoduché povely, co mi PUT nebo DELETE přináší za výhodu?
 
> Já bych ti to klidně nějak zkusil namodelovat, ale k tomu by se hodila
> komplet pravidla té hry a možné stavy, do jakých se lze dostat a jak se do
> nich lze dostat.

Pravidla jsou zatím velice jednoduchá:
Server umístí hráče na hrací pole a ukáže jim, kde je poklad. V každém kole
lze provést jednu z akcí:
  * otoč se o 90° doleva
  * otoč se o 90° doprava
  * udělej krok

Cílem je, za co nejmenší počet kol dosáhnout cíle. Server upozorní pokud
by klient šel do zdi nebo pokud chtějí dva hráči vejít na stejné políčko.
Počítám, ale časem s rozšířením pravidel o časované bomby, střílení, dobíjení
a vybíjení baterií, práce v týmu. Uvidíme jak nám to půjde.

Díky
  Marek
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Ales Zoulek]

Technicky rozdil mezi PUT a GET je minimalni. Je ale konvence, aby akce
odpovidala tomu HTTP "slovesu".

Uplnym minimem je rozliseni mezi GET a POST. Tzn. GET (narozdil od POST) by
nemel menit vnitrni stav serveru, pouze ten stav cist.

HTTP REST uz je striktnejsi a popisuje presnejsi pouziti i DELETE, PUT,
PATCH, etc.

Pokud nemas vylozene duvod to nedodrzovat, tak je lepsi se te konvence
drzet.


A.

On Tue, Sep 15, 2015 at 9:54 PM Marek Nožka  wrote:

> Ahoj
>
> On Tue, 15 Sep 2015 08:40:33 +0200 Honza Javorek 
> wrote to Konference PyCZ :
>
> > Jestli mají posílat nějaké informace a těma měnit stav na serveru, tak
> > musíš použít i něco jiného než GET, pokud se budeme bavit aspoň o
> samotném
> > blbém HTTP, když už ne o RESTu.
>
> To je právě to, co nechápu. Pokud vezmu množinu jednoduchých akcí jaký je
> rozdíl mezi
>
> GET /123acb/krok
>
> a mezi
>
> PUT
> id = "123abc",
> akce = "krok"
>
> Chápu, že když chci poslat nějaký větší objem dat je PUT jistě lepší, ale
> pokud jde jen o jednoduché povely, co mi PUT nebo DELETE přináší za výhodu?
>
> > Já bych ti to klidně nějak zkusil namodelovat, ale k tomu by se hodila
> > komplet pravidla té hry a možné stavy, do jakých se lze dostat a jak se
> do
> > nich lze dostat.
>
> Pravidla jsou zatím velice jednoduchá:
> Server umístí hráče na hrací pole a ukáže jim, kde je poklad. V každém kole
> lze provést jednu z akcí:
>   * otoč se o 90° doleva
>   * otoč se o 90° doprava
>   * udělej krok
>
> Cílem je, za co nejmenší počet kol dosáhnout cíle. Server upozorní pokud
> by klient šel do zdi nebo pokud chtějí dva hráči vejít na stejné políčko.
> Počítám, ale časem s rozšířením pravidel o časované bomby, střílení,
> dobíjení
> a vybíjení baterií, práce v týmu. Uvidíme jak nám to půjde.
>
> Díky
>   Marek
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
>
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

[python] Roboti, REST, Flask?

[Marek Nožka]

Ahoj

Potřeboval bych malou radu. Učím programování(Python) na SŠ. Takže jsem
vymyslel(okoukal), že si budeme hrát na Roboty. Bude to tahová hra.
Jednotliví roboti(studenti) se připojí k serveru a budou mezi sebou soutěžit
o nejlepší algoritmus, který projde bludištěm podle zadaných pravidel.

Na serverovou část jsem chtěl použít Flask a vytvořit jednoduché REST API.
Řeším ale jak mám obsloužit více klientů tak, aby na sebe navzájem počkali.
Každý klient by měl říct, kam táhne. Ale odpověď můžu poslat až potom, co
všichni pošlou požadavek. Napadli mě dvě řešení.

1) Klient pošle požadavek a čeká na odpověď. Stream odpovědi se ale zastaví
   a čeká se až se ozvou další klienti. Tohle nevím jak bych ve Flasku
   udělal -- pokud to tedy vůbec jde. Pokoušel jsem se to vygooglit ale na
   nic kloudného jsem nepřišel. 

2) Klient pošle požadavek a za nějakou chvilku se zeptá jestli má
   server už odpověď. To je zase více složitosti na straně klienta.

Protože jsem nic podobného zatím nikdy nedělal, budu vděčný za každou
připomínku, poznámku nebo radu. Co za knihovnu/framework byste mi
doporučovali. 

Dky
   Marek

-- 
 @ @ @ Marek Nožka
 '.@
 :*`@   email: marek <@t> tlapicka  net
 `*'   jabber: tlapicka <@t> mitranet  cz
  ::  web: http://tlapicka.net/
  `'
  `'   Powered by Debian GNU/Linux
  `.**'
¨¨
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Ales Zoulek]

Ahoj,

jednotlivy hraci se budou nejak ovlinovat? (Napr pokud robot R1 stoji na
poli 3,4 nemuze na nej R2)

Pokud ne, proc proste kazdy student nekomunikuje se serverem samostatne
podle, server si vsechny tahy nahraje zobrazi vysledky az kdyz vsichni
tudenti poslou sve tahy?

Pokud ale opravdu musi vsechny tahy synchronisovat, pak bych rekl, ze
implementacne bude lehci 2). Tak jak tak se zda rozumny, aby studenti
nepsali vlastniho rest klienta a dostali se zadanim i malou knihovnu, ktera
s tim flaskem komunikuje.

A.

On Fri, Sep 11, 2015 at 10:40 AM Petr Messner 
wrote:

> Na tohle se hodí websocket, lze to provozovat i ve Flasku. Nebo rovnou
> použit něco jiného, např. ZeroMQ.
>
> Petr Messner
>
> 11. 9. 2015 v 10:29, Marek Nožka :
>
> > Ahoj
> >
> > Potřeboval bych malou radu. Učím programování(Python) na SŠ. Takže jsem
> > vymyslel(okoukal), že si budeme hrát na Roboty. Bude to tahová hra.
> > Jednotliví roboti(studenti) se připojí k serveru a budou mezi sebou
> soutěžit
> > o nejlepší algoritmus, který projde bludištěm podle zadaných pravidel.
> >
> > Na serverovou část jsem chtěl použít Flask a vytvořit jednoduché REST
> API.
> > Řeším ale jak mám obsloužit více klientů tak, aby na sebe navzájem
> počkali.
> > Každý klient by měl říct, kam táhne. Ale odpověď můžu poslat až potom, co
> > všichni pošlou požadavek. Napadli mě dvě řešení.
> >
> > 1) Klient pošle požadavek a čeká na odpověď. Stream odpovědi se ale
> zastaví
> >   a čeká se až se ozvou další klienti. Tohle nevím jak bych ve Flasku
> >   udělal -- pokud to tedy vůbec jde. Pokoušel jsem se to vygooglit ale na
> >   nic kloudného jsem nepřišel.
> >
> > 2) Klient pošle požadavek a za nějakou chvilku se zeptá jestli má
> >   server už odpověď. To je zase více složitosti na straně klienta.
> >
> > Protože jsem nic podobného zatím nikdy nedělal, budu vděčný za každou
> > připomínku, poznámku nebo radu. Co za knihovnu/framework byste mi
> > doporučovali.
> >
> > Dky
> >   Marek
> >
> > --
> > @ @ @   Marek Nožka
> > '.@
> > :*`@   email: marek <@t> tlapicka  net
> > `*'   jabber: tlapicka <@t> mitranet  cz
> >  ::  web: http://tlapicka.net/
> >  `'
> >  `'   Powered by Debian GNU/Linux
> >  `.**'
> >¨¨
> > ___
> > Python mailing list
> > python@py.cz
> > http://www.py.cz/mailman/listinfo/python
> >
> > Visit: http://www.py.cz
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
>
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Honza Javorek]

Pokud bude REST API tim nejlepsim zpusobem jak to udelat (coz nemusi byt),
tak bych to udelal nejak takto:

- hrac udela POST na nejake URL, to mu vrati HTTP kod 202, nejakou odpoved
a Location hlavicku, v niz bude odkaz na URL s vysledkem
- hrac dela nasledne polling na vysledkovem URL, kde se objevi odpoved az
ve chvili, kdy bude server chtit (do te doby tam muze byt treba chybova
odpoved informujici, ze server ceka na dalsi hrace - nejspis HTTP 423
Locked (WebDAV; RFC 4918), ale tohle rozsireni specky jsem necetl, jen
podle nazvu mi to prijde nejbliz)

Maly priklad zde:
http://restcookbook.com/Resources/asynchroneous-operations/

Honza

2015-09-11 10:47 GMT+02:00 Ales Zoulek :

> Ahoj,
>
> jednotlivy hraci se budou nejak ovlinovat? (Napr pokud robot R1 stoji na
> poli 3,4 nemuze na nej R2)
>
> Pokud ne, proc proste kazdy student nekomunikuje se serverem samostatne
> podle, server si vsechny tahy nahraje zobrazi vysledky az kdyz vsichni
> tudenti poslou sve tahy?
>
> Pokud ale opravdu musi vsechny tahy synchronisovat, pak bych rekl, ze
> implementacne bude lehci 2). Tak jak tak se zda rozumny, aby studenti
> nepsali vlastniho rest klienta a dostali se zadanim i malou knihovnu, ktera
> s tim flaskem komunikuje.
>
> A.
>
> On Fri, Sep 11, 2015 at 10:40 AM Petr Messner 
> wrote:
>
>> Na tohle se hodí websocket, lze to provozovat i ve Flasku. Nebo rovnou
>> použit něco jiného, např. ZeroMQ.
>>
>> Petr Messner
>>
>> 11. 9. 2015 v 10:29, Marek Nožka :
>>
>> > Ahoj
>> >
>> > Potřeboval bych malou radu. Učím programování(Python) na SŠ. Takže jsem
>> > vymyslel(okoukal), že si budeme hrát na Roboty. Bude to tahová hra.
>> > Jednotliví roboti(studenti) se připojí k serveru a budou mezi sebou
>> soutěžit
>> > o nejlepší algoritmus, který projde bludištěm podle zadaných pravidel.
>> >
>> > Na serverovou část jsem chtěl použít Flask a vytvořit jednoduché REST
>> API.
>> > Řeším ale jak mám obsloužit více klientů tak, aby na sebe navzájem
>> počkali.
>> > Každý klient by měl říct, kam táhne. Ale odpověď můžu poslat až potom,
>> co
>> > všichni pošlou požadavek. Napadli mě dvě řešení.
>> >
>> > 1) Klient pošle požadavek a čeká na odpověď. Stream odpovědi se ale
>> zastaví
>> >   a čeká se až se ozvou další klienti. Tohle nevím jak bych ve Flasku
>> >   udělal -- pokud to tedy vůbec jde. Pokoušel jsem se to vygooglit ale
>> na
>> >   nic kloudného jsem nepřišel.
>> >
>> > 2) Klient pošle požadavek a za nějakou chvilku se zeptá jestli má
>> >   server už odpověď. To je zase více složitosti na straně klienta.
>> >
>> > Protože jsem nic podobného zatím nikdy nedělal, budu vděčný za každou
>> > připomínku, poznámku nebo radu. Co za knihovnu/framework byste mi
>> > doporučovali.
>> >
>> > Dky
>> >   Marek
>> >
>> > --
>> > @ @ @   Marek Nožka
>> > '.@
>> > :*`@   email: marek <@t> tlapicka  net
>> > `*'   jabber: tlapicka <@t> mitranet  cz
>> >  ::  web: http://tlapicka.net/
>> >  `'
>> >  `'   Powered by Debian GNU/Linux
>> >  `.**'
>> >¨¨
>> > ___
>> > Python mailing list
>> > python@py.cz
>> > http://www.py.cz/mailman/listinfo/python
>> >
>> > Visit: http://www.py.cz
>> ___
>> Python mailing list
>> python@py.cz
>> http://www.py.cz/mailman/listinfo/python
>>
>> Visit: http://www.py.cz
>>
>
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
>
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Petr Messner]

Na tohle se hodí websocket, lze to provozovat i ve Flasku. Nebo rovnou použit 
něco jiného, např. ZeroMQ. 

Petr Messner

11. 9. 2015 v 10:29, Marek Nožka :

> Ahoj
> 
> Potřeboval bych malou radu. Učím programování(Python) na SŠ. Takže jsem
> vymyslel(okoukal), že si budeme hrát na Roboty. Bude to tahová hra.
> Jednotliví roboti(studenti) se připojí k serveru a budou mezi sebou soutěžit
> o nejlepší algoritmus, který projde bludištěm podle zadaných pravidel.
> 
> Na serverovou část jsem chtěl použít Flask a vytvořit jednoduché REST API.
> Řeším ale jak mám obsloužit více klientů tak, aby na sebe navzájem počkali.
> Každý klient by měl říct, kam táhne. Ale odpověď můžu poslat až potom, co
> všichni pošlou požadavek. Napadli mě dvě řešení.
> 
> 1) Klient pošle požadavek a čeká na odpověď. Stream odpovědi se ale zastaví
>   a čeká se až se ozvou další klienti. Tohle nevím jak bych ve Flasku
>   udělal -- pokud to tedy vůbec jde. Pokoušel jsem se to vygooglit ale na
>   nic kloudného jsem nepřišel. 
> 
> 2) Klient pošle požadavek a za nějakou chvilku se zeptá jestli má
>   server už odpověď. To je zase více složitosti na straně klienta.
> 
> Protože jsem nic podobného zatím nikdy nedělal, budu vděčný za každou
> připomínku, poznámku nebo radu. Co za knihovnu/framework byste mi
> doporučovali. 
> 
> Dky
>   Marek
> 
> -- 
> @ @ @   Marek Nožka
> '.@
> :*`@   email: marek <@t> tlapicka  net
> `*'   jabber: tlapicka <@t> mitranet  cz
>  ::  web: http://tlapicka.net/
>  `'
>  `'   Powered by Debian GNU/Linux
>  `.**'
>¨¨
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
> 
> Visit: http://www.py.cz
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Marek Nožka]

On Fri, 11 Sep 2015 11:05:48 +0200 Honza Javorek 
wrote to Konference PyCZ :

> Pokud bude REST API tim nejlepsim zpusobem jak to udelat (coz nemusi byt),
> tak bych to udelal nejak takto:

No...já měl v úmyslu použít spíš, "něco jako REST". Počítám spíš s tím, že
se bude používat jen GET a požadavky budou jako součást URL: ///
Nebo tak nějak. Jak bys to udělal ty?
 
> - hrac udela POST na nejake URL, to mu vrati HTTP kod 202, nejakou odpoved
> a Location hlavicku, v niz bude odkaz na URL s vysledkem
> - hrac dela nasledne polling na vysledkovem URL, kde se objevi odpoved az
> ve chvili, kdy bude server chtit (do te doby tam muze byt treba chybova
> odpoved informujici, ze server ceka na dalsi hrace - nejspis HTTP 423
> Locked (WebDAV; RFC 4918), ale tohle rozsireni specky jsem necetl, jen
> podle nazvu mi to prijde nejbliz)
> 
> Maly priklad zde:
> http://restcookbook.com/Resources/asynchroneous-operations/

Díky, myslím, že tak nějak to provedu.

Marek

-- 
 @ @ @ Marek Nožka
 '.@
 :*`@   email: marek <@t> tlapicka  net
 `*'   jabber: tlapicka <@t> mitranet  cz
  ::  web: http://tlapicka.net/
  `'
  `'   Powered by Debian GNU/Linux
  `.**'
¨¨
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Marek Nožka]

On Fri, 11 Sep 2015 14:29:36 +0200 Hynek Fabian
 wrote to Konference PyCZ :

> Ja jsem asi moc ovlivnenej corewars, ale nejak mi unika k cemu by tam
> sitova komunikace byla. Stacilo by kdyby klienti uploadnuli modul,
> simulator si vsechny naimporti, projede a vyhodi vysledek (vitezove,
> resp. zaznam tahu). Na to staci blbej sitovej share.

Pravidla mám zatím vymyšlená velice jednoduchá, ale budou se časem
zesložiťovat. Jednotlivý roboti na sebe budou reagovat, bude se měnit počet
hráčů atd.

Marek

-- 
 @ @ @ Marek Nožka
 '.@
 :*`@   email: marek <@t> tlapicka  net
 `*'   jabber: tlapicka <@t> mitranet  cz
  ::  web: http://tlapicka.net/
  `'
  `'   Powered by Debian GNU/Linux
  `.**'
¨¨
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Marek Nožka]

On Fri, 11 Sep 2015 08:47:33 + Ales Zoulek  wrote
to Konference PyCZ :

> Pokud ale opravdu musi vsechny tahy synchronisovat, pak bych rekl, ze
> implementacne bude lehci 2). Tak jak tak se zda rozumny, aby studenti
> nepsali vlastniho rest klienta a dostali se zadanim i malou knihovnu, ktera
> s tim flaskem komunikuje.

Ano, hráči nemůžou stát na jednom políčku a měli by na sebe reagovat. Ta
knihovna je dobrý nápad.

Díky
Marek

-- 
 @ @ @ Marek Nožka
 '.@
 :*`@   email: marek <@t> tlapicka  net
 `*'   jabber: tlapicka <@t> mitranet  cz
  ::  web: http://tlapicka.net/
  `'
  `'   Powered by Debian GNU/Linux
  `.**'
¨¨
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

[Hynek Fabian]

Ja jsem asi moc ovlivnenej corewars, ale nejak mi unika k cemu by tam
sitova komunikace byla. Stacilo by kdyby klienti uploadnuli modul,
simulator si vsechny naimporti, projede a vyhodi vysledek (vitezove,
resp. zaznam tahu). Na to staci blbej sitovej share.


On 09/11/2015 11:05 AM, Honza Javorek wrote:
> Pokud bude REST API tim nejlepsim zpusobem jak to udelat (coz nemusi
> byt), tak bych to udelal nejak takto:
> 
> - hrac udela POST na nejake URL, to mu vrati HTTP kod 202, nejakou
> odpoved a Location hlavicku, v niz bude odkaz na URL s vysledkem
> - hrac dela nasledne polling na vysledkovem URL, kde se objevi odpoved
> az ve chvili, kdy bude server chtit (do te doby tam muze byt treba
> chybova odpoved informujici, ze server ceka na dalsi hrace - nejspis
> HTTP 423 Locked (WebDAV; RFC 4918), ale tohle rozsireni specky jsem
> necetl, jen podle nazvu mi to prijde nejbliz)
> 
> Maly priklad zde:
> http://restcookbook.com/Resources/asynchroneous-operations/
> 
> Honza
> 
> 2015-09-11 10:47 GMT+02:00 Ales Zoulek  >:
> 
> Ahoj,
> 
> jednotlivy hraci se budou nejak ovlinovat? (Napr pokud robot R1
> stoji na poli 3,4 nemuze na nej R2)
> 
> Pokud ne, proc proste kazdy student nekomunikuje se serverem
> samostatne podle, server si vsechny tahy nahraje zobrazi vysledky az
> kdyz vsichni tudenti poslou sve tahy?
> 
> Pokud ale opravdu musi vsechny tahy synchronisovat, pak bych rekl,
> ze implementacne bude lehci 2). Tak jak tak se zda rozumny, aby
> studenti nepsali vlastniho rest klienta a dostali se zadanim i malou
> knihovnu, ktera s tim flaskem komunikuje.
> 
> A.
> 
> On Fri, Sep 11, 2015 at 10:40 AM Petr Messner
> > wrote:
> 
> Na tohle se hodí websocket, lze to provozovat i ve Flasku. Nebo
> rovnou použit něco jiného, např. ZeroMQ.
> 
> Petr Messner
> 
> 11. 9. 2015 v 10:29, Marek Nožka  >:
> 
> > Ahoj
> >
> > Potřeboval bych malou radu. Učím programování(Python) na SŠ.
> Takže jsem
> > vymyslel(okoukal), že si budeme hrát na Roboty. Bude to tahová
> hra.
> > Jednotliví roboti(studenti) se připojí k serveru a budou mezi
> sebou soutěžit
> > o nejlepší algoritmus, který projde bludištěm podle zadaných
> pravidel.
> >
> > Na serverovou část jsem chtěl použít Flask a vytvořit
> jednoduché REST API.
> > Řeším ale jak mám obsloužit více klientů tak, aby na sebe
> navzájem počkali.
> > Každý klient by měl říct, kam táhne. Ale odpověď můžu poslat
> až potom, co
> > všichni pošlou požadavek. Napadli mě dvě řešení.
> >
> > 1) Klient pošle požadavek a čeká na odpověď. Stream odpovědi
> se ale zastaví
> >   a čeká se až se ozvou další klienti. Tohle nevím jak bych ve
> Flasku
> >   udělal -- pokud to tedy vůbec jde. Pokoušel jsem se to
> vygooglit ale na
> >   nic kloudného jsem nepřišel.
> >
> > 2) Klient pošle požadavek a za nějakou chvilku se zeptá jestli má
> >   server už odpověď. To je zase více složitosti na straně klienta.
> >
> > Protože jsem nic podobného zatím nikdy nedělal, budu vděčný za
> každou
> > připomínku, poznámku nebo radu. Co za knihovnu/framework byste mi
> > doporučovali.
> >
> > Dky
> >   Marek
> >
> > --
> > @ @ @   Marek Nožka
> > '.@
> > :*`@   email: marek <@t> tlapicka  net
> > `*'   jabber: tlapicka <@t> mitranet  cz
> >  ::  web: http://tlapicka.net/
> >  `'
> >  `'   Powered by Debian GNU/Linux
> >  `.**'
> >¨¨
> > ___
> > Python mailing list
> > python@py.cz 
> > http://www.py.cz/mailman/listinfo/python
> >
> > Visit: http://www.py.cz
> ___
> Python mailing list
> python@py.cz 
> http://www.py.cz/mailman/listinfo/python
> 
> Visit: http://www.py.cz
> 
> 
> ___
> Python mailing list
> python@py.cz 
> http://www.py.cz/mailman/listinfo/python
> 
> Visit: http://www.py.cz
> 
> 
> 
> 
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
> 
> Visit: http://www.py.cz
> 
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz