This Week Reading List

Want to learn any programming language? — Write These 3 Simple Apps!

https://medium.com/@samuel.fare/want-to-learn-any-programming-language-write-these-3-simple-apps-5af8cd119921

Very good read if you want to learn new programming langugage. Sam Fare challenges you to build 3 simple apps with a new programming langauge: Hello World, Anagram and Pizza app. I’ll throw in one more as a bonus: a Todo app.

 


How to Become a Better Software Developer by Digging & Climbing

https://dmitripavlutin.com/become-better-software-developer-digging-climbing/

Even if you are an experienced developer, it’s still a very good read. Dmitri shares what he did to become a better developer (and we always have room to become a better developer). It’s a conceptual idea, which is why it’s a very good read, with some practical examples.

 


Event-driven analytics with Azure Data Lake Storage Gen2

https://azure.microsoft.com/en-us/blog/event-driven-analytics-with-azure-data-lake-storage-gen2/

If you are dealing with big data, the ingestion, processing, storage, consumption and ETL stuff, add this to your reading list. It outlines a way to use event-driven technique using Azure services to build data for analytics.

 


Azure solution architectures

https://azure.microsoft.com/en-us/solutions/architecture/

One of my favorites. This is more of a reference than a reading. Microsoft docs provides cloud architecture solutions (based on Azure services) for different scenarios and needs. Definitely check it out when you need to design and build a new system.

 


The Azure Infrastructure Architect Map

https://techcommunity.microsoft.com/t5/Azure-Developer-Community-Blog/The-Azure-Infrastructure-Architect-Map/ba-p/766268

Yet another good resource for a reference. This guides you through way-too-many Azure services based on your needs, sorta help you to decide what Azure service to use for a specific scenario. There’s also Solution Architect map and Security Architect map. Links are in the article.

 


Pipeline Pattern Implementations in C# .NET – Part 1

https://michaelscodingspot.com/pipeline-pattern-implementations-csharp/

Part 1 of 2 where Michael explains how to implement pipeline pattern in C#. This is not about `System.IO.Pipelines` library, but rather,
Part 2 – https://michaelscodingspot.com/pipeline-pattern-tpl-dataflow/

Advertisements

What is Event Sourcing?

Event Sourcing

Every application has a state, representing current snapshot at the moment. Event sourcing is the idea of persisting all of these states as it changes from one to another.

Imagine a workflow for an invoice goes something like: invoice is created which set the status to pending. Pending invoice then gets approved which sets it approved. Approved invoice can be denied or collected. When invoice is denied, it goes back to pending, but when it’s collected, it becomes closed. The state of an invoice is where it’s at a particular time. However, when event sourcing pattern is implemented, we will be able to see a historical timeline of an invoice, from when it’s created to the current state.

What this allows us to do is, we are able to:

  • Complete rebuild: getting rid of the current state and use events to rebuild the invoice to its current state.
  • Temporal query: we can tell what state an invoice is at particular point in time.
  • Event replay: when the past event is incorrect, we can make the change and compute it from the beginning, thus, replaying the whole series of events.

Some applications of event sourcing are:

  • Source control. Every source control uses time series where commits made change the code. By storing events for every commit, we are able to state of the code at particular point in time.
  • Redo / undo. Applications that utilize undo / redo, such as word processor, will benefit from event sourcing pattern.
  • Document history. Word processor application will also benefit from event sourcing by storing event every time changes are made.

I hope this simple explanation of event sourcing helps you to understand what it is and how we can use it. There’s definitely a lot more to it that I don’t cover here, but there are lots of resources online you can learn from.

Reference

https://martinfowler.com/eaaDev/EventSourcing.html

Event Sourcing Design Pattern

What is Event Sourcing?

Is a architecture design pattern that uses append-only store to record full series of events that happen on specific data. The store also acts as publisher to all subscribers whenever an event is recorded.

Characteristics

  • Append-only store. Some implementation may be different.
  • Event store as system of record.
  • Materialized object is constructed from events.
  • Provide audit trails.
  • Fast performance.

