קטגוריה: טיפים וטריקים

מציאת רשומה לפי התחלה מדוייקת ב PostgreSQL

הנה בעיה מעניינת – כיצד אני מביא רשומה המתאימה ביותר להתחלה כלשהי, כאשר ההתחלה משתנה באורך/תווים שלה?

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

כאשר אני יודע כי 2 תווים ראשונים מחזיקים תמיד בקידומת הבעיה מאוד פשוטה – אני חותך 2 תווים ראשונים ומחפש עליהם קידומות בצורה חד חד ערכית, ואם מדובר ב unique index חיפוש מהיר ביותר שאולי יעשה sequence scan במקום חיפוש באינדקס ויהיה מהיר מאוד.

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

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

הדגמה של טבלת קידומות:

להמשיך לקרוא

hell אל dll (בGo) – חלק ראשון

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

יצרתי באמצעות שפת C++‎ (וקצת C) איזשהו DLL המבצע קיצורי קוד עבורי שבכל דרך אחרת הייתי צריך לממש הרבה COM בשפת Go – כאב ראש עם הרבה boilerplate code של Vtbl ‏(Virtual Function Table) ומימוש Interfaceים שלמים, כולל ירושות שלהם מinterface אחרים.

אני מאוד אוהב את שפת Go אבל יש לי גם ביקורת קשה כלפיה – הביקורת העיקרית שלי (לצורך הפוסט כי יש לי יותר מביקורת מאחת) – הוא שמצד אחד ניסו לספק לי קוד "גבוה" שלא מעניין אותו מערכת ההפעלה, כאשר מהצד השני, רואים שהוא נבנה עבור Unix/Linux וכאשר אנו נמצאים במערכת הפעלה שונה כדוגמת Windows מערכת ההפעלה מרגישה שם כ second class citizen.

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

void GetBuffer(type_t * in, const char **buffer, const unsigned int * length);

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

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

הבעיה היא שבזמן טעינת DLL בזמן ריצה בצורה דינאמית עם LazyDLL (למשל) צריך להעביר פרמטרים וזה דורש מאיתנו להשתמש ב unsafe.Pointer בשילוב של טיפוס בשם uintptr.

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

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

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

...
outBuffer := make([]byte, 2 << 24)
var length uint
...
getBufferFunc.Call(
  uintptr(unsafe.Pointer(&MyType)),
  uintptr(unsafe.Pointer(&outBuffer)),
  uintptr(unsafe.Pointer(&length)),
)
...
saveToFile(outBuffer[:length])
...

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

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

הכנסתי לdll דגל אשר במידה ומדובר בגרסת פיתוח הוא גם כותב את buffer בעצמו לקובץ, וכך גם ידעתי להשוות בין הדברים (היות וקומפיילר של Go אינו יודע ליצור debug symbols בWindows) בצורה "טיפשה". וזאת לאחר ש delve לא הסכים לעבוד לי.

בקוד רגיל, ולא בהדגמה שכזו, חשוב גם לבדוק שגודל length אינו גדול יותר ‎ 2 << 24 לשם כך אפשר לבדוק את ה cap של ה slice ואין צורך לחשב מחדש.

בפוסט הבא בנושא אסביר כיצד להתמודד עם struct שלם בתוך DLL.

גילוי פורטים פתוחים בצורה נאיבית

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

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

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

  1. התעבורה עברה, אבל לא קיבלנו אישור – הפורט פתוח אבל מפולטר (מלווה ב Connection Refused).
  2. אין פורט פתוח – אולי מפולטר, ואם כן מקבל drop כאילו אין פורט פתוח.

פעולה זו של SYNchronize היא הדרך עבורינו לגלות האם TCP פתוח.

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

זו לא הדרך היחידה לעשות את זה, אבל זו הדרך הפשוטה ביותר.

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

רובי:

#!/usr/bin/env ruby
require 'socket'
def tcp_connect(address, port, timeout: 20)
# making sure we are talking with IP
connected = false
addr = Socket.getaddrinfo(address, nil)
sock_addr = Socket.pack_sockaddr_in(port, addr[0][3])
Socket.new(Socket.const_get(addr[0][0]), Socket::SOCK_STREAM, 0).tap do |socket|
begin
socket.connect_nonblock(sock_addr)
rescue IO::WaitWritable
if IO.select(nil, [socket], nil, timeout)
begin
# try again, might work
socket.connect_nonblock(sock_addr)
connected = :connected # no other exception, then should be yes
rescue Errno::EISCONN # we have a connection
connected = :connected
rescue Errno::ECONNREFUSED # we are filtered
connected = :filtered
rescue Errno::ETIMEDOUT # timeout
connected = :closed
rescue StandardError # something else :'(
connected = :error
end
else # unable to wait for an answer, but no exception was raised
connected = :error
end
rescue StandardError # ops, something went wrong
connected = false
ensure
socket.close
end
end
connected
end
puts tcp_connect('192.168.97.3', 8823)
view raw scan.rb hosted with ❤ by GitHub

