נניח שיש לכם Unit Testing וגם מותקן לכם Resharper ב Visual Studio.

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

ואז אתם מנסים להריץ את הטסטים האלה דרך הרישרפר, מצפים ל Pass ומקבלים Fail.. למה?

תמונה אחת שווה אלף מילים:

להסיר את הסימון

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

בקיצור, תסירו את הסימון ותאריכו ימים

Happy Testing!

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

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

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

אז בבקשה, עו"ד קלינגר, אמנם לא אמן שעונה לקריטריון המדויק, אבל אולי בכל זאת: מדי פעם האתר StackExchange, שהוא האתר הגלובלי שתחתיו רצים אתרים כמו stackoverflow, serverfault, superuser, מוציא את המפלצת שנקראת:

Stack Exchange Data Dump

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

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

הנה, עו"ד קלינגר, יש לך נקודת התחלה.

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

בכל מקרה, מה שרציתי לכתוב זה שביטורנט זה רק פרוטוקול.
כמו ש SMTP זה פרוטוקול לשליחת מיילים.
כמו ש POP3 זה פרוטוקול לקבלת מיילים.

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

אבל חבר'ה, ביטורנט זה רק פרוטוקול. עזבו אותו במנוחה

מדי פעם אנחנו יוזמים מפגש פורום.

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

ו"אנחנו" זה משתתפי הפורום, או לפחות ה"גרעין הקשה"

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

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

נמשיך בתודה למכללת סלע, שכאמור, נתנה את החסות.

וכמובן, תודה למרצים: עידו פלטו, שהרצה על Fiddler, וגדי מאיר, שהרצה על Production Debugging. שתי ההרצאות היו מעולות.

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

הנושא שדברתי עליו היה מעבר מקוד פרוצדורלי ל Object Oriented.
לשמחתי האנשים שרדו יפה ולא נרדמו

ההרצאות הוקלטו והן זמינות ברשת (שוב תודה למכללת סלע!), ההרצאה שלי לקחה 28 דקות.

תוכלו להוריד את דוגמאות הקוד ואת המצגת עצמה, שהמרתי גם ל slide-share:

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

בקיצור, Good Vibes, ואפילו בלי אלכוהול! נקווה שיהיו עוד מפגשים כאלה.

צ'ירס!

לחברת WinBuyer דרוש/ה מתכנת/ת Web

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

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

דרישות מקצועיות
לפחות שנתיים נסיון ב ASP.NET, עדיפות ל MVC
לפחות שנתיים נסיון וידע ב HTML, CSS, JavaScript
לפחות שנה נסיון בעבודה מול MS SQL Server
חובה נסיון בתכנון (design) לפני כתיבת קוד
יתרון משמעותי: נסיון ב Multi Threading
יתרונות אחרים: נסיון ב jQuery, הבנה אמיתית של OOP, רקע ב WCF ו/או HTTP, נסיון ב Big Data, נסיון ב SilverLight, השכלה אקדמית.

הגדרת התפקיד
מתכנתת בסביבת ASP.NET + C#, עם הבנה טובה ב Web, לעבודה בשני הצדדים: Client+Server.

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

מתאים לך? שלחי קורות חיים למייל jobs_rd2012a@winbuyer.com
נא לא לציין בקורות החיים: תאריך לידה, מצב משפחתי, שירות צבאי וכד'. אנו מעוניינים לקבל קורות חיים מקצועיים בלבד.

ניר (מתי תפתח כבר בלוג) ואני מפתחים Pet Project בשם Patriq ב CodePlex.

פטריק הוא סוג של Router אפליקטיבי במסגרת MSMQ.

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

כרגע הפרויקט בשלב ממש התחלתי, אבל בסך הכל – עובד!

http://patriq.codeplex.com

אני בודק מדי פעם מה קורה בפורום דוט נט ב MSDN, בגירסתו העברית.

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

אתם מרגישים שעוד רגע מגיע ה"אבל.."?

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

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

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

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

ועכשיו, אחרי שהקדמתי וכתבתי את ההלל והשבח לאלו שלוקחים חלק במשימה של יצירת קהילת משתמשים בעברית, הנה זה בא:

אבל…

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

נכנסתם? יפה.

הכל בסדר. באמת. ממשק משתמש סביר, יש שאלות, יש תשובות.

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

טוב, לא נורא, קורה.

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

מה זה שאלות יחסית שטחיות? נניח, משהו כמו: מה זה connection string? מתי משתמשים בזה? – זו שאלה שטחית.

מה מפריע לי בזה?

