יש לכם אתר אינטרנט שמתארח ב – IIS6 ונמצא מאחורי NLB והדפים שלכם לפעמים עולים לאט ולפעמים יותר מהר ?!
יכולות להיות מספר סיבות להתנהגות (מעצבנת) שכזו. אני רוצה לדבר כאן על גורם אחד חמקמק…
(ממליץ לקרוא פוסט קודם שעוסק בנושא של caching ל- static contents).

ETag

אז מה זה Etag?
בקצרה – חלק מפרוטוקול HTTP. השרת מייצר ETag Header שאמור לייצג “גרסה” של ה- resource שאותו הוא מספק (בד”כ רלוונטי יותר ל- static contents – תמונות, JS וכיו”ב) והדפדפן משתמש ב- Header הזה לבדיקת caching.
ה”גרסה” של resource, בד”כ, מיוצגת ע”י תאריך עדכון של ה- resource.

אז איפה הבעייה?
נניח שיש לי תצורה של שני שרתי IIS מאחורי NLB. אני מבצע request לדף – page1.aspx וה- NLB מפנה אותי לשרת א’. בתוך הדף יש “קבצים” מקושרים – תמונות, JS וכו’. הדפדפן מוריד גם אותם משרת א’ ושם עותק ב- cache המקומי.
בפעם הבאה שהדפדפן מבקש את הדף page1.aspx הוא צריך שוב את ה”קבצים” המקושרים, הוא בודק האם הם קיימים ב- cache המקומי שלו וכשהוא פונה לשרת לקבל את הקובץ המקושר, הוא מוסיף ב- request את ה – ETag של הקובץ מה – cache. השרת בודק האם ה – Etag שנשלח ב – request זהה ל – Etag השייך ל- resource המתאים על השרת.
אם זהה – מחזיר HTTP 304, אחרת, מחזיר לדפדפן את הקובץ המלא.
בהנחה שיש לי שרת אחד, אחרי הפנייה הראשונה לדף, כל שאר ה – static content יגיע מה – cache, שכן השרת יזהה שה – ETag זהה.

טוב, אז מה הבעייה? הרי אם שמתי לדוגמא, את אותו קובץ תמונה על שני שרתים, ה-ETag יהיה זהה בשניהם, שהרי לשניהם אותו תאריך עדכון אחרון…

אז ככה…
ב – IIS הערך של ה – ETag בנוי משני חלקים בערך במבנה הבא: ComputedValue:ChangeNumber.
ComputedValue – זה הערך שהשרת מייצר לפי תאריך עדכון אחרון.
ChangeNumber – זהו ערך קבוע.

OK, ובכל זאת איפה הבעייה?
ב – IIS6, הערך של ה – ChangeNumber לא בהכרח זהה בכל שרת…, לכן, הערך של ה – ETag כולו, עלול להיות שונה עבור אותו קובץ בשני שרתים שמאחורי NLB אחד. כך שלמרות שלכאורה ה- resource שנמצא ב – cahce של הדפדפן עדכני, אם הערך הקיים ב – cache שייך לקובץ משרת א’, אם ה – NLB מפנה אותי ב – request אחר לשרת ב’, במקום לקבל את הקובץ מה – cache, הקובץ ירד מהשרת.

ולכן, כאשר ה – NLB מפנה אותי לשרת אחר, אני עלול להרגיש שהדף יורד לאט יותר ואילו כאשר הוא מפנה אותי לשרת שהייתי בו קודם, הדפים יורדים מהר יותר.

אז אחרי שהבנו (אני מקווה) את מקור הבעייה, בואו נדבר על פתרונות:

1. sticky session – פותר את הבעייה ברמת session. יתכן שבהתחברות הבאה, הדפדפן יופנה לשרת אחר ושוב יצטרך להוריד את הקבצים הסטטים.

2. לעבור ל – IIS7 – למה? ב – IIS7, כברירת מחדל, הערך של ה – ChangeNumber הוא 0. ומאחר ואני מניח שאף אחד לא מתעסק עם הערך הזה, ניתן להניח שכל השרתים ייצרו את אותו ETag לאותו דף.

3. לעדכן בכל שרתי ה – IIS6 את הערך של ה – ChangeNumber לערך זהה. איך? ככה.

יש לכם בעיות אחרות/נוספות עם caching? עם ביצועים באפליקציה שלכם? אתגרו אותי.

בהצלחה,

טל

שירותי MCS רלוונטיים

· (PDF) שירות ניתוח פערים ושיפור ביצועים

· (PDF) שירות תכנון וניתוח בדיקות ביצועים

· (PDF) סדנת פיתוח מערכות מונחה ביצועים

