<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" 
  xmlns:content="http://purl.org/rss/1.0/modules/content/" 
  xmlns:dc="http://purl.org/dc/elements/1.1/" 
  xmlns:atom="http://www.w3.org/2005/Atom" 
  xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" 
  xmlns:media="http://search.yahoo.com/mrss/">
  <channel>
    <title>Val&#39;s Tech Blog</title>
    <link>http://valerii-udodov.com/</link>
    <description>Recent content on Val&#39;s Tech Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <managingEditor>vudodov@gmail.com (Valerii Udodov (aka Val))</managingEditor>
    <webMaster>vudodov@gmail.com (Valerii Udodov (aka Val))</webMaster>
    <lastBuildDate>Fri, 17 Nov 2023 18:35:36 +1100</lastBuildDate>
    
        <atom:link href="http://valerii-udodov.com/index.xml" rel="self" type="application/rss+xml" />
    
      
      
      
        
      
        
      
        
      
        
      
        
      
        
      
        
      
        
      
        
      

      
      <item>
        <title>Data Partitioning in Distributed Systems</title>
        <link>http://valerii-udodov.com/posts/data-partitioning/</link>
        <pubDate>Fri, 17 Nov 2023 18:35:36 +1100</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Fri, 17 Nov 2023 18:35:36 +1100</atom:modified>
        <guid>http://valerii-udodov.com/posts/data-partitioning/</guid>
        <description>I feel like data storage scalability in distributed or not systems is often overlooked.
Whenever we talk about scalability, we usually imply processing scalability in distributed systems. We talk about ways to scale out dedicated service clusters without downtimes or data flow interruptions.
I’ve written a few articles about it myself. Don&amp;rsquo;t forget to check them out afterwards
Data Consistency in Microservice Architecture. Clean Event-Driven Architecture But today, let’s talk about data scalability.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/data-partitioning/main.png" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>scalability</category>
            
          
        
        
          
            
              <category>architecture</category>
            
          
        
        
      </item>
      
      <item>
        <title>Git Hygiene</title>
        <link>http://valerii-udodov.com/posts/git-hygiene/</link>
        <pubDate>Mon, 01 May 2023 17:50:06 +1000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Mon, 01 May 2023 17:50:06 +1000</atom:modified>
        <guid>http://valerii-udodov.com/posts/git-hygiene/</guid>
        <description>Don&amp;rsquo;t forget to subscribe ✉️, so you won&amp;rsquo;t miss latest news and articles. Not by coincidence Git has become a default version control system for many of us. Git has proven itself to be predictable and reliable. Especially when it comes to conflict management, history traversal, and other daily developer routines.
I have collected some recommendations that will enhance your day-to-day experience of working with Git. And hopefully, reveal some hidden features that have been laying around all this time.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/git-hygiene/main.png" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>git</category>
            
          
            
              <category>devOps</category>
            
          
            
              <category>vcs</category>
            
          
        
        
          
            
              <category>git</category>
            
          
        
        
      </item>
      
      <item>
        <title>Domain-Driven Design: building the Right thing Right</title>
        <link>http://valerii-udodov.com/posts/domain-driven-design/</link>
        <pubDate>Wed, 12 Apr 2023 17:50:06 +1000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Wed, 12 Apr 2023 17:50:06 +1000</atom:modified>
        <guid>http://valerii-udodov.com/posts/domain-driven-design/</guid>
        <description>The success of any given software project can be distilled to a rather simple definition or rule: we need to build the right thing, and we need to build this thing right.
It is a very abstract and simple if not primitive definition. Nevertheless, it is the one that is hard to argue with.
Building the right thing Building the right thing… I don’t think it is necessary to emphasise the importance of this claim.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/domain-driven-design/main.png" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>domain-driven-design</category>
            
          
            
              <category>communication</category>
            
          
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>domain-driven-design</category>
            
          
        
        
      </item>
      
      <item>
        <title>HTTP/3. All you need to know.</title>
        <link>http://valerii-udodov.com/posts/http3/</link>
        <pubDate>Wed, 22 Jun 2022 17:50:06 +1000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Wed, 22 Jun 2022 17:50:06 +1000</atom:modified>
        <guid>http://valerii-udodov.com/posts/http3/</guid>
        <description>HTTP/3 is a long overdue change in the way the Internet works. Surprisingly, though, it does not impact us as protocol consumers much&amp;hellip; Moreover, the transition will be barely noticeable. Eventually, we will notice that port 443 is gone. And we won&amp;rsquo;t need to type https:// anymore. We will be getting back to http://&amp;hellip;
