Posts in "Rovani in C♯"

Build A Shopify App Tutorial

Shopify has a really good tutorial on building a Shopify App using Node.js and React. It includes the initial node and 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 of steps adapts the tutorial from Shopify and add some more steps to get an app deployed on Azure.

Tutorial last updated .

  • Auth0 Progressive Profiling Proof-of-Concept

    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.

    Progressive Profiling Proof-of-Concept form
    Are you jealous of my awesome styling? It's ok, I am, too.
  • Authenticate Shopify Customers with Auth0

    What better way to follow up from the last two posts by combining the concepts. In “This week at BlueBolt”, I present my solution for utilizing Auth0 to authenticate a user and then pass them back to Shopify utilizing the Multipass feature.

    Leeloo Dallas Auth0 Multipass
    Leeloo Dallas Multi PassThe Fifth Element (1997)

    The primary steps involved in this process include:

  • Using SAML 2.0 with Auth0 to Authenticate Users in TalentLMS

    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 Multipass in .NET Core 3.0

    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.

    Leeloo Dallas Auth0 Multipass
    Leeloo Dallas Multi PassThe Fifth Element (1997)

    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.

  • First Week at BlueBolt Solutions

    BlueBolt Solutions

    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.

  • Assessment Final Notes

    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.

  • Adding Create Functionality

    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.

  • Adding Delete Functionality

    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?

  • Requirements and First Pass

    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.

  • My Time at _The Fellowship_

    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.

  • I Made a Logo

    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.

  • Stumbling Into Design Patterns

    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).

  • Commit 8c41b3dc: Vigil Base Solution

    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.

  • Commit 69a7825e: Letting Users Get Ahead Of Me

    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.

  • Commit bccg1aea: Preemptively Structuring the Chaos

    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.

  • Commit 4b684657: Laying the Foundation

    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.

  • Commit 527fabb8: Vigil.Data Solution and Initial Projects

    After several false starts, the convention for how to organize a solution seems to have come together. This also includes how to change the default project settings, and how to keep everything tidy as the software grows.

  • Recurring Gifts — Part 1: Database Schema

    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:

  • Naming the Patron Object

    There are only two hard things in Computer Science: cache invalidation and naming things.

    • Phil Karlton
  • KnockoutJS Tutorials Suck (But Not As Much As the Documentation)

    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.

  • All I Wanted Was an Integer Primary Key

    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.

  • Establishing KnockoutJs Design Patterns

    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.

  • Just Because It's On the Microsoft Stack Doesn't Mean It's Closed Source

    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.