AJAX - מה זה, והאם מדובר בדבר חדש?

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

מה זה AJAX?
Asynchronous JavaScript And XML אלה הראשי תיבות.
מדובר על מונח המאחד תחתיו מספר טכנולוגיות - כשהרעיון הכללי, הוא שדף הבנוי עם טכנולוגיות ה AJAX, ישלב בין צד-שרת לצד-לקוח.
ארכיטקטורת התקשורת הנהוגה ברוב המקומות כיום, היא שכשאני פונה לשרת, ומבקש דף דינאמי כלשהו (ASP.NET למשל), אני מקבל בחזרה מהשרת דף HTML כלשהו עם הגרפיקה, וכל פעולה תתבצע ע"י שליחת המידע לשרת.

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

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

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

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

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

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

עוד דבר חשוב, זאת האפשרות להחליט איפה ירוץ סקריפט, באמצעות המאפיין runat - ניתן לקבוע סקריפט שירוץ ב server (צד-שרת) או script שירוץ בצד-לקוח.
שלושת השיטות הללו שהצגנו עכשיו, בצירוף האובייקטים שקיימים ב .NET לעבודה ולטיפול ב XML, הם הבסיס שאיתו ניתן להשתמש בשביל לבנות מנוע AJAX משלך.

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

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

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

שחר.

שימוש ב OleDb עבור מסד-נתונים מסוג Postgresql

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

אתם מוזמנים להוריד ולנסות. המנוע נכתב כך שיתאים ל ADO, ולא ל ADO.NET. ככה, שדברים עלולים לא לעבוד אם תשתמשו ב .NET.

http://pgfoundry.org/projects/oledb

חוקיות תוכנה ו"מי חסם לי את האקספלורר?"

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

התוכנה תתוקן / תורד, בהתאם למדיניות העדכונים האוטומטיים.
מדובר בתוכנה, שבודקת האם עותק ה Windows שלך חוקי או לא חוקי, ואם העותק חוקי, לא תשמעו יותר מהתוכנה הזאת, ובנוסף, תזכו להוריד תוכנות שונות של מיקרוסופט כמו Windows Defender Beta, Windows MEdia Player 10 וכו'.
אם ה Windows לא חוקי, העדכון אמור "לנדנד" לכם בהודעות שיופיעו כל הזמן ליד השעון, הודעה בעת הפעלת המחשב, והודעה נוספת כל חמש-עשר דקות.
העדכון, דרך אגב, ניתן להסרה בקלות, מה שכמובן ימנע את הורדת תוכנות שהשימוש בהם מותנה בעותק חוקי, וכמו כן, כנראה גם הורדת עדכונים נוספים.
לפני שבכלל מתעסקים בסוגייה "האם מדובר בפעילות כשרה, או חדירה גסה לזכויות הפרט", אני אציין רק את תוצאות הבדיקה הקטנה והלא מחייבת שלי בנוגע ליעילות התוכנה.
התקנתי את העדכון על מספר מערכות (חלקן וירטואליות), כולן עם SP2, והתוצאה הייתה שמערכות חוקיות, ובאמת, לאחר הורדת העדכון (שאפילו לא דורש restart!), לא שמעתי יותר מהעדכון הזה.

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

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

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

1. הצגת הודעה למשתמש על סיבות לשימוש בפיירפוקס.
2. הצגת הודעה על כל המסך המכילה סיבות "למה להשתמש בפיירפוקס".
3. מניעת כניסה לאתרים שונים למשתמשי Internet Explorer.

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

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

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

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

שחר.

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

פרצו לדף הראשי של הבלוגים של מיקרוסופו

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

גרסאות SQL Server 2005 Express חדשות

מיקרוסופט הוציאה גרסא חדשה ל SQL Server 2005 Express Edition, גרסא "מצומצמת" (בעיקר בכלי ניהול ובכמויות המשאבים והנתונים איתם היא יכולה לעבוד, בכל השאר, גרסא מאד חזקה), הגרסא ה"רגילה" החדשה, כוללת את כל הכלים הרגילים לניהול Database, בייחוד הכלים שעושים למפתחים את החיים קלים יותר.
מומלץ מאד למפתחים להתקין אותה, ולעבוד מולה בכל מה שקשור לאפליקציות WEB. חשוב לציין, שנתונים של אפליקציות ASP.NET נשמרות במידה ומותקן, בה.

