DCSIMG
February 2008 - Posts - Justin myJustin = new Justin( Expriences.Current );

February 2008 - Posts

[Tapuz .Net] WPF vs. Winforms

שאלה:

אין לי ידע רחב ב C# אך לעומת זאת יש ידע ב MFC ו C++.
אני עומד להתחיל לבנות אפליקציה לחבר בעל חברת השמה.
אני יכול לבנות לו את זה ב MFC או ב WINDOWS FORMS אבל קראתי הרבה על WPF ואני שוקל אם כבר, להתמקצע בזה למטרת בניית אפליקציות מהסוג הנ"ל. אין לי בעיה להעמיק את הידע ב C#(לא מעוניין ב VB).
ראיתי ש WPF מספק UI עשיר מאוד וזה נראה באמת הדור הבא של UI.
מה דעתכם ? האם מישהו כבר בנה אפליקצייה עם הטכנולוגיה הזאת ?
אשמח לשמוע התרשמויות מבעלי נסיון.

 

תשובה:

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

היתרונות הגדולים שלו: (לפי דעתי ובלי סדר ספציפי)

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

למשל נביט על יכולות ה-Resizing של WPF.
נגיד וציירנו כפתור שלוקח את כל השטח בתא שגדולה 100 (יחסי) על 100 (יחסי).

image

זה ה-XAML שנקבל:

<Window x:Class="WPFTesting.Window2"

   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   Title="Window2" Height="300" Width="300">

    <Grid>

        <Grid.RowDefinitions>

            <RowDefinition Height="100*" />

            <RowDefinition Height="162*" />

        </Grid.RowDefinitions>

        <Grid.ColumnDefinitions>

            <ColumnDefinition Width="100*" />

            <ColumnDefinition Width="178*" />

        </Grid.ColumnDefinitions>

        <Button Name="button1">Button</Button>

    </Grid>

</Window>

 

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

image  

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

image

או להקטין את החלון והכפתור עדיין יתפוס גודל יחסי.

image

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

בכלל WPF יודע לתת התייחסות מצויינת לגודל הסופי של אלמנט על המסך דרך פרדיגמת: Measure Twice, Cut Once. למעשה, WPF שואל את האלמנטים שלו "מה הגודל שאתם חושבים שתצטרכו?" ובנפרד מודיע לכל אלמנט "זה הגודל הסופי שקיבלתם לפי מערכת ה-Layout המאוד מתוחכמת שלי".

יש עוד המון אפשרויות Layout כאלו שיודעות להתאים את התוכן לגודל המסך הזמין, הרזולוציה וה-DPI של המסך.

 

2. מודל ה-Content. בכל מקום שהיינו רגילים ב-Winforms שמבקשים מאתנו String לתצוגה, עכשיו מבקשים מאתנו UIElement.
כלומר, אם פעם היה Button.Text ב-Winforms, אז ב-WPF יש לנו Button.Content.
ככה שלמעשה אפשר להכניס מחדש על אלמנט גרפי לתוך אלמנטים גרפיים אחרים. מה שב-Winforms ובטכנולוגיות אחרות מהדור שלו, בלתי אפשרי או דורש המון המון המון עבודה עם ציור ידני.

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

<Window x:Class="WPFTesting.Window2"

   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   Title="Window2" Height="300" Width="300">

    <Grid>

        <Button Name="button1" Margin="35,30,43,40">

            <Button.Content>

                <MediaElement Source="http://silverlight.net/quickstarts/silverlight10/thebutterflyandthebear.wmv" />

            </Button.Content>

        </Button>

    </Grid>

</Window>

שימו לב שיש בתוך Button.Content את אלמנט ה-MediaElement שמצביע לקובץ WMV באינטרנט. (אומנם עדיף במציאות לעבוד רק מול קבצים לוקאליים, אבל זה רק הדגמה ליכולות של WPF).

אם נריץ את האפליקציה נקבל את הכפתור הבא:

image

image

 

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

 

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

