Download pdf - Collaboration Party of One

© 2013 RunningNotes

COLLABORATION PARTY OF ONE:WHEN YOU'RE BOTH THE ADMIN AND THE DEV

Kathy Brown, PSC GroupJess Stratton, Solace Learning


2

Agenda■ Introduction■ Avoiding Pitfalls of Going It Alone■ Reaping Rewards of Being On Your Own


3

Who Are We?■ Your Collaboration Hosts

─ Jess Stratton‒ IBM Lotus Domino Consultant (both a developer and admin)‒ Trainer (anything anyone will let me teach)‒ Tweeter (@NerdGirlJess)‒ Blogger (momelettes.com, anywhere else anyone will let me write)‒ Autocrosser (MINI Cooper S, anything else anyone will let me drive)

─ Kathy Brown‒ Application Developer (and admin dabbler)‒ Author (Lotus User Group Dev Tips Newsletter)‒ Tweeter (@RunningKathy)‒ Blogger (runningnotes.net)‒ Runner (daily, since June 1 2009)


4

Why Are We Here?■ If you're here, you are probably the developer AND administrator at your

organization.─ Congratulations! You're probably one of the most popular people at your office!

■ You probably have ALSO learned the danger of dabbling at one point or another.─ Your ID file? The one you log in with? It's probably the single most powerful ID file in

your office.─ You can quite easily cause a time-paradox, the results of which could cause a chain

reaction that would unravel the very fabric of the space-time continuum and destroy the entire universe!

‒ (Not really. But you can write some pretty destructive agents!)─ We'll help you minimize these dangers.

■ However, you've probably also discovered that being both the administrator and developer is Pretty Darn Awesome.─ If you haven't, we'll tell you why it's awesome!


5

Sound familiar?■ When you hear people talking about their teams of IT people, dev

teams, and admin teams, you probably feel like their offices look like this:


6


7

And then there's you...■ You're alone.

■ The admin and dev all rolled into one, and so you feel a bit like this:


8


9

The Good News■ When things break, you don’t have to wait for anyone else to fix

them!

■ You can write code to do your own monotonous, repetitious admin tasks for you!

■ You are a well-rounded individual who can probably tackle anything anyone can throw at you!

■ At parties, once people find out you know anything about computers, you will become the most popular person there!


10

The Bad News■ When things break, it’s probably you that broke it in the first place.

─ The silver lining: You won’t waste time blaming other people or arguing.

■ It’s easy to forget your “higher powers” and you can do some real damage carelessly!─ And surprisingly fast...

■ You can’t even make it to the office bathroom without your entire organization stopping you for questions on the way.

■ You should never, EVER, under any circumstances, tell anyone at a party that you know anything about computers.


11



12

Pitfall 1: Your ID file can and will be used against you!■ Imagine this scenario:■ You are currently playing the Developer role, making a change to a

database.─ Maybe you are getting ready to upload it to the server. It really doesn't matter.

■ When, suddenly, the phone rings!─ “Can you reset my password?”─ “Can you get rid of these replication conflicts?”

■ Your brain wasn't made to switch multitasking roles this quickly.─ OOPS! You ran the wrong agent.─ You may have also been in the wrong database when you made that change.

■ Bottom line: It's too easy to do damage when you are being pulled in fifty different directions!


13

The Solution for Pitfall 1■ You need TWO ID files.

─ One is used for mail, other daily use and Admin tasks.‒ It has your super-bionic ultra-powerful administration rights.

─ The second ID file is for development.‒ It is to be used on your Sandbox server.

• We will talk about THAT later!

■ Even though you are one and the same person, assume the Business Process is still that of a Dev-Admin hand off!─ Use your developer ID to make changes on the sandbox server.─ Use your admin ID to sign or bring those changes over to the production server.

■ This system of checks and balances will help avoid missteps.─ And will help your multi-tasking mind correctly break out of each task.


14

Solution Bonus!■ Users can use your Developer ID's Inbox as a request for support/

features.─ This will keep them completely separate from your daily Inbox!


15

Pitfall 2: Not switching IDs because it's too inconvenient!■ When things are too inconvenient, we don't do them.

─ This is true for ANY process, home, work or otherwise!

■ It's HARD to remember to do a File-->Security-->Switch ID!─ And, it's kind of a pain. We understand.


16

The Solution for Pitfall 2■ Create a separate Location document that ONLY works for that ID

file.─ And, that automatically switches to the ID file when you switch to it!

■ Create the Location document:─ File → Locations → Manage Locations─ Select New...

■ BONUS: Working sets!


17

Solution (cont.) - Creating Location docs

