Collaboration Party of One

310 views

Published on

When your administrator and your developer are one and the same, and they’re both you, things can get confusing. As the administrator, you’ve got a lot of power. Frequently, the role of administrator is to lock things down, keep the server running smoothly and tune performance. As the developer, you want a lot of power. You want unlimited agents to run anytime you want, as frequently as possible, with little to no limitations! So how do you reconcile these opposing needs when you have to play both roles? We’ll show you how to use separate IDs, location documents and other failsafes to make sure your party of one is successful!

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
310
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Collaboration Party of One

  1. 1. COLLABORATION PARTY OF ONE: WHEN YOURE BOTH THE ADMIN AND THE DEV© 2013 RunningNotes Kathy Brown, PSC Group Jess Stratton, Solace Learning
  2. 2. Agenda ■ Introduction ■ Avoiding Pitfalls of Going It Alone ■ Reaping Rewards of Being On Your Own 2© 2013 RunningNotes
  3. 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) 3© 2013 RunningNotes
  4. 4. Why Are We Here? ■ If youre here, you are probably the developer AND administrator at your organization. ─ Congratulations! Youre 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? Its 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!) ─ Well help you minimize these dangers. ■ However, youve probably also discovered that being both the administrator and developer is Pretty Darn Awesome. ─ If you havent, well tell you why its awesome! 4© 2013 RunningNotes
  5. 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: 5© 2013 RunningNotes
  6. 6. 6© 2013 RunningNotes
  7. 7. And then theres you... ■ Youre alone. ■ The admin and dev all rolled into one, and so you feel a bit like this: 7© 2013 RunningNotes
  8. 8. 8© 2013 RunningNotes
  9. 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! 9© 2013 RunningNotes
  10. 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. 10© 2013 RunningNotes
  11. 11. Agenda ■ Introduction ■ Avoiding Pitfalls of Going It Alone ■ Reaping Rewards of Being On Your Own 11© 2013 RunningNotes
  12. 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 doesnt matter. ■ When, suddenly, the phone rings! ─ “Can you reset my password?” ─ “Can you get rid of these replication conflicts?” ■ Your brain wasnt 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: Its too easy to do damage when you are being pulled in fifty different directions! 12© 2013 RunningNotes
  13. 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. 13© 2013 RunningNotes
  14. 14. Solution Bonus! ■ Users can use your Developer IDs Inbox as a request for support/ features. ─ This will keep them completely separate from your daily Inbox! 14© 2013 RunningNotes
  15. 15. Pitfall 2: Not switching IDs because its too inconvenient! ■ When things are too inconvenient, we dont do them. ─ This is true for ANY process, home, work or otherwise! ■ Its HARD to remember to do a File-->Security-->Switch ID! ─ And, its kind of a pain. We understand. 15© 2013 RunningNotes
  16. 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! 16© 2013 RunningNotes
  17. 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. 17© 2013 RunningNotes
  18. 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. 18© 2013 RunningNotes
  19. 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. ─ Its an easy switch, do it right from the bottom right of the Notes client. 19© 2013 RunningNotes
  20. 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? 20© 2013 RunningNotes
  21. 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]” ■ Dont forget to put the Servers, and the Admin in there! ─ Thats 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) 21© 2013 RunningNotes
  22. 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 its 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. 22© 2013 RunningNotes
  23. 23. Pitfall 5: Not Creating a Sandbox Server ■ One that mirrors your environment ─ Its easy to create a sandbox server. ‒ If you havent, its the first thing you should do when you get home ─ Its less easy, but very important to make your sandbox mirror your production environment! ‒ User Groups/Roles/Access ‒ Replication ‒ User data ‒ Nightly agents running ‒ Everything! 23© 2013 RunningNotes
  24. 24. Pitfall 6: Being Disorganized ■ It is easy to think you dont 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. ─ Its very easy to lose track of what needs to be done and with no one else to remind you, its even MORE important to organize and document 24© 2013 RunningNotes
  25. 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! 25© 2013 RunningNotes
  26. 26. Pitfall 7: Not Building a Network. ■ No, not a Domino network! ─ Youve 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! 26© 2013 RunningNotes
  27. 27. Be Social! 27© 2013 RunningNotes
  28. 28. Agenda ■ Introduction ■ Avoiding Pitfalls of Going It Alone ■ Reaping Rewards of Being On Your Own 28© 2013 RunningNotes
  29. 29. Reward 1: Make Your Own Administration Process! ■ What is the Administrative Process again? ─ Its 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, its 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? 29© 2013 RunningNotes
  30. 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 30© 2013 RunningNotes
  31. 31. Reward 1 (cont.) ■ PS – when its finished, think about putting it on OpenNTF.org! ■ Time for a demo! ─ The Automated Admin ─ Admin Power Tools 31© 2013 RunningNotes
  32. 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 its 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. 32© 2013 RunningNotes
  33. 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. ■ Whats 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. ─ Heres one I use daily: ─ @Command([ToolsRefreshSelectedDocs]);@True 33© 2013 RunningNotes
  34. 34. Reward 4: You Know What Your Servers Can and Cant 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 dont have to have admin lockdown ■ You can create the necessary compromises between security and performance 34© 2013 RunningNotes
  35. 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 35© 2013 RunningNotes
  36. 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! ─ Its 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 36© 2013 RunningNotes
  37. 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! 37© 2013 RunningNotes
  38. 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) 38© 2013 RunningNotes
  39. 39. Reward 7: Make Yourself Happy (cont) ■ 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 didnt already know it was you. 39© 2013 RunningNotes
  40. 40. Reward 7: Make Yourself Happy (cont) ■ 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: LotusDominodataappscustomersrv.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. ─ Its 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., 40© 2013 RunningNotes
  41. 41. Reward 8: You Can Restore When Needed! ■ Youll 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, youll know what is broken and why, and how far to go back to fix it 41© 2013 RunningNotes
  42. 42. Reward 9: You Can Prioritize! ■ You can decide whats 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! 42© 2013 RunningNotes
  43. 43. You Dont Have to Go Home, But You Cant Stay Here ■ Fill Out Your Evals! ■ Contact us: ─ @NerdGirlJess ─ @RunningKathy ■ Get Social! Have Fun! 43© 2013 RunningNotes

×