בפוסט הזה יש מכל הבא ליד – גישות תכנות, מתכנתים נטולי תואר, תכנות בסוף שנות ה-60, ועוד כיפים. עשרה נושאים שונים שהתקבצו בפוסט אחד
AMP – המושג הזה, Accelerated Mobile Pages, נטבע לפני 4 שנים ע”י גוגל. אני עוד לא מצאתי את הצורך להשתמש בזה, אבל לאחרונה קראתי פוסט מעניין שמסביר לעומק אבל בצורה מעניינת מה זה AMP, ולמה זה טוב. יש שם סרטונים קצרים שמסבירים איך AMP גורם לאתרים לעלות מהר יותר, איך לעשות ולידציה לעמודים כאלה, קשינג, ועוד. נראה כמו מקום טוב להתחיל ממנו. אולי זה יקרה לי יום אחד 🙂 .
OOP נחשב לעתים קרובות כמתודה מוצלחת לכתיבת קוד (פעמים רבות קראתי ביקורות על וורדפרס בגלל שהיא לא OOP). כאן יש מאמר ארוך ואינטלגנטי על למה OOP הוא גישת תכנות לא מוצלחת. אני אוהבת לקרוא מאמרי דעה, בעיקר עם דעות לא שגרתיות ואף מרדניות. מקווה שגם אתם תאהבו.
אתר שמאגד ראיונות עם אנשים שהצליחו בעולם התוכנה בלי שיש להם תואר במדעי המחשב. זה קונספט מעניין, לאגוד אנשים בעלי המכנה המשותף הזה, ואני אוהבת ראיונות, ועוד עם אנשי תכנות, אז לכן אני משתפת גם אתכם בזה.
אתר שאני רוצה לחזור אליו כשיהיה לי זמן: ספר על איך ללמד טכנולוגיה.
אוטומציה לתהליכים שחוזרים על עצמם היא תמיד רצויה אבל לא תמיד מצויה. הפוסט הזה מציע דרך אחרת להתמודד עם תהליכים כאלה – שכוללים פרטים רבים ודורשים תשומת לב אבל הם משעממים – בלי להצטרך ליצור אוטומציה: סקריפט שמלווה את המשתמש בכל שלב ומזכיר לו מה עליו לעשות כעת. כלומר הסקריפט לא ממש עושה את העבודה, הוא רק מלווה את מי שכן. כך אפשר לעשות את הפעולות בלי להקדיש הרבה תשומת לב אבל בלי לחשוש שאחד השלבים יישמט בתהליך.
המתכנת השוודי הזה מראיין את אימא שלו, מתכנתת מצד עצמה, על איך היה לתכנת ב-1969. מעניין מאוד לקרוא, גם בגלל עצם התוכן, וגם בגלל הסגנון השוודי שהוא אמנם קצת נוקשה אבל יש לו חן משלו.
פוסט קצר על פונקציות שמייצרות מספרים רנדומליים, ועל מידת הרנדומליות שלהם. נשמע קצת חופר אבל הוא דווקא כתוב די בתמצות.
כלי בשם Storytime שהופך את התיעוד של הקוד לסיפור שמופעל בלחיצת כפתור. יש כפתור play ולחיצה עליו מראה את כל הקוד, ואז עוברים על כל שורה, ואם יש שם הערה – היא מופיעה.
ראיון הפוך: רשימת שאלות שתרצו לשאול את החברה שבה אתם הולכים להתראיין. זה כולל שאלות על תהליכי עבודה, על הצוות, על גבולות ואחריות, ועוד דברים חשובים במקום העבודה שאנחנו לא תמיד חושבים עליהם לפני שמתקבלים.
פוסט מהבלוג של StackOverflow על הסיבות שבגללן מפתחים אמורים דווקא לאהוב הערכות זמן. הפוסט נותן רשימת חוקים להערכות זמן: להעריך רק כשמבינים בדיוק את הפונקציונליות הנדרשת; להעריך מתוך איפיון; אם האיפיון יש חלקים חסרים או סימני שאלה – לא להעריך את החלקים האלה; לא לנסות לכווץ את הערכת הזמן כך שתתאים לתאריך מסוים אלא להפחית פיצ’רים; מותר לתת טווח של הערכות זמנים מלוות בסולם הסתברות, ועוד. מטבע הדברים בנושא שכה נוגע לכולם, יש הרבה תגובות.