גו:

package main
import (
"fmt"
"net"
"strings"
"time"
)
const (
errUnknown = "Unknown error"
connTimeout = "closed"
connFiltered = "filtered"
resolveError = "Resolve error"
lookupError = "Lookup error"
connSuccess = "open"
)
func tcpConnect(address string, port int, timeout time.Duration) (string, error) {
ipList, err := net.LookupHost(address)
if err != nil {
return lookupError, err
}
if len(ipList) == 0 {
return resolveError, fmt.Errorf("Unable to resolve %s", address)
}
connAddr := fmt.Sprintf("%s:%d", ipList[0], port)
conn, err := net.DialTimeout("tcp", connAddr, timeout)
if err != nil {
sErr := err.Error()
if strings.HasSuffix(sErr, "connection refused") {
return connFiltered, err
}
if strings.HasSuffix(sErr, "i/o timeout") {
return connTimeout, err
}
return errUnknown, err
}
defer conn.Close()
return connSuccess, nil
}
func main() {
addr := "google.com"
port := 443
status, err := tcpConnect(addr, port, time.Duration(3)*time.Second)
fmt.Printf("%s:%d - ", addr, port)
if status == errUnknown {
fmt.Println(err)
} else {
fmt.Println(status)
}
}
view raw scan.go hosted with ❤ by GitHub

מתודולוגיות – חשיבה מחודשת

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

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

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

כיצד זה התחיל?

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

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

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

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

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

שאלה אחת שווה אלפי שורות קוד

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

  • באיזה שלב הוא לא מוצג?
  • האם הוא היה מוצג בעבר?
  • האם הוא צריך להיות מוצג?
  • מתי הוא אמור להיות מוסתר?
  • האם יש שימוש בשדה הזה בכלל?

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

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

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

ספר לי סיפור

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

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

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

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

מתכנת ❤ קוד

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

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

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

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

משחק סכום אפס

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

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

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

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

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

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

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

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

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

סיכום

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

ואשמח לשמוע את דעתכם בנושא.

כיצד אני משווה טכנולוגיות

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

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

כיצד מתחילים?

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

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

נגיד הדגש הוא רינדור מידע סטטי שלא משתנה. או אולי זה משהו שיש לו observable, אשר מגלה שינוי במידע.
כל גישה כזו ממקדת אותך בדברים שונים.
למשל React יוצרת מצב סטטי תמידי, וכל שינוי מידע יוצר דינדור מחדש של כל הסביבה אשר מחזיקה במידע.
כמובן שיש מספר דרכים להתמודד שזה לא יקרה (למשל states).
לעומת זאת, יש את Vue.js שזו מחזיקה observable וכאשר מידע משתנה, רק מי שמשתמש במידע מרונדר מחדש על ידי שימוש ב shadow DOM, כאשר שאר המסך לא משתנה או מרונדר מחדש.

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

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

ניסויים

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

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

עד כמה המידע שיש עדכני ומסייע לי להתעדכן?

אם אחזור לדגומא של React מול Vue.js. אז התיעוד של React מאוד מתפזר בתהחלה, ומנסה להסביר concept, בעוד שהתיעוד של Vue מאוד ממוקד מטרה – מה לצפות כאשר מתחילים לעבוד.
שימו לב, הדבר הראשון ש React עושים זה להציג Hello World. אנחנו לא מבינים כלום עוד, וכבר יש סוג של Tutorial כתיעוד, בלי קשר ל Tutorial.

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

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

אב טיפוס

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

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

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

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

דגשים שגויים

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

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

אבל מה זה משנה אם יש 10,000 כוכבים או 100,000,000 כוכבים בgithub?

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

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

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

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

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

סיכום

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

הבנת תבניות זמן בשפת Go

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

כאשר מדובר בשפת Go (או Golang למחפשים), הגישה בנויה מעט שונה. במקום place holder רגיל שבו "m" מייצג חודש בעל תו בודד (כלומר אם החודש הוא "5", אז הוא יופיע כ"5", אך אם החודש הוא "10", הוא יופיע כ"10") או "mm" שהוא חודש דו ספרתי (כלומר אם החודש הוא "5", אז הוא יופיע כ "05", וכאשר מדובר בחודש שהמספר שלו הוא "10", הוא עדיין יופיע כ"10") אינה מתקיימת.

