אני לא חובב כדורגל גדול, אבל עקב אחוזי הצפיה בבית, ועם סיום שלב הבתים התחלתי להראות קצת יותר התעניינות מהרגיל בנעשה במונדיאל.
כדי לעקוב אחרי המשחקים בכל יום, הכנתי מודול קטן לMagicMirror
את הנתונים אני לוקח מאתר כאן 11
המעוניינים יכולים להוריד ולנסות MMM-Mondeal
TL;DR It’s all about the User eXperience, design and making software fit you, and not the other way around.
I’m an amateur radio operator. as all hams, we are required to save a log of our contacts with other people. besides the legalities, it’s nice to have a record of places & people I’ve talked with. when I’ve started my hobby, some 30 years back, I received a paper logbook which I’ve been using untill recently, and I’ve been very happy with it.
I’ve been thinking of using a computerized logbook software, but to be honest, I really had no incentive. pen and paper were good enough for me. plus, the ones I’ve tried to use (out of the thousands out there) left me with a horrible experience. i consider my self as a savvy computer user, but most of the programs I’ve tried had a “designed by an engineer” look and feel, which in this day and age is simply a crime.
Continue reading why i decided to write yet another ham radio logbook software
לפני מספר ימים פרסם חבר טוב סרטון ביוטיוב שבו הוא מדגים שימוש בפונקצית yield אשר מוחבאת בתוך פקודת delay כדי להריץ שתיי משימות במקביל.
גם מיקום הקריאה, וגם המינוח yield (״תן זכות קדימה״ בתרגום חופשי) עוררו בי את החשד שמדובר בתשתית למתזמן (scheduler) עבור מערכת הפעלה. חיפוש קצר באינטרנט אישר את החשד. מדובר בספרית ריבוי משימות, אך כרגע רק לארכיטקטורות 32 ביט של ATMEL ולכן מוגבל בלוחות שנתמכים.
רציתי לכתוב גרסא גם למעבדי הAVR, ולכן התחלתי לקרוא יותר על הארכיטקטורה שלו. תוך כדי מצאתי מימוש שמישהו כתב גם למעבדים ה״רגילים״. המימוש של שנינו דומה מאוד, כך שעבודת הבדיקה נחסכה ממני. אנסה להסביר כיצד זה עובד… Continue reading ריבוי משימות בארדואינו
I’ve been playing around with MagicMirror², and ended up jotting down a few modules of my own.
first was MMM-DailyWeather – which is the missing link between the default CurrentWeather and WeatherForecast. it shows the upcoming weather for the next 24 hour in 6 hour intervals and helps the fashion aware people in the house better prepare their look to the temperature outside.
כבר הרבה זמן שאשתי מבקשת שיהיה לנו איך לשמוע מוסיקה בסלון. הבעיה למעשה התחילה עוד לפני הרבה שנים כשזנחתי את אוסף הדיסקים והעברתי את כולו לקבצים במחשב. מהסיבה הזו הרמקולים הטובים בבית (של bose) היו אלו שמחוברים למחשב. עד לאחרונה שולחן העבודה שלי ועליו המחשב היו בפינת הסלון וכך לא היתה בעיה לשמוע מוסיקה בכל הבית.
אבל בדירה הנוכחית, הוגליתי לעבוד בממד. את הרמקולים העברתי בשמחה למזנון בסלון, אבל לאן בעצם אפשר לחבר אותם ? יש לי מחשב בסלון ששימש בעבר כסטרימר, והיום משמש כשרת מדיה. אבל לא הצלחתי למצוא לו ממשק נוח ואמין שיהיה קביל על בנות הבית. אז נשארנו עם חוט של אוזניות שחיברנו לטלפונים או ללפטופ מזדמן. אבל זה ממש לא לעניין. התחלתי לברר על מקלט bluetooth זול, ואז הכה בי רעיון. למה לא לקנות amazon echo???
It was a sleepless night, when I first learned of the lean manufacturing idea. just arriving back from the US, I was fighting the jet lag by watching random programs on the history channel. then came a program about the car production lines, which overall is a fascinating subject (and if you think otherwise, then there is something is terribly wrong with you)
what caught my attention was the problems that Mr. Toyota encountered when studying Henry Ford’s production plant. while Mr. Ford could sell cars “painted any color he wants as long as it’s black”, then Mr. Toyota had to make small quantities of various types and models. My production manager used to frequently complain: “every day you ask me to make a product with different color pom-poms”. manufacturing people naturally like to create production line a-la Henry Ford (who actually took many of his ideas from Eli Whitney) Continue reading lean software development (english version)
לרעיונות של היצור הרזה נחשפתי לילה אחד בעודי נלחם בג׳טלג שלאחר טיסה וצפיה אל תוך הלילה בערוץ ההיסטוריה. ההתפתחות של קו היצור למכוניות הוא נושא מרתק מהרבה בחינות (ואם אתם לא חושבים ככה, אז משהו אצלכם לא בסדר).
מה שהקפיץ אותי ממרבצי היה תיאור הבעיות שבהן ניתקל מר טויוטה כשבא ללמוד אצל הנרי פורד. בעוד הנרי פורד היה יכול למכור מכוניות “בכל צבע כל עוד הוא שחור”, הרי שטויטה נאלץ לייצר מגוון רחב של דגמים וסוגי רכבים. או כמו שמנהל הייצור שלי היה קורא לזה “כל יום אתם מבקשים ממני לייצר מוצר עם פונפון בצבע אחר”. הנטייה הטבעית של אנשי תפעול היא לנטות לקו יצור סידרתי מבית מדרשו של פורד (שאגב לקח הרבה מהרעיונות מאיליי וויטני).
אחד המקרים התדירים שפוגשים כמנהל הוא כששני מנהלי מחלקות לא מסכימים בינהם.
לא שתמיד אמורים להגיע להבנה, ובסופו של דבר תפקידו של המנכ״ל הוא לקבל את ההחלטות שאף אחד אחר לא יכול או רוצה לקבל. אבל יש בעיה עקרונית ומתסכלת מתחת לדברים. אנסה לתאר מקרה דימיוני אך מייצג.
ראשון נכנס בהיסטריה מנהל התיפעול: ״מה הם חושבים לעצמם? שאני יכול להכין מהיום למחר מוצר לא סטנדרטי? אני לא יכול להחזיק מלאי של הכל. עכשיו אני צריך לטרטר את הספקים שלנו בהיסטריה, להכין תעוד… וכו וכו וכו״
ישר אחרי זה היה נכנס איש המכירות כולו אדום מכעס: ״אני עובד כבר חודשים על העסקה הזו. זה לקוח גדול וחשוב ומה שהוא מבקש זה חשוב. מאיפה הם חושבים מגיע הכסף אם לא נמכור כמה שרק אפשר?״
כמובן ששניהם צודקים. Continue reading הם לא מבינים
בחלק הראשון כתבתי על הכלים ששימשו אותי בכתיבת אפליקצית רשת. בחלק הזה אנסה לסקור את שיטות העבודה ששימשו אותי בתהליך.
בכל פעם שמפיצים תוכנה עוברים את התהליך של גילוי ותיקון שגיאות. כשהתוכנה היא אתר באינטרנט התהליך הזה עובר האצה רצינית.
כל אחד מאיתנו מכיר את הטלפון הזה. מהעבר השני צרחות עד השמים, צמרמורת קרה עוברת בגו ובעיקר המחשבה הטורדנית “איך לא בדקנו כזה דבר טרוויאלי ?”
התשובה מורכבת בדרך כלל מלפחות אחת מהתרוצים הבאים :
אני קורא להם תירוצים, אפילו שזה ירגיז הרבה אנשים, מכיוון שלדעתי הדבר נובע משילוב של חוסר ידע וסתם עצלנות (ובואו נודה שתכנתים, ואני כולל את עצמי בתוכם, הם עם עצלן מטבעו שיחשוב דקות ארוכות על כל האפשרויות איך לתקן שורת קוד בכדי להקיש כמה שפחות על המקלדת).
בדיקות תוכנה הן תהליך ארוך וחוזר על עצמו. שוב ושוב לעבור על סדרה של הקשות והקלדות ומעבר בין המסכים שונים. לכן תהליך הבדיקות הוא בעיקרו משעמם. תפקידו של כל עצלן כמוני הוא להטיל את העבודה השחורה על מישהו אחר. למזלינו יש לנו משהו אחר שמתמחה במשימות משעממות. זה המחשב שלנו. עם קצת השקעה בתחילת התהליך, הבדיקות יכולות להפוך לאוטומטיןת ושמתבצעות בעצמן בהקשת כפתור.
אתם יודעים מה ? אפילו הקשת כפתור זה מיותר (זוכרים? אני עצלן) אפשר להפעיל את הבדיקות באופן אוטומטי לפני כל הפצה ללקוח, או בכל פעם שמכניסים קוד למאגר של הגרסא. (אני משתמש בmercurial) אני בחרתי להשתמש ב sniffer שמריץ את הבדיקות כל פעם שאני שומר קובץ לדיסק. כן, אני יודע שתגידו שזה בזבזני, אבל תזכרו שלא מדובר במאמץ מיוחד של בודק אנושי. זה פשוט עוד חצי דקה של המחשב, והוא ממילא דולק ומחכה לפקודתי. בכל מקרה אני מעדיף שהבדיקות ירוצו גם מאה פעמים “מיותרות” מאשר לפספס בדיקה חשובה.
נכתב די הרבה בזכות ביצוע unit test ותהליך test-driven-development ולכן לא אחזור על כל התאוריה.
היתרון המרכזי שמצאתי בשימוש שעשיתי בתהליך הTDD הוא שזה גורם לפוקוס בביצוע. אתה כותב את הבדיקה, מממש את הקוד המינימאלי בכדי לעבור את הבדיקה וממשיך הלאה. ולכן יש כמה שפחות דברים לא שימושים וסיבוכים שרק יכולים להכניס באגים למערכת ולבזבז זמן פיתוח. וכמובן, מרגע שכתבת את הבדיקה בפעם הראשונה (ועם הזמן נבנית תשתית לבדיקות, כך שזה נהיה הרגל קל ומהיר) אין שום בעיה להריץ אותה שוב ושוב ושוב.
אבל מצאתי את בדיקות המודולים כלא מספיקות. חסרה לי ההיסתכלות המערכתית. ומניסיוני, גם אם כל קופסא עושה את תפקידה כצפוי, מרבית הבעיות נובעות מהממשק בין החלקים.
למזלינו יש לזה פתרון. קוראים לזה behavioral-driven-development. העקרון הבסיסי הוא דומה, אבל יש מספר הבדלים משמעותים. הראשון הוא שההסתכלות היא מערכתית ולא נכנסת לפרטים הקטנים של מודולים או שדות במסכים. ההבדל השני הוא שהבדיקות נכתבות באנגלית (או כל שפה אנושית אחרת) ולא בקוד. הרעיון מאחורי זה הוא שגם אנשים שאינם תכנתים יוכלו לקרוא ולהבין (ואולי גם לכתוב) את הבדיקות. אבל מצאתי שלא משנה כמה טוב אני קורא קוד, לקרוא אנגלית יותר קל. ואם כותבים את הבדיקות נכון, זה עושה סדר בראש.
לתבנית שבה כותבים את הבדיקות קוראים gherkin. זו למעשה Domain Specific Language לתיעוד ההתנהגות הרצויה של תוכנה מבלי להכנס לפרטים של כיצד תסריטים אלו מבוצעים. כמו הרבה דברים טובים בעולם התוכנה היא הגיעה מקהילת הruby. הכלי הנפוץ ביותר ביותר נקרא cucumber. מכיוון שאני כותב את האפליקציה בpython חיפשתי כלי בשפה זו. שוב ישנן מספר אuפציות אני בחרתי ללכת עם behave שנראתה לי הבשלה ביותר.
הרבה מהדברים בוודאי מוכרים לכל מי שקרא את הagile manifesto. אבל כל מי שניסה לממש אג’ייל יודע כמה זה מסתבך כשמגיעים לביצוע. כאן זה יצא כתוצר לוואי.
הבדיקות כתובות בדיוק לפי “סיפורי משתמש” באג’יל. השימוש בשפה מדוברת מאפשר לכל המשתתפים בפרויקט לקרוא ולהבין במה מדובר. והיכולת לבצע את הבדיקות באופן רציף דואג שהתוכנה תעבוד במלואה לפי מה שרצינו.
כמובן שיש עוד הרבה רעיונות טובים שרציתי להשתמש ולא הספקתי. הבולט שבהם הוא שרת אינטגרציה רציפה (כמו jenkins) אבל בטוח שגם זה יגיע (ויאפשר לי לכתוב את החלק הבא)
אני מהנדס בהשכלתי. ולמרות שכבר הרבה מאוד שנים אני עסוק בלנהל אנשים, תמיד הקפדתי לקרוא ולהתעדכן בתחום הטכנולוגי. כך ראיתי מהצד אופנות באות והולכות. חלקן היה ברור שיעלמו מהעולם, חלקן היו יפות בתאוריה אך קשות למימוש, (או כך אמרו לי העובדים שלי) והיו מעטות שממש הצליחו לנו.
לאורך השנים תמיד החזקתי “פרויקטי מחמד” אבל לפני מספר חודשים לקחתי על עצמי לעבוד על פרוייקט של סטארט-אפ צעיר. מטבע הדברים, המשאבים המצומצמים דרשו עבודה יעילה ומענה לכל אותן בעיות שהכרתי מהצד הניהולי כמו עמידה בלוחות זמנים ויצירת מוצר איכותי. זו היתה הזדמנות מצויינת “לשים את הכסף שלי במקום מילים” ולבנות מהבסיס כלים ושיטות עבודה נכונות.
למרות השימוש בטכנולוגיות מתקדמות, החברה למעשה מוכרת שירותים כמודל העיסקי שלה. ולכן היה צורך לבנות פלטפורמה שתאפשר זאת מבלי לתפוס את הבמה מהשרות עצמו וכמובן לבצע זאת באופן אמין ביותר.
השלב הראשון היה לבחור את הטכנולוגיות המתאימות לפרוייקט. כדי לחסוך בעלויות ולאפשר זמינות גבוהה, היה לי ברור שלא כדאי להשקיע בהקמת חוות שרתים אלא ללכת בכיוון של טכנולוגית הענן. מכיוון שחלקים מסויימים נסמכו על מוצרים של google נפלה הבחירה די בקלות על ה google appengine. לכל אותם קוראים שמצקצקים בלשונם ומרגישים צורך “לשמור את הנתונים בכספת מתחת לשולחן שלהם” אני יכול רק להגיד שנראה לי שבמידה והשרתים של גוגל יום אחד יעלמו מהעולם באופן פתאומי, הכלכלה העולמית תהייה בצרות הרבה יותר גדולות מהצורך שלי לעבור פלטפורמה.
הappengine מאפשר שימוש במספר שפות. כשהתחלתי את העבודה היו שתי אפשרויות : JAVA ו PYTHON. היום נתווספו גם PHP ו GO. GO היא שפה נחמדה מבית היוצר של GOOGLE, ועדיין לא נראית לי בשלה עד כדי לבנות מזה מוצר מסחרי. את JAVA אין צורך להציג, ולמרות הפופולאריות שלה אני אף פעם לא הצלחתי להתחבר לסביבת העבודה שהיא יוצרת, עניין של טעם אישי כנראה. השפה היחידה שממש הכרתי מהניסיונות הבייתים שלי לתכנת אתרים (תמיד הקפדתי ללכלך את היידים בעצמי כדי שאוכל להבין מה התכנתים שלי מדברים) הייתה PHP. ולו הייתי מתחיל את הפרוייקט היום כששפה זו אפשרית, יכול להיות שהייתי בוחר בה כדי לחסוך זמן. לשמחתי זו לא הייתה אפשרות ולכן בחרתי בPYTHON. ואני מאוד שמח שכך בחרתי, ושכר הלימוד היה בהחלט שווה את זה.
אז יש לנו שרת ובחרנו שפה. צריך להדליק את הEDITOR ולכתוב “HELLO, WORLD” לא ? אומנם אפשר להשתמש ב(הכנס את שם העורך טקסט החביב עליך) אבל רציתי תמיכה יותר ממנימאלית בשפה, ויכולת שימוש בדיבאגר, אז הבחירה היתה בין pycharm לבין eclipse + pydev. אז למרות שהראשון ממש מוצלח וכאמור אני נרתע מהעולם של JAVA, עניין המחיר דחף אותי לכיוון של הבחירה השניה.
האפקט הראשון של הבחירה הוא הצורך להשתמש בdata store של גוגל. כדי להשיג את המהירות הדרושה להם גוגל עובדים באוביקטים ממויינים.אף פעם לא הייתי חזק בשאילתות SQL, ולכן זה היה לי מאוד טבעי. מצד שני לאורך הזמן התרגלתי לחשוב בצורה של טבלאות מנורמלות, וזה הצריך התרגלות
כל מי שכתב תוכנה אי פעם, יודע שאין צורך להמציא את הגלגל מחדש (למרות שעדיין לא ראיתי תכנת שקרא קוד של מישהו אחר ולא הכריז “צריך לכתוב את זה מחדש”). במקרה של אפליקציות רשת המרכיב החוזר המשמעותי הוא הweb framework. פייטון מציע מגוון שלם של סביבות עבודה כאלו בכל גודל וצבע. גוגל עצמה מציעה את webapp2 כברירת המחדל, ולכן התחלתי שם. זו מערכת קלת משקל ופשוטה, אך ברגע שהאפליקציה גדלה מעט זה התחיל להרגיש צפוף והרגשתי שאני צריך לעבוד קשה כדי לשמור על הסדר ושדברים יעבדו כשורה. מהצד השני של הסקאלה ישנה את האלופה במשקל כבד django. ג’נגו מעניקה סביבה בשלה ומלאה לתכנת. וחשבתי שיכולת האבסטרקציה שלה תהיה יתרון במידה ואצטרך לעבוד לפלטפורמה אחרת. החסרונות שלה היו עקומת למידה תלולה ובעיות התאמה לבסיס הנתונים של גוגל שבזמנו הציעו רק גרסאת non-relational.
איפה שהוא באמצע יש מגוון אפשרויות. אני בחרתי בFlask. היא קלה מאוד ללמידה ולשימוש, מציעה גמישות רבה בכדי להתאים להרבה מהרעיונות וההרגלים שתביא, ובמיוחד יש קהילה תוססת שמפתחת מסביבה תוספים ומסוגלת לתת מענה כשאתה נתקע. אי אפשר לתאר כמה שעות חסכתי לעצמי באמצעות חיפושים קצרים בstack overflow גם לבעיות שלא חשבתי שמישהו אחר אי פעם נתקל בהן לפני.
חמוש בכל הכלים האלו נכנסתי לעולם מופלא וקסום ב”קצה החד” של הטכנולוגיה העכשווית. בסיסי נתונים ללא טבלאות, אפליקצית צד-לקוח, תקשורת ברשת האינטרנט ועוד קללות כאלו ואחרות. היו הרבה דברים רעים שיכלו לקרות בדרך ולכן היה צריך להבטיח שאני נופל לכמה שפחות בורות בדרך. וזה הצריך מתודולוגית עבודה טובה. ועל כך בפעם הבאה.