המעצב שהוא יושב בתוכנה היעודית שלו Expression Blend יכול לקשר כפתור ל-Command שהמתכנת חשף לו מראש ולבצע DataBinding בצורה גרפית על Net Classes.

בואו נציג תרחיש שבו אנחנו בונים מערכת CRUD בסיסית לפרות ובעזרתו נדגים גם את Commands וגם את Databinding ואת ההפרדה המצויינת שהם עוזרים להשיג בין תכנות לבין עיצוב מסך.

נתחיל מדוגמה על Commands.
המתכנת יצור Commands, המעצב ישתמש בהן, והמתכנת בכלל לא יודע מה הולך ב-GUI.

המתכנת בא ויצר פקודה חדשה.

    public partial class Window2 : Window

    {

        public static RoutedCommand InsertNewCowCommand =

            new RoutedCommand("InsertNewCowCommand", typeof(Window2));

 

        public Window2()

        {

            InitializeComponent();

        }

    }

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

    public partial class Window2 : Window

    {

        public static RoutedCommand InsertNewCowCommand =

            new RoutedCommand("InsertNewCowCommand", typeof(Window2));

 

        public Window2()

        {

            InitializeComponent();

 

            CommandManager.RegisterClassCommandBinding(this.GetType(),

                    new CommandBinding(InsertNewCowCommand, InsertNewCowCommandExcuted));

        }

 

        private void InsertNewCowCommandExcuted(object sender, ExecutedRoutedEventArgs e)

        {

            // Insert Cow Into Database, designer doesn't know this

            MessageBox.Show("Cow has been inserted to DB");

        }

    }

הגיע המצב שלנו, פתח את Expression Blend ואפילו צייר כפתור.

image

עכשיו המעצב מפרט איזה פקודה מעלה האירוע ברירת מחדל של הכפתור (שהוא Button.Click).

image

וכשנריץ את האפליקציה שלנו נוכל לראות שלחיצה כל הכפתור באמת עולה הפקודה שלנו.

image

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

 

 

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

המתכנת בא וכתב את המחלקה שלו.

namespace BL

{

    public class Cow

    {

        public Cow()

        {

        }

 

        public Cow(string Name)

        {

            this.Name = Name;

        }

 

        private string _name;

 

        public string Name

        {

            get { return _name; }

            set { _name = value; }

        }

    }

}

סה"כ אין פה הרבה - יש מחלקה עם מאפיין (גם באנגלית: Property) בשם Name שמחזיק את השם של הפרה שלנו ושני קונסטרקטורים.

המעצב יגיע ל-Expression Blend ויבחר שהוא רוצה לעשות DataBinding ל-Cow.Name ישר לתוך TextBox שהוא שם על הטופס.

אז דבר ראשון הוא יוסיף TextBox.

image

ילחץ על הכפתור הלבן הקטן מצד ימין למאפיין Text ויבחר DataBinding.

image

יוסיף Data Source חדש לטופס שמצביע על Cow.

image

 image

ויעשה Drag & Drop ל-Name ישר לתוך ה-TextBox.

image

יבחר שהוא רוצה לבצע DataBinding ל-Text.

image

image

ועכשיו כל מה שנותר זה לדאוג שהתכנת דואג לתת לטופס Data Source כלשהו.

    public partial class Window2 : Window

    {

        public Window2()

        {

              this.DataContext = new Cow("עדנה");

        }

    }

ומולנו נקבל את הטופס הבא:

image

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

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

 

מודל ה-DataBinding ומודל ה-Commands של WPF יוצר הפרדה מוחלטת בשתי הנקודות הכואבות של תכנות חלונאי עד כה ובאמת מאפשר למעצב לעבוד עצמאית מתוכניתן אחרי שהכינו לו את התשתית.

 

4. העובדה שעכשיו יש לנו אפשרות לתכנות "דמוי CSS" זה אחד מהפיצ'רים הבאמת חדשניים של WPF? 
ככה אפשר להכיל סגנון גרפי על כל האפליקציה בשניות.
(כמובן שיש גם אפשרות לירושה בין ה-Styleים אז זה בכלל יוצא מצויין)
מה-Styleים של WPF גם ניתן לקבוע תוכן ברירת מחדל וציור ברירת מחדל לחלוטין.

