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