All posts by ido

בלון לחלל – ניסוי שני

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

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

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

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

ניפחנו שני בלונים, כדי שהעליה תהיה מהירה ושיחררנו …

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

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

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

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

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

IMG_1360

לאחר הארוחה, עלה מישהו לגבעה עם הקליטה וחזר עם החדשות המדהימות ״הבלון בירדן״

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

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

IMG_1374

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

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

gsbc_il flight 2

קמרה אובסקורה

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

IMG_7999

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

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

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

IMG_8012

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

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

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

 

 

IMG_8007IMG_8009

 

 

 

lean startup על קצה המזלג

אולי שמעתם על lean startup. אם לא, תוכלו למצוא הרבה חומר ברשת ויש הרבה מאוד ספרים מומלצים.

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

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

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

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

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

 

אתגר בלון לחלל – טיסת ניסיון

 

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

התחלקנו לקבוצת ניפוח הבלון וקבוצת בניית הpayload. לבסוף חיברנו בינהם.

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

 

 

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

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

 

 

 

Screen Shot 2015-03-14 at 20.03.54ניסינו לחפש באזור, אבל זו בהחלט מחט בערמת שחט.  מבואסים קשות נאלצנו להשלים עם העובדה שאיבדנו אותו ולא נצליח להציל את הציוד

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

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

 

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

 

image

מטענפלצת

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

IMG_0963

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

IMG_0960

שתי רכזות usb תרמו את השקעים שלהן ואת האריזה

IMG_0962

אם אתם משום מה מנסים את זה בבית, שימו לב שצריך לקצר את הרגלים המרכזיות (d,+d-)

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

 

 

 

ללמוד מכישלונות

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

laser1

 

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

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

 

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

 

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

laser2

פרויקט חדש – חלק 2: מטודולוגיה

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

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

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

התשובה מורכבת בדרך כלל מלפחות אחת מהתרוצים הבאים :

  •  לא היה זמן לבדוק את הכל
  • תיקנו רק משהו קטן ובדקנו אותו נקודתית

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

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

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

נכתב די הרבה בזכות ביצוע unit test ותהליך test-driven-development ולכן לא אחזור על כל התאוריה.

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

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

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

לתבנית שבה כותבים את הבדיקות קוראים gherkin. זו למעשה Domain Specific Language לתיעוד ההתנהגות הרצויה של תוכנה מבלי להכנס לפרטים של כיצד תסריטים אלו מבוצעים. כמו הרבה דברים טובים בעולם התוכנה היא הגיעה מקהילת הruby. הכלי הנפוץ ביותר ביותר נקרא cucumber. מכיוון שאני כותב את האפליקציה בpython חיפשתי כלי בשפה זו. שוב ישנן מספר אuפציות אני בחרתי ללכת עם behave שנראתה לי הבשלה ביותר.

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

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

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