Ethereum network and manipulations

In cooperation with Nethermind, I published another research on EIP-1559.  If you don't remember or don't know it, EIP-1559 is an improvement that replaces the auction-based fee market in Ethereum network with a basefee and a tip. The difference between the basefee and the tip is that the first one is paid by a user and burned by the protocol, and the tip is paid directly to the miner. This time I focus on the possibility of the basefee manipulation. As everywhere where the money is involved, somebody can try to cheat the system. You can find the article here.


My first research on blockchain!

In cooperation with Nethermind, I published my first research on EIP-1559. It is an extremely hot topic in Ethereum community nowadays. I analyze how legacy and EIP-1559 users will be treated by the network in post EIP-1559 world. The research, in the form of a Jupyter notebook, can be found here. Comments are welcome.


Neo4j Cypher is great but sometimes strange

My journey with Neo4j started a few months ago and I really think that it is a great database and I'm in love with its query language called Cypher. However, especially having SQL background, some things might be surprising (in this negative way). I will give you an example. Let's assume that we have a graph that among other stores movies. We may write such a query to retrieve all the movies:
MATCH (m:Movie) 
Here is a sample result:

If we slightly modify this query we can select movies that were released in 1999:
MATCH (m:Movie)
WHERE m.released = 1999
This time we will get just 4 movies:

Now let's make something more complex i.e. additionally let's return information about producers of movies (if they exist):
MATCH (m:Movie)<-[:PRODUCED]-(p:Person)
WHERE m.released = 1999
This query has one small bug. The problem is that it returns only 1 movie while we know that there are 4 movies released in 1999. To fix a problem we need to use an equivalent of LEFT/RIGHT JOIN from SQL which is called OPTIONAL MATCH:
MATCH (m:Movie)
WHERE m.released = 1999
Better but still something is wrong. Instead of getting 4 movies, we have dozens of them and if we analyze results we will notice something very strange. Movies returned by a query above were released in many different years e.g. in 1975 even though we have this condition WHERE m.released = 1999.

Does it mean that WHERE statement in Cypher does not work in some cases? Or maybe something is wrong with OPTIONAL MATCH. Well, everything is ok if we know how Cypher exactly works. What is not obvious is that:

OPTIONAL MATCH ... WHERE never removes rows from the result.

Yes, it is awkward but it is how Cypher works. Everything is also explained in this nice article from Neo4j. Any way to fix a problem we have 2 options. We can either change the order of statements in a query:
MATCH (m:Movie)
WHERE m.released = 1999
Or use WITH statement:
MATCH (m:Movie)
WITH m, p
WHERE m.released = 1999
And now results are perfect:


High Load Strategy 2019

I'd like to invite you for my presentation (and not only mine) during this year edition of High Load Strategy conference. On 10th October, together with my colleague Artur Kordzik, we will talk about security in a high-load, distributed environment. Of course, it is not everything and we prepared much more. My colleagues will talk about Kafka, Docker, AI and other things Tiggers like the best.
  • 15.30 – 16.00 Snacks & Networking
  • 16.00 – 16.30 Keynote
    • R. Jaworowski
  • 16.30 -17.15 How we manage our Kafka clusters
    • Robert Fabisiak & Tomasz Gintowt
  • 17.15 – 18.00 What can go wrong during 1,14 ms?
    • Marius Lozda & Wojciech Kromolicki & Arek Bazylewicz,
  • 18.00 - 18.45 RTB Bid Landscape - survival models powered by bitmaps
    • Łukasz Mączewski & Przemysław Piotrowski
  • 18.45 – 19.30 How to make security in a high-load distributed environment
    • Michał Komorowski & Artur Kordzik
  • 19.30 – 20.15 High performance on Docker– adventure
    • Krzysztof Stolarz & Dariusz Binkul
  • 20.15 – 21.15 Beers & Networking
All presentations will be in Polish.


Event Storming workshops from the other side

Some time ago I gave the presentation about DDD and Event Storming during Girls Do IT 2019 conference. I also had occasion to run workshops on the same topic during Programistok 2018 and facilitated a few Event Storming sessions in the past (here is one example). So I can say that I have experience with this very nice modeling and business domain exploration technique proposed by Alberto Brandolini.

However, when I realized that I can take part in Event Storming Workshops organized by Krzysztof Owsiany and Mikołaj Jakubowski I didn't hesitate much to sign in. The workshops had two parts i.e. EventStorming - Big Picture and EventStorming - Design Level. I take part only in the second one while it was more interesting from my perspective.

In the beginning, we finished the Big Picture part and made a quick summary of what was done during the first part of the workshops. Then Krzysztof made an introduction to Design Level Event Storming. To do so he drew such a nice diagram:

Then we divided into 3 teams and started designing a part of a system in more details. Below you can find results of my team.

In the end, we compared designs prepared by all 3 teams. In was interesting to observe the difference between our designs even though we were supposed to design the same functionality.

To sum up I really didn't regret taking part in the workshops! For sure, it was not lost time. It was very valuable to see Event Storming session from the other side and observer how it is facilitated by someone else.

Are you ready to give a chance to Event Storming?

*The pictures in this post comes from own resources and were taken during workshops