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!