All IT leaders face challenges of outdated technology. Sometimes it’s time to build or buy a new application. But nowadays, it might make more sense to refresh the new old one. I explore those challenges and provide real client examples where I’ve used low code to help in both cases.
I share my thoughts on the recent acquisition of AppGyver by SAP and how that does or doesn’t relate to their SOLEX partner, Mendix.
The world is battling a war on two fronts: our health is threatened by COVID-19 and our economies have slowed and even stopped in certain sectors. As an App Developer, does my work really matter in such times?
After years of delivering, leading, and coaching leaders in Rapid App Development, I give you my perspective on what skills and profile it takes to be a ‘Great’ RAD Maker.
It’s been 1 year since I first wrote the post, “Extending SAP: Fiori or Mendix?” and a lot has changed. Because of the changes, this older post has gotten a lot of renewed interest so I thought I would take a look at my opinions from a year ago and see if they differ. If you haven’t already, please refer to the original article to have context for this one.
IT should be an expert “SWAT” team with precise skills to tackle the toughest app challenges, not a bottleneck to solving business problems.
Most of us who have delivered more than one app know that the majority of these turn into applications. That transition from ‘app’ to ‘application’ brings new challenges from the initial prototype and deliver process. Adding all of those extra features requires us to slow down our velocity a bit to test all of the new inter-connectivity. In this post I want to share with you my perspectives on what it means to transition an ‘app’ into an ‘application’.
Sometimes these pesky development bugs just won't go away. I stepped back from the trees to look at the forest and try to find some commonality between the multiple applications I've worked on and the cause of the bugs found. Surprisingly I found more in common than I anticipated. Here's a few reasons why bugs exist in your applications and what you can do during development to avoid them.
One thing that is inevitable in software development is that you will create bugs in your software. The question becomes how and when you deploy fixes for them. Each client has differing levels of change control processes that need to be considered when dealing with these fixes. You want to eradicate the bugs as quickly as possible, particularly if they are preventing the end users from completing their work, but you don't want to affect current main line development. I'll give you a process I use that seems to be working best after much trial and error.
A customer who had started a proof of concept wanted to develop and deploy the app as a production application. However, the page title (seen in the tab of the browser) showed the old name and they didn't know how to correct it. Also, they wanted to change the project name itself. Read on if you've ever come across the same issue or want a guide to point your new business developers.
During the last few weeks I was brought in to a new Mendix project to help troubleshoot and fix production bugs. One issue that was especially difficult to figure out involved the creation of a document based on a template with a whole lot of tokens. For those uninitiated, tokens are attributes that you can use in your application for emails or document generation to allow the dynamic values to populate instead of fixed text. Once I figured out what was causing the issue, I found what I believe is a limitation of the “generateDocument” action in a Microflow. I’m creating a ticket about this but if you’re interested in the problem and short-term solution, read on and I’ll explain.
