יום שני, 30 באפריל 2012

טרנדים חמים בתחום ה Web וה Mobile - חלק 3 ואחרון



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

לדוגמה: ב CSS3, הוצגה לראשונה פונקציה חישובית שמאפשרת לבצע חישובים אריתמטיים. במקום שהמתכנת יפתח מחשבון, יקיש ערכים, יחשב ויקליד את התוצאה בתוך קובץ ה CSS - יהיה ניתן להקליד את החישוב בתוך פונקציית Calc ו"שפת" ה CSS תחשב אותו. אני לא מדבר על הכפלת מטריצות לוגרתימיות, אני מדבר על פעולה פשוטה כמו 8px+2px+4px.

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

"מה כל-כך רע בלבצע חישוב קטן בראש?" - אתם עשויים לשאול. "תפעיל קצת את התאים האפורים שלך!".

ובכן - אני מדמיין את קובץ ה CSS, חלק אינטגרלי מאתר או אפליקציה, שמכיל את הערך:
;width: 531px
...531 פיקסלים. איך לעזאזל הגעתי ל 531 פיקסלים?!
האם זה 600 פחות X, Y ו Z כפול 2?
האם 551 פיקסלים, שני אלמנטים למעלה, צריכים גם הם להשתנות אם יום אחד אחליט להרחיב את "531 הפיקסלים"? מה עוד צריך להשתנות ולמה?

דחף ראשוני של מתכנת טוב הוא להוסיף הערה:
width: 531px; // box is 560px wide - 2*padding (10px) - icon width (9px)
זה באמת יותר ברור.
יותר ברור - נכון, אבל האם אתם מדמיינים קובץ CSS עם מאות שורות בהערות, שניתן לתחזוקה?

אני שומע בראשי את Uncle Bob זועק בסרטוני הווידאו שלו "!!Comment is a Failure" - "אם  כתבת הערה, סימן שנכשלת, לכתוב קוד ברור מספיק על מנת שיחיה בפני עצמו" (הרמת הקול היא במקור).

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

תמונה מייצגת של דוד בוב, כשהוא במצב-רוח טוב. מקור: 33degree.org
היו כמה ניסיונות להתמודד עם הבעיה בעזרת jQuery (או ספריות דומות): במקום לשכפל קוד לא קריא בקובץ CSS - העבירו חלק נכבד מ"קוד" העיצוב ל jQuery (שיכולות ה Selection שלו מקבילות כמעט ל CSS). קוד jQuery נטען בעליה והחיל סגנונות עיצוב על גבי ה HTML. באופן זה ניתן להשתמש ב JavaScript שמספק יכולות מתקדמות למדי לשימוש חוזר בקוד.

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

בשנת 2007 שוחררה ספרייה חדשנית שהתהדרה בססמאות אלגנטיות. קראו לה Sass [א].
Sass היא שפה חדשה שמאפשרת לכתוב StyleSheet אלגנטיים שקלים לתחזוקה. מכיוון ששום דפדפן באותו הזמן לא תמך בקובצי Sass (מצב זה לא השתנה מאז) - הפרויקט כלל גם קומפיילר שהופך את קבצי ה Sass לקובצי CSS מוכרים.
הלוגו של Sass: קיצור של Syntactically Awesome Stylesheets. הספרייה יועדה למעצבים - ולכן השיווק שמתאים יותר לפלח שוק זה. מקור: http://sass-lang.com/

מי שיתבונן בקובצי ה Sass יזהה אלמנטים מוכרים משפת רובי, ואכן משם ההשראה. מתכנתי Ruby on Rails הם אלו שהמציאו את Sass. באתר הבית של Sass תוכלו למצוא דוגמאות למכביר כיצד Sass הופכת את כתיבת ה StyleSheets למלאכה פשוטה ומהנה יותר. הנה כמה דוגמאות:
  • קבועים (נקראים בטעות "משתנים") אשר מאפשרים לקבוע ערך פעם אחת ולהשתמש בו הרבה פעמים. שינוי עתידי ידרוש שינוי במקום אחד בלבד: הגדרת הקבוע.
  • Mixins (מקבילות דקלרטיביות לפונקציות) - היכולת להגדיר פעם אחת מספר שורות שחוזרת על עצמן ולהשתמש בהן שוב ושוב. שימוש נפוץ הוא "לעטוף" בפקודה אחת את הצורות השונות בהן קוראים לפקודה בדפדפנים שונים, כך שהקוד יציג רק את הפעולה הרצויה מבלי לשכפל את התחביר של הדפדפנים השונים. rounded-corners או gradient הן דוגמאות טובות. 
הנה דוגמה איך נראה Mixin בפועל:
.gradient(@color, @start, @stop) {
  background: @color;
  background: -webkit-gradient(linear,left bottom, left top,color-stop(0, @start), color-stop(1, @stop));
  background: -ms-linear-gradient(bottom, @start, @stop);
  background: -moz-linear-gradient(center bottom, @start 0%, @stop 100%);
}


