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 https://www.outsystems.com/community/.

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!

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 azurewebsites.net domain, such as myreallycoolsite.azurewebsites.net. 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

Visual Studio Code Hits the 1.0 Milestone

I must have missed this while avoiding the interwebs around April Fool’s Day, but apparently Visual Studio Code is no longer beta/preview, and has hit their 1.0 version milestone.

UPDATE: I was confused when reading the update log, which had the 1.0.0 update listed as March 2016…this must’ve been referring to the preview 1.0 release. Thus the correction above. The official public 1.0 release was yesterday, so I didn’t miss it after all. Details below the fold…

Continue reading Visual Studio Code Hits the 1.0 Milestone

Top 5 Reasons to Speak at NoVA Code Camp!

…or your local user group, meetup, or code camp.

Becoming a Speaker

As someone who’s been speaking on technical topics since the late 1990s, I can say with great confidence that there are huge benefits to sharing your knowledge at local code camps and user groups. And if you’re in the greater Washington, DC metro area, I want to encourage you to submit a talk for the Northern Virginia Code Camp, which is coming up on April 30th, 2016. Here are 5 reasons to speak you should consider: Continue reading Top 5 Reasons to Speak at NoVA Code Camp!

Thread.Sleep equivalent in UWP

Wanted to share a quick solution to an issue I ran into while working on a Universal Windows Platform (UWP) app for my Raspberry Pi 2.

Background

I was building an app to read sensor data from a .NET Gadgeteer TempHumidity module using the GHI Electronics FEZ Cream, which is a HAT (Hardware Attached on Top) for the Raspberry Pi 2 that allows the use of Gadgeteer modules. In my case, I’m running Windows 10 IoT Core on my Pi 2, so that I can stick with programming in C#. The original driver included a call to Thread.Sleep, which it turns out is not available in a UWP app.

For Gadgeteer modules that are directly supported (i.e. with drivers that have already been ported to work with Windows 10 IoT Core), integrating them into a UWP project is as simple as downloading the relevant NuGet packages. However, in my case, it turned out that the temperature and humidity sensor I was using was an older model which was not directly supported. The good news is that since GHI makes their Gadgeteer mainboard and driver code available on Bitbucket, it was easy to find the driver code for the sensor I’m using and work on a port to work on the Pi. Continue reading Thread.Sleep equivalent in UWP

Troubleshooting Web API and Angular 2 beta

Just ran into an issue with some Web API and Angular 2 code I’ve been working on, and since there didn’t seem to be much info in the wild on the error I ran into, I figured I’d blog it, in case it might help someone else.

A Simple Demo of Web API and Angular 2?

Since I had the day off yesterday, I figured it might be a good day to jump in and start doing some work with Angular 2 (Hey, isn’t that what you do with your day off? Don’t judge!). Of course, I’d already run through a number of tutorials that dealt with hard-coded collections of data, so I figured it was time to build something that could retrieve data from an API. Continue reading Troubleshooting Web API and Angular 2 beta

Multiple Monitors in Remote Desktop with Windows 7 Pro

The Best Laid Plans…

I’ve recently transitioned from working at home to working on-site at a client. The client did a great job of provisioning a nice desktop PC and large dual monitors. But one of the things I missed from my home office was my standing desk. To remedy this, I planned to bring in my laptop, set it up on a stand, and re-purpose one of the two monitors they provided so I could use Remote Desktop to connect to the desktop PC and still enjoy dual monitors…but there was a small wrinkle in my plan.

Continue reading Multiple Monitors in Remote Desktop with Windows 7 Pro

Community Megaphone and a Post-INETA Future

As I noted a few months ago, INETA North America is ceasing operations and wrapping up loose ends. As part of that wrap-up, the INETA board asked if I would be willing to help with community continuity through the website I created, Community Megaphone. The idea was for INETA to encourage folks on their mailing list to join a list I set up to discuss the future of Community Megaphone, and what kinds of features might help fill some of the gaps left behind by the end of INETA North America.

With this post, I’d also like to offer others in the developer community the same opportunity. You can join the mailing list, which is for the purpose of providing ongoing updates on the future plans for Community Megaphone. And if you don’t want to join a mailing list, but still want to provide feedback or ideas on features that would be useful for user group leaders, speakers, and attendees of developer community events, you can do so on the Community Megaphone Uservoice page, or the Feedback page on the Community Megaphone site.

I’m looking forward to the feedback of the community, and finding better ways to serve the developer community, and I hope you’ll share your feedback, too.