■ Give your new Location an easily identifiable name:─ Developer─ Sandbox─ Playground─ App Dev

■ Fill out all other fields as normal:─ Servers – This should be your playground server!─ Mail File – Your dev mailbox for feature requests/bug fixes─ etc.


18

Solution (cont.)■ Go to the Advanced → Basics tab

─ Edit the “User ID to switch to” field.‒ Click the flashlight icon, and browse to your developer ID.


19

Solution (cont.)■ Now, when you are ready to do development work, all you have to do

is switch Locations !─ Your Notes client will take care of the rest!

‒ It will put you on the right server.‒ It directly connects you to your dev mail file.‒ It will switch your ID file.

─ It's an easy switch, do it right from the bottom right of the Notes client.


20

Pitfall 3: Locking Domino

■ You can lock yourself out quite easily.

■ The Security tab in the Server doc─ Who can run agents, etc.─ Who has Full access Admin?


21

Pitfall 4: Not Creating Design Failsafes!

■ Readers fields without using ACL roles can ruin your entire day.─ Readers fields Best Practice: create Roles in the ACL.

‒ “[Reader Admins]”:”[HR]”

■ Don't forget to put the Servers, and the Admin in there!─ That's your OTHER ID file, remember?─ Preferably, you use Groups:

‒ LocalDomainServers‒ LocalDomainAdmins

■ If you do lock yourself out, make sure you have access to an ID File that has Full Access Admin rights!─ (See Pitfall 2)


22

Pitfall 4 – Design Failsafes (cont.)■ Poorly designed elements can really slow a database down.

─ These are issues that will affect server performance – also your job, remember?─ They can also come back to haunt you when it's time for a server upgrade or hardware

change.‒ Hardcoded values!

■ Design elements you need to avoid:─ Too many sorted columns.

‒ Too many secondary sorts!─ @Today in views.─ Hardcoded server names and user names.

‒ Instead, pull the current server name programmatically from the DB file info.─ Field values that pull their information from other field values that pull their value from

a value on another document that pulls that value from a Group that pulls their values from other nested Groups.

‒ Remember: It will be YOU that has to do all that tracing when a department head leaves.


23

Pitfall 5: Not Creating a Sandbox Server

■ One that mirrors your environment─ It's easy to create a sandbox server.

‒ If you haven't, it's the first thing you should do when you get home─ It's less easy, but very important to make your sandbox mirror your production

environment!‒ User Groups/Roles/Access‒ Replication‒ User data‒ Nightly agents running‒ Everything!


24

Pitfall 6: Being Disorganized■ It is easy to think you don't have to organize/communicate/

document because you are the only person doing the work─ But you are the only person doing the work so you probably have a lot of work to

do!─ Your admin tasks and duties are piling up and vary greatly from the dev requests

and bug fixes that are also piling up.─ It's very easy to lose track of what needs to be done and with no one else to

remind you, it's even MORE important to organize and document


25

Solution to Pitfall 6■ Have a method for tracking administrative requests like adding new

users■ Have a separate method for tracking development requests and bug

fixes■ Good news! Notes applications exist for both of these purposes!


26

Pitfall 7: Not Building a Network.■ No, not a Domino network!

─ You've already built that.

■ A network of PEOPLE.─ Other admins, developers, admins AND developers, members of the Lotus

community.

■ You need sanity checks, and people to bounce ideas off of.

■ Where would you find those people?─ PlanetLotus.org─ Twitter─ Lotusphere─ Other LUGs─ THIS ROOM!


27

Be Social!


28



29

Reward 1: Make Your Own Administration Process!■ What is the Administrative Process again?

─ It's Domino-created batch files.─ The admin selects what users or databases need the tasks run against.

‒ AdminP runs the tasks on them.

■ Sound familiar?─ It should. After all, it's just variables, right?─ And/or agents that run on selected documents?

■ Have you ever created a piece of code and thought, “This could be quite useful if I ever needed to do it again?”─ Why not genericize it and create your own AdminP database?


30

Reward 1 (cont.)■ Gather together your most often used admin routines.

─ Reporting─ Updating values in documents

■ Turn them into generic routines.─ Create a form to add your variables so that you can use it on any server, on any

database.─ Add fields for things like:

‒ Server name‒ Database name‒ User name‒ Field name‒ Field type


31

Reward 1 (cont.)■ PS – when it's finished, think about putting it on OpenNTF.org!

■ Time for a demo!─ The Automated Admin─ Admin Power Tools


32

Reward 2: You Can Run Agents on the Domino Directory!■ Updating phone numbers in Person docs■ Stripping leftover ID files out of Person docs■ Updating Internet addresses (if your Internet domain changes)

