The primary piece of learning for me with this assessment was everything related to the front-end of the application. Creating a Web API in .NET and using Entity Framework is where my core developer strengths lie. While The Fellowship doesn’t currently use .NET Core anywhere, my side projects and code experiments have all been in the new libraries as I prepare the team to make the shift. This was a fun little activity as a way to quickly get the basics of how Angular works - creating components, routing requests, abstracting communication with the server, and binding with the user input.
Posts in "Rovani in C♯"
I am starting to make some real progress with this. I have a better idea of how components, service injection, and input binding works in Angular. These are all concepts that I am very familiar with in my extensive use of Knockout, but anytime one is learning a new framework, there will be a learning curve in figuring out how this particular framework implements various features. Next on the requirements list is the ability to create a new blog post.
Now that I have a static list, the next step is to make it slightly more dynamic. This means that I need to learn how to send something back to the server, instead of just retrieving data from the server. My guess is that a delete method should be easier than an insert of a new record, though I expect them both to be about equal. The first piece I recognized that I needed to add is an identifier for indicating which record to delete. I am a big fan of using a
Guid as the datatype for a “primary key”, so I quickly added a new field to the
BlogPost and added that to my seed data. But how to I make a button in
Angular and then make a
DELETE call to the controller with the id of the selected post?
Yesterday, I did a phone interview with a company offering the possibility for a rather exciting position. The person I spoke with seemed very intelligent, articulate, passionate, and sold the organization well. It’s a small organization that is growing, and is looking to consolidate all of their development work into their Chicago office instead of relying on developers in foreign countries. This feels very similar to what I did with Falkor Group and again with The Fellowship — start with a small team, map out a strategy for the next several sprints, then mentor and grow the team from there. Of course, the interview process is a two-way sales process, and they need to make sure that I can live up to expectations. This leads to why I am doing a Technical Assessment.
Scalar Vector Graphics (SVG) has been one of those many mysteries that I’ve only vaguely been familiar with. Picking up bits of knowledge here and there, I surmised that an SVG image was a set of instructions for how to draw the picture, as opposed to being a mapping of the color of specific pixels. SVG images, thus, could scale to any level and still be the same image. What I had no clue about, though, was what the XML inside of the SVG element was doing. As with all things, I started with a simple Google search that led me to the SVG Tutorial on MDN Web Docs. It is a well written breakdown of how to draw your first SVG image. I highly recommend this, even for those that intend to just use a painting program to spit out the raw SVG. It was a highly illuminating journey.
As I have been working on the Vigil project, I have been accidentally stumbling onto various patterns. I will go in search of a way to solve some particular problem, and end up losing several hours while I research some reference the author made about a concept (or, usually, an acronym) at the end of a post as some kind of a posteriori. The two largest design patterns that I am most excited about are Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES).
I’ve finally done it; I finally ripped, twisted, and otherwise cajoled the default MVC template, Identity code, and a few other tweaks I wanted to make into something I am semi-confident will be a good starting point for future projects. Which is really to say ? I’m at a stopping point and I’ll probably burn it all to the ground, tomorrow.
In the quest to get to a Minimum Viable Product, I wanted to be able to wrap together a set of projects that would act as a complete framework for future projects. Every (nearly every) project requires users and a way for them to register and login. I had already tied myself to the IdentityDbContext for user and role management. Initially, I had my base context (VigilContext) inherit from IdentityDbContext. I had trouble coming to grips with having every project then required to bring in the Microsoft.AspNet.Identity.EntityFramework assembly. As I was explaining a completely unrelated problem to a coworker, it dawned on me that the whole point of Bounded Contexts was to have multiple contexts, and limit them to only a narrow scope. VigilContext was not going to be used everywhere; its purpose is for database initialization and future migrations.
I have found that it is better to put structure in place around a project before going hog wild on implementation. While I recognize that some practices grow organically, a healthy amount of structure up-front can save a project from technical bankruptcy down the line. The two tools that I use early and often are interfaces and contract classes.
Two key library decisions needed to be made this week: choosing the object-relational Mapping (ORM) framework, and choosing a membership provider. To cut right to the end, Entity Framework and ASP.NET Identity were the solutions that I have chosen to utilize throughout the software. This week’s commit has been getting the initial implementation created, customized, and tested.
There are many posts out there for how to configure a database schema to handle scheduling events. The part that I found difficult to find was an algorithm for calculating future dates for each type of recurring schedule. I have started this series on Recurring Gifts as a way to document the process I went through to build the current system. Some features include:
I am not sure why I started using Knockout, but I have had an overall positive experience with the framework. I was very intrigued with their hands-on tutorials built into the site, which made getting started fairly easy. I walked through them step-by-step, writing out all of the code examples by hand, and diligently debugging typos when the example would not execute as expected. From there, I took the simple step of starting a small side-project just to see how it would all interact. At that point, it became quickly obvious that the tutorials suck and are missing large pieces of information that are vital to get just a basic application going. I also found that there are two tutorials that are completely worthless in terms of getting start - they are advanced topics that I still have not found an applicable usage.
The ASP.NET Identity system is designed to replace the previous ASP.NET Membership and Simple Membership systems. It includes profile support, OAuth integration, works with OWIN, and is included with the ASP.NET templates shipped with Visual Studio 2013.
Now that I have been tinkering with Knockout for about a year, I have finally settled on a host of design patterns that I feel strike a nice balance between rigid consistency and flexible prototyping. I like to have all of my code look very similar. I can look at most code that I have written and know about when I worked on it last. I can usually even look at code that several other developers have touched and see what is mine and what is everyone else’s code. Now that I have a team to direct and an expanding code base to maintain, I have realized that I need to document my own code patterns.
I work almost exclusively on the Microsoft WISC stack. The first response that I hear from almost every single developer that I’ve chatted with is something along the lines of “oh, that’s all closed source software”. It makes me want to throttle them. Mostly because it is an entirely antiquated line of thinking that just shows a lack of actual knowledge of the ecosystem.