What should i do Next?

D

dayv2005

Member
I just recently started learning Progress. I was doing .net and some Java developing. The only reason I chose to learn progress was due to the new job i got which is a computer programmer for this company.

I have a couple things i want to ask you guys being that you're experts in this field.

I been using the Progress software student guides from progress them self. They ordered me books to learn. I'm doing pretty good with them, but they are very limited (at least that's what i think). They are for OE10 and we use 8 here but it's all the same concept. Over the next year we plan on migrating our system into .net frame work using c#.

I was wondering if you guys could recommend anything else i could use to do my training for progress. We don't plan on upgrading to any newer version because of the future .net environment.

Also what are some pros and con for progress compared to .net and java Just so i get a full understanding of progress.

Thanks for any advice.
 
Boy, talk about doing things the hard way. If you would upgrade the Progress to current versions, you could do your Progress work in OO and leverage on your experience. With all the things that have been added to the language since version 8, you are probably going to get very frustrated using OE10 books because you will keep running into things that aren't there. Version 8 is antique. Moreover, if you would look into the stuff that PSC is doing with the forthcoming new UI, you will then be able to use all the .NET controls, but do so within ABL, thus leveraging all the existing code.
 
Dang, yeah thats what i was starting to think about to. I been reading how with OE10 being osmewhat OO from my understanding and the .net use with it.

I personally think that my company wants to go this route do to money. I mean we have the money for all the stuff, we are a fairly large company too. But i think they think they can save loads of money by just converting it all.

Thats why i was wondering the pros and cons of it.

thanks man
 
I can never understand why companies focus so much on the cost of licenses when the real value and expense is in the people. Has anyone sat down and actually speced out what it is going to take to completely re-invent this application in .NET? And then multiplied by three to get a more realistic estimate? And then figured in the cost of the developers to make that change? And the impact on business if it doesn't go smoothly? And the cost of the lost opportunity from just reinventing what they already have instead of moving forward from here? Not to mention the well-documented and rather horrible reality that a very large percentage of projects like this fail completely and of the ones that complete, a very large percentage are way over budget and significantly under featured compared with expectations at the beginning.

There are better ways. There are people who can help.
 
Yeah the did but they are looking to sell a good bit of our apps and stuff to other companies in the corp. We are the corp headquarters here and to be honest for a decent sized logistics company and leasing we have 4 main programmers ha ha. I thought it was gonna be crazy but not that bad. So ill be one of the few doing the migration i assume.

And yeah i figured we should just upgrade, main reasoning is our senior dev i don't think he has ever even used asp.net. But i get paid to do what they tell me too ha ha. I think theres going to be mad frustration when this project gets started. Whats crazier is we're corp Hq for all the companies so if we mess up we arn't the only people who's going to suffer from it.
 
Has anyone there ever heard of planning?

Can anyone there legitimately call themselves an application architect?

I think theres going to be mad frustration when this project gets started.

The big frustration will come when it is never finished!

Seriously, though, one of the ideas that you might want to bounce around is what I call a progressive SOA implementation. You start out by bringing in an ESB tool like Sonic and then take some particularly painful piece of the current application and convert it to a service on the ESB. Then you do another one. Gradually, you move more and more onto the bus. All along you are making small controlled changes and you keep a functioning system as you move forward with no big leaps. And, the system gets better and better as time goes on.

As you approach the conversion of any one service, you can decide whether to leave it in ABL or convert it to some other technology, although the ABL version is likely to be the fast and easy alternative. Same decision when you create a new service. As you gain experience, you can see which language or technology gets you the best result ... maybe even have a direct competition to see who can get the job done first with one service. And, you might find that some services are better suited to one language because of special interface questions or whatever.

From your brief description of the company, it sounds like an absolute natural for an ESB ... no better way to integrate the divisions and coordinate with headquarters. You can start with fairly simple data exchange and then move on to workflow management and all sorts of other interesting things.
 
Yeah i agree with you, i would sit and chat a little more but im done for the day man aint sitting here any longer haha. But ill bump this up some tomorrow sometime and what not, thanks for the advice.
 
The main point, of course, is to get some higher ups thinking a bit before they head down the wrong path. Who is driving this particular direction?
 
Are you using ADM(1) with your V8??
The Progress product is not really supported any longer. OpenEdge is the future, though as with all Progress Software Corp products backward compatability is realized.
Why are you even bothering with the outdated V8, instead you should be concentrating on the future.
The future is bright the future is OpenEdge - has the Edge to Open solutions.
 
Actually i ment to mention we were using v 9.1d but for some reason i was thiking we were using 8 i have no idea why though ahha.
 
it's not uncommon to have two versions, the progress version and the application built with progress, version.

it's sometimes easy to confuse between them.
 
The built with version is largely irrelevant unless there are issues about vendor support.
 
if what you mean by built with version, the version used in the development phase then i would agree.

what i meant is the version of the application and the installed/running progress version.

for example, mfg/pro version 8 something and progress version 9.1


in this case the progress version would be relevant to the available features, capabilities etc.

for example, if the customer was interested in web services, replication, sql and olap etc.
 
My point was that, except for vendors who refuse to certify old versions of applications on new versions of Progress, there is very rarely any reason for someone not keeping current. PSC has done a really amazing job of continuing to provide load and go transitions to new versions. The one big stick in the cogs in everyone rolling forward all the time ... other than the people who fail to pay maintenance, of course ... is people customizing a vendor's application so that they can't upgrade to a later release of the application and the vendor not certifying those older versions with new versions of Progress. That traps people in an island and is a perfect setup for someone deciding to drop maintenance and eventually to swap for a new application.
 
You must log in or register to reply here.
Back
Top