This is a long-ish post, intended to document the issues I came across so that perhaps they might be addressed. You don't need to read the whole thing to get the idea, which is: If I were looking at Progress and PDSOE as a development platform, I would probably give up on it fairly quickly, after concluding that the product lacks polish and good documentation, and probably doesn't work too well.
My environment is Windows 10, Progress 11.7.3 64-bit. I'm an experienced developer, and I've been using Progress for decades-- so if I can't make it through the sample code then something is probably wrong. It's not that Progress doesn't have a lot of documentation -- it certainly does, and much of it is excellent. But I keep getting stuck trying to find it, or to make my way through it.
Most of my work over the years has been in a character environment. I've learned enough of Studio, PAS and other "new" technology to be slightly dangerous. But there is a lot of meat to these tools, and a lot of options that I simply don't understand. I thought it was time to learn the tools in depth, and being a good developer I turned to the documentation.
The first thing I thought I would do was look at some of the sample code. Handily enough, PDSOE includes a variety of samples. AutoEdgeTheFactory sounds like a good place to start. Nope: it requires Savvion BPM components, and I don't have those.
Well, maybe I'm starting in the wrong place. Let me try reading the documentation. Ah, here we go: "Getting Started: Introducing the Progress Developer Studio for OpenEdge Visual Designer." Perfect. Till I get about half-way through the first chapter.
OK, I don't have that either. Isn't there any sample code I can just run? Back to the Sample Code. There's a whole BPM section I can ignore -- AutuEdgeTheFactory should probably be in there -- but I can look at the .Net stuff ("OpenEdge Ultra Controls for .NET). It's not what I'm looking for, but at least it's something. Clicking on that brought me to the web page :"OpenEdge Ultra Controls for .NET Illustrative Samples"), which tells me
Oops. OK; instead of prowin32, I'll try prowin64. Nope. How about prowin? Hooray! I can run a demo of some .Net controls -- which teaches me next to nothing about PDSOE. But at least it's running! But wait! I spoke too soon. Whenever I press "Launch Sample," I get a small grey window with no functionality. Unless I run from code instead of the pecompiled runner.r, in which case I get messages like
I thought that my problem was the cultural differences, and language barrier, that limited my ability to find the documentation to what I wanted, so long time ago I stopped looking for documentation except for the win-help, which is very good (although not perfect), and kbase.
Starting with Progress would have been a pain if not supported by experienced people. Documentation for Architect/PDF/whater the next name would be, apparently is *not necessary* as it is "Eclipse based" (as if that were a good thing..)
My conclusion was (and still is), that Progress is not for new people, is for experienced users. The only way into Progress is by the hand of a experienced developer.. no available route for a standalone new user of it.. Maybe because no big company has such a user?
Certainly, Thomas. ABL is not hard to learn -- and the docs are a bit better there. But that's a different world. Simply getting a trial system and reading the docs is the way a lot of new programmers learn a system. That's how I got started with Progress. I don't think I could do that today.
If you (or someone like you) hired me, getting started would be much easier. Put me in a room with experienced users who can guide me past the rough spots, who will direct me to what I should read and what I should ignore, and who can answer the "stupid" questions without my having to spend hours searching for them -- and I would would be up to speed fairly quickly.
I would like to see a series of tutorials on how to build AutoEdge, or at least parts of it. It could step a new user through the tools and the development environment, and then in a second pass and step users through a second time to demonstrate best practices.
If you follow the manual, everything is there, in a simple and concise explanation, with references to the detailed material. You don't need to read it all, just search for what you are looking for, and it's there.
Progress has lots of excellent documentation, but it lacks the "manual" that guides you through. Adding the "global" manual will solve most of the documentation problems. And I don't mean a list of the available documents, but a very concise manual (that will be a huge one) with every subject, in it's shortest expression.
I've not looked in any detail, and apologies if you've found it already, but there is a getting started area that goes with the Classroom edition. Maybe there's some stuff here? documentation.progress.com/.../index.html
Thanks, James. I did come across that, and found that it pointed to a document on PDSOE which I had missed -- but which is actually worth reading: Progress Developer Studio for OpenEdge Online Help. I think I had ignored it assuming it was going to be something akin to the help facility in PDSOE -- containing some small nuggets of wisdom, but chopped up and impossible to simply read. I was wrong; it's an actual document, and it covers a lot of material. I don't know how valuable it will be, but at least it is a bona fida PDSOE manual.
Thanks, Tim. I agree with you -- I *loved* Pocket Progress. But eventually last copy (v9? I think) got so far out of date that it ceased to be useful. I can find things as quickly in the PDF of the reference manual.
But that only takes you so far. Learning ABL is not too bad; the reference manual is straightforward, and I don't mind reading material like that. It is really the IDE stuff -- PDSOE, Kendo UIB, etc that is making me nuts.
Aah I really feel your frustration on this :-) and I have been there as well. Hopefully one day there will be much better documentation. Till then I love the community, hoping for better days. //Geir Otto
One thing I would also like to add - it would be nice to have a list (one might exist but I don't have it) of what is required to develop an application using some of the newer than version 10 stuff. For instance I have progress 11.3 of Unix and windows but can only develop in app builder or vi (progress supplied by ERP vendor). I have been trying for a while to find out what I tools and software I need in order to start developing in Webspeed, or what is Progress Developer studio vs. Progress Studio, What is need to create a REST service or some Java connection through the existing Tomcat service I have. I have found this quite difficult to find this information
There's the legacy OE Application Server (asbman) which would require Developer Studio to build the WAR and link the JSON input/outputs to Progress code; this would be deployed using the standard REST servlet. But there's now the new Pacific App Server; which I haven't used since it's an extra for more or less the same functions.
This is sort of what I had figured out but I don't have developer Studio, and before going to try an purchase it I want to know what all the other pieces I am missing are, but cannot easily determine this. also until we upgrade the ERP release we cannot get an upgrade progress so no KUIB until a new version of Progress
Hire a few bright kids out of college, put them in a room for a month, and tell them to "learn our product." Then watch over their shoulders -- put someone in the room, use video, record their actual PC sessions, or perhaps all of the above. (I think of this is the "Jared Spool" approach.) You will find holes and plug them quickly that way.
Have a wiki page (or set of pages) dedicated to "getting started" docs, videos, tutorials, and the like. This should be well organized and will moderated; every link needs to be checked at least once a year. Make sure there is an easy way to leave feedback about things that don't work or are out of date. If the feedback is valid, publish it next to the offending materials until the issue is fixed; don't make everyone have to trip over the same problem.
Progress has some top people in many fields. Perhaps it could spare one or two of them for a year to teach a few classes at some local college or university -- say, one on Database Programming with OpenEdge ABL, one on Modern User Interface Design, and one on Working to a Reference Architecture. .Progress would make all of the necessary software available to the college at little or no cost -- much easier to do now that it has a subscription model with built-in expiration dates. At the end of the year, Progress would organize the course materials and offer them to colleges and universities everywhere. Partner with professors who want to teach something using Progress tools -- you supply the tools, they create the course materials for others to use. Maybe make a deal with students in these classes to supply them with a 2-year developer kit
The more new programmers you can get using Progress, the more exposure Progress will have across the industry as they get hired. And the greater the likelihood that a few of them will advance to decision-making positions and pick Progress tools in years to come.
4) Make it a cookbook. This is a repeat of my suggestion from above, included here for completeness. Come up with an interesting project -- like AutoEdge -- but instead of creating it fully formed as if from the forehead of Zeus, build it a small step at a time. (I have looked at AutoEdge code. It is nearly impossible to learn anything from it unless you are already an expert.) In addition -- and this is critical! -- as you move to more advanced topics (PDSOE, AppServer, BPM, Kendo UIB, Kendo UI, etc.), make sure that the other parts of the project do not depend on these modules.
4a15465005