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

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

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

בשביל לקמפל סקריפט בשם demo.py אני מפעיל:

python -m compileall demo.py

זה יוצר תיקייה בשם __pycache__ ובתוכה קובץ בשם demo.cpython-313.pyc. בשביל להריץ צריך להפעיל:

python __pycache__/demo.cpython-313.pyc

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

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

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

אחד הטרנדים של ריילס היום הוא לוותר על ה Build Step ולהשתמש רק ב JavaScript. בניסוי היום כתבתי פרויקט ריילס שמשלב את vue כדי לראות איך זה עובד ובמה זה שונה מפרויקט צד-לקוח רגיל.

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

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

הקוד הזה עובד, אבל גורם לטייפסקריפט לכעוס:

<script setup lang="ts">
import { inject } from 'vue';
import { translations } from './InjectionKeys';

const texts = inject(translations);
</script>

<template>
  <button>{{ texts['click-here'] }}</button>
</template>

הקומפוננטה לוקחת מהקונטקסט את הערך הכי קרוב של המשתנה translations ואז מושכת ממנו את התרגום של הטקסט click-here. אין שגיאות בקונסול ועל המסך הכל נראה תקין. יותר מזה, אם בטעות מישהו שכח לעשות provide ל texts מיד נראה את השגיאה בקונסול כי ננסה לקרוא מפתח מתוך null. אני בסדר עם ההתנהגות הזאת כי אין לי מה לעשות עם המערכת אם אפילו הטקסטים לא נטענו. הבעיה שטייפסקריפט לא יודע את כל מה שאני יודע ומסמן את שורת הכפתור ב template באדום. מה עושים? שתי הצעות-

דרך אחת היא להוסיף בדיקה בקוד הסקריפט אחרי inject:

<script setup lang="ts">
import { inject, ref } from 'vue';
import { translations } from './InjectionKeys';

const texts = inject(translations);
if (!texts) {
  throw new Error("Missing texts in parent component");
}
</script>

<template>
  <button>{{ texts['click-here'] }}</button>
</template>

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

<script setup lang="ts">
import { inject, ref } from 'vue';
import { translations } from './InjectionKeys';

const texts = inject(translations, ref<Record<string, string>>({}));
</script>

<template>
  <button>{{ texts['click-here'] }}</button>
</template>

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

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

הפוסט כאן נוגע בנקודה טובה לגבי SQL: https://www.depesz.com/2024/12/01/sql-best-practices-dont-compare-count-with-0/

בקצרה הוא מסביר למה לא כדאי לכתוב את זה:

SELECT u.* FROM users u
WHERE 0 = (SELECT COUNT(*) FROM addresses a WHERE a.user_id = u.id);

כשבעצם היה צריך לכתוב את זה:

SELECT u.* FROM users u
WHERE NOT EXISTS (SELECT FROM addresses a WHERE a.user_id = u.id);

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

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

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

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

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

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

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

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

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

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

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

מישהו פרסם שאלת ראיונות עבודה טפשית על JavaScript ושאל מה יהיה הפלט של התוכנית הבאה:

function sayHi() {
  console.log(name);
  console.log(age);
  var name = 'Lydia';
  let age = 21;
}

sayHi();

זה לא חשוב עכשיו מה התשובה. אתם יכולים ללכת ל Chat GPT לברר. מה שיותר מעניין זה מבנה התשובה של אותו Chat GPT:

1. המשפט הראשון מסביר את המטרה של השאלה - זו שאלה שבודקת את ההיכרות שלך עם הרעיונות של Variable Hoisting ו Block Scoping ב JavaScript. וזאת בדיוק הדרך שכדאי להתחיל תשובה לשאלות גם בראיון אמיתי.

2. אחרי זה Chat GPT מסביר על הרעיונות ומספר מה ההבדל בין var ו let בהקשר של גישה למשתנה לפני שורת ההגדרה שלו.

3. לאחר מכן הוא עובר שורה שורה ומסביר מה היא עושה ולמה (זה קצת מיותר בעיניי).

4. ובסוף מראה את פלט התוכנית.

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

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

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

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

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

היום הוא היום הראשון של דצמבר והחידה הראשונה של Advent Of Code בדיוק התפרסמה. בהצלחה.

https://adventofcode.com