DEV Community: Alex Dhaenens

Building our own Salesforce SFMC integration with Sitecore Forms

Alex Dhaenens — Wed, 30 Sep 2020 10:06:50 +0000

Some time ago, our Marketing team asked if it was possible to integrate a Sitecore website with Salesforce SFMC. More specifically, they asked if they could add data submitted by some Sitecore Forms to Salesforce Marketing Cloud’s data extensions.
At that time, Sitecore had already several connectors for integrating xDB and the Media Library with SFMC, but no solution specifically for Sitecore Forms. We looked at the possibility to integrate it with Salesforce open APIs.

The force is strong with Salesforce

Before continuing further, let me briefly talk about Salesforce, so readers that are not familiar with it understand what I’m talking about.

Salesforce is a big platform offering quite a lot of SaaS solutions like CRM, Marketing Automation, e-Commerce, etc… In this post I’ll be talking specifically about Salesforce Marketing Cloud, used by marketers. In this software there is something called Data Extensions and is similar to database tables. Each Data Extension has a name and different columns, containing data that can be used in marketing automation workflows. Each DE (data extension) column has a name, a type and several other properties. Records can be added, edited or deleted from a DE.

Start of a journey

Although it seemed quite simple at first, the journey wasn’t. Obviously the first thing we did, was to do a little research on what we could use. Firstly we landed on the Salesforce docs and found out that Salesforce offers an extensive soap and rest API. This definitely offered all the features we required four our project, but as developers we did not want to reinvent the wheel and wanted to see around on the internet if there were some nuget packages available that we could use. That way, we don’t have to write any DAO (data access object) code handling the parsing of the api request data. This was the time we arrived at the fuelSDK, a nuget package that is available under the MIT license.

FuelSdk, our savior?

After we found the package, we tested it out, to see if it delivered what we needed. Setting up the package was fairly easy as you just needed to install the package using nuget. The only additional thing developers need to do is to add some configuration to your project’s web config. The configuration exists mostly of api keys and instance urls and looks something like this:

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="fuelSDK" type="FuelSDK.FuelSDKConfigurationSection, FuelSDK" />
  </configSections>
  <fuelSDK
    appSignature="none"
    clientId="YOUR_CLIENT_ID"
    clientSecret="YOUR_CLIENT_SECRET"
    authEndPoint="YOUR_AUTH_TSE"
    restEndPoint="YOUR_REST_TSE"
    useOAuth2Authentication="true" 
    applicationType="server"||"public"||"web" //if you are using oauth2 for public or web app. By default, this will be "server" 
    authorizationCode="AUTHORIZATION_CODE"
    redirectURI="REDIRECT_URI_FOR_PUBLIC/WEB_APP"
    accountId="TARGET_ACCOUNT_ID"
    scope="DATA_ACCESS_PERMISSIONS" />
</configuration>

When the configuration is done, you could simply add data to data extensions using this piece of code:

var deRow = new ETDataExtensionRow {
                    AuthStub = client,
                    DataExtensionName = dataExtensionName,
                };

deRow.ColumnValues.Add("CustomerNumber", "Customer_" + i.ToString());
deRow.ColumnValues.Add("FirstName", "FirstName_" + i.ToString());
deRow.ColumnValues.Add("LastName", "LastName_" + i.ToString());

var derResponse = deRow.Post();
Assert.AreEqual(derResponse.Code, 200);

In this piece of code, we are adding values to a dictionary where each entry has as key the column name of the data extension’s column. This is the column we’ll be inserting this data into. The values of the dictionary entries are the actual (string based) data that we’ll be adding.

So, in order, to reach our goal, which is to add the data from a (Sitecore) form submit to a SFMC Data Extension, we’ll need a Save Action that executes the code above, but adjusted for that specific form and data extension. This means that the keys of the dictionary must be the right column names (no typos allowed!) and that the values should be the value of the right submitted form field. Although it is remarkable easy to use, it is not a silver bullet.

Adding more fuel

The first issue, as you may notice, is that although adding this to a single form is easy and fast, adding this to multiple forms isn’t. This is because the shared code can’t be abstracted away. You’ll still need to build that dictionary with the right keys and values (typos not allowed) for each form. Apart from development time you must also consider the fact that this must be tested for each form on each environment which increases the cost a lot. On a side note, it might also take a while between the marketer or client asking for such a form submit action and the moment it is deployed and working on production. This is because you’ll need to follow the full software development cycle (build, test , release).

The second issue is that it is error prone. If a typo would slip in the code, especially the part of the dictionary (the column names and the field names to be more specific) you can experience massive delays. Not only that , you aren’t guaranteed that the code will work on different environments, as exactly (and when I mean exactly, I mean including the names of the fields) the same forms are a must on each environment and that is something that is not possible in many cases.

The last issue is that the above code is not future proof: as soon as a data extension changes it won’t work and neither will it work in the case of a form change (renaming or removing fields). Also, every time you need a change (e.g. a form must change etc) you’ll need to adjust the code to cope with the change and redeploy and test it on all environments.

