הפוסט נכתב על ידי אבי תשובה מפתח Java ו-Javascript בחברת טיקל.

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

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

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

עומק הכיסוי

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

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

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

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

מיקוד: עד כמה התשתית/כלי ממוקדים בפתרון לבעיה ספציפית. למשל, requires.js מהווה ספרית תשתית שתפקידה הוא מאוד מסוים.

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

המרכיבים הנ"ל, יחד עם הפרמטרים המובנים מאליהם…רגע… אולי לא הכי מובנים מאליהם… מוטב ובכל זאת אומר כמה מילים על הפרמטרים האלה:

• איכות פונקציונלית
• איכות הקוד
• איכות הקהילה

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

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

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

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

יותר מידי אנשים שולחים ידם לכתיבת ספריות ותשתיות

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

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

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

ויש גם תשתיות ראויות

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

כיום, ישנן כמה ספריות תשתית ממוקדות, שלדעתי מצטיינות בתחומן. חלק מהן, הפך לפחות שימושי, לפחות עבור מי שכותב ב-ECMA5 ולעתים יתר הפונקציונליות שלהן מכוסה על ידי ספריות תשתית יותר מקיפות. לדוגמה, underscore – עבור מערכים, יש כבר את הפונקציונליות ב-JS החדשים יחסית ומי שמשתמש ב-angular מקבל גם את הפונקציונליות שקשורה ב-JSON. כלומר, הספרייה מצויינת, אך הופכת במצבים רבים למיותרת.

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

מגה ספריות

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

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

הדבר הטוב ביותר שבבסיס התשתית הזו, הוא עצם ההתייחסות ל-HTML כתבנית של angular: דהיינו, אנגולר קורא את ה-HTML המורחב ומעבד אותו (בזמן ריצה ובמהירות אדירה) וכך הופך את ה-markup למשהו משודרג עד מאוד (משודרג לפי טעמך וצרכיך). יש שם פתרון מסוג MVVM לשאלת הפרדת הרשויות, פתרון אלגנטי למדי, וה-data-binding אלגנטי יותר מכל פתרון אחר מסוג זה שראיתי בינתיים.

התשתית הזו כוללת גם אוסף קומפוננטות שמכסות את נושא התקשורת עם צד השרת בצורה נאה בהחלט, ופותרת את המתכנת מרוב רובו של העיסוק במניפולציה של ה-DOM. יש שם עוד כל מיני דברים טובים ושימושיים, שמייתרים צורך ברוב הספריות. יש גם כמה דברים תמוהים כמו תשתיות מיותרות ל-dependency injection ו-factories שבלעדי lazy loading וכו' הן שימושיות כמו סנדלי אצבע בקוטב (למעט הקניית מיבניות נכונה, למי שלא חזק מספיק בהנדסת תוכנה בעצמו) אבל אני מעריך שה-lazy loading ונגזרותיו ימומשו ואז תתגשם תועלת גם למי שלא זקוק למישהו שיכריח אותו להפריד בין service ל-control ול-model.

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

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

קרדיט תמונה: Shutterstock.

טיקל

