קטגוריה: javascript

פונקציה מונדית

אחד הדברים שאני שומע מהרבה אנשים אשר מתעסקים בתכנות פונקציונאלי הוא שפונקציה מונדית (monad function) היא בערך התשובה לכל מה ש42 לא מצליח לכסות.

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

הנה קוד ג'אווה סקריפט (מבוסס jQuery) קצר שאסביר אותו עוד מעט:

$('#id').html('<p>success</p>').addClass('success')

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

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

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

function init() {
  var self = this;
  return {
     callMe : function() {
       return self;
     }
  };
}

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

הרעיון לשימוש בקוד יהיה בגישה הבאה:

init().callMe().someOtherMethod() ...

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

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

מזלגות נעוצים

בתקופה האחרונה, נעשו מספר פעולות fork לפרויקטים מוכרים, בהם node.js ודביאן.
בנוסף, פרויקט docker מקבל מתחרה, לאחר שחברת CoreOS הודיעה כי לא מקובל עליה הכיון של docker.

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

אתחיל בדביאן
יש המון טינה על systemd, ובעקבות כל הנושא, עם כל הזעם, הוחלט ליצור fork בשם devuan, אשר ימשיך לספק יכולות של sysv init במקום systemd ה"נורא".

החשיבה כאילו systemd גוזל משהו, בכך שהוא בא לסדר בלאגן ובעיות שיש במערכת הקיימת כיום, מקבלת תירוצים של "נוצרת תלות במערכת", והתשובה שלי היא: "כי עד עכשיו התלות ב sysv לא היתה קיימת ?"

המאבקים המפגרים האלו, האם להשתמש בsystemd או לא, פוגעים בלינוקס, ולא האם systemd טוב או לא.

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

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

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

Rocket
במידה ולא שמעתם על docker, אתם כנראה ישנים איפשהו, או שרחוקים מעולם ה IT. זה השם החם ביותר מאז שסייבר ומחשוב ענן נכנס לעולם, או אולי זה היה 42 ?

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

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

החברה של CoreOS, רוצים container ומשהו שזו כל ההתמחות שלו, אבל docker מתחיל להיות stack שלם של דברים, והם ממש לא אוהבים את זה, כי בסופו של דבר,זו סוג של תחרות, לא ?

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

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

knockout.js

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

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

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

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

אז החלטתי לפנות לכלים כדוגמת Backbone, Angular.js ו Ember.js. אבל גיליתי כי עבור הצרכים שלי הן מפלצות – ביחוד אנגולר ואמבר. הכלי שניסיתי היה ד"א אנגולר.

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

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

הכלי נקרא knockout.js. הכלי הזה בנוי בגישה של "תשאיר לי את ה data binding, השאר שלך לעשות מה שתרצה".

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

הגישה של konockout.js קיבלה את השם Model-View-ViewModel אשר מאוד מוכרת לי מעולם הדלפי, רק בצורה שונה.

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

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

זה נעשה בצורה די פשוטה בג'אווהסקריפט נקי:

function observable() {
   if (arguments.length > 0) {
      //write stuff
   } else {
      // read stuff
   }
}

למעשה arguments זה המקביל ל var_args של C או open array של פסקל, רק שהוא מכיל בתוכו אוביקטים כי זו שפת javascript.

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

הנה קוד מאוד פשוט ב knockout:

<p>First name: <input data-bind="value: firstName" /></p>
<p>Last name: <input data-bind="value: lastName" /></p>
function ViewModel() {
    this.firstName = ko.observable("Joe");
    this.lastName = ko.observable("Bloggs");
 
    this.fullName = ko.computed(function() {
        return this.firstName() + " " + this.lastName();
    }, this);
}
 
ko.applyBindings(new ViewModel());

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

זהו, זה כל מה שהיה צריך. אין צורך בשיריון של namespace, איזורים וכיוב' … בלי לבחור סוג של template וכיוב'.
במקום שבו משתמשים בשדות, אז נכנסים לתוך ה namespace של אותו אובייקט, ואז במידה ורוצים לצאת החוצה משתמשים ב ‎$parent ובמידה ורוצים להתחיל מההתחלה, משתמשים ב ‎$root כלומר בנקודה שבה קראנו ל applyBindings.
אם אתם רוצים את האובייקט עצמו שאנחנו משתמשים בשדה מסוים (למשל כאשר משתמשים במערך), משתמשים ב‎$data וישנם עוד סוגי משתנים. הנה הסבר פשוט בנושא.

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

node.js כן או לא ?

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

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

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

אבל יש לי עם זה בעיה, שגורמת לי לחשוב ולרעוד מפחד, כל פעם שאני מסתכל לכיון node.js.
גוגל החליטה לפני שנה לעשות fork לwebkit שהוא עצמו fork של khtml, וקראה לפרויקט שלה blink.
היא עשתה זאת, מבחירה מסחרית גרידא ("אנחנו בידלנו את עצמנו בצורת פרוססים וטרדים שלנו, ולכן עשינו fork").

אמנם node.js לא משתמש ב webkit או ב blink, אבל הוא יוצר לי בעיות קשות:

  1. האם v8 ישאר גם מחר ?
  2. האם יהיה fork ?
  3. האם הוא ימשיך להיתמך ?
  4. האם הכיון שלו כיום ישאר, או אולי ישוכתב/ישתנה לגמרי בגרסאות חדשות יותר ?

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

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

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

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

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

Bero's Ecma Script Engine

Bero's Ecma Script Engine או BESEN בקיצור הוא מנוע שממש EmcaScript גרסה 5 בשפת פסקל מונחת עצמים.
המנוע משוחרר ברישיון AGPLv3 (בעבר היה LGPL) עם חריגה המאפשרת לקשר אל תוך קובץ הריצה את המנוע.

EmcaScript הוא למעשה השם של Javascript רק ללא "זכויות יוצרים" על השם.

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

המימוש מכיל:

  • תמיכה מלאה בתקן EmcaScript גרסה 5
  • מימוש ByteCode מבוסס על ECMA262 עבור מנוע Regex
  • מימוש garbage collector וכן סימון של מקומות לביצוע ניקוי
  • תמיכה בUnicode בפורמטים  UTF8/UCS2/UTF16/UCS4/UTF32
  • תמיכה במצב תאימויות שונות לשפה
  • מהדר ByteCode מובנה
  • קריאה לשגרות (subrotine) מבוססות חוטים
  • תמיכה בהרצת הוראות חוטים לפי מעבדים (אינטל 32 ו64 ביט, amd64 עם  just in time compiler. בתכנון גם תמיכה בהוראות של ARMv7).
  • קיפול קבועים
  • אופטימיזציות בסיסיות על בסיס עצים
  • התעלמות מקוד אשר לא בשימוש (dead code elimination)
  • Type inference (גם exact וגם speculative)
  • תמיכה במטמון פולימורפי במקום, מבוסס על מבנה אובייקט ותכונות של מזה מפתוח
  • אופטימיזציות עבור פעולות מיפוי עם hash
  • עצים מאוזנים (למשל עבור מיון מידע on the fly המקושר למידע בhash maps )
  • הוספה טבעית של מחלקות פסקל (תכונות לפי RTTI)

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

לפרטים נוספים ולקוד מקור