שם: Webzai

פיץ' במשפט: החברה מפתחת פלטפורמה לבניית אתרי אינטרנט הכוללת פונקציונליות מתקדמת ומאפשרת למשתמשים לבנות אתרים ללא צורך בהרשמה מוקדמת לשירות.

כיצד משתמשים ב-Windows Azure: חברת Webzai משתמשת בטכנולוגית הענן של מיקרוסופט, Microsoft Azure על מנת לאחסן את כל המידע המרכיב את אתרי האינטרנט הנבנים על ידי הפלטפורמה על גבי CDN. ה-CDN מאפשר טעינה מהירה של האתרים מכל מקום בעולם.

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

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

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

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

כלי בניית האתרים של Webzai מציע למשתמש את כל היכולות והאפשרויות המתקדמות הנפוצות בשוק לבניית אתרים כיום. בין הפיצ'רים איתם מגיעה Webzai ניתן למצוא מבחר של מעל ל-100 תבניות מוכנות מראש ל-Plug & Play הידידותיות למנועי חיפוש, אלמנטים מובנים של גלריות ותפריטים, חיבור לרשתות חברתיות כגון Facebook, Twitter, Google Plus והטמעה של תכנים מאתרים כמו YouTube, אפשרות לבניית חנות מקוונת ואינטגרציה עם PayPal, חיבור לשירות הסטטיסטיקה של Google Analytics והעלאת קבצים ואפשרות להוספה עצמית של קוד HTML, CSS ו-Javascript אל תוך הדף.

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

בנוסף, ניתן למצוא ב-Webzai מגוון פיצ'רים מתקדמים לבניית אתרים אשר נותנים למעצב האתר חופש מוחלט בבנייה שלו ללא כל ידע מקדים בתכנות. ביניהם ניתן למצוא יכולות עיצוב גרפי מתקדמות בעורך האתרים של החברה, אשר משלב בתוכו כלי עיצוב שעד כה היו זמינים בכלים מקצועיים לעיצוב גרפי, כגון העתקה והדבקה של עיצוב בין אלמנטים, בחירה ועיצוב מרובה ובמקביל של אלמנטים, קבוצות אלמנטים, Grids, Fixed Layouts, Gradient Coloring ועוד.

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

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

עורך האתרים של Webzai. מקור: יח"צ

מדריכי צעד אחר צעד מפורטים למשתמשים לא-טכנולוגיים

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

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

המודל העסקי של Webzai מבוסס על Freemium, כאשר האתר הנבנה במערכת יופיע עם באנר החברה בתחתית ומגיע עם שטח אחסון חינמי של 250MB ותעבורה חודשית של 1GB. החברה מציעה מספר חבילות פרימיום אשר מחירן נע בין 6$ ל-20$ בחודש, המאפשר למשתמשים להסיר את הבאנר, לקבל אחסון מורחב עד 10GB ותעבורת משתמשים בלתי מוגבלת. למעצבים, החברה מציעה מבצע מיוחד, במהלכו חבילת פרימיום לשנתיים תינתן בחינם לכל מעצב או חברה לעיצוב אתרים אשר תבחר להקים את האתר שלה על גבי הפלטפורמה.

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

סרטון וידאו: הכירו את הפלטפורמה של Webzai

קרדיט: cbren, devianart

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

After years of effort, Substrate for Android is finally released, along with full documentation for iOS Substrate ;P. cydiasubstrate.com

— Jay Freeman (saurik) (@saurik) May 14, 2013

רומים מותאמים אישית – פאסה, Framework אלטרנטיבי – העתיד

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

בולט בנוכחותו: WinterBoard

התוסף הראשון והיחיד שכרגע ניתן להוריד דרך Cydia Substrate הוא מנוע תבניות הבסיס המוכר לכולם ממכשירי האייפון, Winterboard אשר מגיע לראשונה למערכת ההפעלה אנדרואיד. משתמשים אשר התקינו לא מכבר רומים מותאמים אישית על המכשירים שלהם, בוודאי מכירים את ה-Theme Chooser אשר נתמך כברירת המחדל על ידי הרומים של CyanogenMOD והוטמע בהמשך על ידי אחרים. עצם העובדה שאושייה כל כך ידועה ומשפיעה על עולם האייפון מצטרפת אל קרב מפתחי הרומים באנדרואיד עשויה למשוך ללא ספק מפתחים רבים אל ה-Framework האלטרנטיבי שלו.

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

להורדת Cydia Substrate לאנדרואיד

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

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

אלן ווירפס-ברוק (Allen Wirfs-Brock) העומד בראש הפרויקט לתקינת ECMAScript 6 היה ה-Keynote Speaker עם הרצאה מרתקת ומעוררת השראה. בהיותו איש מחשבים ותיק (בניגוד לחלק גדול מהנוכחים בכנס שממוצע הגילאים שלהם היה להערכתי 25-35), הוא סיפר על התפתחות המחשוב התאגידי שנשלט ברובו ע"י IBM והשפות COBOL/Fortran.

בשנות ה-80 התרחשה מהפכת המחשוב האישי (ה-PC) שהכתיר את אינטל למובילת התחום עם ++C. כיום, לפי אלן, אנו עומדים בפתחה של תקופת המחשוב האמביינטי, תקופה בה המחשבים יהיו מודעים לקיומם של אנשים ויגיבו בצורה משמעותית לכך. כבר כיום ישנם שלל מכשירים אשר לא מנסים להיות ה-PC באריזה שונה, אלא כולם מחוברים יחדיו ומציגים חוויה אחידה כאשר הפלטפורמה שהמכשירים הללו משתמשים בה היא Web, כלומר HTML, CSS ו-JavaScript. דוגמאות לכך ניתן לראות בהתרבות אפליקציות מבוססות HTML5 בטלפונים הניידים והטאבלטים, מערכות הפעלה למכשירי מובייל, בטלויזיות חכמות ומוצרים נוספים כמו שעוני יד חכמים או המשקפיים המהפכניות של גוגל.

בואו נעשה const ו-let ביחד כבר היום, אולוב לאסוס

