Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Has anyone used Oracle Coherence? It looks very promising at the roadshows.
My concern is whether it's a stable and robust enough to implement mission-critical financial solutions.
I'd be grateful for any feedback on its performance, robustness and ease of maintenance.
I've had first hand experience with Oracle Coherence at two big investment banks and can say it's definitely stable. However, as with any complex piece of software it's not without it's quirks.
EDIT: Doh, just realised the question is over a year old. Oh well...
Coherence is in production at hundreds of companies. Many of the companies are large financial institutions and large consumer websites. For example, hotwire.com uses Coherence.
As with any technology, Coherence has the capability to meet your needs for performance and robustness. If you understand the technology and implement it correctly, then yes.
I've been using it for a few months now. So far, it's doing fine in production. We haven't gotten to the maintenance part yet.
Oracle Coherence is a mature product, but you need to make sure that you have the latest patches from Oracle. The point releases that are downloadable from the Oracle website have many bugs that are fixed in the patch releases.
As for development and maintenance, the learning curve is a little steeper than the documentation would suggest. I recommend the Oracle training course (or Alek Seovic's book).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
When migrating Oracle Forms and Reports, there are several options for that :
ADF
APEX
Yor suggestion ...
Which one do you think is the best in terms of business continuity and also ease of technological transition? Do you have experience in such migrations?
At the end, I would like to know if it would be necessary to migrate or just keep "Oracle Forms/Reports"
Regardless of what tool vendors might say, this is going to be an exercise in rewriting your application.
So the real questions is, why do you want to do this? Oracle are continuing to support Forms for some time yet. There are plenty of things we can do to modernize our Forms applications whilst retaining our investment in the existing software. I urge you to look at Mia Urman's presentation Give Your Forms a Facelift: Tips and Tricks for Forms UI Modernization which she gave at a UKOUG event I helped organise a couple of years ago.
If your mind is absolutely set on a re-write you'll find APEX is the easiest path for developers with a Forms/ PL/SQL background.
Update for 2018:
Oracle have been getting back behind Forms. The 12c release had over 100 new features. Okay, some are quite minor but it's a clear statement of intent. Find out more.
It's a big "it depends". ADF is a comparable alternative, while APEX is easier to learn and find resources to build.
The developer tools statement of direction is a great place to start and a while ago I provided my own commentary (http://www.grassroots-oracle.com/2012/03/on-oracles-statement-of-direction-for.html)
i think you should also check oracle JHeadStart , as mentioned in the documentation :
JHeadstart Forms2ADF Generator; creates ADF Business Components and a
JHeadstart Application Definition file based on Oracle Forms files
Hope that Helps .
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I came to a successful project with 4 years old, it is already in the production.
The problem is that, the project is not documented anymore, it depends on 2 senior developers only, they know the system, they test, they handle change of requests..
I need to know what is the best practice, or what are the main steps that I have to do in order to document all the modules starting from high level design through component analysis & design, code comments, till the configuration management.
The traditional project management processes don't give me a clear idea of how to take the control back of a an old project.
Thanks.
Senior developers will easilly get bothered if you make them write docummentation all day long so you may lose them at the end.
I would hire a technical writer / junior developer if I were you and give him or her this as a first task. I would also make him or her work closelly with the senior guys, without taking too much from their time (like aggregating questions and have a one hour session dailly or something like that).
It will probably hurt in the beginning but if properly executed should prove a good choice at the end.
Note: The level of cooperation between your senior guys and the new guy that will be doing the documentation may vary depending on some internal "political" things like if the developers feel threatened by the fact that you are trying to make them less critical to the project, how overwhealming the new guy / gal is to them and so on. So answer those questions before going for it.
Once again - it is my personal opinion on the given topic and its success will definatelly depend on various factors. So you should decide if it is a good way to go or not.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I understand that it is better to discover requirements through iterative approaches in Agile, however I often hear of people rejecting projects on the basis that they are given up-front requirements.
Why is this the case? Why can't up-front requirements just be taken as-is, e.g. just added to a product backlog and then prioritized and implemented?
There's nothing wrong with up-front requirements. In fact it helps to know where you're heading before you set sail!
Agile is a lot about being able to be adaptable, so that should requirements change you're not locked into something you don't want.
The kind of up front requirements that would cause a developer to think twice about a project, would be those which indicate that the client are likely to be a nightmare to work with:
an obsession with one particular, unsuitable technology or presentation style
insisting on 'security' with glaringly obvious vulnerabilities
In an agile project, it's good to show a client the current state of the partially working system at an early stage, and get feedback, using this information to help design the subsequent parts of the system. If a client is too fixed on ideas of the final product then they might not be able to give useful feedback at this stage, and the final product may be not as good as it could have been.
This something that can be quite problematic with Agile. Some teams will use it as an excuse to not have a plan as they want to be 'adaptable'. Requirements can help to focus on the software architecture, which is something else that is not always given much focus in some Agile teams. It is points like these that lead me to believe that Agile should just be principles but not a methodology. Digital Animal wrote an interesting article about how Agile can be used in such a way that it stops being effective. For some teams, it is better to learn from what is great about Agile and use it to build a methodology that works for them. http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/?AT=CZcb6f
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Our company just decided on Oracle as our new ERP solution. As the current in-house Developer of our WMS/ERP system (VB6/C#/ SQL/VFP) What skills, references, things to learn, words of wisdom you recommend to get a head of the curve for this supplementation.
By "Oracle is our new ERP system" do you mean you are migrating your custom code to an Oracle-database based system?
If that's the case, Oracle Database concepts guide is probably the first thing that you should get started with. There is obviously a big learning curve to this and it will take time, but as someone who understands the existing system, you are definitely at an advantage.
If you mean you are moving to a vendor based (oracle being the vendor) ERP system, there are many systems out there that Oracle has released into the market and each of them with a different technology framework and underlying components. Eg..If you are moving on to Oracle Apps 11i modules or E-Biz, Java and Oracle Database would be the underlying components that you need to concentrate on first. If the ERP system is the new Fusion Applications suite, Oracle's ADF Framework is the place to begin.
By the way, any specific reason why they have such a HUGE shift in the technology stack?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Does anyone know of any software or a good way for developers to build up a knowledge base of business rules that are built in to the software for help desk to use?
We already have a helpdesk software but we are not looking to replace this.
A wiki is definitely the way to go. Processes change, sometimes frequently, and in a fast-paced environment like a help desk a tool that allows quick, easy access and management of that type of content is extremely important to allow people to do their jobs effectively.
One of the greatest benefits I've found is the heiarchical sturcture of many wikis, allowing employees to find the correct content from a number of different customer angles.
Can you be more specific?
This may fall under "policies and procedures" management software. Here are some:
http://www.softscout.com/software/Human-Resources/Policy-and-Procedures.html
I'd like to find one that's more wiki-like or easier to integrate into a a website serving as a more general company knowlege base.
I would recommend a wiki wiht a "Wiki Gardener" role- someone who cleans up the duplicate entries and sorts.
Wiki technology with a Rich Text Editor option would useful if your Support Desk are not totally technical.
Having some structure is imperative, developing something in any Wiki that makes sense to the general editing populace, and has a low threshold to get from reading to editing. You will also possibly need a migration strategy for taking hundereds of little notes into something more readable and searchable.