קטגוריה: PHP

דברים שמעצבנים אותי ב PHP ו MySQL

הקדמה

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

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

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

Why PHP must be abandoned (in my opinion)‎

Foreword

Every now and then, I find myself using PHP as a programming language.
I started using it since the early of 2000, and never really liked it.
Most people like it not because it is good, but because it is easy to "get inside" and start developing stuff with it.

But that's exactly one of it's biggest problems in the world.
I do not want that a programming language will be "easy" to start with, I want it to be good with what it suppose to provide.

First of all, easy is a relative word. That is, you must compare it to something. Back in the days, it was easier to start with PHP then with Perl for example. But when you actually start to "enter" inside the language, well, it's not really a programming language per-se, but a group of a lot of tools that allow you to have some sort of glue to use them.
It does not really act as a language (like with Perl), but a borrow stuff from other languages, such as Perl, C and few others.

Recently I found yet another problem with PHP. I got a 3rd party source code that explains to me how to implement a protocol that reinvent the wheel of HTTP REST using "JSON" like code, but with it's own TCP header, rather then to use plain old HTTP.

Problem

The way that they implement it, is really weird, because instead of using the "pack" function, they are using their own bit manipulation code (poorly), and use the "chr" function to convert each byte into an ASCII value representative.

They code it like so:

 chr(1000 >> 0) . chr(1000 >> 8) ....
The problem is that chr(1000)  (shift right by 0, keeps 1000 as 1000) must report an error, because 1000 is bigger then the last ASCII code (127), or extended ASCII code (255).
I'll explain it again: 1000 is bigger then the range of 255 . ASCII is only at the range of 0..127 chars, but extended ASCII provides extra chars up to 255 (full byte length).
Note: Even a numeric value of 256 is bigger then one byte !
With Ruby for example, I get "RangeError" exception for such action, so does with Python, Pascal, Perl (with strict bytes) and few other programming languages.
While with PHP, well it returns the value of 232.
You must shout out loud, "wait, WHAT ?" if you haven't done it by now.
I'll say it again: "chr(1000)" with PHP returns the value of 232.
It is doing so due to bit manipulation ($value & 255), but it's actually type of an integer overflow IMHO.Why you ask ? Well, the aim of "chr" is to provide one character of ASCII value. The spec of ASCII chars is very very very simple:
Range of a char is 0 to 127 (they write ASCII and not extended ASCII).If you are converting an integer value to it's ASCII value, and the last value is 255 (going extended ASCII here), then what is the representation of the 1000 value in extended ASCII ?
Answer: You do not have one.
That's why normal languages (give or take) return an error that you are out of range.When you give an answer that is not an error, then it means that there is a representation for the value. but 1000 is not 232, it's 1000, and 1000 is out of range.So you might call it a bug right ?
Well according to a person that works at Zend, it is a feature, and the bug is that it is undocumented feature.

Here it is (typos are from the original email):

First of all, this is not integer overflow. integer overflow is hwen the aritmethic result can not be held in integer. here, the function translate what it can and should, which is the last significant byte. I don't see a problem with that except of that is should be documented. if you test 1000 & 255 (the last byte of 1000) you will see that the result is indeed 232.

Oh, and this is the bug I opened for it, so you can follow it yourself.
And It's not the first or last of such "features" within the so called "language".

End

I for one, do not welcome our PHP overlords.
And I think that it's time to abandon this patched "ship" you call a language. The benefits of going in fast, are payed in the long run. with many problems that you actually require an IDE for not loosing your leg by hitting a mine.

סיבוכיות המערך ביעילות חלק 2

בחלק הקודם דיברתי על קוד PHP אשר גרם לי להרבה שקט. ואז הצגתי בעיה:

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

אז מה עושים ?

  1. להשתמש בהרצת הפקודה ls עם glob (למי שלא מכיר, glob זה ההוראות לאיזה תוכן להחזיר לנו, למשל סימן שאלה, כוכבית וכו'…).
  2. לרוץ על כל קובץ וקובץ ולהתחיל לפרק אותו לתווים. אני לא זוכר איך נקרא האלגוריתם, אבל משתמשים בו בד"כ בביצוע מילון.
  3. ריצה על מערך מלא בקבצים, ובכל קובץ, להתחיל לראות אם יש איבר במערך אשר מכיל כמה שיותר תווים מהקובץ שנמצא. אם הכל היה שווה עד שהגענו לסוף המחרוזת באיבר, אז כנראה שמצאנו.
  4. אפשרות נוספת היא לעשות אותו הדבר, כמו אפשרות 3, תוך שימוש בפונקציות של PHP.
  5. ואתם מוזמנים לחשוב על עוד כמה ….

אני בחרתי באפשרות הרביעית וכתבתי את הדבר הבא:

 

foreach ($files as $index => $value) {

foreach ($list as $key => $name) {

if (strncmp($name, $value, strlen($name)) == 0) {

$list[] = $value;

break;

}

}

}

 

פשוט 🙂

סיבוכיות המערך ביעילות חלק ראשון

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

יצרתי "לקוח" ב Lazarus עבור עבודה עם xml-rpc, כאשר אני יכול לערוך את הXML עם צביעת התחביר וכמובן לקבל את התשובה שגם היא צבועה. כל זה גם מכיל log כמובן של כל דבר שהתרחש. והכי חשוב, זה כתוב בצורה מותאמת להיות cross platform.

כל הדבר הזה לקח שעה וחצי של תכנות (הייתי צריך להיזכר איך כותבים תוכנה גרפית רצינית, ולחשוב בצורה חוצה פלטפורמות זה לא דבר קל למי שלא רגיל). התוצאה היא 300 שורות קוד אשר אני כתבתי שנותנות לי את כל התוצאה הזו (בנוסף לעוד כמה תכונות נוספות שלי די מקלות על החיים, ולמרות שהן פשוטות מאוד, התכנון שלהם לקח הרבה אנרגייה). הבעיה היא ששעתיים וחצי טיפלתי בבעיות כמו חוסר תמיכה של gdb ב"חברים" (members) של FPC, אם זה במחלקות או ברשומות דחוסות (בפסקל כל הרשומות דחוסות, רק צריך להגיד למהדר איך לדחוס). היו גם כמה באגים נוספים שמצאתי בספריית lnet שתיקנתי ושלחתי patch שהתקבל ונכנס ל svn. ועוד כמה באגים שאני צריך ללמוד אותם יותר לעומק בשביל לדעת איך לדווח עליהם נכון.

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

להמשיך לקרוא