קטגוריה: עבודה

מבחן שגוי

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

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

אבל במקום, מקבלים שאלות בנושא של TCP/IP, כיצד מסד נתונים עובדים, איך יוצרים מודולים לקרנל וכיוב'.
מה עכשיו? האם אתם מתאימים לתפקיד?

אז הגזמתי קצת, נכון? ובכן לא.

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

שאלות בנושא התפקיד להראות יכולת והבנה חשובים הרבה יותר מאשר היכולת אז אני מדבר על full stack עבור פיתוח web, הנה מבחנים טובים יותר מאשר שאלות מדמ"ח:

  1. יש לי צורך לאסוף את הנתונים הבאים – מה הסכמה למסד הנתונים שתתכנן ולמה?
  2. האם מסד נתונים מבוסס סכמה באמת מתאים לזה, או אולי מסד נתונים מסוג אחר?
  3. תן לי הדגמה מתי תבחר בdjango/rails ומתי ב sinatra/flask?
  4. מתי Go עדיפה על פיתון/רובי?
  5. מה ההבדלים בין Vue/React לבין Angular?

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

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

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

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

זו כמובן דעתי, בלבד, בהצלחה 🙂

כניסה לפרויקט קיים

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

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

התחלה

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

טעויות בכניסה לקוד/פרויקט קיים

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

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

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

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

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

הדרך שלי ללמוד

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

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

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

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

רכיבים קטנים

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

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

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

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

עבור מה השיטה לא מתאימה?

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

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

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

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

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

סליחה, יש לכם אולי זמן ללמוד טכנולוגיה חדשה ?

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

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

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

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

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

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

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

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

אם מסתכלים על הקפיצה הגדולה בין 1.8.6 ל2.1.2 אפשר לחשוב כאילו לא היה מספיק זמן להמיר דברים, אך למעשה המעבר לרובי 2.0.0 היה מאוד ארוך, ובאמצע כלל גרסאות כמו 1.8.7 שהיו הרבה שנים בתמיכה, וגם 1.9 על סדרותיו, שנתנו את האפשרות להתאים את הקוד למעבר של גרסה 2.0.0. כלומר אותו ארגון נתקע מאחור, ועכשיו הקפיצה שלו יקרה מאוד עם המון בעיות, בעוד שאם היה "זורם", העלות הכוללת היתה נמוכה בהרבה, ושורת  הרווח שלו גבוהה יותר.

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

תכנון מודלארי של מערכת

"If I had eight hours to chop down a tree, I'd spend six sharpening my ax." — Abragam Lincoln

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

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

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

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

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

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

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

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

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

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

אנטגוניזם מקצועי

יוצא לי המון פעמים לשמוע תלונות של מפתחי ווב, כמה המקצוע שלהם קשה ומסובך, כי הם צריכים לדעת Javascript, CSS, HTML, DOM, XML ובנוסף יש גם את צד השרת עם שלל הדברים שלו (וזו רק רשימה חלקית ולא מכסה את העולם).

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

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

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

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

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

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

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

האם מיקרוסופט נעלמת מהעולם העסקי ?

לאחרונה לקוח נפל בכך שהזמין מערכת ממישהו שהקים חברה על איזה קורס וחצי של פיתוח בטכנולוגיות מיקרוסופט שלקח, ואותו אדם לא הצליח לספק לו את מבוקשו.
כאשר הלקוח עוד חשב כי יקבל, ביקש ממני סיוע למצוא שרת אירוח מבוסס Windows, היות והוא היה זקוק להתקין את המערכת שאותה חברה בנתה עבורו.
אז שנינו חיפשנו משהו בסדר גודל מסויים, והמחירים שמצאנו במקרה הטוב התחילו ב50 יורו.
מיקרוסופט Azure עצמה כל כך יקרה ולא ריאלית לעסק קטן, אשר זה נפסל עוד ללא מאמץ.
אז הלקוח הזמין Windows Server 2012. וגילינו כי זה, מגיע עם ממשק של Windows 8 משום מה.
והשאלה הראשונה ששאלתי היא: למה ?

