הבלוג של ינון פרק

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

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

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

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

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

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

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

<?xml version="1.0"?>
<soap:Envelope 
          xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Body>
    <m:GetCustomer 
          xmlns:m="http://www.example.org/customers">
      <m:CustomerId>43456</m:CustomerId>
    </m:GetCustomer>
  </soap:Body>
</soap:Envelope>

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

<?xml version='1.0' ?>
<env:Envelope 
        xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
 <env:Body>
    <m:GetCustomerResponse 
          xmlns:m="http://www.example.org/customers">
       <m:Customer>Foobar Quux, inc</m:Customer>
    </m:GetCustomerResponse>
 </env:Body>
</env:Envelope>

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

עד שיום אחד מתכנתים הפסיקו לעבוד ב Visual Studio והלכו לכתוב מערכות אינטרנט ב Rails (כן ריילס היה פופולרי ממש ב 2005) ומפה לשם שמנו לב שהרבה יותר קל פשוט לשלוח הודעה בפרוטוקול REST:

GET /customers/43456 HTTP/1.1
Host: www.example.org

ולקבל את התשובה ב JSON:

{'Customer': 'Foobar Quux, inc'}

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

http://keithba.net/simplicity-and-utility-or-why-soap-lost

עכשיו בחזרה אלינו וללקחים מ SOAP-

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

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

3. למודול soap ב npm יש באזור השמונים אלף הורדות בשבוע. זה אולי לא מתקרב ל 7 מיליון הורדות של אקספרס אבל עדיין מזכיר שאני לא היחיד שהיה צריך להתחבר לשרת SOAP השבוע.

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

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

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

import re
re.search('l+', 'hello')

דרך אחרת היא לשבור את הפעולה ל-2 כמו שממחישה התוכנית הבאה, שעושה בדיוק את אותו דבר רק נותנת לך ״נקודת התערבות״ אחרי הקומפילציה של הביטוי:

import re
scanner = re.compile('l+')
scanner.search('hello')

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

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

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

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

use strict;
use v5.24;

my $scanner = qr { l+ }x;

if ("hello" =~ $scanner) {
  say "Match!";
}

לרובי יש פונקציה בשם compile אבל היא בסך הכל שם נרדף לפונקציה Regexp.new ולכן כך יראה אותו הקטע ברובי:

scanner = Regexp.new('l+')

if scanner.match('hello')
  puts "Match!"
end

ו JavaScript השאירו רק את פונקציית הבנאי ושם הקוד יראה כך:

const scanner = new RegExp(/l+/)
if ('hello'.match(scanner)) {
    console.log('Match!');
}

הי חברים,

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

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

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

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

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

המטרה שלי בקורס Node.JS היא לתת לכם את כל הכלים לפתח יישומי ווב מלאים ולכן הקורס כולל גם את Node עצמה, ה APIs שלה ו Best Practices לפיתוח יישומים בסביבה אסינכרונית, ובנוסף גם את כל הספריות שצריך להכיר כדי לפתח Web Applications. בגדול זה אומר שלומדים:

1. מתחילים עם Node.JS - התקנת הסביבה, פקודות בסיסיות וכו'.

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

3. נדבר על npm וניהול חבילות - על הקובץ package.json, מתי משדרגים ואיך לנהל תלויות גם ביישומים גדולים.

4. נלמד לפתח Web Applications עם ספריית Express, כולל עבודה עם EJS, פיתוח APIs, כתיבת Express Middlewares ו Best Practices לפיתוח פרויקט ווב מלא.

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

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

7. נלמד איך לשלב תקשורת דו-כיוונית עם Socket.IO ונפתח יישום צ'ט עם מספר חדרי שיחה ששומר את המידע בבסיס נתונים ומדווח על הודעות חדשות "לייב" כל המצ'וטטים.

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

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

https://www.tocode.co.il/bundles/nodejs

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

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

לכן שתי טעויות של מתכנתים שכדאי להימנע מהן:

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

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

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

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

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

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

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

c = { 'one': 1, 'two': 2, 'three': 3, 'four': 4 }

found = False
for k, v in c.items():
    if v == 2:
        found = True
        break

if found:
    print("Found a 2 in the dictionary")

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

c = { 'one': 1, 'two': 2, 'three': 3, 'four': 4 }

if any(v == 2 for k, v in c.items()):
    print("Found a 2 in the dictionary")

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

c = { 'one': 1, 'two': 2, 'three': 3, 'four': 4 }
d = { 'two': 2, 'four': 4 }

if all(v % 2 == 0 for k, v in c.items()):
    print("All values in c are even numbers")

if all(v % 2 == 0 for k, v in d.items()):
    print("All values in d are even numbers")

שימו לב לשימוש ב Generator Comprehension ולא ב List Comprehension, כלומר סוגריים עגולים ולא מרובעים. הבחירה ב Generator Comprehension היא שגורמת לקוד להתנהג כמו לולאת for, כלומר שהערכים ייבדקו אחד-אחד ולא ייטענו כולם לזיכרון. זה חסכוני יותר בזיכרון ובמקרה של any גם ירוץ מהר יותר אם התשובה היא True.

את Redux הוגים רי-דאקס.

את Tuple הוגים בשורוק (כמו יוטיוב).

את Git הוגים עם גימל בהתחלה.

ב Node.JS כן הוגים את ה de ואומרים "נוד ג'יי אס"

ב Django לא הוגים את ה D ולכן אומרים "ג'נגו"

את Erlang הוגים עם צרה, כמו אריקסון שהמציאה את השפה.

כשמדברים על Scss אומרים את האותיות אחת אחרי השניה כלומר "אס סי אס אס"

את Ajax הוגים Ay-Jax אפילו שרוב האנשים שאני מכיר אומרים א-ג'קס.

את PostgreSQL רוב האנשים הוגים post-gres-q-l, אבל אף אחד לא יכעס אם תקראו לו באהבה post-gres.

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