התשובה הטבעית היא כמובן: “לא” ב- ל’ רבתי. ארכיטקט חייב לפעול מתוך שיקולים מקצועיים קרים וברורים, לדעת להסביר כל החלטה שלו באמצעות נימוקים רציונליים ולעולם לא לנטות לכיוון ארכיטקטוני מסוים בגלל שכיוון זה מקדם מוצר כזה או אחר, או שירות כלשהו.

אז לאחר ששמנו את הנושא הזה מאחורינו, ווידאנו שכולם מבינים את הרעיון, נשאל שוב – האם לעולם לא יקרה שארכיטקט יעבוד כאיש מכירות?

למעשה התשובה מסובכת קצת יותר. עבודת הארכיטקט למעשה מחולקת לשני חלקים עיקריים:

- בניית הארכיטקטורה

- הטמעת הארכיטקטורה

 

לגבי החלק הראשון – בניית הארכיטקטורה אכן אמורה להתבצע בצורה מקצועית וקרה, והיא לעולם לא תושפע משיקולים זרים. ארכיטקט שעושה זאת – חוטא לתפקידו בצורה הבוטה ביותר, וסביר להניח שלא יאריך ימים בתפקיד זה.

ומה לגבי ההטמעה? פה הנושא קצת שונה. במקרים רבים הארכיטקט הוא פונקציה חיצונית לארגון, או מבחינה רשמית (לדוגמה – יועץ חיצוני שמסייע לארגון בפרוייקט מסוים) או מבחינה מעשית (אם הארכיטקט הוא פונקציה צדדית שאינה מנהלת עובדים ישירות ואינה מעורבת בפיתוח בפועל). במקרים כאלו מתעוררת הבעיה הידועה בשם “השפעה ללא סמכות”. הארכיטקט צריך לגרום לארגון לממש את הארכיטקטורה למרות שאין לו את הסמכות להחליט על כך. מה עושים במצב כזה?

כל מי שעוסק בשיווק יותר משבוע יודע שהדרך הטובה ביותר לגרום לאדם מסוים לבצע פעולה מסויימת (למשל: לקנות טוסטר משולב במשקפי צלילה) ללא סמכות היא על ידי שכנוע אותו האדם כי הוא צריך לבצע את הפעולה. ניתן, למשל, להסביר לאותו אדם כי חווית אכילת טוסטים מתחת למים תשפר את חייו ללא הכר ותגרום לו להבין עד כמה הטוסטים הקודמים שאכל היו יבשים ומשעממים ביחס.

במובן מסויים הארכיטקט עומד בפני משימה דומה. עליו לגרום לארגון להבין שהוא צריך לממש את הארכיטקטורה, לא כי הארכיטקט אמר כך אלא בגלל שזה מה שבאמת טוב לארגון.

 

אז איך עושים את זה?

ובכן, הדבר החשוב ביותר לעשות לפני תחילת שיווק הארכיטקטורה, ולמעשה לפני תחילת בניית הארכיטקטורה, הוא להבין את הסביבה העסקית של הלקוח. לפני שעשינו את זה – חבל על המאמץ והזמן. כבר נתקלתי בארכיטקטורות שהיו מבריקות מבחינה מקצועית אבל לא התאימו בכלל לסביבה העסקית של הלקוח, לדוגמה: ארכיטקטורה שלקחה בחשבון התקנת בסיס נתונים קטן על תחנות הקצה לצורכי Offline, אבל שכחה לחלוטין שהלקוח עובד בסביבה עסקית עם שולי רווח קטנים ביותר ותחרות פרועה, ותוספת של כמה דולרים לכל תחנה עבור אותו בסיס נתונים (שלא היה חינמי, אם עוד לא הבנתם…) היתה מוציאה אותו לחלוטין מהשוק.

אחרי שעשינו את זה – הגיע הזמן ללמוד לדבר בשפה של הלקוח. כן, גם מונחים מהסלנג המקומי של הלקוח. ארכיטקט  לא צריך לעבוד עם מתורגמן צמוד. אני אתן דוגמה דווקא ממיקרוסופט: בתקופה זו אנו סוגרים את החציון הראשון של השנה הפיסקלית, וניתן לראות במייל משפטים בסגנון הבא:”ה- CPE ב- H1 FY10 משתקף ב- CBI של MCS”. ברור, לא? לכל לקוח יש את הז’רגון שלו, הן בתחום הטכנולוגי והן בתחום העסקי. למדו את הז’רגון, וכך לא רק שתבינו יותר את הלקוח, הוא גם יקשיב לכם יותר.