We&amp;rsquo;ll talk more about it later.
ℹ️ Port 443 is the one that is used for secure HTTP (aka HTTPS connection).</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/http3/main.png" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>http3</category>
            
          
            
              <category>tcp</category>
            
          
            
              <category>udp</category>
            
          
            
              <category>quic</category>
            
          
        
        
          
            
              <category>network</category>
            
          
            
              <category>protocols</category>
            
          
        
        
      </item>
      
      <item>
        <title>Data Consistency in the Microservice Architecture</title>
        <link>http://valerii-udodov.com/posts/data-consistency-in-micorservice-architecture/</link>
        <pubDate>Thu, 09 Jun 2022 11:14:23 +1000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Thu, 09 Jun 2022 11:14:23 +1000</atom:modified>
        <guid>http://valerii-udodov.com/posts/data-consistency-in-micorservice-architecture/</guid>
        <description>Don&amp;rsquo;t forget to subscribe ✉️, so you won&amp;rsquo;t miss latest news and articles. Data Consistency is an enigma of Distributed Architecture. It is a rather poetic way to say that something is a pain in the ass.
It might not be that obvious at the first glance, but Data Consistency never exists in isolation. It is heavily bonded with Availability and Partition Tolerance. If they sound alien, don&amp;rsquo;t worry. We will closely look at them and their friendship in a moment</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/data-consistency-in-microservices/m.png" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>micro-services</category>
            
          
            
              <category>architecture</category>
            
          
            
              <category>event-driven-architecture</category>
            
          
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>microservices</category>
            
          
        
        
      </item>
      
      <item>
        <title>Monolithic Architecture</title>
        <link>http://valerii-udodov.com/posts/monolithic-architecture/</link>
        <pubDate>Sun, 05 Jun 2022 11:14:23 +1000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Sun, 05 Jun 2022 11:14:23 +1000</atom:modified>
        <guid>http://valerii-udodov.com/posts/monolithic-architecture/</guid>
        <description>Nowadays, Monolithic Architecture carries this exaggerated ill fame. I personally worked with a few monolithic architectures in the past. And there&amp;rsquo;s something shameful in admitting that you work or have been working with a monolith. Imagine going to the interview and saying that you have deliberately built a monolith&amp;hellip; Without supervising this claim with a context, you probably better not wait for an offer.
Surprisingly, as we&amp;rsquo;ll reveal a bit later, such a bad reputation was not caused by an architecture itself, or should I say solely by it.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/monolithic-architecture/main.png" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>microservice-architecture</category>
            
          
            
              <category>microservices</category>
            
          
            
              <category>architecture</category>
            
          
            
              <category>monolithic-architecture</category>
            
          
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>microservices</category>
            
          
        
        
      </item>
      
      <item>
        <title>JavaScript. Memory. Architecture and Lifecycle.</title>
        <link>http://valerii-udodov.com/posts/javascript-memory/</link>
        <pubDate>Tue, 19 Oct 2021 11:14:23 +1000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Tue, 19 Oct 2021 11:14:23 +1000</atom:modified>
        <guid>http://valerii-udodov.com/posts/javascript-memory/</guid>
        <description>Don&amp;rsquo;t forget to subscribe ✉️, so you won&amp;rsquo;t miss latest news and articles. I&amp;rsquo;ll start this article with a quote that changed the way I think of memory. The way I perceive memory lifecycle in major modern languages (those that have automatic memory release aka garbage collection).
Garbage collection is simulating a computer with an infinite amount of memory.
&amp;ndash; Raymond Chen
This is exactly how we think of memory in JavaScript.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/javascript-memory/main.jpg" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>javascript</category>
            
          
            
              <category>javascript runtime</category>
            
          
            
              <category>browser</category>
            
          
            
              <category>javascript garbage collector</category>
            
          
            
              <category>javascript engine</category>
            
          
        
        
          
            
              <category>exploration</category>
            
          
            
              <category>javascript</category>
            
          
        
        
      </item>
      
      <item>
        <title>Run, JavaScript, Run</title>
        <link>http://valerii-udodov.com/posts/run-javascript-run/</link>
        <pubDate>Thu, 09 Sep 2021 11:14:23 +1000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Thu, 09 Sep 2021 11:14:23 +1000</atom:modified>
        <guid>http://valerii-udodov.com/posts/run-javascript-run/</guid>
        <description>Don&amp;rsquo;t forget to subscribe ✉️, so you won&amp;rsquo;t miss latest news and articles. Preamble Let&amp;rsquo;s admit. JavaScript is not the most predictable language out there. It might get pretty quirky very easily.
