Check Your Assumptions, Know Your Defaults

A couple of weeks ago, I had a problem. It appeared that my refrigerator was failing to keep the cool food section, well, cool. Freezer was fine, but the thermometer I had in the cool food section was showing between 50-60 degrees F, which is far too warm.

This wasn’t the first time this had happened, and on previous occasions, the issue was ice buildup in the freezer that blocked the channel allowing cold air to move from the freezer to the cool food section. So I largely skipped over diagnosis, and jumped straight into trying to fix the issue by running a couple of defrost cycles. I also did a cleaning of the coils under the fridge which, thanks to our dog, were pretty nasty, in case that might be contributing to the problem.

I'll spare my readers a photo, as I would not want to cause any nightmares. Suffice it to say, if you have pets, check and clean your coils regularly.

Savvy troubleshooters among the readers may have already figured out where I’m going with this, but it turned out that the fridge was actually fine. I didn’t hurt anything by running the defrost, and I’m sure clearing the coils of dog fur made for more efficient cooling, but the central problem in this case was a sensor that was misreporting the temperature. I figured that out by moving a separate smart temperature sensor into the cool food section and monitoring it, which told me that the temperature was, in fact, just fine.

Check Your Assumptions

My problem was that instead of troubleshooting from a clean slate, I brought in a set of assumptions based on prior experience. Those assumptions are a shortcut, and in many cases that shortcut can lead to the right conclusion. But when it doesn’t, it can cost us in time or money in pursuing the wrong problem.

This can happen in the software world as well. Many developers will, over their career, work with multiple programming languages, platforms and paradigms, and the assumptions that work for one platform may not readily apply to others. So it’s really important to make sure that you’re aware of any assumptions you’re bringing to the table when you are working with a new platform (or even switching between platforms that you’re familiar with).

Know Your Defaults

One of the places this came up for me recently is during some code reviews that I’ve been participating in going over several applications built on the OutSystems low-code platform. OutSystems, like many low-code platforms, is designed to simplify and accelerate the process of creating, updating, and maintaining applications by the use of visual tools and paradigms for most of the standard programming structures, including functions and exception handling.

In OutSystems, what would typically be called a function or subroutine in a language such as C# or Java is called an Action, and is modeled as a visual flow from a start to an end node, with other nodes representing other Actions that are called, logical nodes like If, Switch, etc. Alongside the main flow, developers can also define one or more exception handling flows.

In our code reviews, Justin James, who was leading the code review, noted several instances where the exception handler logic was calling a system Action called LogMessage to log the exception information. Sounds pretty normal, right? If you’re coming from a platform like .NET, this may seem perfectly fine, because in a high-code world, you do typically have to define your logging explicitly.

OutSystems Database Exception Flow – Note the default value for Log Error is Yes

In OutSystems, however, the beginning node of an exception handler flow provides options for automatically logging the exception information, and this option is enabled by default, as shown above. So by logging the exception information explicitly in the flow, the developers were inadvertently double-logging the same information.

As Justin observed, there may well be occasions where you want to explicitly call LogMessage in order to log information above and beyond the standard exception information, but just logging the error message is redundant and provides no additional information to help troubleshoot the error. The developers were trying to do the right thing, but because they did not know the default behavior of the exception flow was to log the error, they were duplicating effort unknowingly. This is illustrated in the screenshot below:

With the default Log Error set to Yes, the Log Message node is redundant

For what it’s worth, I’ve been working with OutSystems for years, and I didn’t know that was the default behavior, so I learned something new as part of this process as well.

For those doing a lot of work on the client side, note that exceptions in Client Actions also log error information by default, though it should be noted that the specific type of exception above, the DatabaseException, does have a major difference between the Client Action and Server Action implementations in that the latter includes an option to abort the implicit transaction that is part of the default behavior for Server Actions when working with the platform database. The DatabaseException on a Client Action does not provide this option.

Challenge Yourself

So how do we avoid falling into the trap of working from assumptions that may not apply? One way is to challenge ourselves to spend time going back to basics. Whether that’s troubleshooting a problematic appliance as if it was the very first time we’re looking at it, or engaging in code reviews (formally or informally) that may help reveal things we weren’t aware of in our platform of choice, taking a step back from the day-to-day to get back into learning mode can reduce the risk of wasted time and money based on incorrect assumptions.

