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!