As the new year starts, so does a good time for a new set of goals. Having recently transferred from the delivery side of BlueBolt to the sales side (in a Sales Engineering capacity), I bring into the new year an ability to focus a lot more on my personal brand. It seems that year after year, I strive to write more; and damnit, this year I’m going to!
Posts in "Rovani in C♯"
Another year has come and gone, and it’s another year with lofty goals that fell well short of what I had hoped. This seems to be a common theme at the end of each calendar. There’s probably a lesson to be learned there, though I doubt I’ll carry that into the new year. I have already started thinking about what I want to accomplish in 2021, which makes it tough to look back and see what this last year was. I have found, though, that these posts have become a journal of sorts. I occasionally go back and reread my chronicles from years past, just to remind myself of what it was like. Perhaps sometime in the future, my kids will read through this and see what happened while they were growing up.
Shopify has a really good tutorial on building a Shopify App using Node.js and React. It includes the initial
npm set-up. The tutorial uses
ngrok to handle allowing communication from Shopify to the local
node server. Then it gives a quick GraphQL primer, uses
Apollo to fetch data, goes through setting up Billing the Shopify store, and listening for webhooks. There is a pretty sizable leap from taking this information and getting a proof-of-concept app running.
This series takes a different route. I am going to start by creating a webhook listener in Azure Functions, published from Github; then create the code necessary to install the app; then create the code to allow updating the app’s permissions; then get into billing for the app; and finally, actually start building some real functionality.
The goal of this is to create a solid starting point, thus lowering the barrier for entry for building future apps.
After a brief stint working on other projects, it’s time for a quick pop back over to Auth0. In my previous post about integrating TalentLMS and Auth0 with SAML 2.0, I describe how to capture the user’s first and last name during the registration process. Instead, for this task we are taking the first name and last name capturing out of the user sign up and implementing it as part of what Auth0 calls Progressive Profiling. The documentation is both extremely helpful and entirely too specific to be of use. A lot of the complications with this task was been figuring out what the specific implementation that the documents describe is trying to do, and then implementing that process in a simpler or different manner.
Prior to this week, I did not know who TalentLMS is, what SAML does, and how Auth0 fits into the SSO alphabet soup. However, when a client wants something figured out, that’s what I am here to do! After pouring over documentation for both TalentLMS and for Auth0, going down several dead-end paths, and nagging a few of my coworkers to “try it again?”, I now successfully (and very delicately) have credentials collected from Auth0 logging a user into TalentLMS.
Shopify has a feature that allows an external service to automatically log a user into the store from a third-party application. This is commonly used when integrating a Shopify store with a larger website product like Wordpress, DNN, or Drupal. Shopify calls this feature “Multipass”. Of course, this means for the last two days, all I can hear in my head is “Leeloo Dallas Multipass”; but even worse than having it on repeat (in my head) is that no one else on the project gets the reference.
Now that that’s out of the way - on to the project at hand. For a client that we are working with at BlueBolt, the desire is to use Azure AD B2C as the backing authentication mechanism. The user experience is simple: the customer clicks the “Login” button, they are sent to an Azure AD B2C login form, then redirected back to the Shopify store. However, as we all know, nothing is as easy as it seems.
After nearly 7 years of full-time employment with IFCJ (and five years prior to that of part-time consulting work), I have chosen to move to other opportunities and challenges. This presented itself in the form of an offer from BlueBolt Solutions to join their team as a Senior Solutions Architect. My primary duties will consist of being a technical lead across several projects of varying size, architecting and scaffolding solutions, work with the project managers to ensure timely delivery of the completed project, and mentor junior/mid-level developers as they work on the project.
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.
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.
The last time I had an introspective post was in my sign-off to 2017 post. As I’m flying from Chicago to Toronto on a work trip, I felt inspired to write another piece. During the summer I came to the realization that I’ve reached the end of the growth that I can gain at The Fellowship, and that it is time for the next phase in my career. Over the last ten years, I have found what I am passionate about and now I need to find the right company with the culture that can support those passions and where we will have a mutually beneficial relationship.
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.