ng-conf 2015 – סיכום היום השני

בהמשך לסיכום היום ראשון של ng-conf 2015, הגיע הזמן לסכם גם את יום ההרצאות השני.

Keynote

הועבר ע"י: MIŠKO HEVERY ו- RADO KIROV

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

Binding to the Cloud with Falcor

הועבר ע"י: JAFAR HUSAIN

ג'פר הוא Tech-Lead ב- Netflix וחבר בקבוצת TC39 והוא דיבר על ספריה שהם מפתחים ב- Netflix המשלבת ארכיטקטורה חלופית ל- MVC. הוא העלה טענה שבעקבות אופן השימוש באפליקציות וואב כיום – MVC לא באמת מצליחה במלאכת ה- Separation of Concerns, ה- View תלוי ב- Controller ולכן שינויי תצוגה רבים מחייבים גם שינויים ב- Controller. הוא הציג ספריה שהם עובדים איתה בנטפליקס בשם Falcor המפשטת את צורת העבודה מול השרת ומאפשרת לנו לעבוד עם המידע כאילו הוא נמצא אצלנו מקומית. הוא סיים עם משפט שבו אמר: "[באינטרנט של היום] אתה כבר לא מקבל דברים, אתה עושה דברים" והדגיש את הצורך בשינוי צורות החשיבה והעבודה שהיו קיימות בשנים האחרונות.

TypeScript and Angular 2.0

הועבר ע"י: JONATHAN TURNER

גו'נתן הוא ה- Program Manager של TypeScript במיקרוסופט, בהמשך להכרזות מאתמול על השקת אנגולר 2 והמעבר ל- TypeScript, הוא נתן סקירה נוספת של השפה וכתב איתה אפליקצית אנגולר 2. גו'נתן הסביר על הפיצ'רים השונים בשפה ואיך הם עובדים ואז קפץ לדמו שבו הוא כתב אפליקצית Todo list באנגולר 2 באמצעותה, במהלך הדמו הוא המשיך להסביר איך עושים דברים וסיים עם התוכניות לעתיד והפיצ'רים הנוספים שיגיעו ממש בקרוב, ביניהם תמיכה רחבה יותר ב- ES6 ובגרסה הבאה גם פיצ'רים מ- ES7.

What's new in ngAnimate

הועבר ע"י: MATIAS NIEMELÄ

מטיאס, חברנו מ- yearsofmoo, דיבר על אנימציות באנגולר ובעיקר על השינויים שנעשו ב-ngAnimate במסגרת אנגולר 1.4. הוא הציג את angular.animate, הסביר על callbacks שניתן להעביר על מנת לזהות מתי נגמרת אנימציה, הציג את הפיצ'רים anchors ו- ngTimeline וסקר יכולות נוספות שצפויות להגיע בגרסאות 1.5 ו- 2 של אנגולר.
קישור למצגת: http://yom.nu/ng-conf-2015-slides

Building Platforms with Angular

הועבר ע"י: JEN BOUREY

ג'ן היא ה- Tech-Lead של Google's Cloud Platform והיא דיברה על האתגרים בפיתוח אפליקציות גדולות ובעיקר על שיתוף קוד, מניעת התנגשויות וביצוע שינויים רוחביים. במהלך ההרצאה ג'ן הציגה את הספריות השונות שהם משתמשים בהן, ציינה שהפרויקט שלהם כולו כתוב באנגולר והוא מכיל כ- 200,000 שורות קוד ו- 25mb של ג'אווה-סקריפט. היא גם הציגה את מבנה הצוותים, הסבירה על מערכת ניהול החבילות שלהם, הציגה את אסטרטגית המעבר שלהם לאנגולר ולבסוף את הבדיקות שהם עורכים לאחר כל שינוי שנעשה בקוד.

Reactive all the things

הועבר ע"י: BEN LESH ו- MARTIN GONTOVNIKAS

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

Angular 1.3 meets Angular 2.0

הועבר ע"י: MICHAŁ GOŁĘBIOWSKI ו- ANDREW JOSLIN

מיכאל ואנדרו הציגו דמו שבו הסבירו כיצד לבצע מיגרציה מאנגולר 1.3 לאנגולר 2.0. הם המליצו להשתמש ב- ES6 כבר היום על מנת להקל על התהליך, להעזר בכלים כמו babel, לעבוד עם הגרסאות החדשות ביותר של אנגולר ולאמץ את הראוטר החדש. במהלך הדמו הם העבירו Service פשוט מאנגולר 1 לאנגולר 2 וסקרו את השינויים שנעשו במסגרת ההמרה, לאחר מכן הם עשו אותו דבר גם עם Directive ובנוסף הציגו את angular.component שעשוי להקל עלינו עוד יותר.

Digging into Angular Style Guide Decisions

הועבר ע"י: JOHN PAPA

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

Better i18n for your Angular apps

הועבר ע"י: CHIRAYU KRISHNAPPA ו- PASCAL PRECHT

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

Badges? We don't need no stinkin' badges!

הועבר ע"י: LUKAS RUEBBELKE ו- GEOFF GOODMAN

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