Do you have any favorite stories of gotchas based on incorrect assumptions or misunderstood defaults? I’d love to hear them…drop a comment below!

The Difference Community Makes

In a recent post, I talked about my background as a software developer, teacher, and developer advocate, and how I ended up finding and liking Low Code, and more specifically, the OutSystems platform. In this post, I want to talk about the importance of the software development community, and why community is one of the things that’s helped keep me in the OutSystems orbit.

Starting Fresh

Some twenty-five plus years ago, when I left behind the world of building sets, hanging lights, and long hours for little compensation of the regional theatre world, I really wasn’t sure how I was going to manage in the world of I.T. I got some good advice early on from a relative and got a few certifications, and managed to land a few jobs, first doing help desk work, and later training folks at the Pentagon in using Windows 95. Glamorous work, to be sure! I realized pretty quickly that writing software was the direction I wanted to go, but had no idea how to get there.

Enter Community

As it happens, around this time I signed up for a local event called Microsoft DevDays, which featured a series of talks by software developers from area consulting and software companies. One of these talks was given by Geoff Snowman, and he impressed me with his knowledge and presentation, so I stuck around to ask some questions, including how someone like me could get started in professional software development. A bit of conversation later, he invited me to send him a copy of my resume. A few emails, and another certification later (got my certification in Visual Basic 4, for the record), I landed my first job as a software developer.

While I’m not sure I’d classify DevDays as a pure community event, since it was organized by Microsoft, it did feature speakers from the local developer community, so I think one could call it my first exposure to that community.

My next stroke of luck was being assigned to a project with two of my new company’s top developers, one of whom was a big fan of user groups, and got me connected with the user group community in the Washington, DC area. I started regularly attending user group meetings, particularly the Internet Developer User Group and SQL Server User Group, and I learned a lot quickly as a result, and got to know a ton of great people. Eventually, I started speaking at the user groups as well, and a few short years later, I was invited to speak at the 2004 DevDays event. It was after that event that I was approached about whether I might be interested in a role at Microsoft as a Developer Evangelist.

In short, it’s not an exaggeration to say that much of my success in my career came as a direct result of finding and participating in a rich and robust developer community.

The OutSystems Community

My journey with OutSystems was in some ways a mirror of that with Microsoft in that I started in OutSystems by being hired by them, first as a Solution Architect (technical pre-sales), and later as a Developer Advocate (teaching about the platform, and sharing feedback from developers back with internal folks). In that latter position, I worked closely with the OutSystems community, particularly with the folks who were part of the MVP program.

A big strength of the OutSystems platform is the community that surrounds it. The MVPs are both advocates for the platform, but also passionate critics when there are things that they see that need improvement. Having fans who only tell you what you want to hear is not a great way to have a strong platform over time, so being able to hear feedback that the MVPs provide is really important, even if it wasn’t always comfortable on the receiving end.

The OutSystems community is also really helpful in providing support to one another through the OutSystems Forums, and in sharing reusable solutions and components in the OutSystems Forge. OutSystems helpfully provides a home page for the community at

OutSystems Community Home Page

On the Community page, you can find links to relevant information like the Forums, Forge, Documentation, MVP program, and events (including user groups).

I recall that at one of the first OutSystems events I attended as an employee, the NextStep conference in Boston in 2018, I was approached by Mário Araújo, who at the time was running the Developer Relations team at OutSystems, to pick my brain based on the 10 years I’d spent working with developers while at Microsoft. I liked that he (and others I’ve since worked with at OutSystems) wanted to better understand developers and how best to serve them (and how to explain to execs what developer relations is and why it’s important…such activities do require budget and buy-in, after all).

OutSystems has provided good infrastructure (Forums, Forge, several community recognition programs, etc.), and had the savvy to incentivize participation through a bit of gamification of the community sites. Community members receive points for responding to forum posts, but more points for having their answer marked as a solution, which at least in theory incentivizes quality over quantity. Points are also rewarded for publishing components to the Forge, and there are other categories as well. I would agree with those who say there’s room for improvement here, but I do think overall the gamification has strengthened the community by encouraging more consistent participation. OutSystems also has a team dedicated to supporting, understanding, and improving their platform for developers, a team I was proud to be a part of.