למשל, ה-Style ה-WPF הבא ידאג לפרמט סוג וגודל פונט לכפתורים כל האפליקציה. (כאשר הוא יושב בקובץ ה-App.xaml של האפליקציה)

        <Style TargetType="{x:Type Button}">

            <Setter Property="FontSize" Value="22"/>

            <Setter Property="FontFamily" Value="Arial"/>

        </Style>

בדוגמה ל-CSS יש לנו שלוש רמות של Style:
1. שמתאים לכל אלמנט גרפי מסוג מסויים ברחבי האפליקציה. זאת הדוגמה שראינו למעלה.
2. שמתאים לכל אלמנט גרפי מסוג מסויים בתוך חלון או Container כלשהו. (ככה אפשר לפרמט רק כפתורים בתוך Panel או Window מסויים)
3. שמתאים רק לאלמנט גרפי ספציפי או שביקש ספציפית שה-Style יפעל עליו.

 

בניגוד ל-CSS קיבלנו גם פיצ'ר מדהים של ירושה בין Styleים. 

למשל בדוגמה הבאה נירש את BaseStyle ונוסיף לו.

        <Style TargetType="{x:Type Button}" x:Key="BaseStyle">

            <Setter Property="FontSize" Value="22"/>

            <Setter Property="FontFamily" Value="Arial"/>

        </Style>

 

        <Style TargetType="{x:Type Button}" BasedOn="{StaticResource BaseStyle}">

            <Setter Property="FontWeight" Value="Bold" />

        </Style>

עכשיו כל הכפתורים באפליקציה מקבלים גם את BaseStyle וגם את היורש ממנו.

image

 

כמובן שכל העניין הזה עם ה-Styleים הוא אוטומטי 99% דרך Expression Blend ומעצב רק גורר דברים ממקום למקום וקובע מאפיינים כרגיל.

 

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

 

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

למשל, אם הייתי רוצה שב-Button Click הכפתור יעשה סיבוב של 360 מעלות תוך 2 שניות ויזוז ימינה, פשוט אי-אפשר לעשות את זה בצורה הגיונית ב-Winforms. זה ייקח לפחות שבוע עבודה ב-Winforms ויראה נורא.
אבל ב-WPF אנימציות הן פיצ'ר משמעותי ודרך Expression Blend ניתן לצייר אותן.

נממש את הדוגמה עם הכפתור שלנו שדיברנו עליה לפני שנייה.

נבחר להוסיף Trigger חדש לטופס שיעבוד על button Click.

image

image

 image

נבחר להוסיף Storyboard חדש באירוע הזה.

image

 

דרך ה-Designer הגרפי גררתי את הכפתור 100 פיסקלים ימינה וסובבתי אותו, והכל בסימן ה-2 שניות באנימציה.

image

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

ואם נריץ את האפליקציה נראה במהלך ה-2 שניות את האנימציה הבאה את האנימציה מאוד חלקה הבאה.

image

image 

image

image

image

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

 

סה"כ אלו היתרונות הגדולים של WPF לפי דעתי.

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

 

קישור: http://www.tapuz.co.il/tapuzforum/main/Viewmsg.asp?forum=831&msgid=112351636

ASP.Net חוויות של יועץ דוט נט עצמאי - אימוץ של ASP.Net

 

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

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

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

image

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

 

הפעם אני רוצה לדבר על סטטיסטיקות אימוץ ל-ASP.Net, או בעגה מקצועית יותר - ASP.Net Penetration Statistics.

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

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

image

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

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

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

בכל שאלת "למה בחרתם X?" התשובה הקבועה שהגיע ממני - "It's in the main Microsoft technology stack".
כלומר "כולם עובדים עם זה, זה הדרך המומלצת של מיקרוסופט - כי ככה הם החליטו".

