Skip to main content

Multisport karta

Multisport je takový gadget mezi fitnessy, až jsem o něm musel napsat článek :-) O co jde? Zaplatíte určitý obnos peněz za parmanentku, se kterou můžete navštěvovat různá sportovní zařízení. Genialita spočívá v tom, že jen v Praze jsou těch zařízení stovky, od fitness přes bojové sporty, badminton, tenis, bruslení, bazén, wellness, sauny atd. Více v seznamu partnerů.

Jediné omezení spočívá v tom, že na multisport kartu můžete navštívit jen jednoho partnera denně, což v praxi moc velké omezení není. Zároveň v seznamu partnerů nejsou ty TOP záležitosti, např. z posiloven jsou tam převážně ty menší. Např. moje oblíbené fitness BBC tam není. S ním konec konců budu srovnávat všechna fitka dále v minirecenzích.

Zároveň ještě některé podniky maji problém při kolektivních sportech, např. jsme řešili problém s Erpetem na badminton, kdy na jeden kurt neumí rozpůlit cenu, tzn. že já bych "platil" multisport kartou a kolega penězi. Museli bychom mít karty oba dva, abych ji já mohl uplatnit.

Pro mě osobně je to skoro revoluční záležitost. Jednak je příjmné chodit v týdnu do fitka blízko k prácí, o víkendu zase blízko bydlišti. Aktivní člověk by měl rozhodně relaxovat a i to karta v ceně nabízí. Za druhé po delší době chození kamkoliv se člověku jedno zařízení okouká, velmi tedy vítám možnost průběžně měnit místa, kde člověk tráví větší množství času.

V dalších článcích bych rád přinesl minirecenze jednotlivých podniků, kam jsme měli šanci zajít, protože dokud člověk nezkusí, tak neví :-) Fotky občas zkreslují.

Na závěr to nejlepší: karta mě v rámci akce pro mého zaměstnavatele, HP, stála nějakých 590kč měsíčne - na půl roku. Což zní skoro neuvěřitelně, když za pět set korun stěží seženete permantnentku do jednoho podniku, tady jich máte stovky.

Všechny minirecenze lze najit postupně tady.

Comments

Popular posts from this blog

Performance Battle of NoSQL blob storages #1: Cassandra

Preface We spend last five years on HP Service Virtualization using MsSQL database . Non-clustered server. Our app utilizes this system for all kinds of persistence. No polyglot so far. As we tuned the performance of the response time - we started at 700ms/call and we achieved couple milliseconds per call at the end when DB involved - we had to learn a lot of stuff. Transactions, lock escalation , isolation levels , clustered and non clustered indexes, buffered reading, index structure and it's persistence, GUID ids in clustered indexes , bulk importing , omit slow joins, sparse indexes, and so on. We also rewrite part of NHibernate to support multiple tables for one entity type which allows use scaling up without lock escalation. It was good time. The end also showed us that famous Oracle has half of our favorite features once we decided to support this database. Well, as I'm thinking about all issues which we encountered during the development, unpredictive behavio

ETCD: POST vs. PUT understanding

ETCD is distributed key value store used as a core component in CoreOS . I've already send a post earlier this week. Here is a page describing how to use ETCD basic commands = ETCD API. Code snippets placed in a page mostly use put , but ETCD allows to use post as well.  Most of us understand differences between those two commands in a notion of a REST(ful) service, but how does it work in key value store? POST Example over many words. curl -v http://127.0.0.1:2379/v2/keys/test -XPOST -D value="some value" curl -v http://127.0.0.1:2379/v2/keys/test -XPOST -D value="some value" Two same command result into following content: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 { "action" : "get" , "node" : { "key" : "/test" , "dir" : true , "nodes" : [ { "key" : "/test/194" , "value" : &