הגרסא היותר מעניינת, שיותר כדאי להתמקד בה (כמובן, למי שצריך את הפונקציונאליות שלה), נקראת SQL Server Express Edition with Advanced Services (שם מפוצץ. מיקרוסופט מוכשרים בלהביא שמות כאלה), מכילה פונקציונאליות יותר מתקדמת שכוללת פונקציונאליות נוספת.

שתי הגרסאות זמינות כעת להורדה מעודכנת, עם SP1.
עוד כלי שכדאי לשים לב אליו בתחום הזה, הוא SQL Server Management Studio Express, כלי שמאפשר לנהל בקלות רבה את מסדי-הנתונים, בסגנון Enterprise Manage, שמיועד עבור גרסאת ה Express (אין כלי ניהול למד-הנתונים עצמו מובנה, רק כלי הגדרות).

הוא מכיל את רוב הפונקציונאליות העיקרית של Enterprise Manager - ניהול נוח של מסדי-נתונים עצמם (הוספה, צפייה בכל מיני דברים...).
בכל זאת, חסרים בו דברים. הוא לא מנהל את כל מה שקשור ל Mobile, Analysis Services, Integration Services ו Reporting Services, כפי שניתן להבין, כלי חלקי בלבד, אבל בכל זאת, מקל על כל מה שקשור בנושא.
ניתן לנהל עם הכלי גם שרתים לוקאליים וגם מרוחקים (אתה מכניס את פרטי ההתחברות).
צירפתי כמה תמונות מסך נחמדות, תעיפו מבט.

האתר להתעדכן בכל הקשור לזה, הוא www.microsoft.com/sql

יום טוב.

תפיסה או טיפול מונע?

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

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

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

למשל, מקרים של Exception כתוצאה מערך שהכניס המשתמש:

• המשתמש הכניס ערך שגורם לחלוקה באפס
• היות והמשתמש הכניס ערך של ' בשם משתמש, נוצרו בעיות בגישה ל DB

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

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

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

ניתן עוד להביא הרבה דוגמאות, על מקרים שבהם רוב המתכנתים היו תוחמים ב Try & Catch, למרות שיש פתרונות נוחים יותר, אלגנטיים יותר, ושיותר טובים לביצועים של המחשב שלך.
נכון, שכיום, המחשבים חזקים הרבה יותר, ככה שקצת עלייה בדרישת האפליקציה לא "תזיז" יותר מדי, ונכון גם שמשפטי ה Try & Catch ב .NET יעילים יותר, מהגרסאות התואמות שלהם בשפות כמו VisualBasic 6, ושאר שפות קודמות, אבל, עדיין מדובר בעלייה ברמת הביצועים שנדרשת - ולחינם!
במיוחד באפליקציות שממילא כבדות, אין צורך להוסיף עליהן עומס מיותר.

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

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

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

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

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

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

שבת שלום,
שחר.

ל Ineternet Explorer 7.0 יש משהו נגד הבלוגים של מיקרוסופט?

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

ניתן לראות תמונה בקובץ המצורף.

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

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

מוזר.

בועת הפיירפוקס הגיע לקיצה

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

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

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

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

תרגום לתבנית של hover

שיניתי תבנית.
החלטתי שהתבנית של hover יותר יפה לבלוג שלי, אבל היות ולא הייתה לי סבלנות עד שיתרגמו אותה, טיפלתי ב CSS כך שייושר לימין.
בלוגרים אחרים פה- אתם יכולים להוריד את התבנית, ולהכניס אותה ב css override בשביל שהיא תהיה גם בבלוג שלכם.

בהצלחה.

תקן תקן תרדוף

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

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

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

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

ה Web Controls ב .NET Framework 2.0 הותאמו, בשביל שיוכלו לעבוד לפי התקן, והפלט שייצרו יתאים לתקן.
בנוסף, כל דף שנפתח ב VWD 2005, יהיה תואם כברירת מחדל לתוכן, ויכיל את תגית ה Doctype (מציינת שהדף אמור לעבוד לפי התקן).
בנוסף, ה VWD עושה חיים קלים יותר למי שמחפדים מהמילים CSS (עוד ראשי תיבות של 3 אותיות?!) ו XHTML (למה X? מי הרג לי את ה HTML הישן?), זה בגלל, שאם תכתבו דף שלא לפי התקן (תשתמשו, למשל, בתגית font, או לא תשימו סלאש גם בסוף תגית שאין לה תגית סגירה), תוכלו לראות בדיוק מה השגיאה ולקבל עליה מידע.

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

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