image

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

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

image

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

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

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

image

שאנשי עסקים שומעים "מיקרוסופט" הם ישר יודעים שמדובר בטכנולוגיה סולידית ומקובלת שמדובר ב-Zero friction לשכנע אנשים לעבוד איתה.

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

החלק העוד יותר קטן של אנשי עסקים כבר הבינו באיזה מצב השוק נמצא ומבינים שקיימת תסמונת "עדר" והם רוצים להיות חלק ממנה.
אם 1,500 כבשים רצות ואתה כבשה, עדיף שתרוץ איתן.

image
(מתוך - וואלה!. עדיף לא להיות הכבשה הראשונה שקופצת...)

 

במהלך אותו דיון עלתה באופן קבוע השאלה - מה בפועל השיעורי אימוץ של ASP.Net?

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

image

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

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

image

באותו ערב התיישבתי ובדקתי בפועל מה ה-Penetration של ASP.Net לשוק הטכנולוגי.
בדקתי מספר מדדים: כמה דפים נכתבו בפועל באיזה טכנולוגיה, מה מידת העניין בטכנלוגיה וממתי הטכנולוגיה קיימת.

כמובן שרק גוגל יודעת את התשובות לשאלות האלו.

 

חיפוש על כמות הדפים עם הסיומת ASPX בגוגל העלתה 213,000,000 תוצאות.
ASPX - הסיומת הרשמית של ASP.Net.
http://www.google.com/search?hl=en&q=filetype%3Aaspx

image

חיפוש על כמות הדפים באינטרנט עם סיומת ה-PHP בגוגל העלתה 308,000,000 תוצאות.
PHP - הסיומת הרשמית של PHP.
http://www.google.com/search?hl=en&q=filetype%3Aphp

image

חיפוש על כמות הדפים באינטרנט עם סיומת ה-JSP בגוגל העלתה 35,000,000 תוצאות.
JSP מייצג Java Server Pages.
http://www.google.com/search?hl=en&q=filetype%3Ajsp 

image

חיפוש על כמות הדפים באינטרנט עם סיומת ה-CGI העלתה 11,500,000 תוצאות.
CGI מייצג את הטכנולוגיית CGI.
http://www.google.com/search?hl=en&q=filetype%3Acgi

image

חיפוש על כמות הדפים באינטרנט עם סיומת ה-ASP העלתה 194,000,000 תוצאות.
ASP מייצג את טכנולוגיית ה-ASP.
http://www.google.com/search?hl=en&q=filetype%3Aasp

image

 

נסכם את המספרים שכרגע ראינו.

image

אם נצמד רק לשחקנים שבאמת עדיין במשחק נראה את הדיאגרמה הבאה.

image

 

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

PHP - מדובר בטכנלוגיה משנת 1994.
ASP - מדובר בטכנולוגיה משנת 1996.
CGI - מדובר בטכנלוגיה משנת 1995. (לפי דעתי זה לא מדוייק, אבל לא מהותי כרגע)
JSP - חלק מטכנולוגיית Java Servlet משנת 1997.
ASP.Net - חלק מטכנולוגיות דוט נט משנת 2002.

 

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

image

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

image

 

נחזור לגוגל ונראה מה מידת ההתעניינות ואולי היא השתנתה עם השנים.

בשביל זה נשתמש ב-Google Trends שמאפשר לרמות מגמות בחיפוש מילות מפתח מסויימות.

 

נתחיל בחיפוש על מילת המפתח PHP.

image

למרות שב-Google trends אין מספרים ספציפיים, אפשר לראות שרק משנת 2004 ועד שנת 2007 פחתה ההתעניינות ב-PHP לחצי.

כלומר, כמות החיפושים על המילה PHP ירדה בחצי בשלוש שנים האחרונות.

תופעה דומה אפשר לראות עם ASP.

image

כמות החיפושים על המילה ASP פחתו לכדי רבע בשלוש שנים האחרונות.

 

