אנחנו מתכנתים אחרת

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

אותו הירוק

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

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

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

הכל עניין של הסתכלות

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

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

array[0][0]; // 1
array[0][1]; //2
array[0][2n-1]; //2n
array[2n-1][2n-1]; //4n^2 

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

for ( int i = 0; i < array.length; i++ )
for ( int n = 0; n < array[i].length; n++ )
 if ( array[i][n] == myNumber )
   return Array (i,n);

הפתרון דרש מאיתנו במקרה הקיצוני לעבור על כל אותם 4n^2 נתונים.

מקומות שהטבלה יפה להם

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

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

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

• מציאת X - מקומו של האיבר הפנימי הוא שארית של החילוק ב-2n (כמותה איברים בכל שורה), כלומר אנו נאתר את כמות האיברים שנותרים לנו אחרי פעולת החילוק, נשים לב כי המפתח הראשון הינו 0 ולכן נפחית את המספר שקיבלנו ב-1.
• מציאת Y - לאחר שמצאנו את X נוכל לחסר אותו מהמספר שאת מיקומו אנחנו בודקים, דבר שייתן לנו מספר המתחלק ב-2n ללא שארית ומציין את המפתח של השורה בה אנו נמצאים, כאשר שוב נזכור כי המפתחות מתחילים מ-0, ולכן נצטרך להוסיף בתחילה ל-X את מה שהורדנו בשלב הקודם.

כעת נכתוב זאת בצורת משוואות:

// array[y][x] = myNumber;
int x = ( myNumber - 1 ) % 2n; // פעולת שארית
int y = ( myNumber - ( x + 1 ) ) / 2n;

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

בלי פאניקה

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

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

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

משדרגים את עצמינו

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

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

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

הקופסה של ההחלטות החשובות

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

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

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

סודות של תכנות

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

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

תכנות נעים.

העורך האולטימטיבי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המשך עבודה נעימה.

עיצוב אתרים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המשך עיצוב נעים.

בניית תשתית לאתר

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

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

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

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

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

התבנית Model-View-Controller
או בקיצור MVC, תבנית בהנדסת תוכנה המחלקת את היישום לשלושה חלקים, ובעזרת דימוי אני אציג את שלושתם.

תזכרו (או לצעירים יותר, דמיינו) את מסיבת סוף יב', וההכנות למסיבה, כאשר ישנן 2 ועדות עיקריות:

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

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

כעת נכיר את אותם המושגים של עולם המסיבות, בעולמו של ה-MVC:

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

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

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

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

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

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

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

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

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

בסיסו של קידוד

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

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

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

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

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

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

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

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

סוגי תגיות: מבנה הדף
התגיות הבסיסיות ביותר בשפת ה-HTML הן התגיות שחייבות להופיע בכל דף, והן המבנה של דף ה-HTML:

• html - פותח וסוגר את מסמך ה-HTML, התגית מכילה את התגיות head ו-body.
• head - בתגית הראש אנו מגדירים מידע על הדף, את האופי שלו, והתנהלות מול הדפדפן.
• title - תגית שנכנסת תחת תגית הראש, ובה אנו קובעים את שם הדף.
  
• body - מה שבא בין התגיות נקרא גוף המסמך, ובו אנו כותבים את התוכן של אותו הדף.
  

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

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

תגיות נוספות (מרכזיות):

• style - לצורך קביעות הנוגעות לעיצוב. ניתן לייבא מסמכי CSS בעזרתו.
  
• script - עבור שימוש בסקריפטים. ניתן לייבא מסמכי Javascript בעזרתו.
• meta - תגיות המגדירות מאפיינים בדף והתנהלות מול המשתמש (לדוגמה הגדרת קידוד שפה בדף).
• link - קשרי גומלין של הדף, ניתן לטעון בעזרתו מסמכי CSS.
• base - הגדרת נתיב עבור קישורים, תמונות ואלמנטים נוספים בדף (לא ממליץ להשתמש בזה).
  

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

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

2 סוגי האלמנטים הבסיסיים:

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

