[PL] var Sovia = new Tech();

TL;DR

Polski Piątek: o Warszawskiej Grupie .NET, o polskim community, o tym co u nas w trawie i w technologii piszczy, a także o innych rzeczach wszelakich.

Jakość, jak zawsze

Po raz kolejny polski oddział Microsoft dostarczył wydarzenie na bardzo wysokim poziomie var Sovia = new Tech (); Nie chodzi mi tu o zawartość merytoryczną (o tym później), ale o organizację, wybór miejsca na konferencję jak i rzeczy tak trywialne jak jedzenie czy dobrą kawę. Po ostatnim lokalnym wydarzeniu “Build” wyszedłem oczarowany. Także w tym wypadku, wysoko postawiona poprzeczka została utrzymana na tym samym poziomie.

Kontent, czyli zawartość

Prezentacji było wiele. To co ciekawe to przepleciono wystąpienia związane z technologiami MS z prezentacjami produktów czy startupów na nich bazujących. I tak na przykład, o Hololensach słyszał każdy. Nie każdy wie, że powstaje projekt, który umożliwi sprawne i szybkie przygotowanie chirurga do wykonania operacji serca. Cognitive Services użyte w kwerendzie SQL generującej raport razem z wiekiem osoby, której zdjęcie pozyskaliśmy? Żaden problem.

Prezentacja Satyi Nadelli. Na żywo. W Warszawie. Tego jeszcze nie było.

Ciekawą pozycją była walka w klatce starego .NET z nowym .NET core dostarczona przez Bojana Vrhovnika i Jakuba Gutkowskiego. Było zabawnie, z jajem. Pojawiły się też smoki 😉

Społeczności

Event bez społeczności nie znaczy nic. I tym razem nie zabrakło ludzi, dyskusji i dywagacji na przeróżne tematy. Ewidentnym plusem spotkania była możliwość porozmawiania z osobami albo pracującymi w MS albo pozostającymi w bliskich relacjach.

Jeżeli var Sovia = new Tech(); zagości u nas ponownie za rok, to będzie to mój pewnik w konferencyjnym kalendarzu.

Better Stateful Service Fabric

TL;DR

This is a follow up entry to Stateful Service Fabric that introduced all the kinds of statefulness you can out of the box from the Fabric SDK. It’s time to move on with providing a better stateful service. First, we need to define what better means.

KeyValueStoreReplica implementation details

The underlying actors’ persistence is based on KeyValueStoreReplica. This class provides a high level API for low level interop interfaces provided by Service Fabric. Yep, you heard it. The runtime of the Fabric is unmanaged and is exposed via COM+ interfaces. Then they are wrapped in a nice .NET classes just to be delivered to you. The question is how nice are these classes? Let’s take a look at the decompiled part of a method.


private void UpdateHelper(TransactionBase transactionBase, string key, byte[] value, long checkSequenceNumber)
{
using (PinCollection pin = new PinCollection())
{
IntPtr key1 = pin.AddBlittable((object) key);
Tuple<uint, IntPtr> nativeBytes = NativeTypes.ToNativeBytes(pin, value);
this.nativeStore.Update(transactionBase.NativeTransactionBase, key1, (int) nativeBytes.Item1, nativeBytes.Item2, checkSequenceNumber);
}
}

 

pinning + Interop + pointers = fun

As you can see above, when you pass a string key and a byte[] value a lot must be done to execute the update:

  1. value needs to be allocated every time

    as there’s no interface accepting Stream or ArraySegment<byte> that would allow you to reuse bytes used for allocations, you always need to ToArray the payload

  2. key and value are pinned for the time of executing update.

    Pinning, is nothing more or less than prohibiting object from being moved by GC. The same effect that you get when using fixed keyword or using GCHandle.Alloc. When handles not that many requests it’s ok to do it. When GC kicks in frequently, this might be a problem.

The interesting part is the nativeStore field that provides the COM+ seam to the Fabric internal interface. This is the interface that is closest to the Fabric surface and that allows to squeeze performance out of it.

Summary