For those reasons and because Sitecore is such an open platform that can be easily extended, we’ve decided to experiment with our own Forms extension module. The idea is to build a Sitecore integrated application that does not require any coding nor deploys, is movable between environments and is easily adjustable in Sitecore for non tech savvy users. We will add soon the result of our experiments as a module for the Sitecore community.

If you are not sure that the module is something for you, I’ll be discussing the many features it brings to the users and developers in my future blogposts!

SFMC and its many features

Alex Dhaenens — Thu, 24 Sep 2020 16:21:08 +0000

In one of my previous blogposts I discussed why we made our own SFMC Forms extension module based on Salesforce open APIs, a module to make moving data from Sitecore forms to Salesforce Marketing Cloud easier. Feel free to read the blogpost, if you haven’t already.

At this instant, we are also very happy to announce that the module is released to the public for free and can be downloaded from the git repository. In this blogpost we would like to talk about the many features of the module. During this writing, we’ll be using the terms developer and content editor. The developer is the person that develops the Sitecore website and therefor also needs to install the module. On the other hand, the content editor denotes either somebody for marketing or the person that is creating content on the Sitecore instance.

The easy setup

In order to get your data from Sitecore forms to Salesforce Marketing Cloud, both the developer and content editor need to do several things.

First of all, the developer needs to download and install the module on the Sitecore instance. After that (s)he needs add some configuration to the web.config. This is the configuration required by FuelSDK and consists of api endpoints and keys. It looks something like this:

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="fuelSDK" type="FuelSDK.FuelSDKConfigurationSection, FuelSDK" />
  </configSections>
  <fuelSDK
    appSignature="none"
    clientId="YOUR_CLIENT_ID"
    clientSecret="YOUR_CLIENT_SECRET"
    authEndPoint="YOUR_AUTH_TSE"
    restEndPoint="YOUR_REST_TSE"
    useOAuth2Authentication="true" 
    applicationType="server"||"public"||"web" //if you are using oauth2 for public or web app. By default, this will be "server" 
    authorizationCode="AUTHORIZATION_CODE"
    redirectURI="REDIRECT_URI_FOR_PUBLIC/WEB_APP"
    accountId="TARGET_ACCOUNT_ID"
    scope="DATA_ACCESS_PERMISSIONS" />
</configuration>

Whenever this configuration is added to the web.config, the module is ready to use. This is the moment where the developer’s job is done (yes for real!) and (s)he can continue working on other exciting stuff.

This is also the moment that the content editor’s work begins. First of all (s)he needs to add the ”Send to SFMC” to the form that needs to send its data to SFMC. The next step is to create a binding between a form and a data extension to then publish it. This can be done by the handcrafted SFMC save actions dashboard application.

A Sitecore integrated UI

When a content editor wants to create or edit an SFMC binding, (s)he can open the dashboard application in Sitecore. When the application is opened it will display a UI showing a list of configured bindings. This looks like this:

As you can clearly see, this is a very intuitive UI fully integrated inside Sitecore and therefor the content editor will use the same UX experience as other standard Sitecore modules.

This page has several buttons, to create, update, publish or delete a binding. If a CE (content editor) creates or updates a binding, a page like this will be displayed:

Again, this UI is very intuitive and has a full Sitecore look and feel.

Fully fetched data

When creating or editing a binding, you’ll see just as in the image above, that all the data that needs to be used is fetched either from Sitecore or Salesforce. That data is then displayed in a drop down. This serves several purposes, firstly no names and ids need to be remembered and therefor mistakes and typos can’t be made. This also greatly increases speed.

There are several things a CE needs to choose for each binding, firstly the form the data is coming from as well as the data extension the data is going to. This can be done with the beforementioned dropdowns. When those two are chosen, a CE can choose to trigger an event in SFMC.

As soon as a form and a DE (data extension) are chosen, the UI will fetch respectively the form fields as well as the data extension columns. Those will be displayed in the UI as well. For each DE column, a row will be shown with the name as well as a dropdown with different fields to choose from (including the fetched form fields).

Lots of fields to choose from

As soon as the UI is loaded with the DE columns and form fields a CE can choose for each DE column a field. Those so-called fields are displayed in a dropdown. There are many fields to choose from and because there are so many, we’ve grouped them in different categories.:

The first group, “form fields” consist of all the fields from the form. When such a field is picked, the value that the website user provided for that field will be send to SFMC. Another group is the “calculated fields” group. This group consist of different values that do not originate from a form such as the website language, a random GUID or timestamp and many more. The last two groups are groups for xdb related data.

Migrating configuration

As soon as you save a new binding an item will be created in the master database in Sitecore. Whenever you are ready to go live with the binding, you can publish either the item in the Sitecore tree or use the publish button in the dashboard application.

Since all the bindings are Sitecore items, you can migrate bindings between different environments by simply packaging those items and installing them on the desired environment. This also means that you do not need to recycle, nor do you need to redeploy anything when migrating data.

Conclusion

