Some time ago, I started work on a personal project called Rat Catcher. This application helps companies that create content determine if their author submissions are original works, and then find instances of other sites copying the content on a regular basis. When I first wrote Rat Catcher, my plan was for a desktop application that I would sell, but after integrating additional functionality from other Web service vendors, I realized that I wanted to move to a Web application model instead.

In all honesty, I have not really enjoyed Web development much ever since I stopped working in Perl; I have used and been frustrated by PHP, J2EE, and ASP.NET for various reasons. A few years ago, I was chit chatting with a friend about what my ideal system for developing applications would look like, and the OutSystems Agile Platform comes pretty close to what I envisioned, including the idea that error handling was metadata and a divorce from the traditional source code model. But for a while now, I have been tied up in the desktop development world, and as a result, I didn’t have much time to really work with the Agile Platform in a real project environment. When I made the decision to move Rat Catcher from a desktop application to a Web application, I knew that this was my chance to move to the Agile Platform as well.

Throughout this six-part series, I will tell you about my experiences with the Agile Platform, both the good and the bad. As of this writing, Rat Catcher is not finished as a Web application (the core algorithmic functionality was completed quite some time ago), but it is barreling full tilt towards completion. I’ll start with my initial experiences with Agile Platform; in upcoming entries, I’ll look at the things I did, such as user management (including a transition from a home-brewed method to the Agile Platform’s Enterprise Manager system), integration with my separate Rat Catcher code, handling credit card transactions, scheduled batch jobs, and more.

Agile Platform: Initial impressions and experiences

Last year when I first looked at the Agile Platform, I really liked what I saw when Miguel Baltazar (the OutSystems Solutions Delivery Manager in the United States) showed me some of the basics. Even though I was picking up this project long after that, it only took me an hour or two to re-acquaint myself with how the Agile Platform does things. The key thing to understand is that things “just happen” in the Agile Platform. There is a very strict rhyme and reason to it, but it can be startling if you are not used to working like this; in many ways, it feels like working in a functional language (because of how things fluidly tie together) mixed with Perl (because of how much work the system does for you). After the initial time needed to get my bearings, I was off and running very, very quickly.

My number one mistake was trying to skip the training. (I keep promising myself that I will stop jumping into new systems and languages without first getting my groundings. I say this as someone who is simultaneously reading a book on F# and one on Python.) I was so excited about this project that I just started to cowboy my way through it; as a result, I made a few bad decisions.

The worst decision was deciding to try to put together my own user management system, because this is a problem that is already solved with the Enterprise Manager component, which is free; I wasted a lot of time recreating functionality that the Enterprise Manager already has. Fortunately, Enterprise Manager can be added on later. (In an upcoming article, I will talk about my transition from the homegrown system to using Enterprise Manager.) One of the key things to realize about the Agile Platform is that there is functionality like the Enterprise Manager that you really do not see in Service Studio. This large structure of interlocking components gets even larger when you step up from the free Community Edition to the full paid editions and have access to the project management tools. The training introduces you to these other systems, and the time spent in training (rather than spent duplicating work) is worth it.

One of the hardest things for me to adjust to in Agile Platform is the TrueChange engine. TrueChange detects the changes that I have made, and immediately updates everything else in the application to reflect that change. The only comparison I can make is ReSharper’s Rename feature. Imagine if that functionality was automatic and applied to every possible thing in your project, from variable names to database types to file names to… well… everything. It is really mind-blowing to see it in action, and to be honest, it scared the pants off of me.

I have encountered so many systems in the past that claimed to do stuff on my behalf, but required a pile of manual intervention, that I just did not trust it up front. For the first few hours that I really worked on this project, I found myself making a change and then going to other areas to update the work there, only to see that it was already done. When TrueChange can’t make the change, or if it detects a problem, it immediately tells you. It does not wait until you perform a publish action (akin to compiling and then deploying to a test server) to tell you that something is wrong.

Over the course of this project, I have only encountered two instances of TrueChange not working right. The first time was when I changed the type of a “static entity” from integer to decimal. The record values were still integers without a decimal point, and the system balked when I went to publish the project, because it could not cast the integers as decimals. The other problem I had also involved a data problem where I already had data in the system, and it was not compatible with the new data type. This would be a problem in any system, so I have a high level of forgiveness here. In my case, I didn’t mind blowing the column away manually, since it was just test data, but if the system were in production, I would have had to be a bit more careful.

What really stands out to me about the Agile Platform is the system’s visual nature; it’s not just a WYSIWYG tool for laying out GUIs (that is old hat by now) — it’s the WYSIWYG nature of the workflow itself. I first started this project in October 2009, but unfortunately, I was interrupted for months; when I picked the project back up, I had no problem figuring out the workflow or understanding how things happened. In the traditional source code model, the best you have to go on in terms of understanding what code “belongs” to what statement in terms of conditionals or loops in the indentation. That’s helpful, for sure. But unless you are using Python (or something like it, where indentation determines scoping), it is easy to accidentally have a block of code at the wrong indentation level, making it very difficult to identify what code belongs where. And forget about looking at someone else’s code and trying to understand it — even when it is well written, it can be tough to follow. With the Agile Platform, it is a cinch to see how the code works, just follow the arrows, literally.

Overall, my experiences so far have been fantastic, and I look forward to telling you more in the upcoming weeks. Rat Catcher has progressed incredibly fast, and by the time this series is finished, it will be deployed and ready for business!


Disclosure of Justin’s industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.


Get weekly development tips in your inbox
Keep your developer skills sharp by signing up for TechRepublic’s free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!