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

אחד הדברים שאני שומע מהרבה אנשים אשר מתעסקים בתכנות פונקציונאלי הוא שפונקציה מונדית (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() ...

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

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

פורסם בקטגוריה javascript, טכנולוגיה, פיתוח, קוד פתוח, תכנות | עם התגים , , , , , | השארת תגובה

אנשי DBA

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

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

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

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

למשל בכל מסדי הנתונים שאני מכיר, יש בעיה עם Foreign keys. הם נשמעים טוב, אבל מוסיפים סיבוכיות בכך שהם בעצם מתורגמים לעוד פעולת select. את בעיית הביצועים הזו גיליתי לבד, את הסיבה לכך, ובכן איש DBA הסביר לי. אבל הוא באמת מבין המון דברים. הפתרון לכך פשוט, אבל זה לא נושא הפוסט :)

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

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

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

פורסם בקטגוריה טכנולוגיה, יעוץ, מסדי נתונים, פיתוח, קוד פתוח, תכנות | עם התגים , , , , | 6 תגובות

האלמות

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

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

פורסם בקטגוריה כללי | השארת תגובה

סינטרה מודולרית

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

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

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

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

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

אנחנו משתמשים בRack בעצם, היות וכמעט וכל הframeworks עבור בניית מערכות web ברובי משתמשים בו, אנו זקוקים לקובץ קבוע בשם config.ru.

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

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

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

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

למערכת שיצרתי ישנם שני מצבים – מערכת לדיבוג REST, ומערכת "בדיקות" אשר עליה אפשר לבדוק שדברים עובדים, והיא בעיקר על תקן "echo" כלשהו.

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

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

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

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

במקרה הזה, הגדרתי כי במצב של ‎:development משתמשים ב Sinatra::Reloader, אשר מגיע עם Sinatra-Contrib – תת פרוייקט המספק הרבה כלי עזר לדברים שונים.
הסיבה לשימוש ב Reloader הוא לא לאתחל את השרת בכל שינוי שעושים למחלקה של סינטרה, כאשר Reloader מגלה כי התוכן של הקובץ השתנה, הוא גורם ל rack לטעון אותו שוב, וככה אנחנו לא זקוקים לטעינה מחודשת של השרת עצמו.

המערכת שכתבתי, משתמשת ב template בשם haml, למעשה פעם ראשונה אשר אני משתמש בה מרצון. תוכלו למצוא את ה layout.haml שהוא המסגרת הרגילה וכן כרגע קובץ בשם index.haml תחת ספריית view.
ועבור העיצוב, אני משתמש ב Foundation 5, אשר אני אוהב אותה יותר מאשר bootstrap.
עבור Javascript יש גם את jQuery וגם את knockout.js, כאשר אני נעזר גם ב lodash.js למספר דברים פשוטים, והיא מספקת בעצם גרסה שעברה אופטימיזציה ל underscore.

את הקבצים של Foundation, וכל ה Javascript ניתן למצוא תחת public.

דבר אחרון שנשאר לספר עליו הוא שאני משתמש במשהו אשר נקרא puma.
מה זה ?
puma הוא משהו שלוקח את rack וגורם לו להיות שרת לכל דבר ועניין, אשר ניתן לבצע עליו חיבור לשרתי HTTP שונים, כדוגמץ apache או nginx.
החיבור נעשה על ידי הגדרת proxy בשרתים.

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

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

פורסם בקטגוריה Ruby, ui, unix, אינטרנט, טיפים וטריקים, טכנולוגיה, לינוקס, פיתוח, קוד פתוח, רשתות, שרתים, תוכנה, תכנות, תקשורת | 2 תגובות

האקינג לראוטר, או איך להפוך ראוטר לקוד פתוח

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

מאז לא היו לי אתגרים באמת מעניינים בנושא ההאקינג של מכשירים, עד שרכשתי את WDR4300 של TP-Link והחלטתי שאני לא אוהב את הרעיון שאין לי שליטה על הראוטר שלי.

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

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

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

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

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

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

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

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

אני יכול לבצע אפילו התקנת freeswitch עליו, מגרסת הפיתוח (משום מה), שלא לדבר על אסטריסק, או yate.
התקנה של מרכזיה כדוגמת freeswitch למשל, מאפשרת אם מתבצעת נכון, להעביר את הכוח לסוג של DMZ, שמוגן מתקיפות למינהן, אבל כן מסוגל לבצע שיחות.
אך אין לי כוונה להתקין מרכזיה כלשהי על הראוטר.
אם זה לא מספיק, אני יכול גם להתקין את Kamailio מסדרת שלוש וסדרת ארבע, מה שאומר שאני גם יכול לקבל SIP Proxy שאני יכול לתכנת כפי שאני רוצה, אך גם כאן, זה לא יהיה מה שאעשה.

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

בכל מקרה, אני מאוד נהנה :)

פורסם בקטגוריה asterisk, freeswitch, kamailio, OpenMoko, Operating Systems, yate, חומרה, טכנולוגיה, טלפוניה, לינוקס, קוד פתוח, ראוטרים, רשתות, תוכנה | עם התגים , , , , , , , , , | 2 תגובות

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

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