התבניות האלו מוחלפות בגישה אחרת, שאותי לפחות מאוד בלבלה במשך הרבה מאוד זמן. הגישה אומרת כי יש לנו offset holders. מה הכוונה? ובכן תאריך ושעה בGo נשמרים בברירת המחדל כמספר שלם בגודל 64 ביט (כלומר int64). בנוסף, ישנו מספר בגודל 32 ביט (int32) שמחזיק בנונו השניות לשנייה מסוימת., ובנוסף לזה, יש גם מערכת לשמור מיקום.
כל המשתנים האלו מאוגדים ברשומה בשם Time.

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

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

בשביל המבנה, יצרו בגו סוג של Fixed Date שהוא המייצג את הימדע הזה:

Mon Jan 2 15:04:05 MST 2006

המידע הזה הוא נקודה קבועה היודעת להיות מתורגמת ל Unix Epoch 1136239445.
להמשיך לקרוא

recursive tail

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

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

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

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

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

הגישה המוכרת ביותר לכך נקראת tail recursion. או רקורסיית זנב בעברית טכנית.

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

מה הכוונה? אשתמש בקוד רובי (שהוא לדעתי קריא מאוד) לשם כך.

רקורסיה בגישה ה"רגילה" תהיה כתובה כך:

def recursive(n)
  if n <= 1
    1
   else
     n * recursive(n - 1)
   end
end

recursive(4)
=> 24

רקורסיית זנב, תראה כך:

def tail_recursive(current, n, result)
  return result if current <= n

  new_result = result * current
  tail_recursive(current + 1, n, new_result)
end

tail_recursive(1, 4, 1)
=> 24

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

אבל לא הכל ורוד בזה. קשה יותר לדבג בעיות ברקורסיית זנב, היות ולמעשה אין לנו stack frames רבים, שיהיה ניתן להבין באיזה שלב יש בעיה. ובכך אין לנו stack trace שיסייע לנו בנושא.

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

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

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

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

שינוי פורמט לוג של Rack, והסתרת אזהרות ברובי

יש לי מערכת העובדת עם Sinatra, unicorn ו nginx ביחד.

הבעיה היא, ש nginx נמצא בראש, והוא מעביר את הבקשה ל unicorn, אני מקבל את כתובת ה ip בלוג של ה nginx ולא של הפונה המקורי, ורציתי לשנות את זה, שאראה את הכתובת של הפונה, ולא של nginx.

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

# ... 
# snips 
# ...

# Overriding the original constant
FORMAT = %{%s - %s [%s] "%s %s%s %s" %d %s %0.4f\n}

# ... 
# snips 
# ...

def log(env, status, header, began_at)
  now = Time.now
  length = extract_content_length(header)

  logger = @logger || env['rack.errors']
  logger.write FORMAT % [
    # adding IP
    env['HTTP_X_REAL_IP'] || env['HTTP_X_FORWARDED_FOR'] || 
    env["REMOTE_ADDR"] || "-",
    env["REMOTE_USER"] || "-",
    now.strftime("%d/%m/%Y %H:%M:%S"),
    env["REQUEST_METHOD"],
    env["PATH_INFO"],
    env["QUERY_STRING"].empty? ? "" : "?"+env["QUERY_STRING"],
    env["HTTP_VERSION"],
    status.to_s[0..3],
    length,
    now - began_at 
  ]
end

# ...
# snips 
# ...

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

proxy_set_header        X-Real-IP       $remote_addr;

במידה והוא אינו קיים, אני מנסה לבדוק האם HTTP_X_FORWARDED_FOR קיים, במידה ולא, אז אנסה את מזלי עם REMOTE_IP, ואם זה גם לא, אז אין IP.

במידה ותריצו את זה, תגלו אבל בעיה חדשה – הודעת אזהרה ש FORMAT כבר הוגדר:

warning: already initialized constant Rack::CommonLogger::FORMAT
/home/ik/.gem/ruby/2.0.0/gems/rack-1.5.2/lib/rack/commonlogger.rb:24: warning: previous definition of FORMAT was here

אז מצאתי להודעה הזו פתרון נחמד ופשוט:

module Kernel
  def suppress_warnings
    original_verbosity = $VERBOSE
    $VERBOSE = nil
    result = yield
    $VERBOSE = original_verbosity
    return result
  end
end

והשימוש בו יהיה בצורה הבאה:

module Rack
  class CommonLogger
    Kernel::suppress_warnings do
      # Overriding the original constant
      FORMAT = %{%s - %s [%s] "%s %s%s %s" %d %s %0.4f\n}
    end

    def initialize(app, logger=nil)
