In a previous post on event sourcing, I mentioned that there should be a compelling business need to use event sourcing, but how do we know it’s a suitable pattern? After talking to several colleagues I was introduced to the idea of thinking in event streams in order to figure out if event sourcing would be an appropriate given a new new project or adding to an existing solution. Jimmy Bogard commented on Event Sourcing Revisted by Gabriel Schekner, in response to this same question. His process is to determine whether the business (not the developers) thinks and models their problem as a series of events, as a way of deciding to use an event sourced system. If we’re lucky the business will think about and actually model their system as a series of events. They might recognize events in their domain, but I don’t think it’s likely they would have the technical expertise to model the system as a stream of events without input from technical experts familiar with design of event based systems. So it’s up to us, not only be able to recognize events in the domain, but to transform those thoughts into event streams. So how do we get there? We need to start thinking in event streams!
In my post on event sourcing, I briefly described event sourcing and touched on appropriate usages. I’m planning on writing some more about usages, but for now I wanted to share my notes on the fundamental thing we are dealing with when using event sourcing—Events.
I recently took an interest in CQRS (Command Query Responsibility Segregation) to learn how it’s used with DDD (Domain Driven Design) for a project I’m working on. CQRS is an architectural pattern that separates a system into two distinct parts, which either changes the state of the system or reads its current state. While on my CQRS journey, I came across several articles and posts which covered Event Sourcing (ES). This was really interesting to me so went in a little deeper to get a better understanding. Here’s what I know.
After getting through a bulk of the GTD book, the idea of clearing your mind is something that resonated with me and motivated me to try it again; albeit with some minor improvements.
Last month I started an advanced business training program through my employer. It’s a 13 week program that includes several modules on various topics. One of the topics we covered is on Attention Management. This was a really interesting topic and required reading a couple of articles on the subject and David Allen’s Getting Things Done (GTD).
The last year and a half I’ve been working on completing an MBA. And, as of May 2016, I am the proud recipient of a MBA from Webster University George Herbert Walker School of Business!
I had the pleasure of a giving a talk to the Houston Dot Net User Group yesterday evening about fundamental concepts related to SignalR. I had a really good time, thanks to all in attendance!
Today I had to refactor some domain models to a generalized hierarchy with EF. I used the TPH pattern defined by the EF team to split a JournalEntryHeader into a BillingRecordJournalEntryHeader and an InvoiceJournalEntryHeader in order to secure the domain models using the projects data entitlements paradigm.
Today a colleague of mine used the word “coercion” when referring to a soft cast in code. Some thoughts I captured about this.
Warnings in code. Use warnings in code when a challenging section of code has been implemented. Should be in a comment banner and say something like…”If you are not do not have these skills (Demon hunter level 12) then you should probably not be modifying this code!”
In this post I want to improve upon the setup I covered in the previous post Setting up an ASP.NET MVC application with RequireJS and KnockoutJS
Today I gave my first talk at Houston TechFest. The talk was an introduction to building web applications using ASP.NET MVC. I used a military boot camp as a metephor for developing an MVC app. It was a lot of fun!
How does a request for a URL become HTML in an ASP.NET MVC application? This information can be easily found by doing a basic search for the ASP.NET http request cycle. This process is pretty well documented, on both MSDN and the ASP.NET website, so I recommend you go there for a more detailed explanation of the process. So the purpose of this post is for me to articulate how an HTTP Request becomes an MVC View while highlighting the interesting parts.
Below is my list of recommended readings on software development. These books have provided the basis of my knowledge on software design and software development practices in general. I highly recommend these books for junior developers interested in growing or possibly transitioning to software delivery.
About a month or so ago, on a trip to a conference, during dinner, my colleagues and I had a conversation around the use of mocks in unit testing. Not surprisingly it was a passionate conversation on the premise that mocks are bad and should be avoided because it can lead to poor testing form and ultimately sub-optimal design. The conversation was not only entertaining but very interesting, so I took some time to look into it further and form my own opinions.
Over the past few months I’ve had to coach some junior developers on how to TDD. Although most of the devs I’ve been working with are knowledgeable about TDD, putting it to practice seems to be a challenge. Most of them know how to write unit tests, but are not actually practicing TDD where the development of tests drives the development of the code. Instead, they are writing the code first and then bolting tests on afterward. Although this approach works, it is not TDD; it’s unit testing. And unfortunately, misses the main benefit of TDD which is to write testable code that adheres to SOLID design principles; in particular Interface Segregation and Dependency Injection.
My first post using jekyll static website template and GitHub Pages!