Git הוא כלי לניהול גרסאות (Version Control System) הנחשב הפופולרי למדי בימים אלו. בניגוד ל-(Subversion (SVN או Perforce שהם כלים בעלי ניהול מרכזי, ל-Git יש ניהול מבוזר.

משמעות אחת היא שבמקום שיהיה איש Operations מאחורי הקלעים שינהל את שרת ה-SVN ויחסוך חשיבה למתכנתים ברוב הסוגיות הקשורות ל-Source Control – כעת על המפתחים לדאוג לנושא זה בעצמם (לפחות במידה מסוימת).

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

יעילות מתמשכת

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

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

גיט הוא פשוט להיט!
מקור: סקר המפתחים של אקליפס 2013

קצת הגדרות

כשלומדים גרמנית (ניסיתי), מהר מאוד מזהים את הדמיון שלה לאנגלית:
Ich bin Lior, משמעו: I am Lior.
Das ist gut, משמעו: This is good.

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

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

ה-Commit Graph בגיט, מורכב מה-commits השונים (ריבועים בציור למעלה) – כל אחד כולל snapshot של כל הפרויקט ברגע מסוים, וחצים – המייצגים קשר בין commits. למשל: B הוא בן של A: מישהו עבד על A, שינה אותו ואז ביצע commit ל-B.

Branch בגיט מוגדר כשרשרת כל parent commits של ה tip (קצה) של ה Branch. כלומר:

• ה-release Branch מכיל את A, B, C, E, G, H.
• ה-master Branch מכיל את A, B, C, D, F, I, J, K. כן, commits יכולים להיות חברים ביותר מ-Branch אחד.
• ה-topic Branch מכיל את A, B, F, I, L, M.

בד"כ נעבוד על ה Tip של ה Branch ולא על commits שנמצאים בהיסטוריה שלו. ה-Branch הראשון שנוצר ב Git Repository נקרא master, אולם הוא לא שונה במאומה מכל מכל branch אחר שתיצרו מאוחר יותר – זה רק שם ברירת-מחדל.

גיט מקומי וגיט מרוחק

יש טעם לעבוד על גיט מקומי-בלבד, נאמר: כאשר שאר הצוות שלכם עובד על SVN ואתם רוצים Repository שלכם שישמור את השינויים שעשיתם כל 5 עד 30 דקות של עבודה.

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

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

פעולת ה-"clone" תשכפל את ה-Repository המרוחק ותייצר Repository מקומי זהה על המחשב שלכם. זהה = מכיל את כל הקבצים, כל ה-Branches וכל ההיסטוריה מרגע יצירת הפרויקט.

פעולת Push דוחפת (commit(s מה-Repository שלכם למרוחק ו-Pull מביאה (commit(s מה Repository המרוחק אליכם.

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

לגיט יש עקומת למידה לא-קלה

שכבת ה-Persistence של גיט

שכבת אכסון הנתונים של גיט ידועה בשם The Object Store או Object Database. את התוכן שלה ניתן למצוא בפועל תחת הספרייה git/objects.(בעקבות פעולת git clone נוצרת תיקייה נסתרת בשם "git." ב path בו התבצעה הפעולה).

ה-Object Store מאכסן 4 סוגים של אובייקטים. הנה הקשרים הלוגיים ביניהם:

האובייקט הבולט ביותר הוא כמובן אובייקט ה Commit, המשמש כ Aggregator לתת העץ של כל הספריות והקבצים באותו ה Commit. ה-Commit מצביע לעץ (Tree) אחד, שהוא ה Root Directory של תתי-הספריות (עצים) וקבצים (BLOBs) שהם חלק מה Commit.

הערת צד: בוודאי מטרידה אתכם השאלה כיצד ענף (Branch) יכול להכיל משהו (Commit) שמצדו מכיל הרבה עצים (Trees) – הרי "ענף" הוא חלק מה"עץ". יש לכך 2 תשובות:

1. Branch הוא ענף של ה "Commit Graph"', בעוד עץ (Tree) הוא ספרייה במערכת הקבצים של ה-Commit הנוכחי.
2. זו אכן טרמינולוגיה מבלבלת – היה עדיף לקרוא ל Tree פשוט Directory או Folder, על אף הקונוטציה הלא-רצויה למערכת ההפעלה חלונות (רחמנא ליצלן).

כל BLOB ב-Object Store מייצג קובץ, יהיה זה קובץ קוד (למשל java.) או קובץ נתונים אחר (למשל תמונה בפורמט png.). תוכן הקובץ עובר פונקציית Hash בשם SHA-1 המייצרת מספר בן 160bit המתאר את תוכן הקובץ. פונקציית SHA-1 היא פונקציית hash בעלת פיזור אחיד למדי (מקורה בעולם האבטחה) – ואנו מניחים שהיא מזהה תוכן של קובץ באופן ייחודי. ב-UI של גיט נראה את ה hash בייצוג הקסדצימלי, למשל:

12cfb1862b23356523d88127fa5d5aeb333950

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

גיט מזהה כל קובץ ע"פ התוכן שלו (לא ע"פ שם הקובץ, סיומת או תאריך) – כלומר, ע"פ ה hash שלו. זאת אומרת ש Tree בעצם מכיל רשימת hashes של קבצים, המתארת את הקבצים בספרייה, ומייצא בעצמו hash של ערכים אלו. ה Commit מקבל ה hash המחושב מה hash של תיקיית ה root של הפרויקט + כמה שדות.

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

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

באופן דומה, העצים הם hash של כל ה hashes של העצים / קבצים שהם מכילים. אם כל הקבצים בתת-עץ לא השתנו, אזי אובייקט ה Tree שמייצג אותם יישאר עם אותו ה hash וכן הלאה.

זיהוי אובייקטים ע"פ hash מאפשר לגיט לבצע השוואות מהירות בין אובייקטים ובין תתי-עצים של אובייקטים: פשוט יש להשוות בין שני hashes.

כמה properties חשובים על אובייקט ה-Commit:

commit message

הערת טקסט המסבירה מה כולל ה-commit.

parents

מצביעים ל-commits אחרים, קשר המגדיר את ה-Commit Graph.

• אם ל-commit יש יותר מהורה אחד (ניתן 3 או יותר) – אזי זהו merge בין ענפים (branches).
• אם ל-commit אין parents, אזי ה commit הזה הוא ה Root Commit (ראשית ה Repository) או orphan commit – מין אופציה מתקדמת בגיט לייצר branch חדש עם קוד שלא קשור לענפים הקיימים ב Repository.

committer vs. author
לרוב ה committer וה author יהיה אותו אדם, מלבד כמה מקרים בהם מישהו מבצע commit מחודש לקוד שמישהו אחר עשה לו commit בעבר.

דוגמה אחת לכך היא cherry-pick, היכולת לקחת שינויים של commit ולהעתיק רק אותם (כלומר: את השינויים) ל branch אחר. יכולת זו היא רבת-עוצמה כאשר רוצים להעביר בין ענפים תיקוני-באגים. יכולות אחרות הן filter-branch ("שכתוב היסטוריה") ו rebase (חיתוך ענף, והדבקה שלו במקום אחר). במקרים אלו יהיה ניתן להבחין בין האדם שביצע את הפעולה (committer) לבין ה committer של הקוד המקורי (author).

ה-Index

תהליך העדכון קבצים ל-Git Repository מתבצע בשני שלבים:

1. עדכון ה Index (נקרא גם "Staging Area" או "Directory Cache") בעדכון.
2. ביצוע העדכונים מתוך ה-Index ל-Repository.

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

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

האינדקס הוא מבנה נתונים נוסף של גיט, שמנותק ממצב הקבצים במערכת הקבצים (נקרא בעולם הגיט "Working tree)" ו/או מה Commit האחרון. הוא פשוט מילון של pathnames ו-hashes של אובייקטים ב-Object Store, כלומר <pathname, hash>.

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

הערה: git stat הוא alias שיצרתי לפקודה git status –short. לא נראה לי הגיוני שהגרסה הקצרה של הפקודה, ארוכה יותר להקלדה מהגרסה הארוכה של הפקודה. לכן יצרתי ה-alias באופן הבא:

git config –global alias.stat "status –short"

ברגע שנבצע פעולת git add לקבצים – הם ייווספו לאינדקס:

• ה-pathname יזכור איזה קובץ במעקב.
• תוכן הקובץ, כפי שהוא באותו הרגע, ישמר כ BLOB ב Object Store וה hash של אותו BLOB יישמר באינדקס.

הנה:

כעת אני רואה שהקובץ התווסף לאינדקס (עמודה ירוקה, A הוא קיצור של Add).
כדי לראות אלו קבצים נמצאים באינדקס – פשוט הקלידו git ls-files.

כמה דקות לאחר מכן אני מבצע git stat ומקבל את המצב הבא:

מה זה המצב הדו-פרצופי הזה – מישהו יודע?
הקובץ השתנה או התווסף? מדוע אדום וירוק יחדיו?

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

אם נבצע git commit בשלב זה, העותק שהוספנו קודם לכן לאינדקס (ונשמר ב Object Store) יכנס ל Repository, בעוד השינויים שביצעו לאחר מכן – יישארו במערכת הקבצים.

לאחר ה-commit, פעולת Git Stat תראה רק את השינוי שבדיסק (הקובץ יוותר במעקב):

עוד טיפ קטן:

• פעולת <git rm <filename מסירה קובץ מהאינדקס (כלומר – הוא לא יהיה במעקב) ומהדיסק: זו הדרך להעיף קובץ שאינכם מעוניינים בו מהפרויקט. במילים אחרות: הוסף קובץ להסרה – לאינדקס. בכלל ש rm נשמע ההיפך מ add – זו דרך מצוינת להתבלבל.
• לצורך הגנה, אם ניסיתם לבצע git rm על קובץ שנעשו בו שינויים – גיט יסרב ויציע לכם להוסיף cached– .לא פעם הקשבתי לעצתו בשמחה – ומחקתי לעצמי כמה שינויים.
• פעולת <git reset <filename רק מסירה את הקובץ מהאינדקס – זו בעצם הפעולה ההופכית ל git add.

לי זה עזר.

אם אתם רוצים לבצע היפוך ("revert" בשפת perforce) לשינוי בקובץ, עליכם פשוט לבצע <git checkout <filename. כפי שהזהרתי בהקדמה על השפה הגרמנית – פעולת git revert עושה משהו לגמרי אחר (והרסני).

ענפים

הפוסט מתארך, ולכן אסיים בנושא אחרון חשוב לפוסט זה: Branches.

מהו Branch?

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

גיט מחזיק במבנה נתונים נוסף: refs (קיצור של References, נקרא גם Pointer לפעמים). יש בגיט 2 סוגי מצביעים:

• מצביע ישיר, המצביע לאובייקט ב Object Store (לרוב זה יהיה commit או tag).
• מצביע סימבולי (symbolic ref) המצביע למצביע אחר. משהו כמו symbolic link במערכת ההפעלה.

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

לעתים יווצר מצב בו ה-Repository המרוחק ("origin") יכיל branches שלא קיימים אצלנו. פקודת git pull מייבאת את ה-commits – אך לא את המצביעים. פקודת git fetch מייבאת את המצביעים מה-Repository המרוחק, מה שיראה אצלנו כ-branches ו-tags.

commit E הוא לא חלק מה-branch. ניתן לפתור מצב זה ע"י יצירת branch חדש מהנקודה הנוכחית ע"י פקודת <git checkout -b <new branch name ואולי אח"כ לבצע merge בין ה-branch החדש ל-dev. אם לאחר זמן ממושך לא "תטפלו" ב-commits שאינם שייכים ל-branch כלשהו – גיט ינקה אותם בתהליך "ניקוי הזבל" שלו.

סיכום

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

שיהיה בהצלחה!

—–

קישורים רלוונטיים

GitGuys – מקור טוב להבנת המבנה של גיט:
http://www.gitguys.com/topics/

UnGit – כלי ויזואלי שעוזר ללמוד גיט:
https://github.com/FredrikNoren/ungit

Learn Git Branching – אתר טוב שמציע "משחק" שיסייע לכם לעקוב אחר branching מתקדם בגיט – נחמד מאוד.
http://pcottle.github.io/learnGitBranching/

כלי UI טוב מהרגיל לגיט (שומר על השפה של גיט) – SourceTree:

הפוסט פורסם לראשונה בבלוג ארכיטקטורת תוכנה.

הפוסט נכתב על-ידי מירון גופר – מומחה DevOps בטיקל 

פעם, לפני לא מעט שנים, עוד כשהייתי סטודנט, עבדתי במשרת סטודנט בצוות שנקרא אז צוות בקרת תצורה (CM team). תפקידי הצוות, שהיום מן הסתם היה נקרא צוות DEVOPS, כללו אחריות על source control, על ה-build, על תהליכי ההתקנה ועל ניהול מעבדה קטנה של צוות הפיתוח. בתור הסטודנט הכי צעיר – קיבלתי את התפקידים שאף אחד אחר לא רצה. כלומר את ניהול המעבדה.

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

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

הצורך בסביבת ריצה זמינה

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

מחשב ״נקי״

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

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

לא רק אפליקציה אלא כל התשתית התומכת

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

בניהול של סביבות וירטואליות כאלו קיים מתח בין ניהול של תצורות וירטואליות (Images) לניהול של תהליכי התקנה חיצוניים. במילים אחרות: איזה חלק מהתוצאה הסופית אני מתקין מראש ושומר כ-Image (לאחרונה רווח המונח Box) ואיזה חלק מותקן על המכונה הוירטואלית אחרי שהיא עולה (עדיף, כמובן, בצורה אוטומטית). במקביל להתפתחות של כלי ניהול וירטואלים שמאפשרים לייצר "קופסאות" בקלות יחסית, להפיץ אותם, להרים ולהוריד אותם על שרת הוירטואליזציה וכדומה, חלה התפתחות רבה בכלים שממדלים, מנהלים ומאפשרים אוטומציה של תהליכי ההתקנה כדוגמת chef ו-puppet.

במתח הזה אין תשובות חד משמעיות וסביר להניח שלכל פרויקט ולכל איש DEVOPS יהיו את ההעדפות שלו. אישית, אני חסיד של הגישה שטוענת ש:"הכל הוא קוד". אני מעדיף, בדרך כלל, לעבוד עם קופסאות מינימליות (JEOS – Just Enough Operating System ) ולתת ל-chef לעשות את רוב העבודה. הסיבה היא שאני מעדיף לנהל קוד על פני קופסאות שחורות בינאריות. קוד אפשר לשים ב-git, קל יותר לנהל לו גרסאות, לעקוב אחרי התפתחויות ישנות, להשוות גרסאות, לנהל ענפי פיתוח וכדומה. יתרון נוסף, ולא פחות חשוב, הוא היכולת לעשות שימוש בקוד קיים, להיעזר בקהילה ובספריות צד שלישי. ולבסוף, (ומצאתי שנוטים לזלזל ביתרון הזה שלא בצדק) קוד, בעיקר אם הוא כתוב היטב ובניגוד לקבצי Image, ניתן לקרוא. אפשר לעבור עליו ולהבין את הסביבה שלך גם כשהיא למטה.

סביבה נקייה במחשב מלוכלך

אבל השלב האחרון במהפכה הוא, בעיני, המעניין ביותר. הכוח של המחשבים, כולל לפטופים, מצד אחד והיכולת להתקין בקלות מנוע וירטואליזציה על תחנת העבודה (מנועים כדוגמת virtual-box, vm-player ואחרים) מאפשרים למפתח לקבל את סביבת הריצה הנקייה, המנוהלת והמוגדרת היטב  - אצלו על המחשב. בלי להשפיע או להיות מושפעת מכל ה"זבל" שמותקן, כאמור, על המחשבים שלנו. מהרגע שהשתדרגתי למחשב חזק מספיק – אני מוצא את עצמי מנהל ארגון IT בזעיר אנפין בתוך ה-virtual-box שלי. מתקין מכונות, מקנפג רשתות, מעלה, מוריד, מחסל. כל החגיגה. כאן נכנס לפעולה אחד הכלים המועילים והמגניבים שיצא לי לפגוש לאחרונה – vagrant.

vagrant הוא למעשה סוג של מחולל. הוא קורא קובץ מרכזי אחד שמתאר את סביבת הריצה הוירטואלית שלי. ויודע להביא את ה-Image, להתקין אותו במנוע הוירטואלזיציה (כרגע נתמכים virtual-box ו-vmware) להרים, להוריד, להרוס, ליצור מחדש ועוד. במילים אחרות – כל מה שהייתי עושה בממשק הניהול של מנוע הוירטואליזיה (כולל פעולות מתקדמות כמו הגדרת רשתות, שירשור פורטים וכדומה) אני כותב ב-descriptor אחד שנשמר לי כקובץ טקסט (git, גרסאות, ענפים, השוואות, לקרא ולהבין … זוכרים) ומאפשר לי לשמור על אחידות גם ברמה הזו (קובץ שיופץ למפתחים אחרים ירים בדיוק את אותה סביבה אצל כל אחד) קובץ התיאור שנקרא (במפתיע) Vagrantfile הוא אמנם תיאורי במהותו אבל הוא כתוב ברובי כך שהוא קריא למדי.

יחד עם סט הולך וגדל של plugins – הכלי הזה נראה יותר ויותר טוב. התכונה החשובה ביותר ב-vagrant לטעמי היא החיבור הטבעי שלו ל-chef (וגם ל-puppet אם כבר מדברים). ב-Vagrantfile ניתן להגדיר את chef בתור provisioner ולהגדיר רשימות ריצה וענייני chef נוספים. הגדרה כזו מאפשרת לחבר את ה-Vagrantfile לפרוייקט chef שמתאר ומתקין את סביבת הריצה, להגדיר בו את הbox שהכנו מראש (או להשתמש באחת מתוך עשרות קופסאות קיימות שהקהילה משתפת) ולקבל מגוון מרשים של יכולות וגמישות. אפשר להרים סביבה נקייה, לבדוק תהליכי התקנה של האפליקציה וכשמשהו לא מצליח – זורקים ומתחילים מהתחלה. ה-Vagrantfile יכול להיות עשיר מאד ולהחזיק תיאור של מספר מחשבים עם יחסי הגומלין ביניהם, רשתות וכדומה. לאחרונה הוסיפו ב-vagrant תמיכה גם ב-AWS של אמזון. התמיכה הזו מאפשרת לשכפל את המערכות שרצות בסביבת הוירטואליזציה הפרטית שלי גם בענן האמזוני ולנהל את האחידות בעזרת קובץ descriptor אחד.

לסיכום

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

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

אם הגעתם עד לכאן הפוסט כנראה עניין אתכם. רוצים לשמוע עוד? הצטרפו לקבוצת המיטאפ: Full Stack Developers Israel, בה תוכל להמשיך ולהעמיק את הידע בנושא זה ואחרים ע"י טובי המומחים. יתכן ותמצא עניין באירוע הקרוב שיערך ב-28.11.13 בנושא :Chef and Vagrant: The DevOps Perfect Couple.

קרדיט תמונה: servers via Shutterstock.

לא לכל פרויקט יש מעצב גרפי. למי מכם (מתכנתים) שיצא ליצור אתר/אפליקצית ווב מ-scratch, בוודאי יודע שידע ב-CSS ובאפקטים – פשוט לא מספיק כדי לייצר אתר יפה:

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

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

האם HTML5 boilerplate ישפר את המצב? Plug-Ins של jQuery לאפקטים הם הדרך? לא, לא, ולא.

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

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

על Bootstrap

אם נתבונן על אתרי אינטרנט, נוכל לראות שיש ברבים מהם תבניות עיצוב שחוזרות על עצמן:

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

• Layout מסוים של הדף.
• Navigation Menu – המאפשר לעבור מדף לדף באתר.
• Side Bar – אם מידע שימושי שאינו משתנה, או משתנה מעט ע"פ התוכן המוצג במרכז הדף וכו'.

הנה 3 אתרים לדוגמה שמציגים את תבניות הללו (לחצו על התמונות על מנת להגדיל):

יש עוד כמה תבניות נפוצות אחרות, למשל כמו grid (קרוי גם: cards):

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

טקסט HTML פשוט, בלי ועם Bootstrap שנטענה.
וידוי: הוספתי על אלמנט ה body תכונת class עם הערך container, בכדי לקבל את המרכוז.

Responsive Web Design

משפחה חשובה נוספת של תבניות עיצוב-אתרים שהופכת לפופולרית בשנים האחרונות היא משפחת התבניות של Responsive Web Design (בקיצור RWD): כיצד מתאימים אתר למחשב שולחני, טאבלט וסמארפון – מבלי לכתוב את האתר 2 או 3 פעמים (= תוספת עלות משמעותית לפיתוח!)

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

למרות הבאזז הרב מסביב ל"תחכום" שב-RWD, ניתן למצוא מספר של תבניות פתרונות עיצוב שחוזרים על עצמם:

• "קיפול" תפריטים (toolbar) ל-drop-down menu.
• צמצום מספר עמודות של desktop/tablet ל "מחסנית" (stack) – בסמארטפון.
• תמונות ברזולוציות שונות למכשירים שונים.
• התמודדות עם touch events וכו'.

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

גישה נפוצה היא מה שנקרא "גישה מצמצמת" (subtractive approach) בה כדי שאתר יתאים ל Smartphone, למשל, מוסיפים לקוד ה-Desktop קטעי קוד ש"יבטלו" פונקציונליות מסוימת / פחות חשובה שאין לה מקום במסך הסמארטפון.
המשמעות היא שכל הקוד של ה-Desktop ירוץ על המכשיר הכי חלש (סמארטפון [ב]), ויש פה חוסר יעילות משמעותית.

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

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

הערה: במרכז Bootstrap גרסה 3 (החדשה, יחסית) עמד הנושא של Responsive Design ו-Mobile First (בגלל ההבנה שזה שמובייל הופך להיות מרכז השוק). Bootstrap 3 הציגה שינויים לא תואמים-לאחור ל-Bootstrap 2, ורבות מהתכונות / פתרונות שאתאר בפוסט זה, המתבסס על Bootstrap 3, לא יהיו נכונים / מדויקים לגרסאות ישנות יותר.

הערה נוספת: Bootstrap היא לא יחידה במינה. ישנן עוד כמה ספריות אחרות עם עקרונות דומים מאוד ל-Bootstrap, ספריות כמו Pure, Neat, Foundation או SemanticUI. יש טענות שספריות חדשות, כמו Neat, Pure או SemanticUI הן הצעד הבא של Bootstrap, אך בחרתי להתמקד ב-Bootstrap כי היא כיום האופציה הפופולרית ביותר.

עיצוב ברירת-המחדל של Bootstrap

כמה נקודות מעניינות על Bootstrap

• Bootstrap פותחה על ידי טוויטר להתמודדות עם חוסר-קונסיסטנטיות של ה-UI שפותח במחלקות שונות בחברה. עובדים בחברות גדולות בוודאי מכירים את האתגר.
• Bootstrap שוחררה כ-Open Source באוגוסט 2011.
• כבר בפברואר 2012 (!!!) היא הפכה להיות הספריה הפופולרית ביותר ב-Github. סקר הראה שכ-1% מאתרי האינטרנט בעולם בנויים בעזרת Bootstrap (רוב אתרי האינטרנט נבנו לפני ש-Bootstrap בכלל הופיעה).
• Bootstrap מתבססת בעיקר על CSS ורק מעט JavaScript – הדבר מתאפשר בעקבות היכולות המקדמות של CSS3. כשיצאה – זו הייתה גישה חדשנית ביותר, היום ניתן למצוא משחק מחשב (פשוט למדי, שלא לומר מעאפן) שכתוב ב-CSS ללא ג'אווהסקריפט.
• Bootstrap מתבססת על LESS (בזמן "קומפילציה"), בניגוד למתחרתה החשובה Foundation שמבוסס על SASS.
• Bootstrap נפוצה בעיקר בקרב אתרים קטנים, בהם מנסים לחסוך בעלויות פיתוח האתר, אך עדיין ניתן למצוא לא מעט אתרים "בעלי תקציב" המשתמשים ב Bootstrap, למשל: AngularJs, viber.com, SugarSync או האתר של Fender (לחובבי הגיטרות).
• טיעון נפוץ נגד Bootstrap הוא: "אתם לא רוצים שהאתר שלכם יראה כמו כולם".
• מקור המונח "Bootstrap" הוא מאגדה גרמנית על הברון מינכהאוזן, שהצליח על פי האגדה לחלץ את עצמו מביצה טובענית על ידי משיכה בשערו שלו. בגרסה מאוחרת יותר מסופר כי השתמש באוזן הנעל (באנגלית: Boot strap) כדי לחלץ עצמו מים גואה. בתרגום לעברית ניתן לומר ש Bootstrap הוא "אתחול" – לרוב תהליך שאחראי לאתחל את כל התוכנה. בהקבלה, ספריית Bootstrap מספקת התחלה קלה / מהירה יותר לפיתוח אתרי ווב שנראים טוב.
• Bootstrap היא מודולרית: ניתן לבחור באלו חלקים אתם משתמשים וליצור custom build קטן יותר מהספרייה המלאה. בנוסף, תוכלו להגדיר ערכים לפרמטרים (צבעים, פונטים, גדלים וכו') שאתם רוצים לשנות, והם "יקומפלו" (בעזרת LESS compiler) לתוך העותק הפרטי שלכם של bootstrap.
• Bootstrap כוללת סט אייקונים מתאימה (חשוב למי שאין לו מעצב גרפי צמוד).
• אפשר למצוא כמה אינטגרציות ל Bootstrap עם ספריות UI אחרות, למשל jQuery Bootstrap או Bootstrap Angular directives (עדיין לא עודכן לתמוך בגרסה 3).

ה-Grid-System

Bootstrap לא המציאה את ה-Grid System, אך יש לה Grid System בוגר, responsive ושבשימוש ניכר – אז כנראה שניתן ללמוד ממנו משהו.

Bootstrap מחלקת את המסך ל-12 עמודות וירטואליות. כל אלמנט על המסך מגדיר מה הרוחב שלו ב"עמודות", למשל 2 עמודות זה שישית מסך ו 6 עמודות הן חצי מסך. הגובה נקבע, כמובן, ע"פ התוכן של האלמנט. זה לא טבעי ב-HTML לנסות לקבוע 2 מימדים של אלמנט (אלא במקרים בהם מוכנים לעבוד עם scrollbar).

למה בעצם לא לעבוד באחוזים? גם הם סוג של "responsive"?

• מסך צר יחסית כדאי למלא, אבל על מסך רחב מאוד, לפעמים אתר נראה טוב יותר עם שוליים בצדדים. כלומר במסכים גדולים בוטסארטפ יוצרת ריווח בצדדים ומחלקת רק חלק מהמסך ל 12 עמודות.
• כאשר עובדים עם עמודות – קל יותר לקבוע ריווחים (margin) קבועים בין העמודות. עם אחוזים לא מקבלים את האפקט הזה.
• 12 כמספר חלוקה הוא "מספר קסם" עיצובי: הוא מתחלק ב 2, 3 ו 4 – מה שמאפשר חלוקה הרמונית של אלמנטים בין דפים שונים. היכולת להגדיר אלמנט בדף אחד כ 50% ובדף שני כ 55% – הוא לא "בריא" עיצובית.
• 12 הוא מספר קטן מספיק כדי שהיה קל למתכנת לעשות חישובים בראש. "6 זה חצי, 5 זה כמעט חצי". לרוב מקובל לעבוד עם מערכות צרות (12 או 16) או רחבות (960 או 976) – המדמות עמודה ל"בערך פיקסל, תלוי במסך" – מערכות שלמפתח יהיה קל לעבוד איתן.

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

ניתן ליצור nesting של grid בתוך grid. אלמנט ברוחב 4 עמודות (שליש) בתוך אלמנט ברוחב 4 עמודות יצור אלמנט ברוחב תשיעית מרוחב התוכן במסך.

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

• lg, למסכים ברוחב 1200 פיקסלים או יותר (מכוון למחשב שולחני או laptop)
• md, למסכים של 992 עד 1200 פיקסלים (מכוון לטאבלט בהעמדת landscape)
• sm, למסכים של 768 עד 992 פיקסלים (מכוון לטאבלט בהעמדת portrait)
• xs, למסכים קטנים יותר (מכוון לסמארטפונים)

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

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

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

איך קובעים רוחב של אלמנט? פשוט מוסיפים לו class של CSS בשם col-xx-yy, כאשר xx הוא lg עד xs ו yy הוא מספר מ 1 עד 12. למשל: col-sm-3 או col-md-9.

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

<divcolor: rgb(45, 45, 45); font-family: Arial, Helvetica, sans-serif; line-height: 18px; background-color: rgb(255, 255, 255);">row"> <img …><p …></div>

כלי נוסף ב grid system הוא היכולת ליצור ריווח בעזרת offset. למשל:

<divcolor: rgb(45, 45, 45); font-family: Verdana, Geneva, sans-serif; line-height: 18px; background-color: rgb(255, 255, 255);">col-md-offset-4">

יציב אלמנט ברוחב 4 ובמרחק 4 מהאלמנט הקודם באותה השורה.

מקור: יח״צ

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

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

פיתוח אפליקציה פשוטה לדוגמא

לכניסה ל-App Inventor

בתחילה, תידרשו להיכנס עם חשבון ה-Google שלכם. הקלידו את שם המשתמש והסיסמא, ולחצו Sign In. לאחר מכן, אשרו לאפליקציה MIT AppInventor Version 2 לגשת לפרטי חשבון ה-Google שלכם. לאחר מכן, תתבקשו למלא סקר קצר של MIT App Inventor, נעזוב את זה לכרגע. נלחץ על New Project ונקרא לפרוייקט שלנו בשם מסויים (אותיות ומספרים בלבד), נניח helloworld.

בכדי להדגים לכם כמה פיתוח אפליקציות באמצעות ה-App Inventor היא משימה פשוטה, נבנה אפליקציה עם פקד תיבת טקסט, כפתור, ופקד Text-To-Speech. המטרה הסופית של האפליקציה, היא ברגע שנקליד טקסט כלשהו ונלחץ על הכפתור, האפליקציה תקריא לנו אותו תוך שימוש במנוע ה-TTS המותקן על המכשיר. במידה ואין לכם אחד כזה, תוכלו להוריד אותו כאן.

נקבל את מסך ה-Designer, אשר מייצג את מה שאנחנו רואים בפועל בתוך האפליקציה שלנו:

לחץ להגדלה

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

נגרור את הפקדים הרצויים עלינו לאפליקציה הפשוטה שאנו בונים עכשיו: תיבת טקסט, כפתור (שניהם נמצאים תחת לשונית ה-User Interface), ו-Text-To-Speech (נמצא תחת הלשונית Media):

נלחץ על פקד ה-Text To Speech, רואים את המאפיינים (Properties) שלו בצד שמאל? נגדיר את השפה: Country – United States, Language – English:

ועכשיו, החלק הכיפי

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

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

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

בתרשים זרימה:

נלחץ על כפתור ה-Blocks בצידו הימני העליון של המסך, ליד ה-Designer, בכדי להחליף לתצוגת Blocks. נלך אל הכפתור שלנו, Button1, אשר עליו אנחנו רוצים להחיל את הפעולה, ונסתכל על הפעולה המתאימה (when Button1.Click do):

מה זה אומר בעצם? בדיוק מה שאנחנו רוצים לעשות: כאשר הכפתור Button1 נלחץ, עשה משהו.

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

ברגע זה סיימנו לבנות את האפליקציה הראשונה שלנו!

בניית קובץ ה-APK

כעת כל מה שנשאר זה להריץ ולבדוק אותה. למטרה הזו יש לנו 2 אופציות: או להריץ אותה על מכשיר האנדרואיד שלנו, או להריץ אותה על גבי האימולטור במחשב. מכיוון שהאימולטור לא עובד בצורה אופטימלית על כל המחשבים ולוקח זמן הרצה רב, נבנה קובץ APK אותו נוכל להתקין על המכשיר ולהריץ, ואפילו לאחר מכן לחתום ולהעלות את הקובץ ל-Google Play.

נלך לתפריט, שם נבחר ב-Build –> App – Save to my computer התהליך אורך כמה שניות (עד דקה, פחות או יותר). בסופו של עניין תקבלו את תיבת הדו שיח הבאה, ותוכלו לראות את קובץ ה-APK (מצורף כאן) יורד ישירות אל מחשבכם. בכדי להתקין אותו, העבירו אותו אל מכשירכם, וודאו כי בהגדרות האבטחה של המכשיר האפשרות Unknown Sources מסומנת ב-V, והתקינו אותו באמצעות מנהל קבצים כגון ES File Explorer.

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

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

מקור: Shutterstock, יח"צ, עיבוד תמונה

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

עובדים על משהו חדש

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

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

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

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

טכנולוגיה למען המדע

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

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

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

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

מקור תמונה: Shutterstock / An image of a red grunge x, עיבוד תמונה

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

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

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

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

עם 10,000 פרויקטים ביד עבור כל אחת מהשפות, המשכנו לשלב הבא: עבור כל שפה דירגנו את 100 הספריות הנפוצות ביותר, על סמך מספר המשתמשים בכל ספריה. במקביל, כדי לקבל תמונה רחבה יותר של המגמות בשפות השונות, חילקנו את הספריות לקטגוריות רחבות יותר (בדיקות, DB, UI וכו'), וערכנו דירוג נפרד של הקטגוריות הפופולריות. מעניין מאוד לראות כיצד הבולטות של כל קטגוריה משתנה בהתאם לשפה.

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

Java

עונת ה-Guava כבר כאן, או: גוגל במיינסטרים. ספריות Spring ו-Apache נפוצות כל כך בג'אווה, שהן כבר הפכו הלכה למעשה לחלק מהשפה. שתי הספריות חולשות על יותר מ-25% מהפרויקטים במאייה הראשונה, בחלוקה כמעט שווה. נתון מפתיע למדי הוא הנוכחות הלא מבוטלת של ספריות מבית גוגל, כמו GWT ו-Guava, במאייה הראשונה, עם נתח של 7%. מסתמן שנוסף עוד תחום לחיינו שבו לגוגל יש דריסת רגל משמעותית.

ביג דאטה – Hadoop מקיימת את ההבטחה. עיבוד מידע תופס חלק גדול מהעבודה בג'אווה, כש-16 ספריות מתוך ה-100 המובילות מתמקדות בניהול מאגרי מידע, בהשוואה ל-12 ספריות ברובי ו-5 בלבד בג'אווה-סקריפט (האחרונה עוסקת עדיין בפיתוח לצד הלקוח, למרות הגידול והעניין הרב בשרתים מבוססי ג'אווה-סקריפט כגון Node.js).

מעניין לראות ש-Hadoop מקיים את הציפיות הגבוהות שתלו בו, עם 168 פרויקטים העושים בו שימוש. לשם השוואה, ב-MySql, אחד מבסיסי הנתונים הנפוצים ביותר, נרשמו כ-225 פרויקטים העושים בו שימוש. לבסיס הנתונים PostgreSQL נרשמו כ-121 פרוייקטים שעשו בו שימוש.

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

TDD – Test driven development תופס נתח משמעותי בג'אווה וברובי (אך עדיין לא בג'אווה-סקריפט) – בכל שלוש השפות אפשר לראות שבדיקות משחקות תפקיד משמעותי מאוד. בג'אווה וברובי כ-40-50% מהפרויקטים שנבחנו משתמשים בתשתיות תוכנה לבדיקות אוטומטיות. המובילות הן JUnit בג'אווה ו-RSpec ברובי. לעומת האחוז הגבוה של שימוש בשתי השפות הללו, בג'אווה-סקריפט שיעור הפרויקטים שמשתמשים בסביבות בדיקה נמוך יותר, ועומד על כ-25%.

Mocking, שיטה לסימולציה של אובייקטי העולם האמיתי בשלבי בדיקות ופיתוח, רושמת גם היא פופולריות לא מבוטלת, והיא נמצאת בשימוש ב-10% מהפרויקטים בג'אווה, וב-7% מהפרויקטים ברובי. בג'אווה-סקריפט, לעומת זאת, עוד לא נראה שימוש נרחב בשיטה הזו לפיתוח אפליקציות.

Ruby

SQL עדיין שולט בעולם בסיסי הנתונים – מאגרי NoSQL אמנם נחשבים לצעקה האחרונה בתחום הדאטה, אך בסיסי נתונים רלציוניים עדיין שולטים בעולם הרובי – Sqlite, PostgreAQL, MySql נמצאים בשימוש ב-25% מהפרויקטים, לעומת 3% בלבד מהפרויקטים עבור Redis ו-Mongo.

עם זאת, MongoDB מציג רמה גבוהה של פופולריות בעולם הרובי, עם 185 פרויקטים שמשתמשים בו (כפול ממספר הפרויקטים בג'אווה).

בתחום פיתוח הווב אפשר לראות שלמרות הפריצה של תשתיות חדשות בשנים האחרונות (כמו Sinatra, שנכנס לדירוג עם 570 פרויקטים), רובי עדיין נעה בעיקר סביב Rails, עם יותר מ-7,000 פרויקטים העושים שימוש בתשתית. עבור שרתי ווב , ב-Thin (עם 487 פרויקטים) נמצא שימוש גבוה פי 2 מאשר Unicorn.

נראה ש-CoffeeScript, שפת סקריפטינג חדשה המיתרגמת לג'אווה-סקריפט, מתקבלת בחיבוק חם על ידי קהילת הרובי, עם יותר מ-1,000 פרויקטים שעושים בה שימוש.

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

Javascript

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

השימוש ב-Grunt עצום. תשתית האוטומציה Grunt משחקת תפקיד גדול מאוד בפיתוח בג'אווה-סקריפט (בייחוד עבור node.js), והיא נמצאת בשימוש ב-23% מתוך 100 הספריות המובילות. נראה ש-Grunt ממלאת את החלל במעגל ה-build, testing and deployment בג'אווה-סקריפט. תהליך זה מנוהל בשפות כמו ג'אווה באופן חיצוני לפרויקט עצמו, על ידי כלים אחרים כמו Maven או Jenkins.

תכנות לרשת עדיין מהווה בעיה רצינית. חלק גדול מספריות ג'אווה-סקריפט (7% מתוך המאייה הראשונה) מתמקדות בתקשורת לקוח/שרת. כמות זו גדולה פי 3 מאשר בג'אווה וברובי. סביר מאוד להניח כי הסיבה לכך היא הצורך של מפתחי ווב להתמודד עם אקו-סיסטם לא אחידה מאוד בצד הדפדפן מחד, אך בוסרית למדי בצד השרת מאידך. עבור פיתוח ווב בצד השרת – הפריימוורק express עבור node.js מוביל את הטבלה עם 631 רשומות.

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

רוצים לראות את 100 הספריות המובילות בכל שפה? לחצו כאן.

הפוסט פורסם לראשונה באנגלית בבלוג של Takipi.

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

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

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

לעזור לאחרים יכול להיות עסק משתלם

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

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

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

קצב צמיחה אדיר

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

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

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

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

איך עושים את זה נכון?

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

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

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

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

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

"עשו את זה קודם…."

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

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

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

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

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

קרדיט תמונה: africa via Shutterstock.

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

קודם כל – מי אני? למרות שאין לי תואר במדעי המחשב – אני מתכנת כבר 15 שנים. עובד בשעת כתיבת שורות אלו בחברת HP Software (אין שום קשר למדפסות) כמפתח PHP ומפתח כתחביב וכמקצוע.

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

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

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

נשמע נהדר, לא? אז מה הבעיה?

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

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

כשהשכר הוא המניע המרכזי, זו בעיה

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

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

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

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

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

בעשור הראשון של שנות ה-2000, מספר המועסקים בהיי-טק צמח ב-10% בלבד – מ-47 אלף בשנת 2000 ל-56 אלף ב-2010 (מתוך דהמרקר)

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

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

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

הפוסט פורסם לראשונה בבלוג Internet Israel.

קרדיט תמונה: ways via Shutterstock.

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

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

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

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

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

בסופו של שלב זה יוצא מסמך תיכנון המוצר.

הגדרת המוצר עדיין משתנה

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

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

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

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

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

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

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

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

וחוזר חלילה.

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

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

תמונה: צילומסך

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

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

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

אפליה מקלקלת

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

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

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

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

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

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

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

תמונה: flickr, cc-by, langalex

נגישות עסקית

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

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

הנגשת תכנים למנועי חיפוש

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

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

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

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

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

תמונה: flickr, cc-by, Jacob Davies

הנגשה חזותית

בסקר השוק הדמיוני שערכנו לפני הקמת המיזם שלנו, מצאנו שקהל היעד אליו מכוון השירות מורכב מכ-40% משתמשים מעל גיל 45, כאשר מתוכם כ-25% מעל גיל 60 (סה"כ 10% מכלל המשתמשים). אם נבחן לרגע שני מאפיינים נפוצים בקבוצות המשתמשים הללו, נוכל להכליל ולהניח שתי הנחות. ההנחה הראשונה היא שאחוז ניכר מהמשתמשים בקבוצות הגילאים הללו סובלים מלקות ראיה כלשהי. ההנחה השניה היא שהבקיאות הטכנולוגית של המשתמשים השייכים לקבוצות הגילאים הללו נמוכה ביחס למשתמשים צעירים יותר (מה שנקרא – פער הדורות).

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

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

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

1. גודל גופן ומרווחי שורה של לפחות 16 פיקסל ו-140% מגודל הפונט בהתאמה, המאפשרים קריאה נוחה ממרחק סביר ללא מאמץ.

2. ניגודיות (קונטרסט) טובה בין טקסט לרקע שימנעו טשטוש או "בליעה" של טקסט על-גבי הרקע שעליו הוא מוצג.

3. צבעוניות מאוזנת שתמנע רעש חזותי העשוי לבלבל ולעייף את העין בעת הקריאה.

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

1. ממשק חיפוש גדול ובולט המכיל טקסט המסביר את מהות הממשק (למשל "חיפוש מסעדות").

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

3. הבלטת רכיבי הממשק הנ"ל ע"י גודל ומיקום ולא רק ע"י צבע.

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

מילות סיכום

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

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

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

הפוסט בחסות איגוד האינטרנט הישראלי

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

צילום: אבישי בסה

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

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

יופי, איך עושים את זה?

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

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

• מערכת MultiROM - מערכת אשר יושבת בין הקרנל, או הליבה של המערכת לבין ה-init binary אשר אחראי על טעינת כל המחיצות הנדרשות להרצת אנדרואיד על המכשיר.
• ריקברי מותאם אישית ל-MultiROM – ריקברי המגע של TWRP אשר הותאם ושונה בשביל לעבוד עם MultiROM.
• רום נוסף שברצונכם להתקין – בפורמט ZIP.
• דרייברים לנקסוס 7 – כדי שלא יהיו פאשלות.
• Fastboot + ADB – פקודות command line המיועדות למכשירים מבוססים אנדרואיד. הורידו וחלצו אל תיקייה בשולחן העבודה, לתיקייה נקרא Android, לדוגמא.
• boot.img של הרום שלכם לצורך uninstall – במידה ומדובר ברום הרשמי של גוגל, הורידו את הגירסא המתאימה למכשיר שלכם וחלצו משם את הקובץ. במידה ולא, הקובץ נמצא בהתקנה של הרום המקוסטם שהורדתם.

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

• העתיקו את הריקברי המותאם ל-MultiROM, קובץ עם סיומת img, לתיקיית Android. מומלץ לשנות לו את השם ל-recovery.img. את קובץ הרום הנוסף שברצונכם להתקין ואת קובץ ההתקנה של מערכת MultiROM שימו בתיקייה הראשית בזיכרון הפנימי של המכשיר.
• לאחר מכן, חברו את מכשיר הנקסוס 7 למחשב באמצעות כבל USB. אחר כך, היכנסו אל שורת הפקודה של חלונות – cmd ולנווט לתיקיית Android שיצרנו ממקודם.
• הקלידו את הפקודה הבאה בשורת הפקודה: fastboot flash recovery recovery.img – הפקודה הזו למעשה משנה את הריקברי במכשיר שלכם לריקברי מגע מותאם למערכת MultiROM. יש להמתין לסיום הפעולה, ולאחר מכן להיכנס לריקברי של המכשיר על ידי כניסה נוספת למצב Fastboot, ניווט בעזרת החיצים ל-Recovery Mode ולחיצה על כפתור ההדלקה.
• עם הכניסה לריקברי, בחרו ב-Install, נווטו לתיקייה בה העברתם את הקובץ multirom_v2_n7-signed.zip וביחרו בקובץ. אל תשכחו לבצע לאחר מכן Swipe to Confirm Flash בכדי לאשר את הפעולה.
• לאחר סיום התהליך, בחרו ב-Advanced –> MultiROM –> Add ROM, בחרו ב-ROM Type כ-Android וסמנו את הקובץ שהעברתם אל כרטיס הזיכרון. ההתקנה תתחיל, ובסיומה יש לבחור ב-Reboot System.
• המכשיר ייטען, ויקפוץ לכם ממשק אשר ייתן לכם אפשרות לבחור בין הרומים השונים המותקנים על המערכת. בהצלחה!

צילום: אבישי בסה

• מחיקה של רום – במידה והתקנתם רום חדש ואתם רוצים למחוק אותו ולהתקין רום אחר, מחקו את התיקייה multirom מהתיקייה הראשית בזיכרון הפנימי של המכשיר שלכם.
• מחיקת MultiROM – צרבו את קובץ ה-boot.img אשר הורדתם, המתאים לרום המקורי שלכם בעזרת Fastboot, בדיוק באותה הדרך אשר צרבתם את הריקברי המותאם אישית של MultiROM, על ידי הפקודה הבאה: fastboot flash boot boot.img.

גם אני רוצה אובונטו על נקסוס 7

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

את השלבים הנוכחיים של פרוייקט אובונטו לנקסוס 7 תוכלו להוריד מכאן. בחרו בקובץ המתאים לפי המכשיר שבבעלותכם. שימו את הקובץ בכרטיס הזיכרון, וודאו לאחר מכן שיש לכם לפחות 3 ג'יגה של זיכרון איחסון פנויים על הזיכרון הפנימי של המכשיר. כל שעליכם לעשות לאחר מכן, הוא להיכנס לריקברי של TWRP, לבחור ב-Advanced –> MultiROM –> Add ROM, לבחור ב-ROM Type כ-Ubuntu ולסמן את קובץ ההתקנה של אובונטו שהעברתם אל כרטיס הזיכרון. ההתקנה תתחיל מיד, ותימשך באזור 5-10 דקות. יש להתאזר בסבלנות עד לסיום ההתקנה ועליית המערכת.

צילום: אבישי בסה

מקור: יח"צ, עיבוד תמונה

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

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

פלטפורמה להתאמת תוספים לכל הדפדפנים

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

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

מתוסף לסטארטאפ מצליח

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

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

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

תמונה: flickr, cc-by, Dmitry Baranovskiy

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

אז מדוע לדעתי פלטפורמת הג'אווה עדיפה?

1. תאימות בין מערכות הפעלה: קוד Java מהודר לקוד מכונה של ה-JVM. ישנם מספר JVMs בשוק המתאימים למערכות הפעלה רבות כולל פלטפורמות embedded. חברות רבות מריצות אפליקציות ג'אווה על Linux ו-Unix. למרות שגם ל-Net. קיימים מימושים של CLR לפלטפורמות נוספות מלבד חלונות, אבל הם אינם בשימוש נרחב ואין הרבה חברות מסחריות שמריצות קוד עליהם.

2. מבחר גדול של ספריות קוד פתוח: בעולם הג'אווה ישנן אינספור ספריות קוד פתוח (הרבה יותר מאשר ב-Net.). להלן מספר דוגמאות:

• Spring – ספרייה המעניקה שירותי ניהול והזרקת תלויות (Dependency Injection) ומקלה על הפיתוח במבחר תחומים בפיתוח אפליקציות אירגוניות.
• Hibernate – ספרייה נפוצה למיפוי עצמים למסד נתונית רלציוני (ORM).
• Logback – ספריית רישום (logging) בעלת ביצועים מעולים.
• AspectJ – ספרייה לתכנות מונחה היבטים. זאת הספרייה הראשונה שהייתה בתחום ומאפשרת לפתור בצורה מודולרית בעיות רוחביות כגון ניהול טרנזקציות, עיקוב (tracing), ניתוח ביצועים ועוד.
• Akka – ספרייה לפיתוח מערכות מבוזרות ומרובות חוטים (threading) המאפשרת לבנות בפשטות מערכות עם יכולת התרחבות (Scaling) העומדות בקצבים גדולים מאוד.

3. סטנדרטיזציה: בעולם הג'אווה, לרוב הנושאים יש סטנדרטים המוגדרים ע"י אירגון ה-JCP. לכל סטנדרט יש בדרך כלל מספר מימושים, דבר המאפשר לכותבי האפליקציות להחליף מימושים של ספריות ללא צורך לשנות את הקוד. לדוגמה, מי שמשתמש בסטנרדט ה-EJB לכתוב לוגיקה עיסקית ולקבל מספריית שרת האפליקצייה שירותי טרנזקציות וביזור, יכול לעבור משרת WebSphere ל-WebLogic או להיפך. או לעבוד עם JBoss, Geronimo או מספר אחרים. לדעתי זו תכונה חשובה המאפשרת גמישות רבה.

Java EE. 4: ישנם מספר סטנדרטים המתאימים לפיתוח אפליקציות אירגוניות המאוגדים תחת סטנדרט אחד הנקרא JavaEE. המיוחד בסנדרטים אלה הוא העובדה שהם דורשים אפליקציה מיוחדת (Application Server) המעניקה את השירותים הנ"ל. סטנדרטים אלה מטפלים בפיתוח אפליקציות אינטרנט, ביזור אפליקציות בין שרתים, תמיכה ב-security, ניהול משאבים, הודעות א-סינכרוניות ועוד מספר רב של נושאים.

5. תחרות: ישנן מספר חברות גדולות המציעות מוצרים מתחרים בעולם הג'אווה. לדוגמה Oracle, IBM, RedHat שמציעים שרתי אפליקציה. הן מציעות גם סלי מוצרים רבים הכוללים כלי ניהול תהליכים עיסקיים (BPM), פלטפורמות SOA ועוד. ישנם מספר מסדי נתונים בג'אווה, מנועי חיפוש מבוזרים (ElasticSearch, Solr) ועוד…

6. ביצועים: לג'אווה ביצועים טובים ביותר. זה נובע בעיקר מה-JVM והאופטימיזציות החזקות המתבצעות בו. מעבר לכך, ישנם מימושים שונים ל-JVM וחלקם נותנים ביצועים טובים יותר מהאחרים. לדוגמה, ה-JVM של Azul ידוע באוסף האשפה (garbage collector) היעיל מאוד שלו.

7. כיוונון ביצועים: בנוסף לביצועים המצויינים, יכולת קונפיגורציית ה-JVM הינה חזקה מאוד. לדוגמה ל-JVM של Oracle יש למעלה מ-700 תכונות קונפיגורצייה שונות (configuration flags).

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

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

10. פופולאריות: למרות ששתי הפלטפורמות (ג'אווה ו-Net.) ושתי השפות (ג'אווה ו-C#) מאוד נפוצות, עדיין ג'אווה נפוצה יותר וקצת יותר קל למצוא בה מפתחים המנוסים בפלטפורמות השונות. הרבה יותר קל למצוא מפתח ג'אווה שמכיר Hibernate מאשר מפתח Net. שמכיר את NHibernate.

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

Scala הינה שפה עם טיפוסים סטטיים (static typed), מונחיית עצמים ומתאימה לתיכנות פונקציונלי. אני לא ארחיב ואפרט את כל יתרונות השפה כאן, אבל אחזור ואומר שהיא עדיפה מבחינות רבות מ-Java וגם מ-C#. כמובן ש-Scala אינה האפשרות היחידה. ניתן לכתוב גם ב-Clojure, JRuby, Groovy ועוד… ולפיכך ניתן לקבל את יתרונות פלטפורמת הג'אווה יחד עם שפת פיתוח חזקה בעלת יכולות המתאימות לאתגרים התיכנותיים הקיימים היום.

הפוסט בחסות ג'ון ברייס – מכללת היי-טק

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

• Java Programming - בקורס זה נלמד לפתח אפליקציות בתכנות מונחה עצמים בשפת Java הפופולארית.
• JavaEE 6 – קורס זה סוקר את הסטנדרטים המובילים של גרסאת JavaEE החדשה כגון: EJB, Web, JPA.
• Spring 3 – בקורס זה מלמד על ספריית הקוד Spring שהינה מאוד נפוצה ומאפשרת פיתוח מהיר במגוון תחומים ב-Java.
• Scala Programming – בקורס זה נלמד לפתח בשפת ה-Scala שהינה תחליף טוב הרבה יותר מ-Java ומאפשרת פיתוח מהיר יותר עם כמות קוד משמעותית קטנה יותר.
• Hibernate – קורס זה מציג איך לכתוב קוד מונחה-עצמים העובד מול מסד נתונים רלציוני באמצעות ספריית Hibernate הנפוצה.

הרשמה בחודשי דצמבר- ינואר לאחד מהקורסים הנבחרים תזכה אותך, גולש ניוזגיק, ב-10% הנחה.

מקור: יח"צ, עיבוד תמונה

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

אוניברסיטה לפיתוח רומים

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

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

מעל ל-4.7 מיליון משתמשים

קהילת המפתחים של XDA-Developers היא קהילה שנוסדה בשנת 2003 ומשרתת מעל 4.7 מיליון משתמשים מרחבי העולם. מטרת הקהילה היא דיון, פתרון בעיות ופיתוח לאנדרואיד ול-Windows Phone בעיקר. האתר מציע למשתמשים גם מידע כללי על מכשירים של אנדרואיד, תמיכה טכנית, שאלות ותשובות וסקירות מכשירים וקהילות נפרדות קיימות עבור כל אחד מהדגמים של הטלפונים והטאבלטים. עיקר כוחה של הקהילה הוא בהצעת שדרוגי גירסא מותאמים אישית על ידי מפתחים, למכשירים אשר לא נתמכים יותר באופן רשמי על ידי היצרנים שלהם.

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

מקור: יח"צ

יוטיוב הודיעה ביום שישי בבלוג הרשמי שלה על שחרור ספריית ה-API למפתחי אפליקציות לאנדרואיד, שתאפשר להם להטמיע סרטונים באופן מובנה ולהשתמש במגוון האפשרויות שמציעה בתוך האפליקציות שלהם, עם תמיכה בפרסומות ובפיצ’רים נוספים שלא היו זמינים עד עתה. ה-API הוכרז לראשונה בשנה שעברה בכנס המפתחים של גוגל Google I/O 2012.

הטמעת סרטונים באפליקציות

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

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

These instructions explain how to include the YouTubeAndroidPlayerApi.jar client library in your Android application. The library is supported on Android devices running version 4.2.16 or newer of the Android YouTube app

You can use the YouTubeApiServiceUtil class’ isYouTubeApiServiceAvailable method to confirm that a device is compatible

For a simple embed, use the YouTubeStandalonePlayer. To build a more sophisticated user interface, try theYouTubePlayerView or the YouTubePlayerFragment. Fragments can help create an engaging experience as shown in the Video Wall app example

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

קיימות כבר מספר אפליקציות אשר משלבות את ה-API החדש בתוכן, כולל FlipBoard, SoundTracking, BuzzFeed, 9x9tv ו-Skimble. אז אם אתם מתלבטים האם לשלב את ה-API באפליקציה שלכם, תוכלו להציץ באפליקציות הללו על מנת להציץ ביישום מקצועי.

הפוסט נכתב על-ידי דניאל גרינפלד ותורגם על ידי אבישי בסה. דניאל גרינפלד הוא מנהל פיתוח בחברת Cartwheel Web Development, לוס אנג'לס, קליפורניה.

תמונה: flickr, cc-by, @boetter

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

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

אנחנו יודעים את זה, מנהלים טובים יודעים את זה, חברות טובות חיות מזה.

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

האם יש דרך לתקן את המצב?

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

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

אז איך בכל זאת אפשר לתקן את זה?

1. יום עשייה - אחד מהחברים שלי, קרייג קרסטינס, מתאר כיצד חברת Heroku נותנת למהנדסים שלה יום אחד מלא בשבוע (חמישי) אשר מתרכז בסיום משימות. בלי פגישות, בלי ישיבות, רק 100 אחוזים של זמן שקט ללא הפרעות אשר מתמקד בעשיית דברים בלבד.
2. חלוקת זמנים - החל משנת 2010, חברת Eldarion פירקה את יום העבודה שלה ללפחות שני בלוקים של פעילות ללא הפרעות. בין נתחי הזמן היה אפשר לתקשר עם עמיתים לעבודה. היתרון בגישה זו הוא שגם אם עשיתם משהו לא בסדר, או שלמישהו הייתה שאלה קריטית לשאול אתכם, בנתח הזמן הזה שבין זמן הפעילות, היה ניתן לטפל בבעיות הללו. בתיאוריה, זוהי הדרך אשר הרבה מקומות עבודה עובדים על פיה (הפסקה בזמן ארוחת הצהריים). המציאות היא שההפרעות עדיין קיימות וקורות. בחברת Eldarion זה עבד מפני שכולם היו רחוקים אחד מהשני.
3. מיקום חדש לשולחן העבודה - אם אתם עובדים במשרד, בקשו לעבור למקום עם פחות תנועת הולכי רגל. החיסרון בעניין הוא שאתם יכולים בסופו של דבר להיתקע במקומות רועשים, קרים ואפלים.
4. עבודה חדשה - לעבור למקום עבודה חדש שמבטיח פחות הסחות דעת.

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

הפוסט פורסם במקור באנגלית בבלוג pydanny

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

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

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

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

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

עכשיו, בואו נחשב שניה במספרים, כדי להבין את סדרי הגודל: גרסה 1.6: 1.44 מיליון מכשירים (0.3% מ-480 מיליון). גרסה 2.1: 12.96 מיליון מכשירים. גרסה: 2.2 49.44 מיליון מכשירים. גרסאות 2.3 עד 2.3.7: כמעט 244 מיליון מכשירים. ובקיצור קצת יותר מ-65% מאוכלוסיית האנדרואיד, שהם יותר מ-310 מיליון מכשירים ברחבי העולם, בעלי גרסאות ישנות.

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

מה זה אומר לנו?

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

אז נעלת את המכשיר ו…?

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

/data/system/gesture.key
/data/system/password.key

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

אז מה צריך בשביל זה:

1. USB Debugging פועל, במידה והוא לא פועל ניתן להריץ את הפקודות דרך ה-Recovery (במידה ויש. במידה ואין, לא יהיה ניתן למחוק את הקובץ כשהמכשיר כבר נעול, למרות שלרוב ניתן "לדחוף" את הריקברי המפותח "בכוח", במצב של Fastboot).

2.יש לציין כי לא חשוב אם קיימות הרשאות root או לא.

הפקודה:

adb shell rm /data/system/gesture.key

או:

adb shell rm /data/system/password.key

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

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

rm זהו קיצור של remove. ובכך אנחנו מסירים את הקובץ gesture.key (או password.key) שנמצא בנתיב /data/system (לפעמים לאחר הרצת הפקודה יש לכבות-ולהדליק את המכשיר).

בנוסף יש לציין כי הפרצה נבדקה ועובדת על גרסאות 2.1 – 2.2 – 2.3.3 – 4.0.3 – 4.1.2 – 4.2 המהווים קצת יותר מ-95% מסך המכשירים המאוקטבים היום (וניתן להניח כי הפרצה עובדת גם על גרסאות קודמות יותר).

יש לציין כי הפרצה נוסתה על גרסת AOSP – גרסה נקייה של אנדרואיד, ואשמח לשמוע אם היא עובדת על המכשירים עם הממשקים השונים (sense של HTC, touchwiz של Samsung וכד').

גישה לכרטיס ה-SD ובעיית המפתחים

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

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

להלן כמה דוגמאות של המידע שאנו מאכסנים (בכוונה או ש"מאסחנים אותו בשבילנו"):

1. כל אפליקציה שמותקנת אצלנו במכשיר יוצרת תיקייה בנתיב Android/data/, וכך ניתן לקבל רשימה של כל האפליקציות המותקנות אצלנו במכשיר.

2. ניתן לראות / להעביר את כל הסרטונים, התמונות והשירים שיש אצלנו ב-SD.

3. במידה וביצענו גיבוי של אנשי הקשר ב-SD, קובץ ה-VCF חשוף לגמרי וכולם יכולים לראות את אנשי הקשר שלנו (עם כל המידע שרשום אצלנו כמו קישור לפייסבוק, כתובות מייל וכד').

4. גישה למידע של אפליקציות. דוגמאות:

1. Dropbox שם כל אחד יכול לראות את התמונות/קבצים/מסמכים שהורדתי/העליתי ל/מהמכשיר.

2. SMS Backup & Restore שמגבה את כל ה-SMS-ים שלי, וכל אחד יכול לפתוח את הקובץ ב-Notepad ולקרוא את כל ה-SMS-ים שכתבתי אי פעם.

3. Waze שומרת קובץ בשם waze_log בו קיים המידע של האפליקציה בעת ההתקנה כמו על איזה מכשיר היא הותקנה (דגם מדויק), איזה גרסת אנדרואיד (לפי API), מתי היא הותקנה, גרסת רום, איזה גרסה של האפליקציה, על איזה רשת התחברתי וכד'.

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

4. Readitlater שומרת אתרים וכתבות כדי שנוכל לקרוא אותם אחר כך (ועל הדרך בצורה נוחה), איפה היא שומרת את הכתבות, בנתיב: \Android\data\com.ideashower.readitlater.pro\files\RIL_offline\RIL_pages

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

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

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

6.אפליקציה בשם 1Weather ששומרת בקובץ שכל אחד יכול לקרוא את המיקום שבו הייתי לפי תאריך, שעה, מזג האוויר באותו מיקום וכו'.

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

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

הצפנה

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

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

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

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

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

החידושים של Jelly Bean בתחום האבטחה (4.1 – 4.2)

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

נעילת הפנים

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

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

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

ASLR

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

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

כמו שניתן לראות בתמונה:

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

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

סריקת אפליקציות בזמן אמת ב- Play

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

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

ה-Bouncer מבצע עוד פעולות, הנ"ל הוא הסבר במשפט, רק כדי להזכיר. למידע מלא יש לקרוא את המאמר הקודם. (קישור בסוף הפוסט)

שורש הבעיה

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

הירושי לוקהיימר (Hiroshi Lockheimer) סמנכ"ל ההנדסה בצוות אנדרואיד מסביר על סריקת האפליקציות במכשיר: "יש לנו קטלוג של 700,000 יישומים ב-Play, ומעבר לכך, אנחנו תמיד סורקים חומר באינטרנט במונחים של רכיבי APK שמופעים. כעת, יש לנו הבנה די טובה של המערכת של האפליקציה, לא משנה אם ה-APK ב-Play או לא."

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

מסך ההרשאות

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

התראה על הודעות טקסט (SMS) בתשלום

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

SELinux

SELinux (ראשי תיבות: Security-Enhanced Linux) היא סדרה של תוספים לקרנל וכלים למשתמש שניתן להוסיף להפצות השונות של לינוקס. הפרויקט עצמו התחיל לראשונה בידי ה-NSA. ב-SELinux, הקונספט של root לא קיים. מדיניות האבטחה נקבעת בידי האדמין ותקפה על כל תהליך ואובייקט הקיים במערכת, ואף אחד לא יכול לעקוף זאת.

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

• כמובן שגוגל לא סוגרת את אפשרות ה-root. האופציה הזאת תהיה אופציית בחירה במכשיר, וכנראה שלרוב רק ארגונים גדולים יחייבו את העובדים שלהם לבצע שימוש באותה אופציה.
• כפרויקט קוד פתוח, צוות הפיתוח של אנדרואיד מקבל כל הזמן קוד חדש ומשלב אותו במערכת, פרויקט שילוב ה-SELinux באנדרואיד (נקרא גם SE Android) החל בינואר האחרון על ידי ה-NSA (בעוד אנדרואיד מתבססת על לינוקס היא לא לינוקס, וה-NSA ביצע שינויים כדי להתאים את התוספים והכלים למערכת האנדרואיד), וניתן לראות כי גוגל אכן משלבת כל הזמן עוד חלקי קוד עם פרויקט האנדרואיד.

סיכום

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

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

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

*  *  *

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

הפוסט פורסם לראשונה בגיליון ה-38 של מגזין Digital Whisper מינואר 2013.

מקור: Flickr, cc-by-fostersartofchilling

הפוסט נכתב במקור על ידי פיטר רובינט, מייסד ומנכ"ל חברת Bubble Foundery המפתחת אפליקציות Web ומובייל.

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

וזו היתה התשובה שלי

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

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

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

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

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

רעיונות לא ריאליסטיים

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

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

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

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

הפוסט תורגם מאנגלית ופורסם במקור בבלוג BubbleFoundry

מחפשים אירועי פיתוח?

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

תמונה: יח"צ, עיבוד תמונה

חברת האנליזה למובייל VisionMobile, פרסמה לאחרונה דו"ח רביעי בנושא כלכלת מפתחים. הדו"ח לשנת 2013 שנתמך על ידי חברות כמו AT&T, מוזילה, נוקיה ועוד, בוחן את דעתם של המפתחים, ומשרטט לפי זה תמונה הנוגעת לאיזו מהפלטפורמות הקיימות בשוק זוכה לדעת הקהל הגבוהה ביותר בקרב קהילת המפתחים, וכמו כן איזה מהפלטפורמות מניבה את הרווחים הגבוהים ביותר למפתחים שלה.

לאור העובדה שפלטפורמת האנדרואיד זוכה לנתח שוק גבוה יותר מזה של האייפון פי כמה וכמה (האייפון מהווה כרבע מנתח השוק העולמי בסמארטפונים ואילו אנדרואיד ליותר מ- 70% כשביחד 2 הפלטפורמות מהוות קצת יותר מ- 90% מנתח הסמארטפונים העולמי) מפתיע לגלות ש- iOS מובילה בדעת הקהל של המפתחים, כאשר כמעט 50% מהמפתחים ציינו שמדובר בפלטפורמה המועדפת עליהם. אחרי iOS ניתן למצוא את אנדרואיד ואת בלקברי כשהן מקבלות גם עדיפות גבוהה. באופן מעניין פלטפורמת WP של מיקרוסופט ו- HTML מסומנות על ידי מפתחים כאמצעי להרחבת השוק של האפליקציות שלהן ולא כיעד מועדף לפיתוח והפצה.

7 מילארד דולר למפתחים

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

חברת App Annie מוסיפה קצת יותר מידע לגבי הנושא כשהיא מחדדת מצד אחד את העובדה שפיתוח לפלטפורמת האנדרואיד נמצא בתנופה, אך מצד שני נראה כי האפסטור עדיין יוצרת פי כמה וכמה (לפי הדיווח פי 3.5) יותר הכנסות עבור המפתחים, אם כי בלומברג מפקפקים קצת באמינות המספרים של App Annie. הדיווח מוסיף ומציין כי המדינות העקריות שיוצרות הכנסה למפתחי האפסטור ומהוות כ- 60% ממקור הרווחים הן: ארה"ב, יפן, אנגליה, אוסטרליה וקנדה כאשר סין, למרות שעדיין נמצאת עם השפעה קטנה הולכת וצוברת תאוצה.

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

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

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

המפתחת המובילה ל-iOS: גוגל

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

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

הפוסט נכתב על ידי נתי שוחט ופורסם לראשונה בבלוג iPhones.co.il.