בהמשך, אוכל פשוט לקרוא ל:
.gradient(#F5F5F5, #EEE, #FFF);
על מנת להחיל גרדיאנט שתומך ב 3 דפדפנים (כל אחד עם תחביר מעט שונה) או רקע קבוע אם גרדיאנט לא נתמך.


Sass מציגה עוד יכולות חשובות, כגון nesting (היכולת לסדר את הקובץ ע"פ מבנה ה markup ולצמצם התנגשויות אפשריות ב CSS), חלוקת הקוד לקבצים מבלי לגרוע בביצועים, פונקציות חישוביות, לוגיות או ניהול צבעים. פונקצית ()opacify, למשל, מאפשרת לכם להוסיף שקיפות לצבע מבלי לפרק אותו לערוצי ה RGB, כפי שנדרש בפונציה הסטדנדרטית של CSS - הרי היא rgba.

על גבי Sass קיימת ספריה עשירה של mixin בשם Compass שמציעה סט יכולות מגוון ובוגר. את הכל יכולתם לכתוב בעצמכם - אך ה mixins של Compass כבר עברו שיפורים רבים.

שפת Meta-CSS נוספת, דומה להפליא ל Sass, נקראת LESS - לא אתפלא לגלות שהיא Fork של Sass בימים מוקדמים יותר. הצעד הגדול ביותר שלה היה להחליף את הקומפיילר של Ruby בו משתמשת Sass בקומפיילר שנכתב ב JavaScript. ישנן עוד כמה שוניות פחות משמעותיות.

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


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

השפה הנפוצה בתחום היא ללא ספק CoffeeScript, תחת הסלוגן "Expose the good parts of JavaScript".
בניגוד ל Sass ו LESS שבאות להתמודד עם חוסר-יכולת-ביטוי של שפת ה CSS, שפת JavaScript עשירה למדי ומלאה ב"שטיקים" המאפשרים גמישות רבה למתכנת. שפות המטא של JavaScript באו דווקא לעשות את ההפיך: להגביל את JavaScript ולהגן על המתכנת בפני שורה של Pitfalls אפשריים.

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

לדוגמה, במקום לכתוב:
var Animal, Horse, Snake, sam, tom,
  __hasProp = {}.hasOwnProperty,
  __extends = function(child, parent) {
    for (var key in parent) {
      if (__hasProp.call(parent, key)) child[key] = parent[key];
    } function ctor() { this.constructor = child;
  } ctor.prototype = parent.prototype; child.prototype = new ctor; child.__super__ = parent.prototype; return child; };

Animal = (function() {

  Animal.name = 'Animal';

  function Animal(name) {
    this.name = name;
  }

  Animal.prototype.move = function(meters) {
    return alert(this.name + (" moved " + meters + "m."));
  };

  return Animal;

})();


Horse = (function(_super) {

  __extends(Horse, _super);

  Horse.name = 'Horse';

  function Horse() {
    return Horse.__super__.constructor.apply(this, arguments);
  }

  Horse.prototype.move = function() {
    alert("Galloping...");
    return Horse.__super__.move.call(this, 45);
  };

  return Horse;

})(Animal);

אפשר לכתוב בקופיסקריפט:
class Animal
  constructor: (@name) ->

  move: (meters) ->
    alert @name + " moved #{meters}m."


class Horse extends Animal
  move: ->
    alert "Galloping..."
    super 45

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

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

עוד ביקורת אפשרית הוא שאולי, אבל אולי, קופיסקריפט לא הולכת רחוק מספיק: קופיסקריפט משפרת את התחביר, מונעת טעויות ג'אווהסקריפט נפוצות (למשל הגדרה של משתנה ללא "var" - כך שהוא הופך להיות גלובלי או שימוש ב"==" ולא ב "===") אך היא עדיין לא מאפשרת קפיצת מדרגה ביכולת ה static checking של השפה. כמתכנת צד-שרת עדיין חסרה לי היכולת להגדיר משתנה שיספק לי Type Safety או בכלל לתפוס עוד טעויות בעזרת הקומפיילר.

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

class Point {
  num x, y;
  Point(num this.x, num this.y);
  Point scale(num factor) => new Point(x*factor, y*factor);
  num distance() => Math.sqrt(x*x + y*y);
}

void main() {
  Point a = new Point(2,3).scale(10);
  print(a.distance());
}
הנה דוגמה לשפת DART: תחביר קרוב יותר ל C-Syntax שנהוג בג'אווהסקריפט אך עדיין עם קיצורים רבים. "num" הוא תחליף ל "var" שיספק לי גם בדיקה בזמן קומפילציה.

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

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

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

בתוכנות גרפיות יש פקדים קלים על מנת לייצר אותו. איך אתם מעבירים אותו לCSS?
כמה שניות בראש יקחו לכם לתרגם אותו לקוד, הברור מאליו, הבא:
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,rgba(180,221,180,1)), color-stop(17%,rgba(131,199,131,1)), color-stop(33%,rgba(82,177,82,1)), color-stop(67%,rgba(0,138,0,1)), color-stop(83%,rgba(0,87,0,1)), color-stop(100%,rgba(0,36,0,1))); 
כמובן שזה רק דפדפן ואחד ויש בערך 6 צורות מעט שונות להגדיר את אותו הגרדיאנט לדפדפנים שונים.

