לדוגמה: ב CSS3, הוצגה לראשונה פונקציה חישובית שמאפשרת לבצע חישובים אריתמטיים. במקום שהמתכנת יפתח מחשבון, יקיש ערכים, יחשב ויקליד את התוצאה בתוך קובץ ה CSS – יהיה ניתן להקליד את החישוב בתוך פונקציית Calc ו\”שפת\” ה CSS תחשב אותו. אני לא מדבר על הכפלת מטריצות לוגרתימיות, אני מדבר על פעולה פשוטה כמו 8px+2px+4px.
בעת כתיבת פוסט זה, רק שני דפדפנים נפוצים (מתוך 7, אם נחשיב מכשירי מובייל) תומכים ביכולת החישוב של CSS3. עבור כל שאר הדפדפנים יש לבצע חישוב בראש ולהקליד את התוצאה לתוך ה CSS.
\”מה כל-כך רע בלבצע חישוב קטן בראש?\” – אתם עשויים לשאול. \”תפעיל קצת את התאים האפורים שלך!\”.
ובכן – אני מדמיין את קובץ ה CSS, חלק אינטגרלי מאתר או אפליקציה, שמכיל את הערך:
…531 פיקסלים. איך לעזאזל הגעתי ל 531 פיקסלים?!
האם זה 600 פחות X, Y ו Z כפול 2?
האם 551 פיקסלים, שני אלמנטים למעלה, צריכים גם הם להשתנות אם יום אחד אחליט להרחיב את \”531 הפיקסלים\”? מה עוד צריך להשתנות ולמה?
דחף ראשוני של מתכנת טוב הוא להוסיף הערה:
יותר ברור – נכון, אבל האם אתם מדמיינים קובץ CSS עם מאות שורות בהערות, שניתן לתחזוקה?
 |
| תמונה מייצגת של דוד בוב, כשהוא במצב-רוח טוב. מקור: 33degree.org |
 |
| הלוגו של Sass: קיצור של Syntactically Awesome Stylesheets. הספרייה יועדה למעצבים – ולכן השיווק שמתאים יותר לפלח שוק זה. מקור: http://sass-lang.com/ |
- קבועים (נקראים בטעות \”משתנים\”) אשר מאפשרים לקבוע ערך פעם אחת ולהשתמש בו הרבה פעמים. שינוי עתידי ידרוש שינוי במקום אחד בלבד: הגדרת הקבוע.
- Mixins (מקבילות דקלרטיביות לפונקציות) – היכולת להגדיר פעם אחת מספר שורות שחוזרת על עצמן ולהשתמש בהן שוב ושוב. שימוש נפוץ הוא \”לעטוף\” בפקודה אחת את הצורות השונות בהן קוראים לפקודה בדפדפנים שונים, כך שהקוד יציג רק את הפעולה הרצויה מבלי לשכפל את התחביר של הדפדפנים השונים. rounded-corners או gradient הן דוגמאות טובות.
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%);
}
בהמשך, אוכל פשוט לקרוא ל:
השפה הנפוצה בתחום היא ללא ספק CoffeeScript, תחת הסלוגן \”Expose the good parts of JavaScript\”.
בניגוד ל Sass ו LESS שבאות להתמודד עם חוסר-יכולת-ביטוי של שפת ה CSS, שפת JavaScript עשירה למדי ומלאה ב\”שטיקים\” המאפשרים גמישות רבה למתכנת. שפות המטא של JavaScript באו דווקא לעשות את ההפיך: להגביל את JavaScript ולהגן על המתכנת בפני שורה של Pitfalls אפשריים.
בנוסף – הן מציגות תחביר משופר, יותר תמציתי ואלגנטי. אלמנטים רבים שחוזרים על עצמם ב JavaScript לא באמת נדרשים והסרתם – יכולה לשפר משמעותית את קריאות הקוד.
לדוגמה, במקום לכתוב:
__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);
אפשר לכתוב בקופיסקריפט:
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 וכך להשיג ביצועים אפילו גבוהים יותר. כרגע לא נראה שדפדפנים אחרים ימשיכו בקו זה.
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.
למשל, אתם רוצים לייצר גרדיאנט מושקע שכזה:
בתוכנות גרפיות יש פקדים קלים על מנת לייצר אותו. איך אתם מעבירים אותו לCSS?
כמה שניות בראש יקחו לכם לתרגם אותו לקוד, הברור מאליו, הבא:
אם אינכם משתייכים ל\”גאונים המתמטיים\” שמחשבים ערכים כאלו בראש, אבל כן משתייכים ל\”עצלנים\” שמחפשים דרכי קיצור – יש הרבה כאלו באינטרנט. אמנם אין הרבה IDEs חזקים לפיתוח ווב אך יש הרבה מאוד כלים (Generators) שייצרו לכם snippets של CSS או JavaScript שיכולים לחסוך לכם הרבה עבודה.
- colorzilla gradient-editor הוא הכלי שייצר את קוד הגרדיאנט למעלה וישמח לייצר קוד שמתאים לכל הדפדפנים.
- CSS Layout Generator יסייע לייצר Layouting בעזרת CSS בלבד – פעולה שעשויה להיות מלאכת מחשבת
- השם עשוי להפתיע אתכם, אך CSS Button Generator ייצר כפתורים עגולים ויפים בעזרת CSS בלבד.
- kuler יספק לכם sets של 5 צבעים שמתאימים אחד לשני. לא עוד אתר בעיצוב
גיאורגי(החליפו את המחוק בכל שם שנותן לכם קונוטציה לעיצוב גרוע). - Pattern Cooler ייצר לכם תמונות רקע ש\”מתחברות אחת לשנייה\” ויוצרות טאפט.
חפשו בגוגל \”Generators\” ותראו שהאינטרנט מלא בכלים קטנים שמסייעים למפתחי ווב.
Aptana הוא מורכב ומסורבל ופשוט לא מסודר נוח. מעולם לא חיבבתי אותו. העדפתי אפילו להשתמש ב++Notepad שהיה מוגבל אך זריז. עד שגיליתי את מה שמפתחי הווב המתוחכמים מכירים: IDE מבית IntelliJ בשם WebStorm.
כמובן שיש פה עניין של טעם אישי, אך אם אתם מפתחים ווב בחצי משרה או יותר, ומוכנים להשקיע bare 100$ בשביל איכות החיים שלכם – כדאי לכם להוריד גרסת ניסיון של Web Storm. אני לא אפרט את רשימת הפ\’יצרים (תמיכה ב SASS, LESS, CoffeeScript, Node.js השלמה אוטומטית חכמה, Refactoring ו Debugger חזק – אופס, פירטתי). הדבר שאני הכי אוהב ב IDE הזה שהוא מרגיש לי טבעי ו\”זורם איתי\” בוייב הנכון. לא מקשה עלי, כמו Aptana. שלא תאמרו שלא ידעתם.
[ב] ההדמיה היא מוצלחת – אך בהחלט ניתן לראות שאלו הם \”תרגילים\” וכי תחביר השפה לא מספק כלים מיוחדים לסייע לתאר מקרים נפוצים אלו.
[ג] בעצם 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 שנראה שנצחה את הקרב