מי ירצה להריץ שרת שעובד קשה על מערכת טאבלט ? מדוע הממשק צריך להיות זהה גם כאשר מדובר בשרת ?

אבל זה לא הכל, עצם החיפוש עבור חברות המספקות מערכת ווינדוז, היה יחסית קשה למצוא, בעוד שמאוד קל, פשוט וכיום כבר זול להזמין. למשל אני עובד עם Digital Ocean (לחיצה על הקישור והזמנה דרכו יזכו אותי בכסף – אומר זאת בצורה גלויה), שרת במחיר של 10 דולר לחודש (120 דולר לשנה) והכל עובד, קל, אין בעיות, יש לי סנאפשוטים של מצבים שונים כאשר אני עושה ניסויים על המערכת, ונהנה מזה שאין לי כאבי ראש מיותרים.
הכל היה קל ופשוט מידי, בייחוד כאשר משווים זאת לאמזון, אשר הם לא ברורים במחירים שלהם, והממשק שלהם זוועתי, וכבר סיפרתי מה הם עשו לי.

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

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

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

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

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

מחדשנות לשמרנות

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

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

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

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

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

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

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

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

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

לימוד שפת רובי

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

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

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

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

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

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

האם יש צורך בQA ?

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

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

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

מי תיקח כמתכנת אצלך ?

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

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

בהרבה פורומים אני רואה את התשובה: "שפות התכנות הנפוצות הן 1,2,3,4 אז תלמד אותן". זו הטעות הכי גדולה לדעתי להגיד למישהו לעשות. היות ומה שנכון כרגע לא בהכרח נכון עוד שנתיים מהיום.
כן ללמוד גם את השפות 1,2,3,4 . הבעיה היא שזה לא "בשלוף", כי צריך להבין mindset של שפה, יותר מאשר את התחביר שלה, וזו כבר פעולה שלוקחת זמן.

אז מה כן אני מייעץ ?

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

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

למשל כבר כיום, הרבה מאוד מתכנתים בשפות כדוגמת C ו ++C אינם יודעים להתמודד עם שפות דינאמיות. הם פשוט לא מבינים אותם. זו גישה שדורשת mindset לגמרי שונה. ולכן הם לא מסוגלים לתת מענה אמיתי לעסק הזקוק להם כך סתם פתאום.
הם מסוגלים לכתוב את התחביר, אבל לא להבין את המשמעות שלו, ולמה הוא מגיע כמו שהוא מגיע. הקוד שלהם לא יכתב "בראש" השפה, אלא כקוד בסגנון C או ++C, והרבה קללות של "למה זה לא עובד לי בצורה הזו", או "אי אפשר לעשות עם זה כלום" וכיוב' …

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

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

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

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

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

מצגות בעולם הרחב של הרשת

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

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

עד היום הייתי במידת הצורך יוצר שקפים באמצעות Impress של Libre/Open Office (בהתאם לקיומם בעולם), וכבר הרבה זמן שאני חושב להתחיל לעשות את זה קצת אחרת.

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

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

אז החלטתי ללכת על משהו בין מה שגוגל מציעים לבין impress.js, ומצאתי את reveal.js.
המערכת מציעה להעביר מצגות, עם תמיכה ב html5, css3 ו javascript. אבל אינה דורשת ממני לתכנת דברים, אלא להתמקד בתוכן, וכיצד אני רוצה שהוא יוצג. למעשה התכנות שלי זה html הכי מינימליסטי בעולם. המפתח שלה אפילו חשב על תמיכה בשפות כמו עברית, ולאפשר לנו להציג הרצאה מימין לשמאל לפי בחירה.

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

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

הכנתי הדגמה נחמדה של כיצד להשתמש בreveal.js. אצלי על המחשב, היא יושבת במקום אחד, וההדגמה במקום אחר, ולכן אתם רואים את הקבצים שהם בעצם symlink למיקום שאצלי.