לעומת זאת, בחיפוש על מילת המפתח #C (שהיא מילת החיפוש שאותה יחפשו מפתחי דוט נט באינטרנט)

image

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

מרבית הנטישה מ-ASP קלאסי היא כמובן לכיוון ASP.Net והיא צפויה להמשיך בשנים הקרובות.

 

את הנתונים שאתם רואים עכשיו, הראתי למשקיעים מחו"ל שהשתכנעו ש-ASP.Net היא אכן ברירה מובילה היום בשוק.

 

חוויות של יועץ דוט נט עצמאי - אאוט-סורסינג

 

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

בשום שלב במאמר לא ציינתי את המחויבות של מיקרוסופט לספק תאימות אחורנית (Backward Computability).
אחד מהשירותים הקרדניליים שמיקרוסופט מציעה זה Service Incident.
Service Incident אומר שלקוחות MSDN של מיקרוסופט יכולים לפנות למיקרוסופט וזאתי מחויבת לספק פתרון לבעיה טכנית שהם העלו. הפניה תלך אם צריך את כל הדרך לצוות המוצר ברדמונד ואף תוביל לכתיבת HotFix לבעיה שלהם. זה שירות קדוש ועומד בתשתית של המדיניות של מיקרסופט בתמיכת גרסאות קודמות. 
חשוב לציין שמיקרוסופט היום עדיין מספקת Support Services לכל גירסה של הדוט-נט פריימוורק.

image

Support Incidents are holy Microsoft cows

 

בואו נדבר קצת על - אוף שורינג בתעשיית התוכנה.

image

מה זה אאוטסורסינג? (גם באנגלית Outsourcing, ובעברית תקינה מיקור חוץ)

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

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

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

image

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

image

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

במהלך הפגישה הציג לי ה-CTO את מצב הפרוייקט.
אפשר לתמצת את סטטוס הפרוייקט כ-"הפרוייקט אבוד, לנטוש! לברוח!".

image

ישר אחריו התחיל הסמנכ"ל לדבר על כמה יפה בהודו, ואיך האוכל בסין, וכמה יקרים המלונות בסן-פרנסיסקו.
הייתי בטוח שהוא מנסה למכור לי Time Share לאיזה בית בחו"ל, אבל מסתבר שהוא דיבר על Out sourcing.

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

 image

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

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

image

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

image

בפגישה עם ה-CTO קיבלתי תמונה טכנית עגומה של המצב:
1. הקוד מהאאוט-סורסינג ההודי והסיני באיכות נמוכה להחריד.
2. אין שום קשר בין הלו"ז לבין מועדי האספקה של ההודים.
3. מלבד ה-CTO, אין ר"צ שעובד על הפרוייקט הזה עם ניסיון טכני ניהולי. כולם תכנתים בכירים שקודמו.
4. הצוות בארץ הוא צוות טכני ברמה טובה וגבוהה. היחס בין תכנתים בעלי ניסיון לתכנתים טריים דווקא יחסית גבוה.
5. המורל בצוות בארץ נמוך מאוד.

image 

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

לפני השיחה עם הר"צ ההודי והר"צ הסיני עשיתי שיעורי-בית.
ישבתי עם ה-CTO וכמה תכנתים ועברנו על הקוד.
זה באמת היה קוד שאף אחד בארץ לא היה מעיז לרשום. 
עשה רושם שהם השתמשו ב-Daily WTF כדי למצוא "טיפים וטריקים" לקוד מעניין.

image

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

 image

 

ה-CTO גם הראה לי לו"זים ותכנוני פיצ'רים של הצוותים בארץ ובחו"ל.
היה בבירור אפשר לראות איפה הצוות ההודי לא קשור מתייחס יותר מדי ללו"זים.

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

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

image

הר"צ הסיני היה יותר מאופס על עצמו מאשר הר"צ ההודי.
סה"כ מדובר בבחור צעיר מאוד שקודם במינוי שדה להיות אחראי על אנשים. כמו כן הוא עובד תחת מכבש לחצים מישראל ומה-HQ בסן-פרנסיסקו.
 