ועכשיו מגיע השלב החשוב ביותר – הדגשת התועלת העסקית של הארכיטקטורה ללקוח. בינינו, ללקוח לא ממש משנה אם נעשה שימוש ב- Entity Framework או NHibernate, או אפילו אם נכתוב ב- .NET או Java. אותו מעניין דבר אחד: איזו טכנולוגיה ואיזו ארכיטקטורה תחסוך לי כסף בטווח הארוך? ומכיוון שזה מה שמעניין אותו – זה מה שצריך להגיד לו.

משפט כמו: “הארכיטקטורה החדשה תסייע לך להטמיע את הטכנולוגיות החדשות של מיקרוסופט ולהיות מוביל בעולם מבחינה זו” תגרום אולי לאנשי הפיתוח של הארגון להזיל ריר, אבל סביר להניח שהמנמ”ר / סמנכ”ל פיתוח / מנהל עסקי המעורב בדיון יזרוק אתכם מכל המדרגות, ובצדק. מצד שני, משפט כמו: “הארכיטקטורה המוצעת תסייע לתדמית העסקית של הארגון וצפוי שתגרור עליה של 15% במכירות ה- WTP בשנה הקרובה בגלל פתרון בעיית הביצועים שהמשתמשים מתלוננים עליה לאורך זמן” תגרור הקשבה מצד כל הדרגים בארגון (אגב, אין לי מושג מה זה WTP – ז’רגון של הארגון, זוכרים? (אבל אם תסתכלו ב- Wikipedia בערך הזה, תגלו שם את ספר הילדים האהוב עלי ביותר)).

 

אז אחרי שסיכמנו את נושא השיווק של הארכיטקט, נותר עוד נושא אחד חשוב, והוא – שיווק עצמי.

במקום להסביר ולכתוב על זה, אני אתן דוגמה:

בעוד כשבועיים מתקיים כנס P&P ביוזמת קבוצת MCS במיקרוסופט. ודאי שמעתם עליו, ואם לא – רוצו לקרוא. זה הולך להיות אחד הכנסים היותר מתקדמים ומעניינים שהיו בארץ, וטובי האנשים של קבוצת ה- P&P במיקרוסופט העולמית עומדים להעביר הרצאות מרתקות. גם אני מעביר הרצאה בכנס, וכרגיל ההרצאה שלי נמצאת בשעת השלאף שטונדה – מיד אחרי ארוחת צהריים…

מספר המקומות בכנס מאוד מוגבל, עקב הרצון שלנו לשמור על אוירה פחות המונית, ואין לנו ספק שכל מי שיגיע יפיק ממנו רבות.

אם עוד לא עשיתם את זה – רוצו להירשם עכשיו!

שמי אורן קנדל, אני מנהל את קבוצת היועצים בתחום ה- MCS בשנה וחצי האחרונות ובמסגרת תפקידי אחראי על ה- Delivery של פעילויות הייעוץ אשר מתבצעות על ידי היועצים בקבוצתי, על רמת המוכנות על היועצים לביצוע פעילויות אלו ועל הקשר השוטף עם השותפים העסקיים של הקבוצה. לאחרונה מסתובב לי בראש הרעיון של לכתוב פוסט על מהות התפקיד ודברים מרכזיים שלמדתי בשנה וחצי הראשונות שלי בתפקיד זה. מקווה שיעניין אתכם לקרוא על זה...

קודם כל נתחיל בכך שהתזמון שלי לכניסה לתפקיד היה מושלם (עם או בלי מרכאות כפולות סביב המילה "מושלם") – כשנכנסתי לתפקיד הדאגה הגדולה ביותר שלי הייתה איך לגייס שני יועצים חדשים לקבוצה מבלי להתפשר על הרמה המקצועית הגבוהה ביותר שאנחנו דורשים מעצמנו (בממוצע מתקבל מועמד אחד מתוך 400) ומבלי לעכב יותר מדי מספר עבודות חשובות אשר הגיעו לפתחנו. לכל מי שקורא עיתונים או נמצא בשוק שלנו בשנה וחצי האחרונות מיותר לציין כי תוך חודשים ספורים הדאגות שלי קצת השתנו...