May the source be with you 🙂

שימוש שגוי בזמן המתכנת

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

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

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

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

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

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

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

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

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

תובנות השוק מהרצאה שהעברתי

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

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

לאחר מכן, העברתי הרצאה על No(t only) SQL. בהרצאה העברתי הסבר מה זה בגדול אומר, איך מבינים בכלל מתי, ואיך הוא מתאים לנושא, התמקדתי בMongoDB ובRedis. שני מסדי נתונים אשר אני משתמש בהם.

הדגמתי להם לפי צורות העבודה שלהם, כיצד הם יכולים לשפר להם את הביצועים, למנוע בעיות עומסים שונים וכו'

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

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

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

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

או כפי שאברהם מאסלו אמר פעם – כאשר יש בידך פטיש, הכל נראה לך מסמר
אתה פשוט לא מסוגל להבין כי לפעמים יש שימוש גם למברג, שפכטל וכו' …

Facebook do not understand their users

I've been using Facebook on and off since 2007, and have to say one thing:

Facebook do not understand their users, or how to make things right !

What does it mean, you probably ask yourself ?
Well here are some of the messages I keep on getting on Facebook in the past few months (Almost constantly): להמשיך לקרוא

עתיד עולם התכנות לאן ?

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

למשל כאשר אדם שאל שאלה בwhatsup על ללמוד לפתח אפליקציות לאנדרואיד. אנשים התחילו להציע לו ללמוד את שפת C ואת שפת ++C, וכו' … ובסוף אחרי שהבין איך לתכנת בשפות האלו, לעבור לJava אשר איתה הוא סוף כל סוף יגיע "למנוחה ולנחלה".

היות והתשובות לא היו רלוונטיות לשאלה, ודיברו איתו על ללמוד לתכנת, החלטתי להציע לו ללמוד לפתח אפליקציות אנדרואיד בעזרת FPC. אממה, אנשים ראו את המילה "פסקל" ולא הסתכלו על כך שההצעות שלי (בניגוד לקודמי) היו רלוונטיות לבקשה (כלומר דיברו על אנדרואיד במפורש), וגם בעצם עזרו בתשובות המקוריות והלא רלוונטיות, של "קודם תלמד שפת תכנות". כך למעשה התשובה שלי שילבה גם תשובה לשואל המקורי, וגם תשובה לעונים שצריך להשתמש ב gcc קודם כל, בשביל שבסוף תגיע לשפת Java ואז תלמד לתכנת לאנדרואיד.

