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

טיפים קצרים וחדשות למתכנתים

צעדים ראשונים עם jQuery

30/10/2018

ספריית jQuery נוצרה כדי לתת לנו ממשק עבודה טוב יותר עם ה DOM. בתקופה ש jQuery התחילה כל דפדפן סיפק פונקציות שונות כדי לחבר בין קוד JavaScript לבין התוכן שאתם רואים על הדף. ג'ון רסיג כתב את jQuery ב 2005 בזמן שלמד בקולג' במטרה לתת למתכנתים (ולעצמו) כלים טובים יותר לגשת ל DOM ולחבר קוד טיפול באירועים בצורה שעובדת טוב בכל הדפדפנים.

בשנה הראשונה של jQuery היא היתה הספריה היחידה שהגיעה עם תיעוד מלא. כל שאר הספריות שלחו אתכם להסתכל בקוד המקור שלהן או להבין דברים לבד. מאפיין זה יחד עם ארכיטקטורת פלאגינים שבנויה לתוך הספריה הפכו אותה מ"עוד ספריה לגישה ל DOM" לספריה המרכזית שאנשים בוחרים בה ב 2006, ב-2012 וכן גם ב 2018.

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

המשך קריאה

תקשורת Ajax ב jQuery היא עדיין הרבה יותר פשוטה מהדפדפן

29/10/2018

שתי יכולות של תקשורת Ajax ב jQuery מחזירות את הסיפריה הוותיקה לחיים והופכות את השימוש בה להרבה יותר מהנה מכל API מקביל שיש בדפדפן. הראשונה היא השימוש ב Promises והשניה היכולת לקבוע Headers בצורה גלובאלית לכל בקשות התקשורת בעמוד.

המשך קריאה

איך לכתוב jQuery Plugin

28/10/2018

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

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

המשך קריאה

שלושה מנגנונים מ jQuery שהגיעו ל DOM API הסטנדרטי

27/10/2018

ספריית jQuery התחילה עם רעיון פשוט וגאוני: לבנות API טוב יותר ואמין יותר עבור ה DOM. בימים שהם התחילו המצב היה הרבה יותר גרוע ממה שהוא היום והצורך ב API אמין לחיבור בין JavaScript לאלמנטים על המסך היה מאוד בולט.

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

המשך קריאה

צעד ראשון בבטן הלוויתן

24/10/2018

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

אבל מהר מאוד עלתה שאלה יותר קשה- איך מתחילים? איך מתחילים ללמוד ריילס, או אנגולר, או CSS?

אז הלכתי ליודמי כדי לשמוע איך אנשים מלמדים CSS. שלושת הקורסים המובילים נראו כך: קורס אחד כלל 11 שעות במהלכן אתם צופים במישהו כותב דף HTML/CSS. קורס שני הציע 28 שעות וידאו והפעם המדריך כתב שני פרויקטים מלאים. הקורס השלישי נשמע לי הכי מעניין כיוון שלא כלל פרויקטים ובמקום נראה שהסביר מאוד לעומק על כל פיצ'ר מה המשמעות שלו ומתי נשתמש בו. הבעיה שזה לוקח 22 שעות של וידאו שבמהלך לא בונים כמעט שום דבר מעניין.

אבל האמת שאם מישהו ישאל אותי איך ללמוד CSS ההמלצה שלי היא על הקורס הזה של סקרימבה:

https://scrimba.com/g/gintrotocss

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

ארבע דרכים לקרוא קובץ טקסט ב Node.JS

23/10/2018

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

המשך קריאה

אימות

22/10/2018

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

כשהבעיות הופכות יותר מורכבות האימות נהיה קשה יותר אבל הרבה פעמים עדיין אפשרי. אם יש לך בעיה בקוד מקבילי שנובעת מ Race Condition בין התהליכונים השונים אז צריך יותר להתאמץ כדי לראות את הבעיה בסביבת בדיקות ואולי להוסיף המתנות יזומות כדי שמקרה הקצה באמת יקרה יותר פעמים. או אם יש לכם בעיית ביצועים בשרת רק במצב של עומס מסוים אז צריך להתאמץ ולסמלץ את אותו העומס בסביבת הבדיקות כדי שנוכל לבדוק אם השינוי שלנו פותר את הבעיה.

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

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

אני לא מאמין ששוב עשיתי את הטעות הזאת...

21/10/2018

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

import React from 'react';

class App extends React.Component {
    render() {
        return
            <div>
                Hello World
            </div>
    }
}

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

import React from 'react';

class App extends React.Component {
    render() {
        return undefined;

            <div>
                Hello World
            </div>
    }
}

הפונקציה הסתיימה בשורת ה return ואף אחד לא הגיע לקוד שמופיע אחרי.

ורק כמה ימים אחרי שהתאוששנו מההלם הזה תלמידה אחרת בקורס Linux שאלה אותי על תוכנית Awk שלא עובדת. הקוד שלה נראה בערך כך:

/^#/
{
    gsub(".", "-");
}

{
    print;
}

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

# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
# one of these shells.

/bin/bash
/bin/csh
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh
/usr/local/bin/zsh

התוצאה היתה:

# List of acceptable shells for chpass(1).
------------------------------------------
# Ftpd will not allow users to connect who are not using
--------------------------------------------------------
# one of these shells.
----------------------

---------
--------
--------
-------
---------
--------
------------------

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

/^#/ { print; }

{
  gsub(".", "-");
}

{
  print;
}

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

/^#/ {
  gsub(".", "-");
}

{
  print;
}

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