במיקרוסופט, לכל אחד מאיתנו יש לפחות שני Title-ים. האחד הוא ה"ידידותי לסביבה" שאותו אנחנו מדפיסים על כרטיסי הביקור ובעזרתו אנו מציגים את עצמנו והשני הוא ה- Title הפנימי שמבטא את התפקיד שלנו בצורה.. בואו נגיד.. יותר מיקרוסופטית... במקרה שלי, ה- Title השני הוא PDRM או באריכות – Professional Development and Resource Manager. מאיר עיניים, לא? צריך להדפיס כרטיסי ביקור בגדול של שלטי חוצות בשביל להכיל כזה דבר... למה אני מציין זאת בכל זאת? כי התיאור של התפקיד מגדיר בצורה מאד יפה את תחום האחריות המרכזי שלי – לנהל בשוטף שיבוץ שפוי של המשימות בין האנשים (טוב, זה החלק הפחות מעניין...) ולדאוג לכך שהיועצים בקבוצה מספקים מספיק ערך ללקוחות בכדי שנישאר אטרקטיביים ונספק ללקוחות איתם אנחנו עובדים יותר תועלת וערך מהעלות שלנו. זה נשמע פשוט כשאומרים את זה כך אבל כשמשלבים את המטרות האלו בחיי היומיום, הן גוזרות משימות לא טריוויאליות.

התמזל מזלי ואת רוב התפקיד שלי עד היום ביצעתי בתנאים רחוקים מלהיות אופטימאליים. כן, המשבר הכלכלי לא פסח על אף אחד מהגורמים המעורבים בשוק, בטח לא בשוק ה- Services. למה אני רואה את זה כסוג של מזל? כי בתקופות כאלו אתה מגלה את המקסימום שלך, נדרש להוציא קצת מעבר לאותו המקסימום, מתמודד עם אתגרים לא שגרתיים, מתחשל ומתנער משומנים עודפים (טוב, את החלק האחרון אל תיקחו באופן מילולי, בנושא הזה עוד יש לי עבודה :-). זו תקופה מצוינת לחשיבה מחוץ לקופסה ולחשיבה מחדש על כל התהליכים ואופן ההתנהלות שהתרגלת אליהם. תקופה של התחדשות.

אז מה למדתי השנה וחצי האחרונות? (חשוב לציין שאת רוב הדברים לא למדתי בעצמי אלא מאנשים חכמים ו/או מנוסים ממני – היועצים בקבוצה שלי, הלקוחות שלי, הקולגות שלי, המנהלים שלי ובעלי עניין נוספים במיקרוסופט)

 

