Basically, that's a function that uses a little DXL trick to allow you to create your own custom button that contains whatever LotusScript or @Function code you want, and append it to a NotesRichTextItem. All using LotusScript in the backend.
The usual method for doing that is creating the button by hand ahead of time, saving it in the rich text field of a profile document, and then copying it from the profile doc when you need it. Which works just fine if you know exactly what button label and code you need ahead of time. Doesn't really help if you don't know what the code should be until runtime, though. That's where my tip will help you.
A given feature [in a software interface] presents both a simple aesthetic problem and a complex mathematical one. The look and feel of a product forces a designer to think about the arrangement of colors and lines on a screen; often, even the most trivial element of that arrangement forces a developer to create an enormously complicated subarrangement of equations, classes, heirarchies, and relationships in the intricate universe of a computer program. During the course of [Microsoft] Encarta's design and development, for example, Carolyn Bjerke made a tiny change that grew into a legend. For years after, it was cited as the classic example of how difficult it is for Microsoft designers and developers to communicate.
Bjerke's gaffe began with a small design change in two generic buttons... The buttons are designed to look more or less like the rectangular buttons on amplifiers and tape decks. Shadows and highlights drawn around their edges give them a three-dimensional look. Bjerke, working on Encarta's design, decided she wanted to distinguish the row of buttons along the bottom of Encarta's screen from those along the top by giving the former a slightly different look. She drew a single, nearly imperceptible white line along two sides of each bottom-row button, a corresponding light grey line along the other two sides, and altered the typeface on all of them. "It made a very subtle difference in the look," she said.
Not so subtle was the effect on Encarta's developers. Instead of taking generic Windows code for traditional Windows buttons and plugging it into Encarta's program, they had to write hundreds of lines of new code, over several weeks, to accomodate Bjerke's change. Writing the code for the look of the buttons themselves and for that code's relationship to the rest of the Encarta program, to hear a developer tell it, was an operation on the scale of adding a new galaxy to the universe. The code can now be found in Microsoft's code library under the label "sbutton code". The s stands for "stupid".
If you're going to assign blame for an episode like that, you can probably dole it out to both sides of the team. The next paragraph quotes Bjerke as saying, "If I'd known what it cost them to make that change, I never would have done it. They should have explained it to me." However, there may have been some dynamics that kept them from explaining it to her, or maybe they tried and she didn't listen. Who knows. Sounds like multiple issues, in any case.
The point is, you do indeed have to be flexible as you're designing an application ("are you sure the sbutton is a have-to-have?"), but at the same time it's very important to have a good vision of where the total application design is going and how all the pieces are going to eventually fit together ("all right guys, looks like we may have to put some sbuttons in later on, so keep the button code really generic").
This comment was met with a mystified look. What do you mean? Spinach has all sorts of iron in it. Doesn't it?
I responded that spinach actually doesn't have any more iron than any other green leafy thing, and that it was actually just a misprint in a study on food from long ago that created this "iron rich spinach" myth. Since the computer was on right next to me, I pulled up the Wikipedia article on spinach for verification. It said:
In popular folklore, spinach is supposed to be rich in iron; in reality it has about the same iron content as any other green vegetable. However, spinach is a rich source of Vitamin A, Vitamin E and several vital antioxidants. On the negative side, spinach is also high in oxalates, which can contribute to gout.
Spinach's iron content had been determined in 1870 by Dr. E. von Wolf but a misplaced decimal point in his publication led to a figure ten times too high. In 1937, German chemists reinvestigated this "miracle vegetable" and corrected the mistake. It was described by T.J. Hamblin in British Medical Journal, December 1981.
If you don't believe the Wikipedia article (as some people are suspicious of such "Internet community knowledge"), here's an article from the British Medical Journal that also supports the claim. I tried to get the actual T.J. Hamblin article from 1981, but it looked like I had to pay for it, and it wasn't really that important to me.
Anyway, it's just interesting how so-called "facts" can be spread around as common knowledge, even years after they've been disproven.
I mean, the project I was working on should have been perfect for that methodology: small development team (me), low documentation requirements (yay), and frequent milestones based on an iterative approach. Requirements are, apparently, dealt out in small doses as the iterations go forward -- which from what I could tell meant that you still tried to get requirements upfront, but you didn't kill yourself over granular details because those would come as you did your iterations.
Either I did it wrong, or it just didn't work for me.
I am, as you are reading this, in the middle of the third total rewrite of the application. I think this time it's finally going to work, but I'm just fed up with the whole mess.
You see, the theory that "changing requirements won't matter because we'll deal with the new requirements in the next iteration" only works if the changing requirements affect functionality that you haven't designed yet. If you haven't written that part of the code, then who cares what the requirements are? You're not there yet. Write them down and move to the next agenda item. However, if the code is already written and tested and "architected", and some new requirement makes you have to rethink the underlying design, you're screwed no matter what kind of methodology you use. You still have to go back and rethink your original code.
What's worse is, the "we'll cross that bridge when we get to it" mentality doesn't take into account that there's a certain kind of butterfly effect with software design. A tiny change in architecture at the beginning can have huge impacts later on (for better or worse). Likewise, having to make a seemingly tiny change to core functionality or design later on down the road can be a major undertaking.
When you're designing an application, you have to spend a lot of time at the beginning building a strong foundation, taking into consideration the entire framework of the finished structure, because all the things you'll be adding later have to stack on top of that foundation. It's like building a brick wall, while this agile stuff (from what I understand, which could be wrong) assumes that it's more like paving a brick sidewalk -- like you can just set all the bricks down next to each other and place them and pull them up piecemeal without affecting the structure of the whole. That's just not how it works.
I know that the end-users seem to like this agile stuff quite a bit, because all they see is that you come to meetings every month or so with "new stuff". Yeah, that's all well and good, but here's something that I've realized in my small and undistinguished career as a programmer: end-users have no earthly idea what's involved with writing an application. It seems to me that this agile technique is allowing the end-users to control the development process, and that just doesn't make sense.
End-user input on requirements? Sure. End-user input on user interface? Of course. End-user input on how the application is built and what new iterative features we get to see next week? Um, no.
When I bought my house, it was brand new and in the process of being built. My wife and I got to pick the paint colors, the tiles, the light fixtures, and a few upgrades and enhancements. At one point we asked how much extra it would cost for a brick exterior, but they said they had already built the exterior walls for stucco, and that was fine. We got stucco. It didn't really matter. They told us when it would probably be done, we planned our moving date around that time, and luckily they got done when they said they would. It all worked.
Now think if that had been an agile process, where they were giving me a new "iteration" every month, and I was constantly changing the design as we went along:
So anyway, I'm going back to big planning and lots of architecture at the beginning of the project. Most of my deliverable "iterations" might be towards the end of the project instead of gleefully scattered throughout, but it'll get done right.
[UPDATE: Jens-Christian Fischer posted a good response to this on his blog: Lotus Notes is not agile]
It's based on the 1.1a template (which is the current one on OpenNTF, at this time). If you're using the "stock" domBulletin 1.1a template, you should be able to just change the master template name on your database to "OpenNTF_domBulletin11julian" and do a design refresh.
After you refresh design, you'll see a new "rss feed" link next to the database name/link on the main web page (just above all the categories), and each category will also have a link under the description text that says "rss feed for this category". Here's a partial screenshot with glaring red arrows added for emphasis (click for a larger image):
What I changed:
The only real issue is that I couldn't figure out how to insert the server's DNS name in the main column of the (RSSViewAll) and (RSSViewCategorized) views. RSS feeds are supposed to have fully-qualified links, not relative ones, although some RSS readers don't seem to care.
Anyway, the way I worked around it for now was to hard-code the server DNS name in the view column, in the "hostname" variable. I'm not sure of a good way to make the view figure out what the DNS name should be without hard-coding it, since the view index won't read things like CGI variables or profile forms.
Also, I have no idea how well this will scale (that is, I'm not sure if the performance will go to crap on a large or very active bulletin board). Testers are welcome.
I know that last year and the year before I put together lists of favorite topics from the past 12 months, but this year you get no such thing. With age comes laziness, and I'm just too lazy to go back through my old posts right now.
Have a good weekend. Talk atcha later.
So anyway, I've started getting into the habit of checking them out from the library and listening to them on the way to/from work. I can check them out for 30 days per title, which is plenty of time to listen to a 5 or 6 CD book (hint: get the abridged books when you can). It's a nice change from music and talk radio, and very non-stressful for the commute.
Right now I'm on the second [unabridged] CD of The Hippopotamus by Stephen Fry, which is absolutely hilarious (warning: LOTS of male sex jokes... as if there are any other kind of sex jokes...). It's read by the author, which is sometimes a bad thing, but Steven Fry has a most excellent voice that is perfect for the main character in the story. [UPDATE: okay, I'm on CD #4 right now, and certain parts of the story are getting a little... well, let's say certain aspects are not quite my speed. Not sure where it's going, or if the rest will be as good as the first CD in the set. I just wanted to warn you.]
As you would expect, a reader can completely make or break a book. I've listened to plenty of books that were ruined by bad (or sometimes simply average) readers. Usually because they can't do character voices very well, but sometimes for other reasons too. I had a CD recently where the guy reading sounded like he was catching a cold, like he was congested way in the back of his head, and maybe if he snorted really good it might have cleared his passages for a few minutes. Drove me crazy.
Anyway, here are a couple other recommendations, if you're looking for any:
A mildly amusing side note: I usually still refer to audio books as "books on tape". I guess that's kind of a throwback these days. Like talking about "albums" or "dialing up to the Internet" or something.
Thanks to Ben Poole for pointing out the change to me about a week ago. I made the modification to the script right away, but didn't push it out until now in case they changed the forum designs again.
If you've already installed the script, please reinstall to get the latest version (you can install right over the existing script). Here's the local link:
After you have Greasemonkey installed, you can just right-click the link above and choose the "Install user script..." option.
If you're trying to figure out why LDDMonkey is a good thing to have, please see my blog entry from April 17th.
Oh yeah, and I'd also like to thank Rob Wunderlich for mentioning LDD Monkey in his recent presentation at the Detroit Notes Professionals user group meeting.
I set up the agent on a Windows XP machine, and also on my Ubuntu Linux machine (running under Wine). What the heck, right? A recent forum post indicated that there would be a native Linux client by the end of the year, but in the meantime Wine seems to work okay, sort of...
Here's what I did:
I had to kill the Wine session (Control-C from the Wine terminal window) to stop the agent, but it seemed to pick up where it left off when I restarted. To run the program, you just need to "wine UD.exe", with the proper path to ug.exe.
The only real problem is that in Ubuntu, which uses Gnome as the default window manager, the status bar icon for the WCG agent is essentially invisible and unusable. I just get a tiny wine-systray square that looks like this:
I'm guessing this is because of a really old Wine bug -- bug number 1301 -- that appears to be specific to Gnome. It sounds probable (based on reading the bug report and forum messages) that the Wine status bar works properly in KDE. In any case, I can still hover over the floating systray square to get the status of the WCG agent, so that's good enough for now.
Oh, and for anyone else who wants to try this little World-Community-Grid-On-Linux trick, you might want to consider disabling the OpenGL screen savers while the agent is running. Every little bit of CPU horsepower helps.
You know how when you run a view action against selected documents in the view, sometimes the docs are deselected after the action finishes and sometimes they're not? Well according to IBM Technote #1101841:
So simple, and yet the difference has escaped me all these years. It just seemed to me that sometimes everything got deselected and sometimes it didn't, and everything was just screwy that way.
I was almost too embarrassed to write this, since I know there are going to be people who think that's just Notes Development 101 (heck, it's probably in the Help file if I looked hard enough), but just in case there are one or two other people out there who never realized this...
I read somewhere recently (can't remember where, but if someone finds the reference I will make proper attribution) that in the software world there are really 3 kinds of free. We often hear about the first two, as discussed by the Free Software Foundation:
If you're not familiar with those definitions, feel free [ahem] to click the FSF link above and read a little.
There is, however, a third kind of free that is also quite prevalent, and quite insidious. It is:
That's like the situation where a drug pusher will give you one or two free hits of crack or coke or whatever to get you hooked, and once you're hooked you've gotta start paying like everyone else. Problem is, it's only free when you're a prospect, not after you become a user.
You knew it would happen, but you thought you were in control of the situation, and all of a sudden you find out how deep you are and how expensive it is. The analogies can go on.
Anyway, just make sure you know what kind of "free" your free software is.
It points out two things (well, probably more than two, but you can read the article yourself to get the whole experience). First, Microsoft is essentially giving away Sharepoint to many of its customers. The customers think it's free. Second, Microsoft just released 30 "Industry and Role-based SharePoint applications" for immediate download from their site. Also free, and they're out-of-the-box kinds of apps. Here's a sampling:
Traditionally, Notes/Domino developers have thought of Sharepoint as competing with WebSphere Portal (and now Workplace). So it's still the same ol' Notes versus Exchange smackdown, and Sharepoint is an entirely different market, right? Listen, and listen good. You need to stop thinking that way immediately. All of these Sharepoint apps compete directly with Lotus Notes.
The knee-jerk reaction from most people will be: "Yeah, but it won't integrate and there are all these hidden costs and you still need Exchange and SQL Server and nyah nyah nyah." Resist that reaction. Even if you're right, you need to open your eyes.
The Microsoft salespeople are in your manager's offices right now, as we speak, wooing them with instant Help Desk and Change Management apps, all for the price of... nothing. Sure, you might want to spend a little extra development time to properly integrate everything, but hey, that'll come. It works right out of the box, right now. Just plop it in and do your development later -- no need for any fanciness, because you're just piloting this free system, and you can work out the details later... muwahahaha...
And the next thing you know you've got this "free" system up and running in the server room, and all the screens are real pretty, and you start getting a lot of hard questions about costs and interfaces and "do we really need all that extra Notes stuff anyway?"
Get ready. It's not just coming, it's here.