As you can clearly see, this module is easy to install and to use. It was such a cool experience to develop this module using Sitecore and Salesforce APIs that we made it available to the community. So feel free to use it!

How to execute shell commands in js

Alex Dhaenens — Wed, 26 Aug 2020 10:06:00 +0000

For one of my side projects, I needed to be able to execute certain shell commands with JavaScript. That project is an Electron–React project, in which – thanks to the Electron framework – I have full access to the Node.js API and therefor the Node.js runtime. For the readers that are interested in Electron or in combining Electron and React you can find my blogs on those topics respectively here and here.
Although it is possible to execute shell commands in JavaScript, there are two important remarks: first that executing shell commands uses the Node.js API, so be aware that it only works in an environment that has access to that API (meaning a normal browser runtime won’t work). Secondly, some shell commands require administration permissions, so in those cases you’ll need to make sure that the process running your JavaScript code has such permissions.

The API

The Node.js API has a module called child_process that offers functions to spawn child processes both in ansynchronous as asynchronous manner. One of those functions that are available is the exec function. It has the following signature:

exec(command[, options][, callback])

With the parameters: command as a string, options as an object with various options (see the documentation for more information) and a callback function. The function itself returns a reference to the spawned process (but it is not needed for executing shell commands).

With the exec function we can create a custom function with two different callbacks:

const { exec } = require('child_process');

export const executeCommand = (cmd, successCallback, errorCallback) => {
  exec(cmd, (error, stdout, stderr) => {
    if (error) {
     // console.log(`error: ${error.message}`);
      if (errorCallback) {
        errorCallback(error.message);
      }
      return;
    }
    if (stderr) {
      //console.log(`stderr: ${stderr}`);
      if (errorCallback) {
        errorCallback(stderr);
      }
      return;
    }
    //console.log(`stdout: ${stdout}`);
    if (successCallback) {
      successCallback(stdout);
    }
  });
};

Although not required, using such a function is much handier and cleaner as you can use a different callback functions for success and error. In addition, there is a single point where you can turn on or off logging for all your commands.

Creating command functions

Since we got our base function for executing commands we can create now different functions for the different commands the code needs to execute. Depending which operating system you are targeting, it can be possible that other (shell)commands are needed (e.g. the dir command on windows and the ls command on linux). For the sake of an example you can get the current git branch with the following git command:

git -C “folder” rev-parse --abbrev-ref HEAD

We can create a custom function for this, accepting a folder and two callbacks to execute:

export const getGitBranchCommand = (folder, success, error) => {
  executeCommand(
    `git -C ${folder} rev-parse --abbrev-ref HEAD`,
    branch => success(branch),
    errormsg => error(errormsg)
  );
};

This functino will either call the success callback with the output of the shell command (which is the branch name) or call the error callback with the message the command returned when failing.

Some shell commands print a lot of text to the stout stream, so for those commands you’ll need to apply a regex to parse the data you want from that output.

Combining with state frameworks

A lot of applications use a state framework to keep the current state of your app. Chances are that you, the reader, use such a framework in your project and you’ll want to store the result of the commands you executed in that state. In my example I’m using Redux but you can follow a similar approach for other frameworks.
By using the getGitBranchCommand shown above you can create a new function specific for the Redux framework:

export const getGitBranch = (folder, dispatch) => {
  getGitBranchCommand(folder, branch =>
    dispatch(setFocusProjectGitBranch(branch), () => {})
  );
};