...

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

הקוד המלא נמצא כאן.

הפילוסופיה של הקוד

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

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

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

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

כל זה נעשה בשפה העברית.

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

ענב הזעם – API

ברובי, הדבר הכי מוכר ביקום הוא framework בשם Rails, אשר מאפשר ליצור אתרים דינאמיים בצד השרת.

ישנם עוד מספר סוגי framework עבור עולם ה web, בהם Sinatra, שאני משתמש המון, ולאחרונה התחלתי לשחק גם עם framework מאוד מעניין שנקרא grape.

Grape הוא framework אשר נועד לתת לנו כלי לפיתוח API. זה אומר שכל הפיטצ'רים שלו הם על טהרת REST ואין שום דבר הקשור להצגת templates למשל בצד המשתמש.

כלומר ניתן להציג xml, json או כל מבנה אחר של מידע, אבל זה לא נועד ליצור אתר, אלא להחזיר מידע, או לבצע פעולות API.

הנה הדגמה קלה כיצד תראה תוכנית שכזו: להמשיך לקרוא

טיפים על עבודה ב ssh

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

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

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

Host *
  ControlPath ~/.ssh/sockets/master-%l-%r@%h:%p
  ControlMaster auto
  GSSAPIAuthentication=no
  ServerAliveInterval 25
  Compression yes
  IdentityFile ~/.ssh/id_rsa

ה"חלק" הזה שיצרנו בעצם יוצר קבוצה של הגדרות עבור 100% מהחיבורים שלנו (אלא אם נדרוס אותן). אנחנו יודעים זאת, בזכות הglob של כוכבית.
אנחנו אומרים לו ליצור קובץ socket על שם החיבור המדויק שלנו, ושopenssl ינהל אותו לבד. מדובר למעשה ב unix socket, וזה מה שמאפשר את השיתוף.
אנחנו אומרים למערכת שלנו כל 25 שניות לשלוח סוג של ping בשביל להשאיר את החיבור פתוח (אחרת יש חיבורים שיסגרו בשרתים שונים אם אין תגובה אחת לזמן מסוים), אנחנו דוחסים את המידע העובר עם החיבור, ובסוף אומרים מה המפתח ברירת המחדל שלנו.

כל האופציות האלו, הן אופציות שניתן להגדיר גם בשורת הפקודה, וגם תחת ssh_config שנמצא ב etc, אך כאן אנחנו עוקפים את ההגדרות של הקובץ האחרון, ובנוסף אין צורך ליצור משהו בשורת הפקודה, ואפילו alias מיותר.
בשורת הפקודה אנחנו מגדירים את רובם עם הדגל של ‎-o, ואז מציינים את ההגדרה שרוצים.

הקובץ של config מאפשר לנו גם לבצע הגדרות מדוייקות לשרתים שונים. למשל: להמשיך לקרוא

אפצ'י מפסיק לפעמים להגיב לבקשות בצורה רנדומאלית

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

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

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

הפעלתי wireshark, וגיליתי כי three way handshake אינו מתבצע עד הסוף, ולמעשה ה ACK האחרון לא נשלח חזרה על ידי השרת (ה wireshark היה על השרת עצמו).
יש מספר נסיונות שליחה של לחיצת היד, ובסוף יש RST על הבקשה כי לא ניתן היה ליצור קשר, והבקשה התנתקה.

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

בנתיים דיברתי עם בוריס, והוא הצליח למצוא קישור מעניין שמדבר כי אפצ'י בברירת המחדל מגיע עם דגל של TCP_DEFER_ACCEPT. עד כמה שאני מבין, הדגל הזה אומר לשרת לא לחכות ל three way handshake, אלא במידה ונשלח מידע אחרי החיבור הראשוני, כשעוד אין ACK, אלא רק SYN-ACK, ניתן כבר לקבל את המידע, ולמעשה רק כשהוא יסתיים להישלח, ישלח גם ה ACK.

מסתבר שבאפצ'י 2 הדגל מאופשר בברירת המחדל (בניגוד לnginx ששם צריך להגיד לו את זה במפורש), ולכן צריך לכבות אותו.

בשביל לכבות את הדגל בחיבור, צריך לשים ב httpd.conf הראשי, את הקוד הבא:

 AcceptFilter http none

במידה ויש הגדרה אחרת בנושא, למשל עם data, יש לשכתב אותה לnone.
וזה מכבה למעשה את הדגל של TCP_DEFER_ACCEPT ועכשיו אפצ'י חייב לחכות ללחיצת היד כמו שצריך לפני שיוכל לנתח את מה שנשלח.

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

 