פורסם בקטגוריה Debian, docker, it, javascript, systemd, אירגונים וחברות, לינוקס, פיתוח, קוד פתוח, שרתים, תוכנה, תכנות | עם התגים , , | השארת תגובה

Firebird 3.0

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

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

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

  • DSQL
  • ESQL
  • PSQL

DSQL – הם בעצם השאילתות שכותבים ומריצים בצורה דינאמית באמצעות API. המקדם D מייצג את המילה Dynamic.
ESQL – הם בעצם שאילתות עם preprocessor, כאלו שכותבים למשל דרך תוכנה שלנו. ההבדל בינה לבין DSQL היא שבשפה זו משתמשים בפקודה EXEC. הפירוש של המקדם E מייצג את המילה Embedded.
PSQL – השפה שבה כותבים stored procedure וטריגרים. המקדם של P מייצג את המילה Procedural.

בנוסף ישנה שפה בשם DDL – ‏Data Definition Language. זו השפה בה עושים פעולות כדוגמת create table או create database.

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

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

SQL – כלל השפות:

  • Merge Syntax
  • פונקציות window
  • תמיכה ב regex בביצוע SUBSTRING
  • נכנס סוג נתונים בשם Boolean
  • יכולת לשמור גרסאות עם RDB$RECORD_VERSION
  • cursor יציב

PSQL:

  • פונקציות SQL
  • פרוצדורות
  • טריגרים, פונקציות ופרוצדורות משפות חיצוניות
  • חבילות
  • חריגות עם פרמטרים
  • SQLSTAT במצב של WHEN
  • שימוש ב continue בתוך לולאות.
  • cursor יכול להחזיר התייחסות כמשתנה מסוג רשומה
  • cursor דו כיווני

DDL‏:

  • תמיכה במצב null של עמודה ו domain
  • היכולת לשנות קידוד ברירת המחדל של מסד הנתונים
  • הוספה של Identity Column – המקביל ל serial בPG ו Auto Increment של SQLITE ו MySQL
  • תחביר עבור RECREATE SEQUENCE/GENERATOR
  • טריגרים עבור DDL
  • תמיכה ב DATABASE LINGER

אבטחה:

  • תמיכה database encryption
  • תמיכה מורחבת יותר בהרשאות Object
  • הרשאות לעבודה עם DDL
  • הרשאות ברמת מסד הנתונים
  • תוספות לעבודה עם Roles

פיקוח:

  • הוספת יכולות נוספות לסטטיסטיקה אודות שאילתות ומסד הנתונים בכלל

אז מה זה כל הסעיפים האלו ? להמשיך לקרוא

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

יחידות בדיקה, כן, לא, אולי

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

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

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

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

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

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

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

יחידות בדיקה (מיד יצעקו הבודקים), לא נועדו לכך, ואני אומר להם כי הם טועים !

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

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

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

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

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

האם בדקת באמצעות ‎ /dev/full האם המערכת שלך יודעת להתמודד עם מצב בו אין מקום יותר לשמור מידע ?
רק השבוע סידרתי את MySQL שהרס טבלה כי מערכת הקבצים הגיעה ל 100% ולא היה מקום לרשום את הרשומה, אז הטבלה נהרסה.

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

יותר מזה, אתה בודק את הקוד שלך על 10,000 רשומות, הלקוח קצה שלך אבל משתמש ב10,500 רשומות, ואז יש איטיות (ב10,499 עדיין אין), איך לא ידעת להוסיף עוד רק 500 רשומות לבדיקה ? זה מה שמנהל מסוים יצעק עליך, לא ?

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

האם בכלל יש פתרון למקרי קצה כאלו ?

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

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

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

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

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

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

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

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

מוגש כחומר למחשבה.

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

אריקסון ו webrtc

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

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

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

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

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

החברה פתחה אתר בנושא, ושמה את הקוד שלה ב github, וגם הוא ברישיון פתוח – BSD.
הכלים שהיא משתמשת גם הם פתוחים, כדוגמת Gstreamer .
הם גם משתמשים במימוש של סיסקו – מימוש קוד פתוח עבור H.264, למעשה זה משהו שהם מספקים שגוגל בכלל לא.

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

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

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

כרגע יש קרב גדול על בחירת קודקים לוידאו, כאשר הקרב הוא בין H.264 לבין VP8 ובעתיד גם VP9.

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

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

פורסם בקטגוריה VoIP, אינטרנט, אירגונים וחברות, אתרי אינטרנט, טכנולוגיה, טלפוניה, כלכלה, קוד פתוח, תוכנה, תקנים, תקשורת | 2 תגובות

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 וישנם עוד סוגי משתנים. הנה הסבר פשוט בנושא.

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

פורסם בקטגוריה javascript, אינטרנט, אתרי אינטרנט, טכנולוגיה, פיתוח, קוד פתוח, תוכנה, תכנות, תקשורת | 3 תגובות