PHP: обрезаем backtrace у exception

Разберём следующий кейс.

Разрабатываем мы на своём любимом похапэ некую систему и используем при этом некую библиотеку.
Пускай, например, это будет вот эта поделка для работы с базой данных.

И вот мы вызываем какой-то метод в нашей системе, тот вызывает ещё какой-то и так далее.
И, в конце концов, где-то мы обращаемся к вышеозначенной библиотеке:

$db->query('SELECT * FROM `test` WHERE `id`=?i')->el();

Запрос составили, в каком формате результат вернуть указали, куда данные вставлять с помощью плейсхолдера указали, а вот сами данные для этого плейсхолдера не предоставили.
Запамятовали в пылу разработки.

И вот, вызванный нами, метод query() начинает обращаться к каким-то другим классам библиотеки, те к следующим и так далее, всё как обычно.
В какой-то момент доходит дело до того, чтобы данные в запрос на нужные места вставлять и тут выясняется, что данных нет никаких. Ну и, ясное дело, всё валится с исключением:

go\DB\Exceptions\DataNotEnough: Data elements (0) less than the placeholders in /test/my/db/Helpers/Templater.php on line 126
 
Call Stack:
    1. {main}() /test/my/index.php:0
    2. callMyClass() /test/my/index.php:14
    3. MyClass->method() /test/my/index.php:11
    4. MyClass->selectDB() /test/my/MyClass.php:7
    5. go\DB\DB->query() /test/my/MyClass.php:20
    6. go\DB\DB->makeQuery() /test/my/db/DB.php:92
    7. go\DB\Helpers\Templater->parse() /test/my/db/DB.php:312
    8. preg_replace_callback() /test/my/db/Helpers/Templater.php:57
    9. go\DB\Helpers\Templater->placeholderClb() /test/my/db/Helpers/Templater.php:57

Смотрим мы печальными глазами на этот вывод и читаем сообщение, ага, забыли данных накидать.
А вот где именно это случилось, хрен поймёшь.
Исключение указывает на точку, где его выбросили, то есть глубоко в недрах библиотеки и делать нам там нечего.
Нам нужна та точка, где мы в эту библиотеку с невалидными данными вошли.

Остальной текст под катом

Когда евро — не евро

Начинаем новую рубрику «пятиминутка ликбеза с сайтом Таблица символов Юникода»

Сегодня посмотрим на раздел «Управляющие символы С1», к которому относятся символы с кодами от 0080 до 009F. То есть блок, идущий сразу после ASCII (первые 128 символов).

Этот раздел был унаследован Юникодом от кодовой страницы ISO 8859-1. Сама же ISO 8859-1 (также известная, как Latin-1), основана на символьном наборе для терминалов. В следствии чего, первые 32 символа были выделены для различных терминальных команд. То есть, «разрешение разрыва строки», «запрещение разрыва строки», «обратный перевод строки», «символ-заполнитель» и остальной допотопный треш.

На Latin-1 также раньше строились и другие 8-битные кодировки, в частности Windows-1252, использовавшаяся в Windows для западноевропейских алфавитов.

Однако, Microsoft, как всегда, сторонние стандарты использует, но только так, как хочет. Там решили, что в Latin-1 не попали многие нужные и ненужные, но забавные, символы. Например, не попал знак евро (€), что всех очень напрягало, так как цены на сайтах писать не удобно. Зато целых тридцать две позиции занимают какие-то символы для терминалов. Кому они нужны? На терминалах-то и Windows нету.

Остальной текст под катом

Таблица символов Юникода — новые горизонты

А тем временем антисоциальная сеть нового поколения «Таблица символов Юникода» развивается бешеными темпами.

Уже 5 000 пользователей каждый день заходят на сайт с одним им известными целями.

Как показала практика, добавление новых фич и фишек на сайт не даёт никакого прямого эффекта. А вот если просто забросить его на полгода, то посещаемость сразу начинает стабильно расти.

Чтобы как-то сбить этот бурный рост, с которым уже не справляется наш дохленький сервер, мы собираемся в ближайшее время добавить множество новых возможностей.

Из того, что мы успели сделать в последнее время:

1. Таблица символов, наконец, показывает действительно, практически, все символы, а не квадратики. Это достигается использованием нормального шрифта, а не того барахла, которое стоит по умолчанию во всех операционных системах. Чтобы не слишком нагружать пользовательский канал, шрифт подгружается не целиком, а постепенно, нужными частями.