1. מעגל הערך – אם תשכיל לספק את הזמן והמשאבים ליועצים לצורך למידה והתפתחות מקצועית, הם גם יהיה מרוצים יותר מעבודתם וגם יספקו ערך רב יותר ללקוחותיהם. ערך רב מביא שביעות רצון גבוהה ומערכות יחסים בריאות וארוכות טווח עם הלקוחות. ערך מביא גם הכנסות נוספות ורווחיות גדולה יותר אשר מאפשרות לנו להשקיע יותר בפיתוח האישי שלנו וחוזר חלילה.
2. שיתוף ידע – הפריה הדדית, Review בין עמיתים, שקיפות מלאה – כל אלו מייצרים סביבת עבודה בריאה ומשפיעים באופן מהותי על איכות התוצרים אשר ניתנים ללקוחות. ואיכות בביזנס שלנו, מיותר לציין היא top priority.
3. איזון נכון בין הטווח הקצר לטווח הארוך – חשוב ואף קריטי לעמוד ביעדים בטווח הזמן הקצר (שביעות רצון לקוחות, הכנסות, רווחיות, אחוז הזמן בו היועצים מבצעים עבודת Billable) אך חשוב באותה המידה להשקיע גם באסטרטגיה של הקבוצה, בנושאים שמעבר לאופק, בבניית הכוח והכשרת האנשים. כך, לדוגמה, אחד היועצים הבכירים שלנו (דני כהן) עוסק בתחום הענן כבר יותר משנה וכאשר התחום יתחיל לפרוח בשוק המקומי הוא יוכל להנחיל את הידע לשאר הקבוצה ולהשאיר אותנו בחזית הטכנולוגיה. לשם כך אנחנו קיימים.
4. ב- Services, ניתן לתקן ולהחזיר הכל... חוץ מזמן שעבר – כשמנהלים אופרציית Services, אחת המטרות היא להישאר כל הזמן כמה שיותר עסוקים בעבודה שנמצאת על הציר האסטרטגי של החברה. אצלנו קוראים לזה Utilization (אחוז שעות ה- Billable מתוך סך כל שעות העבודה). לפעמים יש הזדמנות גדולה ומתקרבת שמתאימה בדיוק ליכולות של אחד היועצים. אם מתפתים לחכות להזדמנות במקום למצוא תעסוקה בפעילויות שכבר זמינות, עלולים לצאת קרחים מכאן ומכאן. והזמן שעובר בינתיים, אותו כבר לא ניתן להשיב...
5. השוק כל הזמן משתנה, חייבים להשתנות ביחד איתו – כולנו מכירים את אזור הנוחות. המקום הזה שבו אתה עושה מה שאתה אוהב, מה שלמדת לעשות ומרגיש הכי חזק בו. אנחנו חיים בסביבה מאד דינאמית וחובה עלינו להביט כל הזמן סביבנו ולזהות מבעוד מועד מגמות חדשות, כיוונים חדשים, דרישות משתנות ולקוחות אחרים. אם נכשלת בכך, מהר מאד תמצא את עצמך עם חבורה של סופרמנים בתחום מסוים שיושבים על הספסל ומחכים לפעילויות שכבר לא יגיעו. ובעיתות משבר – על אחת כמה וכמה – יש להישאר פתוחים וגמישים ולזנק מאזור הנוחות לאזור אחרים.
6. If you build it, they will come.. or will they? – גם קבוצות עילית כמו MCS צריכות לדעת לשווק ולמכור את עצמן. צניעות היא תכונה מצוינת אבל היא לא תקדם אותך בעסקים. הצדק לא צריך רק להיעשות, הוא חייב גם להיראות. ומלאכתם של צדיקים, היא לא תמיד נעשית בידי אחרים (להמשיך עם הקלישאות? :-). הרעיון, בסופו של דבר ברור – צריך למצוא את הזמן להשקיע גם בשיווק, מיתוג ומיצוב, הן פנימית בחברה והן חיצונית בשוק. זה לא חייב להיות קמפיין מתוחכם ומהוקצע. גם בלוג או כנס פה ושם יעשו יפה מאד את העבודה.
7. ארכיטקטורה וטכנולוגיה זה לא הכל – חלק גדול ממה שאנחנו עושים סובב סביב התחום המקצועי. וזה חשוב, זה קריטי, בשביל זה אנחנו כאן. אבל זה לא הכל... הערך האמיתי שלנו בא לידי ביטוי כאשר אנחנו משלבים בין התחום המקצועי לידע והכרות מעמיקה עם ורטיקלים מסוימים, עם הביזנס של הלקוח. כשאנחנו מסוגלים להוביל תהליך של שינוי בתוך הארגון איתו אנחנו עובדים. בשנה וחצי האחרונות עבדנו הרבה על שיפור היכולות שלנו בתחום ההשפעה ללא סמכות, עבודה עם הנהלה בכירה, ערנות למתרחש בסביבת הלקוח ואיזון בין פוקוס על המשימה לבין הרחבת מוטת ההשפעה.
8. ורסטיליות היא המפתח להצלחה כיועץ – במיוחד בתקופות קשות, היכולת לטפל במספר דיסציפלינות שונות מאפשרת ליועץ להצליח יותר ולהישאר חיוני ללקוחותיו. זה כמובן עקרון פשוט וברור. מה שגיליתי כשהתחלנו להשקיע בורסטיליות של היועצים זה שגם ברמה המקצועית מדובר במכפיל כוח. יועץ שמכיר מצוין .NET וגם Dynamics CRM (או לצורך העניין, xRM) יידע לשלב בין העולמות ולספק תוצר איכותי, יצירתי ובסופו של דבר תואם יותר לדרישות הלקוח. יועץ שמכיר בתחום התשתיות גם Exchange וגם MOSS יוכל לספק פתרונות מיוחדים של שילוב בין המוצרים האלו או מיגרציה של פונקציות מסוימות מאחד לשני.
9. שעות זה נחמד ונוח אבל העתיד הוא ב- Fixed – כשמדברים על יועצים, האסוציאציה הראשונית היא בדרך כלל לאחת הקריקטורות של דילברט אשר "מהללות" את עבודת היועץ בתור מישהו שכשאומרים לו שהמחיר שלו לשעה מאד מאד גבוה ושואלים אותו איך הוא מתכוון לבצע את העבודה, תשובתו היא "מאד מאד לאט...". כשעובדים לפי שעות, המדד העיקרי מבוסס של תשומות. אנחנו מאמינים בעבודה לפי תפוקות. שינינו מדיניות ברמת כל MCS – כל פעילות שניתן לבצע ב- Fixed (הרוב המוחץ), כך נעשה אותה. אז כן, יש פה קצת סיכון ולפעמים אנחנו מפסידים אבל בסופו של דבר ניתן למדוד באופן מוחשי את התוצרים שלנו, תיאום הציפיות מול הלקוח הוא built-in מה שמייצר שביעות רצון גבוהה יותר ובסופו של יום, גם לנו יש תחושה שלקחנו אחריות על משהו ונתנו ערך אמיתי.
10. כשיש הרבה אנשים חכמים מסביבך, יהיה טיפשי מצדך לא להשתמש בזה – זה הדבר האחרון שאני מציין ברשימה הזו למרות שהיה אחד הראשונים שלמדתי. אם התמזל מזלך ואתה מוקף במקום עבודתך באוסף של אנשים מוכשרים באופן קיצוני, חובה עליך ללמוד להשתמש בכך כמכפיל כוח. מה שאני בעצם מנסה להגיד כאן, זה שכל התהליכים, השינויים והדרכים בהן הצלחנו להמשיך לצמוח גם תוך כדי משבר – כל אלו קרו כי השכלנו לשים את האגו בצד, לפתוח את הראש, להקשיב אחד לשני ולנצל את ניסיוננו המצטבר בכל תחום ותחום. חלק קטן מהדברים שמצוינים בפוסט הזה היו ביוזמתי. חלק נוסף היו בהובלתי, הרוב המוחץ הגיעו מהיועצים, מהקולגות, המנהלים הבכירים וגורמים אחרים בחברה. וזו אחת הסיבות המשמעותיות ביותר לכך שאני קם בבוקר ונוסע לעבודה עם חיוך – כי כיף לי לעבוד עם אנשים כ"כ טובים ותמיד יש לי ממי ללמוד...