מה אני עושה עם סקריפטים ב vbScript?
vbScript לא נתמך ברוב הדפדפנים שאינם IE. בכל מקרה, רצוי תמיד שרוב הקוד ייכתב ב Java Script.

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

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

מהם הנקודות הבעייתיות?
נקודות בעייתיות, שבמקרים מסויימים עלולות לא לעבוד בדפדפנים שונים, הם:

• סקריפטים ב vbScript, או סקריפטים ב JS שחורגים מהתקן של JavaScript בצורה משמעותית.
• תפריטים נגללים, וגרפיקה מיוחדת, עלולה ליצור בעיות, כי במקרים רבים משתמשים בה בתכונות של סקריפטים ותגיות שאינן לפי התקן.
• שימוש בתגיות שקיימות רק ב Internet Explorer ובדפדפנים המבוססים עליו.
• שימוש בטבלאות בצורה לא נכונה.
  עפ"י התקן, מומלץ בכלל להימנע משימוש בטבלאות, ולהשתמש ב Box Moedels (DIV) במקום.
• שימוש במסגרות
  עפ"י התקן, מומלץ להימנע מזה, ולהשתמש, רק במקרה הצורך, ב iframe.

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

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

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

איך אני יודע אם דף תואם לתקן?
http://validator.w3.org

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

לידיעתך:
רוב האתרים יעבדו מצויין גם בדפדפנים נוספים, אפילו אם לא נכתבו לפי התקן.
המכשול העיקרי, שלעיתים מונע פעולות כמו התחברות לאתרים וכו', הוא סקריפטים, ולכן פה, יש לעיתים צורך להקפיד על שימוש ב JavaScript תקני.
הפלט של ה Controls ב ASP.NET 2.0, שופץ, וכעת רובו תקני.
לעיתים, יש צורך במקומות "רגישים" (דפי התחברות והרשמה), לכתוב עם יותר דגש לתקן, כדי שההרשמה לא תשתבש בגלל שאי אפשר ללחוץ או למצוא את הכפתור, למשל.

איך אני כותב לפי התקן, משתמש ב XHTML וב CSS בצורה הטובה ביותר?
כדי להגדיר שאתר יעבוד וידובג לפי התקן, גשו למאפייני הדף, (קליק ימני ב Source ובחירה ב Formatting and Validation), ותיגשו לכרטיסיית הוואלידציה, תוכלו להגדיר את הדף לפי תקן XHTML 1.1, מה שאומר, שתקבלו שגיאות בהתאם לבעיות בתקן.
השגיאות יופיעו כקו אדום מתחת לתגית הבעייתית, והערה שהתגית כבר אינה בתוקף.
{ראה תמונה מצורפת}.
ניתן לבחור בסוגי תאימויות שונות, עבור פעולות שונות. למשל, אם אתה רק רוצה תאימות למוזילה, תוכל הלגדיר את זה, גם בלי לכתוב את כל הדף לפי התקן, אלא רק תקבל התרעה על תגיות שעלולות להיות בעייתיות במוזילה.

כך ייראה דף באופן בסיסי שהוא לפי התקן:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default2.aspx.cs" Inherits="Default2" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >

<head runat="server">

<title>Untitled Page</title>

</head>

<body>

<form id="form1" runat="server">

<div>

</div>

</form>

</body>

</html>

הנה דוגמא לקוד שהוא לפי התקן.

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

הדף מכיל שימוש בתגיות div (Box Model), שבתוכן, ניתן לשים את המידע על ה style.
שימו לב, שבתקן XHTML, ההתמקדות היא לחלוקת הקוד לאיזורים באמצעות תגיות div, כשלכל תגית div (לכל איזור), משוייך קטע כלשהו בקובץ ה CSS, או מוגדר style ספיציפי.
במידה ואתם לא מתשמשים בקובץ CSS חיצוני, ומערבים בין תוכן לעיצוב, לכל תגית div יש מאפיין בשם style, וכשתכתבו style= ב VWD, אוטומטית, תקבלו השלמה אוטומטית של הפרמטרים השונים.
הנה דוגמא קטנה לתגית div עם style (ניתן להוסיף סטייל גם לתגית P, למשל):

<div style="background:'red';border:0">

