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

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

• האם רמת הסיכון בסביבת אינטראנט היא אותה רמת הסיכון כמו בסביבת אינטרנט? סביר להניח שלא, אלא אם כן סביבת האינטראנט כוללת משתמשים קרימינאלים מדופלמים מרובים.
• האם ישנו כח אדם מתאים ומספיק כדי לנהל את חוקי ה-Firewall שמפרידים בין אפליקציה לבין בסיס הנתונים?

הנה דוגמה קטנה שיכולה להפוך החלטה לכאן או לכאן. הזדהות מומלצת ל-SQL Server היא Windows Integrated Authentication. כדי לבצע הזדהות כזו דרך Firewall נדרש לפתוח לא מעט פורטים, חלקם לא כל כך אהובים ע”י אנשי אבטחת מידע כמו 135. אם ההחלטה נופלת להציב FW ואנשי FW לא מוכנים לפתוח את הפורטים אז האפליקציה תצטרך להשתמש ב-SQL Authentication שהיא פחות מאובטחת עקב צורך ניהול פרטי הזדהות – שם משתמש וסיסמה.

מה השיקולים שלך להפרדה או אי הפרדה של בסיס הנתונים מאפליקציה בעזרת Firewall?

מה טכניקות נוספות שהיית ממליץ?

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

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

חומר רלוונטי

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

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

Although Microsoft introduced WPF allowing amazing looking UI to be developed.
WinForms will probably be a major player for a while. That assumption is my own.

One of the challenges UI developers face (especially with Forms) is supporting different types of monitors having different settings of resolution and DPI.
So, how can achieve a well designed UI that still looks good when the DPI Settings are changed?

Ok, you ask why would the DPI setting change?

1. One scenario is that you need to target two different setups, one with 96DPI and the second with 120DPI.
2. The user can manually change it if he\she chooses to. Although this is not recommended as Windows will usually detect the optimized DPI settings of the monitor.

By carefully planning the UI layout, you can minimize the effects of the different settings on your UI.

Here’s a short list of things to consider:

1. Carefully plan your Form design and controls layout.
2. Use Layouts - as of .Net 2.0, WinForms provide the TableLayoutPanel  and FlowLayoutPanel controls.
   These are very useful but come with a price. Especially the TableLayoutPanel.
3. Prefer using  FlowLayoutPanel over TableLayoutPanel when possible.
   It's more efficient and in many cases will do the job.
4. User Anchoring and Docking of controls. Sometimes, that all you'll need for your layout .
   See more at "How to: Anchor and Dock Child Controls in a FlowLayoutPanel Control".
5. Make sure you use the AutoScale property of the forms you build and choose the
   Font attribute. This will make sure that when the font size changes, the controls will
   be resized  accordingly.
6. Changing the DPI setting causes things to move a bit. Leave enough space on your layout
   so controls don't  overlap and text fields have enough space.
7. If you know in advance that you need to target multiple DPI setups, make sure your
   controls and layouts support theses DPI's. This can be easily done by adjusting
   The DPI on your development machine while designing the UI.

For more readings, check out these two links:
"Best Practices for the TableLayoutPanel Control"
"How to: Anchor and Dock Child Controls in a FlowLayoutPanel Control"

     הערה: אני שמח לארח ארכיטקט ותיק בוגר MCS, מורי ורבי, אשף קבבים וסטייקים ובין היתר סמנכ”ל פיתוח בחברת Mobideo – אייל רייסמן. אחד הדברים החשובים שלמדתי מאייל זה לדעת לקבל החלטות וליישם אותן. אייל משתף כאן אחת הדילמות שהתלבט לאחרונוה. הוא גם קיבל החלטה ויישם אותה. תהנה!

