February 2008 - Posts
בחלק הקודם סקרתי את המנגנון שמסתתר מאחורי מדריך האתרים. עכשיו הגיע הזמן לראות איך משתמשים בו.
Governance
כמו שאמרתי בפוסט הקודם, מדריך האתרים הוא אחד מאמצעי הניהול והבקרה ב- MOSS - רק צריך לדעת קצת על שלוש אפשרויות חשובות:
- אכיפת שימוש - כברירת מחדל, רישום אתרים במדריך הינו אופציונלי ונתון להחלטת יוצר האתר (ראו במסך למטה "רשום אתר חדש זה במדריך האתרים"). כדי לשנות את זה, קיימת אפשרות האכיפה בשתי רמות:
- באתר הניהול המרכזי - admin/SiteDirectorySettings.aspx_
- בהגדרות אוסף האתרים - layouts/SiteDirectorySettings.aspx_
- בדיקת אתרים שאינם רשומים - כן, גם על זה חשבו וזה נמצא באתר הניהול המרכזי: admin/LinksCheckerJobSettings.aspx_
- רשימה כוללת - בכל אוסף אתרים ישנו רישום מסודר של כל תת-האתרים, כולל התבנית מהם נוצרו (!), עם גישה ישירה לניהול שלהם. יותר מזה אנחנו לא צריכים - layouts/vsubwebs.aspx_
רישום אתר למדריך
קודם כל חשוב לזכור, שממשק יצירת אתר חדש מספק יכולת קיטלוג רק לשדות של "איזור" ו"אגף". כך שכל שדה שתוסיפו תצטרכו להזין עצמאית לאחר יצירת האתר.
יש שתי אפשרויות עקרוניות לפתור את זה:
- פיתוח של מסך יצירת אתר מורחב - לא במסגרת היכולות שלנו.
- שימוש ב-workflow על רשימת האתרים (lists/sites) - ניתן להגדיר WF ב- SharePoint Designer שיופעל אוטומטית עם כל הוספה של פריט חדש לרשימה (=עם כל יצירת אתר) ויבצע פעולות רלוונטיות - למשל ישלח מייל למנהל הפורטל, או יבקש מהמשתמש מידע ויזין אותו אטומטית לשדות המתאימים וכו'.
יצירת קטגוריה\דף חדש במדריך ב- 4 צעדים
אם תשתמשו בסכימה שהצגתי בפוסט הקודם, יהיה קל יותר להבין את הצעדים:
| פירוט | תמונה |
יצירת דף חדש - אפשר ליצור את הדף איפה שרוצים ובלבד שתיצרו אותו מתבנית "דף הבית של מדריך האתרים" | |
עריכת הדף החדש - שימו לב ל- WP קטגוריות - בדף שלכם הוא כמובן עוד לא קיים, מייד תוסיפו אותו... | |
הוספת WP קטגוריות - בתמונה 2 אפשר לראות את היכולות של ה- WP הזה למעשה זוהי שאילתת תוכן. | |
הוספת כרטיסייה (TAB) - שימו לב להפנות לאותו שם דף שיצרתם מקודם - ללא הוספת קידומות! (=ללא http://...sites/pages וכו') | |
זהו. כמובן שניתן להוסיף עוד WP לדף ולקנפג אותם איך שתרצו - הנה דוגמה לדף כזה, אליו הוספתי גם WP שאילתת תוכן (Content Query) - בסופו של דבר ה- WP "קטגוריות" בבסיסו הוא פשוט שאילתת תוכן:

קצת רקע

בפראפראזה על דברי הרמב"ם בהקדמתו למורה הנבוכים שלו: "אין הכוונה במאמר זה להבין את כולם להמון, ולא למתחילים בעיון... אלא מטרת המאמר הזה להעיר לאדם המשכיל, שכבר נקבע בלבו והושג בדעתו אמיתת ה- MOSS, והוא שלם בדעתו ומידותיו, ועיין במדעי ה- MVP's וידע ענייניהם, ועמדו בפניו פשטי ה- MOSS, ומה שלא הצליח להבינו ויישאר במבוכה והיסוס... ואל ידרוש ממני הנבון, ואל יתלה תקוותיו שבכל מקום שאזכיר עניין מסוים שאני אשלימנו... כי דבר זה אי אפשר לשום משכיל לעשותו..."
או בעברית: הפוסט מניח נסיון מוקדם בעבודה עם מדריך האתרים.
אז קודם כל, מדריך האתרים הוא למעשה אתר ב- MOSS בשם "אתרים" (Sites), המגיע כברירת מחדל עם כל אתר מתבנית שיתוף\פרסום. התפקיד המרכזי של האתר הזה הוא להציג את האתרים הקיימים בפורטל, מקובצים בקבוצות שונות עפ"י הצורך.
ה"לב" של האתר הוא רשימה בשם "אתרים" המחזיקה רישום של כל האתרים והמטה-דאטה\מאפיינים שלהם. התצוגה עצמה מתבצעת ע"י דף הפתיחה של האתר, בו מוצגים טאבים (כרטיסיות) המאפשרים תצוגות שונות של כלל האתרים בפורטל (וגם של כל קישור שהוא אותו בחרו מנהלי הפורטל להוסיף למדריך).
מי צריך את המדריך?
האמת ניתנת להיאמר, שבחלק מאתרי ה- MOSS שיצא לי לראות, אין שימוש במדריך. האתרים פשוט לא נרשמים, או שסתם נרשמים עם מאפייני ברירת המחדל וזהו זה. הסיבה היא בדרך כלל "הערכת חסר" של משמעות המדריך + הבעיה שהמדריך מורכב מכמה ישויות שבמבט ראשון (וגם שני) לא ברור בדיוק הקשר ביניהן ואיך מתפעלים אותן - אז פשוט מניחים את זה בצד. (רמז לכך מצאתי בפסוק מפורש בתורה - "וַיִּשְׁמַע הַכְּנַעֲנִי... ישֵׁב הַנֶּגֶב, כִּי בָּא יִשְׂרָאֵל דֶּרֶךְ הָאֲתָרִים, וַיִּלָּחֶם בְּיִשְׂרָאֵל" - דרש ר' עַmoss: אין כנעני אלא יצר רע ואין דרך אלא מדריך. מכאן שהיצה"ר של מנהלי הפורטל נלחם בהם מלהשתמש ב"דרך האתרים" הלא הוא מדריך האתרים ודו"ק...)
אז סיבה ראשונה ומיידית להשתמש במדריך היא כמובן מפת האתר, שהיא אחד הדפים המגיעים כברירת מחדל עם המדריך. זה נוח, שימושי, ולא מצריך מאמצי תחזוקה כלשהם - כל אתר חדש שנוצר ונרשם - יופיע בהתאם.
אבל ישנה סיבה נוספת, לא פחות חשובה - המדריך הוא אחד מאמצעי ה- Governance החזקים של הפורטל, בזכות היכולת לכפות רישום של אתרים אליו, כולל המאפיינים שלו. המשמעות היא, שגם בפורטל מבוזר בו יש מספר מנהלי אתרים הרשאים ליצור אתרי-משנה, יש לכם תמיד שליטה על כל אתר שנוצר אי-שם + מהם המאפיינים שלו.
מדריך למדריך
אז לפני שנתחיל, הנה סכימה של הישויות השונות במדריך והקשרים ביניהן - זה נראה אמנם כמו תרשים מערך התקפה בפוטבול במבט ראשון, אבל אני מקווה שעם ההסברים למטה הכל יתבהר:
הסכימה מתארת למעשה 3 ישויות המשפיעות על המדריך, שניתן לחלק אותם ל- 2 קבוצות:
רשימת האתרים - זה "מסד הנתונים" שמחזיק את רישום כל האתרים, כרשימת SharePoint לכל דבר. התוצאה היא פשוט טבלה ובה מספר עמודות מידע, הבאות לידי ביטוי במקומות שונים במדריך:
- שם האתר - כשמו כן הוא
- איזור\אגף - שדה מסוג אפשרות המשמש להצגה כקטגוריות נפרדות
- אתר מוביל - שדה מסוג כן\לא המשמש להצגה ייעודית כאתר מוביל
- משימות וכלים - שדה מסוג אפשרות המשמש להצגה ייעודית ב- WP "עליי" (I need to) בדף הבית (אם כי ניתן להשתמש בו גם כקיבוץ לקטגוריות)
חשוב להדגיש - במסך יצירת אתר חדש (layouts/newsbweb.aspx), יוצגו לבחירת המשתמש רק השדות "אגף", "איזור" ו"משימות וכלים". כל שדה אחר שתגדירו לא יבוא לידי ביטוי - אז תשתמשו באלו הקיימים!
כרטיסיות + דפים - אלו אמצעי התצוגה של רשימת האתרים, המאפשרים "מניפולציות" על הרשימה להצגת האתרים השונים בחיתוכים שונים. מאחורי כל כרטיסיה (טאב) עומד דף aspx אותו אתם יכולים ליצור לבד, מתבנית "דף הבית של מדריך אתרים" (ראו בהמשך). דף זה מכיל מראש WP ייעודי בשם "קטגוריות" אותו אתם יכולים לערוך כרצונכם. לחיצה על הכרטיסייה פשוט מעבירה אותכם לדף הרלוונטי.
עוד לא ברור? אז הנה אותה סכימה, אבל עם הרכיבים עצמם:
טוב, קצר המצע מהשתרע ויש לי עוד 2-3 תמונות בגודל טבעי להציג - אז אעצור כאן בינתיים.
בחלק הבא אני אציג את תהליך יצירת הכרטיסיות + איך מגדירים כל מה שצריך בשביל לאכוף את הרישום.
האמת שכבר לפני הרבה זמן רציתי להפנות את תשומת ליבכם לאתר הנהדר הבא, אבל מן השמיים עיכבו בידי...
אז הנה - http://www.sharepointhosting.com/video_tutorials.html
באתר יש כ- 50 סרטונים קצרצרים (חצי דקה-דקה) ויעילים למשתמשים מתחילים ב- SharePoint.
כדי להקל עליכם מצ"ב טבלה ובה קישורים ישירים לסרטונים החשובים ביותר (לדעתי):
בנוסף, ישנם סרטונים טובים גם באתר של Kwizcom -
http://www.sharepoint-howto.com/Lists/Screen%20Casts%20Links/AllItems.aspx
מנסיוני זה מקל מאוד את ההטמעה הראשונית של SharePoint מול כמויות גדולות של משתמשים.
בפוסט הקודם הבטחתי להתחיל לכתוב קצת על Governance - אז הנה הנושא הראשון והחשוב ביותר לדעתי - ניהול הרשאות.
נושא הקצאת הרשאות למשתמשים ולפריטי מידע הוא אחד המרכזיים ביותר בכל מערכת, בוודאי ב- SharePoint 2007, שעשה קפיצת דרך גדולה מאז גירסת 2003. הבעיה היא שמודל ההרשאות קצת מורכב ולא תמיד ברור איך בדיוק עושים מה ואיפה.
שתי בעיות מרכזיות אחראיות ל"ערפל הקרב" הזה לדעתי, ואני מקווה לתת להן מענה בסיסי בפוסט הזה:
1. "קבוצות" SharePoint - ארכיטקטי המוצר הוסיפו ישות בשם "Group" המהווה קבוצת הרשאות פנימית של SharePoint. הבעיה שלא מעט מתבלבלים בינן לבין קבוצות ההרשאה הרגילות של Active Directory, או שכלל לא מבינים את הצורך בהן.
2. דפי הניהול - בכדי לנהל את מערך ההרשאות, יש צורך להשתמש לפחות ב- 4 דפי ניהול, בכל אחד פעולות משלו, ובחלקם ישנן פעולות זהות, מה שמגדיל את הבלבול - איפה עושים מה?
הנחת העבודה שלי בפוסט היא שאתם מכירים ברמה סבירה מה זה Active Directory - אם לא כל-כך -
תקראו ב- Wikipedia, זה מסביר הכל. אגב, המודל תקף כמובן גם במקרה של זיהוי מבוסס טפסים (Forms Authentication), אלא שבמקום AD יש לנו את ה- asp.net DB או כל מסד משתמשים אחר.
"גליון הרשאות" - הבנת מודל ההרשאות ב- MOSS 2007
לפני שנתחיל, נסתכל רגע על הסכימה הבאה, שמתארת את מודל ההרשאות ושיוכן למשתמשים\קבוצות במערכת. שימו לב שמתחת לכל "ישות" הוספתי את שם דף הניהול הרלוונטי (יש להוסיף כמובן את כתובת האתר לפני ה- /Layouts_. במקרה של דף admin_ יש להוסיף את כתובת אתר הניהול המרכזי). מייד תקבלו הסבר מושגים + הסבר תהליכים לתרשים הזה:
הסבר מושגים
הרשאות - זה ה"סל" של כל סוגי\פרטי ההרשאה האפשריים, ברזולוציה הגבוהה ביותר. לא ניתן להוסיף הרשאות מעבר לקיים (למשל אם תרצו לתת למשתמש הרשאות להוספת wp מסוג עורך תוכן בלבד וכדומה). לשם נוחות, מחולקות ההרשאות ל- 3 קבוצות תצוגה: רשימה, אתר ואישיות - אבל אין לכך משמעות פונקציונלית. המקבילה של זה ב-AD הן כמובן ההרשאות read, write, execute וכו'.
חשוב לזכור, ותראו את זה בהמשך כשתקבצו רמות הרשאה להרשאות וכו', כי ישנן רמות הרשאה התלויות זו בזו: אם בחרתם ברמת ההרשאה "הוספת פריטים" אוטומטית ייבחר גם "הצגת פריטים" וכן הלאה. לכן אל תסתמכו על הרשימה כדי לקבוע שניתן לתת הרשאות אך ורק לפעולות אלו ואחרות, אלא תנסו בפועל לבחור ותראו מה נבחר אוטומטית ביחד עם בחירתכם.
רמות הרשאה - קבוצות\קטגוריות של הרשאות, או בלשון אחרת - Roles. כאן כבר ניתן להוסיף Roles משלנו, שיורכבו למעשה מסט של הרשאות כאלו ואחרות, על-פי החלטתנו. המקבילה של זה ב-AD היא למשל Full Control, שלמעשה מסמנת אוטומטית את כל רמות הרשאה הקיימות.
אפשרות נוחה מאוד היא "העתק רמת הרשאה", שמאפשרת "להתלבש" על רמת הרשאה קיימת וליצור ממנה חדשה עם השינויים הרלוונטיים, במקום להתחיל מאפס.
קבוצות SharePoint - הקצאה של רמת הרשאה ספציפית למשתמשים\קבוצות מה- AD. אם ב-AD הקבוצות מכילות רק משתמשים\קבוצות אחרות, הרי שכאן הקבוצות מכילות גם הרשאות כחלק בלתי-נפרד מהגדרת הקבוצה.
בהתאם לכך, ישות לוגית זו מאפשרת שתי פעולות עיקריות:
- קיבוץ של משתמשים\קבוצות מה-AD מצד אחד
- הקצאת הרשאה (אחת בלבד) לקבוצה מצד שני.
הסבר תהליכים
בהנחה והגדרות ברירת המחדל של MOSS לא מספקות אותכם, או שאתם רוצים לחקור אותן, סדר הפעולות הוא כזה (המספור עפ"י התרשים):
- באתר הניהול המרכזי החליטו אילו הרשאות יהיו בכלל חשופות בכל אוספי האתרים (admin/vsmask.aspx_).
- לאחר מכן באוסף האתרים הרלוונטי קבצו הרשאות לרמות הרשאה מתאימות, עפ"י הצורך.
- אופציה א': הקצו רמות הרשאה ישירות למשתמשים\קבוצות מה- AD
- אופציה ב': הקצו רמות הרשאה לקבוצות SharePoint ובמקביל -
- אופציה ב' - המשך: שייכו משתמשים\קבוצות מה- AD לאותן קבוצות SharePoint
מתי להשתמש בקבוצות SharePoint?
שאלה מצויינת - למרות שהקבוצות האלו מוטבעות בפורטל, ואוטומטית מקבלים אוסף של קבוצות כאלו, מומלץ לחשוב טוב לפני שמשתמשים בהן, בשל הכפילות והבלבול שעלולים להיווצר.
אז קודם כל חשוב להבין את המטרה של הישות הזו - בגדול המטרה היא "לעקוף" מצבים בהם אין קבוצות מתאימות ב- AD שיקבצו אוסף של משתמשים להם רוצים לתת הרשאה מסויימת בפורטל. לדוגמה: אם יש לי הרבה משתמשים להם אני רוצה לאפשר יכולות ניהול מלאות באתר, אני יכול לבנות קבוצת SharePoint בשם "בעלי אתר" (כן, אני יודע שיש כזו...) ולשייך אליה את המשתמשים הרלוונטיים מה- AD.
היתרון בכך הוא, שניתן לשנות את "אופי" הקבוצה בפעולה אחת, וזה יחול רוחבית - לדוגמה, אם אני רוצה שמנהלי האתר יהפכו למשתתפים בלבד, כל שעליי לעשות הוא לערוך את הקבוצה ולתת לה הרשאת "השתתפות" במקום "ניהול". כנ"ל אם אני רוצה למנוע ממשתמש בודד לנהל את האתר - אני עורך את הקבוצה ומסיר אותו ממנה וזה יחול על כל המקומות בהם לקבוצה זו יש הרשאות.
ככלל אצבע, רק בהתקיים שני התנאים הבאים במצטבר יש מקום להשתמש בקבוצות:
- אין קבוצה מתאימה ב- AD
- קיימות מספר ספריות\רשימות\אובייקטי תוכן להם יש צורך לשייך את אותה קבוצה בדיוק
מתי כדאי להשתמש בקבוצות SP - דוגמה:
אתם מעוניינים לתת לקבוצת משתמשים בארגון יכולת ליצור תצוגות אישיות ברשימות. למשתמשים אלו אין מכנה ארגוני משותף (ולכן לא יטרחו ליצור להם קבוצה ב- AD) וכמות הרשימות האפשריות היא גדולה. כאן קבוצות SP נותנו מענה מצויין - צרו רמת הרשאה בשם "משתתף עם תצוגות אישיות", שייכו אותה לקבוצת SP בשם "משתתפים עם תצוגות אישיות" ובמקביל שייכו לקבוצה הזו את כל המשתמשים המתאימים מה- AD.
מתי לא כדאי להשתמש בקבוצות SP - דוגמה:
אתם יוצרים מספר סקרים בארגון. לכל סקר קהל יעד משלו, להם נדרש לתת הרשאות השתתפות בסקר. אם תשתמשו בקבוצות SP, תצטרכו ליצור מס' קבוצות כמספר הסקרים + תצטרכו לנהל שיוך ידני של משתמשים לקבוצות. אם תשתמשו בקבוצות AD - פעם אחת תשקיעו ביצירת הקבוצות (בד"כ באחריות ה- IT), ומכאן והלאה לכל סקר תשייכו ישירות רמת הרשאה לקבוצת ה- AD המתאימה.
טיפ קטן - הרשאה מוגבלת
לא דיברתי בפוסט על הצד השני של המטבע - איך נותנים הרשאות לאובייקטי תוכן שונים (ספריות, מסמכים וכו'), וכמובן נושא ההורשה או ה"שבירה" של הרשאות בין ישויות.
אבל שימו לב למשהו אחד מעניין ומוזר - במקרה של "שבירת" הרשאות (=מתן הרשאות ייעודיות למשתמשים מסויימים על פריטים מסויימים), אם תלכו לדף ניהול ההרשאות (user.aspx) של אתר האב, תראו פתאום שאותם אנשים נוספו כ"הרשאה מוגבלת". זו הדרך של MOSS להודיע למנהל האתר שיש באתר אנשים בעלי הרשאה חריגה על פריטי תוכן. זה יכול להיות מאוד מטריד כשמדובר באתר עם הרבה "שבירות" - מתקבלת רשימה גדולה מאוד של בעלי הרשאה מוגבלת - אבל זה מה יש, לפחות ככל הידוע לי.
מקורות
מומלץ לעיין במאמר הבא:
http://technet2.microsoft.com/Office/en-us/library/610a48d4-a805-4c47-8801-a8a912b294ea1033.mspx?mfr=true
ובבלוג הבא של Sahil Malic שמדגים חלק ממה שהצגתי:
http://blah.winsmarts.com/2007-4-SharePoint_2007__Fine_grained_permission_control.aspx
קיצור תולדות ה- Governance
לאחרונה עלה הנושא של MOSS Governance למודעות של ארגונים בארץ, ואפילו קויימו כבר שני ימים פתוחים של מייקרוסופט בנושא.
לזכות מייקרוסופט ייאמר שארכיבישוף ה- MOSS, מכרנו Joel Oleson, מעלה את הנושא שוב ושוב כבר מאז 2006, תוך שהוא נוגע כמעט בכל התחומים הקשורים לכך - ארכיטקטורת מידע, ניווט, תבניות, מדיניות מידע וכמובן Capacity Planning מכל כיוון אפשרי.
אז מה זה בכלל Governance? בקצרה, זה כל מה שקשור בניהול ותכנון נכון של מערכות ופורטלים מבוססי MOSS. אבל ההגדרה הקולעת ביותר באה (שוב...) מ- Joel, ודווקא על דרך השלילה - פשוט תקראו את הפוסט השנון שלו ותצחקו (במרירות...) - כניסה לפרוייקט MOSS בלי ניהול נכון היא מתכון בדוק לכאוס ארגוני ולכשלון פרוייקטלי. כמות היכולות המסתתרות במוצר, והנטייה שלו "להתפשט" בארגון כאש בשדה קוצים גורמים לאחר זמן קצר לכפילויות מידע, בלגן בהרשאות, חריגה מנפחי האיחסון הקיימים, חוסר יכולת לחפש מידע ועוד ועוד.
כחומרי מניעה\עזר הוצעו לציבור מספר חומרים שמציגים את הנושא בכלליות, וכמובן מסמך ה- Checklist הנחמד הזה, שמחולק גם כ"מניפה" מוכנה לשליפה. הבעיה עם החומרים האלו היא שהם כלליים מדי ולמעשה לא נותנים למנהל הפורטל ו\או לאנשי ה- IT כלי עבודה, אלא (וגם זה חשוב) אוסף של תזכורות למה חשוב לשים לב.
HP נכנסת לתמונה
כאן המקום לגילוי נאות - אני עובד בחברת HP, שלאחרונה פרסה את מה שמסתמן כחוות MOSS 2007 הגדולה ביותר בעולם, כפורטל ארגוני לכ- 150 אלף עובדים בכל העולם. זה שווה פוסט בפני עצמו, שאני מקווה שיורשה לי לפרסם (קבעתי עם Mark Hurd שנדבר על זה בבית כנסת...), אבל מה שכן אפשר לגלות זה שכחלק מתהליך הפריסה הצוות האחראי הוציא מסמך SLA המפרט ברחל בתך הקטנה את כלל השירותים הקיימים ב- MOSS, בחלוקה ל- 3 רמות שירות, כולל פירוט כל ה- web parts ועוד ועוד. בדיוק באותה תקופה אני הייתי עסוק בכתיבת מדריך מעשי לניהול פורטל ארגוני והמסמך של HP "שייף לי את הפאנלים" כמו שאומרים....
אז התוצאה היא מסמך שמקיף (כמעט) כל מה שצריך לדעת על MOSS 2007 Governance, אבל ב-4 הבדלים חשובים מרוב החומר הקיים:
- מיועד גם לאנשי ה- IT, גם למנהל הפרוייקט וגם למנהלי\מיישמי הפורטל
- המסמך הוא מעשי - לא ניסוחים מעורפלים של "שימו לב ל..." אלא הנחיות מעשיות + המלצות לביצוע.
- המסמך מכיל הפניות ל(כמעט) כל דפי הניהול הרלוונטיים - רק לחיפוש, לדוגמה, יש כ- 10 דפי ניהול רלוונטיים (אני מתכוון לדפים כמו layouts/enhancedSearch.aspx_ ודומיהם). דפי הניהול מפוזרים בין הניהול המרכזי, ניהול ה- SSP וניהול אוסף האתרים, והמיון שלהם לפי נושאים מקל מאוד - לדעתי - על עבודת התכנון.
- וכמובן - המסמך בעברית...
אבל...
מטבע הדברים, תוכן המסמך הוא IP של HP (בתחום ה- SP...) ולא אוכל לחשוף אותו לציבור. מה שכן, בפוסטים הבאים אני אציג כמה נושאים מהמסמך וארחיב עליהם, כי לדעתי זה הנושא המרכזי ביותר שכל מיישם\מטמיע,מנהל פרוייקט בתחום ה- MOSS צריך ללמוד לפני שהוא נכנס להרפתקאה המרתקת הזו.
זו אגב הסיבה שהדמות המוערכת ביותר בעולם ה- MOSS מבחינתי היא (אם לא שמתם לב) Joel Oleson - הוא פשוט בין היחידים ששם את הנושא על סדר היום, ומשגיח עלינו מלמעלה שלא נתפתה לעסוק כל היום ב- web parts חדשים וקוליים מבית Codeplex וכדומה....
אז היכונו לביאת המשגיח!