ארגון הזמן

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

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

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

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

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

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

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

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

המשך מרוץ נעים.

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

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

אותו הירוק

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

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

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

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

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

דוגמה יפה לבעיה שכזאת היא תרגיל בו נתון לנו מערך דו מימדי, כלומר מערך בתוך מערך, כאשר בכל אחד מהם 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;

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

בלי פאניקה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תכנות נעים.

המתכנת שבחיינו

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

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

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

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

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

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

בדומה לפוסט שהצגתי לפניכם, אני גם מוצא לנכון לקשר לקומיקס שעוסק באיך פרויקט באמת עובד:
http://www.projectcartoon.com/cartoon/2

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

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

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

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

שלכם,
איתי.

הדרך ל-Windows 7

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

החיפוש אחר עורך טקסט חדש אינו קל, בייחוד כי לכל אדם יש דרישות וצרכים שונים, כאשר אם לאחד זה שהעורך יצור קוד 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) שעוסק ביצירת אפיון בדרכים שונות, ובין היתר מתייחס ללקוח במהלך האפיון.

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

Disk on Key - המחשב שלך

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

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

הכרות עם ה-U3
את ה-U3 אני מכיר כבר זמן רב, מדובר בלא יותר מכפתור "התחל" שמאפשר גישה מהירה להגדרות והפעלת תוכנות בצורה מהירה, ממש דומה לתפריט התחל שיש בחלונות, ההבדל העיקרי הוא שהתוכנות מותקנות על ה-Disk on Key ושניתן להפעילן מכל מקום בו יש מחשב עם חלונות.
הדבר העיקרי שגרם לי לפנות לזה הוא הידיעה שלא בכל המחשבים בבית שלי יש Firefox, אז אם אני כנראה ארצה לגלוש בצורה המועדפת עלי, אני אצטרך להביאה איתי, וכאן התחלתי במסע התקנות קצר, אם זה תוכנה לקריאת PDF, אם זה תוכנת SKYPE, ואם זה הדפדפן האהוב והמוכר.

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

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

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

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

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

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

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

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

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

לרצות פשוט

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

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

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

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

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

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

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

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

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

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

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

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

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

גלישה פשוטה לכולם.

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

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

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

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

המדריך להמנעות מהודעות ספאם

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

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

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

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

להטל ברובוטים במגרש שלהם
במידה ויש לפרסם בפומבי, נסו לצנזר את הדואר האלקטרוני בצורה שלא תאפשר לרובוטים לקרוא אותו:
user [at] domain [dot] com
בצורה זו הרובוטים לא יוכלו לקרוא את הכתובת הרשומה, אך המשתמשים העצלנים יותר וחסרי המוטיבציה לא ינסו לפענח את הרשום, ועל כן יש להשתמש בדרך זו רק כאשר הדבר נדרש וברור מאליו שהצד השני רוצה ליצור איתכם קשר ולא משנה מה.
בנוסף יתכן כי משתמשים שירצו לשלוח לכתובת יטעו בפיענוח, יוסיפו בטעות רווח או ישמיטו בטעות אות, ועל כן לא ניתן להיות בטוחים בדרך זו כי כל ההודעות אכן מגיעות אליכם.

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

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

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

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

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

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

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

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

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

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

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

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

המשך גלישה נעימה וחסרת ספאם.

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

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

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

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

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