We just had someone working with a partner that was going to OE Architect. They understood all the mechanics of working with the product, but they didn't understand the best practices of how to use it. The best way to define projects, how to work in a multi-developer environment, how to migrate from AppBuilder, etc.
Any thoughts on that in the community?
There was a lot of best practice discussion in Sunil's talk at Exchange. It was a bit frenetic since he was covering a lot of ground, but I think it would make a great whitepaper ... especially if published in preliminary form and then we had a discussion here about the pros and cons. I know myself that there are some issues which are not that cut and dried, but more a matter of choices that one has to make. If Sunil would at least document the pros and cons of those choices, even if there isn't an absolute single recommendation, then I think it would be a very, very handy whitepaper.
Of course, the big problem with that is that I tend to want Sunil to be writing code, not whitepapers!
I have faced that teams starting with OEA need some time re-thinking their multi-developer strategy. Some of them (at least in Germany) have been using shared network drives for source code, configuration files etc. since ages. Eclipse works way better with local source code and some sort of a SCM tool. Some others had problems with having all the configuration locally in their workspace/project settings.
Screen resolution is another thing. Don't go with less than 1280*1024.
Mike
Bye the way: Powers of Progress - way a great title for a blog.
The problem that I faced when moving to OEA was that it was so different from the old editor / UIB / Appbuilder thingy.
It took some perseverance, and even now I still find things in OEA that make life easier, but would I ever want to change back ? Hell no.
fire up OEA, add some plugins (subclipse is a must for me - I know that there are other scm plugins that other people swear by) and get cracking
As Mike says, Local files for each developer works well for me / us.
I don't know that we have the expertise to have a set of best practices defined. Best practices require practice and the product is still very new.
This reads like our exact problem...
Our current setup is a network share with four main directories:
- work (this is where developers work)
- test (when development is ready files are moved from work to test)
- approve (when qa is ready files are moved from test to approve)
- done (when creating new PL files are moved from approve to done)
The propath used is usually dependent on the role: development / qa / support.
This setup works efficiently - one central source base, no mucking around with local sources. Disadvantage can sometimes be that projects get in the way of each other, but this can also be seen as an advantage.
My big question (mentioned this to Ken Wilner in the buffet queue at PTW Brussels) is what is the best way to translate this to OEA's way of working?
Local source and the use of an SCM tool is the way to go. CVS and SVN will do for simple scenarios and are for free (and if you are currently copying file manually that would probably work for you). Roundtable and Perforce offer more control of imports between branches. I use Perforce and that works perfectly. Also very handy if you need variants of a set of files for multiple clients.
A shared network location for projects (not the workspace) is theoretically possible, but Eclipse will complain whenever somebody else but you modified a file (tools like the Multi file search will report an error). New files don't show up automatically, you need to Refesh the project all the time.
When you are working quite often in all 4 code locations, you might have that (no matter if using a SCM tool or not) within 4 projects in the same workspace (offering 4 propath settings, different db connections for the OpenEdge runtimes). You can close projects that you don't need right now. The will also prevent launching the OpenEdge runtime.
Hello.
"Local source and the use of an SCM tool is the way to go."
Spoken like a true developer. :-)
...however not all companies allow or desire this. Quite frequently customers and prospects tell me that that want a more secure development environment (i.e. they don't want developers pulling source code down to their local machines, they want to control which databases the developer's compile against, etc). This is most due to newer auditing and security restrictions they are under.
A company's codebase is it's intellectual property and it's a valid concern for them to want to protect that. Having a consultant come in, check-out all your code to his or her laptop, and then leave with it can be considered dangerous.
I believe that the Eclipse platform has recognized that one cannot always assume that resources are local and thus have implemented the Eclipse File System API in 3.2 (unfortunately, this isn't fully supported by the OEA).
Moving forward, we (Roundtable) will be taking advantage of this more and more by providing a Roundtable filesystem which will enable us offer a "secure" SCM solution.
"But then a network share won't help either. If a locally running prowin32 needs to get (read) access to source code in order to be able to compile or syntax check the same suspicious consultant would be able to copy everything localy as that requires the same privilegue."
Exactly.. hence the EFS. The repository objects "magically" appear as resources and all programs that work with resources could interface with them as if they were local resources. However, since it's based on your own implementation of an EFS, you can control what they do with them.
Not a perfect solution, but with SVN you can (I do) manage access to the files inside the repository in a folder by folder fashion... So no consultant is even allowed to read the files...
Regards,
Daniel
Right. But as far as I understand Jeff, the Eclipse File System would allow consultants access to the files while they are at your site, but won't allow them to take the files home.
Hi!
You are Not Alone!
I have been looking at the OEA for almost a year now, and remember posting a similar request on PSDN and ProgressTalk - after a couple of weeks, almost 500 folk had checked the request, just a couple of replies on each, maybe two helpful.
My experience is simply that Progress do not know themselves - we have previously been promised a 'Best Practise' document, but this has not materialised - I doubt its existence!
We have had immense hassle -especially linking through to Oracle, and it took Progress a significant amount of time to get back with a solution ( to be fair they did get us a solution, not the best answerm, but a solution).
Progress seem to take the position that the OEA depends on third party tools, outside their control, so are unwilling to provide any indication as far as Best Practise for the OEA.
It is my feeling that the Best advice/Support will NOT come from Progress, but from the Progress World - coslty R&D and then those willing to share the R&D...
One word of warning as we have found to our cost -DON'T DO OEA WITH 10.1A, at the very least delay until 10.1B (or later)...!
That comes from having a consultant visit our site recently....
The OEA does look a good option, alhough it might be worth going with Progress added to an Eclipse installation...
Given the fluidity of Eclipse Plugins, the only way isR&D - try & see...
Your current scenario and needs will be different most other teams, so R&D is the only way forward....
Apologies for no nice, clear, answer - I believe that the answer simply does not exist, although perhaps it could be 42...
This is a great discussion and you guys are quite correct - we (Progress) unfortunately do not have all the answers! We are however listening to the experiences of people moving to OEA, we are looking at the rest of the community and visiting customers to better understand the real world use cases. What we do know is that the typical OpenEdge persona and use cases are quite different to non-OpenEdge personas and use cases, e.g. Java developers and so just following Eclipse best practices may not be the best thing for our community.
We do plan on putting together more assistance in this area as to possible use cases for moving to OEA project-based approach - but before doing so want to ensure we fully understand the realities (so doing more research - actively)
We can offer best practices till we are blue in the face, but the reality is that in order to adopt OEA you will first likely need to stay with a less structured approach that is similar to your existing way of working, hopefully with some more controls in the way of SCM. That is what we have seen so far anyway.
We are working in this area too to better understand how we can make OEA more productive when projects are not configured as we would like, e.g. you have huge projects containing thousands of source files, large database schemas, etc.
Any thoughts anybody has in this area would clearly be very helpful - the more data we have, the better job we ca do to make it all easier.
Thanks, Ant.
We can offer best practices till we are blue in the face,
I for one am curious as to where these "Best practices" come from. Outside of ADM, Dynamics, and the admin tools (which haven't been updated / redone in how many years?) - how much 4GL / ABL code does PSC actually generate to derive a "best actual practice" (or should it be "recommended" practice?) as opposed to a best practice "in theory"?
good point Tim - we prefer using "principals" than "best practice" as best practices is probably not the best term to describe what we would offer from Progress. There is such a diverse set of use cases that there really is no single answer - that we have learnt along the way!!
What is more relevant is to understand common use cases and the pros and cons of approaches to solving those use cases - as I think was suggested earlier in this and other threads. That will likely be our primary focus.