יום שני, 7 בספטמבר 2009

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

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

אותו הירוק

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

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

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

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

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

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

בלי פאניקה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תכנות נעים.

יום שישי, 21 באוגוסט 2009

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

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

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

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

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

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

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

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

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

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

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

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

שלכם,
איתי.

יום ראשון, 7 ביוני 2009

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

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

יום ראשון, 17 במאי 2009

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

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

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

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

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

יום שבת, 2 במאי 2009

עיצוב אתרים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יום חמישי, 16 באפריל 2009

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 המושלמת, ומקווה שמישהו שמע עליה.

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

יום שני, 23 במרץ 2009

לרצות פשוט

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יום שישי, 6 במרץ 2009

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

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

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

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

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

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

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

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

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

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

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

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

יום שישי, 23 בינואר 2009

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

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

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

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

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

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

יום שלישי, 13 בינואר 2009

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

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

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


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

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



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


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


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

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

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

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

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

יום שישי, 2 בינואר 2009

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

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

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

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

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

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

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

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

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

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

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

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