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

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

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

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

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

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

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

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

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