Susan Duncan

Subscribe to Susan Duncan feed
Filtering the Muddy Waters of ALM, Team Development, Database and Oracle ADF in JDeveloper
Updated: 4 days 6 hours ago

ALM - help me help you!

Tue, 2008-04-22 04:34
Some of the areas that I've always been interested in - as a consultant, a teacher, a curriculum developer or as a Product Manager - are standards, methodology and development process: From Designer to JDEV, from CDM to Agile, from ClearCase to SVN, from IE to UML and so much more. Now we call that ALM - Application Lifecycle Management - the management of the lifecycle development practices (requirements, build, test, change control, defect mgmt etc) fused together through application of process, reporting, traceability and collaboration.

Here in JDeveloper land we are always looking at ways to improve both our tooling and the developer experience so I've put together a survey to find out what ALM tools you are using today. We're looking into adding better integration with ALM tools and the results of the survey will ensure that we move in the right direction.

So please, take a couple of minutes to complete this quick online survey and help me help you!

Evil Clones - The SCM nightmare that can stop you in your tracks

Fri, 2008-02-08 09:04
It can happen to anyone. First the feeling of disbelief, then the cold sweat; you try pinching yourself, hoping it's some bad dream and you'll wake up and they'll be gone . . .

There, that's my catchy first line of my first novel written, now just the other 150 pages to invent. But unfortunately it really can happen to you - if you are working with ClearCase you may have come across evil twins. But I want to talk about a different nightmare that can occur if you are using SVN or CVS.

Here's the scenario. You and a team member are both working on a file (let's call it MyClass1) checked out of SVN.

Your colleague, as part of her edits, renames MyClass1 to CloneClass1 and commits the working copy.

SVN uses copy/delete commands for a rename:
First MyClass1 is copied (so that the history is maintained) to CloneClass1.
Then MyClass1 is deleted from the repository.
The screenshot of the SVN repository (left) shows the new resulting file with CloneClass1.

CVS is not quite so clever is uses add/delete: It adds CloneClass1 and deletes MyClass1 - so none of the history of MyClass1 is copied to the new CloneClass1.

But back to the SVN example. You have edited the checked out MyClass1 and are oblivious to your team member's edits. Not a problem, you might think as an update from the repository would absorb the changes or at the very least show you a conflict over the rename. Unfortunately not!

Here is where the nightmare that I'm calling Evil Clones appears.

The repository rightly updates your working copy with CloneClass1. But wait, your class MyClass1 is not only still in your App Navigator, but is no longer under version control!

If you think about it, this is correct -
  • SVN has replaced MyClass1 with CloneClass1. It has no recollection of the object MyClass1 so there is no merge of MyClass1 and CloneClass1.
  • You wouldn't want to lose the additional changes you have made to MyClass1 in your working copy - and it is not under version control - well, it's not, because it doesn't exist in the SVN repository
  • You can easily recognize that MyClass1 has been replaced by CloneClass1 so it's a simple job to move your changes to CloneClass1 - or is it. . .
This is expected behavior from Subversion and it seems that they recognize it as a bug . The example above is very simple. But what when you have 00s of different files in your working copy?

I'd be interested in how you work around this shortcoming in SVN. Here are some of my thoughts:
  • Don't rename, if you think you must, think again!
  • If you must, then refactoring or plain renaming of files (this is not specifically a Java problem, could be XML metadata, diagram or any other file type) should always be taken seriously in team development. In our JDeveloper development teams it's usual for the developer thinking about renames to email colleagues, check for dependencies and most definitely comment both the code, the check-in and the build notes to minimize the possible problems.
  • How renaming is handled in your team should be part of your defined development process. It should take account of your source code system, your build system and provide workarounds as necessary
  • If you are using JDeveloper and find that one of your objects appears to 'lose' its versioning status after an update - think rename!
  • Always ensure that you fully comment a rename on commit so that other users can use the log to find out where and why their object was deleted from the repository