בכנס דובר רבות אודות ECMAScript 6, אשר טיוטת התקן שלו צפויה להיות מוכנה עד סוף השנה וה-Working Group שלו צופה לאשרה כתקן עד סוף 2014. אולוב לאסוס (Olov Lassus) הציג את פרויקט ה-DEFS.js שלו, precompiler ל-JavaScript המאפשר להשתמש ב-let ו-const של ECMAScript 6 כבר היום.

פרט לכך, DEFS.js מבצע ניתוח של הקוד ומתריע על בעיות scope פוטנציאליות. היופי בפריקומפיילר זה הוא שבעתיד הקרוב יחסית, כאשר הדפדפנים יתמכו ב-EC6 בצורה טובה יותר, ניתן יהיה פשוט לוותר על השימוש בו. כמו כן, הוא כמעט ולא משנה את הקוד המקורי שלנו פרט להוספת suffix (של דולר ומספר אינדקס) למשתנים שהוגדרו כ-let/const בצורה צפויה מראש ללא שינוי מספרי שורות.

function fn() {
	let y = 0; // z is certainly not defined here

	for (let x = 0; x < 10; x++) {
		let y = x * 2;
		let z = y;
	}

	console.log(y);  // prints 0
	// z is not defined here
}

function fn() {
	var y = 0; // z is certainly not defined here

	for (var x = 0; x < 10; x++) {
		var y$0 = x * 2;
		var z = y$0;
	}

	console.log(y);  // prints 0
	// z is not defined here
}

שיקולים לשיפור ביצועים במובייל, אסטל וואי

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

• העדיפו להשתמש ב-JPEG על פני PNG או GIF. זאת בעיקר מאחר ו-JPEG לא תומך בשקיפות ולכן נדרשים פחות משאבים (=חשמל) לרינדור התמונה.
• מזערו את כמות האלמנטים ב-DOM למינימום האפשרי.
• הקטינו את כמות קוד ה-JavaScript שאתם טוענים. כלומר, אם חשבתם שמאחר ואתם טוענים את jQuery והספרייה תהיה ב-cache של הדפדפן אתם "מוגנים" אז אתם כנראה טועים שכן הדפדפן בכל זאת צריך לפרסר את כל הקוד של הספרייה. לכן, אם אתם מוסיפים את jQuery (או כל ספרייה אחרת) לפרוייקט רק כדי לעשות דברים שיכולתם לעשות באמצעות Vanilla JS, וותרו על כך. זכרו גם כי מכשירי המובייל בד"כ מריצים דפדפנים מודרניים המאפשרים לעשות את מה שספריות כמו jQuery מנסות להשלים בצורה מלאכותית. לדוגמה, הדפדפנים תומכים ב- Query Selector ולכן אין צורך ב- Sizzle, המנוע שמאפשר ל-jQuery לבחור אלמנטים ב-DOM.
• השתדלו לוותר על אנימציות מבוססות JavaScript והשתמשו ב- CSS transitions/animations על מנת להשיג תוצאות דומות. הרווח מסעיף זה הוא איננו רק חסכון בסוללה, אלא גם אנימציות חלקות יותר.