Build an Angular Material App

THOMAS BURLESON & NAOMI BLACK

הרצאה מעולה על Angular Material מאת תומאס ונעמי מגוגל. הם סקרו את הפרויקט, הסבירו למה חשוב לשים לב כשעובדים עם Material Design וסקרו את הפיצ'רים השונים של הספריה, ביניהם ה- Directives המובנים, התפריטים וההתנהגות הרספונסיבית. הם גם הציגו את הדוקומנטציה, הציגו את התמיכה של הספריה בנגישות, סיפרו מה עדיין חסר, הבטיחו שישלימו את הרוב עד הקיץ ולבסוף ציינו שהם עובדים במרץ על מנת לתמוך גם באנגולר 2. מי שרוצה להתחיל לעבוד עם הספריה, יש פרויקט ב- ES5 ופרויקט ב- ES6 שרק מחכים לכם.

Angular + React = Speed

הועבר ע"י: DAVE SMITH

דייב הציג את הבדלי המהירות ביוז-קייס מסויים בין אנגולר, React ואנגולר + React ביחד. הוא התחיל עם הסבר של 90 שניות על מה זה React והציג אפליקצית לוח שנה שבה פיצ'ר מסויים מומש במספר דרכים שונות. הוא השווה בלייב את המהירות בין הגרסאות השונות, הסביר שהיתרונות העיקריים ב- React במקרה הזה הם המהירות בזמן העלייה הראשוני ובשינויים, בעוד החסרונות הם בגודל הספרייה הגדול יחסית של 500kb ובהוספת framework נוסף לפרוייקט. לסיום דייב הציג את אותו רכיב בדיוק באנגולר 2, והמהירות הייתה מדהימה.

Change Detection Reinvented

הועבר ע"י: VICTOR SAVKIN

ויקטור סקר את הארכיטקטורה החדשה באנגולר 2 בכל מה שקשור לזיהוי שינויים וזרימתם במערכת. הוא הסביר את המבנה הפנימי החדש ומדוע לא צריך יותר מ- digest בודד על מנת לעדכן את כלל המערכת. הוא הסביר את היתרונות בשימוש ב- Immutable Objects ו- Observables באלגוריתם החדש ואמר שהוא מהיר פי 3-10 יחסית לאנגולר 1.3. ויקטור גם ציין שלא חייבים להשתמש ב- Immutable Objects או ב- Observables ואפשר גם בלעדיהם, ומי שרוצה יכול אפילו לשלב גם וגם. הוא גם כתב בעבר פוסט בנושא שמי שמעוניין מוזמן לקרוא.

(Super)Power Management

הועבר ע"י: IGOR MINAR

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

Angular Team Panel/QA

הועבר ע"י: GOOGLES

בסיישן שאלות ותשובות הצוות ענה על מגוון שאלות שהופנו אליהם מהקהל באולם ובאינטרנט. מס' דברים מעניינים שנאמרו הם שחשוב להם לתמוך ב- lazy loading של קבצים והם יעבדו על מנת שזה יהיה קיים כבר באנגולר 1.4, הם ביקשו עזרה מהקהילה עם תיקוני באגים ופיתוח של פיצ'רים נוספים ולשאלה על העלמותם של ה- Filters הם השיבו שהם לא נעלמו ובאנגולר 2 הם נקראים Pipes, למי שחשש.

לסיכום

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

את הפלייליסט עם כל ההרצאות ניתן למצוא כאן:

ng-conf 2015 – סיכום היום הראשון

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

Welcome

הועבר ע"י: BRAD GREEN ו- IGOR MINAR

בראד הינו מנהל פיתוח בגוגל, בין היתר הוא מנהל את הפרוייקט של אנגולר, ואיגור כרגע מוביל את אנגולר 2. שתי הכרזות משמעותיות קיבלנו מהם בהרצאה הזו, הראשונה הייתה בנוגע ל- Angular 2 – שוחררה גרסאת Alpha Preview והושק אתר חדש. והשנייה הייתה בנוגע ל- AtScript – גוגל תשתף פעולה עם מיקרוסופט, AtScript ישולב לתוך TypeScript וישוחרר ב- TypeScript 1.5. בנוסף, נאמר שהקבוצות של Angular ו- Angular Dart יאוחדו, כעת כולם יעבדו עם TypeScript ובסופו של דבר הקוד של אנגולר יומר הן ל- JavaScript והן ל- Dart, מה שיאיץ את פיתוח הפריימוורק ויעשה טוב לכולם. שמחתי לשמוע גם שהגרסה החדשה של אנגולר תושק עם Style Guide רשמי, תקח את עניין ה- performance ברצינות ותגיע עם Immutable data structures.
בנוגע למיגרציה מאנגולר 1 לאנגולר 2, מה שמדאיג ומפחיד לא מעט מתכנתים בקהילה, בראד ציין כי בגוגל יתחילו להעביר אפליקציות פנימיות לגרסה החדשה בסביבות חודש מאי, במהלך הדרך הם ילמדו, יסיקו מסקנות וימשיכו לעדכן את הקהילה. נראה שהם לוקחים את העניין הזה ברצינות.

