Many people responded. Eventually there was a recurring theme: it's all about the apps. There are few in the Yellowverse as eloquent as Tim Tripcony. And he articulates this point very well in his comment (number 20 in the link above). There are open source efforts (CouchDb, NoSQL, etc.) attempting to recreate the flexibility of the NSF database format and replication. They aren't mature. They don't scale as well. They don't have IBM's support arm behind them. They don't have the ACL integration that N/D offers. They don't have an RAD environment wrapped around it with the slick design inheritance that DDE provides. But everybody has email. Let's hope this message sinks in with the IBM upper echelon.
Here's Tim's comment in case you can't be bothered to click on the link: -----------------------------------------------------------------
----------------------------------------------------------------- Bravo, Tim.
|
 Ratings
0
|
I love the Fix List database. Sometimes the write-ups are a little vague, but generally they're chock-full of great detail.
But there's a general theme throughout most SPRs that really bugs me. SPRs like this one. Can you spot it?
Fixed in 8.5.2: SPR# CSCT7V2RJS - This fix disables all compute actions for the conflict losing document since a computed field can in turn try to open up a database and require a lock. The conflict losing document will not have computed fields calculated but all other data should arrive in the updaters mailbox.
It's right here: "All other data should arrive in the updaters mailbox."
Um, conflicts affect WAY more than just mail, guys. Mail's just an app, one of many that N/D ships with. Will this affect the discussion template? Wiki template? How about my custom apps?
A fair number of SPRs are written with a mail-only slant. I've had PMRs come to a screeching halt "oh, that's only reproducible in your custom app? Sorry, let us know if it's reproducible in the mail template." Even the Lotus Knows campaign has had a mail-only slant with respect to N/D. Oh, with a slight mention of Composite Apps.
This is all proof to me that there needs to be an organizational-wide shift in mindset about emphasizing the app dev component of N/D. After all, this is the value of N/D. It's what keeps companies on it (even IBM couldn't replace NSF) and why new companies choose it ("You can do soooo much more than mail.")
If IBM really wants to get serious about it they should eat their own dog food: base N/D 9's mail template on XPages. Stop building closed-box compiled stuff (iNotes) and quit leveraging hidden C API calls for functionality. Heck, base all of the templates on XPages. Roll out internal IBM workflow apps on N/D and XPages.
If they did that, I guarantee you all of the Designer-on-Eclipse bugs would get fixed REAL fast. We might also get some updated templates as a result. The entire platform would be better off in so many different ways.
But the simulated user load tests for mail would probably experience a performance drop for a couple of versions. The current mail setup is heavily optimized. So it's doubtful this will happen for mail. But they should at least do it for the out-of-the-box apps.
Microsoft writes the next version of Visual Studio using.... Visual Studio. Do you think it helps the success of the product? Absolutely.
Now, obviously you wouldn't write DDE in DDE (in Eclipse perhaps, but not in Designer itself.) But if IBM increased usage of DDE and XPages internally I think we would all be better off.
|
Ratings
0
|
Just some more brainstorming thoughts while I've got a free moment...
2. Keep pushing forward on XPages and Dojo documentation. 3. Offer a free cloud hosting environment for XPages apps. E.g.
Something similar to Blogpress. IBM already does this via their cloud and Amazon's EC2
cloud... almost. Maybe make the first 10MB of storage free?
4. Have Niklas Heidloff create a 20 minute "Hello World" video that starts with downloading Designer Lite and ends with a live "Hello World" XPage on the web. 5. Promote it a tiny bit.
Low-cost-of-entry, cutting-edge JSF+Dojo integration with NSF flexibility, ACLs, replication, and design inheritance? There's just a couple of programmatic pieces to work out (e.g. implement SSJS for scheduled agents and views) but I'd bet a fair amount of cash that it would go viral.
|
Ratings
0
|
Here we go: A $5 Notes/Domino app that will likely have 1000 downloads by the end of the month.
To quote the infamous Will Ferrell as Ricky Bobby in Talladega Nights: The Ballad of Ricky Bobby: "What does that do? Does that blow your mind? THAT JUST HAPPENED."
Um, IBM, you just maaaaayy want to build an app store. Just sayin'.
|
Ratings
0
|
|
Great news! We're looking to hire a Notes/Domino developer with XPages experience. You'll be working on the most complex Domino web app in history with an awesome team of people.
This is a full-time position in Tallahassee, Florida and relocation expenses will be considered.
I know XPages are still relatively new technology, so if you've only got a few months' experience that's fine. If you've got no XPages experience but have a lot of experience with legacy Domino dev on the web, that's fine too. We're interested!
If you are interested, please email resume and salary requirements to me at {erik}
{archondev.com}
|
Ratings
0
|
A few weeks ago we all screamed "We want XPages documentation!" at IBM.
I started looking around the 'net for more IBM-initiated promotion of XPages. Did you know there's a Wikipedia article about the technology? It's about as sparse as the documentation.
Compare this with this.
Fortunately this is better, but that XPages article is still pretty sad.
Ideally the page would be beefed up by IBM, but since anybody can edit Wikipedia we can all get in there and contribute.
|
Ratings
0
|
If you're reading this, no doubt you've read Ed's blog post asking what the "tripwire" is for Lotus Notes/Domino app dev.
The comments had some resounding themes:
- IBM doesn't market Notes as an app dev platform
- IBM sales actively (though perhaps not intentionally) offers incentives to sell something other than Notes/Domino
- The N/D app dev strategy is unclear
- IBM needs to attract young blood to N/D
This blog entry explores an idea to tackle the last two points. I started commenting about this on Andrew's blog and I decided it warranted its own entry on mine.
If you want to attract young blood your software needs to:
- be useful
- be free
- be based on open-standards, preferably open-source
- be easy to learn
- be fun
- be "cool"
IBM has almost got a perfect solution to attract young devs: Domino + Designer + browser.
Young devs don't care about the Notes client. It never existed to them.
Their client for their entire life has been the browser, period. So forget the thick Notes client. Don't mention it at all.
Imagine if, when you installed Designer, you had two options: "full" and "modern only". The first is DDE as it stands now. The second is still Eclipse, but has only the following features:
- XPages
- Java
- SSJS
- Agents
- Views
Feature-wise that's almost a slam-dunk for a college crowd. Especially when you throw in replication, security, and template inheritence. Then your only real issues for new-developer uptake become:
- Agents can't run SSJS
- No offline/local functionality for XPage delivery
- You need to know @Formulas for views
The first is an obviously logical thing for IBM to add. The second is also (DOLS is ready, IBM just needs to add XPages to it.) For the third, views could simply be updated to use SSJS. Or a new design element ("indexes?") could be introduced to replace them and tackle all of the other indexing problems currently faced by NSF: real-time querying, filtering, grouping, sorting, and JOINs that we've all been asking for for years.
Voila: a "Designer Lite" built on Eclipse, where a novice dev can get going immediately using just SSJS. If they're hardcore they'll use Java too, maybe even digging deep in the JSF. But SSJS is the only language they need. All of the "classic" things that made Notes explode onto the app dev scene are still there: security, replication, agents, templates, etc. The Designer sidebar and help would be lean and mean: no entries for outlines, layers, shared fields, forms, subforms, etc. And the thick Notes client could still consume anything made in the lite version.
Since it's Eclipse, you could offer the legacy stuff as plugins. If a project calls for Lotusscript support, somebody can download and install the plugin.
Don't include any legacy templates. If that means not installing e-mail, then so be
it. Either avoid the template entirely or rewrite in XPages. Require internal template dev to eat IBM's own dog food. Everything shipping
with "Designer Lite" would need to be XPages and agents, all documented well so new developers can use them as starting points.
IBM could keep pumping nearly all dev money into NSF, XPages, great custom controls, and great stock templates. Lotusscript, Composite Apps, old-school views, etc. could all take a backseat. The future is NSF, with XPages browser delivery using SSJS/Java. Isn't this where project Vulcan is headed anyway?
The trick here is packaging. It's got to be free, VERY easy to obtain, and well documented. And it needs to be easy to deploy a free Domino server (yes, even in production if I'm a student.) There needs to be a small, lightweight website similar to CouchDb making *everything* no more than 4 clicks away.
And perhaps the biggest bonus of all: IBM could even avoid the Lotus Notes name and "start over" with branding for this young crowd. After all, the thick client isn't even on their radar. Avoid the "Notes" name competely.
Call it "XPages by Lotus" or "IBM XPages" or "XPages by IBM". Short names are catchier, and it's got a freakin' "X" in it, for crying out loud! That immediately adds "cool factor" for the young crowd.
Whatever happens, just don't name it "IBM Lotus XPages Designer Lightweight Personal Edition" and bury it in the IBM website.
|
Ratings
0
|
After several weeks the bug introduced for GetDocumentByKey (and all the other Get*ByKey operations) has been fixed.
As per IBM's announcement it looks like it will ship with 8.5.1FP3.
With the fix lookups to busy views are also exhibiting a marked performance improvement so this is also a significant win for busy databases.
|
Ratings
1
|
Since I know everyone will be asking: no, this is actually not related to the GetDocumentByKey fix that IBM is working on. According to the Designer Help, GetDocumentByKey() is not case-sensitive. Meaning if you have two entries in your view: Apple
APPLE
Calling GetDocumentByKey("Apple", True) returns the first doc.
Calling GetDocumentByKey("APPLE", True) returns the first doc also.
I used to think that the case-sensitivity setting of the column actually controlled this behavior, but that's not the case.
But, wait, it gets worse: GetDocumentByKey("apple", True) returns NOTHING??!??!!?
Explain that logic to me, Batman.
It's not a big deal for me, but I'm curious - how does everybody else usually get around this limitation? @DbLookup instead? Using GetAllDocumentsByKey and iterating through the NotesDocumentCollection? Or something crazy like using a known-unique lookup key like @Password(yourLookupValue)?
|
Ratings
0
|
It was just announced that those of us in the 8.5.2 beta program can start blogging about it in detail. Since we're such an app dev heavy shop I'd like to mention some cool things in that area from the latest 8.5.2 beta:
The most important feature in 8.5.2 from an App Dev standpoint is this:
NotesAgent.runWithDocumentContext(NotesDocument)
WIth this you create an in-memory document and then pass this document to an agent. You do NOT need to save the document prior. This is available for LS, Java, and SSJS code meaning we finally have a bridge to call legacy LS agents from an XPage. This allows XPages to completely duplicate WebQueryOpen/WebQuerySave functionality from legacy Domino forms. Finally you can incrementally add XPages functionality onto older applications while still leveraging your older backend code. An interesting extra use case: If you've got any LS agents that need to call Java code it's arguably better than the LS2J connector in some cases.
XPages received numerous other enhancements, and this is a good thing. Remember that all this stuff works in the client AND on the web:
- On Xpages you can drag and drop directly into the source pane. This is long overdue. Now if only we could have the design AND source up at the same time (e.g. multimonitor).
- XPages also have some new controls, checkbox groups and radio groups being a few.
- Dojo is upgraded to 1.4.1 (if I recall, I might be slightly off here). This framework is getting really sweet and the integration with XPages is even better. If you haven't checked out Niklas Heidloff's latest projects on OpenNTF you need to. He's got an XPages framework for mobile devices that needs only one extra library from Dojo 1.5. Based on the progress I'm seeing here, 8.5.3/9.0 will likely converge with those efforts, giving us a 100% integrated development environment for mobile platforms with XPages. There are also formal "Dojo" attributes everywhere, allowing even better hooks into the framework directly from the IDE. Those of you who have heard me strongly suggest looking at Dojo instead of JQuery over the past few month now know why. The ROI of using native Dojo hooks in XPages is great, and it's only going to get better from here on out.
- SSJS now has a new way to create a session: sessionAsSigner(). THIS IS AWESOME. You can now simultaneously have code that runs with the permissions of the signer of the XPage AND code that runs with the permissions of the current user.
- OneUI v2.0.1 is included as a formal theme. It fixes quite a few quirks and cleans up things a bit over OneUI version 1.
Lotusscript received a tiny bit of love, but not much. Database Scripts now use the Eclipse editor. And you can define database scripts as @Formulas, which is a new capability. I have absolutely no idea why Lotus went out of their way to add that though.
NSFDB2 is formally "no longer available." i.e. if you install 8.5.2 you don't have the option to install NSFDB2. If you were already running it and are upgrading you'll need to contact IBM support to get the files you need to add to the install process.
A big deal in 8.5.2 is silent server failover. This no doubt crosses over with upcoming cloud-related services, but essentially 8.5.2 can silently failover to another server (or even a local replica) if your server goes down. Done right this could be huge.
The 8.5.2 web server also now has a full REST API (of course, you can enable/disable this). [Disclaimer: This is all speculative stuff from the current Beta, which may or may not make it into the final 8.5.2 shipping product.[
|
Ratings
0
|
So on Steve's blog I just saw one of those Google "migrate from Notes" ads. Here was the text in the ad: "Showing my CEO how to check email made me go Google."
LMAO! Really? Seriously? Seriously? Wow.
|
Ratings
0
|
You may have noticed that opening a folder in Designer can take a very long time if there are many docs in the folder. The lightning bolt flashes indicitating a lot of network traffic - it's as if Designer is downloading the entire folder index even though you obviously don't need it. Views, on the other hand, always open very fast. Over higher-latency network connections it can take several minutes for the folder to open. I've reported the problem to IBM Lotus Support but they need more customer weight to address the problem. If you're interested the SPR is #RPEA83N3J7.
|
Ratings
0
|
The 8.5.1 GetDocumentByKey bug fix released last week (for 8.5.1FP1 it was HF124) has regression problems.
If you have a view with these docs:
a
b
y
z
And you have code that performs:
getdocbykey(a), print value
getdocbykey(b), print value
getdocbykey(y), print value
getdocbykey(z), print value
Then you will get "a,b,y,z" as expected. But if you change the code to perform:
getdocbykey(a), print value
getdocbykey(b), print value
CREATEDOC WITH VALUE OF H
getdocbykey(y), print value
getdocbykey(z), print value
Then you will get "a,b,h,z". Not good.
IBM has stopped issuing the original fix and is working around-the-clock to develop a fix for the fix. I'll post updates here as I get them.
Regarding client-side fixes: There's some people who have said that IBM support denied them a client-side fix. I did get approved for a client-side critical fix originally. That's on hold until they fix this latest problem though, but I expect they'll re-issue me a critical fix update for the client. If you need a client fix (or server fix) then open a PMR, and feel free to reference my PMR: 18734 442 000.
|
Ratings
0
|
Wow... there's been nearly 4,000 hits to my blog entries regarding the GetDocumentByKey bug.
A lot of you have been asking me about an update so here we go:
The Short Story
The issue's reportedly been fixed. There is a technote where you can contact IBM for a fix.a technote where you can contact IBM for a fix.
As a nice side effect the original bug they were trying to fix all along (the "infinite loop" bug) is now truly fixed. Your apps that perform any GetXXXByKey calls will likely scale much better under load than they ever have.
The Long Story
I received a fix (8.5.1FP1 HF154) for Domino 32-bit on Win32. We applied for a client version of the fix but haven't yet received it.
The fix has been running for 3-4 days with no errors. But I only received errors maybe 10 times in the past 4-5 weeks anyway so we won't really know if things are fixed until a couple of months down the road. Personally I've received a bunch of hotfixes over the years and they've been all been perfect. I'm sure this is no different.
The technote instructs you to open a PMR to obtain for a fix for this bug. It is uncertain whether IBM will proactively contact customers about obtaining a fix.
This bug exists in the following versions:
7.0.4
7.0.4 FP1
8.5.0 FP1
8.5.1
8.5.1 FP1
8.5.1 FP2 <-- Not out yet, but likely affected
I believe this fix missed the 8.5.1FP2 window (it's due any day now) so the first formal release with the fix will be 8.5.1FP3 (probably due in May/June if the current release cycle times are any clue.) Here's how the fixed call works: If, after the first lookup, the view comes back "dirty" (i.e. there's been an update) then a refresh is forced. Once that refresh completes one more lookup is called. The result of that lookup is always returned, regardless of whether the view is dirty again or not. There's no way for the error to be returned.
So you're always guaranteed at most one refresh, and only if needed.
The remarkable thing about this is that a view can be considered "dirty" if there is time creep (as in my original post) or if there has been another doc update since the lookup's refresh was called. It turns out that the latter case is the main case where we would all encounter a dirty view -- any time our apps were under a load of doc updates. For example, if you've got an agent running that is updating many docs then in the past a simultaneous GDBK() call might have spun and spun for a long time until things settled down (i.e. your update agent paused or finished updating docs) and then finally returned a result. Throughout that time it will have kept refreshing the view, resulting in needless resources being consumed over and over. I've seen this personally where an agent creating about 5 docs a second would cause a GDBK() call to hang for 10-20 seconds or more before finally completing. This was likely because it was continuously refreshing the view until the update agent's activity slowed down sufficiently. With the fix the call will finish much faster (the time it takes to perform one refresh.) This means your apps that perform GDBK() calls in busy databases should scale much better and seem much more responsive. This is what IBM was trying to tackle all along, though the original technote is not very specific on this topic.
Some really great people helped out with fixing this problem. I'd like to publicly thank Chad Scott of the Core Server Team in Lotus Support for his assistance with my cases and Ed for his fast reaction time on his end. There was also some very good discussion on Ed's blog about the IBM PMR process in general. We really need a crowd-sourced way to discuss and search for bugs. To that end I've registered notesbugs.com and will hopefully do something interesting there in the near future.
Thanks to everyone for their support on this as well. Good luck obtaining your fix.
|
Ratings
2
|
For those that were asking me, yes - IBM has finished a fix for the GetDocumentByKey problem. I won't steal any thunder about the formal announcement (also because I don't know all the details) but the way IBM explained to me how the refined algorithm works is awesome. So awesome, in fact, that you may see your apps scale much, much, MUCH better under load than ever before. I'll go into more detail after the formal announcement, but this fix (really a more-correct implementation of the infinite-loop fix) may be yet another reason to get on 8.5.1, ASAP!
|
Ratings
0
|
