RxJava is an implementation of “Reactive Extensions” (Rx) in Java. But what is
this? Originally Rx are an implementation of Microsoft to address the
increasing complexity of software. It is a model to build large scale
asynchronous service architectures.
Another company that has to be mentioned is Netflix: they implemented the
Rx in Java which resulted in RxJava.
On the programming side Rx looks very similar to how streams
(java.util.stream.Stream) work. The main difference in my opinion is that
streams are pull and lazy. They produce only as much data as someone is reading
from them. RxJava on the other side is more push style. The source of data is
pushing events through a pipe of operators similar to what you know from streams
(filter(), map(), and so on) to the sink. And as I know from this book, Java
streams are the wrong tool to parallelize anything that is not CPU bound–like
network requests. There reason for this is, that (parallel) streams are executed
on a thread pool that is shared with several other features of Java. This thread
pools is limited to have only that many workers as the system has CPU
cores. Therefore this pool gets exhausted very soon, when threads in it get
blocked by I/O operations. Any thread waiting for an I/O operation effectively
results in a processor core not used by your program.
RxJava on the other hand is not limited to a fixed thread pool. Any source
(Observable) and sink (Subscriber) of data can be bound declaratively to
user defined Schedulers. As well as Rx favours a model in which I/O
operations are done asynchronously and non-blocking. Therefore resulting in a
need for much fewer threads. In a traditional model of using one thread per
network connection, threads become very soon the first thing that limits
scalability.
What is really great about this book
The best part of this book for me were the reflections on Relational Database
Access in chapter 5. While as a developer you might be tempted to convert
everything to the reactive model, this part of the book shows where it doesn't
make sense to do so.
By converting the access to your relational database to an asynchronous model
you won't gain anything. Whatever you are doing on the client side, let's say
for example your PostgreSQL will run all of your concurrent requests in
different processes. This results in a noticeable limit on the number of
parallel queries you're able to run. You cannot lift this limit by becoming
asynchronous on the client side.
Links to the book
ZooKeeper is a component that facilitates building distributed applications.
It is:
- a distributed hierarchical key value store,
- chooses C(onsistency) and A(availability) in the CAP theorem,
- works best on read-dominated workloads (< 10% writes),
- keeps content in the memory of each instance, and
- expects the data stored on each node (key) to be small (maybe several KiB).
The data managed by ZooKeeper is presented in a file system like manner with
directories and files whose names get separated by slashes (/). The difference
to a file system is, that you can store information in the directories as well.
Or seen differently: directories are files at the same time. Based on this
simple abstraction, users of ZooKeeper can implement things like leader election
in a cluster of software instances.
weiterlesen | read more | lee mas | lê mais | 閱讀更多 »
Testgetriebene Entwicklung (TDD) funktioniert – überall. Sie scheitert nicht am
Kunden, den nicht Qualität sondern Tempo interessiert. Sie steht nicht im
Widerspruch zum jungen Projekt mit wenig Budget, das schnell Kunden gewinnen
muss um zu überleben. Sie hindert nicht daran schnell Features umsetzen zu
können. Ja, sie macht mir auch nicht (mehr) langsamer.
Es ist keine neun Monate her, dass ich das nicht glauben konnte. Mehrere Anläufe
hatte ich unternommen neben Code auch Tests zu schreiben. Länger als zwei
Monate ging das nie gut:
- Ich fühlte mich produktiver, wenn ich „richtigen“ Code statt Tests schrieb.
- Ich arbeitete in einem Team, das kein Interesse daran hatte Tests einzuführen.
- Es war nicht wichtig fehlerfrei zu arbeiten, die schnelle Umsetzung von neuen
Features war was zählte.
- Auch ohne Tests konnte ich relativ fehlerfrei entwickeln.
- Manchmal versuchten wir den Kunden zu überzeugen mit Tests zu entwickeln, aber
dieser hatte kein Interesse daran.
- Die Software an der ich gearbeitet habe war nicht besonders gut geeignet
testgetrieben entwickelt zu werden. Die Tests funktionierten solange gut wie
sie mit den knappen Beispiele aus Büchern gemacht wurden, aber unsere reale
Software war zu komplex dafür.
weiterlesen | read more | lee mas | lê mais | 閱讀更多 »
Für meinen Arbeitgeber habe ich ein Programm
entwickelt, das wir nutzen Zeiten zu erfassen und in unser Projektmanagement
einzukoppeln. Um in der Firma einfach auf allen Rechnern immer die neuste
Softwareversion zur Verfügung zu haben, habe ich mich dafür entschieden Java
Webstart
einzusetzen. Diese Technik hatte ich auch bereits für einige andere
Java-Anwendungen von meinen Kunden eingesetzt.
Neu dieses mal war nun allerdings, dass ich nicht
Sprint sondern
CDI für die
Dependency Injection gewählt habe. CDI implementiert durch
WELD ist bei uns auf der Arbeit hierzu
meist der Standard der Wahl.
weiterlesen | read more | lee mas | lê mais | 閱讀更多 »