קודם כל, זו רק תיאוריה, אין לי שום הוכחה, אז מי אני שאגיד משהו?

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

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

ולסיום – חידה

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

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

כשהתחלתי להשתתף ב stackoverflow נתקלתי בשאלה הבאה (בתרגום שלי):

פרויקטים של קוד פתוח חוסכים לנו הרבה זמן וכסף. למי הייתם תורמים 100 דולר מבין הפרויקטים של הקוד הפתוח?

התשובה שלי היתה:

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

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

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

צ'ירס!

מכירים את enum?

-מכירים.

אז מתי כדאי להשתמש בו וליצור enum בקוד שלנו?

-הממממם… כשיש כמה קבועים מאותה "קבוצה".

ופיסת הקוד הזו:

public class Util
{
  public static void SaveAs(Image image, ImageFormat format, string path)
  {
    switch (format)
    {
      case ImageFormat.Bitmap:
        SaveAsBitmap(image, path);
        break;
      case ImageFormat.Jpeg:
        SaveAsJpeg(image, path);
        break;
      case ImageFormat.Png:
        SaveAsPng(image, path);
        break;
      default:
        throw new ApplicationException(
          string.Format("enum '{0}' changed", typeof (ImageFormat).FullName)
          );
    }
  }

  // implementations here...
}

נראית הגיונית?

-כן. נראה בסדר גמור.

טעות. הקוד הזה מפר את עקרון OCP, קיצור של Open/closed principle.

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

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

using System;
namespace System.Data
{
  public enum ConnectionState
  {
    Closed = 0,
    Open = 1,
    Connecting = 2,
    Executing = 4,
    Fetching = 8,
    Broken = 16
  }
}

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

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

למה זה קורה?

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

בקיצור, יצרנו enum סביב data, וזו הטעות.

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

איך בכל זאת כדאי לעצב ולכתוב קוד עם רעיון דומה?

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

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

using System.Drawing;

namespace Silicate.Lib
{
  public interface IImagePersister
  {
    void SaveAs(Image image, string path);
  }
}

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

using System.Drawing;

namespace Silicate.Lib
{
  public class PngPersister : IImagePersister
  {
    public void SaveAs(Image image, string path)
    {
      image.Save(path, System.Drawing.Imaging.ImageFormat.Png);
    }
  }
}

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

אוקיי, אבל איך הכל מתחבר ביחד?

הרעיון המרכזי הוא לוותר על ה switch, כי אז הוספה (או גריעה) של פורמט לשמירת תמונה תגרום לקימפול מחדש. במקום ערכים של enum נעבוד עם string, שיכול להחזיק ערכים בצורה גמישה יותר. האלטרנטיבה ל switch היא לטעון באופן דינמי את ה plugin הרלוונטי ולהשתמש בו. טעינה דינמית שכזו יכולה להתבצע ע"י Reflection, או ע"י IoC Container (ובקיצור IoCC). אני אראה בפוסט הזה את הדרך של IoCC. אם מישהו יבקש (נניח בהערות לפוסט) – אז אני אוסיף גם קוד שמדגים ע"י Reflection.

נסכם את המהלך בטבלה קטנה ואז נמשיך:

	לפני	אחרי
סוג המזהה	ערך מתוך enum	string
סוג הטעינה	סטטית ע"י switch + new	דינמית ע"י Reflection או IoCC
הרחבה גורמת ל…	שינויים בקוד + rebuild	שינויים בקונפיגורציה בלבד

נחבר את הכל עם Unity

ה IoCC שאדגים באמצעותו את השינויים בקוד הוא Unity. קודם כל – הקונפיגורציה:

<unity>
  <namespace name="Silicate.Lib" />
  <assembly name="Silicate.Lib" />
  <container>
    <register type="IImagePersister" mapTo="BitmapPersister" name="bitmap" />
    <register type="IImagePersister" mapTo="JpegPersister" name="jpeg" />
    <register type="IImagePersister" mapTo="PngPersister" name="png" />
  </container>
</unity>

שימו לב שיש יותר ממימוש אחד לממשק IImagePersister, ולכן יש גם התייחסות לשם (או מזהה) של המימוש.

מרגע שהכל מקונפג כמו שצריך, נוכל לוותר על ה switch ולכתוב את הקוד באופן הבא:

public class Util
{
  private static readonly UnityContainer Container = BuildContainer();

  private static UnityContainer BuildContainer()
  {
    var container = new UnityContainer();
    var section = (UnityConfigurationSection)
      ConfigurationManager.GetSection("unity");
    section.Configure(container);

    return container;
  }