■ How to make changes to Domino Directory via code:─ First, do it in your Sandbox, of course!─ However, when it's time to implement it for real:

‒ Make sure your backups are current!‒ Create manual local replica on your workstation.‒ Temporarily disable replication in Replication Settings for that replica.‒ Run your agent.‒ Check for desired results.‒ Re-enable replication and replicate it back up.


33

Reward 3: You Can Code Your Own Toolbar Buttons!■ These are especially useful for revealing hidden design elements!■ You can display things like:

─ All agent names in a database.─ All form names in a database.─ All field names on a form.

■ What's the value in displaying all field names on a form?─ Once you know the field names, you can change the values!

■ Create a set of toolbar buttons that will help you out, and always keep them visible.─ Here's one I use daily:─ @Command([ToolsRefreshSelectedDocs]);@True


34

Reward 4: You Know What Your Servers Can and Can't Do!■ An admin may insist on shorter agent run times but you know you

need that 5 extra minutes and that it won’t kill the server■ You don't have to have admin lockdown■ You can create the necessary compromises between security and

performance


35

Reward 5: You Can Optimize Code For Your Architecture■ Your servers can be a finely-tuned machine that runs like the Paris Opera Ballet!

■ Schedule nightly agent runs around your server tasks.─ Updall runs at 2AM by default─ When do your backups run?

■ When does your server run program documents like Compact?─ Schedule your nightly agents around these!

‒ 11PM‒ 5AM

■ You know all the servers that belong to a cluster.─ Make sure you specify the “Server to run on” for your scheduled agents!

‒ Otherwise, you could find lots of mystery replication conflicts.

■ You know if/when/how often users replicate


36

Reward 6: You Can Upgrade On Your Schedule!

■ If you need the latest features, upgrade!■ If you need to wait for a fixpack, wait!■ No need to convince anyone why you want to upgrade or wait■ Word of Caution!

─ It's great to be up-to-date on the latest features, but beware of jumping in as any mistakes you make will hit you twice as hard as both the admin and the dev


37

Reward 7: You Can Make Yourself Happy!

■ Use tools that satisfy both the admin and the developer in you:─ Like the Agent Profiler to identify bottlenecks in your code!─ And Application Monitoring in DDM!


38

Reward 7: Make Yourself Happy (cont)

■ Use Application Probes in DDM to find your problem Agents and help make your apps more efficient.

■ You can set up the following probes:─ Agents and Web services ranked by CPU usage─ Agents and Web services ranked by memory usage─ Agents and Web services that run longer than expected─ Agents whose start times have fallen behind schedule (applicable to Agent

Manager only)


39


■ To set up Application Probes:─ Open Monitoring Configuration─ Change to the view “DDM Probes”─ Select “New DDM Probe” or find the canned existing probe and enable it

‒ Probe Area: Application Probe‒ Probe Type: Agents Ranked by CPU Usage

─ You can even choose web agents (run by HTTP) or Agent Manager agents!─ Rank four levels of warnings based on how long the agent takes to run.

‒ ie. 600 CPU seconds = Fatal

■ These warning levels will then be spit out into DDM.─ Along with the agent owner.

‒ Which, frankly, would be more helpful if you didn't already know it was you.


40


■ Let DDM tell you which databases need Full-Text Indexes!

■ Remember this from your Notes logs?─ 01/18/2012 07:23:34 PM Agent Manager: Full text operations on database 'C:

\Lotus\Domino\data\apps\customersrv.nsf' which is not full text indexed. This is extremely inefficient.

■ DDM will tell you which databases get the most queries─ Seeing the total number of FT queries on a database can quickly pinpoint which

databases should have an FT Index.─ It's the same error, except once it appears in Domino Domain Monitoring, it

actually contains a COUNT of the amount of times the error occurred.‒ A great way to tell you which databases will benefit from having an FT Index.,


41

Reward 8: You Can Restore When Needed!■ You'll know what version is safe to roll back to, both server and

application─ Working in a team environment a lot of communication is required to roll back

when necessary‒ What version? What features/fixes will be lost? When did it work last?

─ As admin and dev, you'll know what is broken and why, and how far to go back to fix it


42

Reward 9: You Can Prioritize!■ You can decide what's most important

─ A dev on a team can get frustrated when they think their admin is focusing on “unimportant” tasks instead of upgrading that server

─ An admin on a team can get frustrated when their dev is writing some “unimportant” application instead of that agent for server maintenance

■ You know which task takes precedence and no one will argue with you!


43

You Don't Have to Go Home, But You Can't Stay Here■ Fill Out Your Evals!

■ Contact us:─ @NerdGirlJess─ @RunningKathy

■ Get Social! Have Fun!