Now you have a function that accepts a folder and the dispatch function (needed for dispatching actions in redux). This function can now be used anywhere in your application. In the code snippet above I’ve used the setFocusProjectGitBranch function, which is an action creator (if you don't know what that is, no worries it is Redux specific). Also, on a side node, the error callback is an empty function since I don’t need the error message (yet).

Architecture summary

I would like to summarize the blogpost by discussing the architecture used:

getGitBranch(folder,dispatch) 
=> getGitBranchCommand(folder, success, error) 
=> executeCommand(cmd, successCallback, errorCallback) 
=> exec(command[, options][, callback])

The executeCommand is a general function for executing any command using the exec function from the child_processes node module. That function is used by the getGitBranchCommand, a function specific designed for getting the git branch. Lastly the highest function, is the one exposed to my whole application and is a state management framework dependent function. It executes the earlier mentioned getGitBranchCommand function and stores the result in the state, by using the state management’s api.

Using this architecture has the benefit that, when you would reuse the code in another project but with another state management framework, you only need to replace the getGitBranch function. Additionally, if you would for example support other operating systems, which could require different commands to do the same thing, you’ll only need to replace the getGitBranchCommand function.

How to pass rendering parameters from Sitecore to React

Alex Dhaenens — Wed, 05 Aug 2020 10:01:21 +0000

For some of your projects you’ll probably have a Sitecore component with a React app. Such a component normally doesn't have much logic inside your controller action, since this component only renders a container (div) element. There might also be a script tag in your view, with your React application script, but this depends on your setup. This is often the only job your Sitecore component has to do, because all the rest is handled in the front-end.
Such components make it possible to create advanced components that are a hassle to do in the backend while still making the application user-friendly. However, by using this approach some features of the Sitecore framework are lost: passing rendering parameters, personalization ,...

Why do you want it?

Rendering parameters of a Sitecore component offer a great way to change the presentation and/or functionality of a certain component by adjusting those parameters. Sitecore also made it pretty easy to create custom rendering parameters, a topic that has a lot of blogposts covering it. For that reason explaining on how to do it is out of scope of this blogpost.

Personalization is a big feature in Sitecore that enables the content editors to create rules to e.g. hide or show components, adjust the datasource,... Rendering parameters can be used in combination with personalization: by adding a certain component twice with different rendering parameter values and then hide or show the components with personalization rules.

Using those rendering parameters in the back-end is fairly easy. The only issue rises when you want to pass them to your React based Sitecore component. One could create an api to pass them, but you don't want to introduce additional latency and the parameter values should already be known when the app starts.

Passing the parameters: backend

The key to passing the rendering parameters is the html data attribute. The idea is quite simple: you add your rendering parameters as data attributes to the container (div) inside your (Razor) view and let your React application read them when the app starts.

In order to do this you’ll need to pass the parameters you require from your controller action to your view by using the view model, this is pretty straight forward. Then you’ll pass those parameters as follows:

<div
    class=”reactapp1”
    data-renderingparameter1=”value1”
    data-renderingparameter2=”value2”
/>

You can freely choose a name for your data attribute but,
as this is the HTML specification, there are two rules you need to follow:
1) A prefix of “data-“
2) No uppercase letters

Reading the parameters: front end

The next step is to read them in your React application when it starts and (preferably) store them in state. Reading them is quite easy! You just need to add following code to your application’s entry point, which is the js file where the ReactDOM.render is used to render your application into your container div. You can read the data attributes like this:

const renderingparams = {
  renderingparameter1: container.dataset.renderingparameter1,
  renderingparameter2: container.dataset.renderingparameter2,
 };

The container variable in the above code example denotes a variable holding a reference to your container DOM element. You should already have such a variable since you need it for rendering your app with ReactDOM.render. If you are passing data types other then strings you might want to parse them first. You can do this for respectively booleans and numbers like this:

    container.dataset.renderingparameter1 === ‘True’
    parseInt container.dataset.renderingparameter1, 10)

You might also want to consider using a default value when a data attribute can’t be found or parsed.

The next step is to pass them to your application as prop for example like this:

<App renderingparams={renderingparams} ..>
…
</App>

Your rendering parameters are now fully available inside your React application. I would recommend saving those parameters in your app state (by for example using context, Redux, Mobx) so you can access them everywhere that is needed without passing them as props. As this is application dependent, I’ll leave this task up to the developer.

Personalization

When you have the aforementioned structure in place, you can now personalize the component by adjusting the rendering parameters. Additionally, you can also pass personalization data to your React applications: by using the data attributes to pass xconnect data to your app.

React Summit Amsterdam, my takeaways

Alex Dhaenens — Thu, 14 May 2020 11:22:57 +0000

A small month ago, a major React conference would have taken place in Amsterdam: React Summit Amsterdam. This would’ve been my very first conference in my professional life I would’ve attended. But, as you can guess, due to the global pandemic it was cancelled. Luckily to us, the organizers did a great job and hosted a virtual event at that same date the real event would have been hosted. Aside from that, a replacement conference will be held in September (if all goes well).

In the virtual event many different speakers did discuss many different topics, a full list of the speakers can be found here. The event was livestreamed on Youtube, meaning that I could attend the summit from the comfort of my pj’s and sofa. At the moment of writing, some time to reflect has passed and I can now say what really kept hanging in my brain. There are four talks that really stayed: The Mystery talk by Guillermo Rauch, Controlling apps by Vladimir Novick, AHA programming by Kent C. Dodds & React Query by Tanner Linsey.

Mystery Talk – Guillermo Rauch