  public static void SaveAs(Image image, string format, string path)
  {
    var persister = Container.Resolve<IImagePersister>(format.ToLowerInvariant());
    persister.SaveAs(image, path);
  }
}

בואו נעבור קצת על הקוד:

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

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

עניין נוסף – מי שמבצע את הטעינה (בפועל) של המחלקה הרלוונטית הוא ה Unity. העברנו אליו את האחריות לבצע את זה. [אנחנו, ראש קטן אנחנו, כמה שפחות אחריות - יותר טוב ]

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

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

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

ונעבור ליתרונות:

• המערכת שיש לנו ביד – פתוחה להרחבות, וללא צורך בשינוי כלשהו בקוד עצמו (וב rebuild שלו). כלומר, אנחנו עומדים בעקרון שנקרא OCP. אם יש לנו קבוצה של 10 פורמטים, ונרצה להוסיף את הפורמט ה 11 שנרצה לתמוך בו – אין שום בעיה.
• הקוד שיש לנו קריא יותר, ולכן התחזוקה שלו קלה יותר.
• במקרים אחרים (ואולי פחות בדוגמה הזו) – הקוד יותר טסטבילי, כלומר יותר מוכן לבדיקות.

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

ולשאלה המתבקשת…

השאלה המתבקשת שעולה עכשיו, והיא שאלת מיליון הדולר: מתי כדאי להעדיף את הצורה הראשונה (enum+switch) ומתי נעדיף את הצורה השניה?

התשובה המתבקשת, וזו בד"כ התשובה הטבעית לשאלות של מיליון דולר ומעלה:
תלוי.

תלוי כמה הפרויקט גדול.

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

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

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

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

תכנות נעים!

קבצי הקוד: גירסה ראשונה – עם enum וגירסה שניה – בצורה של plugins.

[התמונה מתוך אתר flickr, שם משתמש tj scenes, לינק ישיר לתמונה, תחת רשיון CC BY 2.0]

אני עובד בחברה שנקראת WinBuyer, ואנחנו מחפשים ראש צוות web.
ההודעה מנוסחת בלשון נקבה, בשביל הכיף.
התפקיד הוא של ניהול של שני מתכנתים, hands-on, כלומר צריך לכתוב קוד בחלק מהזמן.
ברמת הטכנולוגיה מדובר על פיתוח web, שכולל את כל ההיבטים:
client side – לדעת ולהבין JS ברמה טובה וכן jQuery (או כל פריימוורק אחר ב JS), כולל Ajax
לדעת ולהבין HTML+CSS
server side – לדעת ולהבין ASP.NET עם C#
לדעת ולהבין אחסון נתונים ב MSSQL (עם או בלי שכבת ORM, לא עקרוני)

נדרש נסיון של שנתיים לפחות בניהול צוות בתחום.

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

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

מי שרוצה פרטים נוספים – שתשלח לי מייל לכתובת jobs.winbuyer@yahoo.com ואני אשלח לה דרישות תפקיד מלאות במסמך Word. אבל תכלס התמצית של הכל כבר כאן.
אשמח לקבל קורות חיים במייל.

בהצלחה!

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

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

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

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

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

בהתחלה אלעד העביר סשן מעניין על הטכנולוגיות של ה client בעיקר בקונטקסט של web: איפה אנחנו עומדים כיום ולאן מועדות פנינו בהקשר של SilverLight, JavaScript, HTML(5) ועוד. מעבר לחנופה צפויה ושגרתית, באמת היה מעניין. תודה, אלעד!

אחרי שאלעד סיים אני העברתי סשן בנושא Introduction to Unit Testing with NUnit. מעבר למבוא ולדוגמאות שהן סוג של Jump Start למי שרוצה להיכנס לתחום של Unit Testing, ניסיתי להעביר את המסרים הבאים:

1. קוד שמכוסה ב Unit Testing הוא קוד שיחסית קל לשנות לו את המימוש. הבדיקות מוודאות שהפונקציונליות נשמרת למרות השינויים במימוש.
2. קוד שהוא לא טסטבילי, כלומר שלא ניתן לכתוב לו Unit Testing – הוא ברוב המקרים קוד שצריך לשפר אותו. כלומר, טסטביליות מובילה אותנו לקוד טוב יותר ו/או ל design טוב יותר.

הנה המצגת שליוותה את הסשן שלי:

אפשר גם להוריד את הקובץ של המצגת ואת הקוד לדוגמאות (שימו לב שצריך רפרנסים ל NUnit, וזה לא חלק מההורדה).

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