רברס עם פלטפורמה

מקבץ כל פרקי העבר

ori@reversim.com (Ran Tavory & Ori Lahav) — Sat, 02 Jun 2012 15:07:00 +0000

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

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

http://m.reversim.com/reversim_1-121.zip (2.3G)
http://m.reversim.com/reversim_122-141.zip (400M)

141 Object Pascal with Ido Kanner

ori@reversim.com (Ran Tavory & Ori Lahav) — Mon, 28 May 2012 20:13:00 +0000

אני מתכבד לפתוח בזאת את הכנס השמיני בנושא "אובייקטיביות ותכנות" של המחלקה לפילוסופיה. איתנו בפאנל פרופסור אורי להב ("האובייקט ואני", הוצאת מידן), דוקטור רן תבורי ("אובייקטיבי-סובייקטיבי: גילוי עצמי דרך תכנות מונחה עצמים", הוצאת עם עובד), ואורח הכבוד פרופסור אמריטוס עידו קנר ("כשסטרוסטרופ בכה: מסע לנבכי המחלקה", הוצאת זמורה-ביתן). באג'נדה היום: Free Pascal
עידו עצמאי, מתעסק ב-VoIP, Asterisk.
תורם גם ל-Free Pascal Compiler, סביבת פיתוח (IDE) בשם Lazarus ואוהב קוד פתוח. אנחנו כבר אוהבים אותו.
Delphi הוא ווריאנט של Object Pascal וכך גם Free Pascal. בורלנד טבעו את המושג. דקת דומייה לזכר המתים.
ישנם כמה תקנים של Pascal, אחד מהם של Apple. מי היה מאמין. הם אפילו השתמשו בשפה בשביל לכתוב את מערכת ההפעלה שלהם באותה תקופה.
עידו כותב קליינט לרדיס בפסקל. יש גם מפגש, ממש בקרוב, יום ד הזה (30.5.2012)
שם, בין C ל-++C, שם בדיוק תמצאו את פסקל.
הקומפיילר של פסקל יודע להסיק מתוך הקוד מה הוא צריך לעשות.
בפסקל כדאי להשתמש כאשר המשימה היא יותר High Level
לפסקל יש גם Objective Pascal שיודע לדבר עם Objective C (אותו ABI)
בגרסאות האחרונות של Free Pascal אפשר לקמפל את הקוד כך שירוץ על ה-JVM (כמה בדיחות של אורי ורן באות פה).
לרוב החברות הגדולות יש Delphi בארגון (שזה בעצם אומר שיש להם Pascal בארגון)
מפתחי iOS שלא רצו ++C, C או Objective C הלכו ל-Pascal
אפשר גם לפתח ל-ווב ב-Pascal
כנס התוכנה החופשית בישראל בשיתוף עם עמותת הקוד הפתוח בישראל. תבואו.
ה-ILTechTalks week יוצא לדרך זו השנה השניה. Outbrain מארחת.

הקובץ נמצא כאן האזנה נעימה

תודה רבה ליותם אורון על עבודה התמלול הנאמנה!

140 Dart with Ido Green

ori@reversim.com (Ran Tavory & Ori Lahav) — Thu, 24 May 2012 19:50:00 +0000