State of 1.x

הועבר ע"י: PAWEL KOZLOWSKI ו- LUCAS GALFASO

פבל ולוקס סקרו את אנגולר 1 מבחינת הקהילה, המצב הקיים והחזון של הפרויקט לעתיד. הם ציינו ש- 50% מה- commits באנגולר בעצם הגיעו מהקהילה, הכריזו על 2 חברי ליבה (core contributors) חדשים, ביניהם נציג ישראלי ראשון – שחר תלמי. הם גם דיברו על כל מיני שיפורים ושינויים שנעשו (מפורטים במצגת בהמשך), אמרו שגרסת 1.4.0-RC.0 תגיע כבר בשבוע הבא והמליצו לכולם לעדכן לגרסאות החדשות ביותר ולא להשאר מאחור. בנוסף הם גם דיברו על המשך הפרויקט לגרסא 1.5 ואולי גם 1.6 וציינו שחלק מהפיצ'רים בגרסאות הבאות יהיו בעצם פיצ'רים שילקחו מאנגולר 2, כך שגם מי שישאר עם הגרסא הקיימת יוכל לקבל חלק מהפיצ'רים המגניבים של הגרסא החדשה. לסיכום, הם קראו לכולנו לקחת חלק פעיל בפרויקט, להציע פיצ'רים, לעבוד על באגים ולעזור לפרויקט לצמוח.
קישור למצגת: http://goo.gl/G5Kwkw

The new router

הועבר ע"י: BRIAN FORD

בריאן הוא הבחור שאחראי על הראוטר החדש. הוא התחיל עם דוגמאת קוד שבה הוא סקר אותו, עבר על ה- API והסביר איך הוא עובד כבר בגרסא 1.4. הוא אמר שהם ראו שהמון אנשים מאוד אוהבים את ui-router והם לקחו ממנו השראה בתכנון הראוטר החדש, ואפילו ציין שהם יעבדו על מיגרציה מ- ui-router במטרה להקל על הקהילה ולעזור לכולם לשדרג. הוא הוסיף שהראוטר החדש משתמש ב-route-recognizer, נתן קרדיט ל- Ember שפיתחו אותו ואמר תודה ל- Rob Eisenberg ולחברי צוות נוספת על עזרתם. למי שלא יכול לחכות, עלתה גם דוקומנטציה ראשונית.

Prototyping with Angular? YES!!

הועבר ע"י: KELLY KNIGHT ו- DIRK GINADER

קיילי ודירק הם UX Engineers בגוגל והם דיברו על איך הם עובדים עם אנגולר ליצירת prototypes והציגו מס' שיטות שהם משתמשים בהן. הם דיברו על angular-google-analytics – פרויקט שעוזר לשלב את Google Analytics באפליקציות אנגולר בקלות, הזכירו את cubic-bezier – אתר שמאפשר לבנות אנימציות ולראות אותן בלייב, הם הראו כיצד הם בנו prototypes הניתנים לשינוי בקלות באמצעות ה- URL, ואפילו הציגו prototypes הנשלטים באמצעות קול (ע"י Web Speech API), הם גם דחפו לשימוש ב- ngAria, מודול המשפר את נגישות האפליקציות שלנו בצורה כמעט אוטומטית ומאוד פשוטה. לסיום הם המליצו להשתמש ב- Google Sheets בתור דטא-בייס ל- prototypes בשל היותו מאוד פשוט וקל להטמעה.

Fast from the Start

הועבר ע"י: JEFF CROSS

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

Creating Container Components with Web Components and Angular

הועבר ע"י: KARA ERICKSON ו- RACHAEL L MOORE

ריצ'ייל וקרה הסבירו כיצד הן משתמשות ב- Directives במהלך העבודה שלהן. הן הסבירו קצת על Web Components ו- Shadow DOM והציגו יוז-קייס לדוגמה, הן סיימו עם השוואה בין Directives באנגולר 1 ל- Component Directives באנגולר 2.

ngTasty

הועבר ע"י: LEONARDO ZIZZAMIA

בהמשך להרצאה על performance ו- benchpress, לאונדרו הסביר כיצד יש להתייחס לביצועים כאשר מפתחים רכיבים שצריכים לעבוד מהר. הוא הסביר כיצד לתכנן, למדוד ולזהות מקומות לשיפור ונתן סיישן hands-on שבו הוא הריץ את benchpress על ngTasty והסביר כיצד זה עזר לו במהלך הדרך כשהוא פיתח את הספריה.

TypeScript and ES6

הועבר ע"י: DAN WAHLIN ו- ANDREW CONNELL

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

Community Building How-To: Make More Angular Devs Now

הועבר ע"י: JUDY TUAN

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

ng-wat?

הועבר ע"י: SHAI REZNIK

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

Accessibility Design Made Easy

הועבר ע"י: JULIE RALPH

