About 4 coding style the software engineering spoke.

• If the variable is not type of bool the function return a "the value is not a bool type".
• If the variable is true the function return a "the value is OK flag".
• If the variable is false the function return a "the value is NOT OK flag".

What he say?  if i have a code that working now so why touch it?
Well the performance it's not a issue 

What he say?  let's do it is the right and of course only one return point 

private static string DeveloperWay(object value)

        {

            string res = "the value is not a bool type";

            if (value is bool)

            {

                if ((bool)value == true)

                {

                    res = "this is a OK Flag";

                }

                else

                {

                    res = "this is a Not OK Flag";

                }

            }

            return res;

        }

What he say? We need air-condition. If we ask for more type then my code will be ready. We need to and only dictionary of key value 

private static string GenericWay(object value)

        {

            if (value != null)

            {

                string flag = value.ToString().ToLower();

                if (flag == "true")

                {

                    return "this is a OK Flag";

                }

                else if (flag == "false")

                {

                    return "this is a Not OK Flag";

                }

                else

                {

                    return "the value is not a bool type";

                }

            }

            return "the value is not a bool type";

        }

What he say? First we need to by ready with helper class.
after that we happy that code will be readable for normal human.
Let's write that statement.
If the value is not a Boolean type return "string A" else convert value to Boolean type.
If it's true return "string B" else return "string C" 

public static class SmartObject

    {

        public static bool IsNot<T>(this object value)

        {

            return (!(value is T));

        }

        public static T CastTo<T>(this object value)

        {

            if (value is T)

            {

                return (T)value;

            }

            throw new InvalidCastException();

        }

}

 private static string CleanCodeWay(object value)

        {

            return value.IsNot<bool>() ? "the value is not a bool type" :

                   value.CastTo<bool>() ? "this is a OK Flag" :

                                          "this is a Not OK Flag";

        }

Happy holiday

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

אל תגידו אין לי זמן!!! קראו את הפוסט עד הסוף

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

סיפור אישי

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

To VB or not To VB .NET

יצא לי לפני מספר שנים להיות מפתח בפרויקט שעבר לא מעט ידיים, בין 5 ל 8.
כמובן שפרויקט היה כתוב לפי כל השכבות כולל שכבת WEB עשירה.
למען האמת כתבו אותו לא מעט מפתחים מוכשרים עד מוכשרים מאוד.
אבל הנקודה הכואבת הפרויקט מומש ב VB.NET. אני הוא איש של C++ או C# ו VB זה ממש לא אני :-9. כאשר שאלתי למה לא כותבים ב C# אמרו לי שהתחלנו לכתוב את הפרויקט הגענו מ VB6 ולכן VB.NET זה היה הכי טבעי לנו. אז כמובן בהתחלה אמרתי OK ננסה.
לאחר כ 3 שעות מ(ה/ע)נות החלטתי שדי זה לא יכול להיות, כל קטע קוד שהייתי צריך לכתוב כתבתי בתוכנית בצד ב C# ולאחר מכן בעזרת reflector ראיתי איך צריך לכתוב ב VB.
צעד זה עזר לי בערך לעוד 4 שעות, כלומר משכתי יום שלם.
לאחר מספר ימים כאלו החלטת שדי אני חייב לעשות משהו בנדון, אני חייב לציין שכל הפרויקטים באותו זמן נכתבו ב C# וכולם ידעו C#.
שוב פעם באמצעות reflector המרתי את כל השכבות למעט שכבת ה UI ל C# זה לקח לי ..................................... יומיים.

מאותו רגע היעילות שלי עלתה פלאים ואת המשימה שתוכננה ל שבועיים סיימתי ב שבוע (כולל ההמרה)

שיפור ביצועים או שיפור הפיתוח