הסיכום שלי לנושא.

image

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

 

הגענו לפתרון ובואו נתאר אותו לפי בעיה.
(החץ האדום הוא הבעיה, החצים הירוקים הם הפתרון)

image

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

במשך אותם שבועיים הצוות ההודי והצוות הסיני הגיע לעבוד עם הצוותים הישראליים פה בארץ.
במהלך השבועיים האלו באופן רשמי הכשרתי את כל הצוותים לעבוד בטכנולוגיית WCF של דוט נט 3.0 (לצרכי תקשורת) ועם Linq To Sql של דוט נט 3.5 (לצרכי גישה למסדי נתונים).
במציאות, העבודה הייתה להרים את הרמה המקצועית של הצוותים מחו"ל תוך כדי להכיר להם סטנדרטיים בכתיבת קוד.
איך לא לכתוב את כל הקוד ב-Event Handlers בצורה פרוצדוראלית, איך לבנות מחלקות בתכנות Object-Oriented, איך לחלק אחריות בקוד.
מעבר לזה, גם דאגנו שהם ידעו איך באמת לעבוד כצוות וכבני-אדם.

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

מעבר לזה, דאגנו שכאשר הם יחזרו הביתה יהיה שם Team Foundation Server ומדיניות מאוד דרקונית לביצעו Check-In לקוד הסופי של הצוות.
שילבתי שם את ה-Code Analysis של Visual Studio Team Suite ביחד עם כל מיני מבחנים שונים. (בעיקר Cyclometic Complexity, אחוז שורות קוד מול שורות הערות וכל מיני בדיקות אמפיריות על קוד).

image

אני רוצה להרחיב על אחד מהמדיניות שישמתי בזמן שהצוות ההודי והסיני היו בארץ.
בשלבי ההכשרה ביצענו Pair programming ככה שעל מחשב אחד ישבו שני תוכניתנים.
הזוגות היו מורכבים מתוכניתן ישראלי אחד ותוכניתן הודי\סיני אחד.

image

שימו לב שמדובר במחשב אחד עם שני אנשים עליו.
כחלק ממתודולגיית הפיתוח ה-Agileית בשם eXtreme Programming יש את המנהג הזה של Pair Programming כצורה קבועה של Code Review ושיתוף פעולה קבוע שרושמים קוד.

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

image image

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

בעקבות ה-Pair Programming שדרשתי בתקופה ההכשרה עם העובדים מחו"ל, גם המשכנו לעשות Pair Programming בשאר ההכשרה בארץ. במהלך התקופה שהייתי שם ועד היום כ-70% מהכ"א בצוותי תוכנה בארץ (וייתכן שגם בחו"ל) עובדים היום ב-Pair Programming.

כמו כן, המנהלים של הצוותים מהודו והסין והר"צ הישראלים זכו באמת לקבל מבט מלמעלה בתקופה הזו ובאמת להיות מנהלים של אנשי תוכנה.
יצא להתמקד איתם על "OK, יש משימה שנתנו לזוג #1 וזוג #2, ועוד משימה לזוג #3, מה עכשיו?".

image

 

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

image

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

למשל, בעבר נתנו לצוות ההודי לבנות ב-1.1.2007 את "טיפול במכירת מכוניות" שהכרחי לצוותים הישראליים עד ה-1.2.2007 בשביל "טיפול בלקוחות חוזרים" ו-"טיפול ברכבים שנמכרו".
במצב החדש, הצוות ההודי קיבל "מערכת דו"חות". פיצ'ר שלא הכרחי לשום פיצ'ר אחריו והפרוייקט יתפקד כיחידה בלעדיו.

לפני שהגעתי זה היה המצב.

image

ובסדר החדש זה:

image

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

 

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

אתם חושבים שהחברה הזאת חסכה כסף עם אאוט-סורסינג?

image

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

 

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

הפרוייקט אגב - הצליח בסוף.
והפס האפור בשיער שלי רק תופס עוד נדל"ן.