Find Your Community

Community has changed a lot since my early days in the developer community. What was once mostly in-person and a some online has shifted to more online with some in-person (if you’re in the OutSystems space, you can find local user groups near you on the OutSystems User Groups website), but there are still plenty of opportunities to get involved, learn more about your chosen technology, and meet folks with similar interests. Even better, you can share what you know, and help someone else who is getting started.

A developer community is a great example of a win-win for a company like OutSystems and the developers working with the platform. OutSystems gets the advantage of a group of enthusiasts sharing knowledge and helping one another be more successful with the platform, and the developer community gets the help they need, and the infrastructure to find one another, ask and answer questions, and find and share software solutions.

I have little doubt that much of the success and joy I’ve experienced in my career in software development and developer education and advocacy can be attributed to my participation in the developer community. The friends I made, the knowledge I gained, the mentorship received, all of these acted as accelerators on the path to improving as a developer and teacher.

Whether you’re an OutSystems developer, or have chosen a different software stack, I encourage you to seek out and be a part of the community for your platform. You can get help when you need it, share knowledge with others, provide feedback on the platform, and be a part of something rewarding!

When You Need A Balloon, A Tooltip Just Won’t Do

If, like me, you started your OutSystems journey prior to the mainstreaming of the Reactive Web and Mobile versions of OutSystems, you may have encountered the Balloon pattern, which was originally a part of the Silk UI framework, and continues to be available in OutSystems UI, but only if you are building Traditional Web applications.

The Balloon…A Superior Tooltip

The Balloon pattern is essentially an enhanced Tooltip with support for more content options than a Tooltip would typically allow. Where a Tooltip supports only a single content area, and is generally used for simple text-based content, the Balloon pattern provides more flexibility with a title, content, and footer area. Both patterns provide a selection of triggers (hover, click, or manual), and the ability to select the position of the element relative to the element that it is related to.

Tooltip and Balloon Patterns in a Traditional Web App

As noted above, though, the Balloon pattern is only available when using OutSystems UI in a Traditional Web application…so if you want the UI flexibility afforded by the Balloon, you’re out of luck…or are you?

Forge to the Rescue!

During a recent project, my team had a need for the kind of functionality the Balloon pattern provided, but we were working with the Reactive Web application type, so the Balloon pattern from OutSystems UI wasn’t an option. What to do? Check the Forge, of course!

If you're not familiar with the Forge already, it's OutSystems' repository of UI patterns, connectors, extensions, sample applications, and more. With more than 5,000 shared assets, if you need to do something that isn't directly supported by the platform, there's a good chance it may already be available on the Forge. It's important to note that the Forge is a mix of assets created by teams at OutSystems (many of which carry the "Supported" designation), as well as those created by the OutSystems community, which are not supported by OutSystems, but may be supported by the creator. Some community-provided assets carry a "Trusted" badge, which means they've gone through a review process to assess quality and more. Details can be found here.

Searching the Forge for “Balloon” returns 3 results:

Searching the Forge

Of the 3 results, 1 is for Traditional Web, so that’s out. When looking for a component or widget on the Forge, I typically look at both the number of downloads and the number of reviews as an indicator of which components are more widely used. I’ll also sometimes check the Support tab in the component listing, and see whether the author has added documentation. Both of the components above for Reactive Web are pretty similar in those areas, so in this case, I reached out to some folks internally to see what they’ve used, and Balloon Tippy.js got the nod.

Using the Component

Once you’ve decided on a Forge component to use, you have two options. You can download the component from the Forge website, and add it to your project by opening the downloaded version from Service Studio or Service Center, or my preferred method, you can go to the Forge tab in Service Studio, locate the desired component, and install it from there.

Balloon Tippy.js Component in Service Studio

Note that some components also include a demo, which can be helpful in understanding how to use the component. Once installed, the component is essentially just another OutSystems application, meaning you can open it up, inspect the UI, flows, JavaScript, etc. to better understand how it operates, tweak it to suit your needs, etc.