2. Теперь русские названия символов, это, в большинстве своём, действительно, названия. А не треш из гугло-переводчика.

3. Благодаря иностранным волонтёрам у нас теперь есть интерфейс на тайском, китайском и украинском.

4. И ещё много приятных мелочей.

Из того, что запланировано:

1. Добавление следующей плоскости из стандартна, то есть символы после 65 536. На практике, это совершенно бессмысленная мешанина из иконок типа «самолётик» и «домик». Но для сообщений вконтакте самое то.

2. Множество контента с описаниями символов, разделов, алфавитов и много чего ещё.

3. Обучающие статьи.

4. Новые забавные разделы символов.

5. И ещё множество того, чего мы ещё сами не знаем.

Если вы программист, переводчик, лингвист или просто хороший человек и хотите поработать с нами за уважение и большое человеческое спасибо, обращайтесь. Помните, что Таблица символов Юникода — выбор домохозяек со всего мира.

ПЦ Питону

Питону конец. PHP — рак, убивающий Python.

Питонисты не любят пхпшников. Вот, например, очередной наброс. Если кратко — глупые пыхари сначала выдумали идиотские урлы типа asdsdfg.php?adwq=q343&wewe=345&sweqwe=245 и до сих пор пытаются их исправить ужасным мод-рерайтом.

Другое дело питон — там демон, который ловит все запросы на одну точку входа и всем счастье. Вобщем, все php’шники, которые перешли на python и узнали, что многоэтажные рерайты не обязательны, до сих пор радуются этому и с ужасом вспоминают php, этот недоязык-шаблонизатор.

Конкретно на это можно ответить: эти идиотские урлы пошли не от PHP, а от CGI. И вообще, это специфика середины 90-х, когда люди только начинали нащупывать пути в веб-программировании. PHP не первый и не последний здесь. Те немногие, кто пытался в то время сунуться в веб с питоном, делали тоже самое.

Если бы Python вышел на широкую сцену вместе с PHP, он бы накопил lagacy-говна не меньше него.

Уже десяток лет, как все нормальные люди перехватывают все запросы на одну точку и обрабатывают их без всяких мод-рерайтов. В пыхе это стало мейнстримом, когда в питоне ещё не было ничего подобного стабильного и распространённого.

Но это всё присказка. Сказка в том, что несмотря на то, что в PHP есть множество способов делать всё по человечески, огромный процент «программистов» делает всё через жопу. Они варятся в своём отдельном дерьме и ничего не хотят знать о том, что можно делать иначе.

И вот теперь все эти люди ломанулись в Python! Раньше PHP ставили в вину то, что у него слишком низкий порог входа, слишком просто получить первый результат, он слишком распространён на говнохостингах и всё это способствует бесконечной генерации дерьма.

А теперь питон всё проще и, что важно, всё моднее. Всё больше фреймворков, всё легче запустить свой хелло-ворд, всё больше поддержки на хостингах, всё больше книг «питон для чайников». Всё больше только что перешедших туда пхпшников, которые уже поучают других на форумах. Они все идут к вам, питонисты! Горе вам.

Любой колхозник понаехавший из Мухосранска в крупный центр, начинает всеми силами изображать из себя коренного жителя, интеллигента и глубоко презирать своих вчерашних односельчан. Любой пхп-говнокодер, написавший две строчки на питоне начинает презирать других пхп-говнокодеров.

Эти люди все эти годы писали трёхэтажные мод-рерайты, не знали ничего о шаблонизаторах, роутинге и вообще ООП не использовали, потому что «классы едят память». У них не было никакого желания высунуться из своего ушата и посмотреть, как другие используют тот же PHP.

И что, Python что-то изменит в них? Сделает их программистами из ничего? Привьёт желание учиться и развиваться? Да, в питоне намного меньше способов случайно отстрелить себе яйца. Но они будут отстреливать их совершенно целенаправленно. И получать от этого удовольствие.

Легко с небольшой группой умных сподвижников разрабатывать элитарный язык с продуманным дизайном. На нём особо ничего крупного и сложного не сделаешь, но зато он идеален и сферичен в вакууме.