לאחרונה היה לי העונג להעביר סדנת ארכיטקטורת תוכנה בת 4 ימים לקבוצה של כ- 10 מנהלים, ארכיטקטים, ראשי צוותים ומפתחים מובילים של גוף פיתוח תוכנה של ארגון מוביל בארץ.

תכולת הסדנא הותאמה במיוחד לצרכי הלקוח, על מנת לספק מענה למאפיינים הספציפיים ול – roadmap העסקי והטכנולוגי שלו, אך בבסיסה היא נותרה נאמנה למוטיב המרכזי שהגדרנו בעת הפקתה והכנתה: הקניית ידע ומיומנות בעיצוב ובניתוח ארכיטקטורת תוכנה

התחלתי בכך שאמרתי ש"היה לי העונג" להעביר את הסדנא. ואני מעוניין להבהיר שאני אומר זאת בעיקר בזכות המשתתפים בסדנא:
מנהלי ומובילי קבוצת הפיתוח אשר השתתפו בסדנא היו מאוד אקטיביים, הפגינו ידע, ניסיון וסקרנות אינטלקטואלית. הם שאלו שאלות מצוינות, ולא לקחו שום אמירה כמובנת מאליה אלא דרשו טיעונים, שיקולים, והוכחות! להעביר סדנא בפני קהל משתתפים ברמה גבוהה שכזו זו חוויה מאתגרת, מרתקת ומספקת מאין כמוה.

כמו כן, לגבי הפידבק המצוין שקיבלנו, והמומנטום החיובי שנוצר אצל הלקוח בעקבות הסדנא, הרשו לי לצטט את דברי הלקוח עצמו:

"הצלחת הסדנא ניכרת בזכות ההכנה היסודית, הניסיון הרב מהשטח, וההעברה המקצועית והמעניינת של החומר. עלו המון רעיונות לשיפור תהליכי הפיתוח בארגון, ונוצרה שפה משותפת בין הארכיטקט לבין מובילי התוכנה בארגון"

כאמור, הסדנא ארכה 4 ימים, וכללה את הנושאים הבאים:

Day 1 - Fundamentals 0. Workshop topics and planning 1. Fundamentals of Application Architecture 2. Waterfall vs. Agile-Scrum 3. Designing your Architecture   Day 2 - Architecture Types and Styles 4. Architecture Types 5. Architecture Styles   Day 3 - Architecture in Practice (part 1) 6. Deployment Patterns 7. Quality Attributes 8. The Architect's role   Day 4 - Architecture in Practice (part 2) 9. Introduction to Architecture documentation 10. Architecture Analysis 11. Product-Lines Architecture

     השקעת שנם בלפתח את הרכיבים שלך ב-VB6 ועכשיו אתה מתלבט מה לעשות איתם. יש מצב?

בזמן שאתה מלבט אתה חייב להמשיך לפתח יכולות חדשות וגם להשתמש בקיימות. יש מצב?

אחד ההתלבטויות זה איך לחסוף  את הפונקציונאליות הקיימת המפותח ב-VB6 כשירותי WCF. יש מצב?

תסריט מס’ 1 – חשיפת VB6 כשירות WCF

הדרך הכי פשוטה לטעמי היא לפתח את שירות ה-WCF ב-Net Fx, לעשות Reference לרכיב ה-COM שלי וגמרנו. כאשר עושים Reference ל-COM אז VS יוצר שכבת אינטגרציה בין COM ל-Net Fx הנקרא Runtime Callable Wrapper או RCW שדרכו רכיב ה-COM מופעל ע”י רכיב Net Fx.