אם אינכם משתייכים ל"גאונים המתמטיים" שמחשבים ערכים כאלו בראש, אבל כן משתייכים ל"עצלנים" שמחפשים דרכי קיצור - יש הרבה כאלו באינטרנט. אמנם אין הרבה IDEs חזקים לפיתוח ווב אך יש הרבה מאוד כלים (Generators) שייצרו לכם snippets של CSS או JavaScript שיכולים לחסוך לכם הרבה עבודה.
  • colorzilla gradient-editor הוא הכלי שייצר את קוד הגרדיאנט למעלה וישמח לייצר קוד שמתאים לכל הדפדפנים.
  • CSS Layout Generator יסייע לייצר Layouting בעזרת CSS בלבד - פעולה שעשויה להיות מלאכת מחשבת
  • השם עשוי להפתיע אתכם, אך CSS Button Generator ייצר כפתורים עגולים ויפים בעזרת CSS בלבד.
  • kuler יספק לכם sets של 5 צבעים שמתאימים אחד לשני. לא עוד אתר בעיצוב גיאורגי (החליפו את המחוק בכל שם שנותן לכם קונוטציה לעיצוב גרוע).
  • Pattern Cooler ייצר לכם תמונות רקע ש"מתחברות אחת לשנייה" ויוצרות טאפט.

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


ולסיום - IDE  מתקדם לפיתוח ווב
כלי פיתוח לווב, משום מה, תמיד היו מאותגרים. לרוב הם לא סיפקו הרבה יותר מ Syntax Highlighting ו Auto-Completion בסיסי מבוסס השפה. IDE מתוחכם יחסית ששינה את התמונה הוא Aptana והוא מסופק בחינם. עד לא מזמן, הוא כנראה היה ה IDE המתקדם ביותר לפיתוח Web.

Aptana הוא מורכב ומסורבל ופשוט לא מסודר נוח. מעולם לא חיבבתי אותו. העדפתי אפילו להשתמש ב++Notepad שהיה מוגבל אך זריז. עד שגיליתי את מה שמפתחי הווב המתוחכמים מכירים: IDE מבית IntelliJ בשם WebStorm.

כמובן שיש פה עניין של טעם אישי, אך אם אתם מפתחים ווב בחצי משרה או יותר, ומוכנים להשקיע bare 100$ בשביל איכות החיים שלכם - כדאי לכם להוריד גרסת ניסיון של Web Storm. אני לא אפרט את רשימת הפ'יצרים (תמיכה ב SASS, LESS, CoffeeScript, Node.js השלמה אוטומטית חכמה, Refactoring ו Debugger חזק - אופס, פירטתי). הדבר שאני הכי אוהב ב IDE הזה שהוא מרגיש לי טבעי ו"זורם איתי"  בוייב הנכון. לא מקשה עלי, כמו Aptana. שלא תאמרו שלא ידעתם.



[א] לא לבלבל עם SaaS - Software as a Service.

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

[ג] בעצם V8.


יום ראשון, 22 באפריל 2012

טרנדים חמים בתחום ה Web וה Mobile - חלק 2

בהמשך לפוסט הקודם בסדרה, טרנדים חמים בתחום ה Web וה Mobile - חלק 1, הנה עוד טרנדים חמים בתחום הווב והמובייל:

Unit Testing ל JavaScript
אין פה משהו חדש לגמרי: מי שבאמת רצה, יכול היה לכתוב unit tests לקוד ה JavaScript עוד מזמן. עד לא מזמן Unit Tests היו נפוצים בעיקר בצד השרת ומעט מאוד בצד הלקוח. מה שהשתנה הוא הפיתוח הרב שנעשה למובייל, שעבורו פתרונות כמו GWT, פלאש או IceFaces - כבר אינם טובים מספיק.

