כנס המפתחים CodeMotion מגיע לראשונה לישראל ולנו יש 3 כרטיסים לחלק לכם

הדבר הכי חשוב זה ללמוד לעומק את עורך הטקסט / IDE שלך.
זה הכלי שמלווה אותך יום יום לאורך כל היום.
במעבר בין שימוש רגיל/ממוצע לשימוש מתקדם של power user אפשר לחסוך בין חצי שעה לשעה ביום, שזה בחישוב גס בערך 20 שעות בחודש או 240 שעות בשנה.
תכפילו בשכר ממוצע של מפתח.. וזה יוצא המון כסף.
חוץ מזה שלימוד הסביבה לעומק בד"כ מלווה בהיכרות עם כלים נוספים שעוזרים לשפר את קריאות הקוד והאיכות שלו.

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

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

טיפ מוצלח שאני חושב שכל מתכנת חייב להפנים, בין אם הוא פרילאנסר, ובין הוא שכיר: חייבים לשמור על כושר! נכון שכושר בריאותי נורא חשוב, אבל אני מדבר כאן על כושר טכנולוגי. מה הכוונה? העולם מתקדם מהר, וכך גם הטכנולוגיה, המתדולוגיות, הכלים מתקדמים כל כך מהר ואם לא נשמור על קצב נשאר מאחור. אם אנחנו רוצים להישאר רלוונטים, עבור החברה שלנו, עבור הלקוחות שלנו, עלינו באופן עקבי ומתמשך לתחזק את המוח שלנו ולתדלק אותו בחומרים חדשים, טכנולוגיות חדשות ותפיסות חדשות. מעבר לזה שהגדלת הידע הרוחבי שלנו בנושאים טכנולוגים שונים תגדיל פלאים את הבנה שלנו ואת הידע ב"איך העולם עובד", היא גם… Read more »

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

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

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

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

ההמלצה שלי היא עבור אנשים שנמצאים בתחילת דרכם בכל הנוגע לתכנות (אבל לא רק). בגדול מה שאני ממליץ לעשות זה תמיד שניגשים לפתור תרגיל או בעיה כלשהי, לא לעבוד ישר מול המחשב. תמיד לנסח קודם את הבעיה על דף ואת דרך האסטרטגיה הכללית שאיתה מתכוונים לפתור את הבעיה. זאת משום שהנטיה היא שכאשר עובדים מול מחשב מתחילים ישר לכתוב קוד, ובדרך כלל הדבר יוביל לקוד מבולגן ושלרוב ידרוש שינויים רבים על מנת לעבוד. בנוסף מומלץ גם לרשום את הקוד הראשוני גם על דף או בעורך טקסט פשוט ולא IDE כי אז מתרגלים לזהות שגיאות לבד וגם לומדים את הסינטקס יותר… Read more »

למי שעוד לא מכיר:

crashlytics.com
האתר הזה ישלח לכם מייל מפורט בכל פעם שקורסת אפליקציה שפיתחתם בכל מכשיר שהוא.

מומלץ מאוד.

זהו טיפ שיכול להתאים לכל משימה ולאו דווקא למשימת תכנות, זהו טיפ שכאשר מיישמים אותו הוא יכול להיות מועיל מאוד.

כאשר ישנה משימה מורכבת, הרבה פעמים אנו נוטים לדחות אותה. משום מה קשה לנו "להתניע".

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

לבסוף, מהסיבה שקשה לנו "להתניע", ברגע שכבר נכנסנו לעניינים, חשוב למנוע הסחות ככל שניתן ולהתרכז במשימה כמה שניתן.

בהצלחה.

שירות של מה אני צריך לעשות היום (to do list) ומשותף עם הקולגות :

https://trello.com

http://plnkr.co
Social Web ide

BACKUP חברים!!
עשיתם backup?? ;)

טיפש חשוב לכל המתכנתים, תפנימו שיש יותר מסוג רפרנס אחד, תלמדו את הסוגים השונים ותשתמשו בהם!
strong, soft, weak ב JAVA
strong, weak ב objective c זה יכול לפתור לכם המון המון memory leaks

המניפסט של המתכנת:

1. אם זה עובד אל תיגע
2. אם נגעת ועכשיו זה לא עובד האם אתה יכול לתקן את זה בלי שאף אחד ישים לב?
3. אם לא, תעמיד פנים שזה מעולם לא קרה ותזכור להבא את כלל 1