אני מעדיף ליצור את שכבת ה-RCW באופן ידני בגלל שזה נותן יכולות שליטה רחבות יותר – כמו חתימה עם SNK וגם בגלל שזה כיף יותר – LOL.

הנה השלבים:

1. צור רכיב VB6 בעזרת Visual Basic 6.0 [אחחחח, נוסטלגיה :)]
2. צור RCW בעזרת TLBIMP תוך כדי חתימה עם SNK
   c:\>tlbimp C:\VB6ProjectLibrary.dll" /keyfile:"C:\VB6WrapperKey.snk" /out:"C:\\NetWrapper.VB6ProjectLibrary.dll
3. מתוך פרויקט של Net Fx צור Reference ל-Wrapper שיצרת [NetWrapper.VB6ProjectLibrary.dll]
4. תפעיל את הרכיב בתוך try, תפוס Exceptions ב-catch והכי חשוב [!!!] זה מה תכתוב ב-finally:

   // Make sure that the underlying COM object is immediately freed
   while (System.Runtime.InteropServices.Marshal.ReleaseComObject(vb6Class) != 0) ;
   //FOR NET FX 2.0 and UP
   //System.Runtime.InteropServices.Marshal.FinalReleaseComObject(vb6Class) ;

תסריט מס’ 2 – צריכת WCF ע”י VB6

הדרך שאני חושב הכי כיפית היא לצרוך WCF ע”י רכיב .Net Fx ואת רכיב Net Fx לחשוף לצריכה ל-COM. הנה השלבים לחשיפת רכיב Net Fx לצריכה ל-COM:

1. צור Interface עם attributes שיאפשרו צריכה בעולם ה-COM:
   [Guid("E0281197-1174-4d48-92EA-19FFC3B4EF63")]
   [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
   public interface _COMCallableClass
   
   
2. צור Type שיורש מה-Interface עם עוד כמה attributes – אתה בטח מזהה מה יהיה השימוש של ה-Attributes
   [Guid("2CA46DE2-0502-4ae9-9763-D57EFA3E9457")]
   [ClassInterface(ClassInterfaceType.None)]
   [ProgId("COMCallableNetComponent.COMCallableClass")]
   public class COMCallableClass : _COMCallableClass
   
3. תסמן את הרכיב כ-COM Visible
   
4. רשום את הרכיב לצורך צריכה בעולם ה-COM
   C:\>regasm /codebase "C:\COMCallableNetComponent.dll" /tlb:"C:\ COMCallableNetComponent.tlb"
5. אופציונאלי – אתה יכול לרשום אותו ב-GAC בעזרת gacutil
6. בסביבת VB 6 תוסיף reference לרכיב שלך:
   
7. תפעיל בתוך הקוד של VB6 שלך:
   

איך אתה משמר את רכיבים ה-VB 6 שלך? איך אתה מתכנן לבצע מיגרציה מ-VB 6?

שירותי MCS רלוונטיים

• שירות ניתוח פערי ארכיטקטורה (PDF)
• שירות ניתוח פערים ושיפור ביצועים (PDF)
• שירות תכנון וניתוח בדיקות ביצועים (PDF)
• סדנת פיתוח מערכות מונחה ביצועים (PDF)

חומר רלוונטי

 

שמי אליק לוין ואני מתרכז ב- Architecture, Security, and Performance באפליקציות Net.

בזמני הפנוי אני מפתח את עצמי בתחומים רבים אחרים.

 

     הערה: אני שמח לארח שוב את ארנון רותם-גל-עוז [RGO] אצלנו בבלוג. ארנון ממשיך את הטרילוגיה ומשתף אותנו בהרפתקאותיו בעולם של פיתוח זריז. ארנון הוא ארכיטקט ותיק ומנוסה מאוד. ניתן להשיג אותו דרך LinkedIn ואף לבקש שירותי יעוץ.

זהו חלק II בסדרה המדברת על ארכיטקטורה בעולם של פיתוח זריז. בחלק הקודם דיברנו על ההגדרה של ארכיטקטורה ועל כך שנראה שיש סתירה בין הצורך בעבודה מראש (up front) והפיתוח הזריז שלרוב לא רואה את כל הדרישות מראש. בחלק הזה ננסה לעמוד על עוד אספקט של הבעיה ולמה בעצם תכן יכול להתהוות (emergent design) אבל ארכיטקטורה (שבסופו של דבר היא גם סוג של תכן) צריכה בכל זאת להתפתח.

אם אתם לא חיים בבועה בטח שמעתם על TDD פיתוח מונחה בדיקות מי שיצא לו לעבוד בצורה כזו בפועל בוודאי שם לב להשפעה שיש לזה על התכן הסופי של הקוד שנוצר. בעצם מכך שאנו יוצאים מבדיקות שלאט לאט מגדירות מה התוצר הסופי, יחד עם refactoring שכל הזמן מעדן את התכן אנחנו מגיעים לתכן שהוא הרבה פעמים פשוט הרבה יותר ממה שהיה לו הינו מתחילים בתכן מראש. יש דוגמא די ידועה של בוב מרטין (הידוע כuncle bob) שמראה תהליך TDD מול תכן מראש לקוד לחישוב ניקוד משחק bowling. כדאי לראות את המצגת אבל בגדול מה שנראה במבט ראשון כמספר מחלקות (משחק שמכיל תורות (זוג זריקות), כאשר התור העשירי שונה) מתהווה לפונקציה אחת לא מורכבת במיוחד

בסופו של דבר שם יותר נכון לTDD הוא תכן מונחה בדיקות – הבדיקות הן בעצם לא המטרה אלא הכלי שאיתו אנחנו יכולים להבטיח שהתכן שלנו יבצע מה שצריך והתכן מתהווה מהפונקציונאליות הנדרשת (וגם מקבלים בדיקתיות גבוהה :) ). זה אפקט שמאד מתאים לפיתוח זריז ולכן אנחנו רואים שימוש בTDD (וטכניקות דומות) בפרויקטים כאלו בעיקר מזה שהעבודה היא בגראנולריות של סיפורים (ולא למשל Use cases) ומהאיטרציות הקצרות (1-4 שבועות או ללא איטרציות כמו בKanban). אגב, גם תיכנונים קצרי תווך (בשילוב עם refactoring) וללא TDD המתאימים לאורך האיטרציות יכולים להגיע לתכן מתהווה- בTDD זה פשוט מובנה.

