02
פברואר 13

אפליקצית מציאת המקלטים

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

היום עוד מספר דרישות בסיס:

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

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

הדברים מסתבכים

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

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

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

כמה דברים

את מה שניסיתי לעשות – הצלחתי ודי מהר. השירות עבד, הוא היה באויר תוך שעתיים, הוא לא דרש הרבה משאבים והוא לימד אותי כמה דברים חדשים. בצהריים כשאיתן התקשר אלי ואמר שאולי ידברו על הפיתרון שלי במסיבת עיתונאים (בסוף לא יצא אל הפועל) – ופחדתי לא לעמוד בעומס, פשוט עשיתי הוסטינג על… dropbox (!!) – שוב כלי חינמי ופשוט שמאפשר לעשות דברים בלתי צפויים. עידן גזית היה הראשון ששם לב, דרך אגב, איפה השירות מאוחסן.. ומיד צייץ: "Dude, your shelter map is hosted on dropbox? How ghetto. :)" :)

מאז כמובן שהעברתי את השירות לאמאזון.

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


11
אוגוסט 11

פייראפ ישראל עלה לאויר – פרוייקט קהילתי

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

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

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

כולם מוזמנים..


07
אוגוסט 11

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

העולם

אקסלפורר ממשיך בירידה האיטית אך קבועה, ירידה של 43.5% ל41.8 מסך כל הדפדפנים. פיירפוקס עדיין במקום השני אך עם ירידה מזערית של 0.2%, בעוד כרום ממשיך להתחזק מ20.6% 22.7%. סאפארי נשאר מאחור עם 5%, ועוד קצת לאופרה. לא בשינוי גדול.

מבחינת תתי-גרסאות, חשוב לראות שIE8 מתחיל לרדת, הרבה כנראה לטובת IE9 (מאבד מעל שני אחוזים מול גדל באחוז וחצי), כשפיירפוקס 5 תופס את מקומו הטבעי בראש דפדפני הפיירפוקס, רגע לפני שגירסה 6 יוצאת לאויר.

בגלישה המובילית בעולם, אופרה (שמופיע בהרבה טלפונים ישנים) עדיין מוביל אבל הבכורה הולכת ונעלמת בירידה מ22.8% ל21.6, בעוד אנדרואיד עולה 17.25% ל19.5 (!). שאר מערכות ההפעלה נשארות פחות או יותר אותו הדבר, כשאייפון מראה ירידה (!) קלה מ15.2 ל14.6%.

ארה"ב וצפון אמריקה

כאן הסיפור קצת שונה ואולי קצת מסביר למה הסיפורים ששומעים באתרי חדשות מובילים שונים מהסטטיסטיקות למעלה. במובייל האנדוריד מוביל וקופץ הרבה מאוד מ29.5% ל33.9%, והאייפון במקום השני עם עלייה של 1.5% (24 לערך ל25.5%). מענין לראות את המשך הנפילה של הבלקברי, כשרים פשוט לא מוצאים תשובה למה שוקרה בעולם שלהם, ויורדים הלאה מ16.2% ל14.2%, ומתחילים להתקרב למקום הרביעי של האייפוד טץ'.

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

בישראל

המצב ממשיך להיות מדכא למפתחי ומעצבי אתרים כשאקספלורר עדיין שולט ביד רמה עם כי עם ירידה של 1.5% ל56.7%. בישראל כרום הוא דווקא הדפדפן השני הפופולרי, בעלייה של 2% מ27 ל29%, כשירידה של אחוז בפיירפוקס תורמת גם היא לעלייה הזו. פיירפוקס פשוט לא תופס כאן והוא יושב על 11.4% בלבד.

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


18
יוני 11

מתכנת מעל גיל 45? הסתבכת

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

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

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

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

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

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


11
יוני 11

Django Unit Test על דאטהבייס חלופי

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

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

בדיקות על POSTGRES

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

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

במקרה שלי מכל מיני סיבות החלטתי שהקובץ ירש מהקובץ המקומי (קובץ הproduction) מקבל כל מיני נתונים שלא תלויים בי ולא רציתי לשמור את התלות הזו), ואז פשוט להוסיף את השורות הבאות שמשנות את הנתונים שחשובים לי:

try:
from settings import *
except ImportError:
pass

EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'

DATABASES = {
'default': {
# Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
'ENGINE': 'django.db.backends.sqlite3',
'NAME': project/dev.db',                      # Or path to database file if using sqlite3.
'USER': '',                      # Not used with sqlite3.
'PASSWORD': '',                  # Not used with sqlite3.
'HOST': '',                      # Set to empty string for localhost. Not used with sqlite3.
'PORT': '',
},
}

<p style="text-align: right;"><code dir="ltr">
בשילוב עם הרצה של הבדיקות רק על החלקים שלי, פקודת הבדיקה תהיה:

./manage.py test_watook --settings test-settings

בעיה שנייה


04
יוני 11

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

אתר הסטטיסטיקות statcounter מפרסם בזמן אמת מספרים שונים על מה באמת משתמשים האנשים בעולם ובכל מדינה מבחינת דפדפנים. לרובכם זה אולי מענין ואולי לא, תלוי אם אתם טכנולוגיים או סתם חובבי מספרים, אבל אם אתם מפתחי אתרים הידיעה של מה משתמשים אנשים, בעיקר בשביל לדעת איזה אפשרויות עומדות בפניכם (html5?), ומהם הטרנדים – חשובה ביותר. שאלה שעולה בפורומים שוב ושוב היא מתי אפשר להתחיל לפתח בhml5 לרשת – כשבעיקרה השאלה היא: מתי כבר לא יהיה אינטרנט אקספלורר מתחת גירסה 9 (התשובה: לא בקרוב, בגלל שגירסה 9 לא תומכת בפחות מווינדוס 7).

בעולם

אקספלורר שולט (טטטת) עדיין וכמעט ללא שינוי בגירסה 8 – מסתובב סביב 30%. בגלל הבעיה של גירסת הווינדוס של אקספלורר 9, המספר הזה ירד לאט לאט (כשאנשים ישדרגו מערכת הפעלה או יעברו לדפדפנים מתקדמים אחרים) אבל לא מהר.  ישר אחריו פיירפוקס 3.6 שנופל נפילה רצינית בחודשיים האחרונים ממ24% ל12%, כשפיירפוקס 4 מקבל קפיצה מ3% ל14%, מה שאומר שפחות או יותר, פיירפוקס לא איבד משתמשים אלא רק קיבל שדרוגים.

Source: StatCounter Global Stats – Browser Version Market Share

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

Source: StatCounter Global Stats – Browser Market Share

בישראל

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

 

Source: StatCounter Global Stats – Browser Version Market Share


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

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


30
מאי 11

היום האחרון בjunction 32

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

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

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

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

 


29
מרץ 11

קצרצר: לאתחל את סיסמת המנהל (admin) בדג'נגו

משהו שקורה לי כל כמה זמן – אני שוכח את הסיסמה לאדמין שלי. יש שיטה קלה יחסית להחליף אותה, וזה ע"י כניסה לdatabase:

הכנסו לshell החביב עליכם. לרוב אני משתמש בshell_plus של הdjango extensions שהוא shell רגיל (כמו django shell רק שהוא מעלה אוטומטית את כל המודולים שלכם):

from django.contrib.auth.models import User

us = User.objects.get(username="{{ your username }}")

us.set_password('{{ your password}}')

us.save()

פשוט, לא?


19
מרץ 11

חשיבות הכיסוי (coverage) בבדיקות התוכנה – ואיך עושים את זה בד'נגו

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

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

מהן בדיקות כיסוי (coverage)

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