Но если он становится популярен, то начинают набегать толпы со стороны. Одни хотят одного, другие другого. Одни хотят в одну сторону развивать, другие в другую. В PHP это было почти с самого начала его истории, вот таким тяни-толкаем и вышел. Python сумел тихонько протянуть на десяток лет подольше.

А рядом уже притаились орды говнокодеров. Они заговнокодят всё что угодно, каким бы продуманным и идеальным это не было изначально. Они зальют ваши гитхабы, пипы и форумы своим гноем. Может пых теперь чуть-чуть от них отдохнёт.

Пиздец Питону…

[без названия]

Задолбали умники со своим «вы ввели некорректный email».

Вот это корректный email: one+two@example.loc
И вот это корректный email: one.two@example.loc
И вот это: one.two@127.0.0.1

А вот регулярка для проверки ёмайла: /^[^@]+@.+$/s или, что тоже самое: /@/. Или ещё лучше: /^.*$/.

Константы, строки и ключи

Давайте тестанём не предмет скорости ещё какую-нибудь чепуху.

Вот, допустим, константы. Одно из применений констант, это обозначение «магических» чисел. Например:

class Compressor
{
    const GZIP = 1;
    const BZIP = 2;
    const RAR = 3;
    const HUERAR = 4;
 
    public function compress($str, $type)
    {
        // ...
    }
}

То есть у нас есть некое множество значений (типов сжатия) и для обозначения каждого мы придумываем от балды какое-то число. А, чтобы с числами не запутаться, придумываем поверх него константу. И используем:

$compressed = $compressor->compress($plain, Compressor::GZIP);

С незапамятных пор так ведётся. Ещё Страуструп молодым был.

Однако, иногда посещает мысль, что PHP, это не Си и со строками он работает намного веселее. И почему бы не написать крамольное:

$compressed = $compressor->compress($plain, 'gzip');

Остальной текст под катом

go\Request: доступ к данным запроса (PHP)

В рамках цикла «изобретение велосипедов» представляю релиз-кандидат библиотечки go\Request.

Библиотека осуществляет доступ к параметрам с которыми вызван наш сценарий: GET/POST-данные, куки, переменные окружения, заголовки запроса, настройки сервера и клиента, аргументы и опции командной строки и тому подобное.
Остальной текст под катом

Подключаем классы разным макаром (PHP)

Что-то давненько мы здесь не занимались глупостями.

Сегодня мы будем проводить тесты со всеми возможными нарушениями их чистоты и нагло манипулировать статистикой.

Вопрос: как правильно подключать в своём проекте классы, чтобы при этом сэкономить время на их подключение.

Варианты:

  • Старый добрый autoload(), как у всех нормальных людей.
  • Взять и собрать все классы в один файл, как многие учат.
  • Подключать нужные классы явно через require_once().
  • И новомодная штучка: Phar-архив.
  • Phar-архив ещё можно делать не простой, а со сжатием (GZ или BZ2).
  • Ну и phar’ом также два варианта: autoload() или прямое подключение вложенных файлов.
  • И поверх этого можно акселератором каким-нибудь пошаманить.

Остальной текст под катом

5.5

PHP 5.5 тут на днях вышел.

Генераторов понапихали, нескалярных ключей и всего такого прочего. Вобщем всё как у людей, кажется, скоро будет.

Но нет, никак до конца нормально сделать не могут. Хопа — расширение для хэширования паролей.

5 лет как уже пространства имён. Классы как уже 15. Генераторы теперь. Но всё равно нужно забить глобальное пространство хламом из функций и констант с префиксами. PASSWORD_BCRYPT, оспадепомилуй.

Git, mysql, бэкапы и очумелые ручки

Что-то давно мы тут не изобретали бессмысленных велосипедов.

Итак, ситуация: есть сервачок, на нём крутятся десяток сайтиков средней отстойности. Их базы данных весят в районе нескольких мегабайт и не слишком быстро наполняются.

Хотя сайтики и так себе, но потерять данные и разбираться с их заказчиками всё равно не хотелось бы. Поэтому нужно делать резервные копии.

Ничего из файловой системы сохранять не надо, базы небольшие, ставить и настраивать навороченные системы бэкапов лениво, а руки чешутся сделать что-нибудь бессмысленное и беспощадное. Ну так возьмём и сделаем это.
Остальной текст под катом

По страницам: 123456789101112131415