Considerations

  • Undo is adding another event. Perform undo can only be done by adding compensating event since update is not allowed in Event Store
  • Migration to new format. All existing events must be updated.
  • Consistency. Multi-threaded applications may store events in the same event store. The consistency and order must be maintained.
  • Lack of transactions. Event store by its nature is not transactional and it’s eventual consistency. It’s possible to have event to reduce the inventory count while customer is placing order for the same item.
  • Performance. Replaying large amount of events can slow down the result for materialized view.

Reference
Microsoft Docs

Observer vs Publish Subscribe (Pub Sub) Pattern

Oberserver

  • The recipient knows who’s the sender of the message.
  • Unicast, send one, receive by one.
  • Asynchronous.
  • Straight forward, from sender to recipient directly.

Pub Sub

  • Both sender and recipient don’t know who send or receive the message. They just don’t need to know.
  • Multicast approach, send one, every one receives.
  • Asynchronous, messages can be sent to multiple recipients at the same time.
  • Message queue based, there’s some kind of container to queue a message.

Composite vs Decorator Patterns

In Java world (yes, I know, there is such world ostensibly …), there’s a templating framework called Tiles. It’s basically an open source framework to help developers build View part of the MV* (* = whatever).

Tiles uses Composite pattern, much like what you see in ASP.NET MVC.

The other side of the coin is Decorator pattern. SiteMesh is an example of Decorator pattern, it is also a Java open source template framework to build View. In .Net world, SiteMesh is equivalent to classic ASP’s master page concept.

Composite vs Decorator

Both Composite and Decorator break layout to smaller components (or sections), such as Header, Menu, Content and Footer. Each of these components is built on separate page (.jsp file in the case of Java).

When the page is requested, it will take all needed components and put them together as a page. The difference between Composite and Decorator is on the way the page is constructed.

Composite allows the children components to define what’s needed. For example, when you load a Contact page, you tell the framework that the main component to load is Contact. The framework knows Contact component needs Header, Content and Footer components. It will then load all the dependencies components, stick them into Contact component. The page is complete and returned to user.

Decorator, on the other hand, relies on the parent (or master page) to define what’s needed for a page. Taken from Contact page example above, Decorator will first see which parent component the Contact is using, then call the parent component. From there, it knows the parent’s dependencies, construct the parent component along with its dependencies, then stick the Contact component into parent component where it belongs. In this case, the parent component also define where the main component should be placed.

More differences from Tiles project site.

Aspect Composite View Decorator
Reusability The different parts of the page (template and pieces) can be reused across the whole application. Each decorator can be reused, but the decoration itself can be applied to one page at a time.
Ease of configuration Each page must be defined explicitly. The decorator can be applied even to the entire application.
Runtime configuration The pages can be configured and organized at runtime Since one page is decorated at a time, this feature is not present.
Performances Low overhead for composition. The page to be decorated has to be parsed.

Decorator Problem

One problem I had before was trying to build a reusable web component, think about Calendar widget. I would be fine if I build my widget with pure HTML and JavaScript, but if there is a special case where I need to use View framework to load up my widget, then Decorator wouldn’t be much useful because I can’t have children component to use my widget without repeating code.

That’s not to say Composite doesn’t have any problem, I just haven’t come across one.

What is Command Query Responsibility Separation (CQRS)?

From Wikipedia: every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer.

what-is-command-query-responsibility-separation-cqrs

Further read: MSDN’s CQRS Journey

What is Repository Pattern?

The repository pattern is a data access pattern that abstracts away data access code. With the repository pattern, the application can interact with a data source without knowing specific details of the data source. The application communicates to a repository objects and the repository objects responsible for getting, inserting, updating or deleting data. The application doesn’t know anything about the data access, the repository is in charge of that.

Why would you use Repository pattern:

  • Testability: easier unit test your application, specifically data access layer.
  • Maintainability: since all the data access logic resides in its own object, it’s easier to maintain.
  • Refactor: easier to change data access later. For example, switch from a local DB to a cloud based DB.

Further read: Martin Fowler’s Repository Pattern