Fitness inspektor: World Class Wenceslas/Vaclavské náměstí

Druhou zastávkou na tour de multisport karta bylo fitko na Václaváku, konkrétně World Class Wenceslas. Hned na začátku, kvůli lokaci, trošku problém s parkováním, protože na Václavském náměstí člověk prostě zdarma nezaparkuje.

Zařízení má vlastně tři podlaží. Nahoře recepce, pár strojů, v mezipatře cardio a sál, dole klasická posilka včetně regulérní hrazdy – asi jediné plus, které jsme ještě ke všemu nepoužili 🙂 V pátek večer narváno zrovna nebylo, ale fitko vypadalo plné, nedokážu si představit třeba úterý večer.

Všechna patra jsou v podzemí, takže žádná okna. Díky tomu na mě nepůsobilo nijak pozitivním dojmem. Když člověk přičte starší stroje, tak z návštěvy nadšený moc nejsem. Sprchy, šatny a sauna celkově horší, takže za me tři mínus.

Fitness inspektor: Fitness Kotva

Na první zkušenost s multisport kartou jsme vyrazili do Fitness Kotva. V centru Prahy na Náměstí republiky, parkovat lze v Kotvě několik hodin zdarma. Dostupnost tedy jak MHD tak autem velmi dobrá.

Jedná se o středně velké fitness – velké pro mě znamená Fitness BBC na Želivského. Příjemné prostředí, nějaký pátek od otevření to už bude, ale vše relativně nové. Aerobní část má řádově deset strojů od běhacích pásů přes orbitrek až po veslování. Dostupné jsou dvě multiposilovací zařízení s hrazdou, docela dost jednoúčlových strojů, celkem slušná “činkárna” s benchem a multipressy, protahovace-posilovací koutek se zrcadly, několika míči, podložkami atd.

Dohromady to funguje. Za dvě návštěvy jsme narazili vždycky na solidní osazenstvo, ani ve špičce není nijak narváno, takže šlo vždycky pohodně cvičit. Za mě je to dvojka 🙂

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.

Redis messaging using Spring and Kryo serialization

Redis is famous enterprise key/value data store which provides simple messaging using publisher/subscriber. I’ve decided to use the system to notify remote nodes (components) about a change of state between those components.

Spring among the others allows to use it’s templating system to decouple business logic from messaging system used under the hood. The use of spring data for Redis guarantees a solution which does not utilize any redis command in the code.

Redis contains serialized content, either byte[] or string. So the last thing to reveal is domain model serialization. I’ve decided to fast binary serialization using Kryo framework as a winner of battle of serializators.

Maven

First of all, it’s necessary to define all dependant components. Obviously, usual component like spring itself missing.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

com.esotericsoftware.kryo
kryo
2.22


org.springframework.data
spring-data-redis
1.1.0.RELEASE


redis.clients
jedis
2.1.0

Kryo Serializator

I used domain model’s entity which hold identifier of our internal service, this is just UUID. The point is to setup kryo serializator which get the entity and returns byte[]. The entity itself is not important.

1
2
3
4
5
6
7
8
9
10
11
12
public class MyEntitySerializer extends Serializer<MyEntity> {

@Override
public void write(Kryo kryo, Output output, MyEntity object) {
return ...;
}

@Override
public MyEntity read(Kryo kryo, Input input, Class<MyEntity> type) {
return ...;
}
}

Redis Message Handler

The beautiful part is the complete definition of async message handling within xml configuration of redis message container.

Note that I used Jedis client as java redis client.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<bean id="jedisConnectionFactory" class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory"
p:host-name="${redisHost}" p:use-pool="true"/>

<bean id="myEntitySerializer" class="MyEntitySerializer" />

<bean id="redisContainer" class="org.springframework.data.redis.listener.RedisMessageListenerContainer">
<property name="connectionFactory" ref="jedisConnectionFactory"/>
<property name="messageListeners">




<bean id="messageListener"
class="org.springframework.data.redis.listener.adapter.MessageListenerAdapter">

<bean class="MyEntityListener"
autowire="constructor"/>

<property name="serializer" ref="myEntitySerializer"/>


<bean class="org.springframework.data.redis.listener.ChannelTopic">
<constructor-arg value="${channelName}"/>





What is going on?

Message container references both redis factory and given list of message listeners. It’s a class (or set of classes) having registered method as a callback when a new message arrives.

The last property is channel with important channel name. The code uses two variables, first is redis host and already mentioned channel name.

Message Listener

The last thing to do is to define message listener containing callback method, MyEntityListener. The class instance is called always once new message arrive using channel topic.

