Get the most from Notes®

Category Hobbies Fun Personal

I run with a social club for my running only events. Earlier this month we all took part in the Round Norfolk Relay. The race covered 193 miles of the Norfolk countryside, split into 17 stages. I would highly recommend relay race events to any running club. I felt it bought our team closer together after achieving a goal by working together. I ran what was supposed to be a 19.6 mile section of the race, but it turned out to be 21 miles after we were chased down by marshals telling us we had taken a wrong turn…well it was at dark by the time it was my turn to run!

Take a look at a this short film made by the Round Norfolk Relay organisers.

Posted by Michael Wenn At 8:00 AM | Location Huntingdon, UK | Permalink | Comments (0) |      

Category Development

The good news is more people have access to Designer and can start making those small changes to their databases that have been bugging them for ever. The bad news is that now even Bob in accounting has access to Designer (no offense Bob).

Now, more than ever, developers need to be sure their data is secure. Remember, a ‘Hide when’ formula is not a security feature. Just right click on the document and show document properties. Fine, you say. I'll just hide the design and the list of fields isn't displayed. Still not a security feature.

I am not going to go into the details here, but think of a View with the first column categorized on a sensitive field like BirthDate, and be sure to not check the option to 'Don't show empty categories'. For real security, you need to encrypt the fields, or use Reader fields. Since a Reader field applies to the whole document, put that sensitive information on a 'daughter document' with appropriate Reader access.

We know Bob is a nice guy, but don't give him a head start down the wrong path.

Posted by John Kingsley At 1:43 PM | Location Beverly, MA | Permalink | Comments (7) |      

Category Best Practice

The other day I was watching a football game.  Okay, it was the Patriots 59 to nothing blow-out in a snow storm.  I noticed that the graphic that showed the score had 3 yellow dots over each team’s name.  Later in the game I realized that these dots were not just part of the graphic.  They conveyed the all important information as to how many time outs each team had left.  Intuitively obvious to the casual observer.  

In contrast, I found myself completely confused by the graphic superimposed on the field showing what down it was and how many yards were needed to get a first down.  I found myself trying to make sense of the head or tail of the graphic.  It isn't where the ball is.  It isn't where they need to go.  It appears to be totally random.  Even though it is a really cool thing, instead of adding value it just added confusion.

Which reminds of the Notes application I was using recently.  I was looking for some information and couldn't find and couldn't even understand why I wasn't finding in.  Then I realized the first column of the view was categorized, the second column had information, and the third column was sorted.  So when I read the view from left to right, scrolling down the unsorted second column, nothing made sense.  

Who knew that you would have to explicitly state that a requirement for that application should be that the sort order of views made sense.  If the third column really needed to be sorted, it should be the first column after the categorized column.  Or sort the second column.  It makes it much easier for simple people like me to find stuff.

Posted by John Kingsley At 7:56 AM | Location Beverly, MA | Permalink | Comments (0) |      

Category Risk Good Practice
Several years ago I was working on a new software release for a previous employer when the CTO came into my office asking a favor. He wanted me to let one of the developers on the project implement a feature “his way”. You see, the issue was that he found what he thought was a clever way to implement one of the new features required by the users.

The problem with letting him do things his way was that other developers on the project felt it simply wouldn’t work. More importantly, the business said this solution failed to meet their requirement. The proposed design was pretty cool, but we really needed something that would work AND met the needs of the business.

So why was the CTO so adamant about this? It turned out that this particular developer possessed some unique knowledge because he had been with the company for a very long time and worked on many business critical applications over the years. The CTO was afraid that he might quit if he didn’t get his way on this new project.

I couldn’t believe what I was hearing. Essentially, the CTO wanted to let the project fail in order to retain this guy. Incredible!

I spent a lot of time working with the VP of Development to find a way around this with no real solution in sight. As it turned out, the guy quit within a week. Whew! That was a close call.

In telling this story since then, I’ve come to realize that my experience is not unique. Projects are often held hostage by a key member of the team. So what can you do to prevent your project from turning into a complete disaster when it is being held captive?

There are a few things you can do, but it is important to recognize that losing those sorts of people doesn’t usually end up being as painful as you think it’s going to be.

Following is a short list of suggestions:

• NEVER allow individuals to hold projects hostage to their expertise, experience or knowledge. It is a rare project that ends in success when this happens.
• If a hostage situation occurs, remove the problem immediately. Project delays and challenges will only increase until the problem is addressed. It’s better to make this change on your terms instead of theirs.
• Contact the business immediately to let them know what happened. There may be a delay in the project because of it, but do your best to minimize any negative impact this might have on the schedule.
• Recognize (to the team and yourself) that removal of a key resource may slow a project down at first, but a well managed team will recover quickly and produce a much better result in the long run.

I’d love to hear your ideas on this. Have you been in a similar situation? If so, what did you learn that might be helpful to others who find themselves in a similar situation?

Posted by Scott Johnsen At 8:59 AM | Location Beverly, MA USA | Permalink | Comments (2) |      

Category Application Development Best Practices Build Process Production
Whether it's simply copying and pasting files to a Domino production server and manually setting the ACLs, or creating a complete system with quality gates and automated approvals, somehow we manage to get our Notes applications out into the world.

Usually, the focus is primarily on the development group’s build and deployment requirements, since the code starts with them. Then we try to figure out how to get the code onto a production server. However, it is just as important--if not more so--to focus primarily on the Domino administrators requirements, as 1) they are ultimately responsible for the server, and 2) most support calls go to admins first. In most organizations, the Domino Administrator is not a full-time position, but these individuals are responsible for managing their Domino servers. So, would it surprise you to hear that many issues developers face are also concerns for administrators?

(read more)

Posted by Richard Sharpe At 1:14 PM | Location Beverly, MA | Permalink | Comments (0) |      

Category Hobbies Personal

No matter how fast or slow you run, when one of these songs comes on I guarantee you will change your pace to match.  In no particular order

     1. Mambo No. 5 by Lou Bega
     2. Candyman by Christina Aguilera
     3. Hanky Panky by Madonna
     4. Girlfriend by Avril Lavigne
     5. Chelsea Dagger by the Fratellis'

 And just for fun, any steel drum song because whenever that comes on, no matter where you are or what you're doing, you can't help but smile!  Happy trails!

Posted by John Kingsley At 1:38 PM | Location Beverly, MA | Permalink | Comments (2) |