ירדנו לבירה ובוטנים בפאב השכונתי. כטוב ליבנו באלכוהול קשקשנו עם הבעלים רן תבורי, הברמן אורי להב וה-Doorman עידו גרין על Dart ומשמעות החיים.
עידו עובד בגוגל כ-Developer Advocate ל-Chrome, ChromeOS ו-HTML5
Dart הושקה באוקטובר 2011. הניילונים עוד על הכיסאות.
מטרתה של Dart היא לאפשר למפתחים לבנות אפליקציות מודרניות ומורכבות בווב.
Dart היא אקוסיסטם שלם - ספריות, שפה, Editor, Virtual machine, כלים, קומפיילר (Dart2JS), הדרכות וסקירות וכו' (לעידו יש גם כמה דוגמאות שהוא רקח)
Dart היא Open Source במצב Pre-Alpha - ראו הוזהרתם (אבל דחיל רבאק - תנו פידבק !)
התלות ב-JS יכולה להגביל (Scoping, Annotation וכו').
אפשר בלי Types, אפשר עם. מה שיוצא - אני מרוצה.
הרבה קליברים נאספו להם יחדיו לבנות את השפה ואת הכלים שלה: האבא של ג'אווה גלעד ברכה, האבא של ווי-8 Lars Brunse (שכתב את ה-VM של Dart) ועוד כמה שיודעים.
יש גם Source Maps (אבל זה לא ממש קשור ל-Dart)
Single inheritance, class based, object oriented, interfaces, single threaded. נרשם רחש התעניינות בקהל.
יש כבר כמה סטארטאפים שמנסים את השפה.
בסוף אפריל היה אירוע של Hackathon עולמי של Dart. היה דיסקו.
Dart רצה גם בשרת וגם בקליינט. זה טוב או לא טוב ? אולי קצת טוב ?
המוטיבציה הגדולה של השפה היא לתת Structured webapp programming framework
ומה האינטרס של גוגל בכל העניין ? עולם טוב יותר לכולם.
Dart גם מכוונת ל-Mobile
אל תצפו מאפל לתמוך ב-Dart באופן מלא.

עוד כמה לינקים:

שאלות על Dart ב-StackOverflow
חדשות על Dart

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

הקובץ נמצא כאן האזנה נעימה

תודה רבה ליותם אורון על התמלול המהוקצע.

139 ember.js

ori@reversim.com (Ran Tavory & Ori Lahav) — Mon, 21 May 2012 05:21:00 +0000

בתא כתבי הספורט יושבים רן תבורי ופרשן הבית ישי סמית'. על המגרש מתחממת Ember. הישארו עמנו.
ישי הקים סטארטאפ חדש בתחילת השנה במסגרתו הוא עושה שימוש ב-Ember.js לצורך אפליקציית One page
ג'ף בזוס יודע מה הוא רוצה - One click checkout. בדגש על One.
Play 2.0 עושה את החיים קלים למי כותב אפליקציות לאינטרנט עם ג'אווה ו/או סקאלה.
Ember היא Javascript MVC framework, היא תהיה ברירת המחדל ב-RoR
ל-Ember יש Template engine
במצב שבו שדות רבים תלויים בתוכן של שדה מסוים בדף קשה מאוד לתחזק את הקשרים בקוד ללא עזרה של Framework
על מנת לייצר אובייקט יש להרחיב אובייקט של Ember
Ember התחיל בתור SprouteCore
אפשר לרשום Observers ו-Listeners על שדות
שדה יכול להיות גם פונקציה. החתול של שרדינגר מגרגר בהנאה. אין פה בעיה של ביצועים כי Ember יודעת לעשות caching
יהודה כץ, שמסתבר שהוא אושיה ידועה בעולם ה-JS, כתב (יחד עם עוד כמה שותפים) את Ember
ל-Ember יש תמיכה רחבה בקהיליית הקוד הפתוח
Ember יודעת לעבוד לא רע עם חתיכות קוד JS אחרות
Ember בנוי בצורה מודולרית, לא חייבים לקחת את כל ה-Framework
את ה-Template, שנראה כמו HTML (אבל הוא לא) מקמפלים ל-JS, שבתורו מורץ ומפיק HTML (אבל הפעם על אמת). כל זה יכול לקרות גם בצד השרת וגם בצד הלקוח. מבולבלים ? גם אנחנו.
A/B testing. זה טוב.
ואיזה החלטות קיבלו פייסבוק שעזרו להם להגיע ל-500 מיליון משתמשים ? עשו כמה דברים (אבל האמת היא שהם דאגו לכמה מהפכות עולמיות שבהן הפייסבוק שימש כלי מרכזי - אתה פשוט לא יכול לקנות PR כזה …)
Ember.js. השמיים הם הגבול - נסו ותהנו !

הקובץ נמצא כאן האזנה נעימה

ושוב תודה ליותם אורון על התמלול האיכותי!

138 Final Class 18 - past, present, future

ori@reversim.com (Ran Tavory & Ori Lahav) — Sun, 20 May 2012 05:25:00 +0000

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

פעם לא היה Open source. כן ילדים, לפני מלאן שנים - הכול היה קוד סגור.

XT, Basic, Batch files, 8086, 80286, Atari 800XL (64K), Commodore, Floppy, Amiga, Sinclair Spectrum, Tape cassette, Apple IIc, Pascal - בשנות מחשב הם חיו מתישהו בין הדינוזאורים לממותות …

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

יש שפה. יש עבודה. קשה, קשה …

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

פעם היה מפל, היום אנחנו גמישים. הללויה.

TDD, Unit testing וכדומה - היום הם הסטנדרט, פעם הם אפילו לא היו בתכנון.

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

אז מה הכי טוב ללמד באוניברסיטה? שאלה טובה.

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

האם השפות הולכות ונהיות יותר ויותר High level ?

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

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

Scala מצוינת בהרבה תחומים - ישי ממליץ.

XML כבר יצא מכל החורים - תנו לנו defaults וקונפיגורציה בתוך הקוד ואנחנו מרוצים.

Spring. עוד לא תמו צרותינו.

האם שינוי משמעותי בכלי הפיתוח בשנים הקרובות יגרור שינויים משמעותיים בתרבות הארגונית של חברות ?

לאן הולך הקוד הפתוח ? מה המודל הכלכלי הנכון שייקח ? ימות או יחיה ? ומי רצח את ארלוזרוב ?

Github הם סגניו של אלוהים. לפחות.

Shorts

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

JCP שיחררו גרסה מוקדמת של Java EE 7 עם תמיכה ב-Cloud. אנחת רווחה בקהל.

Prince of Persia. קוד המקור. שוחרר. תיהנו.

כל מתכנת אפליקציות מלמיליאן. או שלא. בכל מקרה, Don't quit your day job (אבל זה כיף !)

הקובץ נמצא כאן האזנה נעימה

ותודה רבה ליותם אורון על הטיקסטוקסט.

137 binpress

ori@reversim.com (Ran Tavory & Ori Lahav) — Sat, 05 May 2012 20:17:00 +0000

אירחנו את אדם לשיחה על binpress

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

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

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

הבעיות הנפוצות בקוד פתוח:

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

המטרה והיתרונות של binpress:

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

עד כה יש כ-400 קומפוננטות ב-binpress, כ-30% מהן מוצעות בחינם. כמו כן יש למעלה מ-12,000 מפתחים רשומים במערכת אשר מתוכם כ-300 מפתחים מוכרים קטעי קוד (אחד או יותר).

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

תהליך ה-review נעשה על ידי מומחים לשפה הרלבנטית.
שימו לב: binpress מחפשת reviewers (בתשלום). אז אם אתם מחשיבים את עצמכם למומחים בפלטפורמה כלשהי, זו הזדמנות לעשות כמה ג'ובות מהצד.

האתר מאפשר למפתחים להציע מספר אופציות תמחור לרשיונות ברמות שונות כאשר האתר גובה 30% עמלה מערך המכירה תוך שימוש ב-paypal וב-debit card.

Binpress פועלת בשני איזורים גיאוגרפיים (מלבד לקיום האתר באינטרנט). האחד בתל-אביב והשני ב-Mountain View. החברה פועלת על בסיס השקעה ומימון עצמי כאשר יש לה הכנסות הגדלות ב-30% מחודש לחודש עם צפי לרווחיות בחודשים הקרובים.

- לינקים:

o http://www.binpress.com/

o http://www.linkedin.com/in/adambenayoun

o http://www.lionite.com/

הקובץ נמצא כאן האזנה נעימה

תודה רבה לגל על התקצור!

137 Nir Katz

ori@reversim.com (Ran Tavory & Ori Lahav) — Wed, 02 May 2012 20:28:00 +0000

והפעם - קרחנה ! בעמדת הדי ג'יי - רן תבורי. שומר הסף הקשוח - אורי להב. על הבר - ניר כץ. יש גם כתבה בוואינט.
ניר בא בימים (בכל זאת -בן 43 !), נשוי, אבא לשלושה.
מתכנת ומאוהב בתחום מגיל מאוד צעיר.
וכן, תמיד בסוף יש אישה. איך הן מצליחות לעשות את זה ?!
ניר עבד במיקרוסופט משנת 1995, בפרויקט של messaging queue שנקרא MSMQ.
לא רוצים פאדיחות במסיבת העזיבה שלכם ? אל תעלו תמונות עירום שלכם לרשת.
הכתיבה נכנסה בהדרגה, בתחילה כתחביב, מאוחר יותר כעיסוק.
משבר גיל ה-40, הלחץ בעבודה, משבר בעבודה - כל אלו צעקו "רד מהסוס!"
כתיבה של תוכנה דומה מאוד לכתיבה של תסריט.
למוזיקאים ומתכנתים יש הרבה במשותף. האם מוצרט התבלבל במקלדת ?
יצירתיות בתוכנה - קל, זמין, מיידי - טוב או לא טוב ?
אז איך עוזבים את כל הטוב הזה במיקרוסופט ? צריך גב כלכלי. או אישה עם משכורת טובה. או שניהם. בכל מקרה - מלאך המוות לא לוקח שוחד, אי אפשר פשוט לקנות עוד זמן.
הספר הכי טוב בעולם ? אתם תופתעו.
לא רק חתולים מחשבים את קיצם לאחור. המוות של כולנו אורב מעבר לפינה, אבל לא צריך להיבהל מזה.
מה הדבר הכי נוראש יקרה אם תעשה שינוי גדול בחיים ? כנראה שלא כזו קטסטרופה.
אבקת מרק עושה את כל ההבדל, אבל רק אם אתם עושים קוסקוס.
ניר כתב תקופה לאתר סטנד-אפ אבל בסוף נפרדו דרכיהם. זה לא מצחיק.
לאורי יש אבא מגניב. באמת.
אם הכתיבה לא תלך, חוזרים לתוכנה - אבל באיזי.

הקובץ נמצא כאן האזנה נעימה

ןשוב תודה ליותם על התקצור הצבעוני.

135 final class 17 Software Deadlines

ori@reversim.com (Ran Tavory & Ori Lahav) — Wed, 02 May 2012 05:47:00 +0000

להלן פרוטוקול ישיבת הוועדה המסדרת שנערכה ביום שני ה-23 באפריל.
נוכחים: יו"ר רן תבורי, סיו"ר אורי להב, וכן ראשי הסניפים ערן הראל, יונתן, ארז מזור, איתי ממן, ישי סמית'. גם גילי בא.
על הפרק היום: דד-ליין בעולם התוכנה.
הערכות זמנים, בדומה לתכניות עסקיות של סטארטאפים, הן תת-ז'אנר בסוגת המדע הבדיוני, מאוד תלוי כמה המתכנת רוצה לבצע את המשימה וכמה היא מעניינת. בכל מקרה - לא טריוויאלי.
ישנן כל מיני שיטות להעריך זמני ביצוע: לתת שלושה זמנים (נמוך, צפוי, ארוך), לתת הערכה של הזמן ואז להוסיף פקטור כלשהו (30 אחוז, כפול שתיים וכו'). צעירים משלמים כפול - פה זה לא סלקום.
גם ב-Quora שאלו. בקצרה, המרחק בין סן-פרנסיסקו ללוס אנג'לס הוא לא בדיוק מה שנראה בהסתכלות ראשונית.
האם חוסר היכולת להעריך זמנים נובע מחוסר בגרות של המקצוע ? חוסר מקצועיות של המתכנתים ?
כל פרויקט תוכנה הוא ייחודי, גם אם יש לו מאפיינים דומים לפרוייקטים אחרים.
לעומת תחומי הנדסה אחרים, העלות של טעות בתוכנה היא לא קטסטרופאלית ולכן אפשר להרשות לעצמנו לטעות.
מה עושים עם דד-ליין שבאמת - אבל באמת - קשה להזיז ? נגיד, יום שבו יהיה ליקוי ירח?
משולש הזהב הוא משאב-תוכן-איכות, כנראה שהתוכן ייפגע אם הדד-ליין מתקרב.
ההגדרה של מה נכנס ומה לא למוצר עד הדד-ליין הוא פונקציה של מה מטרת הדד-ליין (לבדוק היתכנות, A/B testing, להשוויץ בעומסים הגבוהים שאפשר לעמוד בהם וכו').
כדי לעמוד בדדליין, לפעמים חותכים פינות (קוד ספגטי, פחות עמיד וכו'). החוכמה היא לתקן את מה שמקולקל (או שדורש שיפור) בהמשך.
ומה עושים עם מתכנתים שלא נותנים הערכות זמנים ? מחלקים לחתיכות קטנות יותר ומעריכים אותן (לדוגמה).
בני אדם נוטים לצרוך את כל הזמן שהוקצה לביצוע משימה. מישהו כבר אמר את זה קודם.
הערכות זמנים לא מתאימות לכל אחד, יש כאלה שזה יעשה להם רע - ולהיפך.
אורי מדבר על יק. ועל סכיני גילוח. ועל גילוחים. מחלקה סגורה כבר אמרנו ?
הערכות זמנים יכולות לשמש להערכה של הכדאיות העסקית של העבודה.
דדליין יכול להכניס אנשים ללחץ. כן, זה קורה.
"Your lack of planning is not my emergency". לחן - עממי. וגם: אם הכול הוא חירום, אז בעצם שום דבר הוא לא חירום.
אוהבים תכנות ? מתכננים קריירה בתחום ? נהדר. יש לכם 40 שנה לעשות את זה, תעשו את זה בכיף, קחו את הזמן. קנת בק אמר (גם) את זה.
למנהלים יש חומר קריאה מיוחד. אחת המסקנות - תן למתכנת לקבוע את הדדליין.
מה שיכול להניע אנשים לקצר את לוחות הזמנים הוא הידיעה שמעט אחרי שהקוד ייכנס מישהו (ובשאיפה - הרבה אנשים) ישתמש בקוד.
אנשים שונים מייצרים פיתרון שונה לאותה בעיה ולכן הערכת הזמן תלויה מאוד באדם שיממש בסופו של דבר.
דדליין זה כמו חסה: בריא לאללה - אבל לאכול את זה כל יום בצהריים ?!

קצרצרים:

חמשת השלבים של דיבוג.
בקאנדס למיניהם:

למובייל: parse, usergrid, cocoafish, cloudmine, kinvey, stackmob, mobdb
לריל טיים ווב: meteor, derby, firebase

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

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

הקובץ נמצא כאן האזנה נעימה

ותודה למשורר יותם אורון :)

134 The Zen of Python

ori@reversim.com (Ran Tavory & Ori Lahav) — Mon, 30 Apr 2012 18:28:00 +0000

רן שוחח מעל סקייפ עם מיקי טבקה על הזן של פייתון. (תרגום)

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

תרגום של "הזן של פיתון" לעברית

מיקי טבקה, אפריל 2012

The Zen of Python, by Tim Peters	הזן של פיתון מאת טים פיטרס
Beautiful is better than ugly	יפה עדיף על מכוער
Explicit is better than implicit	מפורש עדיך על מרומז
Simple is better than complex	פשוט עדיף על מסובך
Complex is better than complicated	מסובך עדיך על מתוסבך
Flat is better than nested	שטוח עדיף על מקונן
Sparse is better than dense#	דליל עדיף על צפוף
Readability counts	קריאות נחשבת
Special cases aren't special enough to break the rules	מקרים מיוחדים אינם מספיק מיוחדים כדי לשבור את הכללים
Although practicality beats purity	למרות שמעשיות עדיפה על טוהר
Errors should never pass silently	אסור ששגיאות יעברו בשקט
Unless explicitly silenced	אלא אם הושתקו בפרוש
In the face of ambiguity, refuse the temptation to guess	סרבו לפיתוי לנחש כשאתם עומדים בפני דו משמעות
There should be one-- and preferably only one --obvious way to do it	צריכה להיות דרך אחת, ועדיף רק אחת, לעשות את זה
Although that way may not be obvious at first unless you're Dutch	למרות שיכול להיות שהדרך לא תהיה ברורה בהתחלה - אלא אם אתה הולנדי
Now is better than never	עכשיו עדיף על אף פעם
Although never is often better than right now	למרות שאף פעם בדרך כלל עדיף על "ברגע זה"
If the implementation is hard to explain, it's a bad idea	אם קשה להסביר את המימוש, זה רעיון גרוע
If the implementation is easy to explain, it may be a good idea	אם קל להסביר את המימוש, זה אולי רעיון טוב
Namespaces are one honking great idea -- let's do more of those	"מרחבי שמות" הם רעיון נפלא - בואו נעשה עוד

הקובץ נמצא כאן האזנה נעימה

להלן רשימת לינקים:

The Zen: http://www.python.org/dev/peps/pep-0020/
http://code.activestate.com/lists/python-list/287109/
http://dl.dropbox.com/u/706094/CommentsIntoCode.pdf
- Waiting for Mr. Perfect (bit.ly/HW2Znn)

PyCon
=====
* 2200+ people, Santa Clara March 7
* Tutorial, main event, sprints
* Python is going mainstream
- Google, Netflix, SurveyMonkey ...
* Science
- NumPy/SciPy
- Pandas, matplotlib
- sage
- scikit-learn
* PyPy
* Python 3
- Libraries http://py3ksupport.appspot.com/
- Adconion example
* Talks - from very technical to sketching
* Videos at http://pyvideo.org/category/17/pycon-us-2012
- Had a live broadcast
- My recommendations:
- Guido's keynote: http://pyvideo.org/video/956/keynote-guido-van-rossum
- Make Sure Your Program Crashes: http://pyvideo.org/video/647/make-sure-your-programs-crash
- Permission or Forgivness: http://pyvideo.org/video/650/permission-or-forgiveness
- Scalability at YouTube: https://us.pycon.org/2012/schedule/presentation/128/
- Sketching a Better Product: http://pyvideo.org/video/957/sketching-a-better-product
- Pragmatic Unicode or How do I stop the Pain: http://pyvideo.org/video/948/pragmatic-unicode-or-how-do-i-stop-the-pain
- What you need to know about datetime: http://pyvideo.org/video/946/what-you-need-to-know-about-datetimes

Hickey's "Hammock Driven Development" which is excellent -
http://blip.tv/clojure/hammock-driven-development-4475586

133 The Junction

ori@reversim.com (Ran Tavory & Ori Lahav) — Sat, 14 Apr 2012 11:29:00 +0000

יוצאים מחיפה ב-100 קמ"ש: רן ואורי. יוצא מתל-אביב ב-120 קמ"ש: עדן שוחט. כמה זמן ייקח להם להיפגש ב-Junction ?
היסטוריה קצרה של עדן: מתכנת, עבד בנינטנדו, ב-Shells, אלגו-טריידינג, Aternity, ובסוף Face.com. מארגן גם את Geekcon. וגם שותף כללי בג'נסיס פרטנרס. בקיצור, סתם אחד.
ה-Junction הוא יוזמה של ג'נסיס פרטנרס.
הרעיון (של Shared working space) כבר היה קיים בג'נסיס - לאפשר לאנשים להתארח, לעבוד עם אנשים דומים ולפתח רעיונות.
האם התרגום העברי הראשון של יצירה של שייקספיר לעברית אכן טוב יותר מהמקור ? לעדן פתרונים.
ההשראה באה מ-Dogpatch.
מטרת ה-Junction בגדול היא לשפר את רמת החברות השותפות ב-Junction (ובשאיפה גם מחוצה להן) ולכן גם אין סינון מעבר למחויבות של 100%.
מה שמקבל היזם: כסא, אינטרנט כמה שיותר מהיר, קפה חופשי ו-72 בתולות. אפשר גם בתולים. הכול הולך. בתמורה היזם נותן כל שעה נשיקה וכל שעתיים חיבוק.
יש כאלה שגם ישנים ב-Junction. אני אמנע בשלב זה מאלפי הבדיחות שעולות לי בראש מפאת קוצר היריעה.
הריכוז של אנשים עם אותן הבעיות בשלבים שונים שמוכנים ויכולים לעזור האחד לשני תורם מאוד לפיתרון בעיות ולהתפתחות הדדית. Its the sixties all over again.
מסתבר שאורי הוא איש טוב. מי היה מאמין.
הרבה מאוד אנשים, גם כאלה שלא היו חלק ממחזורים קודמים של ה-Junction, באים ותורמים מזמנם על מנת לעזור למחזור הנוכחי ולייעץ.
ג'נסיס יכולה לעשות שימוש (וגם עושה) במשאבים ובקשרים שלה על מנת לעזור ליזמים ב-Junction
חברות שיצאו מה-Junction:

פעם בשבוע בימי חמישי יש TechTalks בשיתוף עם IL Tech Talks
יש גם שיחות סגורות לבני מחזור ובוגרים בלבד.
בסוף כל מחזור יש Demo-Day שאליו מוזמנים אנג'לים ומשקיעים מקצועיים על מנת להתרשם ולהשקיע.
אחלה רעיון, אחלה מימוש - כן ירבו !

הקובץ נמצא כאן האזנה נעימה

Statistics April 2012

ori@reversim.com (Ran Tavory & Ori Lahav) — Wed, 11 Apr 2012 21:24:00 +0000

מידי פעם שואלים אותנו כמה מאזינים יש לפודקאסט?

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

המספר הוא כ 2000-1000 מאזינים.

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

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

נתחיל בגוגל אנליטיקס. אני מסתכל על Unique Visitors ורואה שבמשך 3 החודשים האחרונים יש משהו כמו 100 יוניקים ביום

Daily Uniques

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

Monthly Uniques

כלומר, בין 1500 ל 2500 אנשים שונים (או לפחות - דפדפנים שונים), כל חודש ביקרו באתר. יתכן שהם הקשיבו לפרק אחד באותו חודש, אולי שניים, אולי שלושה, ואולי לא בכלל. אבל כ 2000 כל חודש פוקדים את האתר, שזה לא רע.

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

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

(האזנות זה כמו page-view ומאזינים זה כמו unique visitors)

CDN Traffic

מהגרף הזה ניתן לראות שהחודש העמוס ביותר עד כה, נובמבר האחרון, הכיל 75G של data שעבר למאזינים. ובממוצע, בכל חודש עוברים כ 42G.

כל קובץ של פודקאסט, נפחו הוא בממוצע 20M.

אז אם מחלקים 40G ב 20M מקבלים 2000. כלומר 2000 הוא מספר ההאזנות החודשיות הממוצע.

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

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

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

מה עוד מעניין?

מה הדפדפן השולט? (כרום)
מאיזה מדינות מאזינים?
מה הוא הפרק שזכה להכי הרבה page views?

תשובות לשאלות אלו ואחרות תמצאו בתמונות המסך להלן.

132 Sasson

ori@reversim.com (Ran Tavory & Ori Lahav) — Wed, 11 Apr 2012 20:02:00 +0000

יצאנו לדרכים, נחתנו בפונדק של אבירי Linnovate
מיטיבים ליבם ביין סביב השולחן העגול: רן "בן דמות היגון" תבורי, אורי "מגינה של דולציניאה" להב, זהר "ידידו של סנשו פנשה" סטולר, צחי "הלב של לה-מנצ'ה" שלידור ויעל "הקמע" תבורי.
מנת הבית: Sasson.
לינובייט עושים בעיקר אתרי דרופל, עם לקוחות אנטרפרייז גדולים (ישראל היום, ג'ון ברייס, אנדר.מי וכו')
השירות של לינובייט הוא end2end.
דרופל צועדת עם הזמן, התחילה כמערכת ניהול פורומים פשוטה ומאוד השתנתה וצמחה מאז
המתחרים של דרופל היום הם SharePoint, Vignette וכו'.
ממשלת ישראל בחרה בדרופל כתשתית לדור הבא של אתר gov.il.
ששון הוא ארגז כלים, מעין Base Theme. המקור של השם הוא בכלל מפרי-קומפיילר של CSS שנקרא Sass
ששון עושה שימוש בקומפס ותומך ב-HTML5
ששון תומך ב-Responsive design: תגובה לרוחב המסך. מגיע בעיקר עקב הדרישות של עולם המובייל. דוגמה אפשר לראות במשחק מטמון של ישראל היום בפסח.
RTL עוד יביא את השלום. Just you wait !
לינובייט מארחים בדרך כלל בשרת שלהם (מאובטח) או אמאזון (ולפעמים על שרת של חברה נוספת).
יש הרבה תוספים והרחבות לדרופל להרבה מאוד שימושים.

הקובץ נמצא כאן האזנה נעימה

ותודה רבה ליותם אורון על התמלול הצבעוני.

131 uijet

ori@reversim.com (Ran Tavory & Ori Lahav) — Wed, 11 Apr 2012 19:43:00 +0000

פרק 131 – שיחה עם יונתן דניב –Freelancer המפתח בעיקר Client Sideויוצר ספריית uijet

נושא: UIJet

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

- תוך כדי חיפוש פתרון הזדמן ליונתן לשמוע הרצאה מעניינת של ניקולאס זאקס (מומחה JS ו-performance מיאהו!) בנושא ארכיטקטורה של אפליקציות Client (ScalableJavascript Application Architecture), הרצאה אשר נתנה השראה למימוש הספריה ושימוש בספריות באחרות.

- קצרים על ארכיטקטורת אפליקציות קליינט (מתוך ההרצאה):

o ברובד התחתון של הארכיטקטורה נמצאות ספריות כמו jquery או Prototype אשר עוטפות את ממשק הדפדפן ל-DOM.

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

o מעל האפליקציה יש שכבה נוספת (לפי NZ) הנקראת Sandbox אשר תפקידה לנהל את הקומפוננטות של האפליקציה מבלי להכיר את השכבות הנמוכות שמתחתיה (מתחת לאפליקציה).

o – כל קומפוננטה העומדת בפני עצמה ומדברת ישירות מול ה- widgetSandbox. ה-Sandbox מקבל הוראות מהאפליקציה לגבי הפעלת/הפסקת פעולת ה-Widgets ו/או העברת פרמרטים אליהם.

- מימושים שונים בראיית הארכיטקטורה הנ"ל:

- XJS ו-Dojo –מיישמים את כל ה-stuck הנ"ל.

- jQuery – יישום רק של ספריה ומנגנון לבניית Plugins.

- UIjet זהו ה-sandbox עצמו אשר מגיע יחד עם מספר widgets וכולל:

o Javascript

o שימוש ב-css בסיסי – במידה ורוצים לתמוך במגוון רחב של devices יש לשים לב לשילוב עם Javascript שכן לא כל המכשירים תומכים בכל תכונות ה-CSS.

o הגדרת קבצים ו-dependencies– הנ"ל ייטענו באופן דינמי בזמן הרצת האפליקציה, הקומפוננטות ייטענו ויאותחלו.

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

o צריך להגדיר ספריה לניהול ההודעות ( pub/sub העובד באופן אסינכרוני)

o ניתן להוסיף client side router (בחירת ספריה ומימוש Interface) – להגדרת ה-routing בין ה-URL ל-State של הדף

o ניתן להשתמש ב-Template Engine על ידי מימוש Interface של ה-template.

- ספריות נוספות שהוזכרו-

o bonzo-js – ספריה מינימליסטית המממשת ממשק ל-DOM
o ender-js – מנוע הבונה מספריות נתונות ומיפוי תלויות של מה משתמשים מתוכן ומה לא, ספריה חדשה הכוללת רק את הרכיבים הרלבנטיים.

- לינקים:

o https://bitbucket.org/ydaniv
https://github.com/ydaniv -

הקובץ נמצא כאן האזנה נעימה

ותודה רבה לגל כהן על התמלול!

130 Windows 8

ori@reversim.com (Ran Tavory & Ori Lahav) — Tue, 20 Mar 2012 21:42:00 +0000

פה גרים בכיף: אורי, רן וגיא בורשטיין (Developer evangelist) ממיקרוסופט. יש גם Developer advocat (ויש עוד כל מיני שמות שמחלקת ה-HR המציאה בשביל להצדיק את הקיום שלה - הערת המשורר).
על הפרק באסיפת הבניין - ווינדוס 8. יש גם Preview.
במקום בליל של API (אחד לכל שפה), בווינדוס 8 יש מושג חדש של WinRT - Windows Run Time - דרך אחידה לפנות למשאבי המערכת.
ווינדוס 8 רץ על מספר פלטפורמות - PC, טאבלט (אולי גם מובייל בעתיד?), יחד עם זאת אין איחוד מלא של עולם הווב וה-Native
WinRT גם מאפשר לכתוב קומפוננטה בכל שפה ולהשתמש באותה קומפוננטה בכל שפה
ווינדוס 8 מציג אפשרויות חדשות להתחבר לענן (של מיקרוסופט) אבל לשירותים נוספים (Roaming to the cloud, sky drive וכו').
קונספט חדש שנקרא קונטרקטס יודע לתקשר בין אפליקציות.
בווינדוס 8 יש ממשק משתמש חדש - מטרו. היה גם יום עיון - לעיונכם.
מיקרוסופט מבטיחה לעדכן לעתים הרבה יותר קרובות את הדפדפן. הישארו עמנו.
הגרסה הבאה של ווינדוס 8 תצא אחרי שכל הפידבקים יתקבלו מהשוק ויוטמעו במערכת.
בעתיד תיפתח החנות של מיקרוסופט למפתחים וצרכנים ישראלים.

הקובץ נמצא כאן האזנה נעימה

תודה ליותם על התמלול והאיפוק ;)

129 Backbone.js

ori@reversim.com (Ran Tavory & Ori Lahav) — Thu, 15 Mar 2012 07:10:00 +0000

הנושא היום: התפתחויות בעולם ה- Javascript, MVC Frameworks

משתתפים רן תבורי, ישי סמית ועוזי קילון

קצת רקע: עוזי הצטרף אלינו לשיחה כמשתמש ופעיל ברשימת תפוצה של Backbone.js, שם גם אותר שם על ידי רן. קישור לבלוג של עוזי נמצא כאן. עוזי עובד כיום כמפתח Front-End בחברת Splunk בסן פרנסיסקו לאחר מספר שנות עבודה ב-Dapper אשר נרכשה על ידי Yahoo! ושבה עבד גם בארץ וגם ב-SF. Dapper פיתחה מערכת המאפשרת לבצע Web Scraping יחסית בקלות גם על ידי חסרי רקע בתכנות. הטכנלוגיה בסופו של דבר משמשת את Yahoo! לצרכי זיהוי סוג האתר עליו אתה נמצא לשם זיהוי טוב יותר והאמת פרסומות לקונטקסט הנכון.

Splunk מספקת מוצר בתחום ביזור המערכות. המוצר נולד כפתרון IT לניתוח לוגים ומספק שירותים תחת ההגדרה - Time Based Database. בשלב מאוחר יותר כשהטכנולוגיה הבשילה המוצר הפך לגנרי יותר ומאפשר כיום התממשקות לא רק לחבילות לוג סטנדרטיות אלא גם לכל פיסת מידע וטרנזקציה המתוייגת על ידי זמן. המוצר מאפשר ביצוע שאילתות נתונים והפקת דוחות בקלות רבה, כמו גם להוסיף Adaptors למקורות מידע נוספים. הטכנולוגיה הבסיסית של המוצר עושה שימוש בין השאר גם ב-Hadoop , כמו גם טבנולוגיות יחודיות שפותחו על ידי splunk אך למרות זאת נותן ביצועי חיפוש יעילים יותר ועל פי בדיקה שנעשתה לאחרונה היו טובים לעיתים אפילו פי 100!

הזכרנו מספר Framework ו-Utilities אשר משמשים מפתחי Java Front-Ends כגון: , JQuery, Prototype.js, Undescore.js, Ember.js, Backbone.js וכו'. רשימה מעודכנת של ספריות והשוואה של יכולות MVC שלהן ועוד ניתן לראות ב- Todo MVC demo ב-Github, שם ניתן לראות איך מממשים את אפליקציית ה-demo בכל אחת מהספריות הני"ל.

אבחנה בין Framework ל-ספריה: ה-Framework קורא לקוד שלך ולעומתו בספריה, הקוד שלך עושה שימוש בספריה (כלומר קורא לקוד של הספריה). על פי אבחנה זו, Backbone.js הינה ספריה.

מה זה Backbone.js? – ספריה המספקת שירותי MV (model and view, no control) בשכבה מאוד דקה שמטפלת בעיקר בקישור (routing) של המידע למודל/תצוגה תוך שימוש ב-Patterns פשוטים המאפשרים שיתוף מידע בין Views שונים אשר ממומשים יחסית בקלות.

מכיוון ש-backbone.js קלה מאוד (sizing footprint) היא אטרקטיבית מאוד לשימוש בסביבת מובייל.

בשונה מ- JQuery אשר מסייע ב-DOM Abstraction ופחות מסייע מבחינת ארכיטקטורה, backbone.js נותן שירותים טובים של שליפת מידע ו-dynamic rendering– במיוחד אם עובדים בארכיטקטורת REST מלאה (לכל משאב/שירות יש את ה-URL שלו וכו'). הספרייה עושה שימוש ב- Underscore.js וביכולות ה- Template הטובים שלה וכמו כן משתמשת בשכבת התקשורת xhr מ-jquery לצורך ביצוע הקריאות לשרת וב-delegate (גם הוא מ-jquery) לצורך ניהול ה-events (הרחבנו קצת בנושא).

- דיברנו על מאפייני אפליקציות התואמים שימוש ב-backbone.js (single page applications כמו gmail אשר אין להן הרבה צורך ל-refresh של ה-page, גם אם מדובר על הרבה קריאות לשרת).

- דיברנו על מודלים ורכיבים שונים בתוך backbone ועל דוגמאות להגדרת שליפה מהשרת תוך שימוש בהגדרת מודלים, collections, הגדרת view למודל (template, DOM elements, etc.).

- Routes – מאפשר לבצע מיפוי ושימוש בחלק שמגדיר את ההאפליקציה בשורת ה-Url (מופיע אחרי הגדרת שם הדומיין), מופיע אחרי סימן ה-# וידוע בשם Anchor tag.

- שוחחנו קצת על הארכיטקטורה של הקשר בין ה-view לבין המודל. ה-view מתפקד כ-observer למודל – תכונה אשר מאפשרת לבצע פעולות בצד ה-client מבלי לטעון את כל הדף מחדש. כמו כן, ה-view יכול לבחור על איזה שדות במודל הוא מאזין, בלי קשר לכך שהוא מבצע/יכול לבצע render לכל השאר.

- הזכרנו קצת את ההבדל בגישות בין ember.js ל-backbone.js (ember קצת יותר פורמלית בהגדרות ולעומתה ב-backbone הגמישות דורשת למעשה כתיבה של לוגיקה).

יתרונות וחסרונות של backbone.js:

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

- לא תומך באובייקטים מורכבים (backbone relational יכול לעזור כאן בטעינה של נתונים היררכיים מהשרת)

- יתרון – lightweight.

הקובץ נמצא כאן האזנה נעימה

תודה לגל כהן על התמלול.

128 Final Class 16 - Simplicity

ori@reversim.com (Ran Tavory & Ori Lahav) — Fri, 09 Mar 2012 13:33:00 +0000

מאושפזים בכפייה: רן מ-invi, איתי מ-Google, ערן מ-Outbrain, גילי מ-IBM (אבל דעותיו אינן מייצגות את החברה), אביב מ-BillGuard. בסוף גם ישי בא (QWallet).

והנושאים להיום: פשטות בתוכנה וחדי-קרן. אם כבר פנטזיות אז עד הסוף. סתם, בלי חדי-קרן.
הנושא עלה בעקבות פוסט של Avdi בעניין.
פשטות היא עניין יחסי ותרבותי, תלוי מאוד למה מתרגלים וגם תלוי מאוד מי אמור לתחזק את הקוד וכמה היכרות יש בין הכותב לקורא.
מתכנת אמיתי לא משתמט, הוא משכתב קוד מסובך בלילה (עדיף כשהוא נורא עייף) ובבוקר הכול שוב פשוט.
קנט בק חושב שאתם מסבכים את הדברים. הקוד משקף את היכולת של כותבו להתמודד עם הסיבוכיות של הבעיה שאותה הוא פותר.
מערכת מורכבת היא כזו שבה ישנן הרבה יחידות קטנות ופשוטות מחוברות יחדיו.
4 כללים לדיזיין פשוט. כן, רק ארבעה. פשוט, לא ? הפרחים לקנת בק.
קוד פשוט נשאר כזה לאורך זמן, גם עוד שנה הוא יהיה פשוט (גם ובעיקר למי שכתב אותו …)
קוד פשוט, בניגוד לרוב דיירי האח הגדול, יודע להסביר את עצמו מצוין
פונקציונאליות פשוטה אפשר להסביר בקצרה.
בשביל קוד פשוט אפשר לכתוב טסטים קצרים.
אבדי והחבר'ה מדברים על קוד יפה. הם גם מתאהבים בקוד והקוד אוהב אותם. מה שנקרא - Get a (chat) room
ישנם כלים המיועדים לנתח את הסיבוכיות של קוד.
יישום קפדני של Coding conventions מקל מאוד על ההבנה של קוד.
הרבה פחות נעים לחרב בניין יפה - וזה נכון גם לגבי קוד.
תמיד קשה לגשר על פערי שפה.
האם יש מדדי נחשלות לחברות תוכנה (הי, את זה אני הצעתי !) ? מיילים, מדדי סיבוכיות קוד, כמה קוד מכסים הטסטים, כמות שעות דיבוג, כמות ההערות בקוד, כמות האיתחולים מחדש של שרתים, כמה ישיבות יש בשבוע, כמה זמן לוקח לגלות שהקוד שבור, כמה רועשת סביבת העבודה, האם אתם משתמשים בכלים הכי טובים וכו' וכו'. גם לג'ואל ספולסקי יש מה לומר בעניין.

קצרים

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

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

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

Ember.js

Less - פלטפורמה להקלה על העבודה עם CSS

הקובץ נמצא כאן האזנה נעימה

תודה רבה ליותם אורון על התקצור!

127 Gogobot

ori@reversim.com (Ran Tavory & Ori Lahav) — Mon, 05 Mar 2012 07:01:00 +0000

בחללית האם - רן ואורי, על כן השיגור - אבי צוראל
אבי מפתח אפליקציות מבוססות אינטרנט ב-RoR, עוסק גם בייעוץ לחברת Gogobot (בפועל עובד במשרה מלאה), בזמן האחרון עוסק בעיקר בתחומים של ביצועים והטמעה של תרבות הפיתוח בחברה.
גוגובוט ממליצה על אתרים ואטרקציות תיירותיות בהתאם לגרף החברתי של כל משתמש.
והרי סקופ: אורי ורן לא עושים צ'ק-אין. תזכרו איפה שמעתם את זה ראשונים.
אז באמת, איך עושים דברים בגוגובוט ?
הצוות מבוזר בכל העולם: לונדון, ברזיל, ישראל, סן-פרנסיסקו (את זה ג'ניפר לופז העתיקה מגוגובוט), העבודה א-סינכרונית לגמרי בצ'אט טקסטואלי (מבוסס Campfire). יחד עם זאת, פגישת מתכנתים יומית ושבועית בסקייפ (בשביל רכילות וזה).
בפגישה השבועית מתכננים את השבוע הבא. כמו אלון מזרחי, גם ב-גוגובוט חיים משבת לשבת.
השימוש בצ'אט נותן תיעוד של העבודה היומיומית בחינם. וחוץ מזה, לקרוא לחבר שלך שיושב לידך שיבוא יראה משהו זה ממש לא מנומס ועושה מלא רעש.
בתוך הצ'אט יש יצור - ה-gbot. אביו הוא Hubot. הוא יודע לעשות deploy לכל שרת, יודע לנקות cache, לנקות את ה-cdn, יודע להריץ טסטים ב-CI, יודע להגיד כמה באגים פתוחים, כמה משימות פתוחות, פאנלים-שמשות-אבק. בקיצור, חלומו של כל מג"ד.
ההנהלה משתדלת לא להפריע למתכנתים. במקרים קיצוניים שולחים מייל.
אין קשר בין מה שצריך לעשות בשבוע הקרוב לבין מה שיהיה deployed בשבוע הקרוב.
CI נעשה באמצעות Capistrano. גם איתו gbot יודע לדבר.
בשביל לנטר את השרתים משתמשים ב-Pingdom וב-Pagerduty. הטלפון ירדוף אותך עד הבית. בכל מיני מקרים של רגרסיה בביצועים, יישלחו מיילים/סמסים/טלפונים/גובה מסים עצבני עם מבטא לא ברור, הכול לפי דרגת החומרה. ביצועים מנטרים עם New Relic או ישירות בקוד.
אין דד-ליין. אין מיילסטונס. הרעיון הוא פשוט לעשות את מה שאפשר כמה שיותר מהר באיכות הכי טובה שאפשר. הנרי גאנט מתהפך בקברו. אחרי טראומה מספיק גדולה, גם לכם זה יכול לקרות.
זובור יש לא רק בצבא. נו, אז הפלת את הפרודקשיין, אז מה - לך תבכה בצד, תנגב את הדמעות ותתקדם הלאה.
כמו שאמר אושו - כשהנעל מתאימה, חפש את האישה היחפה אצל הסנדלר החכם ולמד דרכיה (או, במלים אחרות - כששיטת הפיתוח מתאימה לאנשים ול-problem domain, השמיים הם הגבול, ואפילו אפשר ממש ליהנות).

הקובץ נמצא כאן האזנה נעימה

תודה ליותם על התקצור.

126 Android 2

ori@reversim.com (Ran Tavory & Ori Lahav) — Thu, 01 Mar 2012 09:36:00 +0000

פרק 126 – שיח עם רועי בן יוסף, מפתח Mobile ואוונגליסט לפיתוח באנדרויד ובקוד פתוח

נושא: Android – שיחה שניה בנושא

- קיבלנו מספר טיפים לפיתוח ב-Mobile הקשורים ל:

o תגובתיות (2-3 שניות) אשר ניתן ליישם על ידי שימוש נכון ב-Multi-Threading וב-UI Thread

o טעינת מידע Just In Time או במקרים מסויימים Ahead of time ו/או שימוש חוזר במידע שנטען בעבר ולא אמור להשתנות, מתוך מטרה להמנע מ-Timeout שעלול להיווצר בזמן הניווט של המשתמש

o כלים למדידת Response Time ולסימולציית פעולות של משתמש

o שימת לב לניהול צריכת הסוללה וניצול מינימלי של חבילת הגלישה: מתי להשתמש באיכון מיקום ב- GPS או ב-WIFI (Network/Location Management), צמצום צריכת נתונים כשהמסך כבוי (המשתמש במילא לא רואה אותם...) ושימוש ב-BroadcastReceiver, זיהוי Pattern שימוש והתאמת אלגוריתם האפליקציה למצבים שחוזרים על עצמם (לדוגמא: במידה והמיקום חוזר על עצמו לא צריך תמיד לחפש את כל המסעדות בסביבה אלא אחת ל..., או לחלופין, לייצר Service אשר מספק חתימה לפיה ניתן לדעת אם הנתונים השתנו ומתי, וכך לאפשר לאפליקציה להחליט איך לפעול)

- ניהלנו שיחה קצרה על בדיקות תוכנה באנדרויד והזכרנו את:

o MonkeyRunner המאפשר לבצע מגוון פעולות UI.

o הזכרנו את ACRA – ספריה המאפשרת שליחת Logs של UI Flow, Crash Report ומידע אפליקטיבי נוסף ממכשירי קצה – ניתן להפיץ את התוכנה בשלב הבטא לצורכי Friendly User Trial בין חברים לפני שמפיצים את התוכנה ללא יכולות אלה לכלל הציבור (כדי להמנע מבעיות חוקיות). ייתרון נוסף של ACRA בשלב הבטא הוא שהיא מונעת את הדיווח לאנדרויד מרקט במקרה של קריסת אפליקציה, כך שלמעשה לא נאבד רייטינג בזמן הבדיקות.

o הזכרנו את שירות TestFlight מעולם ה-iPhone Development אשר בשלב זה קיים באנרויד מרקט באופן מצומצם יותר וכנראה עדיין לא מספק

o בנושא בדיקות אוטומטיות הזכרנו את Android Test Project החינמי אשר משתמש ב-JUnit ומאפשר ביצוע Unit Test ו-UI Test (כמובן שדורש ניתוח מערכת מתאים ופיתוח נוסף מראש כחלק מפרדיגמת ה-Test Oriented Programming או Test Driven Development).

- הזכרנו מספר ספריות פיתוח שימושיות למפתחי אנדרויד:

o הזכרנו את droid-fu, ספריית utility (ניתנת להורדה כאן) אשר נותנת מגוון כלים שימושיים ל-everyday needs.

o הזכרנו ספריות לניתוח JSON כגון Gson של גוגל ולעומתה Jackson אשר מציגה ביצועים טובים יותר וצורכת פחות זכרון (ראה כתבה בנושא כאן)

- דיברנו על הדרך ל"שחרור" אפליקציות באיטרציות – האם זה אפשרי?

o To make a long story short –the iteration model does not fit well to application development and it is different than service delivery, however, there are still some considerations that shall be taken

o יש לקחת בחשבון את זמן ה-Review ולכן קשה מאוד לתכנן delivery בזמן הקצר מ-3-4 ימים וגם כאן תלויים בגורם חיצוני. תחת ההנחות הנ"ל ובייחוד לאור העובדה שמדובר באפליקציה (בשונה משירות Web אשר ניתן לעדכן ללא עירוב המשתמש הסופי), חשיבות התכנון מראש גדלה משמעותית.

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

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

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

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

פינת המודעה הקטנה:

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

פרטים בסוף ה-Podcast או כאן או באימייל ל-ran.b@matomy.com

הקובץ נמצא כאן האזנה נעימה

תודה רבה לגל על העזרה בתקצור!

125 The Lean Startup

ori@reversim.com (Ran Tavory & Ori Lahav) — Thu, 09 Feb 2012 10:30:00 +0000

ממנגלים: אורי ורן
על האש: הספר The Lean Startup, מאת אריק ריס
Lean Startup היא תנועה, המפגשים נערכים בכל העולם - וגם בארץ! פרטים ביציאה אצל גיא נירפז מ-Totango
העקרונות של Lean Startup (להלן - ל"ס), נכונים גם לצוות קטן בחברה גדולה, לא רק לסטארטאפ ולא רק לעולם התוכנה
כמו כל דבר טוב, חלק גדול מהמתודולוגיה של ל"ס מגיע מטויוטה
המתודולוגיה מגיעה מהשטח ומניסוי וטעייה, לא מהאקדמיה
אריק ריס עבד בחברת imvu.
לפני שמשקיעים את המשאבים - תעשו וולידאציה.
When the going gets tough, the tough gets a pivot: אם הדברים לא הולכים טוב (והנחות היסוד לא מתקיימות) - אולי זה הזמן ל-Pivot ?
כל יום חייב לראות עצמו יזם כאילו יצא ממשרדו של ה-VC והשקיע את מעותיו המתמעטות בכיוון הנוכחי שאליו הולך המוצר.
המשוב של Early adopters מאוד חשוב.
אליבא ד'אריק, מטרת הסטארטאפ היא להגיע ל-Validated learning, על ידי מחזור המורכב מ-Build-Measure-Learn.
השאיפה היא לטעות כמה שיותר פעמים, ו-Continous Deployment מאוד עוזר לזה.
איך עושים מטריקות ? איך מודדים ? איך מוכיחים ששינוי כלשהו הועיל/הזיק/לא שינה כלום ?
החיבור בין R&D, Product, Market מאוד חשוב.
ההבנה על איזה מספרים להסתכל ומה החשיבות שלהם היא אמנות, בסופו של דבר צריך לזקק את הנתונים ל-3-4 מספרים בעלי חשיבות
למה-למה-למה-למה-למה. זה לא האחיין הקטן שקודח לכם, זו השיטה לרדת לשורש העניין (אבל עזבו אתכם, המחשב תמיד צודק - זה אנחנו, בני האדם, שתמיד אשמים בסוף)
ל"ס טוב לכם - שתו ותיהנו !

תודה רבה ליותם אורון על התקצור!

הקובץ נמצא כאן האזנה נעימה

Final Class 15 OOP FTW

ori@reversim.com (Ran Tavory & Ori Lahav) — Thu, 09 Feb 2012 10:22:00 +0000

הנושא היום: פרדיגמות בתכנות מונחה עצמים (Object Oriented Paradigm)

בהשתתפות יונתן, איתי, ערן, אורי, ישי ורן.

לאחר דיון קצר בניסיון לזהות ממתי המונח קיים ומה היו השפות הראשונות בתחום, הזכרנו מספר תכונות חשובות של שפות object oriented כמו:Encapsulation, Inheritance, Polymorphism .

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

הזכרנו מספר שפות תכנות מונחה עצמים שבהן הגדרות העצמים הן סטטיות (עושות שימוש בהגדרת Class), כגון: C++, Java, C#, ולעומתן הזכרנו אתJavascript שיש לה תכונת prototyping מפותחת ואשר למעשה לא עושה שימוש ב-Classes אלא מתבססת על אובייקטים אשר ניתן לשנות אותם באופן דינמי.

סיבוכיות השפה: דיברנו על כך שהשימוש בשפות מונחות עצמים נועד לפשט דברים על ידי מתן כלים לשימוש חוזר בקוד ושימוש בכל התכונות שהזכרנו (ניתנה גם דוגמה לבעיית סידור 8 מלכות על לוח שחמט אשר פתרונה נראה משמעותית פשוט יותר כאשר משתמשים ב-object oriented). לעומת זאת הזכרנו גם שמעבר להפשטה, השימוש בשפות גם יוצר לפעמים סיבוך בכתיבת והבנת הקוד, אשר אינו תמיד חד משמעי וברור כמו שניתן לצפות מקוד C למשל (הוזכרו בעניין זה דברי לינוס טרוולדס בגנות C++, וג'ואל ספולסקי – Leaky abstraction). לשם המחשה הסתכלנו על עקרון ה-Inheritance אשר מתכנתים רבים "נופלים בפח" של ייצור אובייקט בסיס ואובייקטים שיורשים ממנו המרחיבים את תכונותיו עד כדי הוספת מתודות שאינן קשורות אליו כלל, מהלך שמוביל לשימושיות מוגבלת וסגנון כתיבת קוד שהולך ומסתבך. הוזכר התהליך האיטרטיבי של יצירת מבנה האובייקטים הנכון, אשר משפיע בעצם על מורכבות הפתרון וכמו כן הצורך לעשות refactoring לפתרון.

הוזכרו מספר טכניקות המסייעות לקבלת החלטה האם מבנה האובייקטים נכון או לא, לדוגמא: גודל/אורך המתודות, כמות הפרמטרים והרלבנטיות שלהם, מי משתמש בהן (מאותו אובייקט או מאובייקט אחר), צורת וכמות השימוש ב-members, וכו'. דנו בקיום חוקים לבחינת קוד אשר הופכים את תהליך ה-design למשהו טכני, תהליך אשר משתפר עם הזמן והניסיון והופך לאומנות (ההחלטות לא רק טכניות). הזכרנו את הספר Pragmatic Thinking and Learning של Andy Huntהמזכיר נושאים כמו שיפור למידה ועל הצורך של מתלמדים להשתמש בסט חוקים אשר הולך והופך יותר ויותר לאינטואיציה ככל שהם הופכים ליותר מקצוענים. דנו במפגש Code retreat with Corey Haines ועל הדינמיקה והתרגול שהיו במפגש. באותו הקשר דיברנו על נתינת שמות לאובייקטים, התרגול של מחיקת קוד וכתיבתו מחדש, הקשר בין תיעוד ל-refactoring, אי שכפול קוד, שימוש ב-pair programming ועוד.

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

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

סטטיסטיקות ומספרים:

1. שפות פופולריות ב-2011 – מעניין לראות את החלוקה בין השפות השונות, למרות שיש סתירה מסוימת בין שני האתרים הבאים:

a. http://blog.codeeval.com/the-most-popular-programming-languages-of-201

b. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

2. אינטרנט במספרים – 2011

a. http://royal.pingdom.com/2012/01/17/internet-2011-in-numbers/

לינקים נוספים:

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

2. Overview of the object-oriented paradigm

3. דו"ח הבוחן את השימוש בפרדיגמת פיתוח מונחה עצמים – Has the object oriented paradigm kept its promise?

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

הקובץ נמצא כאן האזנה נעימה

123 final class 14

ori@reversim.com (Ran Tavory & Ori Lahav) — Sat, 07 Jan 2012 12:49:00 +0000

בפרק 12, 14 של המחלקה הסגורה השתתפו – רן – invi, אורי outbrain, אורי – Picscout, ערן outbrain, ארז outbrain

נושא: Superstar vs Team Player

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

אזכורים בנושא מהאינטרנט:

Superstar vs. Team: How Manager Mistrust Prevents Growth and Winning

Which Would You Prefer - A Great Team Player or a Demanding Superstar Performer?

פינת המודעה הקטנה:
הצגת רשימת משרות פתוחות בחברת Picscout. פרטים ב-Podcast או כאן.

קצרים על טכנולוגיה:

דיון קצר על WebSockets - פרוטוקול מבוסס HTTP הנמצא כעת בשלב מתקדם להפיכה לסטנדרט. הפרוטוקול מאפשר ייצור תקשורת דו-כיוונית בין clients לשרת תוך שמירה על סקלאביליות של השרת (לא פותח connection HTTP עבור כל שיח).
דיון קצר על Tornado – Web Server אשר ממומש ב-Python.

רשימת אירועים קרובים:

SCISR Meeting with Corey Haines

Code Retreat I - Corey Haines – Take I

Code Retreat I - Corey Haines – Take II

תודה רבה לגל כהן על התקצור!

הקובץ נמצא כאן האזנה נעימה

122 - algo trading

ori@reversim.com (Ran Tavory & Ori Lahav) — Wed, 28 Dec 2011 21:17:00 +0000

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

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

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

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

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

כותבים בכל השפות (יש אחת שאפילו כותבת ב-OCaml) - היעילות והמהירות היא מעל הכול.

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

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

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

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

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

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

סוחרים כשהבורסה סוחרת - גם אם המסחר מתחיל בשתיים בלילה. כל לילה. כל הלילה.

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

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

פרק זה תומלל ותוקצר בעזרתו האדיבה של יותם אורון. תודה יותם!

הקובץ נמצא כאן האזנה נעימה

119 final class 13

ori@reversim.com (Ran Tavory & Ori Lahav) — Sun, 25 Dec 2011 11:19:00 +0000

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

אוטומציה? למה בכלל? מתי כן? מתי לא? באילו כלים אנחנו משתמשים?

אוטומצית תהליך הבילד - TeamCity, או ANT הוורסטילי, או דווקא Maven הקשוח, XCode Gradle, Rake או שמא כלי שבנינו מעליהם?

מהן הן שלל הדרישות שכלי בילד צריך לדעת לענות עליהן (תלויות, שפות מרובות, קימפול מבוזר)?

קצת על כלי בילד ואוטומציה שבנינו בעצמנו.

סיפרנו על STAF/STAX - כלי אוטומציה לסביבה מבוזרת. וגם הזכרנו: BuildForge, וכלי לבדיקת ממשק משתמש RFT.

שאר ירקות בסלט: Maven's UberJAR, PMD, FindBugs

קצרים:

Scala - Play Framework 2.0 beta integrated into typesafe’s stack

ביצועים הן בעיה בסקאלה? Yammer חותכת מסקלה בחזרה לג’אווה.

What tools do developers actually use?

פייסבוק משחררת גרסה מהירה ב-60% יותר של ה-VM שלה ל- PHP הלא הוא HipHop

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

HP to opensource WebOS

הקובץ נמצא כאן האזנה נעימה

121 Kickstarting invi

ori@reversim.com (Ran Tavory & Ori Lahav) — Fri, 23 Dec 2011 13:09:00 +0000

החלטנו לזרום עם פרק מעכשיו לעכשיו ולהקליט על פרק על מה שרן עובר עם ההתחלה של

invi.

רן סיפר על invi ומה היא מתעתדת לעשות. בגדול... "למי בא באולינג? "
איך הולך כרגע? נרשמים? איך אנשים יודעים על זה?
קהילות ומעגלים מקומיים - תנאי הכרחי לאפליקציה הזו. מה התנאי ההכרחי לאפליקציה שלך?
אימות הצורך (ואלידציה) - האם לפנות למי שאוהב אותנו או לעולם כולו? והסיפור של הואלידציה של אאוטבריין.
MVP - מה זה והאם כדאי להשקיע ב"פינישים"?
Early adopters - מי הם? מי אוכל את הפיתיון?
מתי משהו מוכן? כנראה אתמול.
דוגמה מהחיים - איך זה תורם לואלידציה? האם מותר לאכזב לקוח?
הכל עניין של קליקות מקומיות - כמו פריימריז בליכוד.
מה קורה עם גיוסי הון?
UpWest
תחושות הבטן של מתי לגייס. למה בכלל לגייס?
גרפים ומספרים מחזקים את הסיפור שלך בגישה לגיוס.
אנדרואיד? אייפון? ממשק אינטרנטי?
המלצה על פודקאסט בנושא.
שיהיה בהצלחה!

הקובץ נמצא כאן האזנה נעימה

120 android

ori@reversim.com (Ran Tavory & Ori Lahav) — Thu, 22 Dec 2011 12:36:00 +0000

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

איתנו באולפן הווירטואלי רועי בן יוסף, גורו אנדרואיד בקנה מידה עולמי מחברת VidMind

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

הקובץ נמצא כאן האזנה נעימה