אחד מהדברים שאני יודע לעשות ואוהב לעשות (ומקווה שעושה את זה טוב) זה לשפר ביצועים במקומות הקשים ביותר.
מקרה שקרה כך קרה, בפרויקט ענק שמבוסס WPF צוותי הפיתוח התלוננו על ביצועים גרועים במסכי תוצאות. כמו כל מערכת מידע מסכי תוצאות מגיעים אחרי מסכי שליפה. כל עצה שנתתי להם כיצד לנסות לשפר לקח למפתחים יום שלם להחזיר לי תשובה האם העצה עזרה או לא.
אתם בטח שואלים למה יום שלם? זה פשוט: קימופול אפליקציה --> הרצת האפליקציה --> העלאת צד שרת --> הבאת נתוני קונפיגורציה מהשרת --> הכנת נתוני שליפה --> ביצוע שליפה --> הצגת תוצאות במסך תוצאות, כמובן שבדרך השרת היה למטה, ה DB "נדפק" בגלל מישהו או כל סיבה מעקבת נוספת. לעצה שלי למה אתם לא בונים אפליקציה קטנה בצד קיבלתי את התשובה "אין לנו זמן זה כבר עובד בתוך האפליקציה שלנו".
לאחר זמן לא קצר וכמובן לאחר הרבה צעקות עד כדי רצון לוותר על WPF אמרתי לאחד המפתחים, תן לי יום אני רוצה לנסות לבדוק בעצמי.
בשעה הראשונה בניתי אפליקציה עם הXMAL של דף התוצאות. באותה שעה כבר לקחתי את הנתונים שהוכנו לתוך ה DataContext ובאמצעות DataContractSerializer הפכתי את ה DM ל XML.
מאותה נקודה לא הייתי צריך לא דף שליפה וכמובן שום צד שרת. כל בדיקה וניסיון שלי לקחו בדיוק 30 שניות ולא יום שלם. תוך פחות מיום שיפרתי את הביצועים ב 2.5 שניות ל 0.8 שניות וזאת רק ע"י ניסוי וטעייה.

נוסחאת הזמן

כיצד מודדים זמן פיתוח, בואו ננסה לפשט
X- זמן הניתוח והעיצוב
Y – זמן הקידוד
I – זמן האינטגרציה
T – זמן הבדיקות

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

TOTAL=X+Y+I+T

כמובן שבעולם שלנו תמיד הזמנים לוחצים וצריך לספק תוצר ללקוח בזמן המהיר ביותר TTM.
ברור שהלקוח תמיד צודק, הוא רוצה בזמן מהיר תוצר איכותי ושנותן לו את כל היכולות שהוא ביקש.
בואו נראה מה קורה בעולם האמיתי.
למשתנה X אף פעם אין זמן ושלא תבינו לא נכון צריך לתת ל X את הזמן הראוי לא אבל לא יותר מידי, לדוגמא ארכיטקטורה/עיצוב על למערכת הכי מורכבת לא צריך להיות יותר מחמישה ימים.
משתנה Y – כאשר תמחרו לנו את זמן Y ברור שתמחרו אותו ללא כל הדברים מסביב וכולם לחוצים שהמפתחים יסיימו כמה שיותר מהר. אז מה עושים...... כותבים קוד כדי שייתן מענה עסקי (אתם זוכרים יש לקוח בקצה) ואת כל השאר משאירים לסוף ומה זה כל השאר? טיפול בשגיאות, תיעוד , ביצועים, רישום ל LOG ועדכון העיצוב.
משתנה I – אחד מהנושאים הכואבים בכל פרויקט חומרה , תוכנה , ספורט וכדו' ככל שיש יותר שחקנים יותר קשה לבצע אינטגרציה.
משתנה T – שלא תתבלבלו בדיקות לא נועדו להוכיח שמה שפיתחנו תקין............ בדיקות נועדו לבדוק האם מה שפיתחנו "דפוק"

וכמובן שאתם כבר יכולים לראות מה קורה X<=>I<=>T<=>Y משפעים רבות אחד על השני.
במערכת בריאה אנו נראה התכנסות, במערכת פחות בריאה נראה התבדרות
כמובן בגלל ההתבדרות שהיא בחוג פתוח (כדור שלג) נשמע יותר ויותר את המשפט "אין לי זמן"

דרכים ליצר זמן

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