נקודת תורפה נוספת של מכשירי המובייל היא שחיבור האינטרנט מתבצע באמצעות רשת הסלולר. במחשב רגיל התקשורת עוברת מהמחשב ישירות לספקית הרשת (ISP) ומשם לשרת היעד. לעומת זאת, בסלולר על התקשורת לעבור באנטנה הסלולרית ובתשתית של חברת הסלולר ורק לאחר מכן להמשיך לספקית הרשת ולשרת היעד. לכן חשוב מאוד למזער חיפוש (lookup) ב-DNS במידת האפשר, להקטין את כמות הבקשות לקבצים חיצוניים (CSS, JS, פונטים, תמונות וכו') מהשרת ולאחד אותן במידת האפשר. ניתן להשיג את המטרה הזאת באמצעות שימוש בספרייטים או ב-Data URI, חיבור מספר קבצי JS או CSS יחד וכו'.

טכניקת עבודה נוספת ומומלצת היא להשתמש ב- Web Storage, כלי מתקדם נוסף שזמין לנו כבר היום במכשירי המובייל, על מנת לעשות caching חכם בצד לקוח. עלינו לשאוף לדחוס גם את התמונות שלנו למקסימום האפשרי. ניתן להשיג זאת ע"י מזעור השימוש ב-Animated GIFs (ולהחליפן באנימציות CSS כמובן) וכן לוותר על שקיפות alpha בתמונות PNG. מומלץ להשתמש בכלים כמו TinyPNG למזעור התמונות. בנוסף, במקרים רבים ניתן להמנע מתמונות לאייקונים לגמרי ע"י שימוש בספריות אייקונים דוגמת Font Awesome או CopyPasteCharacter (שאפילו לא דורש טעינה של שום דבר נוסף על מנת להשתמש בה – רק להעתיק ולהדביק).

אופטימיזציה נוספת היא להשתמש ב-CSS Transformations לאנימציות במידת האפשר (לדוגמה לצורך הזזת אלמנט ממיקום אחד לאחר – במקום שימוש ב- absolute/top/left). זאת מאחר שבצורה כזאת לא מתבצע reflow מיותר של העמוד בגלל שפונקציית ה-transform משתמשת באותו ה-bitmap על מנת לעשות את המניפולציות הגרפיות ולא מציירת את האלמנט(ים) מחדש. בנוסף אנחנו גם מרוויחים ביצועים טובים יותר מאחר ונעשה שימוש בהאצת חומרה, כלומר בכרטיס הגרפי של המכשיר.

אסטל הציגה שיטה מאוד מעניינת להשגת התנהגות של Responsive Images (שכרגע לצערנו זו רק הצעה לתקינה) תוך שימוש ב-CSS ו-SVG בלבד, בניגוד לשיטות הנהוגות כיום המאפשרות לבצע זאת באמצעות JavaScript בלבד. הטריק בשיטה שאסטל הציגה מתבסס על כך שבמידה ועובדים עם SVG ובתוכו משתמשים ב-media query, אזי ערכי ה-min/max-width/height מתייחסים לגודל האלמנט בעמוד ולא לגודל חלון הדפדפן. בצורה כזאת נוכל להכין לנו קבצי SVG לכל סט של גדלי תמונות ולהטמיעה את קובץ ה-SVG כאילו היה תמונה. כך תמונת ה-SVG שניצור תהיה רספונסיבית ותציג את התמונה המתאימה לגודל הרצוי.

המטרה: אנימציות חלקות בדפדפן, ג'ק ארצ'יבלד

ג'ק ארצ'יבלד (Jake Archibald) משמש כ-Developer Advocate בגוגל. ג'ק הדגיש את חשיבות השימוש בכלים שהדפדפנים המודרנים כוללים על מנת לבדוק ולשפר את ביצועי הקוד אותו אנחנו כותבים, או במילים שלו – "Tools, not Rules".

בהרצאה שלו ג'ק הציג בצורה מדעית (באמצעות ה-profiler של Chrome DevTools) באיזה שלב של הרצת הקוד אנחנו "משלמים" הכי הרבה בביצועים וגורמים לדפדפן לעבוד קשה כדי לצייר על המסך את מה שהעמוד מכיל. הירידה הזאת בביצועים באה לידי ביטוי בכך שמאחר וכל ציור של פריים לוקח יותר זמן, הדפדפן מספיק לצייר פחות פריימים בשניה ולכן מדד ה-FPS (Frames Per Second) יורד למספרים נמוכים.

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

background-position: fixed;

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

ג'ק הסביר בהמשך את הבעייתיות עם אנימציות על מסכים בכלל ובתוך הדפדפן בפרט ולאחר מכן הציג את צורת העבודה הנכונה כדי להשיג אנימציות חלקות בדפדפן. הבעיה, תחילה, נובעת מכך שעלינו לסנכרן בין ציור הפריימים בדפדפן לבין קצב הריענון (refresh rate) של המסך. פתרון הטוב ביותר הוא יצירת אנימציות באמצעות CSS. במידה ואתם צריכים אנימציות מבוססות JavaScript, אז הדרך הטובה ביותר היא עבודה עם requestAnimationFrame ו-fallback בדמות setTimeout של 16.7 שניות. למה 16.7? תצטרכו לעבור על המצגת המדהימה שלו.

כך שלסיכום, עליכם כל הזמן לשאול את עצמכם WTFPS?!

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

המחשבה מאחורי BEM, ורוורה סטפנובה

ורוורה סטפנובה (Varvara Stepanova) היא ראש צוות פיתוח צד קדמי ב-Yandex.ru, הגוגל הרוסי. בהרצאתה היא הציגה את פרויקט BEM (שזה Block Element Modifier). מדובר בכלי פנימי של יאנדקס שפותח על ידם החל מ-2005 וכעת הם שחררו אותו כפרויקט Open Source.

מההרצאה, כמו גם משיחה שניהלתי עם ורוורה לאחר מכן קשה שלא לשים לב שיאנדקס צמאים לדחוף את הפרוייקט הזה קדימה וישמחו לקבל pull requests ב-GitHub. לי אישית הפרויקט הזה מזכיר קצת את Twitter Bootstrap שכן גם הגרעין שלו הוא קופמוננטות (בלוקים בשפת BEM) לשימוש ב-UI של אתרים ואפליקציות ווב.

בולטת מאוד העובדה שקיימת פילוסופיה שלמה העומדת מאחורי הפרויקט והושקעה בה מחשבה רבה שכן יאנדקס מפתחים אותו במשך כ-8 שנים ומשתמשים בו בלמעלה מ-100 שירותים שונים שלהם. פרט לאפשרות לייצר קומפוננטות באמצעות BEM, הפרויקט מגיע עם מספר כלים מעניינים נוספים, אחד הבולטים שבהם הוא CSS Optimizer, או CSSO בקיצור. ה-CSSO מאוד הזכיר לי גירסה קצת מצומצמת של SASS + Compass. כשורווה נשאלה למה CSSO עדיף על SASS, תשובתה הייתה פשוט "כי ככה". כמובן שתשובה מסוג זה גררה צחוק ומחיאות כפיים רבות מהקהל. ללא ספק מומלץ לבדוק את BEM. יש לו תיעוד רב באנגלית וגם עומדת מאחוריו חברת ענק בשוק הרוסי ומציעה גישות קצת שונות לכל נושא הקומפוננטות שאנחנו (הישראלים שהולכים בעיקר אחרי הטרנדים האמריקאים והאירופאים) כמעט ולא נחשפנו אליהן.

הכירו את השגיאות שלכם, דייגו אנטונס

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

אחת השיטות הפשוטות ביותר שהוא הציג להתמודדות עם ניטור ומעקב אחר שגיאות JavaScript היא שימוש ב- window.onerror, כך ניתן בקלות להתמודד עם שגיאות המתרחשות בקוד או לכל הפחות להשתיק אותן מבלי שהמשתמשים ירגישו. במידה ונהיה מעוניינים לשמור את השגיאות, מומלץ לעשות זאת באמצעות Pixel Image; השיטה שנמצאת איתנו כבר שנים רבות מתבססת על טעינת תמונה בגודל 1×1 פיקסלים והוספת query string לכתובת של התמונה עם מידע אותו ברצוננו להעביר לשרת. נעדיף להשתמש בשיטה זו במקום AJAX request מאחר וייתכן והבעיה שיצרה את השגיאה נעוצה דווקא ב-AJAX. כלומר, ננסה לכתוב כמה שפחות קוד JavaScript על מנת לדווח על השגיאה ונשתמש בתכונות הבסיסיות של הדפדפן לטעינת תמונות על מנת להעביר את הדיווח לשרת.

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

מיקרו-ספרייה מעניינת שדיאגו הציג היא stacktrace.js אשר עוזרת מאוד לקבל מידע רב על השגיאות שהתרחשו ושימושית במיוחד בדפדפנים בעייתים ל-debugging כגון IE לדורותיו. בנוסף, ישנם שירותים קיימים לניטור שגיאות JavaScript כגון: Qbaka, Errorception, jsErrLog, Muscula ונוספים. רובם ככולם מאוד דומים בפונקציונליות שלהם פרט לכך שחלקם מוצעים במודל של SaaS ואחרים ניתנים להתקנה על השרת שלכם.

בקטנות

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

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

זביגניו ברנצקי (Zbigniew Braniecki) יחד עם סטאש מאלולפשי (Staś Małolepszy) הציגו את L20N, ספריה ללוקאליזציה של ממשקי UI עם גישה שונה ומעניינת. בין היתר הספריה חוסכת כתיבה של הרבה קוד מותאם אישית המטפל בתרגומים וכן מאפשרת שינוי הטקסט בהתאם לארועים שונים בדפדפן כמו orientationchange לדוגמה. מוזילה משתמשת בספרייה זו ב-Firefox OS לצרכי לוקאליזציה ותומכת בפרוייקט. שווה בדיקה.

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

ריצ'ל אנדרו (Rachel Andrew) היא הבעלים של חברה בריטית המפתחת מערכת ניהול תוכן קטנה. מאחר ומדובר במערכת להצגת תוכן, כל נושאי ה-layout קרובים מאוד לליבה. ריצ'ל סקרה את החידושים שמגיעים לדפדפנים בימים אלו כמו עמודות, flexbox החדש, ה-grid, ה-regions ונוספים.

סבסטיאן גולש (Sebastian Golasch) הציג את Dalekt JS, כלי לאוטומטיזציה של בדיקות UI ופונקציונליות אשר שואב השראה (וגם מממש) מ-Selenium WebDriver. הכלי כרגע בשלבי פיתוח מוקדמים אך נראה מבטיח. המטרה היא ליצור כלי שיאפשר ל-FED-ים להריץ דפדפן וירטואלי ולשלוט עליו מקוד ה-JavaScript אותו כולנו מכירים. בצורה כזאת ניתן יהיה לבצע בדיקות כמו לחיצה על קישורים ווידאו הכתובת אליה הדפדפן הועבר או בחירת אפשרויות ב-select.

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

סיכום

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

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

cc-by-fraserspeirs

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

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

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

לא מפתחים בקוד פתוח ורוצים להתחיל? ג'ון-ברייס מכללת הי-טק מספקת מגוון קורסים בתחום פיתוח בקוד פתוח כולל קורסים בשפות Ruby-on-Rails ו-Python למתחילים ולמתקדמים.

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

אז קדימה, אתם עוד פה?

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

מחשב מיני PC מדגם MK802iii

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

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

עדכון 13/05/13: התחרות הסתיימה והזוכים קיבלו הודעה על זכייתם. שמות הזוכים יפורסמו בפוסט זה בקרוב.

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

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

הרשמה בחודשי מאי לאחד מהקורסים הנבחרים תזכה אותך, גולש ניוזגיק, במלגה על סך 500 ₪

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

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

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

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

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

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

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

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

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

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

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

תרחיש לדוגמה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הסבר קצרצר:

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

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

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

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

אספתי עבורכם כמה דוגמאת לתוצאות המכילות דפים כאלו:

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

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

לסיכום

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

הפוסט פורסם לראשונה בבלוג אני, אדיר.

מקור: Flickr, cc-by-Onesu Bieru

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

דניאל גרינפילד, 'שקט, מפתחים'.

איפה הזמן?

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

מקור: Electric Cloud

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

לא עובדים מהר מספיק

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

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

מקור: flickr, cc-by Bekathwia

פרוטוקול ה-HTTP הוא הפרוטוקול האחראי באינטרנט על שיתוף דפי HTML. רשת האינטרנט נבנתה בחשיבה על מספר רב של שירותים: דואר אלקטרוני, צ׳אט (IRC), שיתוף קבצים (FTP), תקשורת טקסט (Telnet) ועוד. אני לא חושב שבימים הראשונים של האינטרנט היה ברור איזה תפקיד משמעותי יהיה ל World Wide Web, לדפי ה HTML.

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

בראשית ימיו (HTTP 0.9, שנת 1991) פרוטוקול ה-HTTP היה בסיסי ביותר ונועד רק להעביר קבצי HTML (ללא קבצי CSS או js) בצורה סטנדרטית על גבי פרוטוקול TCP. מסמך ה-Specification שלו היה באורך עמוד וחצי. פחות מעשור לאחר מכן (1999), הוגדר פרוטוקול HTTP 1.1, שמסמך ה-Specification שלו הוא באורך 360 עמודים – עליה תלולה במורכבות ובאחידות של הפרוטוקול.

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

On the Wire

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

בקשה נראית כך:

POST /lyrics_server/my_song.php HTTP/1.1
Host: www.lyrics.com
User-Agent: My-Home-Made-Browser/0.1a
Content-Type: text/plain
Referer: http://softwarearchiblog.com

text="Att ahla Hamuda!"&action=post

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

<http method> <url> <http version>
<headers>
<empty line>
<body>

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

HTTP Methods

פרוטוקול HTTP מתאר משאבים (resources, שם נרדף אחר הוא מסמכים documents), המתוארים ע"י URL ופעולות (method או verb) שניתן לבצע עליהם. המשאב יכול להיות קובץ "'קיים" / "סטטי" (למשל קובץ HTML, CSS) או קובץ שנוצר באופן דינמי עבור כל בקשה (למשל דו"ח מצב העובדים). אין מניעה שקבצי HTML או CSS ייווצרו גם הם באופן דינאמי, וזה בדיוק מה שעושים שרתי אינטרנט כמו Tomcat, IIS בעזרת טכנולוגיות כמו ASP.NET או Servlet בהתאמה.

HTTP/1.0 הגדיר את המתודות הבאות:

• Safe Methods: שהן GET, HEAD ו OPTIONS.
• Unsafe Methods: שהן: POST, DELETE ו PUT.

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

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

פתרון מקובל לבעיה היא "תבנית עיצוב" שנקראת (Post/Redirect/Get (PRG בה לאחר פעולת POST השרת מבצע פעולת redirect (קוד 302 שמתואר בהמשך) לעמוד GET שאין שום מניעה לעשות Refresh.

הבדל חשוב לא פחות הוא שתוצאות של פעולות "בטוחות" ניתן לשמור כ-Cache. רכיבי רשת שונים (gateway, proxy, cdn) עשויים לשמור עותק מקומי של תוצאות של פעולות בטוחות ולהחזיר את התשובה עבור בקשות עתידיות. כמובן שחשוב שיהיה תהליך invalidation בו לאחר זמן, התוצאות שנשמרו ב-cache יזרקו לטובת תוצאות מעודכנות יותר.

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

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

שורה ריקה ושורות חדשות

תקן HTTP 0.9 קבע שכל שורה צריכה להסתיים ב-LF (בשפות תכנות רבות: "n\") או ב-CRLF (בשפות תכנות רבות: "r\n\"). תקן 1.1 קבע שגם CR (בשפות רבות: "r\") הוא סוף שורה תקני. כיצד יודעים אם CRLF הוא סיום שורה רגיל או "השורה הריקה" המיוחלת? אין לכך תשובה חד משמעית.

בנוסף יש את החוק המבלבל הבא: שורה שהתחילה ב-white space (טאב או רווח) נחשבת כהמשך לשורה הקודמת, למרות שהיה line break (אחד מהשלושה) קודם לכן.

מעניין לציין ששני שרתי הווב הנפוצים בעולם (Apache ו-IIS) לא מכבדים את התקן ולא מאפשרים לשלוח CR בלבד, בכדי להגן מהבעיות שיכולות להיווצר בגישה הזו. ישנה משפחה של התקפות אבטחה שנקראות header injection שמנסות לגרום לדחיפה של סימני LF, CR ו-CRLF מקומות שונים בתוך ה-headers ולגרום לקוד שמפרסר אותם להתבלבל ולשגות.

מקור: ליאור בר-און

Request Headers

כפי שציינו, הבקשה כוללת רשימה של Headers, כל אחד הוא שורה. ה-Header היחידי שהוא חובה הוא header ה-Host – כל השאר הם אופציונליים. ארגונים רבים משתמשים בשרת Proxy אשר דרכו עוברות כל קריאות ה-HTTP היוצאות מהארגון. שרת ה-Proxy יכול לפלטר אתרים לא רצויים (אתרים מתוך רשימה של אתרים הנגועים בנוזקות, בארגונים מסוימים: אתרים "מבזבזי זמן" כגון פייסבוק), לנטר תעבורה או לשפר ביצועים (ע"י הגשת התשובה מ Cache מוכן).

ההבדל בין קריאה דרך פרוקסי וקריאה רגילה ב HTTP הוא סמנטי וכמעט נחבא מהעין: קריאה דרך Proxy תכלול בשורת הפתיחה URL מלא הכולל את ה Host. עבור הדוגמה למעלה, שורת הפתיחה תראה כך:

POST http://www.lyrics.com/lyrics_server/queen_song.php HTTP/1.1

קצת קטנוני – אפשר לומר.

תהליך חשוב שמתרחש בעת החלפת ה-headers ב-request וה-response הוא תהליך שנקרא "Content Negotiation". בתהליך זה ה-client (כנראה דפדפן, אבל לא בהכרח) מצהיר באילו סוגי תוכן ובאיזה פורמטים הוא תומך. השרת ינסה להיענות לדרישה כמיטב יכולתו. הנה קבוצת headers שכזו לדוגמה:

Accept: text/html, application/xhtml+xml, application/xml; q=0.9, *.*;q=0.8
Accept-Language: he, en-us;q=0.8, en;q=0.6
Accept-Charset: ISO-112, utf-8;q=0.7,*;q=0.3
Accept-Encoding: gzip, deflate

שימו לב ש "Accept-Charset" הוא ה header שמצביע על סוג הקידוד (encoding) בעוד "Accept-Encoding" מתאר דווקא את סוג הדחיסה (compression). סוג של חוסר-דיוק מינוחי שנעשה בתקן. לפני שאנו נגשים ל headers עצמם בואו נבין את התחביר: לכל header יש מספר ערכים מופרדים בפסיקים, לערכים יש ערכי משנה, מופרדים בנקודה-פסיק.

Accept-Language: he, en-us;q=0.8, en;q=0.6

q הוא מדד בין 0 ל-1 שמבטא את חוזק ההעדפה (quantity?) עבור ה-content negotiation. כלומר ב-header זה הדפדפן אומר: "אחי, אני הכי רוצה עברית (q לא צויין = 1) אבל אני מוכן לקבל אנגלית אמריקאית כהעדפה קצת יותר נמוכה או אנגלית-סתם כהעדפה שלישית.

Headers שכדאי לציין הם:

• Accept (נקרא גם Accept-Media) – מציין את רשימת ה-media types (נקראים גם MIME types) שה-client תומך בהם. * משמעה: "תן לי הכל, אני אסתדר כמיטב יכולתי".רשימת ה MIME types נראית קצת מסורבלת, וכנראה שאם תשלחו MIME type שגוי הדפדפן יידע להסתדר (הוא מפענח את התחילה של הקובץ כדי לדעת איזה סוג קובץ זה באמת, בלי קשר ל MIME type שנשלח) – אבל זהו התקן ורוב השרתים מצייתים לחלק זה.
• Accept-Encoding - סוגי דחיסה שונים שהדפדפן יודע לפתוח. קבצים נדחסים על מנת להעביר פחות מידע על גבי הרשת. הדחיסה המועדפת היא gzip (שזה וריאציה קלה-לפענוח של אלגוריתם הדחיסה ZIP). אין טעם לציין כאן q מכיוון שלדפדפן באמת אין העדפה.
• User-Agent - זהו header קצת חריג בנוף של ה-content negotiation: במקום לתאר יכולת של ה-Agent כגון encoding או supported media types, הוא מתאר פרטים מזהים על ה-Agent כמו מנוע הרינדור שה-agent משתמש בו או מערכת ההפעלה שהוא רץ עליה. בעזרת פרטים אלו יכול השרת לנחש ולנסות להתאים את התוכן טוב יותר ל-agent.

אומר זאת בבירור: User Agent הוא סוג של Anti-Pattern בו עושים שימוש נפוץ בכדי להתאים תוכן של אתרים / אפליקציות לדפדפן ספציפי / מערכת הפעלה, על בסיס הידיעה כיצד מתנהג כל דפדפן (באיזו גרסה?). זיהוי דפדפן (למשל IE7) הוא לא משימה קלה מכיוון שבעוד שבמחשב שלכם IE7 ייצר User Agent String (בקיצור UA) אחד, למשל:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.2; Win64; x64; Trident/6.0; .NET4.0E)

במחשב אחר (לא עוד disk image מאותו IT) הוא עלול לייצר UA שנראה כך:

Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)

"אין בעיה!", תאמרו לעצמכם. "MSIE 7" תמיד יופיע ועליו נסתמך. מה שכן, הנה UA שהגיע מדפדפן IE8:

Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.0; Trident/4.0; FBSMTWB; msn OptimizedIE8; ENUS)

גם הוא מכיל משום מה "תאימות ל MSIE 7".

לפני שאתם משחררים קוד המתבסס על UA, כדאי שתבדקו את ה regular expressions שלכם מול בנק של UAs כגון לינק1 או לינק2. הדרך הנכונה לעבוד היא להשתמש בספריות כגון modernizr, שבודקות בזמן ריצה האם יכולות ספציפיות נתמכות בדפדפן כגון SVG או Touch ולא לנסות לנחש זאת דרך ה-UA.

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

גם ג'ון רזיג, היוצר של jQuery, לא "מת" על השימוש ב UA. מקור: twitter, ליאור בר-און

Headers חשובים אחרים ב-HTTP Request הם:

• If-Modified-Since - בעזרת header זה הדפדפן מצהיר: "יש לי את הקובץ הזה (זכרו שקריאת HTTP היא גם לתמונות או מסמכים, לא רק קבצי HTML) מתאריך abc, שלח לי אותו חזרה רק אם הוא השתנה מאז". אם הקובץ לא השתנה, ה response יחזור עם body ריק אבל עם קוד 304 (not-modified) שיאמר לדפדפן להשתמש במשאב שכבר ברשותו, מכיוון שהוא מעודכן.
• Referer - זיהוי האתר שהפנה את הבקשה (בהנחה שבקשת ה HTTP היא תוצאה של לחיצה על לינק). מידע זה הוא שימושי למדי לכלי Web Analytics. בעלי אתרים רוצים לדעת אילו מפרסמים יעילים יותר עבור האתר שלהם. שימו לב ששגיאת הכתיב (באנגלית יש לכתוב Referrer) היא שגיאה שנעשתה במקור בתקן – ונשתמרה.
• Cookie ו Caches - שני נושאים בעלי נפח שראוי להקדיש להם דיון עצמאי.
• (X-forward-for (XFF - פעמים רבות, לפני השרת שלנו יישב Reverse Proxy או Load Balancer המנטרים את התעבורה. מכיוון שכלפי-חוץ (האינטרנט) אותו רכיב רשת הוא היעד הסופי של התעבורה, ה packet של פרוטוקול ה IP יציין את רכיב הרשת בתור היעד ולא את השרת שלנו. רכיב הרשת ישלח שוב את אותה הבקשה אלינו ושם הוא יציין את המקור (ברמת פרוטוקול ה IP) ככתובת שלו, ולא כתובת השולח המקורי. XFF נועד "to patch" מגבלה זו של פרוטוקול IP ולתאר לנו את המקור האמיתי של התעבורה.

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

מקור: ליאור בר-און

הקישו F12 בדפדפן בכדי לפתוח את כלי הפיתוח. בכרום, למשל, לכו לטאב ה-Network ולחצו F5 כדי לטעון שוב את הדף. עכשיו תראו את רשימת כל קריאות ה HTTP, כאשר בכל אחת ניתן לראות את ה Headers שנשלחו. בדפדפנים אחרים הדרך למצוא את ה Headrs אינה שונה בהרבה.

HTTP Response

חפרנו דיי הרבה בבקשת ה HTTP, בואו נעבור על כמה נקודות מעניינות בתשובה. פורמט התשובה הוא דומה למדי:

<http version> <status code> <reason = status text>
<headers>
<empty line>
<body>

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

HTTP/1.1 200 OK
Server: Some-Server/0.9.2
Content-Type: text/plain
Connection: close

<DOCTYPE html><html><head></head><body><p>
This is currently an <b>html</b> document, but http response body can include images, css files, binary files etc.<p>
</body><html>

מקור: Flickr. cc-by Raphael Goetter

שורת הפתיחה

שורת הפתיחה כוללת את גרסת הפרוטוקול, קוד סטטוס (מספרי) וטקסט שמתאר את הסטטוס. אמנם כמעט תמיד נראה את התיאור "OK" עם קוד 200 ("הכל בסדר"), אבל אין מניעה לשלוח טקסט אחר. שדה זה נועד בכדי לשלוח הודעות שגיאה טקסטואליות כאשר עובדים, למשל, עם REST API. הודעת שגיאה כמו ״Bad Request״ היא לא מועילה וכדאי להחליף אותה.

מבין כ-50 הקודים שמוגדרים בפרוטוקול ה HTTP יש אולי 15 שבאמת שימושיים בפועל, בואו נעבור עליהם בקצרה:

• 200 - "הכל בסדר": התוכן שנתבקש אמור להגיע ב-body
• 204 - No Content: כאשר אין ערך החזרה. הדפדפן לא ינווט לכתובת החדשה אלא יישאר בכתובת האחרונה שהיה.
• 206 - Partial Content: כמו 200, רק משמש עבור בקשות של range בתוך המסמך, המבוצעות על בסיס ה header שנקרא Content-Range.
• 301, 302 או 303 - הדפדפן מציין שה URL למשאב זה הוחלף, וה URL החדש מצויים ב header בשם Location. דפדפנים יפנו אוטומטית לכתובת החדשה, מבלי שהמשתמש מודע לכך, מה שנקרא "Client-Side ReDirect". אם הפעולה הייתה פעולת POST, הדפדפן יגש ל URL החדש בפעולת GET (כדי למנוע שליחה כפולה של הנתונים). דפים שמציגים למשתמש הודעה "…You are being redirected" מחזירים בעצם קוד 200, ופעולת ה Redirect היא בעצם אפליקטיבית (בעזרת קוד ג'אווהסקריפט, לרוב).
• 304 - not modified: ראו את ההסבר אודות סטטוס זה תחת ההסבר על ה header בשם If-Modified-Since למעלה.
• 307 - Temporary Redirect: כמו 301-303 רק ללא ביטול פעולת ה POST.
• 400 - bad request: השרת מציין שמשהו לא בסדר בבקשה שנשלחה, אולי הפורמט ואולי תוכן הבקשה. הפירוט אמור להגיע בהודעת השגיאה.
• 401 - Unauthorized: השרת לא מזהה את המשתמש ולכן אינו יכול לאפשר לו לגשת למשאב שהגישה אליו מוגבלת. קוד זה יזניק חלון "שם/ססמה" או יהיה נקודת הפתיחה לסט קריאות מורכב כחלק מהפעלת פרוטוקולים לאימות המשתמש כגון Kerberos או SAML.
• 403 - Forbidden: השרת מזהה את המשתמש, אך למשתמש אין הרשאות לגשת למשאב.
• 404 - לא קיים משאב בשם שתואר ב URL. תשאלו כל ילד בן 12 ומטה, והוא יסביר לכם :)
• 405 - Method not allowed: פעולת ה HTTP שביקשנו (למשל Delete) לא זמינה למשאב הספציפי. ייתכן והיא תהיה זמינה עבור משאב (URL) אחר.
• 500 - Internal Error: תקלה פנימית בשרת, שיכולה להיות בעצם כל דבר. התקלה לרוב תכתב לקובצי הלוג של השרת ולא תשלח (מטעמי בטיחות) למשתמש. אל תצפו להודעת שגיאה מפורטת או מועילה על קודים אלו.
• 503 - Service Unavailable: כמו 500, אך בא להדגיש שמדובר בתקלה זמנית בגלל שאיזה service בדיוק נמצא ב maintainable או restart, למשל.

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

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

Headers מעניינים בתשובה

הנה כמה מה Headers המעניינים שיכולים לחזור בתשובה:

• Content-Encoding, Content-Language, Content-Type ועוד - המקבילים ל-Headers של ה-Content Negotiation בבקשה, אולם הפעם מצוינת ההחלטה. לא יהיו יותר q לבטא את מידת הרצון כי אם החלטה: "התוכן הוא HTML בצרפתית והוא דחוס ב-gzip", לדוגמה.
  ה-Content Type יתואר בעזרת אחד מה MIME types, כמו שהזכרנו קודם.
• Server - ממש כמו user agent – רק בצד השרת. מתאר איזה שרת זה ואיזו גרסה.
• מעולם לא ראיתי קוד שעשה שימוש במידע זה, אך למי שמדבג פלטפורמה מרוחקת מידע זה עשוי להיות שימושי.
• Content-Length - אורך ה body. יכול לסייע ל client להיערך בהקצאת זיכרון.
• Cache-Control, Pragma, ETag - אלו headers המתארים את היכולת לשמור את התוכן ב cache בצד הלקוח, ופרטים אודות התקפות שלו. נושא בפני עצמו.

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

סיכום

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

הפוסט פורסם לראשונה בבלוג Software Archiblog.

מקור: flickr, cc-by Robert Banh

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

הדמיון ל-MVC הוא במטרה – שמירה של סדר בעבודה עם כמות גדולה של קוד. דרך הפעולה – שונה לגמרי. אפשר (וכדאי) להשתמש גם ב-MVC וגם ב-AMD במקביל על מנת "לעשות סדר" בקוד הג'אווהסקריפט שלנו.

הקדמה

בשנת 2009, בחור בשם קוין דנגור (Kevin Dangoor) יזם פרויקט בשם ServerJS. מטרת הפרויקט: להתאים את שפת ג'אווהסקריפט לפיתוח צד-השרת.

הפרויקט, כלל קבוצות עבודה שהגדירו APIs לצורת עבודה שתהיה נוחה ואפקטיבית בפיתוח ג'אווהסקריפט בשרת. פרויקט ServerJS הצליח לעורר הדים והשפיע בצורה משמעותית על עולם הג'אווהסקריפט. פרויקטים מפורסמים שהושפעו ממנו כוללים את CouchDB, Node.js ו-MongoDB.

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

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

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

אנשי הדפדפנים, התאימו את Modules/1.1 לעולם הדפדפן (ישנם כמה הבדלי התנהגות חשובים) וקראו לו: Async Module Definition, או בקיצור: AMD  [א]. רק להסביר: AMD היא הגדרה המתארת API לטעינה דינמית של מודולים – אך אין מאחורי AMD קוד. ל-AMD יש מימושים רבים בדמות ספריות כמו: lsjs, curl, require, dojo ועוד.

המימוש הבולט ביותר ל AMD היא ספרייה בשם require.js. כיום require.js היא הספרייה הנפוצה ביותר, בפער גדול, על שאר האלטרנטיבות. המצב מזכיר במעט את המצב של jQuery מול MooTools או Prototype – תקן "דה-פאקטו".

היתרונות של AMD (בעצם: require.js)

מלבד היכולת להפציץ חברים לעבודה במושגים (כמו CommonJS, AMD או Modules/1.1), תבנית-העיצוב AMD מספקת יתרונות משמעותיים לאפליקציות גדולות. מרגע זה ואילך אתייחס ספציפית ל-require.js, או בקיצור: "require".

#1: ניהול "אוטומטי" של תלויות בין קובצי javaScript

האם קרה לכם שהיה לכם באג בקוד שנבע מסדר לא-נכון של תגיות ה <script> ב head של קובץ ה HTML? קרוב לוודאי שבמערכת גדולה יהיו מספר רב של קובצי javaScript ולכן – מספר רב של תלויות. אין דרך ברורה להגדיר קשרים בין קבצי javaScript (כולם נרשמים במרחב זיכרון משותף), כל שקשרים אלו הם לא-מפורשים ואינם קלים לתיעוד או למעקב.

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

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

הערה קטנה: require לא נבנתה לנהל קשרים בהם יש cycles, אולם יש "טכניקה" בה ניתן לטעון קבצים עם תלות מעגלית - אם כי בצורה מעט מסורבלת.

#2: טעינה עצלה ומקבילית של קבצי javaScript [ביצועים]

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

• Require לא תטען קובץ עד לרגע שצריך אותו בפועל (lazy loading).
• Require טוענת קבצים בעזרת תכונת ה async של תגית ה <script> – משהו שכמעט בלתי-אפשרי לנהל באופן ידני בפרוייקט גדול.

טעינה דינמית של קבצים מפגישה 2 כוחות מנוגדים: מפתחים - שמעוניינים בהרבה קבצים קלים בהם קל לנהל את הקוד. אנשי production / operations - שרוצים שיהיו מינימום roundtrips לשרת.

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

#3: ניהול תלויות בין קובצי ה javaScript השונים

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

הניסיונות שלי לנהל פרוייקטים בעזרת namespaces במרחב הגלובלי (בצורת {} || var myns = myns) נגמרו לבסוף בעשרות תלויות בלתי-רצויות בקוד ש"הזדחלו" מבלי שהרגשנו. ברגע שרצינו להשתמש במודולריות של הקוד, כפי שתכננו – לא יכולנו לעשות זאת ללא refactoring משמעותי.

מה שווה MVC, אם ה"מודל" מפעיל פונקציות שלא היה אמור מתוך ה "View"? מה שווה חלוקה ל Layers, אם היא לא נאכפת בפועל? Require תסייע לכם לוודא שהקוד אכן מיישם את ה-design שתכננתם.

מקור: ליאור בר-און

מבוא קצר ל-Require.js

חטא נפוץ הוא להציג את require.js כספריה קטנטנה ונטולת-מורכבות. מדוע חטא? מכיוון שהרשת מלאה במדריכי "hello world" ל-require, המציגים רק את היכולות הבסיסיות ביותר. אחרי כמה שעות עם עבודה ב-require קרוב לוודאי שתזדקקו ליותר – אך ידע זה קשה להשגה. התיעוד הרשמי של require הוא טכני ולא הדרגתי – ממש כמו לקרוא מסמך Specification. מתאים בעיקר למי שכבר מתמצא. התוצאה: עקומת למידה לא קלה לשימוש ב require – וללא סיבה מוצדקת.

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

מבוא נאיבי ל-Require.js

Require היא ספריה פשוטה וחמודה. היא מציגה בסה"כ 3 פקודות:

• define - הגדרה של מודול (יחידת קוד של ג'אווהסקריפט בעלת אחידות גבוהה ותחום-אחריות ברור).
• require - בקשה לטעינה של מודול בו אנו רוצים להשתמש.
• require.config - הגדרות גלובליות על התנהגות הספרייה.

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

מקור: ליאור בר-און

ModuleID הוא מזהה טקסטואלי שם המודול. ה-Id בעזרתו אוכל לבקש אותו מאוחר יותר. את הקוד של המודול כותבים בתוך פונקציה, כך שלא "תלכלך" את המרחב הגלובלי (global space). קונבנציה מקובלת ומומלצת היא לחשוף את החלק הפומבי (public) של המודול בעזרת החזרת object literal עם מצביעים (ורוד) לפונקציות שאותם ארצה לחשוף (טורקיז). כמובן שאני יכול להגדיר משתנים / פונקציות נוספים שלא ייחשפו ויהיו פרטיים.

מבנה זה נקרא "Revealing Module" והוא פרקטיקה ידועה ומומלצת בשפת javaScript. ספריית require מסייעת להשתמש במבנה זה.

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

מקור: ליאור בר-און

הפונקציה בדוגמה היא callback שתפעל רק לאחר שהקוד של מודולים 1 ו-2 נטען ואותחל. m1 הוא reference ל-מודול1 (אותו object literal שהוחזר ב -return וחושף את החלקים הציבוריים) ו -m1 הוא reference למודול2. השיוך נעשה ע"פ סדר הפרמטרים. doStuff היא כבר סתם פונקציה שעושה משהו עם m1 ו-m2.

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

מקור: ליאור בר-און

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

מקור: ליאור בר-און

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

• כאשר אנו רוצים לטעון מודולים רק בהסתעפות מסוימת בקוד (ולכן איננו יודעים בוודאות על צורך זה בשורה הראשונה).
• עבור הקובץ הראשון בתוכנה שלנו. כלומר: פונקציית ה-"main".

הדרך המקובלת ביותר לטעון את require ב-HTML היא באופן הבא:

מקור: ליאור בר-און

שימו לב שגם בפרויקט גדול, אין צורך להגדיר ב-HTML יותר מסקריפט אחד: require. הוא כבר יטען את כל השאר. data-main הוא שם קובץ ה-javascript של פונקציית ה-"main" שלנו שמאתחלת את התכנית. יש להקליד את שם הקובץ ללא סיומת .js. זוכרים שיש פקודה שלישית? config? – היא לא כ"כ חשובה. היא משמשת להגדרות גלובליות מתקדמות לגבי ההתנהגות של require. למשל קטע הקוד הבא:

מקור: ליאור בר-און

קוד זה מגדיר שאם קובץ לא נטען (ברשת) תוך 10 שניות, require יוותר ויזרוק exception. מצב זה סביר בעיקר כאשר אתם טוענים קובץ מאתר מרוחק. ה-default הוא time-out של 7 שניות.

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

סיכום

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

—-

הפוסט פורסם לראשונה בבלוג Software Archiblog.

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

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

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

הכירו את הזוכות

מקור: דף האפליקציה

Once App on a Time היה היה בתל-אביב

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

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

מקור: דף האפליקציה

המלחמה הבאה

צוות: אסף בנדור ויובל טיסונה.

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

מקור: דף האפליקציה

Moovit

צוות: רועי ביק, ירון עברון, ניר ארז

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

מקור: דף האפליקציה

BuzzJourney

צוות: ליאור חרסט

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

מקור: דף האפליקציה

מיחזרתי

צוות: ענבל גפן

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

מקור: דף האפליקציה

מחשבון מכס

צוות: טל קרלינר, לב ליבר, רותם גיטלין, בן אור דנציגר

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

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

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

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

אם כן, מה אפשר לעשות?

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

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

הנה שלושה כלים (חינמיים) שיאפשרו לכם לעבור את השלב הטריקי הזה:

1. Pop – Prototyping on Paper for iOS: פופ הוא לבטח הדרך הקלה והמהירה ביותר ליצור את האב-טיפוס לאפליקציה שלכם, להראות לאנשים ולקבל פידבק ראשוני של על הרעיון וחווית המשתמש. למעשה, אין כל צורך בעיצוב גרפי או יכולות עיצוב. אם אתם יודעים לעשות סקיצות פשוטות על נייר – אתם מוכנים.

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

לינק להורדת האפליקציה

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

לינק לאתר

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

לינק לאתר

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

תיצרו משהו להראות במהירות וצאו החוצה לעולם.

ללמוד, לעדכן, ללמוד, לעדכן – זה שם המשחק.