Entity Framework (and other ORMs) are in general great pieces of software that makes developers lives so much easier by letting us thinking about objects when we’re working with data persisted in some underlying database. This makes development much easier than writing raw SQL queries. But some of us tend to get too comfy and forgetting about things that lies beneath our beautiful, object oriented code. After all we have Entity Framework, we shouldn’t wrap our heads around SQL stuff. But how about actual...

One of the concepts of actor model that could be hard to grasp at the begining is fact that we will not operate on direct reference to actor instance. This can be a bit confusing before you’ll get used to it but by not using any direct references you’re sure to achieve very good level of encapsulation.

Along with Get Noticed contest I’m a bit preoccupied with other activities. One of them is preparing to take 70-473 Exam (cloud and data related stuff). Since I’m reading and using cert related stuff I could as well write about it – I’ll probably remember everything I’ll write about for rest of my life (writing about things works magic with memory) and maybe someone will have any use for that. Let’s start with simple things – dynamic data masking.

In previous post I’ve explained briefly what actor model is and why it’s so fun. Today we’ll create our ActorSystem instance, learn what it is and send first messages to them. I hope it will be nice and easy start.

I've seen many posts about generics in C# lately. And while they cover basics pretty well, most of them doesn't contain information about constraints which are things that causing generics to be really fun.

I’m building my Get Noticed project from the scratch. And since 3 months is actually a very short span of time, I need compromise between doing some things fast (boring ones) and doing other things in a way that will allow me to write about it and not be ashamed to show some code afterwards. That means I’ll need to incur a technical debt in few areas of project. And I must watch it closely to not allow it to grow without control or interests will probably kill me.

Exactly one year ago I’ve published first post on this blog. It was simple “Hello world” that were followed by some posts related to 2016 edition of Get Noticed contest and after that by some more or less technical related stuff. Since it’s first anniversary of this first, lame “Hello world” post I can’t just write simple “Hi there” again. And because I’m taking a little breath before 2017 edition of said contest I don’t want to write any hard, technical stuff. So let me tell you about some things that I...

So I've got two big, uppercase acronyms in title. Kind of double catchprase and if you're reading this, I've probably got your attention. And I hope to keep it so please, just don't stop reading, at least for a while. But why would you even consider stopping reading post about REST and some kind of API? Well, it's because I have lied and this post is not about this kind of REST that you've expected. Instead, it's about our human, common rest and recharging our batteries... and writing great REST APIs or ...

Some people can say 2016 was terrible year, for me it was one of the best, one of the most productive years as far as I remember. It was sort of game changer to me. So if you believe in balance in the universe, and last 12 month weren't so good for you, you must think there is a guy somehere, who stole your good fortune. Yup, it's me. I'm terribly sorry for that and ... I intend to make 2017 even better, at least for me ;).

W ostatnim poście opisałem i porównałem wydajność różnych sposobów wykorzystania regexów. Zdecydowanie najlepiej sprawowało się wyrażenie, które przygotowałem za pomocą metody Regex.CompileToAssembly(). Dziś omówię ją nieco dokładniej i podpowiem, jak zautomatyzować cały proces aktualizowania zebranych w oddzielnym assembly regexów.