ToCode

# עבודה עם מספר בסיסי נתונים ב Sequelize בפרויקט ברירת מחדל חדש ש Sequelize יוצר אנחנו יכולים בקלות להגדיר מספר בסיסי נתונים עבור הסביבות השונות לדוגמא בסיס נתונים אחד עבור Production, שני עבור test ושלישי לפיתוח. הבעיה שמאותו שלד פרויקט לא כל כך ברור איך להתחבר למספר בסיסי נתונים במקביל כדי למשל להעביר מידע ביניהם, תוך שימוש במודלים ובקוד שכבר יש לנו מ Sequelize. אני רוצה להציג כאן תבנית פרויקט פשוטה שכן מאפשרת עבודה עם מספר בסיסי נתונים במקביל בפרויקט Sequelize. ## הקובץ config.js השינוי הראשון בהשוואה לפרויקט שמג'ונרט אוטומטית הוא הקובץ config.js שעכשיו יכיל את פרטי בסיסי הנתונים השונים:

const path = require('path');

module.exports = {
  "db1": {
    dialect: 'sqlite',
    storage: path.resolve(__dirname, '..', 'data', 'db1.db'),
  },
  "db2": {
    dialect: 'sqlite',
    storage: path.resolve(__dirname, '..', 'data', 'db2.db'),
  },
};

אני קראתי להם בשמות הקצת טפשיים db1 ו db2. בעולם האמיתי ייתכן ותרצו שכל אחד מהם יהיה אוביקט מורכב ובתוכו הסביבות production, test ו development. בכל מקרה אם כן זה ידרוש מכם קצת עבודת התאמה בקובץ index.js. ## קובץ הגדרות המודלים models/index.js קובץ הגדרות המודלים הדיפולטי בוחר את הסביבה המתאימה וטוען את כל המודלים עבורה בלבד. עם שינוי קטן מאוד אפשר לטעון את כל המודלים בכל הסביבות, או לפחות בסביבות איתן אנחנו רוצים לעבוד. האוביקט אותו אני מייצא יראה כך:

const dbs = {
  db1: {},
  db2: {},
};

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

'use strict';

const fs = require('fs');
const path = require('path');
const Sequelize = require('sequelize');
const basename = path.basename(__filename);
const env = process.env.NODE_ENV || 'development';
const config = require(__dirname + '/../config/config.js')[env];

const dbs = {
  db1: {},
  db2: {},
};

for (let [name, db] of Object.entries(dbs)) {  
  let config = require(__dirname + '/../config/config.js')[name];
  db.sequelize = new Sequelize(config.database, config.username, config.password, config);
}

fs
  .readdirSync(__dirname)
  .filter(file => {
    return (file.indexOf('.') !== 0) && (file !== basename) && (file.slice(-3) === '.js');
  })
  .forEach(file => {
    for (let [name, db] of Object.entries(dbs)) {  
      const model = db.sequelize['import'](path.join(__dirname, file));
      db[model.name] = model;
    }
  });

for (let [name, db] of Object.entries(dbs)) {  
  Object.keys(db).forEach(modelName => {
    if (db[modelName].associate) {
      db[modelName].associate(db);
    }
  });
}

dbs.Sequelize = Sequelize;

module.exports = dbs;

## הקוד בפעולה - הקובץ app.js עכשיו אנחנו מוכנים לצאת לדרך עם הקובץ app.js שיראה איך להשתמש בשני בסיסי הנתונים במקביל. הפונקציה הבאה מתחברת לשני בסיסי הנתונים ומוצאת את כל אוביקטי הספרים שמוגדרים באחד אך לא בשני:

async function main() {
  const books1 = await dbs.db2.Book.findAll();
  const ids = books1.map(b => b.id);

  const books2 = await dbs.db1.Book.findAll({
    where: {
      id: { [Op.notIn]: ids }
    }
  });

  console.log(books2.map(b => b.title));
}

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

$ NODE_ENV=db1 sequelize db:migrate
$ NODE_ENV=db2 sequelize db:migrate

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

