טכני


11
אוג' 11

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

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

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

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

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


7
אוג' 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

בעיה שנייה


4
יוני 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 ורק אז אנדרויד.


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

 

 

 


11
מרץ 11

דנקן סטיוארט מדליוט על תחזיות לשנת 2011

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

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

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

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

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

 


20
פבר' 11

זיהוי משתמש לפי מייל בdjango

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

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

שני דברים הנחו אותי בכתיבה:

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

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

הנה הקוד:

from django.contrib.auth.backends import ModelBackend
from django.contrib.auth.models import User

class EmailUserBackend(ModelBackend):

    def authenticate(self, username=None, password=None):

        if '@' in username:

            try:

                user = User.objects.get(email=username)

                if user.check_password(password):

                    return user

            except User.DoesNotExist:

                pass

        return super(EmailUserBackend,self).authenticate(username, password)

בנוסף, צריך להחליף את הקוד הנוכחי בsettings.py:

AUTHENTICATION_BACKENDS = (

'gifts.giftuser.backend.EmailUserBackend',

#'django.contrib.auth.backends.ModelBackend',

)

בהערה: הקוד הקודם.