אם אתם מעוניינים להשתמש בCSS,  ב Add New ITem אתם יכולים להוסיף Style Sheet שיכיל את כל פרטי העיצוב שלכם.
תוכלו לערוך את ה Style Sheet בצורת קוד (אם אתם יודעים לכתוב כזה), או לחילופין, ניתן ללחוץ על הכפתור Build Style שיופיע לכם בין הכפתורים למעלה, בשביל לקבל חלון כתיבת Style Sheet ידידותי יותר.
למעשה, ה Style Sheet הוא דרך "לתת משמעות לתגיות".
למשל, אתה מסביר, שכשאתה כותב h1, אתה מתכוון לכך וכך (מה יהיו המאפיינים של הטקסדט שיהיה בין התגיות h1.
אתה יכול להגדיר מה יהיו המאפייני םשל טקסט ישופיע בין התגיות של body, ואתה אפילו, למרבה הפלא, יכול ליצור תגיות בעצמך, שכשתשמש בהם בשילוב עם קובץ CSS מתאים, יופיע שם בדיוק מה הפירוש שלהן.
בכל זאת, נהוג שלא לעשות זאת, אלא רק להעניק משמעות מורחבת ומפורטת יותר לתגיות הקיימות. בעת הצורך, ניתן להשתמש בתגית span, ולהעביר לה ID.
ה ID ייצג את החלק בקובץ CSS שהוראות העיצוב שלו יוכלו עד לסיום אותה תגית span.

<LINK rel="stylesheet" href="http://www.acme.com/corporate.css">

rel, זה השם של ה Style Sheet כפי שתתייחס אליו בקוד (ניתן להשתמש בכמה CSS-ים במקביל), href זאת הכתובת שלו.
אחרי שייבאת את ה CSS אפשר להתחיל להשתמש בו.
אחרי שייבאנו למשל את ה CSS הקצר שכתבנו קודם, אם נרצה להשתמש בו במסגרת התגית H3, נכתוב <h3 class="something"> text</h3>
היות ואנחנו משתמשים בשמות של class עבור כל תגית, נוכל להגדיר סגנון נוסף לתגית H3, שישמש אם נגדיר את השם שלו במסגרת ה class.
אם יש סתם קטע שנתנו לו שם, נניח שקראנו לו MyPart, נוכל להשתמש בו במסגרת <div class="myPart">

זאת הייתה סקירה קצרה על שימוש ב CSS.
מומלץ לקרוא את המדריך הזה, ללימוד מעמיק:
http://www.w3.org/TR/REC-html40/present/styles.html#h-14.6

בהצלחה.

כל אירוע ואירוע

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

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

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

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

שחר.

Roles & Users ב ASP.NET

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

הוא כתב את האפליקציה ב ASP.NET 2.0, ובגלל חוסר ידע, לא השתמש ביכולות ה Roles & Users שיש בה.
הנה קישור למדריך שכתבתי באתר DevArea, אותו אני מנהל.
אתם מוזמנים לקרוא. הוא מיועד כעיקרון למתחילים.

http://www.devarea.be/Front/Newsnet/reports.asp?reportId=141580

חג פסח כשר ושמח.

על ענייני אבטחה

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

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

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

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

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

רוב הפרצות בהם משתמשי קראקרים כדי לפרוץ לאתרים, פשוטות יחסית. אפילו, פשוטות מאד.
בד"כ, לחסום את אותן פרצות, אם מתכננים את האבטחה מראש בצורה נכונה, זה עבודה מאד קלה.
צריך 2 דברים: מודעות לאבטחה, וידע איך להקשיח את המערכת.
 לחסום את האפשרות להכניס לשדה ההתחברות סימנים של SQL Injection, זה דבר פשוט מאד, לחסום אפשרות של גניבת cookies, זה קצת יותר מסובך, אבל עדיין אפשרי.
ואלה, 2 הבעיות הללו, הן בד"כ הבעיות אותם מנצלים הכי הרבה.
מחרוזות כמו 'or 1=1-- בשביל לעקוף שדה שם משתמש וסיסמא (למעשה, מתערבים בשאילתה, ומשנים אותה קצת, כדי לאפשר לפרוץ).
הנה דוגמא קצרה מאד, רק בשביל להבהיר את העניין על קצה המזלג,  נניח שהשאילתה היא Select * from tbl_users where userName='' and password='' כשבין הגרשיים, רבים טועים ומכניסים ישירות את המחרוזת שהכניס המשתמש.
אם נשתמש במחרוזת הזאת (של ה or), למעשה, "נסגור" את עניין ההכנסה, ונגיד, שאפילו אם הערך שהכנסנו שגוי (אין שם משתמש וסיסמא כזאת), כל עוד 1=1 (וזה תמיד כך), הכניסה שלנו מאושרת, והופכים את כל השאר להערה, כל זה באמצעות פעולה לוגית פשוטה..
בשביל לסנן את הפריצה הזאת, רק צריך לסנן את הקלט מהמשתמש.

או לחילופין, שימוש ב 'having 1=1-- במקומות מסויימים, בשביל לקבל הודעות שגיאה שחושפות קצת את מבנה מסד-הנתונים, גם את זה קל מאד לחסום.
שוב פעם, ע"י סינון הקלט.
כמו כן, רצוי גם שהאפליקציה לא תשמש בהרשאות שמיותרות עבורה ב SQL Server, כדי שנימנע גם ממקרה שמישהו מחדיר לנו שאילתת drop לאפליקציה.
סוג נוסף של פירצות אבטחה שקיים בהרבה אתרים, זה כל הווריאציות של XSS.
לקחת איזשהו פרמטר משורת הכתובת, ולהעביר אותו ישר ל DB, או להדפיס אותו ישר, זה דבר ממש לא בטוח. מה אם מישהו קצת התעסק עם השורת כתובת?
בכלל, כלל חשוב מאד שרבים לא מקפידים עליו, לא לסמוך על מה שה client מכניס.
כל מחרוזת שמוכנסת, חייבת לעבור סינון.
כל זה, עוד לפני שבכלל מדברים על פירצות יותר מתקדמות.

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

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

שיהיה לכולנו פסח כשר, שמח ומאובטח.
שחר.

הוספת ה Dynamic Help ל IDE

מסיבבות השמורות עימם, ועימם בלבד, מיקרוסופט הסירו את כלי העזרה המשולב (ה MSDN, שגם מתעדכן מהאינטרנט), DynamicHelp מסביבת הפיתוח ב VisualStudio.NET 2005.
עבור מי שלא אוהב לגלוש ל MSDN כשיש לו בעייה, או לפתוח בחלון נפרד את ה MSDN Library, יש פיתרון פשוט וקל להוספת ה Dynamic Help ל IDE.

1. לכו לתפריט Tools-->Options-->Help, משמה ניתן לשלוט על מאפייני העזרה.
2. בבחירה של המקטע Show Help Using:, תבחרו "Integrated Help Viewer"
3. תאתחלו את הIDE.
4. כנסו ל Help-->Dynamic Help

עכשיו, התווסף לכם ה Dynamic Help ל IDE.

בהצלחה.

הגיגים על BootCamp של אפל

macs do windows, too.
זה, הסלוגן החדש של חברת אפל, יצרנית מחשבי המקינטוש, לתוכנה חדשה שלה המאפשרת לעשות DualBoot ל Mac OS Tiger,
ול Microsoft Windows XP.
לפני זמן קצר, אפל הפסיקה את שיתוף-הפעולה מול IBM ומוטורולה, עם מחשבי ה PowerPC, ועברה לעבוד עם מחשבי אינטל. PC רגיל.
טוב, כמעט PC רגיל. ההבדל העקרוני הוא שגרסאת לוח האם והBIOS שונה.
זה ההבדל שמונע, למעשה, להתקין באופן עצמאי Windows, בלי תוכנות מתווכות.
Windows Vista ה Windows הבא שייצא באיזשהו זמן, לאחר דחיות אין-ספור, היה אמור לכלול את התמיכה במערכת החומרה בה משתמש MAC,
אבל, כמו הרבה דברים, גם זה הוסר.

Apple השיקה תוכנה בשם BootCamp שמאפשרת לעשות Dual Boot עם Windows, מהלך, שאין ספק, מעורר תדהמה.
מדובר, למעשה, בהורדת אפל מהעץ שעליו היא טיפסה במשך עשרות שנים:
מערכת הפעלה מיוחדת (?), שיכולה לרוץ רק על-גבי חומרה מיוחדת, שרק חברה אחת מספקת, ושום דבר אחר לא יכול לרוץ על אותה חומרה.
עכשיו, כשגם Windows, המתחרה הוותיקה, יכולה לרוץ על מחשבי מק, אפל, למעשה, "יורדת רמה", והופכת מחברת תוכנה, לסתם חברת חומרה,
שמייצרת מחשבים בעלי עיצוב חיצוני יפה, שמגיעים, כברירת מחדל עם מערכת הפעלה (שלמען ההגינות, נציין שהיא יפה מאד. אבל, לפי מה שרואים, Vista בהחלט יכולה לעקוף אותה) מסויימת.

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

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

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

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

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

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

שחר.

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

לפרטים: http://net.nana.co.il/Article/?ArticleID=370470&sid=127