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

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

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

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

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

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

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

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

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

החברים שלנו מאתר tiktaklaw.com העלו טופס חדש שמאפשר לכל אחד להגיש תביעה מיידית בנושא הפרת כללי נגישות האינטרנט, ויש שמועות שכבר התחילו נסיונות סחיטה כלפי בעלי אתרים. אז בשביל שתדעו מה לכתוב בתביעה הכנתי מדריך קצר לזיהוי בעיות נגישות ב-99% מהאתרים בארץ תוך פחות מעשר דקות.

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

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

בעולם התעשייתי חברות מכרו מוצרים ומחירי מוצרים אלו יכול ללכת למעלה או למטה. למעלה כשהשוק טוב כדי להגדיל את הרווח, ולמטה כשהשוק עייף כדי למכור יותר יחידות.

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

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

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

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

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