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.
When used correctly, Calculated Attributes enhance the apps by handling basic calculations at run time; Used poorly and they will damage your app performance. In this use case I walk through a sample app based on a real-world problem to explore the performance issues and a couple of strategies to improve performance to the correct standard. I appreciate any feedback and hope this helps some Mendix devs!
This entry started as the first in my next series that I planned about reporting with Mendix, but when capturing my screenshots I realized my example was so poorly designed in a working, production application that I needed to address it. While I don’t have the story prioritized to actually do the work to fix it versus competing higher priority issues, I’m going to explain what I did wrong in one of the first processes I ever wrote in Mendix and how I would design it differently had I followed my BI best practices and understood Mendix as well as I do now. Hopefully this comparison will help others who develop in Mendix when trying to optimize their application and look at each step more critically.
I was asked to help a fellow Mendix developer with some workflow issues and something stood out: There were a LOT of nested loops. Though preached (commanded?) by computer science professors as bad practice for very good reasons, we all know in the 'real world' outside of the walls of academia that sometimes you require the kind of result that can only be achieved by comparing multiple lists as they relate to each other. This creates a massive amount of overhead on a single-threaded application and can render an application useless if those lists are sizable. Sure, domain modeling is often to blame, but tools like what Mendix provides are supposed to make it easier for non-developers to do this kind of thing. There is a better way, and Mendix provides a set of actions to help you deal with these in a more efficient way: List Operations.