You can probably see, when this leads us. Seeing that underneath the .NET wrapper there is a COM+ that has much more low level interface and allows to use raw memory, we can try to access it directly, skipping KeyValueStoreReplica altogether and write a custom implementation that will enable to maximize the performance.

 

Stateful Service Fabric

TL;DR

This is a very next entry in a series covering my journey based on Service Fabric and my Open Source project called SewingMachine. After hitting the internal wall of Service Fabric I pivoted the approach of as I knew that I can’t change the Actors’ part as I wanted (too much internals) and need to work on a different level.

Underneath it’s all stateful

It doesn’t matter if you use StatefulService or the actor’s model of Service Fabric. In the first case you explicitly work with a state using reliable collections: a distributed, transactional dictionary and a queue. You can access them using StateManager of your service derived from the mentioned base class.

In case of actors, you just register an actor in the Actors’ Runtime. Underneath, this results in creating a stateful ActorService. Both, StatefulService and ActorService derive from StatefulServiceBase. The way they provide and operate on the state is quite different.

Reliable collections

Reliable collections provide a dictionary and a queue. Both, are transactional so you can wrap any operations with a regular transaction. They provide different semantics, where the dictionary is a regular dictionary, a lookup if you prefer or a hashmap. The queue is a regular FIFO structure. The transactions have a bit different semantics from regular db transactions, but for now, you may treat them as regular ones.

If the stateful services use reliable collections, is it the same for actors? It looks like it’s not.

KeyValueStoreReplica

The storage for actors is provided by KeyValueStoreReplica already covered in here and here. If you asked is it that much different from the reliable collections, I’d say yes. It has different semantics and provides a simple replicable key-value store. If its is so different, could we build something else than an actor system on top of it?

The answer will be revealed in the very next post.

[PL] Druga Unconference Warszawskiej Grupy .NET

TL;DR

Polski Piątek: o Warszawskiej Grupie .NET, o polskim community, o tym co u nas w trawie i w technologii piszczy.

Unconference WG.NET

W poprzednim tygodniu uruchomiliśmy drugą edycję Unconference Warszawskiej Grupy .NET. Tym razem ugościł nas Demant Technology Centre, mający siedzibę w Q22, w Centrum Warszawy.

Samo spotkanie dogrywaliśmy na podobnych jak ostatnio zasadach: kilka osób ze zgłoszonymi wcześniej tematami, moderatorzy w liczbie wystarczającej do obsłużenia wszystkich grup i flipboardy, po jednym na każdą grupę. Chwilkę, chwilkę. Flipboardy?

No laptop no slides

Flipboardy, bo konwencja przez nas założona zakazuje używania laptopów i slajdów. Chcemy, zamiast prezentacji i tony tekstów/memów/fotek na slajdach, zobaczyć żywą dyskusję pomiędzy uczestnikami a prelegentem a także pomiędzy samymi uczestnikami.

Jedna runda unconference w naszym wypadku zajmuje około 45 minut, po czym następuje 15 minut przerwy podczas której można się posilić, skofeinić i porozmawiać z innymi uczestnikami i prelegentami. Po tym następuje kolejna runda i kolejna przerwa i tak do:

  1. padnięcia wszystkich
  2. wyrzucenia nas z budynku “bo jest po trzeciej rano”
  3. wyczerpania się tematów

Która z przyczyn jest najczęstsza, nie zdradzę.

Nowy prelegent, nowy słuchacz

Unconference dodatkowo pomaga w jednym aspekcie. Jeżeli zastanawiasz się, czy warto kiedyś powiedzieć coś na forum grupy/konferencji, to ten format jest idealny do sprawdzenia tego. 10-20 osób słuchających Ciebie przy flipboardzie nie wymaga wyobrażania sobie wszystkich “nago”, wystarczy po prostu dyskutować i przekazywać swoją wiedzę naturalnie, zgodnie ze swoim naturalnym warsztatem.

To jest pyszne!

Nowa forma spotkania cieszy się bardzo dobrym odbiorem,

Dzięki za fajne spotkanie i merytoryczną konwersację 🙂

Jak dla mnie ta forma może być na stałe 🙂

co powoduje, że na pewno nie raz do niej wrócimy.

Pay back with your feedback

TL;DR