Once you’ve installed the component, you’ll need to add a reference to the desired UI blocks, flows, and entities, depending on the functionality exposed, and what you need for your use case. In my case, I’m just selecting everything Balloon Tippy.js has, since it’s a pretty simple component.

Adding Balloon Tippy Dependencies

Once the dependency has been added, using the component is exactly the same as using the Balloon pattern from Traditional Web. Simply locate the Balloon widget in the toolbox, drag it to the desired location on the screen, add the desired Title, Content, and Footer, and set the WidgetId property to the Id of the widget you want to use to trigger the display of the balloon on hover or click.

Using Balloon Tippy.js


The moral of the story here is two-fold. One, if you are finding the Tooltip pattern to be a little restrictive, and want more flexibility for your content, the Balloon pattern is there for you if you’re using Traditional Web (and I’m sure some of you still are). Two, if your favorite pattern has been deprecated, or if you’re looking for something that the OutSystems platform doesn’t natively support, it’s worthwhile to check out the Forge to see if OutSystems or the community have provided that functionality for download. Sometimes, as in the case of Balloon Tippy.js, the component may even be essentially a drop-in replacement that works exactly like the one its replacing, making it super-easy for you to implement in your applications.

Would love to hear your favorite components or patterns…feel free to drop them in the comments!

Why Low Code?

TL:DR; How one long-time .NET developer came to discover and embrace low code as another tool in his toolbelt, and why you might want to consider taking a look, too

Where I Came From

For those who don’t know me, I’ve been in the software industry for more than 25 years. My start in software on a professional level came in using Visual Basic, but in what was at the time a little unusual way, using VB to create server components. Which is a bit ironic, as one of the things I found most appealing about Visual Basic was its visual nature, and being able to create application UIs by simply dragging controls onto a form, and linking them up with code.

Visual Basic IDE
Visual Basic IDE – Image credit: Diomidis Spinellis – Creative Commons Attribution-Share Alike 3.0 Greece License

Around the same time, Microsoft was experimenting with bringing similar paradigms to web development, with a new tool called Visual InterDev, which provided similar drag and drop, control-based web UI development. Visual InterDev opened up a new world of data-bound, rapid development for web applications, and I loved it (and eventually wrote a book about it). Paul Thurrott has more thoughts on Visual InterDev here, so I’ll spare the reader too much detail here. The important takeaway is that while it had some downsides, including a pretty heavy load of client-side code to implement its controls, Visual InderDev was a significant leap in web development for those of us in the Microsoft camp.

In my view, the true promise of InterDev’s control-based development scheme came with the release of ASP.NET and its Web Forms development paradigm. Web Forms took the heavyweight, cumbersome, and sometimes finicky client code for Visual InterDev’s code, and replaced it with server controls that rendered HTML and more limited script to the client. Since at the time, servers were generally more robust and powerful than the average client machine, removing processing to the server had a number of benefits, including lighter client code and better performance.

