ToCode

# שימוש ב Scss בפרויקט Webpack פיתוח פרויקט באמצעות Webpack אומר שאנחנו יכולים להריץ קוד על כל אחד מהקבצים שאנחנו טוענים. באחד הפרקים הקודמים בסידרה למדנו על Babel וראינו איך לתרגם קבצי JavaScript בעזרתו. היום אני רוצה לדבר על Scss ואיך להשתמש ב Webpack כדי לתרגם קבצי Scss לקבצי CSS רגילים. ## קובץ Scss הראשון שלי שפת Scss נועדה לתת למתכנתים שכותבים CSS כלי עבודה טובים יותר לשתף קוד CSS בין קבצים ובין פרויקטים. אפשר לקרוא עליה באריכות בפוסט איך ולמה להתחיל להשתמש ב Scss שכתבתי בעבר. לצורך הפוסט היום אני מניח שאתם יודעים קצת Scss או שהעפתם מבט בפוסט על הנושא. בפוסט ההוא על Scss סיפרתי על כלי בשם Koala שיודע להפוך את קבצי ה Scss שלכם לקבצי CSS רגילים. הפעם נרצה לעשות את אותה עבודה עם Webpack וכך לשלב את Scss במהלך העבודה הרגיל שלנו. התחילו עם פרויקט Webpack חדש וצרו בו תיקיה בשם styles ובה קובץ בשם main.scss. כתבו בפנים את התוכן הבא שלקוח מתוך פוסט ההקדמה שלי על Scss:

$fg: orange;
$bg: ligthtblue;

body {
  background: $bg;
  color: $fg;
}

.inverse {
  background: $fg;
  color: $bg;
}

המשימה שלנו להמשך הפוסט היא למלא את שאר הקבצים בפרויקט כדי שהקובץ הזה יגיע לדפדפן בתור קובץ CSS רגיל. מוכנים? יוצאים לדרך. ## יצירת קובץ הגדרות webpack.config.js בשביל לטעון את קובץ ה Scss אנחנו צריכים Loader. ואכן הספריה sass-loader תעזור לנו לטעון קובץ Scss ולהפוך אותו לקובץ CSS רגיל לכל דבר. חוץ ממנה נרצה את node-sass, את css-loader וכמובן את mini-css-extract-plugin כדי לקבל את הקבצים עצמם. סך הכל שורת ההתקנות נראית כך:

npm install --save webpack webpack-cli node-sass sass-loader css-loader html-webpack-plugin mini-css-extract-plugin

ניצור קובץ src/main.js עם שורה אחת שטוענת את קובץ העיצוב שלנו:

import '../styles/main.scss';

וניצור קובץ הגדרות webpack.config.js עם כל הפלאגינים וה loaders:

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin')
const MiniCssExtractPlugin = require('mini-css-extract-plugin');


module.exports = {
  entry: './src/main.js',
  output: {
    filename: '[name].js',
    path: path.resolve(__dirname, 'dist')
  },
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          {
            loader: MiniCssExtractPlugin.loader,
            options: {
              hmr: process.env.NODE_ENV === 'development',
            },
          },
          'css-loader',
          'sass-loader',
        ],
      }
    ],
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: '[name].css',
      chunkFilename: '[id].css',
    }),
    new HtmlWebpackPlugin(),
  ],
};

בניה של הפרויקט עם:

$ npx webpack -d

תייצר לנו עכשיו בתיקיית dist את הקבצים הבאים:

$ tree dist
dist
├── index.html
├── main.css
└── main.js

הקובץ main.css ששם הוא קובץ CSS תקין לכל דבר שאפשר לשלוח לדפדפן. תוכן הקובץ:

body {
  background: lightblue;
  color: orange; }

.inverse {
  background: orange;
  color: lightblue; }

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

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

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

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

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

$ shopt extglob
extglob         on

אם הפלט אצלכם הוא off יש להפעיל את התמיכה באמצעות:

$ shopt -s extglob

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

$ rm *.*

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

$ rm !(*.*)

# לגלות דרכים חדשות דרך קלה לשלב לימודים כחלק מתהליך העבודה היא להוסיף אילוצים - למשל, קיבלתי משימה להתחבר לבסיס נתונים ולהוציא משם מידע, אני יודע כבר לכתוב SQL ולהפעיל SQL מתוך תוכנית פייתון, אז במקום לבחור את הדבר הקל שאני יודע אלך ללמוד SQL Alchemy ואבנה את התוכנית איתו. האילוץ לחפש דרך חדשה הוא שדוחף אותי להמשיך וללמוד. אבל לגישה זו יש הרבה התנגדויות וכולן הולכות סביב נושא המהירות: ״אם קיבלתי משימה אני מחויב לסיים אותה הכי מהר שאני יכול״, או ״יש לי עוד אלף דברים לעשות ובחיים לא אסיים את כל מה שאני צריך אם אתעסק בללמוד כל היום״. המציאות היא הפוכה - אם תשקיעו את היום שלכם בלימוד וגילוי דרכים חדשות תוך כדי עבודה, לאורך זמן תכירו יותר ויותר שיטות עבודה ויותר כלים, וכל כלי חדש יהפוך אתכם למתכנתים מהירים וטובים יותר. היכולת להכיר בדיוק את המודול שצריך ולהשתמש בו בלי שגיאות מהפעם הראשונה היא מיומנות שלוקח זמן לפתח אותה, וההשקעה הזאת מחזירה את עצמה פי עשר ויותר. העבודה ב 120% מהקצב שלכם מתישה, שוחקת ומשאירה אתכם במקום מבחינה מקצועית. הרבה יותר חכם לעבוד ב 60% מהקצב שלכם ולהשקיע את הזמן שנותר בלימוד וקידום מקצועי. בעוד שנתיים ה 60% שלכם יהיה מהיר יותר מה 120% של כל המתכנתים מסביב.

# מה מעניין פה? אז לקחתי השבוע באחד הימים את הקטנה (בת 3) למשרד המשותף בו אני עובד. חשבתי שהיא תוכל לרוץ קצת מצד לצד ואני בזמן הזה אשב על המחשב. זה לא ממש עבד, אבל קרה משהו מעניין אחר במקום- היא באמת רצה מצד לצד, וגם מצאה המון דברים שלא ידעתי שהיו שם, וגם הפכה חלק גדול מהם למשחקים, ותוך כדי שכמעט שברה כמה דברים הצלחנו לגלות יחד שיש המון דברים שילדים יכולים לאהוב בחלל עבודה משותף. הקטע העצוב הוא שבגיל מסוים זה עובד להם. עוד שנתיים-שלוש כשאקח אותה איתי לעבודה באמת אוכל לשבת לעבוד, כי היא תהיה עסוקה במשחקים בטלפון. ובינינו גם אם לא היה טלפון בשלב מסוים ילדים גדולים (וגם מבוגרים) מבינים שיותר קל לחפש לשחק במה שמכירים מאשר למצוא משחקים חדשים עם מה שיש. וכן גם כשלומדים שפת תכנות חדשה. וככה אנחנו מוצאים המון מתכנתים שלומדים JavaScript והשאלות הראשונות שישאלו יהיו איך לבנות היררכיית מחלקות כמו שאני מכיר מ Java, או למה אין פה Static Types ואיך לממש פה את ה Design Patterns שאני רגיל אליהן. וזה חבל, כי הכיף האמיתי מסתתר בשאלות כמו ״מה אפשר לעשות עם Clojure שהיה קשה בשפות אחרות?״, או ״איזה Design Patterns אנחנו עשויים למצוא בפרויקט JavaScript גדול (שלא היינו מוצאים בשפות אחרות)?״.