חשוב לציין כמה נקודות קטנות בקשר לבדיקות האלה:

  • קשה מאוד להגיע ל100% בדיקות, ומעט מאוד אנשים חושבים שזה היעד. יש תלות מסויימת בקוד הספציפי שלכם, אבל קטנה מאוד – אני ממליץ לנסות להגיע לפחות ל70% כיסוי, ולא לנסות להלחם יותר מדי על ה10% האחרונים.
  • בדיקות קוד צד לקוח בעתיות יותר ואני לא הולך להתיחס אליהן בפוסט הזה (במיוחד כי הדגש כרגע הוא על django)
  • התירוץ החוזר הוא ש"הקוד שלנו שונה כי xyz, ולכן קשה בהרבה להגיע לכיסוי טוב". החליפו את xyz בדברים כמו "הוא מערב הרבה מודולים שונים", "אי אפשר להגיע לבדיקה של כל פינה", "יש לנו הרבה יותר נקודות קצה", והחביב עלי: "הקוד שלנו מאוד שונה כי הוא פועל על שילוב מחלקות שונות וקריאות מסובכות, תלויות חצוניות ודברים דומים". יש עוד הרבה כאלה. אל תקשיבו – עוד לא פגשתי קוד שבלתי אפשרי להגיע לאחוזים גבוהים של כיסוי – אם כי פגשתי קוד שהיה צריך לכתוב כמה mockups, נקודות קצה וירוטאליות ועוד משחקים שונים ומשונים.

בדיקות כיסוי בdjango

בדיקות הכיסוי בdjango במוססות על בדיקות כיסוי של נד בצ'לדר (Ned Batchelder) שנמצאות גם כאן או כאן. בחרו את הדרך הנוחה לכם להתקנה:

pip install hg+https://bitbucket.org/ned/coveragepy

או

easy_install coverage

וכדומה. בצורה דומה אפשר לחבר את החבילה לbuildout.

לאחר מכן התקינו את התוסף לdjango:

https://bitbucket.org/kmike/django-coverage/src

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

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

python manage.py test_coverage

אני ממליץ ללכת שלב נוסף, כמו שהזכרתי בפוסט הקודם, וליצור בדיקות רק לקוד שלכם:

בתוך management->commands (הפוסט הקודם מסביר את זה):

from django.core.management.base import AppCommand, BaseCommand

[python]
from django.core.management.base import AppCommand, BaseCommand
from django.core.management import call_command

from django.conf import settings

class Command(BaseCommand):
    
    def handle(self, *args, **options):
        test_app_path = ()
        for app in settings.MY_INSTALLED_APPS:
            test_app = app.split('.')
            if len(test_app) > 1:
                test_app = (test_app[-1],)
            else:
                test_app = (app,)
            test_app_path += test_app
        call_command("test_coverage",*test_app_path, **options)
    
[/python]

הוסיפו בsettings שלכם את מיקום יצירת הhtml:

COVERAGE_REPORT_HTML_OUTPUT_DIR כדי לבחור את הספריה ליצירת תוצאות הHTML


16
מרץ 11

דג'נגו – להריץ בדיקות רק על החלקים שלך

כחלק מפיתוח תוכנה רגילה בdjango אנשים מעודדים להשתמש (בתקווה גם לתרום) לקוד פתוח דרך ספריות מתוך pypi, github' bitbucket וכדומה. כל זה טוב ויפה, אבל מה קורה שאתה אוסף לך רשימה די ארוכה של אפליקציות, שרק חלק קטן מהן שלך, ואתה רוצה להריץ את הבדיקות שכתבת לעצמך (כי כולנו כותבים unit tests, נכון?)?

הבעיה

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

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

הפתרון

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

python manage.py test app1 app2 app3

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

MY_INSTALLED_APPS = ( app1, app2 )

INSTALLED_APPS = MY_INSTALLED_APPS+( app3 )

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

עכשיו רק צריך ליצור פקודה שרצה על MY_INSTALLED_APPS ומריצה על כל אחת מהן פקודת test. בשביל זה יצרתי פקודת שליטה: בתוך הספרייה management->commands יצרתי קובץ test_apps, שבו הקוד:

[python]
from django.core.management.base import AppCommand, BaseCommand
from django.core.management import call_command

from django.conf import settings

class Command(BaseCommand):
    
    def handle(self, *args, **options):
        test_app_path = ()
        for app in settings.MY_INSTALLED_APPS:
            test_app = app.split('.')
            if len(test_app) > 1:
                test_app = (test_app[-1],)
            else:
                test_app = (app,)
            test_app_path += test_app
        call_command("test",*test_app_path, **options)

[/python]

ועכשיו כשאני רוצה להריץ רק את הבדיקות שלי, אני פשוט מריץ python manage.py test_apps