ASP.NET was also a closer match to the programming paradigm of Visual Basic, in that each page in an ASP.NET application had the page itself, which contained the information for the UI of the application, and an associated “code behind” file, which contained the code (VB, or Microsoft’s new language at the time, C#) that responded to button clicks, and otherwise connected the controls on the page together to handle interaction with the user and similar tasks.

From the ASP.NET days (and a couple more books), I made my way through a variety of phases of web development using subsequent versions of ASP.NET (MVC, Web API, etc.), as well as various JavaScript frameworks.

Why the background? Because it informed my decision when I was presented with the opportunity to explore a role at OutSystems, a leading low code platform provider. When this opportunity arrived, I was doing satisfying, if somewhat vanilla, development work using Angular and ASP.NET Web API, so I was under no real pressure to find something new.

Discovering Low Code

When I initially talked to OutSystems, it was via a “friend of a friend” referral, and the conversation was interesting enough that when my interviewer recommended downloading and trying the OutSystems platform, I was happy to do so. What I found brought me back to the things I loved about Visual Basic, Visual InterDev, and ASP.NET in the early days…a visually-focused development environment that made building applications faster and easier.

But OutSystems as a platform took things even further than Visual Basic. In OutSystems, you can develop your entire application, from UI, to logic, to data model, and even workflows, in a single unified development environment, and all using visual tools. So where a developer using Visual Basic would drag and drop a button onto a Form, and double-click the button to add a button click handler, and then be dropped into a code editor, the OutSystems developer following a similar path remains in the visual metaphor with a flow editor instead.

OutSystems Visual Logic Flow
OutSystems Visual Logic Flow

I was sufficiently intrigued by the capabilities of this platform that I continued interviewing with OutSystems, and eventually took on a role as a Solution Architect there. I later returned to my roots in teaching and moved to a role as a Developer Advocate, and stayed with OutSystems until early 2023, when I took a role as a Senior Technical Architect with Xebia, an OutSystems partner.

So…Why Low Code?

Getting back to the title of this post…why have I chosen to explore, and ultimately stay with, low code?

I find that low code provides a good level of abstraction, while still (at least with OutSystems, though I assume other low code platforms have similar capabilities) allowing me to use JavaScript, CSS, C#, and related “high code” functionality where needed to expand or enhance the native capabilities of the platform.

Low code in the OutSystems world also still allows me to choose whether I want to go for raw speed, for example, using scaffolding to build out a simple forms over data app in a matter of minutes, or using codified architecture principles to build a robust, maintainable, and high-performance application that is more suitable for an enterprise.

And in the case of OutSystems, low code is opinionated, in a good way. While the underlying technologies are based on .NET and ReactJS, which means they’re well-understood and mature, the platform itself is designed to be very turnkey. When a customer signs up with OutSystems (or a developer creates a free Personal Edition), the server infrastructure is set up for them, and developers need only download a single tool, Service Studio, to get started with developing their apps. No need to figure out which JavaScript framework, source control, JS loader, etc., etc. to set up your developer machine with. Just one download, log in, and go. Having dealt with the madness of JS framework versions and related technologies, I love how simple it is for me to set up a new machine to develop OutSystems apps.

Low code is not perfect. And like any programming abstraction, there are places where the abstraction breaks down, and those times can be a pain to deal with. But with few exceptions, low code allows me to produce applications that solve important business problems faster than any other platform I’ve used, and also makes it faster for me to keep those applications up to date. That’s a winner in my book, and whether it’s OutSystems, or any of the other players in the low code space, I would encourage my fellow developers to check out low code, and see whether it might just merit a spot on your developer tool belt.

With that background, look for more posts on how OutSystems works, and how you can take advantage of low code to solve problems for your clients faster.

20 Years of Blogging

Apparently, I missed it by a couple of days, but the 22nd of February, 2023 was the 20th anniversary of my very first blog post. I was fortunate enough to be one of the first set of folks with a blog on, which ran on the .TEXT blogging software written and operated by Scott Watermasysk.

The post itself is unremarkable, just an introductory musing. What is remarkable is that 20 years later, that blog is still online, thanks to the folks at Microsoft keeping it up and running. It has been transitioned to Orchard in the meantime, but given how many blogs and sites have long since disappeared from the web, it’s amazing to see things I wrote 20 years ago still online.

Over the subsequent 2 decades, I’ve moved my blog to different places, first moving to when I joined Microsoft as a Developer Evangelist (that site now redirects to, but the content is still online), and eventually stood up my own independent blog here on

My thanks to Scott for his role in helping me get started in the blogging world, and kudos to Microsoft for keeping this resource alive. If you’re interested in seeing all the blogs from, here is a list of all the bloggers on that site:

I should note that I was reminded of my 20th anniversary by a post from my friend Frank La Vigne on the 19th anniversary of his blog 19 years of blogging on the same domain is an impressive feat!

Resources for my OSDC Talk

OSDC Banner

Recently, I gave a talk at the OutSystems Developer Conference (OSDC) on integrating external code and services in an OutSystems application, entitled “A Little Help From My Friends: Integrating External Code in OutSystems”.

Here are some relevant resources that I discussed during the talk:

OutSystems Forge

The Forge is the first stop for OutSystems developers looking for additional functionality for their apps, and you can access it online at:, or via the Forge tab in Service Studio.

The Forge offers thousands of components, ranging from full demo apps, reusable UI widgets, to connectors to popular services from Microsoft (Azure Cognitive Services, etc.), AWS (S3, Lex, etc.), and more.

Integration Builder

Integration Builder is a web-based interface for easily connecting to logic and data from a variety of sources, including Salesforce, SAP oData, SharePoint Online, and more. Learn more about getting started with Integration Builder.

I also mentioned that my colleague Cristiana Umbelino did a Decoded: Quick Hits video covering Integration Builder:

I’ll also add a link to the Integration Builder deep dive session from this year’s OSDC, once the recording is available.

Using JavaScript

During the discussion of custom JavaScript, I mentioned a couple of videos I did on using JavaScript in an OutSystems app. I have videos for both Traditional Web (“Dude, Where’s My JavaScript?”), as well as for Reactive Web Apps, both of which you can see below.

Using JavaScript in OutSystems Traditional Web Apps
Using External JS Code in an OutSystems Reactive Web App

Integrating C# Code

Finally, I mentioned in the section on integrating C# code that I had created a simple .NET extension for reversing a string, and I have a video demonstrating that component, and how you can (in a self-managed OutSystems environment) debug that code using Visual Studio. You can view that video below:

Debug a .NET Component in OutSystems


My thanks to all who attended my talk. If you’d like to see all of the OutSystems content my team produces, check out our playlists:

Building an Internet-Connected, AI-driven Candy Dispenser with OutSystems

A Lighthearted Look at Adding AI to your Apps

If you’re like my boss, you’ve probably thought to yourself, “what the world needs right now is an AI-driven candy dispenser.” OK, maybe that wasn’t exactly what he was thinking, but that’s where we ended up, when he had the idea to demonstrate the power of AI, using an unconventional demo approach.

To make this work, he purchased a simple mechanical food dispenser, shown in the image below:

The Starting Point

This dispenser had the advantage of being inexpensive, and more importantly, it had a removable handle and shaft, which could be replaced by a stepper motor (which can be moved with precision using a variety of microcontroller boards or a Raspberry Pi), along with some 3D printed parts to mate the motor to the paddle wheel used to dispense the contents. That’s where I came in.

Automating the Dispenser

Before we could demonstrate the power of adding AI to an OutSystems app, we needed the candy dispenser to be controllable and automated. As noted, this involved adding a stepper motor similar to the one below, to control the paddle wheel:

NEMA 17 Stepper Motor

To mate the stepper motor to the dispenser, I designed and printed a shaft adapter, and a bracket. To enable the stepper motor to be controlled by the OutSystems app, I purchased a $20 Particle Photon microcontroller *, which has built-in Wi-Fi support, and is programmable using familiar Arduino code, along with a $5 stepper motor driver, which simplified the programming of the device. Wiring was accomplished using a breadboard and jumper wires, which is pretty common for electronics prototyping. For fun, and to provide a visual indication of when the device receives commands from the app, I added a multicolor LED ring to the device as well.

* An earlier version of the dispenser used a Raspberry Pi and Python code, and was a little more complex. The Particle Photon was both cheaper and easier to use, and also had a built-in SDK that enabled calling functions on the device directly as REST API methods.

I won’t spend a lot of time on the device itself (I’m planning a follow-up post that goes into more detail on the hardware, and the firmware that allows the Candy Dispenser to be addressed via REST APIs), but at the end of the build process, I had a Candy Dispenser that could connect to the internet, and receive commands via REST. There’s a parts list for the dispenser in the description of the YouTube video at the end of this post, for those who are interested.

The Mobile App – Hardware and AI

Once I set up the Candy Dispenser hardware to respond to REST API calls, the next step was to create an OutSystems mobile app to consume these REST APIs, and call them based on inputs from device hardware and AI analysis, for the following use cases:

  • NFC for reading text embedded in NFC tags: When the text read from an NFC tag matches the target value in the app settings, dispense candy
  • AI Text Analytics for determining the sentiment (positive/negative) in a given text string: If the sentiment is positive, dispense candy.
  • AI Emotion Detection, leveraging native camera hardware, and Azure Cognitive Services: Evaluate a picture taken from the device camera to determine the emotion of the person in the picture: If the person is sad or angry, dispense candy.

In each case, if the target criteria for the use case is not met, the app calls a REST API that tells the LED ring on the candy dispenser to display red, which provides an additional indication that the REST call succeeded.

Accessing Native Hardware

OutSystems mobile apps are built on top of Cordova, so can leverage Cordova plugins to provide native access to device hardware. These plugins are available to developers in the open source Forge library for download and inclusion in their apps. You can find Plugins using the Forge tab in the OutSystems Service Studio development environment, as shown below, or via the Forge website:

Searching the Forge in Service Studio

Once you find the plugin you want, you can install it directly from Service Studio, and the plugin is then available for any application in the server environment where it was installed (note that the Camera plugin shown below is already installed…if it was not, an Install button would appear):

Camera Plugin

After you install the plugins, you can add them to an application using the Manage Dependencies window, accessed by the plug icon on the toolbar, or Ctrl+Q:

Adding the NFC plugin as a dependency

Where the plugin appears after it’s added as a dependency varies based on the functionality provided by the plugin. Most will appear in the Interface tab (for plugins that provide UI-related or screen-related functionality), the Logic tab (for plugins that provide client Actions that can be used in the app), or both.

For the NFC functionality, I wanted the app to respond to the reading of an NFC tag, and the plugin provides two options for this, MimeTypeListener and NdefListener. I used the latter, which defines an event that is fired when the NFC radio in the device detects and reads an NFC tag. To respond to the event, I created a client Action that handles the event, and receives a list of the text records stored on the tag. The client Action, shown below, checks the first text record (I’ve made the assumption that there will be only one text record) against an app setting stored in local storage, and if it matches, calls the REST API to tell the Candy Dispenser to dispense candy (technically, the client Action is calling a server Action that wraps the REST API call, but the end result is the same).

Client Action for NFC Tag Read

Working with the device Camera is just as easy. In the CheckMyMood screen, I used an Image control to display a neutral face image. I added an OnClick event handler to this image, which is executed when the user taps the image. The client Action checks the status of the Camera plugin, and assuming it’s available, calls the TakePicture Action from the plugin, which I simply dragged into the desired spot in the Action flow. The TakePicture Action only opens the camera UI. No picture is taken unless the user actively chooses to do so. Once the picture is taken, the image data is submitted to Azure Cognitive Services (more on this shortly), which returns an estimate of the emotions displayed in the image. If the emotions indicate sadness or anger, the app tells the dispenser to dispense candy. If not, a message is displayed indicating that happy people don’t need candy.

The OnClick client Action is shown below:

OnClick Client Action

The last use case, analyzing text for sentiment, does not require any device hardware, and simply uses a text box and a button on the screen. The button invokes an action, which submits the text from the text box to the OutSystems.AI Language Analysis plugin’s DetectSentimentInText Action, which again I simply dragged and dropped into the client Action logic flow, as shown below. I arbitrarily chose 0.50 as the breaking point between positive and negative sentiment, and dispense candy for a positive sentiment, and no candy for negative:

Negative Sentiment? No Candy for You!

AI Integration

Both the emotion detection and sentiment analysis use cases rely on AI to drive the outcome. AI functionality is easy to add to an OutSystems application, leveraging a variety of connectors and components in the OutSystems Forge, including OutSystems.AI Chatbot and OutSystems.AI Language Analysis, as well as Azure Cognitive Services, Azure Bot Framework, Amazon Rekognition, and more.

For the candy dispenser, I installed both the OutSystems.AI Language Analysis component, and the Azure Cognitive Services Connector from the Forge, and added them to my mobile app as dependencies.

Configuring these components is pretty straightforward. You do need to set up an instance of the appropriate Azure service (most offer free plans to start with), and add the subscription key from the service instance to the appropriate site property in Service Center. This process is documented in the following articles:

Once the AI service instances have been set up, the last step is to provide the relevant plugins with the necessary information to connect to the AI services, which in the case of the two services I’m using is as simple as adding values to Site Properties representing the API key provided by the relevant service. In my case, I just opened up the AzureCognitiveServicesConnector module (not the Application…Site Properties are configured at the Module level), and set the values for the Face API and Text Analytics API keys, as highlighted below (note that the OutSystems.AI Text Analysis plugin is a wrapper around the Azure Cognitive Services Text Analytics that makes it simpler to use):

Azure Cognitive Services API Keys

With the keys configured, the mobile application is complete, and ready to test. Here’s a video demo of the completed application…Enjoy!

Candy Dispenser Demo

Want to see the Candy Dispenser in action in person? Keep an eye here for upcoming events where I’m showing it off, and watch my Twitter account for announcements as well.

New Role, New Topic – Low Code

Finding Low Code…or Did It Find Me?

Ever run into one of those technologies that snags you immediately? That’s what Low Code recently did for me.

Pixel-perfect Low Code apps with OutSystems
Mobile Apps are Beautiful and Pixel-perfect on OutSystems

As many regular readers will know, I’ve spent the last several years doing independent consulting and coding, mostly in the .NET and JavaScript world. And I was humming along, with the usual ups and downs that go with being independent, but mostly happy with what I was doing. Then a friend reached out, and mentioned that someone he’d worked with in the past was looking for someone with Microsoft stack architect skills, and would I be interested in talking with him?

I wasn’t looking for anything new. But I thought, can’t hurt to take a call, right? Which is how I was introduced to OutSystems. The initial call was encouraging, so I decided to take the OutSystems platform for a spin, and I was immediately impressed by just how fast I could build a fully-functional application, using just a visual approach of assembling UI and logic widgets, quickly creating and querying data entities, and rapidly publishing new versions in an agile manner.

Finding the Fun Again

My immediate reaction was that it reminded me of some of the best of what I fell in love with when I first started using Visual Basic back in the late ’90s. But without all the code, and with a much more robust publishing and administration infrastructure behind it.

I found that at every turn, from automatically inferring data types for attributes based on the names you give them, to rapidly creating basic list and detail pages by simply pulling a data entity onto a design surface, the tools provided by OutSystems made building apps faster and easier than I was used to…and dare I say it, more fun.

To make a long story short, I decided to continue pursuing the conversation with OutSystems. After a few more calls and interviews, I accepted a role as a Solution Architect. I’ve been in that role for about 6 months now, and nothing I’ve learned in that time has diminished my feeling that Low Code, particularly with OutSystems, is a game-changer for application development. I’ll be sharing more in the coming weeks and months on the whys and hows.

Can’t wait to see what Low Code is all about, and how it works in OutSystems? Check out the OutSystems 2-minute Overview below:

If you’re a passionate technologist, and this has sparked your interest…we’re hiring. Contact me, and I’d be happy to put you in touch with our great recruiting team!

Custom Domains the Easy Way in Azure Web Apps

One of the best things about cloud development today is the low cost of entry. With cloud vendors competing to bring customers to their offerings, there are strong incentives to keep prices low, particularly at the entry level. Microsoft’s Azure offerings are no exception. You can get started with Azure Web Apps, whether for hosting a blog or a more full-featured application, for free, if you’re willing to accept the limitations of the free plan.

One of those limitations is that the free offering for Azure App Service does not support the use of custom domains. So any site or app you host using the free plan must use a subdomain of the domain, such as For development and testing, or for hosting an API that will only be called programmatically, this is no big deal. But for public facing sites, you’re going to want a custom domain. Read on to learn how easy Microsoft has made that with Azure Web Apps.

Continue reading Custom Domains the Easy Way in Azure Web Apps

Save Time and Keystrokes with Emmet in Visual Studio Code

It’s been more than 8 years since Jon Udell posted an encouragement of blogging over email entitled “Too busy to Blog? Count your keystrokes” and over 5 years since Scott Hanselman followed up with “Do they deserve the gift of your keystrokes?” Both posts explore the idea of our keystrokes being a limited resource that is better used to contribute to knowledge sources like blogs or wikis that are available to large numbers of people, rather than replying to a much more limited audience via email. In this post, I’ll introduce you to one of my favorite new helpers, Emmet in Visual Studio Code, and show you how it helps me save keystrokes when working with HTML markup. Continue reading Save Time and Keystrokes with Emmet in Visual Studio Code