זהו פוסט המשך לפוסט "טרנדים חמים בתחום ה Web וה Mobile - חלק 2".
CSS Meta-Languages
אתם בוודאי מכירים את "שפת" CSS - שפת העיצוב ה StyleSheets של האינטרנט. מצד אחד, CSS היא שפה רבת יכולות גרפיות, אך מצד שני קשה לקרוא לה "שפה". CSS היא שפה דקלרטיבית (כלומר: המתכנת מציין את התוצאה הרצויה - לא את הדרך להגיע אליה), והיכולות ה"תכנותיות" (אימפרטיביות) שלה - אינן עומדות בקו אחד עם שפות תכנות בסיסיות... משנות השישים של המאה הקודמת.
לדוגמה: ב CSS3, הוצגה לראשונה פונקציה חישובית שמאפשרת לבצע חישובים אריתמטיים. במקום שהמתכנת יפתח מחשבון, יקיש ערכים, יחשב ויקליד את התוצאה בתוך קובץ ה CSS - יהיה ניתן להקליד את החישוב בתוך פונקציית Calc ו"שפת" ה CSS תחשב אותו. אני לא מדבר על הכפלת מטריצות לוגרתימיות, אני מדבר על פעולה פשוטה כמו 8px+2px+4px.
בעת כתיבת פוסט זה, רק שני דפדפנים נפוצים (מתוך 7, אם נחשיב מכשירי מובייל) תומכים ביכולת החישוב של CSS3. עבור כל שאר הדפדפנים יש לבצע חישוב בראש ולהקליד את התוצאה לתוך ה CSS.
"מה כל-כך רע בלבצע חישוב קטן בראש?" - אתם עשויים לשאול. "תפעיל קצת את התאים האפורים שלך!".
ובכן - אני מדמיין את קובץ ה CSS, חלק אינטגרלי מאתר או אפליקציה, שמכיל את הערך:
האם זה 600 פחות X, Y ו Z כפול 2?
האם 551 פיקסלים, שני אלמנטים למעלה, צריכים גם הם להשתנות אם יום אחד אחליט להרחיב את "531 הפיקסלים"? מה עוד צריך להשתנות ולמה?
דחף ראשוני של מתכנת טוב הוא להוסיף הערה:
בהמשך, אוכל פשוט לקרוא ל:
לדוגמה: ב 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%);
}
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 לא באמת נדרשים והסרתם - יכולה לשפר משמעותית את קריאות הקוד.
לדוגמה, במקום לכתוב:
אפשר לכתוב בקופיסקריפט:
ניתן לזהות בתחביר של CoffeScript אלמנטים רבים משפת רובי וגם מפייטון (כלומר, גישת פייטון שהועדפה על גבי רובי).
ובכן, מה החסרונות של קופיסקריפט?
יש ללמוד שפה חדשה, לעבור עוד שלב של קומפילציה ולהסתפק בסט כלים חיצוניים קטן יותר (למרות שיש כבר לא מעט IDEs בעלי תמיכה כזו או אחרת לקופיסקריפט).
עוד ביקורת אפשרית הוא שאולי, אבל אולי, קופיסקריפט לא הולכת רחוק מספיק: קופיסקריפט משפרת את התחביר, מונעת טעויות ג'אווהסקריפט נפוצות (למשל הגדרה של משתנה ללא "var" - כך שהוא הופך להיות גלובלי או שימוש ב"==" ולא ב "===") אך היא עדיין לא מאפשרת קפיצת מדרגה ביכולת ה static checking של השפה. כמתכנת צד-שרת עדיין חסרה לי היכולת להגדיר משתנה שיספק לי Type Safety או בכלל לתפוס עוד טעויות בעזרת הקומפיילר.
שפה אחרת, עם מאפיינים דומים לקופיסקריפט, שכן עושה צעד נוסף בכיוון זה היא Dart של גוגל. יעד מרכזי של השפה הוא לאפשר לקוד להתחיל לרוץ גם לפני שכל הקוד נטען - וכך לספק פידבק מוקדם למשתמש. זמן טעינה ארוך ללא תגובה היא בעיה ידועה של אפליקציות גדולות בג'אווהסקריפט.
דפדפן כרום [ג] יודע להריץ את Dart ללא קומפילציה ל JavaScript וכך להשיג ביצועים אפילו גבוהים יותר. כרגע לא נראה שדפדפנים אחרים ימשיכו בקו זה.
בניגוד לשאר הטכנולוגיות שהצגתי בסדרת פוסטים זו, דארט עדיין לא הוכיחה את עצמה. האמת שהיא אפילו חדשה למדי וגרסה רשמית שלה שוחררה רק לפני חודש.
מפתח ווב ותיק ציין בפני השגה מעניינת: "לגוגל יש היסטוריה של טכנולוגיות מרשימות, שלבסוף לא תופסות", הוא אמר. לא אנסה לנתח את הסיבה - אך זו בהחלט נקודה שאני מזדהה איתה וששווה התייחסות לפני שאתם קופצים וממירים את כל הקוד שלכם ל DART.
השפה הנפוצה בתחום היא ללא ספק 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);
__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
בד"כ חיסכון הקוד לא יהיה כ"כ גדול, אך בכל-זאת החלטתי להביא דוגמה זו כדי להראות את הפוטנציאל.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" שיספק לי גם בדיקה בזמן קומפילציה.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.
Generators
תהיתם פעם איך מפתחי ווב מנוסים מייצרים חלקים מורכבים ב CSS שלהם?
למשל, אתם רוצים לייצר גרדיאנט מושקע שכזה:
בתוכנות גרפיות יש פקדים קלים על מנת לייצר אותו. איך אתם מעבירים אותו לCSS?
כמה שניות בראש יקחו לכם לתרגם אותו לקוד, הברור מאליו, הבא:
[א] לא לבלבל עם SaaS - Software as a Service.
[ב] ההדמיה היא מוצלחת - אך בהחלט ניתן לראות שאלו הם "תרגילים" וכי תחביר השפה לא מספק כלים מיוחדים לסייע לתאר מקרים נפוצים אלו.
[ג] בעצם V8.
למשל, אתם רוצים לייצר גרדיאנט מושקע שכזה:
בתוכנות גרפיות יש פקדים קלים על מנת לייצר אותו. איך אתם מעבירים אותו ל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 שיכולים לחסוך לכם הרבה עבודה.
חפשו בגוגל "Generators" ותראו שהאינטרנט מלא בכלים קטנים שמסייעים למפתחי ווב.
אם אינכם משתייכים ל"גאונים המתמטיים" שמחשבים ערכים כאלו בראש, אבל כן משתייכים ל"עצלנים" שמחפשים דרכי קיצור - יש הרבה כאלו באינטרנט. אמנם אין הרבה 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. שלא תאמרו שלא ידעתם.
Aptana הוא מורכב ומסורבל ופשוט לא מסודר נוח. מעולם לא חיבבתי אותו. העדפתי אפילו להשתמש ב++Notepad שהיה מוגבל אך זריז. עד שגיליתי את מה שמפתחי הווב המתוחכמים מכירים: IDE מבית IntelliJ בשם WebStorm.
כמובן שיש פה עניין של טעם אישי, אך אם אתם מפתחים ווב בחצי משרה או יותר, ומוכנים להשקיע bare 100$ בשביל איכות החיים שלכם - כדאי לכם להוריד גרסת ניסיון של Web Storm. אני לא אפרט את רשימת הפ'יצרים (תמיכה ב SASS, LESS, CoffeeScript, Node.js השלמה אוטומטית חכמה, Refactoring ו Debugger חזק - אופס, פירטתי). הדבר שאני הכי אוהב ב IDE הזה שהוא מרגיש לי טבעי ו"זורם איתי" בוייב הנכון. לא מקשה עלי, כמו Aptana. שלא תאמרו שלא ידעתם.
[א] לא לבלבל עם SaaS - Software as a Service.
[ב] ההדמיה היא מוצלחת - אך בהחלט ניתן לראות שאלו הם "תרגילים" וכי תחביר השפה לא מספק כלים מיוחדים לסייע לתאר מקרים נפוצים אלו.
[ג] בעצם V8.
1. איזו שפה היא CSS?
השבמחק- "קשה לקרוא לה 'שפה'."
- "היכולות ה"תכנותיות" (אימפרטיביות) שלה."
למה קשה לקרוא ל-CSS "שפה"? HTML אינה שפה? XML אינה שפה? עברית ואנגלית אינן שפות?
"שפה" אינה בהכרח "שפת תכנות". CSS היא שפה לכל דבר, כך גם XML, HTML ודמויהן, שהינן "שפות סימון".
אגב, למרות שזו לא טעות לקרוא ל-JS "שפת תכנות", אם נדייק, זו "שפת תסריט" (כך לדוגמה גם PHP).
בל אופן, הטעות הגדולה ביותר היא לנסות לערב את נושא ה-CSS לתכנות. CSS הינו חלק נפרד שכלל אינו קשור לתכנות (גם אם יהיו בה "משתנים" ו"פונקציות"). היא אינה מתיימרת להיות כזאת, אינה מתחילה לדמות לשפת תכנות וכשם שלא תשווה בין צלחת למחשב, כך עצם הנסיון לקשר בין שפת העיצוב CSS לתכנות, הינו מוטעה וחסר כל קשר :)
2. בענין הפוקנציה calc:
לדעתי, זו גישה שגויה לחשוב שהפונקציה calc נועדה לחסוך הערה.
אני מניח שפונקציות כאלו יהיו שימושיות בעיקר עבור נתונים משתנים, להבדיל מערכים קבועים מראש.
יתירה מכך, הפונקציה (לפחות בצורתה הנוכחית) אינה חוסכת את ההערה, גם בצורת כתיבה כזאת ההערה נדרשת, על מנת להבין מהו האלמנט שמידתו X פיקסלים, ומדוע בחרנו בדרך זאת.
תודה ישראל על התגובה.
מחק1. מבחינה אקדמית ברור לי שאתה צודק. עדיין CSS היא מוגבלת ממה שהייתי מצפה.העקרונות ה"תכנותיים" לכאורה שהייתי מצפה מ CSS הוא לפחות DRY - Don't Repeat Yourself, או קריאות טובה.
ברור שיעד מרכזי של CSS הוא להתאים למעצבים גרפיים ולא למפתחים - אני מסכים לגמרי. העובדה בשטח היא שיש קהילה גדולה של מעצבים גרפיים שמשתמשים ב Sass ו Compass ומסתדרים איתם היטב ונמנעים כך מ DRY ומשפרים את קריאות הקוד.
2. לגבי Calc:
לא ציינתי בפוסט המקורי כדי לא לסבך, אך Calc נועד גם לחישובים פשוטים וגם לקומבינציות מורכבות שלא ניתן לבטא בצורה אחרת. לדוגמא 50%-10px.
היכולת לכתוב (500px-10px-2*(2px היא פחות טובה משימוש בקבועים, אך היא עדיין קפיצת מדרגה בקריאות מול ערך יחיד ולא מוסבר.
אפרופו CoffeeScript ו Dart, הנה עוד גישה מעניינת לוידוא נכונות של קוד JavaScript:
השבמחקאם תוסיפו הערות (= annotations) בפורמט מסוים לקוד שלכם, http://typedjs.com/ יבדוק את נכונות הקוד בהקשר של Type Safety. לא ניסיתי ואני לא יודע כמה הספריה הזו טובה, אך הגישה בהחלט מעניינת.
רציתי קודם כל לומר שהבלוג מאוד מעניין ויסודי ונוגע בנושאים מאוד חשובים.
השבמחקרציתי לשאול כיצד אתה ניגש לעשות מחקרים כמו מחקר מהסוג שעשית בכתבות על טרנדים במובייל?
יש ים של מידע שצריך "לצוד" ממנו את העיקר, הרבה frameworks, קצת קשה לפעמים לדעת מה מהם באמת פופלרי וסטנדרטי ומה לא, ולפעמים הולכים קצת לאיבוד בדרך. תודה
היי,
מחקתודה רבה על הפידבק!
לעשות מחקר מאפס זה באמת מאוד קשה - אבל זה לא מה שאני עושה.
אני עוקב אחרי מה שקורה בתעשיית התוכנה - אני פשוט מאוד נהנה מזה.
אני עוקב, באופן קבע, אחרי כ 20 בלוגים - רשימה שנוצרה אצלי לאורך הדרך ומתעדכנת כל הזמן, אני שומע כמה פודקאסטים (בניהם Reversim ו javascriptjabber.com), עוקב אחרי כמה כנסים (QCON, Goto;, Berlin Buzzwords, OSCon) - מעלעל ברשימת הנושאים שהוצגו שם וקורא כמה מצגות / צופה בהרצאות הוידאו שהוקלטו. לאחרונה גם עוקב אחרי כמה אנשים בטוויטר וגם אחרי אתר לינקים בשם ביטורמה. אם אני פוגש מישהו שמתעניין גם כן, אני שמח לשמוע וללמוד. בקיצור: זה פשוט תחביב.
כשאני מגיע לכתוב פוסט כבר יש לי תמונה מגובשת יחסית של הנושא ולעיתים רשימה של לינקים ששמרתי לי במהלך הדרך עבור הבלוג. תמיד יש לי כמה עשרות כאלה, בנושאים שונים. תזכורים ל Backbone.js, Ember וחברים שמעתי במספיק הזדמנויות כדי להבין שהם "שם". ה"מחקר" בבלוג הוא בעיקר אימות של דברים ש"נדמה לי" (ופעמים רבות אני לומד שה"נדמה לי" הוא טעות) וסגירת פינות של חוסר ידע.
לרוב אני משתדל לכתוב על נושאים שיצא לי להתעסק בהם בפועל, אני מצטער על כמה פעמים שלא עשיתי כך.
זהו, מקווה שהצלחתי לענות.
ליאור
תודה רבה על התשובה המפורטת! בזכותך הוספתי כמה אתרים לרשימת הקריאה :)
מחקרציתי גם לשאול איך אתה תופס את התפקיד של סיסטם ארכיטקט - מה בעיניך הגדרת התפקיד כוללת (למשל - להביא טכנולוגיות חדשות לארגון? לדאוג למודעות לטסטינג ראוי, ללמד מתכנתים לעבוד יותר נכון ויעיל? לדאוג לתפור אינטגרציות בין מוצרים? לכתוב קוד בתור ארכיטקט? וכ"ד) , ואיזה הבדלים ראית (או מכיר מאנשים אחרים) של הגדרת תפקיד זה בחברות השונות.
מחקתודה!
היי nacrafts,
מחקזו שאלה קשה. תפקיד הארכיטקט הוא לא תפקיד מוגדר היטב כמו, נאמר, מתכנת או ראש-צוות. הוא שונה מאוד מארגון לארגון ואדם לאדם.
הייתי רוצה שתפקיד הארכיטקט יהיה בנוסח התיאור של הבלוג - וזה בערך מה שאני עושה כיום, אבל זה לא תמיד כך.
בישראל, אני יכול לספר אחרי שראיתי כ 10 מקומות בתחילת השנה, יש הרבה מאוד (50% או יותר) תפקידים של "ארכיקט כותב spec". זה סוג של waterfall בצורה הרעה והמנוונת שלו בו הארכיטקט נסגר בחדר, עושה design במקום המפתחים ומתאר מערכת שלמה ומורכבת לפרטי פרטים לפני שהפרוייקט החל. אין שום יכולת להגיב לתובנות או התפתחויות חדשות, יש טלפון שבור עם המפתחים, וסביר שצוותי הפיתוח יצמדו להגדרות ללא ביקורת עצמית - יש מעט מאוד הפעלה שלהם כיחידים. זה אף פעם לא עובד - זו דרך מצויינת ליצור שחיקה גבוהה וארכיטקטורה לא-טובה, אבל בכל זאת זה מודל שקל לארגון להבין איך הוא "אמור לעבוד" ולכן, אני מאמין, האינרציה האבסורדית שממשיכים לעשות את זה.
בקיצור, תפקיד ארכיטקט בעל משמעות או "שעובד" הוא לא דבר מובן מאליו. אחרי שנכוותי בחברה האחרונה שעבדתי בה - הבנתי עד כמה הדברים יכולים לא-לעבוד.
יש הרבה משמעות לדינמיקה של הארגון ולא רק ל"הגדרות התפקיד" (אם הן בכלל קיימות).
בתור אחד שזה מה שהוא עושה - אפשר לדבר על זה עוד הרבה...
אני יכולה לומר שאני רואה תופעה אחרת והפוכה ממה שאתה מתאר - הארכיטקטים לא מקדמים טכנולוגיות חדשות (לא מחדירים אותן לארגון), לרוב המפתחים עושים בעצמם את הDESIGN המפורט, ולפעמים גם את ה HIGH LEVEL - מלבד אולי נקודות ואינטגרציה שעליהם דנים עם הארכיטקטים. ולמעשה המפתחים לרוב לא כל כך צריכים אותם.
מחקאבל זה מעודד לדעת שבכל זאת יש מקומות בהם הארכיטקט הוא קודם כל טכנולוג, מעורב במה שקורה בפיתוח ועושה דברים שהם דומים במהות לבלוג שלך :)
המצב שאת מתארת הוא כנראה נפוץ למדי, והוא הדרך בה הדברים נראים מהצד השני.
מחקטוב לקבל רענון על איך הדברים נראים מהעבר השני.
יש סיכוי טוב שהארכיטקטים שאת מדברת עליהם הם סוג של ה"ארכיטקטי spec" שאני הזכרתי, שעושים תכנונים על תכנונים - ללא קשר למציאות בצוותי הפיתוח. הם אולי יותר קשורים לאיזו אסטרטגיה אמורפית של איזה מנהל בכיר. מאוד קשה להיות גורם מסייע למפתחים - ללא הבנה של הפרטים, וגם מאוד קשה לסייע באמת למנהל הבכיר ללא הבנת הפרטים. אבל קל ללכת פה לאיבוד ולהתעסק באיזה "חלומות גבוהים".
במידה והארכיטקטים אכן מתמודדים עם בעיות אמיתיות (זה לא תמיד כך) אזי ייתכן שהם מאוכזבים מהמפתחים שלא מבינים את הבעיות האלו ועוזרים לפתור אותן, והמפתחים מאוכזבים מארכיטקטים שלא מבינים על מה הם מדברים ועסוקים בשלהם. חוסר תקשורת.
אני מניח שזו סיטואציה דיי נפוצה, וחבל.
היי, השאלה שלי קצת סוטה מנושא הכתבה
השבמחקיש לך מדריך או שאתה מכיר איזה מדריך שמדריך על פיתוח אפליקציות למובייל בHTML5?
היי אלעד,
מחקאני מניח שאתה יודע JS/HTML/CSS ובעיקר מנסה ללמוד מובייל.
האינטרנט מלא בחומרים, אבל אין לי משהו ספציפי שאני יכול להמליץ עליו.
אתה יכול להתחיל עם ספר ל jQuery Mobile - זו ספריה בסיסית למדי שיכולה לתת נקודת פתיחה טובה לנושא.
בדרך שווה גם לראות מה עשו ב Mobile Boilerplate (לינק http://html5boilerplate.com/mobile) שזה קצת hardcore, אבל כולל מידע רב ומאוד ממוקד לגבי מובייל.
משם אני מניח שגוגל יספיק להשלמות (אינסופיות, כמובן).
ליאור
היי,
השבמחקהייתי רוצה להמליץ על עוד כלי מעולה ליצירת טבלאות מעוצבות על ידי CSS בלבד.
http://www.csstablegenerator.com
נחמד מאוד!
מחקתודה
עדכון ל-2016
השבמחקכדאי לציין את typescript שנראה שנצחה את הקרב