תהליך הנדסי

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

בקרה מסודרת וטווחים קצרים

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

איכות קוד

קוד לא איכותי משפיע ישירות על Y,I,T גם בטווח הקצר וגם בטווח הארוך. בתוך ניסיון אני יכול להגיד בצורה ברורה השקעה מינימאלית באיכות קוד מייצרת באופן ברור חסכון ב Y,I,T. ברור שניתן להגיע לזה במספר דרכים פשוטות כגון סקרי קוד, static code analysis , peer programming וכמובן "חילות פרט"

כלים אוטומטים

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

נא לא לדחות למחר מה שניתן לעשות עכשיו

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

9 המשפטים שאומרים "אין לי זמן" ומה הכוונה

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

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

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

"אין לי זמן" לבצע בדיקות זיכרון.
הכוונה--> מה זיכרון , הרי יש לאפליקציה 1G לפחות . הכי הרבה פעם בשעה שהלקוח יתחיל אותה מחדש

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

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

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

"אין לי זמן" זמן לתעד את הפיתוח.
הכוונה--> למה לתעד בכל מקרה אני לא אהיה פה במהדורה הבאה

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

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

אני בסוף החודש בכפר המכביה יתקיים כנס שווה לכל מפתח ומנהל פיתוח להיות בו!!!

Agile Practitioners 2012 אז היום הראשון יהייה יום סדנאות אבל לדעתי היום הבאמת שווה הוא היום השני, אפילו שחברי משכבר הימים שמארגן את היום לא מרצה בו (לפחות לפי הרשימה).

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

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

כמובן שאשמח לשמוע המלצות לאיזה הרצאות ללכת………

נתראה ונהנה :-9

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

אז למה בעצם יצא לי המשפט הזה? כמו על כל דבר בצבא התשובה מתחלקת ל 3

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

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

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

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

ושוב פעם אין לא שום אמירה רעה/טובה על אף אחת מהחברות שמוזכרות בפוסט.

ראשית התחיל ואומר שאני לא מכיר מערכת שאין לה DAL.

אז בעצם מה זה בשבילי <DAL> ?

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

במערכות מידע בפרט זו השכבה הכי חשובה! הרבה פעמים שיפור בא משפר עד 80% ביצועים.

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

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

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

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

אני חייב לציין של למעט “מלחמות תוכנה” / “מלחמות ארכיטקטים” נסבו סביב נושא ה DAL

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

פוסט זה הולך להיות פוסט מאוד off topic אבל מצד שני אני חושב שרבים ימצאו בו קווים דומים למה שהם מכירים. אני רוצה לתת טיפה את התבלינים שלי לתבשיל שנקרא קריירה.

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

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

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

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

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

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

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

אני רוצה לסכם בנימה הכי אישית בכל הפוסטים שכתבתי.
מירב תודה רבה על הדרך ושיתוף הפעולה וכמובן מזל טוב ליום ההולדת. לא סתם נולדת ב 10/10 את באמת בנאדם מדהים.

ונסיים בוידאו שמנסה לסכם את הכל :-9

אני נמצא בעולם ה WPF כבר יותר מ 4 שנים ולא פעם שמעתי אמירות ש WPF מת.

כנס BUILD האחרון האיץ את האמירות האלו לרמות מטורפות.

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

אז ראשית בספטמבר האחרון נשארתי בארץ ולא קיבלתי מתנה.

אבל כן הייתי ברעננה וכן קראתי לא מעט.

בשורה התחתונה WIN8 יספק אפשרות לפתח בצורה שאנחנו מכירים, אפליקציות שולחניות כולל אפליקציות LOB. והדבר הגדול הבא באמצעות WIN8 נוכל גם לפתח אפליקציות הממשק חדש Metro style apps .

בואו נראה מה זה אומר למפתחי ה WPF שבינינו.