העיקרון דומה למדי ל Unit Tests בצד השרת, מלבד העובדה שהשונות בין סביבות הריצה היא רעש לא קטן. בעוד שלג'אווה יש JVMים רבים, יכולתי בתור מפתח לבדוק את הקוד שלי על JVM של Windows (רץ ב IDE וב CI) ולהניח שהוא ירוץ בצורה זהה על שאר הפלטרפורמות הנפוצות. את רוב ה JVMים הקיימים מייצרת סאן אורקל והם דומים למדי. במצב נדיר בו הקוד שלכם אמור לרוץ, נאמר, על Z/OS (מערכת הפעלה של יבמ למיינפריים) אזי עליכם להתמודד עם JVM של יצרן אחר (יבמ) וייתכנו שונויות. אני נתקלתי פעם אחת בחיי בקוד שמתנהג אחרת (סביב SoftReferences) בין JVM של סאן ל JVM של יבמ.


אם ניקח את Rhino (מנוע ה JavaScript שמגיע עם ג'אווה) ונוסיף את Env.js, ספרייה טוב של ג'ון ריזלינג (היוצר של jQuery) שמדמה את ה DOM של הדפדפן, נוכל לבצע Unit Testing שיבדקו בצורה דיי טובה את הריצה של הקוד שלנו ע"פ התקנים הרלוונטים, ובצורה בינונית למדי את הריצה של הקוד על דפדפנים אמיתיים, בגרסאותיהם השונות.

ישנם 4 מנועי ג'אווה סקריפט שמשולבים בדפדפנים נפוצים: V8 של גוגל, Spider Monkey של מוזילה, Chakra של מייקרוסופט ו SquirrelFish שרץ בספארי.
כל אלה שונים במידה מורגשת מ Rhino, ושונים גם אחד מהשני. Charka, הוא מנוע חדש שנכתב עבור IE9 והוא שונה מהמנוע של גרסאות קודמות (JScript Engine) שעדיין זמין על IE9 ב Compatibility Mode [א].

מה הפתרון?
ניתן להריץ כלי אוטומציה כמו Selenium על דפדפנים שונים כחלק מתהליך ה CI. רוצים להתקין מספר דפדפנים (בעיקר IE) על מחשב אחד? Spoon.Net הוא שירות מצויין שיעשה עבורכם את העבודה עבור תשלום של 60$ בשנה.
כלי אוטומציה פשוט ומגניב יותר שעושה את אותו הדבר הוא JSTestDriver. הוא "משתלט" על ה process של הדפדפן ולכן אמור להיות מהיר ואמין יותר מ Selenium שמתבסס על ה UI.
עבור מובייל, יש כאלו שבודקים רק על WebkitJSCore שכנראה מספיק דומה לV8 ברוב המקרים, וניתן להריץ אותו ללא הרצה של דפדפן. כלומר, הרבה יותר מהר. חפשו בגוגל "Webkit headless" כדי למצוא מגוון של פתרונות.

הנה עוד כמה ספריות שיעשו את פיתוח ה Unit Tests שלכם לקלים ומהנים יותר:
Jasmine - סביבת unit testing ו BDD, כנראה הנפוצה מכולן.
QUnit היא אלטרנטיבה מבית היוצר של ג'ון ריזלינג. יש כאלו שאומרים שהיא קצת יותר טובה, אך הקהילה שלה קטנה יותר והשוני בקוד של הבדיקות הוא דיי זניח, לדעתי.
Mocha (מבטאים כמו "מוקה") היא ספריית בדיקות נחשבת, עם הרבה פלאג-אינים ותמיכה ב Node (פרטים בהמשך).

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

בדיקות תוכנה: "אני לא סומך על עצמי, אבל אני סומך על פראנק". מקור: youtube

Hybrid Web Container או בקיצור: PhoneGap
דילמה קשה ובסיסית של פיתוח למובייל הוא הבחירה בין פיתוח אפליקציית נייטיב (native) לבין אפליקצת ווב (כלומר HTML5 ו CSS).
לאפליקציית נייטיב יש יתרון ביצועים משמעותי, היא יכולה לגשת למצלמה ולרשימת אנשי הקשר ובעזרתה ניתן לייצר חווית משתמש "יותר חלקה".
אפליקציית ווב מאפשרת לכתוב קוד פעם אחת ולהשתמש בו, עם התאמות קלות, במכשירים שונים. גם ההתאמה למסך בגודל שונה (טאבלט, Note) היא קלה יותר. אין API שיישבר בין גרסאות של מערכות הפעלה.

ישנה אופציה שלישית דיי פופולרית - ה Hybrid Web Container.
איך לצרוך PhoneGap - ה HWC הנפוץ. מקור: האתר של phoneGap

הרעיון הוא דיי פשוט: כתבו אפליקציית HTML רגילה. ה Hybrid Web Container, או בקיצור HWC, יספק לכם אפליקציית נייטיב שכל מה שהיא עושה היא לפתוח מעין iFrame ענק על על המסך שמפנה לכתובת האפליקציה שלכם.
מה היתרון בכזה תרגיל?
  • אתם יכולים להפיץ את האפליקציה שלכם בעזרת ה AppStore או Google Play - היכן שמשתמשים בד"כ מחפשים אחר אפליקציות.
  • ה HWC יחשוף יכולות native של המכשיר שלא זמינים ב HTML5 כ JavaScript API: מצלמה, אנשי קשר, גישה לקבצים מקומיים, notification (לדוגמה הפעלת רטט של המכשיר, או push messages) וכו'. הערה: כותבי HTML5 עובדים כדי לאפשר להשתמש בשירותים אלו מאפליקציות ווב - אך הפער בין המצוי לרצוי הוא עוד גדול.
  • ה HWC יאפשר לכם לכתוב custom native code (נניח שדורש חישוב מאוד יעיל) ולחשוף אותו ב JavaScript עבור החלק ה HTML-י של האפליקציה שלכם.
האם HWC הוא הטוב משני העולמות? הפתרון המושלם שייתר את שתי הגישות האחרות (נייטיב וווב)? החומר השיווקי של מפתחי ה HWC יטען שכן, אך נראה שזו תשובה לא מדויקת.

HWC מביא איתו גם חסרונות מ-2 העולמות הקיימים, למשל:
  • חווית המשתמש לא תהיה חלקה ונקיה כמו באפליקציית נייטיב (עדיין יש דפדפן).
  • התאימות לכל המכשירים לא תהיה טובה כמו אפליקציית HTML.
  • אם תעשו שינוי בnative קוד תצטרכו לשחרר גרסה חדשה דרך ה AppStore, דבר שלוקח זמן אצל אפל אפילו אם מדובר ב"תיקון אבטחה קריטי". צד ה HTML - מצד שני, יצטרך לדעת להתמודד עם הגרסאות השונות של ה Container מכיוון שאין לכם שום דרך להכריח את המשתמשים לשדרג את ה Container.
בקיצור, HWC היא אופציה שלישית ואטרקטיבית - אך אינה בהכרח אופציה נעלה. היא פשוט עוד אופציה אפשרית שכדאי לשקול.


MVC Frameworks for JavaScript
מכירים Frameworks מבוססי תבנית העיצוב MVC - Model View Controller? אני מדבר על Struts, JSF או ASP.NET MVC? אני מניח שכן.

ובכן - תשכחו מכל מה שידעתם. אנחנו נדבר על MVC ל JavaScript.

לא, לא בגלל שMVC התגלה לפתע כלא-מוצלח. להיפך. בגלל שמה שנקרא כיום "MVC Framework for JavaScript" - הוא פשוט לא MVC במובן שאתם מכירים. העקרונות דומים, אך הצורך העיקרי איננו עוד בשליטה בניווט בין דפים. לדקדקנים: מדובר יותר ב MVP או MVVC - תבניות עיצוב שמתארות בצורה מדוייקת יותר את מה ש Frameworks אלו מספקים. בקיצור ניתן לומר שמדובר ב *MV, שיש בהם אלמנטים דומים ל MVC.

MVC קלאסי מבוסס על 2 עקרונות מרכזיים:
  • הראשי: הפרדה בין UI ל Business Logic, או מה שנקרא View ל Model. זו הפרדה חשובה מאז ומעולם. הקשר בין ה View ל Model יהיה לרוב ע"י Value Objects בלבד, מה שנקרא בג'אווה Beans.
  • המשני: העברת פעולות ה navigation בין הדפים למקום מרכזי (ה controller). במקום שכל דף יכיר את הדפים אליהם אפשר לנווט ממנו - הוא מכיר רק פעולות, וגורם שלישי מרכז את הפענוח וההפניה ליעד האמיתי. לעתים קרובות בעזרת קומפיגורציה שאפשר לשנות ללא כתיבת קוד או תלוית הקשר, משתמש למשל.
ה Framework הנפוץ ביותר ה Backbone.js. זהו "*MV של JavaScript" ללא Controller שמבצע ניווט בין דפי ווב. גם ההפרדה בין UI ל Business Logic היא given - אך היא לא העיקר. היכולת העיקרית שלו היא לסייע בכתיבת אפליקציות "דף אחד" עם אלמנטים דינמיים מתחלפים.

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

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

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

Backbone.js, למרות השם ה"כבד", הוא ספרייה רזה בת כ 700 שורות קוד (אם לא סופרים הערות). אפשר ללמוד אותו על בוריו בשעה-שעתיים והוא מתאים למכשירי מובייל. אם דיברנו בפוסט הקודם על Micro JS Frameworks- הרי גרסת ה minified שלו היא 16K בלבד. 

ישנם Frameworks רבים, אך ללא ספק הנפוץ שבהם הוא Backbone.js. בעולם ה .NET נפוץ יותר Knockout.js שמקדם את תבנית MVVP, שלמיטב ידיעתי, מוכרת בעיקר מפירסומים של מייקוסופט. 

עוד 2 ספריות נפוצות הן Spine.js ו Ember.js.


Node.js
חשבתם פעם בכמה שפות וטכנולוגיות מפתחי Web צריכים להתמחות? מצד אחד HTML CSS ו JavaScript, מצד שני לרוב האפליקציות זקוקים לשרת ואז צריך לכתוב ב Java, Ruby או #C. פעמים רבות, מפתחי הווב חזקים יותר בצד הלקוח ו"קצת מחפפים" בצד השרת. "לו רק ניתן היה לפתח רק ב JavaScript...".
מפתחי צד השרת (כמוני) נוטים לתעב ג'אווהסקריפט ומחפשים כל מיני דרכים להימנע ממנו (פלאש, GWT ועוד).

האם אפשר להריץ Groovy (וריאנט של ג'אווה שאני אוהב) בדפדפן? - בחלומות הלילה.
האם אפשר להריץ JavaScript בצד השרת? כן. קיימים מנועי ג'אווהסקריפט שרצים בצד השרת כמו Rhino או V8. הרשו לי להציג את קפיצת המדרגה בצד זה: Node.js.

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

אבל בכל זאת - זה קצת גימיק, לא? JavaScript עם Interpreter הוא קצת איטי. ובכלל להשוות שרת מורכב כמו Apache Geronimo לאיזו ספריית JavaScript? זה נשמע קצת לא רציני.
אז מתי אני ארצה להשתמש בפיתוח ג'אווהסקריפט לצד השרת? עבור בדיקות? עבור Prototyping?

האמת המפתיעה הוא ש Node.js הוא מהיר. מאוד מהיר.
בואו נתחיל בלהסביר ממה Node.js מורכב:
Node.js הוא (הגדרה שלי) שרת ווב שכתוב בג'אווהסקריפט. הוא רץ על V8 - מנוע הג'אווהסקריפט המהיר של גוגל (שבעצם מקפמל JIT את הג'אווהסקריפט לקוד מכונה). בנוסף יש ספריות שונות המשלימות יכולות צד שרת שחסרות  בג'אווהסקריפט (גישה לקבצים, תקשורת וכו') וספריית ניהול חבילות בשם npm (המקבילה ל Ruby Gems או Python Eggs). הכתיבה ב Node היא דיי low level, ויש להרכיב לבד את הודעות ה HTTP, אך אין מניעה להשתמש בספריות שיאפשרו רמת אבסטרקציה גבוהה יותר.

Node מול אפאצ'י - השרת המהיר של הווב. מקור: http://blog.raducojocaru.com

בעוד שרתי ווב מלפני עשור (כמו תקן ה Servlets של ג'אווה) תוכננו בראיה של הגשת דפי HTML גדולים, Node נכתב בראייה של מענה להודעות קטנות (קריאות Ajax או WebSockets), כאשר שרת HTTP מצומד מגיש את קבצי ה JavaScript או CSS ובניית ה markup נעשית בצד הלקוח. התוצאה היא טיפול בעיקר בפעולות IO (בסיס נתונים, קבצים, רשת) קצרות. כל פעולות ה I/O ב Node הן אסינכרוניות ומבוססות callbacks ברגע שפעולת ה IO הסתיימה.

למטרה זו Node מהיר בצורה ניכרת מרוב השרתים שאנחנו מכירים היום (IIS, Tomcat וכו') כאשר הוא צורך קצת יותר זיכרון ו CPU (יש Overhead לכל המקביליות הזו) אך הוא יכול לטפל במספר רב יותר של קריאות. בדיקות מסוימות מראות טיפול בפי 10 בקשות במקביל משרת Apache + PHP. המספרים המדויקים כמובן תלויים בתסריט המדויק - אך יש הרבה פוטנציאל. במצבים של גישות ארוכות שחסומות ב CPU - צפו לתוצאות משמעותית פחות מרשימות. כמו כן שימו לב שכדאי להימנע מקוד סינכרוני ולהתאים את גודל ה Connection Pool על מנת להגיע לתוצאות הרצויות על גבי Node.

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

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


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


[א] המצב ב JavaScript הוא עוד טוב. אם אתם מתעסקים בDOM ותומכים ב IE, בקרוב תצטרכו לבדוק את הקוד שלכם על 72 גרסאות שונות.
על Android תצטרכו להתמודד עם Chrome (החל מ Android 4 ועדיין לא דפדפן ברירת המחדל) או Android Browser - דפדפן מעפאן לגמרי שזמין בכל הגרסאות המוקדמות יותר של אנדרואיד. בנוסף יש לא מעט דיווחים שחומרה שונה של אנדרואיד גורמת לדפדפן ה Android Browser להתנהג קצת אחרת - דבר שלא אימתתי בעצמי.

יום שבת, 21 באפריל 2012

טרנדים חמים בתחום ה Web וה Mobile - חלק 1

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

HTML5 + CSS3
לא ניתן לדבר על עולם הווב והמובייל בשנה האחרונה מבלי לדבר על HTML5. זה יהיה כמו לדבר על מבנים גבוהים בת"א... מבלי להזכיר את מגדלי עזריאלי. זהו המובן מאליו.

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

אלמנט פחות מביש, ואפילו דיי שימושי, היא היכולת לייצר תג ("Badge") שמציין את האלמנטים של HTML5 שהאתר שלכם משתמש בהם - ולפרסם זאת. ללא התג - יהיה קשה למדי לדעת במה השתמשתם, אבל ככל שהוא מופיע בעוד ועוד אתרים אנו מקבלים את התחושה ש HTML5 "כבר כאן" והגיע הזמן לשקול ולהשתמש בו.
יש בו גם אלמנט של Gamification: כל פעם שהוספתם יכולת-בסיס של HTML5 אתם מקבלים עוד "אייקון". מי יודע - אולי יתפתח בכם צורך בלתי-נשלט "להשלים את כל הסריה". עצם העובדה שאחד הסמלים ב Badge מסמל CSS3, שאינו חלק ממטריית התקנים [1] של HTML5 - היא עובדה זניחה. לא ניתן לפרט שולי שכזה להפריע בקמפיין מוצלח.


מעבר לקידום המכירות, שמשמעותו לדעתי יחסית זניחה, הסיבה העיקרית להצלחת HTML5 היא עקשנותו של סטיב ג'ובס לא לתמוך ב Flash על המכשירים של אפל. אתרים שרצו ליהנות מקהל היעד החדש נאלצו לחפש אלטרנטיבה לפלאש (או Silverlight או Java Applets - מכשירי אפל לא תומכים באף אחד מהם) - ו HTML5 היה האלטרנטיבה הנראית היחידה. מאותו הרגע HTML5 התקדם בקצב מסחרר, הן בצד האתרים שמשתמשים בו והן בצד התמיכה מצד הדפדפנים. גוגל (+Chrome for Android 4) ומייקרוסט (Windows 8 Metro Experience) שהחליטו גם הן להפסיק לתמוך ב Flash - סגרו סופית את הגולל ופתחו את דרך המלך ל HTML5.

ציון תאימות ל HTML5 עבור דפדפנים שולחניים. מקור: html5test.com

ציון תאימות ל HTML5 עבוד דפדפנים לסמארטפונים. מקור: html5test.com
קוריוז קטן הוא זהות הדפדפן עם התמיכה הטובה ביותר ב HTML5 נכון ליום זה (הנתונים משתנים מרגע לרגע). מנחשים??
לא Chrome של גוגל, לא ספארי ובטח לא Internet Explorer שמתשרך הרבה מאחור. דווקא Maxthon, הדפדפן הסיני מבוסס IE (במקור) זוכה לציונים הטובים ביותר. בעלות משותפת עם גוגל היא אולי הסבר שירגיע כמה מהקוראים מהפחד "הסינים באים" [2].


בואו נעבור לכמה טרנדים חמים ואולי פחות מוכרים מ HTML5:

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

איך עושים את זה? התבוננו למשל באתר הבא: http://mobilism.nl/2012 ממחשב שולחני / לפטופ. עכשיו לחצו על הכפתור, בפינה העליונה של החלון, שגורם לחלון של הדפדפן לא להיות maximized והתחילו להצר את רוחב החלון של הדפדפן עוד ועוד. שימו לב אילו שינויים חלים באתר ומתי. הנה עוד דוגמא.

המימוש המקובל לעקרון זה הוא שימוש ב CSS media Queries - מנגנון שמאפשר לכם לכתוב אתר ב HTML פעם אחת והתאים קובצי CSS שונים לטווחי רזולוציה (או Orientation) שונים. מכיוון ש CSS3 הוא דיי חזק - אתם יכולים לשנות את העיצוב בצורה דיי דרמטית: Layout, תמונות, רקעים ועוד.

CSS Media Queries, אגב, סובל כיום ממגבלה והוא יוריד את כל התמונות של כל המצבים על מכשיר iPhone למשל. ניתן להימנע מבעיה זו ע"י התערבות ב JavaScript או בצד השרת על מנת לטעון רק את הקבצים שבשימוש.

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

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


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


  1. הגדירו baseline של החומרה / סט היכולות הכי מצומצם בו תרצו לתמוך. 
  2. בנו אפליקציה עם פונקציונליות ושימושיות טובה מספיק בכדי להיות בעלת ערך, על בסיס ה baseline שלכם. לרוב הפיתוח יעשה על הרזולוציה הקטנה ביותר שאתם מתכוונים לתמוך בה.
  3. העשירו את האפליקציה שלכם ביכולות נוספות (לרוב אלה יהיו שיפורי - נוחות, לא פונקציות קריטיות לעבודה) על בסיס חומרה זמינה: יותר מסך = יותר פרטים או קיצורי דרך זמינים. קיומו של GPS יכול להיתרגם למידע מותאם למקום או defaults חכמים יותר. יותר זיכרון או כוח עיבוד יכול להיות autocomplete שיחסוך הקלדה למשתמש וכו'.

עקרון משנה, שגם הוא נפוץ, נקרא "Mobile First": כאשר אתם מתכננים אפליקציה אל תתחילו בעיצוב ל desktop כי אם ל mobile ובתור עקרון. יש בכך 2 יתרונות:

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

ספרייה שהיא בגדר "חובה" לפיתוח בשיטת ההעשרה המדורגת היא Modernizr - סיפרית JavaScript שמזהה יכולות של המכשיר ו/או הדפדפן בו אתם רצים: תומך ב colors input של HTML5 או לא תומך. תומך ב SVG או לא. יש GPS או לא.

הניסיון לעשות חישוב "זהו אייפון 4 ולאייפון 4 יש GPS" הוא אולי סביר בעולם ה iOS - אך חסר כל סיכוי בעולם ה Android בו יש כל-כך הרבה מכשירים.


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

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

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

אבל... בעוד jQuery מספקת קובץ בגודל 78K בגרסת ה minified (גודל ה GZip הוא פחות רלוונטי) - Zepto עושה הכל ב 6K בלבד - פחות מעשירית!

השוואת הגודל של ספריות נפוצות ל DOM Selection, במצב קוד מקור, מצומצם ומצומצם + דחוס. מקור: webappers.com

מה שעושה את ההבדל הוא הזיכרון המצומצם של מכשירי המובייל. מכשיר אייפון למשל, לא ישמור ב cache קבצים (javaScript, CSS או תמונות) שגדולות מ 25K בזיכרון. "בזיכרון" = לאחר הפריסה של קובץ ה Gzip.
ההבדל בין Zepto.js לבין jQuery היא היכולת להיות ב cache של דפדפן במכשיר מובייל. האלטרנטיבה היא להביא את הקובץ, כל פעם, ברשת 3G יקרה ואיטית.

Zepto.js היא רק דוגמא אחת לטרנד הולך וגובר בו מוחלפות ספריות "שלמות ועשירות" (כגון jQuery Mobile, QT Touch או מקרה הקצה - Sencha Touch), בספריות קטנות ויעודיות שעושות "רק דבר אחד", עושות אותו באופן ממוקד וטוב, ועושות אותו למובייל. "סופסופ לא צריך לתמוך ב Internet Explorer", נאנחו לרווחה מפתחים רבים והחלו לכתוב ספריות פשוטות יותר למובייל. עם הצגת שיתוף הפעולה בין מייקרוסופט לנוקיה ייתכן שדברים יישתנו.

MicroJs, הוא לדוגמא, אתר שכולו מוקדש לאיסוף ספריות שכאלו - ויש כבר עשרות רבות.

עמוד הבית של microjs.com

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

עדכון: יום לאחר שפירסמתי את הפוסט נשאר לי קובץ התמונה, Zepto.png שמוצג למעלה, על שלוחן העבודה. במקרה הבחנתי שמדובר בקובץ בגודל 76K. בעזרת דחיסה פשוטה ל Jpeg באיכות גבוהה הקובץ הפך ל 18K. אני יודע שחלק לא קטן מקוראי הבלוג משתמשים במכשירי מובייל ולכן מעתה, אני אשתמש בתמונות בפורמט JPEG ולא ב PNG.



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

בהצלחה!



-----------------

[1] HTML5 אינו תקן אחד אלא רשימה של כמה וכמה תקנים המתארים יכולות חדשות לדפדפנים שאינן תלויות זו-בזו. לדוגמא "HTML5 סמנטי" שמאפשר מבנה תגים שמתאר את התוכן בצורה יותר טובה או "Web Workers" - היכולת להשתמש ביותר מ thread אחד כדי לבצע חישובים ברקע. HTML5 היא פשוט השם הקל לתאר את אסופת כל היכולות השונות.
נ.ב. דרך קלה לדעת איזו יכולת נתמכת איפה היא להשתמש באתר המצוין http://caniuse.com/

[2] להזכיר: זה שאתה לא מפחד, לא אומר שלא רודפים אחריך.


יום ראשון, 15 באפריל 2012

קצת פרומושיין לבלוגים אחרים בעברית

הרעיון לכתוב בלוג בא לי בחטף.

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

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


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

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

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

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

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

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

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


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

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


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


[2] זומבי = השם ביוניקס לתהליך שמת אך לא נוקה. אין פה קשר למדע בדיוני.