לאחרונה מצאתי את עצמי מתלבט בסיטואציה הבאה – יש אפליקציה די גדולה שעד היום רצה על מכשירים מבוססי Windows CE/ Windows mobile על מסכים קטנים (עד 5 אינץ'), צד הלקוח מבוסס Win app ( .Net CF ).

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

בעיקרון – על פניו נראה שפתרון WPF אמור לספק מענה הולם לסיטואציה בה גודל המסך אינו קבוע ומוגדר מראש באופן מובנה, ולעומתו – ב Winforms ניאלץ לקודד לוגיקת כיוונון של המסכים בכפוף למאפייני המסך (ב Runtime).

כמובן שיש עוד מס' אפשרויות, אך מסיבות שונות הן לא עלו ל Best and final ...

נשמע פשוט, לא? (אז זהו, שלא. אלא אם אתם בעולם שכולו טוב ואין לכם מגבלות זמן/כסף/סיכון...)

כאבים והתלבטויות

הכאבים הקשורים לבחירת הפתרון לצד הלקוח ה"חדש" הם:

1. ראש ובראשונה – סיכון טכנולוגי.
   1. האם לא מסוכן מידי לקחת מערכת שרצה ביצור אצל לקוחות ולפתח צד לקוח חדש?
   2. האם לא תהיה רגרסיה באיכות המוצר כתוצאה מהכנסת טכנולוגיה חדשה?
   3. האם לא יצוצו בשלב מאוחר מידי בעיות שה roll back הטבעי שלהן היה לחזור לטכנולוגיה הישנה אך הוא כרגע יהיה יקר יותר מאשר להישאר "תקוע" איתן ולבצע מעקפים מכוערים אבל שעובדים?
   4. (כמו שאומרים בשפת העם: "כשר אבל מסריח..." ) ?
2. איכות התוצר ללקוח:
   1. האם כתוצאה משדרוג צד הלקוח ל WPF המוצר "שווה" יותר בעיני הלקוח? (ובמילים אחרות – האם הלקוח יהיה מוכן לשלם יותר על מוצר זה מאשר על מוצר בטכנולוגיה ה"ישנה"?)
3. המימד האישי:
   1. מה נוח לספק המוצר?
   2. מה צוותי הפיתוח מכירים?
   3. במה הם טובים?
   4. או במילים אחרות – למה לי את הצרה הזו כשאני יכול בלי?...

דרכי פתרון האפשריים

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

1. בשלב הראשון:
   1. לבצע את שדרוג המוצר בטכנולוגיה הקיימת (Winforms ) לתמיכה בכל הנדרש.
   2. ההשלכה – time to market גבוה , תוצר איכותי (מבוסס על ידע קיים)
2. בשלב השני:
   1. הוגדרו רכיבים אשר להם הערך העסקי הגבוה ביותר עבור הלקוח ברגע שישודרגו ל WPF – ופיתוח שלהם תוך שילובם במסגרת המוצר הקיים (שילוב של Winforms ו WPF באותה אפליקציה).
   2. ההשלכה – העלאת ערך עסקי ללקוח בזמן מהיר על ידי הכנסת רכיבים בטכנולוגיית WPF שמאפשרים יכולות שלא היו קיימות באופן דומה ב Winforms ), ובנוסף – הקטנת הסיכון כיוון שהמימוש הוא ממוקד.

על פי התובנות והפידבקים של כל הגורמים המעורבים לאחר ביצוע סעיפים 1+2 לעיל – קבלתי החלטה על שדרוג גורף.

מה אתה היית עושה במקרה כזה?

קריאת המשך וחומר רלוונטי

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

• WindowsClient.Net
• Chapter 10: Presentation Layer Guidelines (לא חייבים לקרוא הכל...אפשר לדלג לקראת הסוף לפסקה: Technology Considerations)

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

בעיה אמיתית אצל לקוח – איך לתכנן את מערכת כך שתאפשר להגיב מהר לדרישות ושינויים?

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

הבעיות

1. אין הפרדה טובה בין הרכיבים השונים -  כל נגיעה בקוד גוררת תגובת שרשרת מה שמצריך מעבר לאורך ולרוחב המערכת לצורך
   עדכונים ותיקונים ולכן כל שינוי מחייב תהליך בדיקות מקיף.
2. יקר להעלות גרסה חדשה לסביבת הייצור - אווצ'!!! תהליך ארוך, מייגע ויקר.
3. תדמית שלילית לצוות הפרויקט  - חוסר שביעות רצון של לקוחות המערכת העסקיים.

אז מה עושים?

נשארים במצב הקיים -  לקבל את הכאב כסגנון חיים [מעניין אם משתמשי המערכת יקבלו את זה?]

עדכון הארכיטקטורה ועיצוב המערכת

1. הנדסת תוכנה - ע"י design  נכון, ניתן ליישם מודל בו קיימת הפרדה טובה בין שכבות ורכיבי המערכת כך ששינוי/עדכון לא גורר שינויים
   רוחביים - Coupling & Cohesion. שמרנו על סביבה פשוטה ללא תקורות נוספות כמו במקרה של הפרדת לשירותים
2. הפרדת שכבת הלוגיקה העסקית ע"י שכבת שירותים - מה הרווחנו?
   לא צריך לגעת בסביבת הייצור כולה אלא רק בשירות אותו רוצים לעדכן. ע"י שמירה על מס' כללים בסיסיים הקשורים לניהול
   גרסאות שירותים, אנו יכולים לצפות למעט מאוד נק' חיכוך שעלולות לגרור שינויים גורפים במערכת. נשמע טוב לא? אז זהו, שלא בטוח. מה עם תקורת ניהול השירותים, הוספת שרתים לחווה, ניהולם, ניהול תצורה, גרסאות מקבילות? וזה עוד לפני שהתחלנו לדבר על ביצועים. הוספנו תקשורת החוצה את גבולות ה- Process, מה עם latency? מה אבטחת מידע?