את 2 תכונות אלו מייצגות 2 תגיות: div שמוגדר כאלמנט block, ו-span שמוגדר כאלמנט inline, ומלבד התכונות הללו אין לתגיות אלו שום תכונות אחרות, ועל כן נוח להשתמש בהן במהלך העיצוב.

סוגי תגיות: סוגי אלמנטים נוספים ב-body
מלבד 2 סוגי האלמנטים שכבר ציינתי, קיימים מספר סוגי אלמנטים נוספים:

• אלמנטי none - אלמנטים אלו בלתי נראים ואינם שומרים מקום. אלמנטים נפוצים מסוג זה הם הערות ו-input מסוג hidden.
• אלמנטי inline block - אלמנטים מסוג זה יהיו אלמנטים מסוג block ויאפשרו השתמשות בהגדרות CSS המיועדות לאלמנטי block, אך ישתלבו בתוך השורה ולא יגרמו לירידת שורה של הטקסט אחריהן (לא מתפרסים על 100% מהרוחב).
• אלמנטי list-item - מדובר על אלמנטים ספציפיים השייכים לרשימות, מתנהגים בצורה הדומה ל-block.
• אלמנטי table - מדובר על הטבלה ספציפית, שעובדת ברוב המקרים דומה לאלמנט block, אך מושפעת ברוחבה מהתוכן הנכתב בה. לאלמנטי הטבלה השונים מוגדרת ב-CSS הגדרה ייחודית לתצוגה (לדוגמה table-row עבור tr).

שימו לב: התגיות ul ו-ol הינן אלמנטים מסוג block בדומה לשאר התגיות המצהירות על רשימה, ואילו האלמנט li שבתוכן מוגדר כ-list-item בדומה לשאר התגיות של הרשימות.

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

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

עניין התקנים הוא הכרחי ולא מעט אתרים כבר אימצו לעצמם את התקנים.

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

• תגיות מסוג block שמכילות אלמנטים מסוג block ו-inline.
• תגיות מסוג block שמכילות אלמנטים מסוג inline.
• תגיות מסוג inline שמכילות אלמנטים מסוג inline.

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

בנוסף קיימות תגיות שמכילות תחתן תגיות מוגדרות מראש, לדוגמה תגית ul (תגית block המצהירה על רשימה) מכילה רק את התגית li (תגית מסוג list-item, היכולה להכיל תגיות מסוג block ו-inline).

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

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

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

רגע של מחשבה - האם התגית נדרשת?
לעיתים בשל ההרגל להשתמש ב-div כתגית נטרלית שנוח לעצב, אנשים לא משתמשים בתגיות המתאימות, או שמשתמש בתגית div שלא כצורך, לדוגמה תגית div עם class בשם menu, ובתוך תגית ul של רשימה.
לא רק שהדבר מוסיף תוכן מיותר לדף, כל מה שניתן לעשות בעזרת div ניתן לעשות בעזרת ul, וכיוון ששני אלמנטים אלו מסוג block, אין צורך ב-div, ויצירה ישירות של תגית ul עם class בשם menu תיהיה הרבה יותר יעילה וברורה.

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

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

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

הקשר בין CSS ל-HTML
כדי לקשר בין CSS ל-HTMLl נוהגים להוסיף לתגיות את המאפיין class, בעזרתו ניתן להגדיר שם של מחלקה, או כמה שמות של מחלקות, בכדי לאפיין את האלמנט ולתת לו ערכי עיצוב שונים.
לדוגמה להגדיר class בעל הערך menu primary יאפשר לנו בעזרת css לאפיין כל אחת מהמחלקות האלו בנפרד, ובסופו של דבר לקבל תוצר.

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

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

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

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

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

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

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

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

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

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

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

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

המשך קידוד נעים.

שילוב צד לקוח בצד שרת

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

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


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

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



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


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


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

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

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

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

המשך תכנות נעים.

כל מה שצריך לפיתוח אתרים במחשב ביתי

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

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

קישורים:

• עמוד הבית של אפצ'י - כולל הורדה של השרת, מדריכי התקנה, קינפוג ושימוש.
  

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

קישורים:

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