In a forthcoming post I want to look more closely at how you detect and work to correct a rename problem. Specifically I want to use JDEV's offline database objects to do this. In the Java world developers may be more aware of the power of refactoring. But, as I said above, this is not a problem restricted to Java. I want to highlight the effect on XML and database objects.

At what level should I version my source code? - Alternate Takes

Fri, 2008-02-08 05:04
So now you know that I'm a Blues fan. One of Blues most revered artists was Robert Johnson. There are only a very few recordings of him - done between 1937 and '39 - just 29 different songs, but there are alternate takes bringing his total recordings to around 40 songs. Maybe he was striving for perfection, maybe different styles suited different audiences or even his moods, but these alternate takes add to the legacy left by him. Some blues fans have their own favorites but I love them all!

Recently I've been speaking with a number of JDeveloper/SVN users concerning the level at which they version their code. While I still maintain that the best way is to create a working copy at the Application level there are times and development process requirements when this isn't practical or possible.

Take this example: A team development with one Application split into many Projects. The Application is under source control using SVN. Their development process mandates commits are done per Project. There are a number of ways to achieve this, here are my suggestions for a team member to work on one or more projects and be selective about what is committed:

Alternate Take 1: Check-out each project as a separate working copy
  1. Create a new empty Application with no projects
  2. Use the SVN Navigator to select the root node of one of your projects in the repository
  3. Check this project out of the repository
  4. For the check-out destination, select the root folder of your newly created application
  5. You will get a warning on the Confirm Check Out dialog that you have selected a directory that is not empty - this is OK
  6. Continue to check out projects under your application root folder

  7. Now you can use JDeveloper's Commit Working Copy command on any node in a specific project and that project's changes will be committed.
Alternate Take 2: Filter the Outgoing Pending Changes Window

Using JDeveloper 11g you can filter the Pending Changes window by application or project. In the screen shot below I've filtered my outgoing changes to myProject1. I can select one or more of these files and with the context menu Commit Working Copy or Commit. I'd choose to select all the files and Commit if I had checked out my Application as the working copy. I'd choose Commit Working Copy if I had used Alternate Take1 to check out each project as a working copy. Unfortunately JDEV 10g doesn't have this filtering ability so this is an 11g only Alternate Take

I'm sure there are other Alternate Takes to both the level at which you version your code and how you manage checkin/out. I'd love to hear the good practices and the pitfalls.

I got tagged in the <a href="http:/

Mon, 2008-01-14 09:01
I got tagged in the Oracle Blogsphere tag game by Shay Shmeltzer so here goes my entry of 8 things you didn't know about me.

1. In 1973 I was sent from Reading, UK to live on a cotton farm and attend high school in Arkansas, USA for a year by AFS Intercultural Scholarships. At the end of the year I was inducted as an Arkansas Traveler. Even now I drop into an Arkansas drawl the minute I reach the Delta - love it!

2. This started my love affair with Blues. It grew and developed after I met my husband, Scott, through his research for the original writers of songs recorded by such great guitarists as Rory Gallagher. In about 1986 during a blues festival holiday in Memphis (TN) we met some people who have become our great friends: David and Liz Berntson who, earlier in the year, had founded the Tulsa Blues Society. Also first met Paul Jones who was in Memphis to cover the festival for BBC Radio. As a result of these meetings we arrived home to find Paul had talked about our ideas on air and we started the British Blues Connection and the magazine Blueprint.

3. During over 10 years of the British Blues Connection and Blueprint, we became the first overseas Blues organization to be affiliated to the Blues Foundation and were Keeping The Blues Alive award winners in 1990. In the late 1990s we passed the UK blues gauntlet over to Blues In Britain

4. I love music, singing and dancing. From working the amateur chorus lines in productions like Lady Be Good in my 20s (when I was younger, thinner and more flexible!) to singing and dancing with blues men or my fab musical family or anyone who will let me. One of my special blues moments is dancing on stage with Willie Dixon when he presented us with our KBA Award in 1990. But it's not just about Blues, I love music - from Karaoke to Kraftwerk, Blues to Bartok and all the Kings (Elvis, Freddie, Albert, James, Frank, Bob ....)