Crucial point was to discover the signature of callback’s method because spring’s documentation is little bit sloopy. Quick look into org.springframework.data.redis.listener.adapter.MessageListenerAdapter’s onMessage shows the correct way.

1
2
3
4
5
6
public class MyEntityListener {

public void handleMessage(MyEntity entity, String channel) {
// provide handling code
}
}

Incoming message is automatically deserialized so the method accepts entity itself.

Conclusion

Look at previous code. Every redis related code is defined in spring’s context and container class. No boilerplate code. Pretty nice.

Architectural note should explicitly show that the entity serves as a notification only. This is very important as such messaging is not reliable. Although the entity holds some information all the persistent data is defined within another place, e.g. as key/value pairs. Approaching message just notifies subscriber that new content is available to refresh and it’s supposed to GET key(s).

Scala: get rid of not-null validations

Scala has been always known as a language which allows special handling of null values. There is ton of articles regarding Some[T], None, Option[T].

What is most annoying code for me? Null validations, see usual example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class Entity {

}

class ServiceA {
def method(a: Entity, b: Entity, c: Entity, d: Entity) = {
Validate.notNull(a)
Validate.notNull(b)
Validate.notNull(c)
Validate.notNull(d)
}
}

class ServiceB(val a: ServiceA) {
def method() = {
a.method(null,null,null,null)
}
}

When you start to write save code in the term of fails-as-fast-as-possible, your code, services or even domain model, will be weedy, you will find such boilerplate code at every method because you can’t be sure which parameter supplied someone to you class or method.

Unfortunately Scala has beautiful way how to achieve nice and simple code – without these checks. If you don’t think that null is proper state for your class, just dismiss this option. How to do that?

1
2
3
class Entity extends NotNull{

}

Well, that’s all. Look at screenshot from my IDE what is about to happen:

notNull trait scala

Now, if you are sure that you don’t want to allow null value for your entity, you can implement NotNull trait and you can remove many lines from your source code.

I was surprised when I found this trait in scala code, because many tutorials or even famous Scala for the Impatient book does not mention this simple but beautiful piece of code.

Tomcat 7 remote deployment

I decided to provide automatic deployment of war packaged application using Jenkins and Deployment plugin. The target platform is Amazon with Tomcat 7, see nice set of articles to find out how to setup such environment for free.

Well, there is couple of tutorials but they missing some points so it pushed me to lost one hour of my work.

What I got

  • Fresh installation of Tomcat 7 on remote machine with opened 8080 port on firewall
  • Personal war file supposed to be deployed

How to push it to tomcat?

1. First of all, there is simple configuration of tomcat users in file tomcat-users.xml – it was my pain in the ass 🙂 As original comprehensive documentation says, it’s necessary to define user, but which one(s)?

Here is working example of tomcat-users.xml:




The important part is manager-script, contrary to Tomcat 6 where it had not exist yet. This user allows access to /text sub-namespace in management uri. The first user called manager-gui is the one which you use in GUI console, e.g. http://localhost:8085/manager/html

Once you run tomcat using bin’s bat file, you can move to second bullet.

2. Now, it’s possible to use remote deployment using curl command, e.g. in my use-case:

curl –upload-file my.war “http://manager-script:changeit@localhost:8080/manager/text/deploy?path=/myPath&update=true&#8221;

The command is working using manager-script user contrary to my original manager-gui. Another interesting part is path=/myPath. This attribute say which URL sub-namespace is to be used.

Even if you deploy my.war and common Tomcat’s approach is to deploy application in /my subname, the application is to be exposed on /myPath.

Jenkins + git revision in all build names

Jenkins by default assigns version of a build using local counter within each type of a build. An example is better.

When you look at this overview, you definitely do not know which code revision was used in Compile build and which in Integration Tests. I’ve followed nice article regarding real CI pipeline using jenkins. It uses Build Name Setter Plugin. Unfortunately this article uses SVN revision number.

So I said I’ll just use git revision as git is my source control. But it’s not so easy as how it could seem for first look.

My Jenkins setup comprised of first compile build step which clones git server and performs an compilation. Second build steps clones the repository from first step and executes integration tests. The problem here is that the second step does not know which git revision compile step cloned.

Here is list of steps how to do that.

1. You obviously need Git Plugin, Build Name Setter Plugin and Parameterized Trigger Plugin
2. Compile build requires following Post-Build action using Parameterized Trigger Plugin

This will introduce new environment property called GIT_REVISION with value equals to current cloned git revision.

3. Integration Test build uses Build Name Setter Plugin’s option along with following code:
PL#${ENV,var=”GIT_REVISION”}-${BUILD_NUMBER}

And that’s all.