ג'ולי מובילה את Protractor, כלי לבדיקות E2E המיועד לאפליקציות אנגולר. במהלך ההרצאה גו'לי דיברה על plugins ל- Protractor והסבירה כיצד הם עובדים, אך עיקר ההרצאה היה בנוגע לנגישות (Accessibility) – ג'ולי הסבירה מדוע המקום הנכון לבצע בדיקות נגישות זה בבדיקות ה- E2E, הסבירה כיצד להשתמש בפלאגין לבדיקות נגישות החדש, כיצד להפעיל את האפשרות ב- Chrome DevTools ועברה בקצרה על הפלט של בדיקה לדוגמה שהיא הריצה על הדוקומנטציה של אנגולר.
קישור למצגת: http://goo.gl/wgXRwb

Why Realtime Matters

הועבר ע"י: JAMES TAMPLIN

ג'יימס הסביר מה זה בעצם Real-time data, סקר את Firebase והסביר כיצד הוא עובד. במהלך ההרצאה ג'יימס הכריז על ההשקה של AngularFire 1.0 ופירט על הפיצ'רים השונים שהספריה מכילה. פיצ'ר נחמד שהוצג היה בהקשר של infinite scroll והוא הוצג באפליקציית ionic – ג'יימס הראה כיצד במס' שורות קוד בודדות הוא משלב pagination ומושך דינאמית מהשרת מידע נוסף במהירות ובקלות. לסיום ג'יימס הציג 2 פיצ'רים נוספים – הראשון נקרא Private Backups והוא מאפשר לנו לייצא את כל המידע שלנו מ- Firebase, השני הוא SEO Support והוא מיועד לשפר את ה- SEO של האפליקציה שלנו ולהפוך אותה נגישה יותר עבור מנועי החיפוש השונים.

ngModelOptions in 5 minutes

הועבר ע"י: KENT C. DODDS

קנט הציג את ngModelOptions, פיצ'ר שהתווסף בגרסה 1.3 ומאפשר לנו לשלוט על עדכון המודל מה- View. ב- 5 דקות קצרצרות הוא הסביר על הפיצ'ר והציג את ההגדרות השונות שניתן להחיל וסיים עם הפניה למאמרים נוספים ב- egghead, למי שרוצה להתעמק יותר.

How to Teach Angular to your Kids

הועבר ע"י: KATYA EAMES

קטיה פתחה במשפט: "היי, קוראים לי קטיה אימס, אני בת 16 ואני מתכנתת אנגולר" וזכתה למחיאות כפיים מהקהל, לאלו מכם ששמו לב לשם המשפחה שלה – כן, היא הבת של ג'ו אימס, אחד ממארגני ה- ng-conf. קטיה הסבירה כיצד היא נכנסה לתחום, איך היא השתלבה בזה במסגרת בית הספר, כיצד הגיעה לכתיבת האפליקציה הראשונה שלה באנגולר ואיך גם אנחנו יכולים ללמד את הילדים שלנו אנגולר. קטיה רצתה שנזכור 3 דברים עיקריים מההרצאה שלה: (1) אנגולר הוא דרך מצויינת ללמד ילדים לתכנת כי הוא מאוד מעניין, (2) אנחנו חייבים להיות מעורבים בתהליך (3) ושאנחנו אכן יכולים ללמד את הילדים שלנו אנגולר.

Run digest cycle in web worker

הועבר ע"י: DR. GLEB BAHMUTOV PHD.

ההרצאה של גלב התמקדה ב- scope וב- digest cycles באנגולר בהקשר של ביצועים. הוא הראה מקרה שבו ה- digest היה ארוך ותקע את הממשק, לאחר מכן הציג פתרון שבו הוא מעביר את ה- digest ל- web worker – כך שהוא ירוץ על thread אחר וישאיר את הממשק רספונסיבי.
קישור למצגת: http://slides.com/bahmutov/run-digest-cycle-in-web-worker

Sasqwatch is real

הועבר ע"י: WILLIAM SCOTT MOSS

וויליאם דיבר על performance ובעיקר על watchers ו- digest cycles. הוא הדגיש שלא צריך להשתמש בכל מה שאנגולר נותן ושצריך להתייחס להשפעות של היכולות המובנות על הביצועים – בהקשר הזה הוא עקץ עם משפט שמסכם את זה בצורה נהדרת לדעתי: "[כשאתם עושים הכל עם אנגולר] המשתמשים שלכם מאוכזבים, אבל לפחות המתכנתים שלכם עושים חיים". וויליאם המשיך והציג אפליקציה אמיתית שדרכה היא המחיש את הדברים, הוא פירט בנוגע לדברים שצריך ולא צריך לעשות, הציג best-practices והמליץ להשתמש באופטימיזציות הקיימות באנגולר 1.3 על מנת לשפר את ביצועי האפליקציה שלנו.

Ionic + Angular: Superpowers for Mobile App Development

הועבר ע"י: ADAM BRADLEY