Let&amp;rsquo;s look at the following example.
1 2 3 4 5 6 7 8 setTimeout(() =&amp;gt; console.log(&amp;#34;1. timeout&amp;#34;)); console.log(&amp;#34;2. console&amp;#34;); Promise.resolve(&amp;#34;3. promise&amp;#34;).then((res) =&amp;gt; console.log(res)); // prints // 2. console // 3. promise // 1. timeout Even if we will change the order of instructions, it won&amp;rsquo;t impact the final result 🤨</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/run-javascript-run/run-js-run-2.jpg" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>javascript</category>
            
          
            
              <category>web browser</category>
            
          
            
              <category>javascript runtime</category>
            
          
            
              <category>browser</category>
            
          
            
              <category>javascript engine</category>
            
          
        
        
          
            
              <category>exploration</category>
            
          
            
              <category>javascript</category>
            
          
        
        
      </item>
      
      <item>
        <title>Clean Event-Driven Architecture</title>
        <link>http://valerii-udodov.com/posts/event-sourcing/clean-event-driven-architecture/</link>
        <pubDate>Thu, 15 Jul 2021 19:44:01 +1000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Thu, 15 Jul 2021 19:44:01 +1000</atom:modified>
        <guid>http://valerii-udodov.com/posts/event-sourcing/clean-event-driven-architecture/</guid>
        <description>Don&amp;rsquo;t forget to subscribe ✉️, so you won&amp;rsquo;t miss latest news and articles.
And you are always welcome to buy me a coffee ☕. In general clean architecture is a pretty bold statement. However, at the same time, it is a hollow and opaque thing to say.
How do you measure the cleanness of the architecture? By the number of components in the system? Nope&amp;hellip; Whether it is cloud-first or not?</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/clean-event-driven-architecture/triangle.jpg" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>event-sourcing</category>
            
          
            
              <category>architecture</category>
            
          
            
              <category>event-driven-architecture</category>
            
          
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>event-driven-architecture</category>
            
          
        
        
      </item>
      
      <item>
        <title>Event Sourcing: Events Evolution, Versioning, and Migration</title>
        <link>http://valerii-udodov.com/posts/event-sourcing/events-versioning/</link>
        <pubDate>Thu, 03 Jun 2021 15:04:16 +1000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Thu, 03 Jun 2021 15:04:16 +1000</atom:modified>
        <guid>http://valerii-udodov.com/posts/event-sourcing/events-versioning/</guid>
        <description>Don&amp;rsquo;t forget to subscribe ✉️, so you won&amp;rsquo;t miss latest news and articles.
And you are always welcome to buy me a coffee ☕. Before we begin There are few things worth noting before we kick things off&amp;hellip;
First thing Let&amp;rsquo;s clarify what do we mean by the term Event Sourcing. Event Sourcing is an approach for storing and restoring system state in/from a series of strictly ordered events, grouped into streams.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/events-versioning/jackalope.jpg" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>event-sourcing</category>
            
          
            
              <category>architecture</category>
            
          
            
              <category>event-driven-architecture</category>
            
          
            
              <category>event-versioning</category>
            
          
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>event-driven-architecture</category>
            
          
        
        
      </item>
      
      <item>
        <title>React Json Schema Form</title>
        <link>http://valerii-udodov.com/posts/react-json-schema-form/</link>
        <pubDate>Fri, 23 Apr 2021 14:46:18 +1000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Fri, 23 Apr 2021 14:46:18 +1000</atom:modified>
        <guid>http://valerii-udodov.com/posts/react-json-schema-form/</guid>
        <description>Today, I&amp;rsquo;d like to share with you one of the items from my tools-belt, which I&amp;rsquo;m successfully using for years now. It is simply a react component. It is a form. But not just a form, it is a form that allows anyone independently of their React or HTML knowledge to build a sophisticated feature-rich form based on any arbitrary expected data in a consistent manner.
Behold, the React JSON Schema Form, or simply RJSF.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/react-json-schema-form/logo.png" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>reactjs</category>
            
          
            
              <category>javascript</category>
            
          
            
              <category>rjsf</category>
            
          
            
              <category>json schema</category>
            
          
        
        
          
            
              <category>front-end</category>
            
          
        
        
      </item>
      
      <item>
        <title>Different Flavours of Events</title>
        <link>http://valerii-udodov.com/posts/event-sourcing/different-flavours-of-events/</link>
        <pubDate>Wed, 21 Apr 2021 15:11:19 +1000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Wed, 21 Apr 2021 15:11:19 +1000</atom:modified>
        <guid>http://valerii-udodov.com/posts/event-sourcing/different-flavours-of-events/</guid>
        <description>It has been a while since the word event became a buzzword in the tech community. And ultimately turned into an obfuscated term. It is used in a mixture of technical contexts which often overlap and create a whole new level of confusion. Check this out, there are Event Stores, event streams, event buses, domain events, and so forth and so on. Moreover, you&amp;rsquo;ll find events in the heart of different modeling technics (e.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/different-flavours-of-events/pencils.jpg" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>event-sourcing</category>
            
          
            
              <category>architecture</category>
            
          
            
              <category>event-driven-architecture</category>
            
          
            
              <category>services</category>
            
          
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>event-driven-architecture</category>
            
          
        
        
      </item>
      
      <item>
        <title>Are Controllers Real Evil?</title>
        <link>http://valerii-udodov.com/posts/controllers-are-evil/</link>
        <pubDate>Tue, 18 Aug 2020 18:21:17 +1000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Tue, 18 Aug 2020 18:21:17 +1000</atom:modified>
        <guid>http://valerii-udodov.com/posts/controllers-are-evil/</guid>
        <description>Initially, this article was called &amp;ldquo;How MVC became an anti-pattern. And Mediator became the pattern.&amp;rdquo;. But as I was writing I realized that we&amp;rsquo;ve got the wrong guy here. Probably you already know that I&amp;rsquo;ll attempt to blame Controllers in everything. Although MVC as we know it played an important role in our perception of the Controllers. I don&amp;rsquo;t think MVC is a true source of evil. I don&amp;rsquo;t even think that Controllers as part of the MVC pattern are evil.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/controllers-are-evil/evil.png" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>MVC</category>
            
          
            
              <category>WebAPI</category>
            
          
            
              <category>http-mediator</category>
            
          
            
              <category>asp.net core</category>
            
          
            
              <category>C#</category>
            
          
        
        
          
            
              <category>architecture</category>
            
          
        
        
      </item>
      
      <item>
        <title>Post articles through CI/CD pipeline. Or having a Tech Blog in 2020.</title>
        <link>http://valerii-udodov.com/posts/my-blog-setup/</link>
        <pubDate>Mon, 03 Aug 2020 16:19:55 +1000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Mon, 03 Aug 2020 16:19:55 +1000</atom:modified>
        <guid>http://valerii-udodov.com/posts/my-blog-setup/</guid>
        <description>Intro I wrote this article in the Visual Studio Code. It was a markdown .md file in the separate article-dedicated GitHub branch, which eventually became a Pull Request. And if you are reading it, it means that the post made its way to the master branch. The merge event triggered the process that transformed .md file into a static .html file, which was finally pushed to a hosting. And now you can read it.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/my-blog-setup/_main.png" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>HUGO</category>
            
          
            
              <category>GitHub</category>
            
          
            
              <category>GitHub Actions</category>
            
          
            
              <category>Google Firebase</category>
            
          
            
              <category>Google Analytics</category>
            
          
            
              <category>CI/CD</category>
            
          
        
        
          
            
              <category>exploration</category>
            
          
        
        
      </item>
      
      <item>
        <title>Server-side Redux. Part III. The Code.</title>
        <link>http://valerii-udodov.com/posts/server-side-redux/server-side-redux-3-the-code/</link>
        <pubDate>Thu, 09 Apr 2020 05:10:31 +0000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Thu, 09 Apr 2020 05:10:31 +0000</atom:modified>
        <guid>http://valerii-udodov.com/posts/server-side-redux/server-side-redux-3-the-code/</guid>
        <description>The State Management Goes Wild his is the final article of the series where we explore Redux and its boundaries. In the previous articles, we first dived into the main principles of the Redux, then we tried to move things around and conceptually move Redux from one side to another.
This article is all about hands-on experience, and by the end of it, we will have a working application that will follow the design we settled before.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        
        
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>ReactJS</category>
            
          
            
              <category>redux</category>
            
          
            
              <category>code</category>
            
          
            
              <category>JavaScript</category>
            
          
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>experiment</category>
            
          
        
        
          
            
              <category>Server-side Redux</category>
            
          
        
      </item>
      
      <item>
        <title>Server-side Redux. Part II. The Design.</title>
        <link>http://valerii-udodov.com/posts/server-side-redux/server-side-redux-2-the-design/</link>
        <pubDate>Sat, 04 Apr 2020 04:57:15 +0000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Sat, 04 Apr 2020 04:57:15 +0000</atom:modified>
        <guid>http://valerii-udodov.com/posts/server-side-redux/server-side-redux-2-the-design/</guid>
        <description>The State Management Goes Wild This is the second article of the series where we will try to find out if there’s a place for Redux on the other side of the fence.
Even though this series is base on the assumption that you are more or less familiar with what is Redux, don’t worry if not, as we covered all necessary concepts in the previous article. Take your time and make yourself comfortable with Redux.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        
        
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>ReactJS</category>
            
          
            
              <category>redux</category>
            
          
            
              <category>JavaScript</category>
            
          
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>experiment</category>
            
          
        
        
          
            
              <category>Server-side Redux</category>
            
          
        
      </item>
      
      <item>
        <title>Server-side Redux. Part I. The Redux.</title>
        <link>http://valerii-udodov.com/posts/server-side-redux/server-side-redux-1-the-redux/</link>
        <pubDate>Sun, 29 Mar 2020 08:29:53 +0000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Sun, 29 Mar 2020 08:29:53 +0000</atom:modified>
        <guid>http://valerii-udodov.com/posts/server-side-redux/server-side-redux-1-the-redux/</guid>
        <description>The State Management Goes Wild This is the first article of the series where we will try to find out if there&amp;rsquo;s a place for Redux on the other side of the fence.
Even though this series is base on the assumption that you are more or less familiar with the Redux, but don&amp;rsquo;t worry if not, as we will go over necessary concepts first.
Once we are confident with the Redux as a React state manager, we will be exploring how we can use it as a back-end state management and state distribution tool and gradually build the conceptual design.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        
        
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>ReactJS</category>
            
          
            
              <category>redux</category>
            
          
            
              <category>JavaScript</category>
            
          
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>experiment</category>
            
          
        
        
          
            
              <category>Server-side Redux</category>
            
          
        
      </item>
      
      <item>
        <title>CQRS: Querying via HTTP</title>
        <link>http://valerii-udodov.com/posts/cqrs/cqrs-querying-via-http/</link>
        <pubDate>Tue, 10 Mar 2020 03:46:17 +0000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Tue, 10 Mar 2020 03:46:17 +0000</atom:modified>
        <guid>http://valerii-udodov.com/posts/cqrs/cqrs-querying-via-http/</guid>
        <description>This article continues the series dedicated to the CQRS pattern. We will be looking at the Command Query Responsibility Segregation pattern as an architecture, particularly dive into the Querying part and try to find out how to fit it in the HTTP. At the time this article is written, two main protocol versions exist HTTP/1.1 and HTTP/2. Version 3.0 is in the draft, so we are not considering it. The main difference between 1.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        
        
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>CQRS</category>
            
          
        
        
          
            
              <category>architecture</category>
            
          
        
        
          
            
              <category>CQRS via HTTP</category>
            
          
        
      </item>
      
      <item>
        <title>CQRS: Commanding via HTTP</title>
        <link>http://valerii-udodov.com/posts/cqrs/cqrs-commanding-via-http/</link>
        <pubDate>Thu, 20 Feb 2020 06:33:21 +0000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Thu, 20 Feb 2020 06:33:21 +0000</atom:modified>
        <guid>http://valerii-udodov.com/posts/cqrs/cqrs-commanding-via-http/</guid>
        <description>This article starts the series dedicated to CQRS on top of HTTP. We will be looking at the Command Query Responsibility Segregation pattern as an architecture, particularly dive into the Commanding part and try to find out how to fit it in the HTTP. At the time this article is written, two main protocol versions exist HTTP/1.1 and HTTP/2. Version 3.0 is in the draft, so we are not taking it into consideration.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        
        
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>CQRS</category>
            
          
        
        
          
            
              <category>architecture</category>
            
          
        
        
          
            
              <category>CQRS via HTTP</category>
            
          
        
      </item>
      
      <item>
        <title>Web Browser Anatomy</title>
        <link>http://valerii-udodov.com/posts/web-browser-anatomy/</link>
        <pubDate>Thu, 06 Feb 2020 03:20:52 +0000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Thu, 06 Feb 2020 03:20:52 +0000</atom:modified>
        <guid>http://valerii-udodov.com/posts/web-browser-anatomy/</guid>
        <description>Web Browser is a big and sophisticated application, built from multiple components. It obligated to satisfy different boring standards, to facilitate developers with stable contracts. You might know these contracts as HTML, CSS, and JavaScript.
Any valid code or markup will be recognized and processed by one of the browser modules. The browser glues together all its modules with the Browser Object Model (BOM) API, aka Web API. This is something that empowers JavaScript to operate on HTML and CSS.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        <media:content url="http://valerii-udodov.com//images/posts/web-browser-anatomy/v8-blueprint.jpg" medium="image"><media:title type="html">featured image</media:title></media:content>
        
        
        
          
            
              <category>web browser</category>
            
          
            
              <category>browser</category>
            
          
            
              <category>browser engine</category>
            
          
            
              <category>compilation</category>
            
          
            
              <category>front-end</category>
            
          
            
              <category>javascript</category>
            
          
            
              <category>javascript engine</category>
            
          
        
        
          
            
              <category>front-end</category>
            
          
            
              <category>exploration</category>
            
          
        
        
      </item>
      
      <item>
        <title>Single Page Application. React example.</title>
        <link>http://valerii-udodov.com/posts/single-page-application-react-example/</link>
        <pubDate>Fri, 24 Jan 2020 04:10:49 +0000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Fri, 24 Jan 2020 04:10:49 +0000</atom:modified>
        <guid>http://valerii-udodov.com/posts/single-page-application-react-example/</guid>
        <description>It is not a guide for building a single page application with the help of React JS.
This article is about the tool that empowers modern web to look the way it looks today and provide a seamless experience of navigation, enabling single page applications to exist.
Good old days Back in the days, the internet and everything around it was different, as well as expectations from web sites. A typical web site would be a set of HTML pages tied together with cross-references.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        
        
        
        
          
            
              <category>reactjs</category>
            
          
            
              <category>routing</category>
            
          
            
              <category>S3</category>
            
          
            
              <category>SPA</category>
            
          
            
              <category>WebPack</category>
            
          
        
        
          
            
              <category>front-end</category>
            
          
        
        
      </item>
      
      <item>
        <title>CQRS: Intro</title>
        <link>http://valerii-udodov.com/posts/cqrs/cqrs-intro/</link>
        <pubDate>Mon, 13 Jan 2020 05:31:09 +0000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Mon, 13 Jan 2020 05:31:09 +0000</atom:modified>
        <guid>http://valerii-udodov.com/posts/cqrs/cqrs-intro/</guid>
        <description>Command Query Responsibility Segregation
This pattern gains popularity lately. And there’re certain benefits of using it as well as drawbacks. I would like to share my own experiences and thoughts on this topic.
ℹ️ Don&amp;rsquo;t forget to check out more advanced series dedicated to appliying CQRS architectural patter on top of HTTP [CQRS via HTTP].
The series covers in depth main actors of the pattern, such as Commanding and Querying, as well as how do they fit in the HTTP.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        
        
        
        
          
            
              <category>architecture</category>
            
          
            
              <category>CQRS</category>
            
          
        
        
          
            
              <category>architecture</category>
            
          
        
        
      </item>
      
      <item>
        <title>Mixing C# with JSON Schema</title>
        <link>http://valerii-udodov.com/posts/making-strongly-typed-language-a-bit-more-loose-with-json-schema/</link>
        <pubDate>Mon, 24 Jun 2019 13:05:32 +0000</pubDate>
        <author>vudodov@gmail.com (Valerii Udodov (aka Val))</author>
        <atom:modified>Mon, 24 Jun 2019 13:05:32 +0000</atom:modified>
        <guid>http://valerii-udodov.com/posts/making-strongly-typed-language-a-bit-more-loose-with-json-schema/</guid>
        <description>The JSON Schema Have you ever found yourself in a situation when your application requires pre-defined data which you will use to build your business logic, but besides that you need a capability to extend your data, in a way so it stays meaningful. Maybe even extend it differently depending on circumstances. It might depend on the users location, or preference. Or it might depend on the customer, and customer-specific data.</description>
        
        <dc:creator>Valerii Udodov (aka Val)</dc:creator>
        
        
        
        
          
            
              <category>C#</category>
            
          
            
              <category>JSON</category>
            
          
            
              <category>JSON Schema</category>
            
          
        
        
        
      </item>
      

    
  </channel>
</rss>
