DDE does disruption (4) – xHausting

Yes, DDE is disruptive again!

Today I wanted to copy some code from one application into another, straight via DDE, an a phenomena that I experienced earlier occurred again:

Most XPages and Custom Controls became signed with my Notes ID

With most I mean ALL XPages (20) and most Custom controls (31 out of 34). All other design elements in the NSF (forms, views, pages, agents, script libraries, java design elements, java libraries etc were untouched.

At the moment I had only open: one server-side JavaScript library and one XPage.

Do you have any explanation for this?

I am running 9.0.1 FP 9.

Advertisements

DDE does disruption (3) – Perhaps DDE is not build for it?

I am still complaining about DDE because I am facing the following situation:

I am working with a colleague on a project. Our code resides in a central repository on TFS. We both develop with a local clone and we sync towards our own NSF on a Domino server where we do our development work. The problem  is that she is unable to build the project and have her NSF running. I do not have those problems but perhaps that is because I have written most code lately. When I build HER NSF, the application WILL run.

We have a similar setup (version DDE, installed plugins).

When she performs a clean, build, refresh she does not get errors or anything whatsoever. What might cause that her build process does not succeed or complete?

DDE does disruption (2)

For some reason I was unable to open JavaScript libraries in the JS editor in DDE. It concerned both client- and server-side libraries. LotusScript and Java libraries I could open just fine.

The only thing I could see was this:

The problem was not concerned all databases, but at least the problem was consistent in multiple NSF’s. Building and refreshing the project no effect. Also removing the applications from the workspaces, restarting DDE and re-opening the NSF’s did not change the editor’s behavior.

At this point I was getting a bit annoyed. Colleagues reported similar problems in the past but none had a suggestion other than re-installing the client.

So I let my stubbornness win and installed Feature Pack 9 instead. After 10 minutes (!) the installation was complete so I started DDE and opened the unwilling script library. Hurraaaah! The problem was solved, I could see the code in the editor.

However I noticed some missing in DDE: the nice Swiper 2.0.1 toolbar buttons where gone! So I removed the files from the notes/data/workspace/applications folder, downloaded Swiper from OpenNTF again and installed them. Back to normal. Well not quiet yet.

When working on an XPage I noticed that all the plugins I was using where not recognized anymore. For example the Debug Toolbar plugin. Again, I could not see the plugin disabled under Application Management. So I removed the files, downloaded the plugin from OpenNTF and re-installed it. Now the plugin was visible again in DDE.

So the feeling I am left with is that this Superhuman Software is not so Superhuman anymore.

DDE Does Disruption

This week we received an incident about an application that was not accessible any longer. It turned out that all the design elements where signed with my Notes ID which has (of course) insufficient rights to run in the Production environment.

The curious case here is that nobody intentionally replaced or refreshed the design of the application.

The application still had the “inherit design from template” option enabled. However the template resides on a different server and there is no replication between the Production and this staging server.

I know I have the two databases somewhere in a Working Set in my Domino Designer so most obvious option for the design refresh must have come from my workstation even though I have not worked with these applications this week .

Have you experienced something similar also? What was the cause?

Source Control disruption in DDE

In a project me and my colleague faced major complications working towards a GIT repository on TFS. In short: she did not see the changes I had made in her Domino Designer even though her GIT client had transferred everything correctly to the On Disk Project (ODP) on her local drive.

It seemed that the problem was totally focusing on her development setup. For the good order here is how our both environments look like:

  • Me: TFS, SourceTree, Domino Designer FP8.
  • Colleague: TFS, Visual Studio, Domino Designer FP8.

As a result we are facing major delay in the project because we can’t rely on the setup so we are 50% developer resources short.

So in order to test our bad experiences we sat up a small test with some other colleagues to see if we could reproduce the disruption and allocate where it occurs.

We had no particular test script in mind. We just sat up a new repository on TFS, we cloned it locally with different GIT clients, imported the ODP’s in DDE, created new NSF’s from it and we started to make changes in them.

Luckily for us a new disruption appeared fairly quickly. Changes made by two of my colleagues did not appear in my NSF but they could see each other changes.

It turned out that the changes where in my ODP but DDE was not able to transfer them in the NSF.

Here are some dumps that shows the situation. The use of capitals in the H2 element are not similar.

XPage in DDE:

XPage in ODP Project in DDE:

Same XPage in ODP on local drive:

Removing the imported ODP, removing source control with the NSF, re-importing the ODP in DDE and re-establishing source control for the NSF with the new project caused that I could see the changes in the NSF. However with the next change which a colleague made we were facing the same disruption on my machine.

For us it clear that this is not a work situation we can trust when DDE is not able to make the transition from ODP to NSF.

Have you experienced the same and have you come up with a work-around?

For us it would mean that we can not complete the DevOps chain that is set for development environments…