30 Days in the Shoes of an Umbraco Package Developer: What I Learned

Hold up, we're already nine months into the year... Where did the time go?! There sure has been a lot going on in the last couple of months, and what better way to reflect on what's been going on than by writing a blog post like I'm talking to myself in the third person! πŸ‚

A New Chapter

Let's start at the beginning of what happened prior to 30 days ago. Most of you may have already heard the news that I've started a new position at a new organization, hence the title of this blog! Instead of focusing on building platforms using the Umbraco CMS, I have taken on the challenge to shape & develop the all-in-one marketing suite for Umbraco, uMarketingSuite! As of August first I'm their new Lead Developer, where together we try and make the world of Umbraco better, each and every step along the way! 😊

But let me tell you, being on the other side of the platform, building on-top/for the Umbraco CMS instead of using it to build a website sure comes with a lot of challenges, hurdles and learnings! I am no expert by any definition, but as someone who has always held dear to the saying "You don't have to be an expert for someone to learn something from you", I would love to share my experiences with you every step along the way!

Framework Multi-Targeting

One of the first things I had to get used to is that with a platform/package like uMarketingSuite you are no longer targeting just a single version of .NET. Where normally you would either build a platform on-top of Umbraco 8 which would target .NET Framework, or Umbraco 10 and above which would target .NET 5/6/7+, I now had to get used to targeting all versions of Umbraco... at the same time!

That's right! While things may change in the future, each and every version & feature of uMarketingSuite that's been released has been made compatible with all versions of Umbraco between v8 to v12! I knew beforehand that there were such things as C# preprocessor directives, but this is a whole different story! You might have stumbled upon one of these preprocessor directives before, something like "#if DEBUG ... #endif", being instructions that are processed by the compiler only under a specific condition. They are quite powerful if done right, because they also allow you to create specific statements depending on which .NET SDK you are targeting, like NET472, NETFRAMEWORK, NET5_0, or NET5_0_OR_GREATER, just to give some examples. Because of this, you could create classes that compile specific sections of code, or import specific using statements, only when being compiled to a specific version of said framework!

AngularJS

I'll admit it, when it comes to code I get excited about C#, but when creating packages for Umbraco v8 through v13 there is this thing... this realm that I as a mere mortal didn't dare touch... and it's name is AngularJS!😱

Okay maybe I am exaggerating a little bit, because at the end of the day as a software engineer, our job is to resolve problems and create solutions, no matter the tools or languages used. This one is next-level though! Sure I've dabbled in the world of Javascript before, but for a tool like this, we're not talking about a Javascript file... there are hundreds! While scary at first, I can't be anything less than impressed. Hundreds of features, controllers, services, endpoints, package.manifest files, and variables come together to form a brilliant set of dashboards to be used in the Umbraco back-office! I've been learning a lot about the way you can structure and re-use AngularJS components, how to inject and separate services, conditional rendering and updating, and so much more... definitely a learning process! πŸ“–

Umbraco Pipelines & Lifecycles

When working on a package that does a lot of things based on visitor behavior, you immediately start learning about the way Umbraco handles requests. Some things are .NET based like Middlewares, Environments, Providers and Contexts, other things are Umbraco's own like Composers, Umbraco Controllers and NotificationHandlers. Together they form a powerful tool-set to fully customize the end-users experience allowing you to extend or override pretty much any behavior that would normally be considered impossible! πŸ› οΈ

From Class Library to NuGet Package

Being able to run something locally is all fun and games, but we need to be able to distribute the libraries in the form of a NuGet package in order to make it use-able to the public! A process I may have touched once or twice in the past, but now we're doing it on a commercial level! I can't go into the full details of how this is done, but using a set of very specific Dotnet Pack command configurations surely helps out! Packages your Class Libraries into usable .Nupkg files to be ready and shipped to a NuGet feed near you!

Never stop learning

My journey as a package developer has only just began, and even within just 30 days I've become to deeply admire (even more) those who've been doing this for a very long time, inspirations like Lee Kelleher (Contentment) & Matt Brailsford (Umbraco Commerce) just to name a few! I'm looking forward to learning even more along this journey as a Lead Developer for a commercial Umbraco package, and being able to share my learnings in whichever way I can along the way to the Umbraco Community! β™₯️

If you've made it all the way to the bottom, I would like to thank you for your interest, and if there is anything I've mentioned that you'd like to learn more about feel free to contact me over at my socials available at the Contact page, of which I may expand on in a future blog! 😊