# הולך על בטוח אפילו בבחירות הכי קטנות של היום יום, וכמובן שבבחירות מקצועיות משמעותיות, אנחנו יכולים להחליט ללכת על בטוח או להיות מיוחדים. אתם יכולים לראות את הסידרה שכולם מדברים עליה (ואז בטוח יהיה לכם עם מי לדבר ותרגישו בעניינים), או שתבחרו סידרה שאף אחד לא שמע עליה. אתם יכולים לצאת למסעדה שאתם מכירים ויודעים שיהיה שם טעים, או שתבחרו לנסות מקום חדש. אבל כמובן שבשדה המקצועי הבחירה הזאת נראית הרבה יותר משמעותית - אתם יכולים ללמוד Java כמו כולם או להחליט להיות מיוחדים ולהשקיע ב Scala. וההתלבטות הזאת גומרת אותנו לפעמים. בשדה הטכנולוגי כדאי לזכור שיש מעט מאוד טכנולוגיות שהן באמת ללכת על בטוח. Java היא כזו וכנראה גם JavaScript, תתחילו ללמוד אותן היום ובעוד שנתיים עדיין כולם ידברו על זה. מצד שני היום אפשר להתפרנס לא רע בכלל גם מהטכנולוגיות הייחודיות שאף אחד לא מדבר עליהן או שהן קשות מדי ואף אחד לא רוצה ללמוד אותן. אם אני צריך מומחה Linux Kernel לפרויקט יש מעט מאוד אנשים בארץ שאני יכול לדבר איתם על זה, והם מתפרנסים לא רע מהמומחיות הייחודית שלהם.

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

BookCategory.all.select {|bc| bc.category.nil? }

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

BookCategory.left_outer_joins(:category).where("categories.id is null")

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

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

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

# למה לקשור פונקציה לעצמה? בפוסט של אתמול הופיעה שורה קצת מוזרה:

  constructor() {
    this.inc = this.inc.bind(this);
  }

למה לקשור את הפונקציה לעצמה? איך זה משפיע על הקוד? והאם דברים יעבדו גם בלי זה? בואו ניקח 5 דקות לדבר קצת על bind ו this ואני מקווה שבסופן נבין את התעלומה. ## משפט וחצי על this ב JavaScript בשפת JavaScript המשתנה המיוחד this הוא סוג של עוף מוזר. בעוד שבשפות Object Oriented קלאסיות אחרות יש חיבור אוטומטי בין משתנה זה לבין המחלקה ממנה הוא נוצר, ב JavaScript חיבור כזה אינו קיים. קל מאוד "לעבוד" על מתודה ולגרום לה לפעול על אוביקטים שונים או על אוביקטים ממחלקה אחרת. שימו לב רגע לקוד הבא:

class Foo {
  constructor(name) {
    this.count = name.length;
  }

  show() {
    console.log(`your name has ${this.count} letters`);
  }
}

const f = new Foo('ynon');
f.show();

הקוד עובד ומדפיס שבשם שלי יש 4 אותיות כמו שחשבנו שיקרה, בגלל שבכניסה לפונקציה show המשתנה this מתיחס לאותו דבר שהמשתנה f מתיחס אליו בקוד החיצוני. אבל החיבור הזה בין הפונקציה show לבין המשתנה f בקוד החיצוני הוא שברירי וזמני. למעשה השם האמיתי של הפונקציה הוא Foo.prototype.show והשורה f.show היא בסך הכל קיצור דרך לפקודה הקצת יותר ארוכה:

Foo.prototype.show.call(f);

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

class Foo {
  constructor(name) {
    this.count = name.length;
  }

  show() {
    console.log(`your name has ${this.count} letters`);
  }

  showLater() {
    setTimeout(this.show, 500);
  }
}

const f = new Foo('ynon');
f.showLater();

הפעם אנחנו מקבלים את התוצאה:

your name has undefined letters

הסיבה לבעיה היא שהחיבור בין הפונקציה Foo.prototype.show לבין המשתנה f החיצוני הוא זמני: הוא קיים רק כי f עבר כפרמטר נסתר לפונקציה, ואנחנו באותה שרשרת קריאות. ברגע שהוספתי setTimeout, כשהדפדפן יגיע להפעיל את show הוא כבר לא יעשה את זה עם אותו this. ## קשירת הפונקציה לעצמה עכשיו אפשר לדבר על השורה שלמעלה:

    this.inc = this.inc.bind(this);

ולשים לב שהמטרה שלה היא לא לקשור את הפונקציה לעצמה, אלא לקשור את הפונקציה ל this. ננסה את אותו קוד עם ה setTimeout אחרי הקשירה:

class Foo {
  constructor(name) {
    this.count = name.length;
    this.show = this.show.bind(this);
  }

  show() {
    console.log(`your name has ${this.count} letters`);
  }