How many times you read a blog post or seen a presentation and had some opinions or remarks that you wanted to share with the author/presenter. How many times you actually shared them?

Vacuum is no good

The worst thing that can happen when presenting is receiving no questions or remarks at all. Lack of it undermines the whole presentation leaving the speaker in a state where their presentation wasn’t bad or good. It was nothing. Still, there’s a line between a regular attendee and a presenter  like a question in a head

How can I ask a question or share my remark/feedback with a presenter? She/he is a presenter, I’m the listener. I should be listening

or something similar.

Your opinions are my money

Presenters and bloggers strive for feedback and your opinions! Actually, receiving one is the best and only opportunity to make a better presentation, to write a better blog entry. How should you provide one?

Have you seen a mizpelld wrod? Write a direct message or an email.

Are you seeing some fallacy? Ask about it in a comment clarifying your point of view.

The presentation/entry is plain wrong? Write your own and ping the author. Maybe it’ll start a fruitful discussion?

Of course there is a lot of dragons in there like trolling, being rude and so on and so forth. If you keep your thoughts to yourself though, nobody will know about them, including the author that you think about.

Shallow and deep foundations of your architecture

TL;DR

This entry addresses some of the ideas related to various types of foundations one can use to create a powerful architectures. I see this post as somewhat resonating with the Gregor Hohpe approach for architecture selling options.

Deep foundations

The deep/shallow foundations allegory came to me after running my workshop about event sourcing in .NET. One of the main properties of an event store was the fact whether it was able to provide a linearized view of all of its events. Having or not this property was vital for providing a simple marker for projections. After all, if all the events have a position, one could easily track only this one number to ensure, that an event was processed or not.

This property laid out a strong foundation for simplicity and process management. Having it or not, was vital for providing one design or another. This was a deep foundation, that was doing a lot of heavy-lifting of the design of processes and views. Opting out later on, from a store that provides this property, wouldn’t be that easy.

You could rephrase it as having strong requirements for a component. On the other hand, I like to think about it as a component providing deep foundations for the emerging design of a system.

Shallow foundations

The other part of a solution was based on something I called Dummy Database. A store that has only two operations PUT & GET, without transactions, optimistic versioning etc. With a good design of the process that can store its progress just by storing a single marker, one could easily serialize it with a partition of a view and store it in a database. What kind of database would it be? Probably any. Any SQL database, Cassandra or Azure Storage Tables are sufficient enough to make it happen.

Moving up and down

With these two types of foundations you have some potential for naturally moving your structure. The deep foundations provide a lot of constraints that can’t be changed that easily, but the rest, founded on the shallow ones, can be changed easily. Potentially, one could swap a whole component or adjust it to an already existing infrastructure. It’s no longer a list of requirement to satisfy for a brand new shiny architecture of your system. The list is much shorter and it’s ended with a question “the rest? we’ll take whatever you have already installed”.

Summary

When designing, split the parts that need to be rock solid and can’t be changed easily from the ones that can. Keep it in mind when moving forward and do not poor to much concrete under parts where a regular stone would just work.

Do zobaczenia na GET.NET Łódź

GET.NET w Łodzi nadciąga wielkimi krokami. Mam nadzieję, że zarezerwowałaś/-eś sobie sobotę 22 kwietnia jako czas poświęcony na pogłębienie swojej pasji i wiedzy. Razem z wieloma prelegentami, będę miał przyjemność podzielić się z Tobą swoim doświadczeniem i wiedzą podczas mojej prezentacji The Only Thing That Matters jak i dyskusji w przerwach. Aby umożliwić Ci łatwiejsze dostanie się na konferencję, przygotowałem mały konkurs. Wystarczy, że krótko opiszesz:

“Najciekawsze zagadnienie architektoniczne z którym się ostatnio spotkałaś/-eś”

Jak rozumieć architekturę, co opisać, to pozostawiam Tobie.

Odpowiedzi wstawiajcie w komentarzach pod tym postem. Nie zapomnijcie podać maili! Wśród zwycięzców (wyłonionych metodą pseudolosową Random) organizatorzy przygotowali 2 bilety.

Termin zgłaszania odpowiedzi: 29 marca (włącznie).