אדם, היוצר של Ionic, הציג את המטרות והחזון של הפרויקט. הוא הציג מס' פיצ'רים מעניינים כמו collection-repeat העובד בדומה ל- repeat אך מרנדר רק את הפריטים המוצגים על המסך (כמו ב- UICollectionView של iOS), הסביר כיצד עובד ה- Cached views והציג פיצ'ר בשם "Swipe to go back" המאפשר לחזור אחורה באמצעות swipe כמו באפליקציות נייטיב. אדם הציג המון פיצ'רים נוספים, נתן live demo עם אפליקציה לדוגמה, הציג את ionicions – פונט לאייקונים, הראה כיצד ניתן לעבוד עם ה- console כאשר עובדים עם מכשירים אמיתיים ואימולטורים, הציג את ionic.io ואת השירותים החדשים שבאופק, הכריז רשמית על השקת Ionic 1.0 והדגיש שהצוות שלו יעבוד עם הצוות של אנגולר במטרה לתמוך גם באנגולר 2.
קישור למצגת: http://adamdbradley.github.io/ionic-present/

Angular Behind The Scenes

הועבר ע"י: RODRIC HADDAD

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

לסיכום

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

עדכון: למי שמעוניין, סיימתי לכתוב גם את סיכום היום השני של ng-conf 2015.

את הפלייליסט עם כל ההרצאות ניתן למצוא כאן:

המתכנת האידיאלי

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

מיהו המתכנת האידיאלי?

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

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

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

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

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

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

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

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

חוב טכני

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

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

חוכמת ההמונים

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

שאלון - המתכנת האידיאלי

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

לסיכום

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

מס' מקורות רלוונטים נוספים שנתקלתי בהם במהלך הדרך:

אשמח לשמוע את דעתכם.

כתיבת אפליקצית AngularJS 1.3 ב- ES6

כבר כמה חודשים שאני נלחם בחשק מוזר להתחיל לכתוב קוד ב- ECMAScript 6. היות ובשנתיים האחרונות אני עובד בעיקר עם AngularJS ולאור ההכרזות על AngularJS 2.0, זה בדיוק הזמן להתחיל ואפילו לקחת את האתגר צעד אחד קדימה – לכתוב אפליקצית AngularJS ב- ES6.
אז קדימה, מתחילים.

על מה נדבר?

אפשר לדבר על המון דברים בנוגע ל- AngularJS, באופן אישי אני מעדיף מאמרים פרקטיים ועניניים, אז מאמר בנוסח "למה אנגולר 2.0 זה אסון" לא תמצאו כאן, זה גם לא "מבוא ל- ES6". בחרתי לדבר על מיגרציה מ- AngularJS 1.x ל- AngularJS 2.0, או בעיקר על הכנה מקדימה למיגרציה שתבוא לידי ביטוי בשכתוב האפליקציה שלנו ב- ES6. כן, לכתוב ב- ES6 כבר היום, עם AngularJS 1.3 ובדפדפנים שאפילו לא לגמרי תומכים בתקן. אני רוצה לבדוק האם זה אפשרי, ואם כן – האם זה גם כדאי.

למה עכשיו?

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

AtScript = ES6 + Types + Annotations + Introspections

אומנם בצוות של אנגולר משתדלים לציין בכל הזדמנות שאנחנו בתור מפתחים לא חייבים לעבוד עם AtScript או אפילו עם ES6 על מנת להשתמש באנגולר 2.0, אומרים שנוכל לעשות הכל גם עם ES5 הישנה והמוכרת, אבל באותה נשימה גם אומרים שזה בהחלט יהווה יתרון וכדאי להשתמש ב- AtScript (שלמעשה, מדובר ב- ES6 עם כל מיני תוספות כפי שכבר הבנו).

מה המוטיבציה?

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

היכון, הכן, צא!

אתחיל עם העובדה שהדפדפנים היום לא לגמרי תומכים ב- ES6 בצורה רחבה, כך שאנחנו לא יכולים פשוט לכתוב ב- ES6 ולהריץ כמו שאנחנו רגילים, אנחנו זקוקים לאיזשהו כלי שיגשר על הפער הזה. ישנם מס' כלים המאפשרים לנו לכתוב ב- ES6 והם למעשה דואגים להמיר את הקוד שלנו (כל אחד בצורה שלו) לקוד שיכול לרוץ כבר היום, חלקם עושים את זה ב- runtime ואת חלקם צריך לשלב בתהליך ה- build, לא אכנס לזה יותר מדי כרגע – רק אגיד שאני בחרתי ב- Traceur ובמקרה הזה אני מריץ אותו ב- runtime.

כ- PoC בחרתי באפליקציה די פשוטה המכילה View, Controller ו- Service בסיסיים.
אני יוצא מנקודת הנחה שאתם כבר מכירים את התחביר של ES6, אם לא – למה אתם מחכים? בכל אופן, במקרה הזה שילוב של היכרות עם שפות נוספות והיגיון בריא אמור להספיק גם למי שלא מכיר את השפה.

נתחיל עם ה- Service (קובץ: alerts.service.js):

export class Alerts {
  
  constructor($window) {
    this.$window = $window;
  }
  
  fire(alert) {
    this.$window.alert(alert);
  }
}

ה- Controller (קובץ: main.controller.js):

export class MainController {
  
  constructor(Alerts) {
    this.Alerts = Alerts;
  }
  