  showLater() {
    setTimeout(this.show, 500);
  }
}

const f = new Foo('ynon');
f.showLater();

והתוצאה הפעם תקינה:

your name has 4 letters

החיבור של הפונקציה ל this גורם לזה שלא משנה מתי ואיך נפעיל אותה, המשתנה this בתוך גוף הפונקציה תמיד יכיל את האוביקט ש new Foo יצר. זאת ההתנהגות שאנחנו רגילים אליה מ Java או Python אבל היא לא ברירת המחדל ב JavaScript. ## האם צריך תמיד לקשור פונקציות? אז האם צריך להתחיל כל קלאס בשורת bind-ים? התשובה הקצרה היא לא. זה אולי לא מזיק אבל זה כן יכול לבלבל קצת (כמו שקרה בפוסט של אתמול) ולקחת קצת יותר זיכרון. אנחנו נפעיל bind רק כשאנחנו חושבים שמישהו עלול להפעיל את הפונקציה שלנו מחוץ לקונטקסט וש this עלול להתקלקל. ## ויש גם קיצור דרך ולפני שניפרד שווה להזכיר שיש גם קיצור דרך. הקוד הזה מפעיל אוטומטית את bind על הפונקציה show איפה שנתמך:

class Foo {
  constructor(name) {
    this.count = name.length;
  }

  show = () => {
    console.log(`your name has ${this.count} letters`);
  }

  showLater() {
    setTimeout(this.show, 500);
  }
}

אבל היו זהירים כי הוא לא נתמך ברוב הדפדפנים ולא ב Node.JS.

# היום למדתי: משתנים פרטיים ב JavaScript אז אנחנו כבר יודעים ש JavaScript רצה מהר ואחד הפיצ'רים שכבר נכנסו לדפדפנים (ול Node.JS) נקרא משתני מחלקה פרטיים. בואו נראה בגדול מהם ואיך משתמשים בהם. ## הגדרה ושימוש במשתנים פרטיים משתני מחלקה פרטיים הם משתני מחלקה שאפשר לגשת אליהם או לשנות אותם רק מקוד שכתוב בתוך המחלקה עצמה. הדרך להגדיר אותם ב JavaScript היא ליצור משתני מחלקה ששמם מתחיל בסימן הסולמית. אז נכון שסולמית לא נראה הכי טוב ותכל'ס כולם רצו שטרודל כדי שיראה כמו רובי, אבל בגלל ששטרודלים היו תפוסים בשביל Decorators היה צריך להיות יצירתיים. נשים לב שבניגוד למשתני מחלקה רגילים, כשמדובר במשתנים פרטיים אנחנו חייבים להצהיר עליהם בעת יצירת המחלקה שזה אומר לציין בתוך קוד המחלקה מחוץ לכל הפונקציות את שמות המשתנים הפרטיים שלנו. הקוד הבא מגדיר מחלקה בשם Counter עם משתנה פרטי בשם #val:

class Counter {
  #val
  constructor() {
    this.inc = this.inc.bind(this);
    this.#val = 0;
  }
  
  inc() {
    return ++this.#val;
  }
}

קוד חיצוני שייצור לעצמו אוביקט Counter וינסה לשנות את הערך של val ייכשל ויקבל הודעת שגיאה:

const c = new Counter();

// Error - #val is private
c.#val = 999;

## קודפן אם בא לכם לשחק עם זה יצרתי כאן קודפן שאפשר להריץ בדפדפנים. אצלי בכרום זה עובד מעולה אבל פיירפוקס עדיין לא תומך. לחצו על הכפתור ואם הכל עובד ערך המונה יעלה ב-1 עם כל לחיצה: <iframe height="300" style="width: 100%;" scrolling="no" title="pMPYNq" src="//codepen.io/ynonp/embed/pMPYNq/?height=300&theme-id=20374&default-tab=js,result" frameborder="no" allowtransparency="true" allowfullscreen="true"> See the Pen <a href='https://codepen.io/ynonp/pen/pMPYNq/'>pMPYNq</a> by Ynon Perek (<a href='https://codepen.io/ynonp'>@ynonp</a>) on <a href='https://codepen.io'>CodePen</a>. </iframe> ## שאלות נפוצות וקריאת המשך רשימה של שאלות נפוצות ומידע נוסף על הפיצ'ר אפשר למצוא בקישור: https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md

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

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

[print(x) for x in range(10)]

ל:

for i in range(10):
    print(i)

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