מסד נתונים - MySQL
מסד נתונים [=בסיס נתונים] - קובץ לאחסון נתונים בצורה מסודרת, לשם אחזורם ועיבודם.
אחרי שגמרנו עם ההגרדה הכוללנית שהופכת את הקבצים בעלי סיומת txt למסדי נתונים (ולעיתים אף יעילים), ניתן להתייחס למסד MySQL עצמו, שזהו בסיס נתונים נוח במיוחד שזוכה לפופולאריות רבה בקרב מתכנתים, ומשמשת מערכות רבות בשל הנוחות שבה.
מסד הנתונים MySQL משתמש בתחביר השפה SQL, שפה דיי פשוטה בעלת תחביר פשוט, ואליה מסד נתונים זה מוסיף תוספות תחביר משלו.

קישורים:

• האתר הראשי של MySQL - כולל הורדה, מדריכים, וחומר רב בנוגע למסד הנתונים.
• W3School SQL - מדריך ה-SQL באתר W3C (באנגלית).
  
• Webmaster SQL - מדריך ה-SQL באתר הפופולארי העברי Webmaster, ישנם גם מדריכי משתמשים מומלצים.

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

קישורים:

• האתר הראשי של phpMyAdmin - מאפשר הורדה, צפייה בדמו, ועוד מגוון אפשרויות כמו מדריכים ותמיכה ברכיב זה.
  

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

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

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

קישורים:

• האתר הראשי של WampServer - כולל הורדה, עידכון רכיבי שרת שונים, עדכונים ומידע.
  

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

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

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

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

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

המשך פיתוח נעים.

SVN - לא עובדים לבד

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

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

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

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

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

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

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


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

האינטרנט כרשת מולטימדיה

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

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

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

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

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

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

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

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

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

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

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

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

עד כאן על מלוטימדיה מזויית הראיה שלי.
המשך גלישה נעימה.

מה שמאחורי האתר

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המשך גלישה נעימה ופיתוח פתוח.

יומהולדת + פרוייקט נגישות לבעלי מוגבלויות

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

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

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

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

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

מה לנו משתלם מזה?
למרות שהיה קשה לי להאמין למספרים, שנשמעו לי מופרכים במיוחד, אבל התברר לי שנוכל לזכות ב-25% מהאוכלוסייה שלא מסוגל לגלוש, ועוד כ-37% אחוז שמתקשה להקל עליו זאת.
מלבד הנתון הזה שנשמע לי דיי גבוה ומופרך, נוספת טענה שאתר נגיש מגדיל את כמות הכניסות שלו ממנועי החיפוש ב-8 עד 14 אחוזים, מה שאמור כנראה לפנות ללב של מקדמי האתרים להשפיע על מפתחי האתרים ובעלי האתרים לתמוך בזה.

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

עדיפויות לנגישות
קיימות 3 עדיפויות לתאימות.

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

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

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

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

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

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

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

אז מזל טוב לי, והמשך גלישה מהנה.

תואר בתוכנות לבניית אתרים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

האם אני אדבוק בה? ימים יגידו, ובינתיים ההתרשמות שלי ממנה דיי חיובית.

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

הילד שצעק "תקנים תקנים"

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

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

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

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

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

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

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

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

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


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

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

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

המשך גלישה לא אדישה לכולם.

עובדים ולומדים - אל תצאו פראיירים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בהצלחה לכל העובדים החדשים, ושנה טובה.

מתחילים ללמוד קידוד

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

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

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

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

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

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

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

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

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

טיפ 1 - ולידטור כתיבה נכונה:
פה ראיתי פחות מודעות לכתיבת CSS נכונה מאשר למודעות של תקני ה-HTML וה-XHTML השונים, דבר שלצערי מצער מאוד.
כתיבה נכונה של CSS יכולה למנוע באגים או תופעות בלתי נעימות שקורות עקב התנגשות של פקודות שונות, דבר שיעזור לבטל את התסכול שנוצר וחוסר ההבנה למה אלמנט לא מגיב כמו שרציתם.
כשאתם מריצים בוליטור CSS את הקוד, רצוי לשנות את הערך ב-warnings לערך All, ובכך לקבל תמונה שלמה הכוללת המלצות שיכולות לעזור למנוע באגים בהמשך הפיתוח.

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

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

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

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

יצירת תפריט לאתר

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המשך גלישה מהנה.