סליחה, יש לכם אולי זמן ללמוד טכנולוגיה חדשה ?

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

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

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

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

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

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

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

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

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

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

anti patterns של מתודולוגיות עבודה

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

הקדמה

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

הדגמות

להמשיך לקרוא

Sequel וPostgreSQL

לאחרונה אני מוצא את עצמי משתמש בתכונות מאוד מתקדמות של PostgreSQL, שחלקם נוספו רק ב9.2 (למשל range). העניין הוא שאני עובד עם רובי ו Sequel, ולרוב אנחנו שמים לב כי ORM אינם אוהבים דברים שהם לא סטנדרטיים.

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

ישנם שני דרכים לטעון תוספים:

  1. דרך גלובלית
  2. דרך שתופעל רק על החיבור שלנו

הדרך הגלובלית נראת כך:

Sequel.extension(:core_extensions, :pg_range, :pg_array)

הדרך של החיבור, נראת כך:

DB.extension(:pg_range, :pg_array)

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

DB[:readers].where(Sequel.pg_range(:comments_id).contains([10, 15, 1900])).sql
# SELECT * FROM "readers" WHERE ("comments_id" @> (10, 15, 1900))

והנה יש לנו שאילתא אשר משתמשת ב Range של Pg, אבל כתובה עם ORM.
בתעוד כתוב שגם שם השדה יכול להיות המקור של pg_range (למשל), אבל אצלי זה לא כך (גם אם זה גלובלי).

למערכים, הפעולה מאוד דומה גם כן:

DB[:comments].where(uid: 10).where(Sequel.pg_array_op(:comments).contains(Sequel.pg_array([15,23]))).sql
# SELECT * FROM "comments" WHERE (("id" = 1) AND ("comments" @> ARRAY[15,23]))

קריאה נוספת:

הגדרת sip trunk עם freeswitch

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

אך במידה ויש צורך להגדרות מיוחדות, או הגדרות של ביצוע פעולת register, אז אנחנו זקוקים להגדיר sip trunk, אך גם שם ישנם 2 גישות, אשר מוגדרות תחת sip_profiles:

  1. internal
  2. external

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

בברירת המחדל, internal מוגדר להשתמש עם sip בפורטים של 5060 ו 5061 (אם זה sip או sips). בעוד שרשת external מוגדר בברירת המחדל להשתמש בפורטים 5080 ו5081.

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

העניין הוא, שזה לא נעצר בפורטים, או בהפרדה הזו, אלא זה ממש מסייע למפות מההתחלה עד הסוף מאיפה השיחה מגיעה. האם היא נכנסת מרשת internal או external (למשל), ובכך גם להתנהג לגמרי שונה ולהיכנס ל context לגמרי שונים (כפי שמוגדר בברירת המחדל).
כך למשל, אפשר להגדיר טלפונים (מכשירי טלפון, להבדיל משלוחות המוגדרות ב directory) ב internal בעוד ש sip trunk (או gateway כשם נוסף) לספקית חיצונית נגדיר ב external. להמשיך לקרוא

שפת תכנות זה לא (רק) תחביר

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

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

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

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

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

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

איך לקרוא חוזה אחיד

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

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

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

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

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

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

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

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

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

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

רשומות DNS עבור SIP