  get headerTitle() {
    return 'Hello ECMAScript 6!';
  }
  
  buttonClick() {
    this.Alerts.fire('Awesome!');
  }
}

איתחול האפליקציה (קובץ: app.js):

import {MainController} from 'main.controller';
import {Alerts} from 'alerts.service';

angular.module('app', [])
  .controller('MainController', MainController)
  .service('Alerts', Alerts);

ולבסוף ה- View (קובץ: index.html):

<!DOCTYPE html>
<html ng-cloak>

  <head>
    <title>AngularJS 1.3 application written in ECMAScript 6</title>
  </head>
  
  <body ng-controller="MainController as Main">
  
    <h1 ng-bind="Main.headerTitle"></h1>
    <button type="button" ng-click="Main.buttonClick()">Click me!</button>
    
    <!-- traceur -->
    <script src="https://google.github.io/traceur-compiler/bin/traceur.js"></script>
    <script src="https://google.github.io/traceur-compiler/src/bootstrap.js"></script>
    <script>traceur.options.experimental = true;</script>
    
    <!-- angularjs -->
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.3.2/angular.min.js"></script>
    
    <!-- bootstrap our application -->
    <script>
      System.import('app').then(function(){
        angular.element(document).ready(function() {
          angular.bootstrap(document, ['app']);
        });
      });
    </script>
    
  </body>
  
</html>

זה עובד, אבל אתם לא חייבים להאמין לי – תראו בעצמכם ב- Plunker הבא.

מסקנות

כפי שניתן לראות, עשינו את זה די בקלות. חדי העין מביניכם אפילו ישימו לב שמלבד שמות הארגומנטים שאנחנו מעבירים ל- constructor, וגם את זה ניתן לשנות בקלות אם רק רוצים – ברמת ההגדרה למחלקות שלנו אין שום מושג שהן רצות בתוך AngularJS, השיוך היחיד שלהן לספריה נעשה ב- app.js ששם אנחנו מעבירים אותן ל- AngularJS בתור Controllers/Services בהתאם לצורך. אפשר לעשות את זה גם ב- ES5 – אך לדעתי ב- ES6 זה הרבה יותר אינטואיטיבי, פשוט ומתבקש.

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

לסיכום

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

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

JavaScript – The "Mixin" Design Pattern

כולנו יודעים שב- JavaScript הירושה מתבצעת באמצעות ה- Prototype של הפונקציות, אבל כמה מכם שמעו על Mixins או השתמשו בהם?

Mixins

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

Mixins משמשים בעיקר ל- Code Reuse – אם יש לנו מקומות שונים במערכת שמטעימים פונקציונליות זהה, אנחנו יכולים להוציא אותה ל- Mixin ולכלול אותו בשני המקומות הללו. כותבים את הקוד פעם אחת, משתמשים בו בכל מקום.

ב- JavaScript כפי שאנו יודעים אין מחלקות, אנו נדמה מחלקות באמצעות פונקציות, ו- Mixins נדמה באמצעות אובייקטים.

נתחיל עם דוגמאת קוד בסיסית:

/**
 * Classes
 */
var Person = function(name) {
	this.name = name;
};

var Dog = function(name) {
	this.name = name
};

 
יצרנו 2 מחלקות, הראשונה בשם Person והשנייה בשם Dog. שתיהן מקבלות ב- constructor שלהן את הפרמטר 'name' ושומרות אותו עבור אותו instance.

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

עכשיו ניצור Mixins עבור הלוגיקה המשותפת הזאת:

/**
 * Classes
 */
var Person = function(name) {
	this.name = name;
};

var Dog = function(name) {
	this.name = name
};

/**
 * Mixins
 */
var mover = {
	walk: function() {
		console.log(this.name + " is walking.");
	},
	run: function() {
		console.log(this.name + " is running.");
	}
};

var speaker = {
	speak: function() {
		console.log(this.name + " is speaking.");
	}
};

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

קדימה להטמיע

כפי שאמרנו, אנחנו רוצים להטמיע את היכולות האלו, את ה- Mixins האלו, במחלקות שיצרנו עבור Person ו- Dog. איך אנחנו עושים את זה? בקלות – פשוט מעתיקים את המתודות של ה- Mixins לתוך ה- Prototype של המחלקות שלנו.

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

עכשיו זה נראה ככה:

/**
 * Classes
 */
var Person = function(name) {
	this.name = name;
};

var Dog = function(name) {
	this.name = name
};

/**
 * Mixins
 */
var mover = {
	walk: function() {
		console.log(this.name + " is walking.");
	},
	run: function() {
		console.log(this.name + " is running.");
	}
};

var speaker = {
	speak: function() {
		console.log(this.name + " is speaking.");
	}
};

/**
 * Merge the mixins into the classes
 */
$.extend(Person.prototype, mover, speaker);
$.extend(Dog.prototype, mover, speaker);

 
זה הכל, באמת.

הערות:

1. קוד מלא: http://codepen.io/AdirAmsalem/pen/Fewzk?editors=001
2. מימוש של extend:

/**
 * Merge the contents of two or more objects together into the first object.
 * 
 * @param  {Object} target
 * @param  {Object} source1
 * @param  {Object} sourceN
 *
 * @example
 * 	extend(Person.prototype, speaker); // single source
 * 	extend(Person.prototype, mover, speaker); // multiple sources
 * 
 * @return {Object} the merged object
 */
var extend = function(target) {
	if (!arguments[1]) return target;

	for (var i = 1, l = arguments.length; i < l; i++) {
		var source = arguments[i];

		for (var prop in source) {
			if (!source.hasOwnProperty(prop)) continue;

			target[prop] = source[prop];
		}
	}

	return target;
};

 

JPG.co.il – המהפך

למי שמכיר ולמי שעדיין לא – JPG.co.il הינו אתר המספק שירות העלאת תמונות.
במשך כשנתיים, שבמהלכן בוצעו בו שינויים מינוריים בלבד, הוא היה נראה ככה:

עמוד הבית:
JPG - Old Main Page

עמוד התצוגה:
JPG - Old View Page

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

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

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

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

הגדרת יעדים

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

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

תוצר ראשוני

לאחר לא מעט מחשבות, התלבטויות, התייעצויות וכד', הגענו לאיפיון הבא: http://s5uemp.axshare.com.

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

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

מה עושים עם זה הלאה

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

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

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

מה עשינו

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

עמוד הבית:
JPG - New Main Page
JPG - New Main Page Extended

עמוד התצוגה:
JPG - New View Page

כל סוף הוא התחלה חדשה

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

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

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

כך זה נראה:
JPG - Heatmap

מסקנות מהבדיקות

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

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

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

לסיכום

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

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

מאקרו-סמנטיקה, מיקרו-סמנטיקה ומה שביניהן

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

מאקרו-סמנטיקה

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

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

<section>
<article>
<header>
<footer>
<aside>
<time>
<nav>
<address>

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

נגיד.. למה זה טוב?

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

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

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

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

תרחיש לדוגמה

בואו נגיד שבאמצעות התגיות שניתנו לנו ברמת המאקרו-סמנטיקה יצרנו את המבנה הבא:
Basic Semantic Markup
* אין צורך להתפעל מהיכולות שלי בצייר – כל אחד יכול להגיע לתוצאה כזו לאחר כמה שנות ניסיון.

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

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

מיקרו-סמנטיקה

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

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

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

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

קדימה לאוכל, אה – לעבודה

קודם כל בואו נכיר את הסכמה המייצגת מתכון – http://schema.org/Recipe.
מתכון הוא קודם כל Thing, לאחר מכן הוא CreativeWork ולבסוף הוא כמובן Recipe.
כל סכמה בהיררכיה מרחיבה את הסכמה ממנה היא יורשת ומוסיפה תכונות נוספות המייצגות ספציפית אותה. מאפיינים מסויימים בסכמה יכולים להצביע לסכמות נוספות – לדוג' יוצר המתכון הוא למעשה Person או Organization, כל ביקורת היא Review וכן הלאה. כך ניתן להגדיר קשרים בין פרטי המידע השונים וליצור מבנה שבו ברור לחלוטין מה כל דבר מייצג ולאן הוא שייך.

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

נתון הטקסט הבא:

Moms World Famous Banana Bread
By John Smith, May 8, 2009
<img src="bananabread.jpg" />

This classic banana bread recipe comes from my mom -- the walnuts add a nice
 texture and flavor to the banana bread.

Prep Time: 15 minutes
Cook time: 1 hour
Yield: 1 loaf

Nutrition facts:
240 calories, 9 grams fat

Ingredients:
- 3 or 4 ripe bananas, smashed
- 1 egg
- 3/4 cup of sugar
...

Instructions:
 Preheat the oven to 350 degrees. Mix in the ingredients in a bowl. Add the
 flour last. Pour the mixture into a loaf pan and bake for one hour.

140 comments:
From Janel, May 5 -- thank you, great recipe!
...

על מנת לייצג אותו כ- Recipe, נעשה כך:

<div itemscope itemtype="http://schema.org/Recipe">
  <span itemprop="name">Mom's World Famous Banana Bread</span>
  By <span itemprop="author">John Smith</span>,
  <meta itemprop="datePublished" content="2009-05-08">May 8, 2009
  <img itemprop="image" src="bananabread.jpg" />

  <span itemprop="description">This classic banana bread recipe comes
  from my mom -- the walnuts add a nice texture and flavor to the banana
  bread.</span>

  Prep Time: <meta itemprop="prepTime" content="PT15M">15 minutes
  Cook time: <meta itemprop="cookTime" content="PT1H">1 hour
  Yield: <span itemprop="recipeYield">1 loaf</span>

  <div itemprop="nutrition"
    itemscope itemtype="http://schema.org/NutritionInformation">
    Nutrition facts:
    <span itemprop="calories">240 calories</span>,
    <span itemprop="fatContent">9 grams fat</span>
  </div>

  Ingredients:
  - <span itemprop="ingredients">3 or 4 ripe bananas, smashed</span>
  - <span itemprop="ingredients">1 egg</span>
  - <span itemprop="ingredients">3/4 cup of sugar</span>
  ...

  Instructions:
  <span itemprop="recipeInstructions">
  Preheat the oven to 350 degrees. Mix in the ingredients in a bowl. Add
  the flour last. Pour the mixture into a loaf pan and bake for one hour.
  </span>

  140 comments:
  <meta itemprop="interactionCount" content="UserComments:140" />
  From Janel, May 5 -- thank you, great recipe!
  ...