אמנם זה לא הכי חדשני, אבל אני מתפלא לשמוע כמה אנשים לא מכירים את זה: Source Control. אם אתם מוצאים את עצמכם מגבים את הפרויקט שלכם ע"י "Copy – Paste" בתיקיות, או מעבירים בדיסק און קים את הקוד מקור בין חברי הצוות, או הכי נורא – באטרף שאתם לא מוצאים את הגרסא האחרונה שעבדה ולא מבינים מה השתבש – מוצרי Source Control הם הפתרון! אתם יכולים כבר עכשיו תוך עשר דקות ליצור תשתית אמיתית לניהול גרסאות הפרויקט שלכם, ואם תשקיעו עוד עשר דקות אפילו לשדרג את האופן בו אתם והצוות שלכם עובדים ולעבוד על הפרויקט דרך הענן. Git, SVN –… Read more »

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

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

לעולם אל תציגו שגיאות ב-production, דבר זה עלול לגרום לפריצה לאתרכם.

אל תשכחו ';'..

חברים, טיפ של אלופים, שרק מתכנתים יכולים לבצע.
נהלו את קורות החיים שלכם בעזרת git.
מה שעשיתי זה יצרתי קובץ HTML בו אני מזין את קורות החיים שלי. מי שממש הארד קור יכול להשתמש ב-markdown במקום HTML. אני מנהל את הקובץ ב-git – כמובן שיש גם branches לפי ורייציות של סוג המשרה – לחברת סטארטאפ, בתור פרילנסר, למשרה ניהולית וכו'.
עכשיו ניתן להשתמש בתוכנה כמו pandoc על מנת לייצר קובץ pdf.

זה גאוני.

האמת גיקטיים, עזבו אותכם מכרטיס חינם לכנס, נראה לי שהגיע הזמן שאכתוב מאמר אורח בנושא…

כמה טיפים –
א. להכיר כמה שפות תכנות מפרדימגמות שונות – מרחיב אופקים וגורם לכם להיות מפתחם יתר טובים. אתם תחשבו – "אוקיי, ב clojure הייתי יכול לעשות ככה וככה" ואולי תמצאו פתרון קרוב (יחסית) בשפה שאיתם עובדים (זו רק דוגמא)
ב. בהמשך לא – בכל משימה להשתמש בשפת התכנות המתאימה ביותר – לא להתחיל להשתמש בjava על מנת לכתוב סקריפטים, ולא כדאי מצד שני לכתוב סרבר סייד ב bash :)
ג. להשתתף בקבוצות דיון על טכנולגיות וב meetups
ד. להשתמש ב opensource, לא להמציא את הגלגל מחדש, אבל לשים לב מתי opensource מסויים הוא overkill והיה אולי עדיף לכתוב לבד

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

תרמו לפרוייקטי open-source
אם אתם רוצים להישאר ב"כושר" תכנותי, ללמוד המון על הסטנדרטים המקובלים בתעשייה וגם להעשיר קצת את קוה"ח שלכם, תרמו לפרוייקטי open source. במיוחד כאלו המקובלים בתעשייה דוגמת פרוייקטים של apache וכו'.

אם לא תזכו לפחות תוכלו לקבל הנחה של 100 ש"ח באמצעות
The community for Full stack Developers קוד קופון (אמיתי…) בקישור הבא :-)
http://www.meetup.com/full-stack-developer-il/events/217299602

ה Design Pattern היחיד שתמיד עובד זה :

Common Sense

לא משנה מה הספר (Design Pattern) אומר.תתמקדו בבעיה שעומדת מולכם ותפתרו אותה. אל תפתרו בעיה דומה כי הספר נתן לכם פתרון יפה.

הייתי אומר לכו על TDD,
אבל אם מישהו רוצה באמת להשתפר, שיתחיל לכתוב בלוג.
פעם בשבוע, פעם בשבועיים. לא משנה.

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

ככל שיש פחות קוד באותה שורה, הסיכוי ל-conflict ב-merge קטן.

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

במילה אחת: coursera.

אל תנסה לקודד משהו שאתה לא מצליח להסביר במילים.
אם אתה לא מצליח להסביר בכמה משפטים פשוטים את מה שאתה הולך לקודד – כנראה שאתה לא מבין אותו מספיק טוב…

העצה שלי קצת פחות שגרתית ועזרה לי במקרים רבים:
תקראו בלוגים, ואל תתביישו.

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

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

שווה זהב.

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

הטיפ הכי טוב לדעתי,

להכיר בעובדה שאתה יכול לטעות.

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

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

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

בברכת, שכולנו נלמד מהטיפים אחד של השני ולא נחשוב ששלנו הכי טוב ;)