לפני מספר שנים, למדתי הרבה (אך לא הכל 😦 ) על עולם ה DNS ובעיקר עבודה עם Bind, אך מצאתי שבד"כ יש רק מספר מצומצם של רשומות אשר משתמשים בהם: A, CNAME, TXT ו MX.
לאחרונה יצא לי ליעץ למספר חברות שונות אשר רצו לספק יותר משרת אחד לשירות SIP, ומצאתי את עצמי עושה להם קורס מזורז (לרוב דרך דוא"ל ושיחות טלפון) כיצד זה מתבצע, אז החלטתי להעביר את זה לכתב, ולנסות ולסייע יותר לאנשים באופן כללי.

A/AAAA

רשומת A מייצגת בעצם שם מתחם עבור כתובת IP. יש לו אח צעיר יותר בשם AAAA אשר מבצע אותו הדבר, רק עבור כתובות IPv6.

CNAME

רשומת CNAME, יודעת לקחת שם מתחם קיים, ולתת לו alias לשם אחר, כלומר foo.example.com יכול גם להצביע על bar.example.com ובכך שניהם מצביעים לאותו הדבר. הפירוש של CNAME הוא canonical name record והוא מעט "ממזר" באיך שקוראים ומשתמשים ברשומה.

TXT

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

MX

ויש את רשומת MX, אשר היא קיצור של mail exchanger record. התפקיד של הרשומה הוא לספק גישה למספר שרתי דואר תחת שם מתחם בודד, כאשר יש "משקל" לכל כתובת. המשקל אומר על קדימות של שימוש בשרת אחד על גבי השני. ככול שהמספר גבוהה יותר, כך כמות השימוש בו תהיה גבוהה יותר. כך שאם אשים משקל 60 לכתובת אחת ו10 לכתובת שניה, אז על כל 60 פניות לכתובת הראשונה, יהיו עשר פניות לכתובת השניה.

SOA

עוד רשומה מאוד נפוצה (למעשה הנפוצה ביותר) היא SOA שהיא Source of Authority. היא מחליטה בעצם על מי מנהל את ה DNS בפועל, או כמו שחבר כנסת חיפש פעם, הוא פחות או יותר האחראי על האינטרנט, לפחות בנושא של שמות מתחם.

כל זה נחמד למרבית השימוש כיום באינטרנט, אבל יש למעשה כמה עשרות סוגים של רשומות DNS, ועבור SIP אנחנו צריכים להשתמש בדרך כלל ברשומה מסוג SRV אשר משתמשת דרכה בכתובת שהיא A/CNAME . להמשיך לקרוא

FreeSwitch או אסטריסק ?

הקדמה

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

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

להמשיך לקרוא

Builder – שפת DSL ליצור תוכן Markup

אחד התוספות המעניינות ביותר שיש לרובי נקרא Builder.התוסף מאפשר לנו ליצור תוכן Markup אבל באמצעות שימוש ב DSL, במקום בשימוש של Templates או inline code.

בנוסף, הוא גם נמצא בשימוש של תוספים נוספים, כדוגמת Nokogiri. שם ניתן להשתמש בו לעריכה של xml.

שימוש פשוט בBuilder יראה כך: להמשיך לקרוא

סקריפטים לא קשורים

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

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

אז אני מקווה שהקוד שלי יסייע גם לכם

בזיון השעון (או איך חברות סלולר דופקות את הלקוחות שלהן)

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

העניין הוא שאנדרואיד וגם iOS מבוססות על יוניקס, ומי שאינו יודע, יש מערכת ניהול זמנים די איכותית שם, אשר כיום מנוהלת על ידי ארגון תקינה בשם IANA.

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

$ zdump -v Asia/Jerusalem | grep 2013 | grep Oct
Asia/Jerusalem  Sat Oct 26 22:59:59 2013 UTC = Sun Oct 27 01:59:59 2013 IDT isdst=1 gmtoff=10800
Asia/Jerusalem  Sat Oct 26 23:00:00 2013 UTC = Sun Oct 27 01:00:00 2013 IST isdst=0 gmtoff=7200

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

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

Sequel חלק שני

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

מודל

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

class Posts < Sequel::Model
end

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

require 'rubygems'
require 'sequel'

DB = Sequel::Sqlite('blog.db')

class Posts < Sequel::Model
end

Posts.where('id > :id', 1000).delete

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

בעת חיפוש, במידה וארצה למשל, לקבל את השדה title, אוכל לעשות זאת כך:

Posts[:title].where(id: 1)

אך במידה וארצה להשפיע על מה יהיה בפעולת ה select, עם יותר משדה אחד, אוכל פשוט להשתמש בפעולה הבאה:

Posts.select(:title).where(id: 1)

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

Posts.paged_each(rows_per_fetch: 25) do |row|
  p row
end

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

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

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

Sequel חלק ראשון

הקדמה

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

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

על הספרייה

הספרייה מחולקת לשני חלקים:

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

התקנה

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

$ gem install sqlite3 sequel

התחלה

להמשיך לקרוא

גימגום השיחה בטלפון

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

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

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

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

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

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

encryptfs

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

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

על מנת להתחיל לעבוד, צריך קודם כל לטעון מודול קרנל:

$ sudo modprobe ecryptfs

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

$ ecryptfs-setup-private

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

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

$ sudo mount -t ecryptfs /path/to/directory /path/to/directory

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

Key type: passphrase
Passphrase: ThisIsAVeryWeakPassphrase
Cipher: aes
Key byte: 16
Plaintext passtrough: no
Filename encryption: no
Add signature to cache: yes 

החתימות נשמרות תחת ‎/root/.ecryptfs/sig-cache.txt .

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

שימוש ב DATA של רובי

רובי מאפשרת ליצור איזור מיוחד בסוף קובץ ריצה.

האיזור נקרא __END__ והוא מאפשר לשים טקסט חופשי שם, בלי שהוא ישפיע על הקוד (אלא אם הוא קידוד שפה שונה משאר המידע בקובץ).

אפשר אבל מהקוד עצמו לקרוא את המידע הזה, ולעשות עליו פעולות:

#!/usr/bin/env/ruby
#

DATA.each_line do |l|
  puts l
end

__END__
hello
world

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

והנה דרך להציג את התוכנית הקודמת בתצורה אוקטאלית (מבוסס על הקוד מכאן):

#!/usr/bin/env ruby
#

if __FILE__ == $0
  offset = 0
  while (buf = DATA.read(16)) do
    bytes = buf.unpack 'C*'
    puts "%08X: %s\n" % [ offset, bytes.map { |b| " %04o" % b }.join('') ]
    offset += 16
  end
end

__END__
0000000 2123 752f 7273 622f 6e69 652f 766e 7220
0000020 6275 0a79 0a23 440a 5441 2e41 6165 6863
0000040 6c5f 6e69 2065 6f64 7c20 7c6c 200a 7020
0000060 7475 2073 0a6c 6e65 0a64 5f0a 455f 444e
0000100 5f5f 680a 6c65 6f6c 770a 726f 646c 000a
0000117

Some IX2-200 hacking

I've bought an Iomega IX2-200 NAS as a backup solution. For it's price, it was the best choice imho (but there are much better solutions out there, but a lot more expensive).

It runs Linux (Debian to be exact), but on default it does not enable ssh, and you can choose only sftp or rsync (as a client), but not at the same time.nas_diagnostics_page

Older firmware can open the ssh part as described at the link, however here is how to do it for a newer firmware:

  1. Enter your device
  2. Login
  3. Go to the following address:
    http(s)://<IP ADDRESS>/diagnostics.html
  4. Enable ssh (it might require you to change port due to proftpd acting as sftp server and binded on port 22)
  5. Use the user root with your login password, but provide a prefix of "soho" prior to it. That is, if your password is "1234" (and I hope it is not), then do the following to your password:
    soho1234
  6. Enjoy the access, and remember: "With great power, comes great responsibility" (or something like that)

For my next post, I'll understand how to make it work as an rsync server.

Remember the joy of device hacking 🙂

מי תיקח כמתכנת אצלך ?

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

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

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

אז מה כן אני מייעץ ?

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

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

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

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

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

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

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

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

ה gem הראשון שלי

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

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

אני חייב לציין שזה היה פשוט מידי לעשות את המהלך. הרשמה לrubygems, הורדת ה gemcutter מרובי gem, יצירת ה gem ואז ביצוע push עם הדוא"ל והסיסמה של rubygems וזהו 🙂

אני יודע שסטטיסטיקה חשובה לכם, אז נכון לכתיבת הפוסט היו 40 הורדות של ה gem פחות מ24 שעות לאחר הפרסום שלו, שלדעתי לפחות זה מדהים 🙂

מצגות בעולם הרחב של הרשת

מאז 2007, התחלתי להעביר הרצאות, חלקם ללקוחות בתשלום, ורובם קהילתיים לגמרי.

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

עד היום הייתי במידת הצורך יוצר שקפים באמצעות Impress של Libre/Open Office (בהתאם לקיומם בעולם), וכבר הרבה זמן שאני חושב להתחיל לעשות את זה קצת אחרת.

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

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

אז החלטתי ללכת על משהו בין מה שגוגל מציעים לבין impress.js, ומצאתי את reveal.js.
המערכת מציעה להעביר מצגות, עם תמיכה ב html5, css3 ו javascript. אבל אינה דורשת ממני לתכנת דברים, אלא להתמקד בתוכן, וכיצד אני רוצה שהוא יוצג. למעשה התכנות שלי זה html הכי מינימליסטי בעולם. המפתח שלה אפילו חשב על תמיכה בשפות כמו עברית, ולאפשר לנו להציג הרצאה מימין לשמאל לפי בחירה.

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

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

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

May the source be with you 🙂

טעינת קובץ csv ברובי

אם יש לכם צורך לייבא מידע מקובץ csv, זה יכול להיות כאב ראש. בייחוד אם עובדים מול אנשי ווינדוז החושבים כי אקסל זה כלי יעיל (בהשוואה לLibreOffice Calc).

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

הטעינה הפשוטה ביותר היא כזו:

require 'csv'
CSV.foreach('path/to/file.csv') do |row|
  # use row here...
end

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

מלח הארץ

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

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

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

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

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

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

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

כאשר התחלתי לחקור מה אני צריך לנושא, התחלתי לעשות בדיקות של הרבה מאוד סביבות עבודה, בניהם django, rails, ramaze, dancer, padrino, tornado ועוד מספר מערכות מבוססות Node.js.

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

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

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

יצירת מסד נתונים בזמן ריצה

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

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

createdb

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

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

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

procedure TfrmDBCreate.btnCreateClick(Sender: TObject);
var Transaction : TSQLTransaction;
begin
  FBConnection.DatabaseName := edtDatabaseName.Text;
  FBConnection.CharSet      := 'UTF8';
  FBConnection.HostName     := edtHost.Text;
  FBConnection.UserName     := edtUserName.Text;
  FBConnection.Password     := edtPassword.Text;
  Transaction               := TSQLTransaction.Create(nil);
  FBConnection.Transaction  := Transaction;
  try
   FBConnection.CreateDB;
   FBConnection.ExecuteDirect('CREATE table test1 (name varchar(24) not null)');
   Transaction.Commit;
   MessageDlg('Info', 'The database was created.', mtInformation,
             [mbClose], -1);
  except
    on e : EIBDatabaseError do
     begin
       MessageDlg('Error', 'Could not create database : ' + LineEnding +
                  e.Message, mtError, [mbClose], -1);
     end;

     on e : Exception do
       begin
        MessageDlg('Error', 'Unknown error : ' + LineEnding + e.Message,
                 mtError, [mbClose], -1);
       end;
  end;
  Transaction.Free;
end;

קודם כל אנחנו מזינים לTIBConnection את הפרמטרים שהוזנו, כדוגמת קובץ מסד הנתונים, הכתובת של השרת, בנוסף החלטתי להשתמש ב UTF8 כקידוד למחרוזות.
בנוסף יצרתי רכיב עבור טרנזאקציות, הוא צריך להיות בשימוש לשאילתא שאריץ לאחר יצירת מסד הנתונים (כל השימוש בו).
בתוך try אני אומר למנהל החיבור למסד נתונים ליצור את מסד הנתונים. חשוב לדעת כי זה קיים בכל החיבורים שלנו למסדי נתונים המבוססים DataSet, ולא ייחודי ל Firebird.
לאחר מכן, החלטתי גם להציג כיצד ניתן ליצור בתוך אותו קוד טבלה, אז יצרתי טבלה בשם test1 עם שדה בשם name שהוא מסוג varchar ומסוגל לקבל עד 24 תווים.
נעשה על השאילת commit, ואנחנו מוכנים !

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

מי אמר שעבודה עם מסדי נתונים צריכה להיות כואבת ?

את קוד המקור תוכלו למצוא כאן
 

regular expression על קצה הפוסט – חלק ראשון

עולם המתכנתים מתחלק לשלושה חלקים:

  1. אלו אשר משתמשים ב Regex‏
  2. אלו אשר שמעו על Regex‏
  3. אלו שחושבים שאני מקלל אותם כרגע

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

Regular Expression או Regex כקיצור, זו למעשה שפה המאפשרת לתאר תבנית מסויימת של טקסט שרוצים למצוא או לשנות.

ישנן הרבה מימושים לשפה, כאשר כל מימוש מספק יכולות שונות – בעיקר תוספות למימוש הבסיסי ביותר. אחת הידועות ביותר נקראת Perl Compatible Regular Expression או PCRE בקיצור .אך התקן הבסיסי ביותר שיש עבור השפה, בכלל שייכת לPOSIX.

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

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

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

Hello World

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

^([\w]+)\s([\w]+)$

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

השוואת טיפוס נתונים ב Ruby עם case

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

עם case היה מאוד טבעי לעשות משהו כזה:

a = {'one' => 1 }
puts "a.class = #{a.class}"
case a.class
when Hash
puts 'Hash'
else
puts 'not Hash'
end
view raw case1.rb hosted with ❤ by GitHub

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

a = {'one' => 1 }
puts "a.class = #{a.class}"
case a
when Hash
puts 'Hash'
else
puts 'not Hash'
end
view raw case2.rb hosted with ❤ by GitHub

 

* צריך תמיכה ב Javascript גם ב wordpress וגם ל gist על מנת לצפות בקוד.

הרצת מתודות בצורה דינאמית חלק ראשון

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

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

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

עוד סדרת טיפים לעבודה עם לינוקס

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

דפי man צבעוניים

אם אתם רוצים לצפות בדפי man בצורה צבעונית, או מחפשים עוד PAGER בנוסף, אז אתם מוזמנים להכיר את most. most pagerאני גרמתי לו להיות ברירת המחדל רק עבור תצוגת דפי ה man, על ידי הוספת ההגדרה הבאה בקובץ ‎/etc/man_db.conf: להמשיך לקרוא