5. I love to travel. I'm not sure I'll ever make the Traveler's Century Club (think I'm at about 35 currently) but I like to take every travel opportunity (whether work or leisure related!) Last year I added South Korea and China to my list and this year, as well as Europe and the USA, we will be in Rio to celebrate the wedding of our good friends: Blues man Alamo Leal and Mariza Lopez

6. My first personal computer was an Mac SE30 Bought this in 1989 when Blueprint became a magazine that could no longer be pasted and photocopied on my office copier but had to become more sophisticated as its readership grew. I learned how to use Adobe Pagemaker and spent many long, long nights waiting for the tiny screen to refresh as I moved across its 32 pages adding articles (Scott was the editor) and leaving space to paste in the photos. This was also the time of my introduction to 'programming'. I used spreadsheets and macros to maintain the subscription list and create mailing labels. At the time I thought I had designed a database!

7. Oracle is my second career. In my 20s I was a Financial Controller for a SME US company in the UK and started up subsidiaries in France and Germany for them. In my young, thrusting days I was even a finalist in the UK 'Young Career Woman of the Year' (can't remember which year - didn't get far). Later I took a Computer Science degree (for fun) and decided to try life at Oracle - the rest is history!

8. I have two favourite types of footwear! In the summer it's hard to imagine not being in flip-flops. I have many, many pairs - including High Havaianas that can make that awkward transition from shorts to cocktail dress ;-) In the winter I move into cowboy boots - the most comfortable footwear ever. But be sure to get a good brand. For me that has to be the Ariat.

So, if you see a flip-flop carrying, cowboy boot wearing, laptop hauling Oracle Product Manager demoing with blues-inspired examples - be sure to say "hi y'all"

I hate chain letters but who am I to deny you the opportunity to join the fun? So I tag Sue Harper, Kuassi Mensah, Doug Clarke, Eric Rajkovic, Brian Duff (sorry)

At what level should I version my source code?

Mon, 2007-11-05 09:11
This is a question that comes up regularly when I talk to development teams. And I believe that the answer should always be - at the top level.

If you are using JDeveloper this means at the application level. We adopt this in our own development here and it's my top tip for best practice. Some might want to argue that if their application is broken into a number of different projects then why not version those individually?

One problem with this approach could be cross- project dependencies in your application. Imagine that you work in one project on a day to day basic but there is a dependency on libraries held in another project (let's call it a 'library' project). You might checkout both projects at the beginning of the development cycle but assume that the 'library' project was complete and so you could just work and update your 'working' project. At some later stage, you could run into problems when you want to check in your 'working' project and realise that updates have been made to the 'library' project.

On a practical level, if you are using JDeveloper, you should not only follow my advice and version at the application level, but always ensure that your .jws configuration file is included in source control. This isn't a problem if you using JDeveloper's integrated SVN commands. When you select an application you automatically get the .jws file included.

But what if not all your development team are using JDeveloper? Perhaps you prefer to use Tortoise for your SVN interactions. Or perhaps you have some team members that use Eclipse or another IDE as well as JDeveloper? In this case it is important to ensure that you still place both your 'jws' and your 'jpr' files under source control.

Why? Because JDeveloper's SVN code looks at the state of those files to decide what menu options it makes available. For instance, say an initial import of an application to SVN had been done using Tortoise and the .jws file had not been included. I then check out this into a working copy in JDeveloper and make some changes. When I try to commit or update this working copy using JDeveloper I would expect to get the menu options 'Commit Working Copy' or 'Update Working Copy'. In fact, I would only see 'Import Files' as the .jws files would not be part of the versioned application and so JDeveloper offers you the option to place the application under version control.

I've come across this a few recently. The workaround is to go back to the repository and add the .jws file to version control. This brings the IDE back into kilter and allows you to continue using JDeveloper's integrated SVN support.