Skip to main content

Fitness inspektor: I'M FIT Fitness, Fénix

Během Vánočních svátků jsem vyrazil navštívit jedno z papírově nejmodernějších fitek, které nabízí multisport. I'M FIT Wellness and Fitness v Galerii Fénix v Praze.

Vyrazili bychom tam už dříve, bohužel na multisport kartu je vstup možný pouze 7:00 - 17:00, takže během pracovního dne to skoro nejde. Parkovat lze v obchodním centru zdarma. Na recepci vznikla první komplikace - k uzamčení šatny potřebujete vlastní zámek. Naneštěstí všechny erární byly půjčené, nicméně po pár minutách se problém vyřešil, protože ho někdo z klientů vrátil. Za týden, při druhé návštěvě, však už chtěli za půjčení zámku 30 kč.

Zázemí je výborné. První co jsem viděl v Praze, kde mají ve sprchách sprcháč a další spotřební věci for free. Zklamáním je vlastní posilovna. Z webu lze vyčíst, že zařízení disponuje krom ní i cardio, cyclingem, wellness, bazén, sauna. Jelikož je v I'M FITu tolik věcí, na posilku nezbylo až tolik prostoru. Jednoručky, patnáct možná dvacet moderních leč na sobě namačkaných strojů, hrazda. Na druhé straně v cardiozóně je pár běhátek plus veslovací trenažer. To je vše. Samozřejmě, jak píšu výše, je možné zajít na spinning, do sauny popř. na bosu trénink do menší tělocvičny, kam tu neděli šla většina zákazníků.

Co se mi líbilo bylo celkem civilizované prostředí, normální lidé. Na recepci jsem se dozvěděl, že denně chodí na multisport kartu 120 lidí. Když k tomu přičteme regulérní permanentkáře, nechtěl bych tam chodit v týdnu od šesti, asi by tam nebylo vůbec k hnutí.

Z posilky jsem odcházel se smíšenými dojmy. Celkově pěkné, kultivované, ale malé. Bohužel jsem nebyl ve welness části, ale možná že koncept celého zařízení není v posilce, ale právě ve welness. Příště uvidíme a možná kvůli tomu zbytku zvednu známku, protože zatím průměr - trojka.

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" : &