• Desktop apps – מספק שיפורים ב WPF כחלק מ NET4.5
• Metro style apps – מספק XAML המבוסס WINRT
• כמו כן VS2011 עדין מבוסס WPF, אלה אם פספסתי משהו.
• כל אפליקציה שעובדת על WIN7 תעבוד גם על WIN8, שימו לב גם WPF.
• יש מעל 450 מיליון התקנות של WIN7 וכמספר הזה XP שכולם מריצים WPF.

מתחילת המסע שלי בעולם ה WPF היה קיים SL ותמיד בחזון היה XAML אחד משותף לכלל הטכנולוגיות ובאמת ב Metro style apps זה נקרא פשוט XAML.

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

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

מניסיון אישי ל WPF יש את כל הדברים האלו ואני בטוח שגם ל XAML שירוץ ב Metro style apps יהיה את כל הפרמטרים האלו וקצת יותר.

לסיכום אישי שלי, WPF לא מת :-9 מה שאנחנו רואים זו אבולוציה של טכנולוגיה מדהימה שמתבססת בכל מקום על XAML. XAML אחד הרצות שונות וכמובן שרת/ענן חכם אחד.

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

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

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

אתם לא תאמינו, אמבולנס - יש, מתנדבים להפעילו -יש.

מה אין מספיק?

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

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

1. לפרסם את הפרויקט - עיתונות, רדיו, טלויזיה, אינטרנט, העברה בדוא"ל, וכיו"ב.

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

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

להלן הקישור לאתר שלהם : אמבולנס המשאלות

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

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

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

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

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

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

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

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

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

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

כמו תמיד אשמח לקבל הערות/הארות אל תתביישו להגיב

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

קבלו סרטון קצר ששווה לראות על SOA (באדיבות Juval)

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

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

וכמובן מה זה לא SOA – SOA זה לא תעודת ביטוח להצלחת פרויקט. SOA זה לא אנטי ל OO (מה זה OO יבוא פוסט בהמשך) וכמובן SOA זה לא דת.

אני רוצה להרחיב, מבטיח שלא יותר מידי.

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

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

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

וכמובן SOA שלא יהיה קל להבין לא יהיה קל לממש וכנראה זה לא יתפוס.

ותמיד תיזכרו בסיפור על בגדי המלך החדשים.................. המלך הוא עירום :-9

כמו תמיד אשמח לקבל הערות/הארות, אל תתביישו להגיב

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

עולם התוכנה מכיל ערב רב של תחומים מושגים וקללות שונות...

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

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

אז לפני סיום להל"ן רשימת הנושאים (לא סופית יכול להיות שיהיו יותר או פחות)

• SOA
• Smart client
• OO
• DAL
• RIA
• ארכיטקטורה
• הנדסת תוכנה
• WPF
• סקרי קוד
• מקצוענות

כמו תמיד אשמח לקבל הערות/הארות

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

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

Architect Master Class – Day one

Architect Master Class – Day two

Architect Master Class – Day three

Architect Master Class – Day Four

Architect Master Class –Last Day

בפוסט זה אני רוצה לסכם את הקורס אך ורק בזווית הראיה שלי. זו הפרשנות שלי, אני בטוח שאחרים בטוח ישסכמו את הקורס הזה טיפה אם לא הרבה שונה :-9

על הסדנא

Architect Master Class זה לא סתם קורס!!! זה קורס שמיועד לארכיטקטים עם ניסיון ומנהלים של ארכיטקטים. הקורס מנסה ולדעתי מצליח להעביר מה זה המסר להיות ארכיטקט ולא בהכרח איך לעשות ארכיטקטורה מקצה לקצה. ובאמת מי ששואף על סמך הקורס הזה לדעת איך בונים מערכת אמתית שבנויה מ UI דרך שכבות לוגיות ולבסיס נתונים זה לא הקורס.

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

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

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

על המרצה

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

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

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

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

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

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

מה אני לוקח איתי

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

מה זה ארכיטקט

ארכיטקט ללא תהליך הנדסי טוב לא שווה הרבה

ללמוד טיפה יותר WCF, אולי זה הבסיס למחר

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

Starbility מילה קטנה שאומרת הרבה.

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

מה אני משאיר מאחור

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

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

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