</div>

הסבר קצרצר:

  1. על מנת לייצג פריט אנחנו יוצרים קונטיינר ונותנים לו itemscope.
  2. בנוסף ל- itemscope אנחנו מגדירים itemtype, כאשר ב- itemtype אנו מציינים את עמוד הסכמה הרלוונטי (לדוג': http://schema.org/Recipe).
  3. על מנת לייצג מאפיין של אותו פריט אנו משתמשים ב- itemprop ומציינים את שם המאפיין (לדוג': name).
  4. במידה והמאפיין מצביע לסכמה אחרת – מוסיפים itemscope ו- itemtype כמו בסעיפים 1 ו- 2 וחוזרים על התהליך.
  5. אם רוצים לייצג נתון מסויים אך לא רוצים שהוא יופיע לגולש – ניתן להשתמש בתגית meta אשר מקבלת itemprop כמו בסעיף 3 ואת הנתון עצמו שמים במאפיין content.

איבדתם אותי? תחזרו לדוגמה אחרי כל סעיף ותראו איך זה ממומש.

מנקודת המבט של מנוע החיפוש

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

אספתי עבורכם כמה דוגמאת לתוצאות המכילות דפים כאלו:
The Godfather
Baked Macaroni and Cheese
Lady Gaga

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

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

לסיכום

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

החלפת/ מכירת קישורים ו- SEO

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

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

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

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

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

PHP – על Opcode Caching ו- APC

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

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

מה זה Opcode Caching?

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

מה זה APC?

APC (ר"ת של Alternative PHP Cache) הוא אחד התוספים הנפוצים והמומלצים לביצוע Opcode Caching, ב- PHP 6 הוא גם יהיה מובנה בשפה עצמה ולא יהיה צורך להתקין אותו בנפרד.
APC משתמש ב- shared memory ו- mapping table לאחסון המידע.
חשוב לציין ש- APC יעבוד רק כאשר ה- PHP רץ כ- apache module (אמרנו כבר shared memory), אין אפשרות להשתמש ב- APC כאשר אנחנו עובדים בתצורת CGI.

איך מתקינים APC?

את APC ניתן להתקין בקלות באמצעות PECL, לצורך המאמר אסביר איך להתקין אותו במערכות מבוססות Unix.
יש להריץ את הפקודה הבאה כ- root (או באמצעות sudo):

pecl install apc

לאחר מכן יש להוסיף ל- php.ini (קובץ הקונפיגורציה של ה- PHP) את השורה הבאה:

extension=apc.so

כעת יש לבצע הפעלה מחדש לשרת ה- http וזה הכל!
על מנת לבדוק אם התוסף הותקן כמו שצריך, צרו קובץ חדש עם התוכן:

<?php
phpinfo();
?>

הריצו אותו וחפשו אחר "apc", מצאתם? מצויין.

הגדרות חשובות

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

  • apc.enabled – האם התוסף יפעל או לא.
    כברירת מחדל מוגדר כ- "1" (פעיל), הגדרה כ- "0" תבטל את התוסף.
  • apc.shm_segments – כמות יחידות ה- shared memory שיוקצו עבור התוסף.
    כברירת מחדל מוגדר כ- "1".
  • apc.shm_size – נפח הזכרון (ב- mb) שיוקצה עבור כל יחידת shared memory.
    כברירת מחדל מוגדר כ- "32".
  • apc.num_files_hint – הכמות המירבית של הקבצים שישמרו במטמון.
    כברירת מחדל מוגדר כ- "1000".
  • apc.ttl – זמן התפוגה (בשניות) של המידע השמור.
    כברירת מחדל מוגדר כ- "0" (לא פג לעולם).
  • apc.cache_by_default – האם לבצע opcode caching אוטומטית.
    כברירת מחדל מוגדר כ- "1" (כן), הגדרה כ- "0" תבטל את זה.
  • apc.max_file_size – גודל הקובץ המירבי (ב- mb) שניתן לשמור.
    כברירת מחדל מוגדר כ- "1".
  • apc.stat – בודק בכל בקשה האם המידע השמור במטמון עדכני.
    כברירת מחדל מוגדר כ- "1" (כן), הגדרה כ- "0" תבטל את זה (להשתמש בזהירות).

מידע אודות הגדרות נוספות ניתן למצוא בעמוד APC Configuration.

שיהיה לכם Opcode Caching מהנה ומועיל.

SEO – הגדרת גבולות

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

מהו מנוע חיפוש ומה מטרתו?

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

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

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

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

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

על מה אתה מדבר?

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

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

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

לסיכום

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

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