ההבדל בהצעה שלי, הוא בכך שבאמצעות FPC, אני יכול לכתוב אפליקציות טבעיות לאנדרואיד (מהדר אותן לקבצי class של ג'אווה), ויותר מזה, אני יכול גם לבנות מערכות עבור iOS (יש בMarket של אפל, תוכנות שלמות אשר כתובות עם FPC ודלפי החדש עבור iOS), לספק את אותן המערכות לסביבות שולחנות העבודה, web ושרתים. כל זה ללא צורך להחליף שפה או טכנולוגיה, ועדיין לתת מענה רחב יותר מאשר פיתוח רק בשפת ג'אווה או Objective-C. להמשיך לקרוא

חשיבה קלקלית*

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

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

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

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

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

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

כל זה נכון לפחות בתאוריה.

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

מוקדש כחומר למחשבה

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

אתה יכול לקחת את הגמל עד לבאר, אתה לא יכול להכריח אותו לשתות …

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

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

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

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

כיוון השוק, תנועת הכלכלה

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

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

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

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

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

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

זאי ז'יאן (再見)

הצד האפל של מתודולוגיות פיתוח

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

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

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

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

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

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

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

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

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

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

הבעיה הכלכלית חברתית בישראל

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

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

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

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

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

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

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

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

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

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

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

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

שוק חופשי זה שוק בו אני כספק בודד ותאגיד יכולים להתחרות זה מול זה. דבר שלא יכול להתקיים בישראל בשנות ה2,000.

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

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

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

מה שעצוב זה, שמשנות ה80 ועד היום שום דבר לא השתנה לטובה:

דרושה טכנולוגיה חדשה לדוא"ל

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

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

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

זה נכון גם לסביבות העבודה הגרפיות כיום בלינוקס, ולא רק לעולם הדוא"ל. מאוד קשה להביא שינוי רציני בלי לדרוך לאנשים על הרגליים, ולהציג להם תפיסה שונה. הרי OS2 של IBM די הכתיב לנו את הגישה שאנחנו רובינו רגילים אליה כיום. וזה "שולחן עבודה", עם כפתור "התחל" (או כל איקון/שם אחר). אבל מי זוכר את OS2 ? הרי הם אלו שעשו את המהפכה הזו, אבל רק מיקרוסופט היא זו שזכתה להצלחה על ידי ביצוע copy paste בצורה די כושלת עם windows 95.

ד"א את קוד המקור של google wave אפשר למצוא כאן.

מוקדש כחומר למחשבה.

מה לדעת לפני שאתם פותחים עסק בפעם הראשונה

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

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

ישנם 4 סוגי עסקים שאתם יכולים לפתוח בנושא התכנה (ישנם קצת יותר בישראל, אבל הם בנויים למקצועות שונים כדוגמת עריכת דין וכו'): להמשיך לקרוא

עצור: עסקים קטנים בישראל

The first mistake in public business is the going into it
Ben Franklin

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

  • אני מחוייב לשלם ביטוח לאומי, אבל אני לא מבוטח בו
  • אני מחוייב לשלם הרבה מיסים על דברים, אבל המדינה לא מתחייבת לי שכל רכש שלי יהיה מוכר כהוצאה. יותר מזה, הוצאות כמו רכב מוכרות רק חלקית בלבד.
  • אין לי משרד, והרבה פגישות נעשות בבתי קפה – הוצאה שלא מוכרת על ידי הרשויות
  • אם מחר למרות חוזה חתום, שבו מתחייב לקוח לשלם לי על שוטף, והוא מחליט על דעת עצמו לשלם שוטף+90 (במקרה הטוב, במקרה הרע מחליט לא לשלם) אין חוק שמגן עלי, ולרוב בתי המשפט יכריחו את החייב לשלם (במקרה הטוב) רק חצי מהסכום (קרה ליותר מבעל עסק אחד שאני מכיר)
  • אם אני מרוויח 20,000 ש"ח בחודש (או פחות), לא אקבל שום הנחות במס.
  • אם ארוויח 200,000 כל חודש, אקבל הרבה הנחות במס. למעשה אוכל לנהל משא ומתן על גובה המס שאשלם
  • עסק יכול לשים ווטו ולהגיד כי רק אם אתן לו חשבונית מס הוא ישלם לי כסף. אין שום גורם שעוזר לי מול זה. זה אומר אבל שאני משלם מע"מ, למרות שלא נכנס לי אפילו אגורה אחת מהעסקה בפועל.

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

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

מי שנכנס לעולם העסקים, נכנס לשדה קרב קשה מאוד, וכל יום יש בו הרבה מאוד צלקות חדשות. לרוב אותו אדם נמצא לגמרי לבד בהתמודדות עם ההשלכות בנושא ולכן הרבה מרימים ידיים ב5 שנים הראשונות, ואח"כ ב5 שנים הבאות (מבחינה סטטיסטית). עסק יכול להיות רווחי כל הזמן, אבל ללא תזרים מזמנים, אין לשום עסק יכולת להצליח להתקיים. כלומר אם חייבים לי עכשיו 100,000 ש"ח חובות. וכל ההוצאות שלי הם 30,000 ש"ח. אחרי נקודת איזון (כלומר הכנסות פחות הוצאות), אני רווחי. לפחות על הנייר. אבל אין לי באמת 100,000. מה שיש לי זו הבטחה שאולי יהיה לי 100,000 ש"ח. וזו בעיית התזרים שהורגת עסקים. ואין שום דבר כאמור בישראל שמגן על עסק מפני הבעיות האלו.

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

הרי מה שארוויח בשנה מההצעה האחרונה שקיבלתי, יהיה הרבה יותר מאלו אשר מנסים לרכוש את ה"עסק" שלי (כלומר אותי ובעיקר את הלקוחות שלי) עד עכשיו …

מוקדש כתמרור אזהרה

לכתוב מחדש

Leaning Tower of Pisaהנה שאלה מאוד מטרידה: "למה אף פעם אין זמן לעשות דברים כמו שצריך, אבל תמיד יש זמן לעשות דברים מחדש ?"

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

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

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

אז מדוע אף פעם אין זמן לעשות דברים כמו שצריך, אבל יש זמן לעשות אותם מחדש ?

ניהול פרוייקטי תכנה

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

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

נקודת מבט עסקית

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

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

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

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

השוק מורכב ממספר מרכיבים: עלויות יצור (חומרים, שעות עבודה של עובדים וכו'), עלויות נלוות (חשמל, מים, ציוד וכו'), עלויות עקיפות (מחקר, פטנטים, הסכמים שונים, רשיונות, ארנונה, אגרת שילוט, פרסומות וכו') וכוחות השוק. נגיד ולוקח לי ללא מבט כלשהו מעבר לעלות היצור, 10 ש"ח ל50,000 כדורי אקמול. כאן אני צריך לראות מה עוד העלויות שיש לי, ובנוסף כמה רווח אני רוצה להרוויח וזה בנוסף לכמה הלקוח הסופי מוכן לשלם. כלומר אם הלקוח הסופי לא ישלם לי מעבר ל20 ש"ח, והעלויות המלאות של היצור הם 50 ש"ח פר לקוח, אז אני מפסיד כסף ולא שווה לי לייצר אקמול, אלא אם אני מוכר עוד דברים שהרווח מהם הוא לפחות 200 אחוז, שהם יכסו את ההפסדים על האקמול, בזמן שאני רק מרוויח פחות אבל לא מפסיד כסף.

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

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

דרושים: פרילנסרים בתחום Linux System

אני מתמחה בעולם Voice Over IP, ובונה מערכות מיוחדות על גבי מרכזיית Asterisk.

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

הידע שאני מחפש הוא בעיקר בתחום ה System – כלומר הבנה של שרתים, רשתות וכו', ופחות בתחום של Asterisk, אבל גם ידע כזה חשוב.

הפעולות הנדרשות הם:

  • קריאה וניתוח של לוגים
  • הבנת הבעיות שיש ללקוחות
  • במידת האפשר, גם לפתור את הבעיות, או להציף אותם גבוה יותר (אלי)
  • יכולת לתקשר באנגלית
  • יכולת עבודה ישירה מול לקוחות (אשר אינם יודעים לינוקס ולפעמים גם לא טכניים בכלל)

העבודה נעשת רק מרחוק, כלומר באמצעות חיבורי VPN ו ssh.

אם יש אנשים שמעוניינים, תוכלו ליצור איתי קשר באמצעות:

idok at@at linesip dot.dot com

ואסה

בשל מסמר הפרסה נאבדה
בשל מחסור בפרסה, אבד הסוס
בשל איבוד הסוס, הרוכב אבד
בשל איבוד הרוכב, הקרב הופסד
בשל הפסד הקרב, הממלכה נהרסה
והכל בגלל מסמר

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

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

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

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

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

מוקדש למנהלי פרוייקטים ולמנהלים/לקוחות באשר הם.

דרושים: מתכנתי רובי בישראל

אתמול היה אירוע מדהים שארגנה חברת fiverr הישראלית, לאנשי רובי (ובעיקר rails) בישראל. בין האנשים שהגיעו היו גם אנשי SAP, אשר גם הם מפתחים בארץ ב Rails, ועוד מספר אנשים מחברות שונות כולל LINESIP כמובן (אני) 🙂

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

בSAP למשל יש בסביבות 30 מפתחי Rails בישראל (כמות המפתחים הגדולה ביותר בישראל עבור Rails במקום בודד) במספר צוותים והם מחפשים עוד עובדים. גם שאר החברות מחפשות עוד עובדים שיודעים לעבוד ב Rails, וכולם מתחרים על אותו משאב של מתכנתים קטן שיש. משיחות עם אנשי SAP למינהם, הבנתי שאני צודק בכך שאני אומר שיש יותר מידי באזז על פיתון ובכלל לא שומעים רובי, למרות שרובי נמצאת בהמון מקומות בעולם הגדול (כמובן שאי אפשר להשוות את הבאז של פיתון מול .NET). למעשה כולכם כאן מכירים אתרים שכתובים ברובי ו Rails גם אם אתם לא יודעים שזו הטכנולוגיה מאחורה – עדיין אין את הקישור לכך שיש הרבה עבודה עם רובי ו Rails בעולם ויש ביקוש לשפה ולאנשים שמכירים את Rails – גם בארץ. וכרגע בארץ זה עובד יותר על "חבר מביא חבר", ופחות פרסום רשמי, אבל בעולם יש הרבה מודעות דרושים למתכנתי רובי ו Rails.

המצב הוא כל כך חמור שלמשל ב SAP התחילו להמיר אנשי Java לרובי, וזה בערך כמו לקחת אנשים שעובדים בבניין שיעבדו ביצור מכוניות. הדרישות הן שונות מבחינת תפיסת עולם והבנה של מה שצריך, ולא בגלל שהאנשים לא מסוגלים לעשות את זה. פשוט תפיסת העולם שונה לגמרי בין השפות. כך ששמעתי משפטים כמו "רובי זו שפה מאוד איטית" מאיש שעבד במקור עם ג'אווה. העניין הוא שרובי היא שפה, ואין לה קשר למהירות, אלא רק למימוש של המפרשים השונים יש הבדל. למשל MRI בגרסה 1.8 ומטה מאוד איטית, וMRI 1.9.2 מהירה הרבה יותר, וJRuby עם bootstrap מאוד איטי בגלל JVM, אבל היא מהירה יותר מ MRI 1.8, כך שזו לא השפה, אלא המימוש של המפרש.

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

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

השורה התחתונה היא, שהאינטרס של כולנו כאנשי קוד פתוח הוא שיהיו פחות מפתחי #C ו .NET ויותר משתמשים בכלי קוד פתוח ותכונה חופשית, אז אני בעד עידוד השימוש בשפת רובי.

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

מה כלי העבודה שלך ?

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

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

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

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

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

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

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

האם אתם אי פעם עשיתם הפסקה וחשבתם בעצם מה אתם חייבים בשביל לבצע את העבודה שלכם ובלעדיה לא תוכלו לעשות שום דבר ?

הגנה על מערכות VoIP

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

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

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

  • טלפוניה (ללא קשר לסוג המערכת) רגישה להתקפות כדוגמת Man In The Middle – כלומר מחשב באמצע התעבורה באיזשהו צד יכול לעשות נזק לשיחה או רק להאזין לה בברירת מחדל.
  • טלפוניה רגישה להתקפות כדוגמת DoS – כלומר מניעת שירות. זה יכול להיות מניתוקים רבים של כל בקשה ליצירת שיחה, זה יכול להיות הרבה התקשרויות מעבר למה שהקו או המרכזייה מסוגלים לטפל, זה יכול להיות עוד הרבה דברים שימנעו שימוש בטלפון אצלכם בארגון.
  • ניתוב לא נכון יכול לעלות לארגון הרבה כסף. נגיד שיחות לחו"ל, שיחות למספרים "אסורים" (שעולים הרבה כסף) וכו' יכולים לגרום לכם להיות קורבנות של גניבת שיחות.
  • מתן גישה לכל דורש למרכזייה אומר שאפשר לעשות כל מה שרוצים בה.

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

  1. כל התקשורת מ ואל המרכזייה מתבצעת רק מהרשת המקומית של הארגון.
  2. כל תקשורת יוצאת ונכנסת חייבת להיכנס דרך VPN מוצפן.
  3. ספקי SIP או VoIP חיצוניים צריכים להיות מאושרים לגשת למרכזייה ברמת ה IP שלהם ורק לפורטים הספציפיים שהם עבור SIP: פורט 5060 ועבור תעבורת המידע של RTP ו SDP בטווח של 10,000 עד 20,000 פורטים. שיטת התקשורת היא UDP.
  4. בתוך הארגון אפשרו למרכזייה להיות ברשת משל עצמה (VLAN) ותגבילו גישה רק לMac Address ידוע של טלפונים מורשים בנוסף לכתובות IP סטטיות מוקצות מראש עבור כל טלפון וטלפון.

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

כמו כן, תוכלו למצוא עוד יעוץ בנושא אצלי בעסק.

25 דקות של משימה

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

אז במקרה גיליתי עגבניה (Pomodoro) מסוימת ב n900 שאמורה לעזור לנהל זמן ויש לנו לכל משימה שאנחנו רוצים לנהל זמן של 25 דקות לפני המעבר למשימה הבאה.

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

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

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

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

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

להיות יזם …

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

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

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

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

אח"כ אולי תצליחו להבין טוב יותר את השיר של מטאליקה: The Unforgiven

מרוב תקלות ואבסורד לא רואים את היער

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

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

אחרי שהצלחתי להבין כי לשם שינוי הוט היו בסדר (זה לא דבר שקורה הרבה אני חייב לציין), ישבתי והתחלתי לחקור את הנושא ב4 רמות שונות. כאשר הכל נכשל, החלטתי לעשות test case ואז גיליתי את הגורם לבעיה. לאחר מכן דיווחתי על זה באג, והאדם האמון על הנושא שקשור לבאג הזה, היה עם אצבע מהירה על ה"סגור" וסיפק תחושה בסגנון של "עזוב אותי באימשך, מה אתה מדווח באגים, זה בכלל פיטצ'ר". בזכות צפריר הבאג נפתח שוב, אבל היות וכל המידע בפנים, ורק צריך לעשות copy paste למה שכתבתי ולקבל את הבאג, אין לי הרבה מה להוסיף, אבל האדם שאחראי על הבאג יותר מעניין אותו הכותרת ששמתי לבאג מאשר כל המידע ששפכתי על הבאג לאחר הכותרת.

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

איך משווים בין מחורזות בג'אווה (הנה כמה אפשרויות) ?

"a" == "a"

"a".equals("a")

"a".compare("a")

ובכן, 2 השורות הראשונות זהות, והן מבצעות השווה של האם instance זהה. התשובה השלישית היא התשובה שאנחנו מחפשים לביצוע השוואה של מחרוזות.

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

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

יש לי לקוח אשר מחזיק router + ips בכלי אחד של Fortigate. יש לי כמה שרתי לינוקס אצלו ברשת (למעשה שרתים שלו שאני היחיד שנוגע בהם) והשאר זה הכל Windows. נטוויז'ן שמנהלים לו את הכלי הזה, החליטו ש ssh זה פרוטוקול לא מאובטח ולכן אני מחוייב להתחבר ב ssl vpn ואז משם אני יכול להתחבר לאן שאני רוצה ברשת, אם זה rdp או ssh.

כמה בעיות בגישה הזו:

  1. שניהם עובדים על אותו סוג מנהרה
  2. אני עדיין יכול לעשות מה שאני רוצה בתוך הרשת שלו
  3. יש לי עוד שכבה שיכולה/עושה בעיות ומאיטה את הרשת
  4. בשניהם אפשר להחליט איזו סוג הצפנה (עד כמה שאני יודע) אפשר להשתמש
  5. ב ssh אפשר לשים עוד כמה הגנות שאני לא יודע אם אפשר להכניס אותם ל ssl vpn

ככה שאני מאמין בלב שלם שנטוויז'ן טועים בקטע הזה.

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

פרישת תוכנה ללקוח

זהירות !!!!1

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

שרת יציב וטוב

בעולם השרתים ישנם הרבה מתמודדים גם בחומרה וגם בתוכנה.

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

להמשיך לקרוא

חופש מזמינות – האם אתם מוכנים לזה ?

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

אני לא באמת אוהב לדבר… אבל מה לעשות שהעולם שלנו אוהב שיחות בין אנשים… ואנשים בטוחים שאני חייב להיות זמין 24/7, הרי זה טבעי נכון ?

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

היה לי גם טלפון סלולרי מהעבודה במקום האחרון שעבדתי בו, שבו הוא כמובן בשביל לתת ללקוחות (ובעיקר לבוסים) אפשרות למצוא אותי זמין 24/7. אבל אחרי שלקוח של החברה צלצל אלי ב3 לפנות בוקר רק בשביל לגלות שאני האדם הלא נכון לעזור לו, הבנתי שאני חייב לסגור את הטלפון כאשר אני הולך לישון, ולפתוח אותו שוב רק כאשר אני מגיע לעבודה ! אבל גם זה לא היה מספיק טוב, כי היו לי כמה ימים שאחרי שיצאתי ב9 בערב מהעבודה (12 שעות אחרי שהגעתי אליה) עוד מצאתי את עצמי עובד עוד קרוב ל5 שעות רק בגלל הטלפון… מה אי אפשר לנוח לישון, לנקות את הראש ? מה אני חייב להיות זמין כל הזמן ?!

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

לאחרונה יצא לי לטפל בבעיות של לקוח, והדבר דרש ממני להיות בקשר רב עם חברת HOT עסקים ומחלקת הPRI שלהם. אני לא אספר בדיוק מה קרה ואיך.. אבל מצאתי את עצמי מחייג הרבה מאוד למספר 1-800 של החברה… מספר חינם נכון ? אז זהו שבטלפון הסלולרי לפחות בחברת פרטנר, זה מחוייב במחיר "מוזל" של 0.25 אגורות לדקה. אותו מספר שHOT משלמת עליו, גם אני משלם עליו "מחיר מוזל". פשוט לא הגיוני…
אני באמת שוקל פעם אחת ולתמיד פשוט להתנתק. לרכוש קו "פשוט" מבזק ושזו תהיה הדרך להשיג אותי בלבד. עכשיו רק צריך לגרום לניידות מספרים, ולהעביר אותם לכל מערך הטלפוניה בארץ ולא רק בין חברות הסלולר, וזהו, אנחנו מסודרים.

פיתוח חוצה פלטפורמות באמצעות Free Pascal 2.2.0

תרגום מהגרסה האנגלית לכתבה שפורסמה בOSNews ע"י Joost van der Sluis
תורגם ע"י עידו קנר

לאחרונה Free Pascal (FPC) שחררה את הגרסה 2.2.0. מהדר הקוד הפתוח לשפת פסקל אשר ממשיך מאז התחיל ב-1993 לגדול ולהיות אחד ממהדרי הקוד הפתוח הכי מתוחכמים הקיימים כיום. מדי יום מפתחים רבים מגלים את FPC ומפתחים את התכנות שלהם באמצעות פסקל מונחה עצמים. הפיתוח של Lazarus תרם לכך באופן מיוחד: Lazarus היא סביבת עבודה משולבת גרפית עבור FPC, עם כלי פיתוח רבים לפיתוח ותכנון תכנות גרפיות.
להמשיך לקרוא

משחק המונופול של המשק הישראלי

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

להמשיך לקרוא

שולחן העבודה הוא מקום מסוכן לצפות על העולם

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

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

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

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

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

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

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

סתם עוד חומר למחשבה