אני ממש לא מסכים ש O.O.A.D פס מהעולם. עיצוב ותכנות מונחה עצמים זה הבסיס למערכות תוכנה מוצלחות. SOA זה עוד שלב כחלק מהתפתחות ה O.O.A.D וכאן יש רק שחור או לבן.

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

ולסיכום משהו אישי

בשבילי זו הייתה חוויה אישית ומעצבת ברמה המקצועית. הייתי שמח עם Juval חבריו ואני נמשיך להיות בקשר מקצועי. בתפקידי ביום יום אני לומד מ RSS ומהחיים "בשטח" שמחתי להיות בחברת אנשים במקצועי ולמשך 5 ימים להיות ארכיטקט בתנאי מעבדה :-9

ימים יגידו האם אני באמת ארכיטקט או סתם אחד שעושה רוח :-9

אשמח לשמוע מה תגובות

WCF כדרך חיים

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

• השאלה הנכונה שצריך לשאול היא לא מה לגבי ביצועים אלה מה לגבי יצרנות

• WCF לא תוכנן לרמת השימושיות ש Juval שואף

• רוב הדברים הטובים בעולם התוכנה נוצרו לא מהכוונה המקורית שלהם

• מה שאתה לא מודד אתה לא יכול לנהל

The Zen of architecture

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

• ניתן להכניס את הכול לטבלת החלטה

• אם המפתחים לא מבנים את התכנון הם בטוח יהרסו אותו

• שום פרויקט לא נכשל בגלל טוב לא מושלם, הוא מכשל בגלל צורת התהליך

• חשוב מאוד להשקיע זמן בתכנון כולל בניית שלד מהיר לטובת בדיקת תקינות התכנון

• תכנון טוב הוא תכנון טוב רק אם הוא עובר את כל התהליך עד ליצור מערכת עובדת ללא השלכות מיותרות

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

• מערכות שלא מעדכנות ארכיטקטורה – מתות. שינויים זה דבר טוב

• איך יודעים מהוא שקוד שפותח צריך להיות כלי עזר- שואלים האם ניתן להשתמש בו במכונת קפה

חשיבה קבוצתית

• לאחר 5 ימים מדהימים שבהם Juval על הרבה מאוד נושאים הוא פתח בנושא האחרון של הסמינר.

• בתור ארכיטקטים הבעיה/הסיכון שבהם ניתקל ויכולה להכשיל את הכל זה חשיבה קבוצתית

• כ 70 אחוז מכלל האנשים חושבים כמו כלל הקבוצה. חשיבה מחוץ לקבוצה זה דבר שקשה להשיג.

• צריך תמיד לנסות למצוא את ה 30 אחוז הנותרים

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

בכל מקרה הסיכום האישי שלי בפוסט הבא...

לפני שאמשיך בסקירת היום הרביעי אני רוצה להזכיר למי שלא זוכר ולפרסם למי שלא יודע ש Juval מעביר 3 שעות על Windows Azure Platform AppFabric Service Bus ביום חמישי הקרוב. למי שלא מכיר את Juval אני ממליץ בלב שלם לארכיטקט יש מה להגיד! ותשאלו את גדי.

WCF

• אסור לשכוח ככל שדוגמים רכיב כלשהוא גם כך משפעים עליו יותר

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

• אפליקציות הם לא אלסטיות! היא אפשר להניח שניתן להעמיס עליהם עד לאין סוף. בסוף הם מתרסקות

• המקום הבטוח בעולם זה הענן, המומחים הכי טובים עבדו על הפתרון

• AppFabric Service Bus זה המהפכה הבאה בעולם הטכנולוגיה . Juval בילה את מרבית 4 השנים האחרונות בנושא

• כל Class לא צריך להיות שרות, כל Class צריך להיות שרות Service Bus

• לא להתבלבל AppFabric Service Bus זה לא AppFabric

• Security – הדבר שהכי מפחיד את המפתחים

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

• גילוי נאות של Juval. אשתי לא יודעת שום דבר על WCF, בעצם היא יודעת שזה הדבר הכי טוב בעולם.

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