Guillermo, from the company Zeit.now, started his talk about speed of websites and webapplications. His point was that at the end, static sites are still the fastest sites, since no time is needed for the backend to render the page. Then he continued by talking about JAM stack (https://jamstack.org/), which is a new way of building web sites & - applications. The general idea is to prerender sites (to static html’s) and enhance them with Javascript and API’s. He then concluded his talk with talking about his company, Zeit.now. Aside from obviously promoting the company, he explained that the idea he discussed earlier is actually what the company does, combined with a CI/CD.

I was quite impressed by the structure of his talk (starting with something seemingly random and then building up) combined the passion with he was talking.

Controlling apps - Vladimir Novick

Vladimir started his talk with the brain and its magnificence. He followed his introduction with talking about brain waves & how you can measure them: using those headsets with nods that measure activity at some points on your skull. He then showed that more consumer friendly and less complicated Bluetooth headsets (for measuring brain activity) are available at a reasonable price. Since the modern browsers do have a Bluetooth API available to the developers, he reasoned, you could control your website or application with your brain. This can be done by using the Bluetooth API to read values from the headset. He then put his money where his mouth was by showing a demo. In that demo, he was interacting (scrolling, …) with a page with his brain. Lastly, he went a step further to integrating the headset with a drone, so he could fly a drone with his brain.

I did have to say that it was a very impressing talk in the perspective of future technologies and what is possible right now. It was just quite annoying that he had a poor internet connection and a lot of lagging occurred.

AHA programming – Kent C. Dodds

This talk started by showing the attendees a piece of code, written in Javascript. It contained a function and certain places that that function is used. Kent stated that most of the time code starts like this: clean and great code. But as time and the development progresses, the need arises for a similar function.

Just as all developers have learned, abstraction is the way to go, so Kent added some additional parameters in his function. In his function he then uses an if structure to alter the behavior of the function based on that additional parameter. This way, he told, all the code is reused and the if is then used for the small differences. Again, after some time, he deducted, a new developer starts working on the project and the same time the need for again something similar rises. Obviously, the new developer sees the function and adds another parameter to that function for abstraction purposes.

Although it still worked, Kent pleaded, this piece of code now introduces many issues: First one, by adding parameters the developers created additional test cases. But to make those tests good all possible combinations of those parameters need to be tested and only very few combinations are used. The next issue Kent pointed was that this piece of code will never be altered, because every time something must change the dev will only add lines to that function. This is because the high complexity and nobody know what and where it is used. The last issue the talked about was that the clean code had become a weird piece of spaghetti code.

Kent offered a solution to this with a quote:

Code duplication over lousy abstraction

Which summarizes the ideology that it is not bad to have some duplicated code, because making lousy abstractions is worse. Although abstraction is very important, you should first duplicate the code and adjust it accordingly to the place it is needed and then abstract the common pieces. Most of the time you’ll find out that only very few things are common.

I do have to say that really liked this talk, as it was very clear framework agnostic and very well put together.

React Query - Tanner Linsey

This talk started with a small application, that had some state and some API’s for fetching some data. Tanner used that simple application to show the idea of managing the data querying using React Query (especially the hook). He did this by adjusting the small application and explaining it accordingly.

After this talk, I really had the feeling that this could help me out a lot although I don’t remember a lot of technical details.

Conclusion

Although a remote, virtual conference is different than a real one, it still is a great solution for the quarantine problem. But it only works if the both the attendees and the speakers have a good internet connection. After the couple weeks that past, only a very few things kept hanging in my brain: JAMstack with Zeit.now, you can use brainwaves in your (web) applications, Ken’s ideology “Code duplication over lousy abstraction” and lastly React Query for managing data querying.

Electron and React, a successful marriage?

Alex Dhaenens — Thu, 16 Apr 2020 10:08:22 +0000

In one of my previous posts, I talked (or rather wrote) about a framework called Electron, which offers the possibility to create cross-platform desktop applications with HTML, CSS and JavaScript. As soon I saw it, I had to try it out! The first thing I asked myself, though, after I created my first Electron app was: since Electron displays web pages can I use other JavaScript frameworks (such as React) to build and render my web pages? The answer is YES, and as it turns out combining both offers amazing opportunities!

Short recap

In my blogpost about Electron, I explained that Electron uses a so-called main process to display GUI’s. Each GUI renders a web page (could be an external link or an html file inside your project). Web pages are run in separate, isolated processes called renderer processes. Electron offers IPC (inter process communication) to send messages between the main & renderer processes. Another nice feature is that the full Node.js API is exposed by Electron in both the main as the renderer processes.

Enter React

Electron displays a web page inside a GUI. As a developer you must provide the link to that web page, that page is (often) a static html page inside your project folder. There you can add your React script & container and as soon as the page is displayed, your React app will start. Your React application runs therefor in the renderer process. This is also the same if you would use any other framework (e.g. angular).

As I discussed in the recap, you can communicate between the main and renderer process(es). This provides the developers & software engineers with endless possibilities, since your React runs in that renderer process. For example, you can create a menu in the native window (runs in the main process) and when a certain menu item is clicked, the React app (runs in the renderer process) navigates to a certain page. This is done by using the IPC to send a message from the main process to the renderer process, telling which page to go to. This is amazing!

Because Electron makes it possible to use the full Node.js API in both the main as renderer process, it is possible to let React use the Node.js API. This also provides amazing opportunities, since your React app can now use any Node module. This opens many, many doors: making the React app executing bash scripts on the user's computer, reading from or writing to the user's filesystem, ...

Tons of boilerplates

Although setting up a brand-new Electron-React project is not that much work, there are however a lot of things that developers might require or desire for each project: hot reloading, linting and the usage of certain plugins. Setting those up for each project can be cumbersome and time consuming. Luckily for us, there are amazing boilerplates out there for an Electron-React project. The Electron documentation contains a list of recommended ones. Most of those boilerplates are open source so,you can help them improve if you would like.

My opinion

In my free time I’m currently building an Electron-React application and so far, I’ve liked combining them very much. Although initially it was a challenge to figure out how Electron works, especially in combination with React. I’ve used a boilerplate that has all the features I require for developing (hot reloading, linting, Sass compiler, …) so I did not have to set them up myself. In my experience it is a fast way of developing desktop applications.

There is also another, less obvious benefit: you can actually create a React application and host it online but also build a desktop version with the same source code by using Electron. You don’t have to rewrite anything, only setting up the Electron-React project might take some time. The same React application code can be used without any modifications. You can even go further, you could add additional desktop specific features (adding a menu,…) or change the behavior on desktop (saving user preferences,…) with the same code. Since this uses Electron, it is important to note that the performance issues introduced by Electron will also rise here. Therefor, picking the right technologies for a project is still an important task that must be done before starting.

Electron, the future?

Alex Dhaenens — Fri, 10 Apr 2020 11:02:16 +0000

For some time, I've been hearing things about the Electron framework. It always sounded interesting, but the moment I heard that Visual Studio Code is actually an Electron application, it really took my attention. So, it speaks for itself that I wanted to try it out!

What is it?

According to their site, with Electron you can Build cross-platform desktop apps with JavaScript, HTML, and CSS. And that fully summarizes what it does. Electron does this by combining Chromium & node into a single runtime. It also provides extensive documentation on how to start & use their API's.

What Electron does is create a native window that loads a certain HTML page, where you can unleash the full power of HTML, CSS and JavaScript. Because this is actually a web page and the framework uses Chromium, it can display the full blown dev tools (like you are used to in Chrome), and when I say full blown, I mean you can do everything you can do in the normal dev tools. As you can clearly see that is very useful!

The basics

One of the core concepts in Electron is the principle of the main and the renderer processes. The main process is the process that runs a script which display GUI's (where each GUI renders a web page). There can only be one main process! Each web page then runs in a separate process, called renderer processes. This means that if you have multiple web pages concurrently running in your Electron app, multiple renderer processes are running as well.

There is a significant difference between the main & renderer processes. The renderer process only manages the web page it displays and is fully isolated. The main process however manages the renderer processes.

Electron also provides IPC (inter process communication) so the main process can communicate with renderer processes and vice versa by sending messages. This opens many doors, especially since it is inherently unsafe to call native GUI’s from web pages. You can use the IPC to send the message from the web page (running a renderer process) to the main process, which can call native GUI’s.

As Electron runs on Node.js, it also provides full access to the Node.js API, meaning you can use all your npm packages! And the breath-taking thing here is that the full Node.js API is exposed to both the main as renderer processes. This means that you can for example create or delete files, read them or write to them directly from your web page!

Boilerplates and CLI’s

Electron does not provide one way to build, create or package your Electron apps. Instead it uses a rather modularized approach: different tools & cli’s do different tasks and it is up to the developer to pick the preferred ones and combine them into a pipeline that fits his or her needs. Electron’s documentation also lists recommended cli’s for different tasks.

On the other hand, it is also possible to use a boilerplate. This is a prefabricated, clean project where everything is already setup and ready to use. Most of the time they are repositories where you clone or copy the code. Since a boilerplate is a ready-to-use project, developers can freely remove or add things (frameworks, tools, …) from or to the project. For example, if a boilerplate uses a certain framework they don’t like, they can just remove it. Boilerplates are rather a starting point for a project and are very great for developers that require certain features (hot reloading, …) in their dev environment and they don’t want to waste time setting those up. Electron provides also a list of different recommended boilerplates.

Concerns

For the moment, my only concern is the performance especially compared to a compiled application. I didn’t see any issues nor did I have experienced some in my current Electron apps, but I do think that there will be for apps that do require a (very) high performance. But since performance is a very important topic, the documentation of Electron dedicated a full page to fixing performance if you would have any issues.

Conclusion

At the time of writing I do think that there is a big future in Electron as it opens many doors to write apps on different platforms really, really fast! But I'm a bit reserved with the performance, but this should not be an issue with the gross of the applications. What are your thoughts?

My first hackathon takeaways

Alex Dhaenens — Tue, 10 Mar 2020 10:53:12 +0000

Earlier this month I did, for the first time in my life, a hackathon and I liked it! The one I did participate in was the Sitecore hackathon 2020. Although I did not expect it, I did learn a lot. What is more surprising, is that I learned more non-technical than technical things.

The hackathon

The Sitecore Hackathon 2020 had the following setup: The organizers would release a couple categories at midnight. From that point in time you had 24h to fully create something in one of the categories. The deliverables should include: A package for installation, an extensive installation manual, documentation and a demo. Each team received a (public) git repo to push your code into.

What I learned

Besides from technical stuff and things about myself, this is what I've learned during this hackathon.

24h is long, very long

24h is a lot of time especially when you are coding almost non-stop. What I noticed is that I needed some breaks, both mental and physical. What I've also noticed that I was tired at the end, so my mood wasn't exactly ecstatic. The last thing I noticed is that the quality of my code lowered at the end. So perhaps it is not a great idea to code non stop for a longer periods of time (or even worse, for multiple days) especially if you need to deliver a high quality, production ready, product.

24h is short, very short

On the other hand, I've also noticed that 24h doesn't give you that much time to deliver something amazing! From the 24h you need to at least extract 2h for testing, writing docs, capturing a demo,.... Then you need to extract at least 2-3h for breaks and eating, since your brain and body do require it. Then you'll also need to remove at least 1h-2h of brainstorming time, since you and the team need to think about what to build. This leaves maximum 17h of time to actually code and that is not much! And before you know it the deadline is there! I think that the same can be said over sprints, although they are between 2 weeks and a month long, you still are timeboxed and you can't work the whole sprint every second of your working day on the product (you still would have meetings, coffee & toilet breaks).

A good mvp is key

In the limited time you have, I've noticed that you need a good basic mvp (e.g. the basic site) as fast as possible so then there is time later on for more advanced, fancy & buzz killing features. This is because a solution with fancy features but that does not have the basics working won't get you there. Don't get me wrong, you need the fancy features to win or at least stand out but your basics should work. Therefor, I believe, the focus should be to deliver a mvp fast to spend the remainder of the time on the fancy features. I also think that a parallel can be drawn to the real world: a good product has fancy stuff but has the basics working!

Build the mvp on expertise

As I explained earlier you need a good working mvp and some great fancy killer features. Because you need the mvp first before the fancy features, you need it ready asap. The best way to do this, is to decide to build it in your field expertise. This means that (almost) no risk is involved and therefor the mvp can be delivered on time. For example, if your team's expertise is building React SPA (single page applications), it would be a great benefit to build the mvp in React as a SPA. Since your team does this all day, it wouldn't take long to deliver something mvp worthy fast and without any risks.

Do risky stuff, but at the end

Then when you have an mvp, you can go wild on the fancy stuff, e.g. machine learning etc. This is a great opportunity to try something new! A great tip would be to not pick up too much and consider the risks of what you're doing (e.g. your skill or knowledge in that field).

Preparation is king

One thing that is almost a necessity is to prepare as much as you can. This means: having all the environments working, have all the tools installed and working, have your git repo up & running,... Also consider the things that are not directly needed for development, but are needed for the hackathon: video capturing software, video editing software, communication tools,... Don't underestimate this, because you don't want to browse around the internet for video capturing software 20 minutes before the deadline. I believe also that here a real-life lesson is hidden: a prepared man is worth two.

Don't spend too much time brainstorming

Although brainstorming and conceptualizing is needed, don't overspend time on this, since you also need to build it. Also when brainstorming take the limited time into account since you won't be able to build everything you want.

Stop developing on time

Don't forget that you possibly need to do other stuff than development (depending on the hackathon). So stop on time with the development work so you can capture a demo, write manuals,... because it takes some time to do that stuff. Also remember by that time, you are almost 24h awake so mistakes will be made & your productivity will be lower. Anticipate this by not starting on those tasks the last hour.

Conclusion

At then end, I can only make one conclusion: Hackathons are a great source of learning! You'll learn about new technologies, software development in general and most importantly yourself!

How to find the script that changes a html tag's attribute

Alex Dhaenens — Tue, 03 Mar 2020 13:34:37 +0000

Sometimes you have the luck that you must work on a project that is quite old an contains alot of scripts. Then, one day you are developing (or debugging) and you noticed that a certain html tag's attribute changed. You know that this is done by a script since that attribute does not have that value when viewing the source or when you look at what the backend renders. The next step is then obviously to find that script (and code line) so you can understand why it happens and, if needed fix it.

The most obvious way to find that script is to set a breakpoint the moment that attribute changed. The thing is, you can't set a breakpoint without knowing the javascript file and line number. Or can you??

As I found out recently, chrome's dev tools can actually set a breakpoint on the moment an attribute changes.

How to do it

To get straight to the point, you can you can right click on a html node and choose break on and then pick attribute modifications like this:

Chrome will add a blue dot left of the html tag:

Then, as soon as an attribute changes, the code will stop executing on the line that does the attribute changes

Additional tips

Since there are different ways in javascript to change an attribute (E.g. using jQuery, an additional js file,...) you might not end up on the code location you need to be. But on the right side of your dev tools you can see the stack trace. There you can see which function and file called the code you are currently breaking on.

How to resize images from the media library with code

Alex Dhaenens — Fri, 21 Feb 2020 11:30:51 +0000

One of the missions of a web developer is to make your sites fast & user friendly, something that can be measured by google's speed insights score. One way to do increase your score and speed is to download images in the right size instead of the ( -most of the time- way) bigger size just to then resize it using css. This obviously gives a better speed since you need to download alot less data (which is critical on mobile and low internet devices). In order to download the right size, content editors could upload the correct one to the media library. However this is, due to many reasons (e.g. reusing old images,...), not always possible.

Luckely for us, Sitecore does have this feature built in. You can resize image from the media library to any size by adding query parameters to the image's url and then adding a protective hash.

You can do this as follows in vanilla Sitecore:

string url = Sitecore.Resources.Media.MediaManager.GetMediaUrl(mediaItem);
string resizedImageSrc = HashingUtils.ProtectAssetUrl(url + $"?w={width}&h={height}")

For those of you that do use Glassmapper you can do it as follows:

string url = image.Src
string resizedImageSrc = HashingUtils.ProtectAssetUrl(url + $"?w={width}&h={height}")

Parameters

Besides from setting the width & height you can also set other query parameters:

° w: Width in pixels
° h: Height in pixels
° mw: Maximum width in pixels
° mh: Maximum height in pixels
° la: Language (defaults to context language)
° vs: Version (defaults to latest version)
° db: Database name (defaults to context database)
° bc: Background color (defaults to black, for white bc=ffffff)
° as: Allow stretch (as=1)
° sc: Scale by floating point number (sc=.25 = 25%)
° thn: Thumbnail (thn=1)
° dmc: Disable media caching, both retrieval and storage (dmc=1)

which you can just add to the query parameters.

Sources

https://community.sitecore.net/technical_blogs/b/sitecorejohn_blog/posts/media-options-and-query-string-parameters-in-the-sitecore-asp-net-cms

What the hell is property pattern matching?

Alex Dhaenens — Mon, 10 Feb 2020 11:08:58 +0000

I'vealready made some posts about pattern matching, with the last one about positional pattern matching. Pattern matching made it possible to do a type check, cast to that checked type into a variable and then deconstruct its properties into variables:

if (person is Elf(int age, string elfishName))
            {
                Console.WriteLine($"Elf with elfish name{elfishName} is {age} years old");
            }

And it made it also possible to do a value check while deconstructing:

if (person is Elf(110, string elfishName))
            {
                Console.WriteLine($"Elf with elfish name{elfishName} is 110 years old");
            }

One of the drawbacks of this technique is that a deconstructor is needed (more about that in my blogpost about object deconstructing). Luckely for us, C# 8.0 provides us with property pattern matching!

What is it?

Well property pattern matching does the same as positional pattern matching but without the need of a _Deconstructor_ . The code above, which checks if the person is an Elf then deconstructs it and checks if his/her age is 110, looks like this with property pattern matching:

if (person is Elf{ Age: 110, ElfishName: var elfishName })
            {
                Console.WriteLine($"Elf with elfish name{elfishName} is 110 years old");
            }

As you can see, the syntax is quite similar to its counterpart. The downside however, is that it is more (computationally) expensive.

Sources

https://docs.microsoft.com/en-us/dotnet/csharp/deconstruct
Demo project: https://bitbucket.org/aldhaenens/p-d-demo/src/master/

What the hell is positional pattern matching?

Alex Dhaenens — Mon, 03 Feb 2020 11:11:15 +0000

With the arrival of the brand new C# 8.0, a lot of new things are possible! One of my personal favorites is the positional pattern matching feature!
Just like my other posts about C#, I'll be using the Elf class which has two properties: Age, which is the age and ElfishName, which is the name of the elf in elfish. Before we dive into this feature, let me give you a brief refresher of some stuff you need to know in order to understand what is happening.

Background

Firsly, as you might know, in C# 7.0 there is a feature called pattern matching (if not you can read about it here). Pattern matching makes it possible to do a type check and a cast directly in one line:

if (person is Elf)

Also in c# 7.0 you can extract properties out of an object in one line. This feature is called object deconstructing (you can learn more about this here) and it looks like this:

(int age, string elfishName) = elf;

It is a nice feature but, as you might remember, it requires a deconstructor. A deconstructor is a method called Deconstruct in a class and looks like this:

public void Deconstruct(out int age, out string elfishName)
        {
            age = Age;
            elfishName = ElfishName;
        }

What is it?

In C# 8.0 however, you can combine both pattern matching & object deconstructing which is called positional pattern matching. It is important to note is that just as deconstructing it requires a deconstructor.

So what does it do? Well, it makes it possible to type check the variable, then cast it to a specific type and then deconstruct it IN ONE LINE! It looks something like this:

if (person is Elf(int age, string elfishName))
            {
                Console.WriteLine($"Elf with elfish name{elfishName} is {age} years old");
            }

The Age and ElfishName properties are extracted into the age and elfishName variables, just like in object deconstructing. This is a nice shorthand, but don't forget that a deconstructor is required!

An extra addition is this:

           if (person is Elf(110, string elfishName))
            {
                Console.WriteLine($"Elf with elfish name{elfishName} is 110 years old");
            }

In this piece of code, I've already provided a const value (in this case 110) against which the casted object is checked. So what this one line actually does, is firstly it checks if the person is an Elf, casts it, then deconstructs the casted object and lastly checks if the Age property is equal to 110. You can then access the ElfishName of that casted object in the elfishName variable. Isn't this nice??

Source

https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-8#positional-patterns
Demo project: https://bitbucket.org/aldhaenens/p-d-demo/src/master/