3. הפרדת החוקים העסקיים מן הקוד ע"י כלי BRE (Business Rule Engine) - כמובן שצריך לשקול את הפתרון ולוודא כדאיות ע"י בחינה של עלות מול תועלת.
   כאשר מדובר במעט חוקים או מעט שינויים לאורך זמן, כנראה שלא שווה להשקיע במוצר וניתן להסתפק בפתרון פשוט מבוסס פיתוח עצמי.

לסיכום

לפני שרצים לבצע שינויים מרחיקי לכת חייבים לבצע תהליך של בחינת מצב ע"פ התסריטים העיקריים שמניעים את התהליך.
לאחר מיפוי התסריטים והצרכים ניתן לבצע ניתוח חלופות (design, Service layer, Rules Engine וכו') אמיתי ורציני. רק כך נוכל לבחור בפתרון המיטבי ולהצדיק
את העלויות.

קישורים רלוונטיים

1. Coupling & Cohesion

2. Business Layer Scenarios Frame

3. Service Layer Scenarios Frame

4. WF Rules Engine

5. Business Rules Engine

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

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

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

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

אז בוא נסתכל על מרכיבי ההגדרה

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

מההגדרה הנ"ל ניתן להבין שכדי לבנות ארכיטקטורה כמו שצריך יש צורך בתכנון בתחילת העבודה (Up front design) מה שמן הסתם מתנגש עם עם גישות זריזות (כגון SCRUM שהוזכר כן בפוסט אורח הקודם) שבהן קיים שלב תכן מקדים מאד קצר (אם בכלל). אחד המושגים הידועים בהקשר של גישות זריזות הוא YAGNI או "לא תצטרך את זה" בעברית, כלומר אם אתה יושב ומתחיל לתכנן משהו לעומק אומרים לך מה פיתאום, מאיפה אתה בכלל יודע שיהיה בזה צורך, בוא ממש משהו פשוט שעובד למה שצריך עכשיו. זה לא נשמע כמו משהו שיכול לעבוד עם הצורך בתכנון ארכיטקטורה. או אולי כן?

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

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

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

הנה כמה בלוגים שחובה להרשם:

• מרק רוסינוביצ’. מרק עומד מאחורי כלי Sysinternals החינמיים המדהימים. הוא כותב בבלוג שלו חומר עומק לגבי Windows Internals. אני מת על הסדרה שלו – “The Case Of” בה הוא מתאר מקרה או תקלה ומסביר איך הוא פותר אותו בעזרת כלי Sysinternals שפיתח. אחד הפוסטים הכי אהובים עליי הוא Pushing the Limits of Windows: Virtual Memory.
• טס פרנדז. אם אתה רוצה לרדת באמת עמוק, אבל באמת באמת עמוק לקרביים של ASP.NET ולהבין איך מוצאים בעיות ומקור לבעיות אלה – טס היא הכתובת, אחת והיחידה, נקודה! היא אפילו בנתה סדרת לימוד ופרסמה הכול בבלוג שלה. אמרתי כבר שהיא מדהימה?
• וונלונג דונג. פוסטים מדהימים ומאוד מפורטים בנושא WCF, בין האהובים עליי:
• Scale WCF Application Better with Asynchronous Programming
• Crack Throttling: Debugging WCF TimeoutException for a Middle-Tier Application
• סטיב סאודרס. אין הרבה מה להרחיב, אני פשוט מעריץ את סטיב. שעומד מאחורי הדברים הנפלאים האלה:
• YSlow
• Rules for high performance web pages
• Page Speed
• Web Performance Best Practices

מה הבלוגים המלוכלכים שאתה קורא?

חומר רלוונטי

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

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

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

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

אז זה טוב, או לא?

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

אנשי המוצר והUI נהנו מהיכולת לקבל תוצר מהר מהפיתוח, ולתת משוב תוך כדי, ולא בסיום התהליך.

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

אז מי נהנה פחות, תשאלו?

הQA, כמובן.

מדוע הQA נהנים פחות מSCRUM

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

עוד בעיה אופיינית נובעת מעיקרון ה80-20: כיוון שSCRUM מתמקדת במה שכן אפשר להספיק במהלך כל ספרינט, לעתים השלמת ה20% האחרונים תיקח משמעותית יותר זמן מ80 האחוז שלפניהם.

אז איך אפשר להימנע מהבעיות האלו?

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

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

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

ולסיכום

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

יובל לשם

איש פיתוח.