טיפים קצרים וחדשות למתכנתים
בתחילת השנה מייקל וסטרט התחיל לפרסם ספריית קוד פתוח חדשה לעבודה עם Immutable Data Structures. הספריה נקראת Immer ומאז הפכה לפיתרון יציב ואף זכתה לברכות מדן אברמוב. בואו ניקח כמה דוגמאות כדי להבין מהי ובמה היא טובה יותר מ Immutable.JS הוותיקה.
בתור מתכנתים מאוד קשה לנו לראות את האפקט של כל שורת קוד על ביצועי המערכת או לדמיין איך שורה מסוימת תעמוד בעומס. קבלו כמה טיפים שיעזרו לכתוב קוד חזק יותר ולמצוא מהר יותר את הטעויות.
אחת הבעיות עם ענפים שחיים יותר מדי זמן היא שככל שעובר יותר זמן בין הפיצול מהענף הראשי למיזוג חזרה, כך שני הענפים מתרחקים יותר אחד מהשני ונוצרים קונפליקטים בקוד שלהם. הפקודה יכולה לעזור לנו להתמודד עם קונפליקטים אלה ולהשתלב טוב בשיטת עבודה נקייה יותר.
לולאות בתכנות פונקציונאלי בנויות אחרת מאשר לולאות של תכנות אימפרטיבי מאחר ותפקידן לעזור לנו להתמקד בפונקציה והקלט שלה. בואו נראה את ההבדל ומה הופך לולאה לפונקציונאלית.
כשהתחלתי ללכת למפגשים של קבוצת מתכנתי perl כבר במפגש השני בו השתתפתי אמר לי סויר שהמדיניות אצלם זה שאין דבר כזה אורחים. אם אתה בא אתה צריך לדבר. בפעם השלישית כבר עליתי על הבמה וההרצאות שהעברתי שם חיזקו את הידע שלי בשפה יותר מכל מיטאפ אחר שהייתי בו.
אחרי שלושה חודשים של וובינרים אני שמח לספר שהחודש את רוב הוובינרים תעבירו אתם. אנשים שמוכנים לקחת את הסיכון, לעמוד מול קהל (וירטואלי - אבל עדיין אנשים אמיתיים) ולשתף מהידע שלהם. אנשים שמוכנים להתאמץ כדי ללמוד ולהשתפר.
ואני בטוח שבעמידה (או ישיבה) שלכם עם המיקרופון יהיו רגעים מלחיצים, יהיו רגעים שלא בדיוק תדעו מה לענות ויהיו רגעים שתרצו להפסיק את ההקלטה ולברוח. אני יודע שלי יש כאלה. ואחרי כל שעה כזו אני שמח שסיימתי אותה והולך לקרוא על כל הנושאים שלא ידעתי להתיחס אליהם.
אז ההצעה שלי למנוי שנתי באתר לכל מי שמעביר או מעבירה כאן וובינר עדיין בתוקף ותישאר כך. ועכשיו תורכם: שלחו מייל או השאירו פרטים בדף צור קשר. מבטיח לעזור להתכונן, ומבטיח שלא תתחרטו.
תשתיות פיתוח עמוד-יחיד מודרניות משתמשות לפעמים בסימן סולמית כדי לדעת באיזה עמוד אנחנו נמצאים. מאיפה הגיע, למה צריך אותו והאם אפשר בלעדיו? טוב ששאלתם.
לא משנה מה הבעיה שמולכם - כמעט תמיד אפשר למצוא יותר מגישה אחת לפיתרון. וכמעט תמיד לכל גישה יהיו את היתרונות והחסרונות שלה ואת האתגרים שלה, וכמעט תמיד לא משנה באיזה גישה תבחרו תצטרכו לעבור כמה מכשולים לא פשוטים בכלל עד שהתוכנית תעבוד כמו שצריך.
אנגולר או ריאקט? מיקרו סרביסס או מונולית? אפליקציה או אתר? שרת ייעודי או Serverless?
כן כנראה אחת הדרכים היא קצת יותר טובה מהשניה, אבל גם כנראה שאין לכם כרגע מספיק נתונים כדי לדעת איזה.
במקום לבזבז זמן על חיפושים קחו את זו שאתם יודעים איך להתקדם בה ותתחילו משם. אחרי שהקוד יעבוד יהיה לנו הרבה יותר קל לשכתב או לשפר אותו.
נ.ב. אני עדיין פותר עם חברים את Advent Of Code האחרון, בקבוצת לימוד באווירה טובה ובעברית. אם אתם רוצים דרך בטוחה לשפר את מיומנויות התכנות שלכם דרך פיתרון בעיות מדליקות ועזרה לחברים בבעיות אלה מוזמנים בחום להצטרף. החידה הנוכחית מחכה לכם כאן:
מה שמבדיל בין מתכנתים שיודעים גיט לכאלה שקראו איזה מדריך מקוצר הוא היכולת להתאושש מטעויות. וככל שתעבדו יותר בגיט כך תלמדו שלפעמים טעויות שנראות פשוטות ממש מחייבות צעדים דרסטיים כדי להתאושש מהן. כך המקרה של פיצול פרויקט.
השבוע פרסמתי כאן השוואה בין קוד פרוצדורלי לקוד פונקציונאלי. הקוד היה כתוב ב Ruby ו Elixir וחלק מהקוראים חשבו שיהיה יותר מעניין לראות השוואה דומה בשפה שמכירים. אז הלכתי לכתוב את אותו הקוד ב JavaScript והתוצאה תעזור לנו להאיר עוד פינה בייחודיות של שפות פונקציונאליות.
כלל ידוע בגיט הוא שלא כדאי לשמור שם מידע רגיש כי מי יודע מתי תשכחו את תיקיית .git שלכם על איזה שרת ציבורי. אבל לפעמים בכל זאת אנחנו בטעות מוסיפים מידע רגיש לגיט ואז צריך באיזושהי דרך למחוק אותו. ואל תחשבו אפילו על git rm כי הוא אולי ימחק החל מהקומיט הנוכחי אבל עדיין יש לכם את המידע הרגיש בכל ההיסטוריה. בואו נדבר על פקודה הרבה יותר מתוחכמת בשם git filter branch והיכולת המופלאה שלה לשנות את כל ההיסטוריה.