May your sockets never timeout
גוגל סימנו את כל האתרים באינטרנט כאתרים מסוכנים, והציתו תחרות:
מי ידווח ראשון על הפאשלה.
בלוגים מהרו לדווח, ואחריהם אתרי חדשות עדכניים לרוב.
ציטוטי הקורבנות החלו לצוף:
נכנסתי לגוגל כהרגלי, חיפשתי את האתר של הלו דולי, וחשכו עיניי: האתר הפך לאתר רושעה!.
איך שראיתי את זה, ישר ידעתי שגוגל פישלו ומיהרתי לכתוב פוסט, כדי שכולם יראו כמה שאני מקושר ועדכני.
חשבתי שפרצו לי למחשב שוב!
העיתונאים החרוצים אף לקחו תמונת מסך של הפלא:
ואני שואל, למי איכפת? אז היתה טעות, תשיגו חיים.
גוגל וM-Labs שחררו סט כלים שנועדו לבדוק אם ספק האינטרנט שלכם משחק משחקים מלוכלכים מאחורי גבכם.
בין היתר, הכלי יבדוק הורדת ביט-טורנט מול הורדת HTTP מכמה שרתים ברחבי העולם, וידע לזהות אם הספק שלכם פוגע בתקשורת של ישומים שמשתמשים בפרוטוקול הביט-טורנט.
מזכיר קצת את מה שהצעתי לפני שנה וחצי:
שגוף ניטראלי יקיים בדיקות מהירות (אוטומטיות) לכל אחת מספקי הרשת ויציג את התוצאות במקום מרוכז.
נשאלת השאלה, מה ימנע מספקי האינטרנט (שלא נודעו במיוחד בהגינות ובמשחק ההוגן לתעדף ספציפית את שרתי הבדיקה).
שאלה טובה.
M-Labs, המפתחים של הכלים ישחררו אותם ברשיון קוד פתוח ויעודדו אנשים להריץ אותם על שרתים משלהם.
אם זה יקרה, אנשים יוכלו לבצע את הבדיקות מול שרתים 'אנונימיים' שספקי האינטרנט שלהם לא תעדפו.
החשיבות של שרות כזו היא בשקיפות. ספקיות האינטרנט הרגישו חופשי לבצע שינויים מרחיקי לכת בתשתית שלהם, שפוגעות במשתמשי הקצה – בלי שלרוב המשתמשים יהיה מושג שמשחקים להם בקו.
אם ציבור המשתמשים יתחיל להתשמש בכלי הזה ויתלונן בפני ספקיות האינטרנט, יהיה יותר יותר קשה להן להסתתר מאחורי הסברים שהם אולי נכונים חלקית לפעמים, אבל נוחים לחלוטין תמיד – כדוגמאת "זו בעיה באתר" או "יש תקלה באינטרנט, לא אצלנו".
כצפוי, מקורות (אנונימיים) מתחום הISP כבר מכינים מאגר תרוצים למכירה למשתמשים עצבניים:
However, one ISP industry source, who asked not to be identified, questioned whether the tools would accurately point to the cause of broadband problems. Spyware or malware on computers can affect browser performance, and problems with the wider Internet can cause slowdowns, the source said.
כרגע האתר של M-Labs לא זז, כנראה שהם לא צפו את העניין שהשרות שלהם יעורר (ואת אפקט הסלאשדוט).
יוסי גורביץ התחיל לכתוב לפני כעשרה ימים טור חדש בכלכליסט, בשם 'טכנולוגי על הבוקר', שמדבר על חדשות אחרונות בתחום הטכנולוגיה, כולל פדיחות חמות.
שווה בדיקה, הוספתי לגרגרן.
לפעמים באגים מצליחים לחמוק מבין חריצי השרת ונעלמים במרחבי האינטרנט.
חדי העין שמו לב שהפוסט על בנק הפועלים הופיע במשך היום פעמיים.
אירוניה של ממש בהתחשב בזה שהפוסט מדבר על יתירות (Redundancy).
הפוסט הכפיל את עצמו ואת כל התגובות שלו אחרי שערכתי אותו, ולא היה לי ברור איך להיפטר מזה.
שמתי לב שלשני הפוסטים היה בדיוק את אותו ID, מה שגרם לי לחשוש שאם אני אמחק אחד השני יעלם ביחד איתו, אז לא מיהרתי "לתקן" את הבעיה.
לפני כמה ימים משתמש של פיירסטטס התלונן על בעיה מוזרה, שאלתי אותו באיזו גרסאת וורדפרס הוא משתמש, והסתבר שהבחור משתמש ב2.7-beta3 או משהו כזה.
כדי לבדוק את הבאג הורדתי את הגרסא האחרונה של וורדפרס למחשב המקומי, ותיקנתי אותו , ועל הדרך התרשמתי מאוד לטובה מהוורדפרס הממשמש ובא.
כשנתקלתי בבאג הזה, חשבתי לעצמי שאולי זה משהו שתוקן בוורדפרס החדש, אז העתקתי את בסיס הנתונים של הבלוג הזה לבסיס נתונים עם שם אחד, וניסיתי אותו עם וורדפרס 2.7 חדש ישר מהSVN, בלי ערכת נושא ובלי פלאגינים.
הפתעה: עבד בלי הבאג.
המסקנה המתבקשת: מה שזה היה, זה תוקן ב2.7.
החלטתי לשדרג את הבלוג הזה.
שידרגתי, העתקתי את ערכת הנושא ואת הפלאגינים לבלוג 2.7 אחר (לא זה שאיתו בדקתי קודם).
הפתעה: הבאג חזר.
חשבתי לעצמי, זה באג בן זונה חמקמק.
בטח משהו נדפק בבסיס נתונים. ניסיתי להחליף את הבסיס נתונים של הבלוג בדיקות (שמבוסס כאמור על עותק של בסיס הנתונים הזה) עם הבלוג הזה, והבאג נשאר.
חשבתי : טוב נו, אם זה לא בסיס הנתונים זה משהו בקבצים.
התחלתי שוב מאפס, בלי פלאגינים והפעם זה עבד.
אחרי התבחבשות לא קצרה, שבמהלכה האשמתי את ערכת הנושא, ואחר כך את הפלאגינים הגעתי למצב ששיחזרתי את ערכת הנושא ואת כל הפלאגינים שרציתי אחד אחד, וכשסימתי הבעיה לא חזרה.
הבאג הצליח להימלט.
אני חושד שהוא קשור לאיזה תוסף שהיה מותקן לי – משהו של מיניפוסטים, אבל מכיוון שהוא נכשל בהפעלה אני לא יכול להיות בטוח. בכל מקרה לא השתמשתי בתוסף הזה אז זה לא ממש משנה.
בשורה התחתונה, אני עכשיו על וורדפרס 2.7 שעדיין לא יצא, ואני חייב לצין שהוא יפה במיוחד.
השינוי המרכזי ביותר הוא שממשק הניהול עבר שדרוג מאסיבי, גם מבחינת עיצוב וגם מבחינת פונקציונליות.
אפשר לגרור ולארגן את הווידג'טים שבדשבורד עם העכבר, ויש תפריט חדש ואלגנטי.
אין מה להגיד, ממשק הניהול החדש נראה ממש טוב.
אחד הפיצ'רים הנחמדים – שאני משתמש בו ברגעים אלו ממש הוא QuickPress, שזה בעצם בלוק בדאשבורד של וורדפרס שמאפשר לפרסם פוסטים קטנים ישר מתוך הדשבורד – בלי להכנס למסך עריכת הפוסט.
למה קטנים? כי העורך פה מצומצם בגודל וממשק המשתמש פשוט במיוחד.
זה לא הפריע לי לכתוב את הפוסט הזה (שהוא לא קטן במיוחד) ישר משם, רק כדי לבדוק את זה.
כהערת ביניים : בעיה ראשונה שמצאתי היא שההכנסת תמונה לתוך הפוסט לא עובדת במצב הזה, אבל אני בטוח שזה יתוקן.
טוב, אני הולך לפרסם את הפוסט ולסיים לערוך אותו מממשק העריכה הרגיל.
—
טוב, הצלחתי אחרי שכיביתי את הפלאגין שמוסיף את הPreview pane.
דבר מעניין הוא שתפריט הנייוט הצידי נשאר גם פה, מה שמאפשר ניווט גם תוך כדי עריכת פוסטים.
ניסיון לנווט מקפיץ חלון אזהרה נדרש.
במהלך המשחקים שלי, פיירפוקס קרס פתאום – רגע הוא היה שם ורגע אחרי הוא פשוט נעלם.
בכניסה מחדש וורדפרס איפשר לי לשחזר ולהשוות גרסאות קודמות שנשמרו אוטומטית בממשק ברור ופשוט.
העורך הוויזואלי הוא די איטי, אבל אני לא בטוח שזה חדש (רק לאחרונה הפעלתי מחדש את העורך הוויזואלי אחרי חודשים ארוכים שעבדתי עם העורך הפשוט).
טוב, ולסיכום – צילומסך של ממשק הניהול (בתקווה שהשוא"ש לא יעוף שוב) :
נניח שאני רוצה לפרסם מידע ככה שאני אוכל לקשר אליו אבל אף אחד לא יוכל לטעון שאני אחראי לו (לו בלי עבודת מחקר מעמיקה שנמצאת מעבר ליכולת של רוב האנשים).
לא פעם ולא פעמיים אנחנו נתקלים בשימושים מעניינים של המטמון של גוגל כדי לגשת לתוכן שהורד מאתר מסויים (בדרך כלל עקב דרישה משפטית). הבעיה היא שהתוכן ישאר זמין במטמון של גוגל לזמן מוגבל.
מה אם אתם הם אלו שקיבלו את הדרישה להסיר תוכן מהרשת?
אז איך אפשר לנצל את המטמון של גוגל בצורה יותר יעילה, ולא מוגבלת בזמן?
מה דעתכם על זה:
הלינק המקורי נראה שבור, אבל הוא רק נראה שבור.
גוגל בוט מצליח להכנס ולקרוא אותה, ובשאיפה מכניס אותו למטמון של גוגל, פה (לא מיד אחרי פרסום הפוסט).
כאלטרנטיבה, אני מקווה שהחיפוש הזה יביא את הלינק במקום הראשון.
הקוד של הדף זמין פה.
מה דעתכם? 🙂
אני שומע את סדרת הספרים The uplift saga של דיוויד ברין.
היום סיימתי לשמוע את הספר השלישי (מתוך שישה), והחלטתי לעדכן את הפודקסטים שלי; הפעלתי את הiTunes המאוס, ולא הופתעתי לראות עדכון לiTunes 8.
מה שכן הפתיע אותי זה שאפל בחרו לדחוף לי משהו בשם בונזו'ר לחלונות, כדי .. לשפר את האבטחה של בונזו'ר לחלונות.
לא ידעתי שיש לי את בונז'ור הזה.
סירבתי להזמנה הנדיבה בתקיפות.
אחרי קצת מחקר, גיליתי שזה אפילו יותר גרוע מזה:
העדכון האחרון של אפל מתקין דריברים חדשים, ועוד כמה מתנות (חמש חבילות התקנה נפרדות?!). ושכמובן שמשתמשי חלונות רבים נתקלו במסכים כחולים ותפוחים בתולעים בעקבות השדרוג.
אפל כמובן לא יספרו למשתמש מה הם עושים במחשב שלהם.. אה, שלו.
שינאה.
שוחררה הגרסא האחרונה (ככל הנראה) בענף של PHP 4.4.
הגרסא הזו מסמנת את סוף התמיכה הרשמית בPHP4.
PHP5 כבר בחוץ במשך יותר משלוש שנים, אבל עד עכשיו האימוץ שלו היה די איטי, מסיבות של ביצה ודינוזאור:
מפתחי התוכנות לא רצו להפסיק לתמוך בPHP4 כדי לא לאבד משתמשים. חברות אירוח האתרים לא טרחו לשדרג כי כל התוכנות החשובות תמכו גם ככה בPHP4 והמשתמשים, מה איכפת להם?
בשנה שעברה נפתח אתר gophp5.org, ששם לעצמו למטרה לדחוף את האימוץ של PHP5.
הרעיון הוא שאם מסה מספיק גדולה של פרוייקטים תעבור לPHP5, ומסה מספיק גדולה של חברות אירוח תעבור לPHP5, לשאר חברות האירוח לא תהיה ברירה והן תאלצנה לשדרג או לאבד משתמשים, ואז לשאר הפרוייקטים לא תהיה סיבה להשאר בPHP4 והם יוכלו להתחיל סוף סוף לנצל את היכולות של PHP5.
בפברואר 2008 כבר היו מעל 100 פרוייקטי תוכנה שהתחייבו להפסיק לדאוג לתמיכה בPHP4 (זה לא אומר שהם ילכו וישברו את התמיכה בPHP4 בכוונה, פשוט שהם יפסיקו לדאוג שקוד חדש ירוץ בPHP4), ומעל 200 חברות איכסון שתומכות בPHP 5.2 כביררת מחדל וgophp5 טענו להצלחה והפסיקו לאסוף הרשמות.
אז למה לא לתמוך בPHP4? הנה דוגמא מאתמול:
JSON הוא דרך להעביר מבנה נתונים כלשהו לייצוג של מבנה הנתונים כאובייקט ג'אווה סקריפט, והוא אחת הדרכים הפשוטות והיעילות ביותר להעביר נתונים מקוד בצד השרת לדפדפן (שפשוט מפעיל על הטקסט שחוזר את המפסק (parser) של ג'אווה סקריפט כדי לקבל אובייקט מוכן לשימוש.
למרות שראשי התיבות של AJAX הן Asynchronous Javascript And XML, מעולם לא השתמשתי בAJAX כדי להעביר XML, למעשה אני מוצא את הרעיון מזעזע. הרבה יותר קל להעביר JSON, או אפילו קוד HTML ממש.
JSON משמש בהרבה מאוד פרוייקטים מבוססי AJAX, ומכיוון שאין בPHP4 תמיכה מובנית בJSON (אחרי הכל, PHP4 הוא בן שמונה, וJSON הוא די חדש בשכונה) צריך להשתמש בספריות חיצוניות שיודעות להעביר אובייקט PHP לפורמט JSON, אחת הספריות הנפוצות היא Services_JSON (למעשה אני משתמש בספריה הזו בFireStats).
הספריה כתובה בPHP, ולמרות שהיא עובדת נכון, היא לא ממש עובדת מהר, במיוחד כשממירים מבני נתונים גדולים (לא עצומים, משהו בסדר גודל של מערך עם 1000 אובייקטים טיפה מורכבים) לJSON.
ממש אתמול ניסיתי לשפר ביצועים של ישום PHP, אחרי חפירות גיליתי שאחד הדברים שמאטים מאוד את העסק היה המרה של תשובה לדפדפן לJSON בשימוש בServices_JSON, כשאני אומר איטי, אני מתכוון ל8 שניות.
שמונה שניות שהשרת טוחן את הCPU שלו כדי להכין תשובה ללקוח (במקרה הספציפי הזה, במקרים אחרים עם יותר נתונים זה כמובן יותר גרוע).
ברגע שראיתי את זה, לקח לי בדיוק שניה וחצי להיזכר שPHP5 תומך בJSON. בדיקה מהירה בphp.net הניבה את שתי הפונקציות הפשוטות json_encode וjson_decode. החלפתי את השימוש ב Services_JSON בקריאה לפונקציות של php5, ולא הייתי מופתע במיוחד לראות שהמרה של אותו מבנה נתונים לוקחת פתאום 40 מילישניות.
שיפור של פי 200, בזמן עבודה של כמה שניות (טוב, חוץ מלמצוא את הבעיה 🙂 )
השיפור נובע מכך שהתמיכה של PHP בJSON לא כתובה בPHP אלא בC, ולכן היא הרבה הרבה יותר יעילה.
השיפור הזה התאפשר רק כי הפרוייקט הספציפי הזה לא צריך לתמוך בPHP4.
מה אני אצטרך לעשות בFireStats, שעדיין תומך בPHP4 כדי להנות מהשיפור הזה? לבדוק אם אני על PHP5, ואם כן להשתמש בפונקציות האלו אחרת להשתמש בServices_JSON. לא כיף במיוחד.
ואם לא היתה לי סיפריה כמו Services_JSON (כי אין, או כי תנאי הרשיון לא מתאימים לי), הייתי נאלץ לכתוב אחת או פשוט לעבוד בצורה אחרת, פחות נוחה. גם לא כיף.
אז איך מתקדם האימוץ של PHP5?
החל מFireStats 1.3 ששחרתי לפני יותר משנה, FireStats מכילה רכיב ששולח (באישור המשתמש) מידע מערכת אנונימי. חלק מהמידע הוא גרסאות הPHP והMySQL.
הכוונה היא שאני אוכל להשתמש במידע הזה כדי להחליט בצורה יותר מושכלת במה אני צריך לתמוך.
המידע הצטבר לי בבסיס הנתונים, ונכון לכרגע יש לי מידע על כמעט 12000 התקנות. מה שאומר כמעט 12000 שרתים בעולים (אני מתעלם ממקרים של כמה התקנות על אותו שרת).
למי שתוהה, זה לא אומר שFireStats הותקנה 12000 פעמים, אלא ש12000 פעמים המתקינים הסכימו לשלוח מידע מערכת אנונימי.
מי שרוצה את המידע הגולמי מוזמן לקחת אותם מפה (יצוא MSQL, כ5 מגה דחוסים, 65 מגה פרושים).
אז ישבתי כמה שעות כדי להוציא מהנתונים הגולמיים שני גרפים נחמדים:
הראשון הוא אחוזי ההתקנות של PHP 4 מול PHP 5, במהלך השנה האחרונה.
למרות שאחוזי ההתקנה של PHP4 ירדו במהלך השנה האחרונה מ52% ל38%, עדיין מי אי אפשר להתעלם ממנו. נקווה שהוא ימות סופית בקרוב:
השני הוא אחוזי ההתקנות של הגרסאות המשמעותיות של MYSQL:
כיף לראות שMYSQL 5.0 שולט בשוק, אבל נראה שMYSQL 4.0 הזוועתי נתקע על 7% ולא רוצה למות.
בכל מקרה, MYSQL 4.0 הוא בהחלט מועמד לנטישה, וכבר היום יש לא מעט תכונות חשובות של FireStats שלא נתמכות בגרסא הזו.
אם יש משהו שאני אוהב בפרוייקטי קוד פתוח, זה שאנשים מוכנים לפעמים לעבוד די קשה כדי לשפר אותם.
את IP2C, ספריה למציאת המדינה של כתובת IP שחררתי לפני כמעט שנתיים, וכתבתי גם פוסט שמספר על המימוש שלה פה.
IP2C ממומשת בPHP ובג'אווה. מה שמיוחד בה זה שהיא מסוגלת לחפש ישירות על הקובץ, מה שאומר שחיפוש בודד הוא מאוד מהיר כי לא צריך להעלות את כל הקובץ לזכרון.
הייתי לגמרי מרוצה מהביצועים של הספריה בPHP (כ1200 חיפושים בשניה במחשב האחרון שמדדתי), אבל הביצועים בג'אווה היו טובים יותר משמעותית – כ8000 חיפושים בשניה על אותו מחשב בעבודה ישירות על קובץ הנתונים.
ההבדל בביצועים בין PHP לג'אווה לא הטריד אותי, כי היה לי ברור שPHP תהיה יותר איטית מג'אווה, אבל הוא כן הטריד את תומס רומר שהתיישב על העסק לילה שלם ושיפור את הביצועים של גרסאת הPHP ב150%.
תומס כתב פוסט מעניין על השינויים שהוא עשה, ושלח לי את השינויים. שבמבט ראשון נראים טובים ואני אקלוט אותם לפרוייקט אחרי בדיקה מעמיקה יותר.
בנוסף דיברנו קצת בIRC, והוא יעבוד על תמיכה בבסיס הנתונים של software77 :
software77 מספקים בסיס נתונים של IP למדינה, שאמור להיות יותר איכותי מבסיס הנתונים שIP2C משתמשת בו כרגע (webhosting.info), אבל יש להם קצת בעיות בעקביות המידע.
התחלתי לעבוד על תמיכה בבסיס הנתונים שלהם לפני כמה חודשים טובים, אבל כשראיתי שזה נמשך יותר מדי הקפאתי את העסק (שעדיין נמצא בTODO שלי, קבור איפשהו 🙂 )
תומס ימשיך מאיפה שהפסקתי.
מייקרוספט תורמת 100,000 דולר לקרן התוכנה של אפאצ'י.
המהלך הופך את מייקרוסופט לספונסר פלטינום כמו גוגל ויאהו.
שאלתי כבר, האם מייקרוסופט משתנה?
——————–
דן קמינסקי – האקר, גילה חור אבטחה ברוב המימושים של שרתי הDNS היום שמאפשר התקפת הרעלת מטמון (Cache poisoning).
דן פנה במקביל למפתחות הDNSים הראשיות במטרה לארגן שחרור טלאי משותף במקביל, במטרה למזער את חלון ההזדמנות מרגע שהטלאי שוחרר לראשונה עד שהוא יהיה זמין לכל המימושים של שרתי הDNS.
אחרי חצי שנה של עבודה סודית הטלאי שוחרר אבל קמינסקי ביקש מקהילת ההאקרים לא לנסות לנחש מה החולשה, כי השוק צריך חודש כדי לבדוק ולהתקין את הטלאי.
החודש הזה נגמר באופן נוח בדיוק בתתאריך של כנס הכובעים השחורים, בו קמינסקי תכנן לספר לכולם על החולשה שהוא גילה, ולקטוף את הקרדיט (שמגיע לו).
ההתנהלות הזו עיצבנה לא מעט האקרים, כמה מהם הצליחו להבין את החולשה ושחררו קוד שמנצל אותה, מה שמעלה מאוד את הדחיפות של ההטלאה.
עוד על זה כאן.
בדרך כלל אני נוטה לחשוב שבנקים ואתרים שהתעסקות עם כסף של אחרים היא הביזנס המרכזי שלהם לוקחים את האבטחה ברצינות.
על ההנחה הזו אני מבסס הרבה דברים, כמו למשל ההנחה שלי שקניה באינטרנט היא יותר בטוחה מקניה בטלפון, וזה שאיפשרתי העברת כספים מחשבון הבנק שלי בהוראה דרך האינטרנט.
באופן טבעי תפסתי גם את Paypal כאתר שלוקח אבטחה ברצינות.
החלטתי לצ'פר משתמשי פיירסטטס שתורמים ולתת כמה פיצ'רים למי שתורם בלבד.
מכיוון שאני מקבל את התרומות דרך Paypal חשבתי שזה יהיה נחמד לדאוג לאיזה תהליך אוטומטי שישלח לתורמים אימייל עם לינק להורדה של הפיצ'רים הנוספים.
פניתי לאתר של Paypal, שתומך במשהו שנקרא IPN : Instant payment notification.
בקצרה, האתר של Paypal קורא לURL שאתם מספקים לו ומעביר לו פרטים על הטרנזקציה (מי זה, כמה הוא נתן, וכו').
האתר שלכם מאמת את הפרטים מול Paypal, ומכניס אותם לבסיס הנתונים ועושה מה שאתם רוצים.
די פשוט, אבל חבל בזבוז אנרגיה שכל מי שרוצה להתממשק מול Paypal יצטרך לכתוב את זה מחדש, ולכן Paypal בחוכמתם מספקים Script generator שמייצר קוד שעושה את העבודה במספר שפות.
שמח וטוב לבב, לקחתי את סקריפט הPHP שהוא ייצר לי, והתחלתי לשחק איתו.
לא עבר יותר מדי זמן, ופתאום הבנתי שחוץ מזה שהקוד מכוער במיוחד הוא גם פרוץ לחלוטין ופגיע להתקפת SQL Injection.
[code lang="php"]
$struery = "insert into paypal_cart_info(txnid,itemnumber,itemname,os0,on0,os1,on1,quantity,invoice,custom)
values ('".$txn_id."','".$_POST[$itemnumber]."','".$_POST[$itemname]."','".$_POST[$on0]. "','".$_POST[$os0]."','".$_POST[$on1]."','".$_POST[$os1]."','".$_POST[$quantity]."','".$invoice."','".$custom."')";
$result = mysql_query($struery) or paypal_die("Cart – paypal_cart_info, Query failed:
" . mysql_error() . "
" . mysql_errno());
[/code]
SQL Injection היא התקפה שמאפשרת שינוי וקריאה של בסיס הנתונים בצורה שהמפתח לא תכנן, עוד פרטים בוויקיפדיה.
מה שזה אומר זה שכל מי שהשתמש בקוד לדוגמא שלהם בלי לשים לב לבעיה (אני מניח ש99% מהמשתמשים) יצר לעצמו בעיית אבטחה בשרת, בדיוק בנקודה הקריטית שנוגעת לכסף.
כתבתי להם הודעה בפורום המפתחים שלהם, נקווה שהם יקחו אותה ברצינות.