אוקי אז אפשר (אם כי לא תמיד חייבים) לגרום לתכן להתהוות – למה זה לא נכון גם לארכיטקטורה התשובה היא שלמרות מה שאולי מנסים לומר תמיד הגודל דוקא כן משנה. תכן הוא ארוע לוקאלי, ארכיטקטורה, כאמור בחלק הקודם, היא גלובאלית ברמת הפתרון כולו ולכן גם משיקולי זמן וגם משיקולי היקף צריך גם לעלות ברמת האבסטקציה וגם להגדיר את המגרש שבו משחקים. דברים שקשה לדחות מצד אחד ובעלי השפעות מרחיקות לכת על הפתרון מצד שני. למשל החלטות כמו קנה או בנה משנות באופן מהותי את הפתרון כמו גם בחלטה על פתוח ב3 שכבות לעומת SOA או RDBMS לעמות פתרון NoSQLי וכו.

המסקנה, כמו בחלק הקודם, היא שאנחנו צריכים למצוא דרך לשמור על הגמישות ולתת לארכיטקטורה להתפתח יחד עם הפרויקט (יש יוצאי דופן אבל הם יחכו לחלק הבא) כלומר חייבים לקבוע ארכיטקטורה כבר בשלב ראשוני אבל בדרך כלל מסוכן מידי להשקיע בה יותר מידי בשלבי אי-ודאות גבוהים להקפיא אותה או לקבע אותה הרמה שלא תאפשר התפתחות הדרגתית לצרכים משתנים בהמשך.

אמנם התכוונתי לתת דוגמא או שתיים כבר בחלק הזה אבל היות והוא התארך זה ימתין לחלק הבא בסדרה.

שירותי MCS רלוונטיים

• שירות ניתוח פערי ארכיטקטורה (PDF)
• סדנאות של MCS
• שירותי ניהול מחזור חיים של אפליקציה – ALM
• System Upgrade Offering
• UI Design Process Offering

אז הנה ההסבר:

Visual studio לכל גירסותיו פותח טרנזקציות כ Serializable כברירת המחדל. אין לי מושג למה (ואשמח לשמוע), אבל ברור שאי אפשר לשנות ברירת מחדל זו בגרסאות חדשות בגלל תאימות אחורה.

הסיפור הקצר:

כאשר הערכים המספריים מתורגמים ל:

יותר מידע תקבלו בעזרת:

SELECT  session_id,transaction_isolation_level FROM  sys.dm_exec_sessions ES ON ES.session_id = TST.session_id

 טיפ נוסף לסיום, אם נתקלתם ב Deadlock, המידע המסופק על כך ב profiler כולל את ה isolation level!!