Пользователь
0,0
рейтинг
25 августа 2008 в 14:45

Разработка → Ошибки начинающих PHP разработчиков

PHP*
25 PHP
Подборочка ошибок начинающих PHP разработчиков…

  1. Книга по PHP за 2002 год как источник знаний — это уже история, советую «PHP 5. Профессиональное программирование» — Э. Гутманс, С. Баккен — ISBN:5-93286-083-9, иль даже поновее...
  2. Использование web-сервера, где «всё включено» (Denwer и еже с ним) — научитесь сетапить сами, потом успеете перейти на полуфабрикаты
  3. Используем простенький редактор с подсветкой синтаксиса — пора взрослеть и переходить на IDE — с IDE увеличивается скорость разработки, особенно в больших проектах, где не один десяток классов.
  4. В php.ini включен параметр register_globals — отключаем это ЗЛО, по умолчанию отключен, но Вам он зачем-то понадобился
  5. Реализация «index.php» содержащая приблизительно следующий код: <?php require_once $_GET['mod']; ?> — это уязвимость, зовется PHP инъекцией — всегда проверяйте входные данные.
  6. Реализация авторизации, когда строка запроса к БД содержит что-то типа: «SELECT * FROM users WHERE login=».$_GET['login']." AND password=".$_GET['password'] — читаем что такое SQL инъекции (это относится ко всем входным данным и SQL запросам)
  7. Доверяем POST переменным больше чем GET? — Будьте уверены подделать так же легко, так что проверяем
  8. AJAX это хорошо, дырявый AJAX — плохо — не забывай проверять права доступа для функций вызываемых в AJAX'е
  9. Не проверяем залитые пользователями файлы — теперь и мы знаем что такое PHP Backdoor
  10. Присваивание в условии: <?php if ($auth = DEFINE_NAME) {… } ?> такую ошибку Вы будете долго искать — старайтесь избегать подобных конструкций (используйте конструкцию ввида <?php if (DEFINE_NAME == $auth) {… } ?> — если пропустите один знак «равно» — интерпретатор выдаст ошибку)
  11. «Cannot send session cookie — headers already sent by… » — пытаемся установить куки, когда заголовок уж послан браузеру — незаметили пустую строку или пробел перед первым тегом <?
  12. Переписываем функции PHP — воспользуйтесь поиском по manual'y
  13. Выражение <?php if (array_search('needle', $array) != FALSE) {...} ?> — не сработает если искомый элемент доступен по ключу 0 либо "" — читаем внимательней manual по каждой функции
  14. Работаем под windows, хостинг на linux и сайт не поднимается — имя файла index.php, Index.php, INDEX.php и т.д. это все разные файлы для linux систем, а мы про это забыли
  15. Отключение вывода ошибок — код должен быть чистым  — так что error_reporting(E_ALL) Вам в помощь, следите даже за Notic'ами
  16. Залив проект на хостинг — отключите вывод ошибок на экран — логируйте их в файл — не будете краснеть потом
  17. PHP файлы имеют не стандартное расширение (к примеру .inc вместо .php) — если не защитить такие файлы, то может быть очень стыдно
  18. В рассчете на short_tags, поленились писать польностью <?php… ?> — теперь на новом хостинге переписываем шаблоны
  19. Понадеялись на magic_quotes, теперь наше приложение надежно как швейцарский… сыр
  20. Соблюдай стандарты кодирования и пиши комментарии к коду — твои последователи скажут спасибо
  21. Не пиши маты в сообщениях об ошибках и комментариях — заказчик может просматривать и тогда прийдется долго оправдываться
  22. Читают статью http://php.spb.ru/php/speed.html и думают, что только так можно/нужно оптимизировать код — это «блошиная» оптимизация относится к PHP3
  23. Реализуем функционал БД средствами PHP — array_search вместо WHERE, ну и другие чудеса незнания SQL
  24. Стучимся к БД в рекурсии — стараемся обходить подобные реализации
  25. Не нужно забивать гвозди пасатижами — «Мне надо реализовать гостевую книгу — возьму-ка я свой любимый набор библиотек на 6 мегабайт»
  26. Узнали Smarty, и теперь уверены, что научились разделять логику и отображение
  27. Проверяем ВСЕ входные данные, XSS уязвимости нам не нужны


Если есть что добавить — пишем в комментариях…

P.S. Изначально было перечислено 25 ошибок, оттель и картинка такая…
Антон Шевчук @AntonShevchuk
карма
490,9
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (230)

  • –2
    еще «file.php.gif» на некоторых хостингах выполняется как php файл,… или это к 9-му относится..)
    • 0
      Такая контрукция работает только в том случае, если в настройка веб-сервера не прописан MIME-тип для расширения .gif — в таком случае он посмотрит на то, что стоит перед этим расширением и обработает как php-скрипт.

      Отсюда следствие — при проверке имен загружаемых файлов использовать не логику «это нельзя, а остальное можно», а «это можно, остальное — нельзя». В таком намного меньше спорных вопросов, и ситуация из абзаца выше не произойдет.
  • +27
    «Ежегодный топ-25 ошибок PHP программистов».
    • –4
      В точку. Более того, ошибка номер один большинства похапистов — стремление к изобретению велосипеди и нежелание использовать уже готовые фреймворки.

      Радует только, что большинство ньюбов в веб-программировании начинают свой путь с ПХП. И этот язык выступает неким буфером для Руби и Питона, защищая их от неопытных ручек. Но это временно, к сожалению.
      • 0
        Вы начали с руби и питона? Сразу? В 16 лет? Памятник вам.
        • –3
          Я начал с ПХП в 14, если вам интересно. Сейчас мне 21 и я Rails-разработчик. На самом деле начать с Руби ничуть не сложнее, как показывает опыт моих товарищей. Так что не надо.
          • 0
            Если «Так что не надо», так зачем тогда наезжать на ПХП-разработчиков?
            • +2
              как это зачем?! потому что «Сейчас мне 21 и я Rails-разработчик» :)
            • +1
              Я не наезжаю на ПХП-разработчиков, я наезжаю на ПХП. Я сам был ПХП-разработчиков, плюс я знаю много хороших программистов, которые сейчас используют ПХП в качестве основного языка. Хотя наезжать на ПХП, конечно, очень неблагодарное занятие на Хабре ) Простите, если кого обидел.

              Идея моего комментария заключалась в том, что сейчас большинство начинающих веб-разработчиков стартуют с изучения ПХП. Вскоре, на мой взгляд, эта ситуация изменится и многие будут начинать с Руби (Rails) и Питона (Django). Это, скорее всего, негативно скажется на качестве кода, написанном на этих языках.
        • +1
          Гхм * аж подавился *. Слушайте, а раньше не было никакого php и впомине, был с и lisp и ниче, все живы.
          • 0
            Это мне ответ?
        • 0
          С руби начинать существенно проще и стократно приятнее. С питона — где-то в промежутке между пхп и руби :), но тоже всяко приятнее.
          Уеб разработку я начинал с перла и даже он лучше пхп. В мои 16 лет уеба небыло, тогда я знал калькулятор Б3-34, алгол-60, паскаль, фортран, рапиру и бейсик.
          Вы предлагаете ставить всем неупёртым и всем нелентяям? Так ведь памятников не хватит.
      • +1
        вы разрабатываете Руби и Питон? по-моему нет! так что их никто не защитил от «неопытных ручёнок»
        • 0
          Не очень понял ваш комментарий, простите.
          • +1
            И этот язык выступает неким буфером для Руби и Питона, защищая их от неопытных ручек
            как я понимаю ИХ — это питон и руби. Ну какая вам разница кто на них пишет!? Вы же не являетесь разработчиком этих языком…
            • –4
              любому человеку, считающему себя профессионалом, неприятно, что его инструментом пользуются толпы нубов.
              • +1
                Любому человеку приятно, что его инструментом пользуются.
                • –2
                  Ничего подобного. Если я придумал отвертку и вижу, как кто-то забивает ей гвозди, мне станет омерзительно.
                  • +1
                    А я просто постараюсь объяснить, как ей правильно пользоваться.
      • 0
        Изобретение велосипедов заставляет думать и развивает думалку. Если есть свободное время и вдохновение — почему бы не поизобретать? :)
  • +2
    Очень полезно, для начинающих!
    Вот ещё советы:
    1) Если что-то можно сделать без regexp, делайте это без regexp.
    2) При использовании file_put_contents удалите файл, если он существует.
    • +4
      > 2) При использовании file_put_contents удалите файл, если он существует.
      А зачем?
      • +5
        Если файл существует, то при записи file_put_contents работает в 4 раза медленне чем

        if(is_writable($file)){
            unlink($file);
            }
        file_put_contents($file,$content);

        не знаю почему.
        • 0
          А как на счет
          $fh= fopen ($file, «w»);
          fwrite ($fh, $string);
          fclose($fh);

          С какой скоростью будет работать такая конструкция?
          • 0
            file_put_contents
            This function is identical to calling fopen(), fwrite() and fclose() successively to write data to a file.

            Хотя, вроде как работает быстрее: habrahabr.ru/blogs/php/20784/
          • 0
            забыли дописать flock(...) для КОРРЕКТНОЙ работы!!!

            p.s.: ох уж эти пионЭры ))))
            • 0
              Ничего, главное учится на комментах хабра, а не во время увольнения за найденные ошибки в коде :)
        • 0
          это из-за блокировок. unlink не спасёт от совместной записи.
          • 0
            Вы хотите сказать, что если я сначала удалю файл, а затем его запишу с помощью file_put_contents, то возможна совместная запись, а если, просто вызову file_put_contents — нет.
            Я чего-то не понял…
            • 0
              ээээээ, согласен, немного не понятно выразился.
              допустим есть скрипт счётчика на файлах, для этого
              берём файл, лочим его, считываем информацию, заменяем её новым значение и записываем.
              в итоге мы работаем с актуальными данными, а следующий запрос ждёт пока первый запрос отпустит файл и только после этого получает возможность считывать информацию. а так на этапе чтение — запись, информация полученная во время чтения может быть неактуальной. проверено на горькой практике.
    • +6
      Если что-то можно сделать без regexp, делайте это без regexp.

      Но если для замены регекспа нужно написать 5+ строк — используйте все-таки регексп.

      Если важна скорость — не верьте советам, верьте профайлеру.
      • 0
        писал и 100 строк, скорость очень заметно возрасла.
        • 0
          И я писал, и что с того? Не везде регекспы применимы, только и всего. Кстати что у вас за задача была?
          • 0
            Маленький компилятор для BB тагов, с исправлением ошибок структуры.
    • 0
      А чем вам так regexp не нравятся?
      • +5
        думаю, оратор имел ввиду всего лишь правило «используйте substr и str_replace вместо регулярок там, где это возможно»
      • 0
        Я люблю его, но для простых задач, проще и быстрее сделать strpos, substr и str_ replace, как уже и сказал dasbot.
        Раз, а два иногда полезно комбинировать regexp и strpos. Я так в одном парсере в два раза производительность увеличил, просто за счёт того, что разбил регулярку на части.
        • 0
          Используете неправильный движок регулярных выражений.

          Обычные движки (те, которые с backtracking), можно уложить с помощью сравнительно простого выражения, а вот с реализациями, использующими tagged DFA, к примеру, так сделать не удастся.

          Что же касается парсеров, то надо бы разделять собственно лексический и синтаксический анализ. (Вы, наверное, о первом говорите)
          • 0
            Нет я писал синтаксический анализатор для XML идентичный по функционалу xml_parser с возможностью использовать дополнительный вид тегов.
            Про движки расскажите по подробнее, вы имеете в виду preg и grep?
          • 0
            Про движки уже почитал чуть-чуть. Стало понятней. Есть ли расширение для PHP использующее алгоритм DFA?
            • 0
              По-моему, нету. Вообще, почти все AFAIK пользуются PCRE и подобными, т.е. backtracking. (включая runtime Java, Ruby, Tcl, Perl).

              Помню, DFA-движок был в Boost, и еще где-то. Блин, не могу найти :(
            • 0
              Вот, нашел на LtU: lambda-the-ultimate.org/node/2064
              • 0
                Не могу найти там расширения (
    • +1
      А меня работодатели послали с тестовым заданием — ибо Шаблоны были сделаны с помощью str_replace вместо preg_replace ;)
      • 0
        Ну это уже как повезёт! ;)
        Можно из этого вывести совет не только новичкам: в комментариях к тестовым заданиям старайтесь указывать что и почему вы делаете и, что вы прекрасно знаете, что можно и по-другому, либо не знаете, но молчите ;)
      • 0
        ну и нафик таких работодателей, которые не хотят оптимизированного и рационального кода. сам же потом намучался бы с ними.
  • 0
    Очень полезные советы. Но небольшая аргументации каждого не помешала бы.
    • +3
      +1
      А чо минусуем? Хабр умер? Все все уже давно знают? Может лучше 27 фотографий сисек надо было выложить?
      • 0
        Ну если бы это были какие-то особые сиськи то было бы лучше выложить фотографии 27ми сисек… Но даже сиськам аргументация в общем то была бы лишней…
        • 0
          как можно аргументировать сиськи?
      • 0
        Но ты прав — минусовать больше -5 тут не правильно… Поставил +1
    • +1
      Согласен. Хоть мне и кому-то еще это и так все понятно, новчикам от такой информации будет ни холодно, ни жарко. Голословные факты, практически никаких аргументов. В результате и получается «кто-то умный когда-то сказал делать так, я теперь так и делаю».
  • 0
    Вот про 22 полностью согласен. Даже тут на Хабре не раз уже появлялись топики на тему такой «оптимизации». В 99% случаев это бесполезная трата времени.
    А вот с 2-м пунктом я бы поспорил. В серьезных проектах вам никто и никогда не даст настраивать среду исполнения — для этого есть админы. Это не значит, что вы не должны знать стандартные настройки (те же многострадальные глобалсы), однако уметь это все ставить и грамотно настраивать — не обязательный навык. Разработка в Денвере вполне неплоха, и, я бы сказал, рекомендована (если у вас нет тестового сервера конечно), если вы пишете «сайт фирмы» или что-то подобное.
    • +2
      Денвер не Денвер но знать как минимально настроить Апач, Мускул, ПХП, где и как-что прикрутить, где может быть ошибка и т.д. — знать нужно. Даже для того что-бы написать у себя проверку на те же magic_quotes и в зависимости от этого параметра самому делать или нет с данными.
      • +1
        не надо их проверять, их надо с самого начала отключать :)
        • +1
          это у себя их можно отключать, а вдруг где-то включено? нужно это проверить и правильно среагировать. не все же хостинги одинаковы, и писать под какой-то один также не нужно. а то вдруг клиент переедет а у него что-то отвалится… кто виноват? хостинг или разработчик?
          • 0
            Если придерживаться правил безопасности и «правильности» кода, то скрипт будет работать везде. Разработчик будет виноват, в большинстве случаев.
      • 0
        Знать — нужно. Я так и написал. Но не использовать Денвер нелогично. Он идеально подходит, когда вам надо за вечер слабать сайт-визитку, а среды на компе почему-то нет. Вобщем, как и всегда, все зависит от условий.
        • 0
          Ну да, где-то так, просто если нужно что-то «слабать», а значит вы уже «лабаете» то среда должна уже быть настроена и готова. это много времени никогда не занимает. Но это мое мнение.
        • 0
          А чо бы сайт-визитку не «слабать» на движке?
      • +2
        Тут же советы для начинающих разработчиков. А теперь представьте, что начинающему разработчику нужно ставить непонятные программы, открывать какие-то текстовые файлы, рыться в дебрях настроек и что-то в них делать, плясать с бубном, ради того чтоб запустить <? php echo «Hello world» ?>. Постигание php.ini приходит со временем, вначале лучше полностью доверится Денверу, чтоб все эти шаманские танцы не отбили охоту к РНР вообще.
        • 0
          Полностью согласен, тоже думаю что для начала Денвер самое хорошее решение. Сложно настраивать что-то, когда непонятно как это должно выглядеть, как проверять, и как искать ошибки в конфигурации. Когда уже понимаешь как что работает, что за что отвечает — можно настроить и свою среду.
          Прошёл этап Денвера, благодарен его разработчикам — это действительно Quick Start для windows. Получить работающую LAMP можно просто и без денвера)
    • 0
      про денвер в точку.
      основная проблема, что некоторые пытаются стать админами и больше времени тратян на установку php, чем на изучение самого языка.
      кстати, у меня под linux уже давно настроен почтовыйсервер, а под винду запускаю денвер для проверки mail()
      • 0
        Когда я впервые знакомился с php, на нахождение инфы по установке mysql + apache + php, да и собственно установки под окошки — у меня ушло не более 2-х часов. А это был где-то 2004-й год наверное. Поставить два приложения, распаковать архив, и скопипастить около 5 строчек из мануала — для этого не надо быть админами. Но зато это дает человеку, уже на первых порах понимание того, что пых — это не только модуль для апача — вебсервер одно, интерпретатор — совсем другое, и что в качестве бд может быть что-то другое кроме мускуля.

        А то общался я с одним человеком, который все время денвер использовал. Когда ему сказали, что работает все через nginx + php-factcgi и в качестве базы постгрескуль — он выкатил глаза и начал мямлить про то, что «неужели так бывает», «там наверное програмировать надо по другому».

        Основы надо понимать, хотя бы на базовом уровне. Основы веб програмирования — это вебсервер и хттп протокол.
        • 0
          помнится, у меня возникла проблема с расширениями, как потом догадался, нужно было прописать path в винде, хотя до сих пор не в одной литературе этого пункта не видел. дале, проблему с мылом до сих пор не решил, но и не очень-то хотел.
          конечно, знания об настройке не повредят, но на первом этапе есть вещи гораздо более важные и желательно сконцентрироваться на них, а то получаем гавнокод, зато от сисадминов.
          случай забавный, но здесь непричём, любой программист которому нужен nginx знает о нём, так как пора пришла, а вот внаале от этого ему не тепло не холодно
          • 0
            Если уделять програменгу в день чуть больше часа, и при этом 40 минут каждый раз копатся в настройках сервера — то да, это не очень хорошо. Но что-то я не припомню ни одного случая, когда после настройки мне, да и еще многим людям приходилось каждый день лазять в конфиги и править их. Только раз в полгода, и то что бы добавить еще один экстеншн который понадобился, но по незнанию был закоменчен.
  • +8
    Как говорится есть одно хорошее правило: Никому не доверять, ни пользователю (проверять от него все данные) ни себе (проверять вообще все данные которыми оперируеш). Одним словом — проверять всё!
    • +6
      либо писать так, чтоб ошибки просто не могло возникнуть.
      Простое правило, которое может здорово облегчить жизнь — используйте приведение типов.
      «SELECT * FROM table WHERE id='.(int) $var — спасет независимо от того, что вы умудрились положить в var.
      Это не избавляет от необходимости думать, но это надежный последний рубеж.
      • 0
        А если это не ИД, а, скажем, статус записи. Если в концепции существует нулевой статус, то запрос потенциально фэйловый )

        ЗЫ: И, кстати, в таких вариантах лучше юзать sprintf и %u для формирования запросов )
        • 0
          Запрос может и фейловый, однако без стандартной уязвимости. Как я там уточнил — это не избавляет от необходимости думать.

          А насчет sprintf — это был просто пример приведения типов. Здесь может и лучше, в другом случае — нет. Например в foreach((array) $var as $item) {}.
        • +1
          Лучше вообще юзать bind-параметры
      • 0
        Думаю, что правильнее будет проверять и в случае не соответствия выдавать ошибку. В приведенном примере я бы использовал is_numeric().
  • +1
    requery_once — нет такой функции в этом языке ;)
    • +1
      Спс, исправил…
  • +5
    К слову о 17 правиле: janeyandryan.com/conf/db.conf
    • +1
      щас у человека всю базу просмотрят:)
      • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      А вот если запихивать весь инклуд код выше корня www как в ZF, можно забить на все эти защиты.
      • 0
        Не всегда есть возможность такое сделать, зато .htaccess с deny from all не позволит смотреть файлы в папках. Равно как и используемая в том-же DLE защита-

        if(! defined('DATALIFEENGINE'))
        {
        die(«Hacking attempt!»);
        }
        При просмотре файла напрямую, а не если он вызван инклудом из index.php- интерпритатор завершит работу. Кстати, такой способ защиты библиотек тоже стоит добавить в топик.
  • –6
    18 пункт — бред. <? php вобще кажется в PHP6 уберут
    а отключать <?… ?> — по крайней мере странно.
    у всех ведущих хостеров включена поддержка <?… ?>
    • +5
      ваши данные ошибочны с точностью до наоборот ;)
      • 0
        хм… если это так, хотелось бы пруфлинк.
        тогда соглашусь.

        тем более
        mcdb.habrahabr.ru/blog/19621/
        вот тут написано как раз о том, что я говорил
        • +1
          www.php.net/~derick/meeting-notes.html#remove-support-for-and-script-language-php-and-add-php-var

          Как и ожидалось, «<?» все-таки оставят в угоду конструкции «<?=» Но откуда вы взяли про удаление «<? php» (а именно это я имелл ввиду) не знаю.
          • +1
            хм… значит где-то что-то не то увидел.
            забираю свои слова обратно.
            перепугался наверна того что <?… ?> уберут, а <? php… ?> оставят :)
            • 0
              Уберут ASP-шный стиль, то есть <% %>. А полный и сокращенный останутся.
    • –4
      как раз сокращенный вариант уберут.
      А бред или нет, но отключают — это факт
      • 0
        можно привести пример реального хостинга, где отключают короткий вариант? ни разу не сталкивался.
    • 0
      Если обратиться к синтаксису XML, то <? php ?> — классическая Processing Instruction и убрать php нельзя.
  • –1
    К 24 пункту добавлю:
    не используйте алгоритмы типа:
    Sql запрос — Цикл по результатам с sql запросами (почитайте в таком случае про JOIN, LEFT JOIN и т.п. )
    Старайтесь использовать как можно меньше запросов к базе, напишите один большой запрос заместо нескольких небольших.

    К 25 и 26 пункту добавлю:
    Старайтесь как можно реже использовать смарти, от него очень много тормазов, и он хавает память.
    • +4
      нет, нет и нет. Уж извините.

      Запросы ОЧЕНЬ зависят от ситуации. Есть конторы, где вообще запрещено использовать джоины (SpyLog меня когда-то этим удивил). Иногда действительно лучше разделить запрос на два и более, а связать уже в коде. Однако, повторюсь, это очень обширный вопрос.

      Про смарти вспоминается фраза «вы просто не умеет их готовить». Заметьте, я не сторонник смарти, и даже кое в чем противник. Но тем не менее с вашей формулировкой я не согласен.
    • 0
      вообще сам мускл в своем тренинге советую использовать запросы поменьше чем побольше ;)
    • 0
      По поводу SQL и благах JOIN-ов

      Например у нас, есть таблицы, которые большие, туда постояно пищут, оттуда постоянно читают, причем не только фронтенд-часть но и бэкенд.

      Таким образом если мы приджоиним огромную таблицу с очень важной, причем еще с каким-нить хитрым условием-выборкой (по которым нет нормальных ключей) — мы надолго залочим важную таблицу.

      Вобщем пришлось вместо пары join-ов на 3 таблички писать рнр-код экрана на 3.

      Но не исключаю что подобные моменты — скорее для тех кто уже выходит из разряда начинающих.

      Кстати как совет — используйте EXPLAIN для анализа вашего запроса и ключей.

      А так — статья очень полезная, особенно для начинающих.
  • +2
    Браво! Отличный текст. Всем новичкам приколотить гвоздями к стенке :)
    • +1
      Лучше сразу в мозг
  • +3
    Результаты этого запроса просто поразили:

    очень стыдно
    • 0
      Ктото видать нашел уже janeyandryan.com/conf/auth.inc судя по тайтлу — «SERYOGA NADO BOL'WE SPAT' PO NOCHAM!»
      Сайт какой-то японской пары.
    • 0
      и даже так
  • 0
    можно по пункту 26 поподробнее?
    • 0
      Имеется ввиду — если юзаю смарти, то значит могу запихнуть в него всё что он позволяет — слишком часто сталкивался с реализацией логики в шаблонах — такие перлы очень тяжело исправлять…
  • +1
    страно, в статье ни слова о XSS и XSRF/CSRF, однако это самые популярные уязвимости многих сайтов
    • 0
      ну это, имхо, выходит за рамки статьи для начинающих.
      • 0
        уж лучше про это узнать на этапе разработки, а не когда похакают :)
    • 0
      Добавил 27-ой пункт
  • +3
    n.10 избежать можно используя след. стиль <? if ( true = $auth) {...} ?> Этот код уже выдаст ошибку.
    • 0
      пример добавлен…
    • 0
      Да и вообще, это стандартная семантическая ошибка, и не только в php.
    • +3
      А я, например, постоянно спотыкаюсь на таких кусках кода. Как-то логично, когда «что-то неизвестное» сравнивают с чем-то конкретным. А когда сравнение начинается с чего-то конкретного, у меня взгляд при чтении когда просто спотыкается — чего сравнивать, мы уже знаем, что это?..
      При том, что я уже и не помню, когда я наступал на саму багу присваивания в сравнении.
      Да и отлавливается быстро, на самом-то деле.
      • 0
        Ну для начинающего — наверняка совет хороший
        • +1
          С одной стороны — да, конечно. Нечаянных ошибок будет меньше.
          С другой (и я, наверное, именно об этом) — не будет ли это медвежьей услугой? Как там Дейкстра писал про студентов, «умственно оболваненных Бейсиком»…
          То есть вместо развития у себя каких-то качеств, общеприменимых для программирования вообще (внимательность, определенный стиль мышления, определенный стиль выявления ошибок — тоже немаловажно), мы привыкаем к разным узкоспециализированным грязным хакам.
    • 0
      А может не стоит приводить пример с bool? Ведь пример наталкивает на индийский код, в таких ситуациях принято кратко писать «if ($auth)...»
      В топике можно написать что-то цифровое, например «if (2 == $usertype)»
    • 0
      Многие, включая меня, считают это плохим стилем. Лучше приучать себя к внимательности, чем писать так, ведь такая конструкция хуже читается и слегка нелогична (это неплохо обосновано в соседних комментариях)
      • 0
        Согласен, но я не говорил, что стиль хороший. Я просто показал как можно. Сам никогда не использую такой прием, просто хотя бы потому, что нарушается читабельность.
  • +3
    11. тут чаще проблема в пробеле после закрывающего тега в подключаемом файле. Именно поэтому хорошей практикой является опускать закрывающий тег, если в файле только PHP код.

    18. ну не стоило бы относить это к ошибкам. Это скорее как напоминание, в случае, если на хостинге показывается код, а не собранный HTML. Да и конструкция <?= $title ?> выглядит вкуснее :)

    25. ну и что что 6Мб? пусть даже 100Мб — подключать всю библиотеку Вас никто не заставляет :) Я в простейших консольных скриптах не брезгую использовать Zend_Console_Getopt, и Вы врядли меня аргументированно разубедите это делать, несмотря на то, что весь ZF весит 13Мб :)
    • 0
      11. Если там все же не только PHP код, то данный пункт вообще не имеет смысла
  • 0
    Про 4 и 19. У Хостера «Спейсвеб», по умолчанию включены register_globals, magic_quotes и еще некоторые интересные опции. При смене хостинга, лучше сразу проверить, какие опции включены.
    • 0
      Правильно!, еще никто не отменял get_magic_quotes_gpc() и get_magic_quotes_runtime()
  • +3
    )) особенно порадовал федеральный образовательный портал:
    www.edu.ru/vuz/list/1827/
  • 0
    пункт 1. php 5 в 2002 году не было вовсе, равно как и книжки по оному)
    вероятно, имелся в виду
    www.ozon.ru/context/detail/id/2612430/
    • 0
      сорри, плохо читаю под конец дня
    • 0
      имхо, вот чувак лучше бы смотрелся с велосипедом, нежели с роликами:))
  • +1
    По моему, написано очень не показательно для новичков, которые вроде бы являются целевой аудиторией.
    Я бы не смог понять, нарушает ли мой проект какой-либо из пунктов, прочитав его формулировку. Ссылки на внешние статьи о терминах и примеры помогают разобраться, но остальные пункты остаются туманными. Есть упоминание проблемы, но нет четкого описания где-что искать и как бороться.
    Имхо, стоит переписать текст ориентируясь на лентяев и неофитов.
    • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    а мелочь на картинке — гонорар начинающего PHP разработчика, допускающего перечисленные ошибки )
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      И Вам с Вашей кармой еще и не лень ждать по 5 минут между каментами и продолжать медленно, но уверенно спускаться вниз? :)
      • –1
        Тролль, хуле.
        • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Что-то в этом есть, но это можно лечить если с молодосить приучать их к прекрасному… к Symfony, Zend, Cake, а не читать говнокод любительских CMS и писать по аналогии.
      • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    для себя ввел правило, по мере написания правила сразу же думаю, что можно сделать с функцией, методом и т.д., сразу продумываю все возможные уязвимости

    после написания искать дыры будет сложней, лучше все делать сразу
  • 0
    Почитал и решил пересобрать свой «сервер» как в старые добрые времена… XAMPP под win надоел.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    # Используем простенький редактор с подсветкой синтаксиса — пора взрослеть и переходить на IDE — с IDE увеличивается скорость разработки, особенно в больших проектах, где не один десяток классов.

    Так пора взрослеть или же «Ошибки НАЧИНАЮЩИХ PHP разработчиков»?
    • 0
      Статья о том, как начинающим пора взрослеть :)
      Думаю, что после осознания и использования данных советов разработчик уже будет не совсем начинающим.
      • 0
        Порог вхождения в программирование на php очень низкий, достаточно разобрать несколько типичных примеров, чтобы уже почувствовать себя пхпшником. Как же ошибочно это ощущение :)
  • +1
    Какие-то стремные ошибки.

    Я понимаю написать ошибки, которые трудно искать или ошибки логики…
    [code]«Cannot send session cookie — headers already sent by… „ — пытаемся установить куки, когда заголовок уж послан браузеру — незаметили пустую строку или пробел перед первым тегом <?[/code]
    Во первых в ошибке пишется где вывод начался, во вторых причиной может быть и не пробел…

    И на последок это все хорошо, но опыт показывает что свои грабли бьют гораздо сильнее.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Вообще XSS — это скорее про то, как ВЫводить данные…
      • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      О, я помню видел такую фантастическую прелесть :) Массив экранируется через array_map('addslashes', $_POST) и записывается в самого себя… и делается это все на уровне конструктора подключаемых модулей :)
      А что самое интересное — модулей на страницу подключается от 1 до 7 штук, итого с учетом отсутствия проверки на magic_quotes к каждой кавычке введенной в поле ввода добавлялось от 3 до 15 слешей :) К трем слешам я еще отнесся с мужеством, а 15 меня реально напугали :)
    • 0
      Может есть смысл в таких случаях взять парсер от готового и проверенного временем движка? В последних версиях учтены и искорены и SQL-инъекции и XSS. Из платных запрещает брать авторское право, а вот из опен-сорсных можно.
  • 0
    Советую также как источник знаний Шлосснейгла:
    www.ozon.ru/context/detail/id/2527057/
  • +1
    > 2. Использование web-сервера, где «всё включено» (Denwer и еже с ним) — научитесь сетапить сами, потом успеете перейти на полуфабрикаты
    Несколько спорно… Он еще кодировать не научился, а тут ему предлагают учиться настраивать апач, рнр и проч.
    Все это надо, но не убьет ли интерес ко всему остальному? Научиться писать для готовой к употреблению, удобной среды — весьма хорошо.

    Я уже где-то приводил пример с авто по другой теме.
    Было бы странно новичка автолюбителя заставлять разбираться в устройстве двигателя. Он все-таки хочет научиться ездить, умение ремонтировать и тюнинговать придет потом — с опытом.
    • +2
      Не согласен. Программист, даже начинающий, не пользователь, а инженер.
      • 0
        Да что же вы к мелочам придираетесь :)
        Научится он. научится, но постепенно.
        Новичок он на то и новичок, что сразу охватить сложность проблемы не может сразу, не может он и отвлекаться на смежные темы.

        Но опять же — я не сказал, что неверное это утверждение. Я сказал — оно спорно.
    • 0
      Когда я начинал программировать я не знал как установить php, что это такое, с чем его едят, какое отношение к этому имеет apache и уж тем более какой-то там mysql, месяца два я изучал тему, потому что в компе шарил плохо. Теперь я каждый раз собираю php+apache+mysql ручками, матерюсь, но ставлю. И не заставить меня ставить их из пакета…
  • +2
    Я бы даже сказал, не «error_reporting(E_ALL)», а «error_reporting(E_ALL|E_STRICT)».
  • 0
    Еще совет. Старайтесь все же разделять логику и разметку. Упростите жизнь верстальщику, да и себе пожалуй. Например, так:

    if ($a===$b)
    {
    ?>
    Равны
  • +3
    Что-то не пойму, это ошибки или советы? :)
  • 0
    Что-то не пойму, это ошибки или советы? :)
  • 0
    ++
    -Используйте гугл, даже если уверены что такого еще никто не писал, даже если считаете что вы всегда напишете понятней и проще.
    -Вытекает из первого, используйте фреймворки и либы, лучше качественные и проверенные, phpclasses зачастую не гуд. PECL, PEAR, ZF… Множество профи стараются чтоб Вам жилось проще!
    -Нет ничего более постоянного, чем временное. Пишите сразу максимально правильно, не подрывайте авторитет PHP!
  • 0
    Я бы добавил для начинающих:
    28. Начните писать свою CMS.
    29. Ничните писать свой фреймворк.
    • +2
      30.Начните писать свой стартап?)
    • 0
      глупость, гораздо умнее посмотреть на то, что уже есть. Это сразу прививает хороший стиль. Что за мания вечно изобретать велосипеды?
      ко мне приходили куча прогеров, которые писали что-то свое, многие на этом и застряли. Те, кто начал сразу смотреть в сторону прогрессивных решений в итоге, в большинстве случаев, уровнем выше и ЗП больше.
    • 0
      О да, примеры любительских CMS написанные новичками РНР многим в кошмарах снятся. Писать ля себя может и стоит, но выводить их в проекты и размещать в сети, а также предлагать друзьям и знакомым, то уж лучше не надо, не позорьтесь. Лучше посмотреть примеры готовых ХОРОШИХ CMS и фреймворков, только ознакомившись с логикой, узнав что такое MVC, ORM, FilterChain, да уже наконец и Singleton, тогда можно думать о своем фреймворке.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Быстро подправить — да.
      Эффективность IDE в полной мере раскрывается как раз на громоздких вещах. И да, с не одним десятком классов.
      Не вижу ничего зазорного в том, что среда разработки услужливо подскажет переменную в области видимости, автоматически завершит ввод функции PHP или функции, определенной вами и имеющей веселое camelCaseLike-название.
      Как минимум, сэкономится время и вероятность механической опечатки уменьшится.
      • 0
        Всякий autocomplete, и местами вполне разумный, есть во многих редакторах. Например, любимый мною jEdit это все умеет, но назвать его IDE — язык не повернется :)
        • 0
          Одно дело автокомплит стандартных функций, а вот автокомплит пользовательских классов, переменных, поддержка комментариев PHPDoc это совсем другое.
    • 0
      IDE нужно на ранней стадии для одного, интерпретация языка на лету. Если мы говорим о новичках, то они ещё не привыкли ставить $ и;, а в ошибках парсера ещё могут не разбираться и долго жать F5 чтоб узнать где же ошибка.
  • +1
    Никогда не понимал людей, которые так пишут:
    используйте конструкцию ввида <? php if (true == $auth) {… } ?>
    , это как раз и порождает ошибку написанную в п.10.
    Пишите лучше так: <? php if ($auth) {… } ?>
    • –2
      Если вместо true использовать константы — выражение приймет вид if(DEFINE_NAME == $var) {...} — так что упрощенный вариант не подойдет…
      • 0
        Что-то камент не туда пошел :)
    • 0
      Ну да, варианты if ($auth == true) и if ($auth) — равнозначны, и второй определенно лучше, если не забывать про разницу с if ($auth === true) :)
  • 0
    Простите, не удержался:))))
    • +1
      Я уже как-то говорил по этому поводу — низкий проходной уровень языка — это медаль с двумя сторонами — на РНР может писать всякий, и только каждый пятый пишет правильно…

      Возьмите для примера крупные проекты на PHP — Wikipedia, Facebook, Digg — тут уж не постебаешься…
      • 0
        Согласен.
      • 0
        Sourceforge
    • 0
      Да стеб забавный, где взял :)

      Тоже не мог удержатся
      А теперь просто личное мнение:
      проблеммы с xslt?
      Я знаю пару плюх, но какими-то мега проблеммами это не назовешь — все решаемо
      А зп — это вопрос квалификации и характера, а не языка программирования.
      • 0
        где взял уже увидел… леньс
      • +1
        проблеммы с xslt?

        Видимо, креатифф относится к временам присной памяти Sablotron'а :)
        • 0
          Саблотрон жив! ))
  • 0
    Какие IDE можете посоветовать для начинающих? Желательно бесплатные или полу-бесплатные.
    • +2
      Eclipse + PDT, Aptana, Netbeans кажется…
      • 0
        Netbeans в контексте PHP не совсем удобен. Основная его… гм… заточенность — под Java. Если не ошибаюсь.
        • 0
          Есть такое. Но они недавно соорудили плагин для php. Я правда не знаю в каком он состоянии.

          Кстати, возможно и Intelllij Idea умеет php, надо посмотреть в плагинах… Это самая офигенная среда разработки:)
          По крайней мере для явы:))
          • 0
            Я пробовал плагин netbeans — оставил гнетущее впечатление — вернулся в PDT иногда vim использую(но это не каждому новичку понравится :)) Реально eclipse PDT пока самый лучший выбор имхо… хотя видел некоторые ребята в nuSphere или как то так лабают — подходил тыцкал — с pdt не сравнить и под lin не идет :(
            • +1
              vim — кайф, но это как и emacs не среда разработки а редактор все же:)

              По поводу нетбинс — я его и для явы не особенно люблю, да.
              • 0
                Лучше таки обратить внимание на vim, при желании vim и emacs неплохие ide.
              • 0
                В сочетании с любым шеллом — это среда разработки.
                • 0
                  Дружно учим матчасть. Ставим эклипс, идею, мс вижуалстудию. Разбираемся, думаем.
                  • 0
                    бедный разработчики программ под *nix! Они до сих пор не знают, что shell + *nix tools + make + vi это, оказывается, не среда разработки!

                    Не говорите ерунды.
                    • +1
                      vi и vim — есть вещи разные
                      А по поводу ерунды почитайте allaboutvim.blogspot.com/2007/07/vim2ide-vim-ide-php.html
                      Меня подобный минимализм весьма устраивал в свое время, а в сочетнии с snippetsEmu project и прочими описанными плагинами в блогее — весьма недурственно получается. У нас просто так было проект унаследовали — разворачивать дома не было времени — открыли доступ по ssh — и лабали… я тогда человека три на vim и zsh подсадил… за 6 недель такой мегапроектище склепали… самому не верится — а вы говорите vim :)
                      • 0
                        Я же об этом и говорю (правда написал едко). Сам при разработке использую только vim в качестве редактора (и абсолютно не жалею, что не пользуюсь IDE, где суммарный размер панелек на экране превышает размер окна с кодом).
                        • +1
                          А тебе в голову не приходило что все эти панельки не для дураков сделаны, а для отображения информации которая может быть полезна во время написания кода?

                          А вообще мотивация совершенно бредовая.
                    • +2
                      Уважаемый, нормальные разработчики нормальных программ под *nix пользуются нормальными IDE. Времена, когда vim и emacs были безальтернативными решениями прошли. Я года четыре пользовался vim-ом в качестве среды разработки для С++, пока Eclipse не был доведен до ума. Ничуть об этом не жалею, но сейчас необходимости в этом нет, поскольку есть более лучшие решения.

                      Интересно кстати говоря, ты в разработке каких-нибудь крупных проектов участвовал? Где в команде работает скажем больше 10 человек? Слово рефакторинг тебе знакомо? Для навигации по коду понятное дело кроме ctags да grep ничего использовать не приходилось… Интеграция с дебаггером и профайлером тоже понятное дело для дураков придумана…

                      Вобщем, ставь какую-нибудь нормальную IDE, разбирайся читай мануалы и будет тебе счастье. Про понты тоже кстати советую забыть. Ничего крутого в том о чем ты выше написал нет. Гики пользуются не тем, что круто, а тем что может реально ускорить, упростить и улучшить процесс разработки:) Не думал кстати говоря, почему к эклипсу вим прикручивается? Наверное люди не от нечего делать этим занялись, а для того чтобы совместить мощность редактора и эффективность среды разработки?
                      • 0
                        Кстати, нормальной прикручивалки так и не нашел. Может поделишься?
                        • 0
                          К сожалению не поделюсь, поскольку я не занимался прикручиванием vim-а к эклипсу. На eclim смотрел как-то, но меня редактор эклипса вобщем-то устроил, я на нем и остановился.
                • +3
                  В данном контексте слово «среда» употребляется как синоним слова «окружение» (каковое является калькой с английского «environment»).
                  Но vim наверняка (насчёт emacs не уверен, ибо elisp (правильно?)) не является IDE. Почему? Да потому, что он парсит ваш исходник регэкспами и тупо подсвечивает зарезервированные слова. Не больше. Иными словами, редактор не знает, что слово FreeTypeLoader является именем класса, а слово new не просто зарезервированное — после него в автокомплит нужно вывести только имена классов.
                  Такие дела. Всегда ваш, Капитан Очевидность.
    • 0
      emacs
      • 0
        Наврядли.
    • 0
      Еще советую попробовать Komodo IDE, громоздкий чуть менее, чем Эклипс.
      А так, конечно, поддерживаю тех, кто советует Eclipse PDT. Бесплатен, гибок, достаточное количество плагинов, развивается.
    • +1
      Под Mac советую Coda! «Просто, но со вкусом!» :)
    • 0
      с недавних пор просто влюбился в nusphere phped
  • 0
    SQL Injection рулит=))) был ка кто мной сломан 1 сервак(без ущерба, нужно было видео для конкурса. админ был осведомлен о найденном баге)
    там была скуль инъекция и в другом файле раскрытие путей, еще и права на чтение файлов были… собственно вотъ.
    через пару часов у меня были пароли от БД. был залит шелл ну и т.п. в общем пред выпуском сценариев в свет их нужно тестить как «сидорову козу» вдоль и поперек. осторожность никогда не бывает излишней.
    • 0
      типа понтонулся?
      • 0
        это для наглядности. а программисты кстати в РБК трудятся(из камментов узнал)
  • +3
    Главная ошибка начинаюшего PHP разработчика — чтение постов вроде «Ошибки начинающих PHP разработчиков», где ничего не объясняется, а просто навязывается мнение некого «гуру».
    • 0
      Как правило, главная ошибка начинающих разработчиков это нежелание читать мануал. И писать маленькие тестовые програмки для выяснения различного рода непонятностей и неоднозначностей.

      Если много читать и много учиться, то высказывания «гуру» станут быстро понятны. А если что и останется непонятно, то приобретенные знания позволят правильно поставить и конкретизировать вопрос, а не кричать «ничего не понимаю»…
      • 0
        Так о чём и речь. Никто не читает php.net
        А потом приходят устраиваться на работу и говорят:«Я знаю PHP». Хуже того, на собеседовании поправляю кандидата на предмет незнания каких-либо азов, а он мне в ответ:«А вот я прочитал на форуме...» дальше может идти всё, что угодно.
  • 0
    Ошибки действительно детские, но вот 16й пункт лично я до сих пор не пойму как реализовать. Подскажете?
    • 0
      Директивы error_log и log_errors в php.ini, если я правильно понял.
    • +1
      К примеру, можно воспользоваться функцией set_error_handler — и с ее помощью указать функцию в которой мы и будем писать логи в нужном формате, или более простой способ — идем в php.ini:

      // отключаем вывод ошибок на экран
      display_errors = Off
      display_startup_errors = Off
      // пишем ошибки в лог файл
      log_errors = On
      error_log = /www/logs/php/errors.log
  • 0
    На пхп не пишу (ASP.NET еду мне приносит), но за многие пункты готов пожать руку.
  • +1
    > PHP файлы имеют не стандартное расширение (к примеру .inc вместо .php) — если не защитить такие файлы, то может быть очень стыдно

    К этому я бы добавил, что все файлы, которые не будут запрашиваться посетителем сайта напрямую вообще не стоит класть в public_html. В идеале, чтобы система была спроектирована так, что в public_html будет лежать только index.php, внутри которого единственное подключение файлика, не лежащего в public_html.
  • +2
    дежавю?
  • 0
    Так-то это пособие не для PHP-программиста, а для веб-разработчика. Часть советов к PHP никак не относится.

    По 10 примеру: а не проще при проверке на true писать так: if ($auth) {}?
    • 0
      Пример не очень удачный:
    • 0
      Пример не очень удачный:
      if(DEFINE_NAME == $var) {...}
  • –7
    Ошибка начинающих PHP разработчиков в том, что они выбирают PHP.
    • –6
      Обоснуйте?
    • 0
      уже было.
      читайте, перед тем, как постить
    • –3
      [|||||||||||||||||||||||]
    • 0
      Ваш пост доказывает, что ламеров, учащих язык только для того, чтобы пускать пыль в глаза, везде хватает.
    • 0
      смешно но не правда
    • 0
      Скорее дело в другом, начинающие программисты на PHP прочитают книжку типа «Освой PHP за 24 часа», поставят IDE с автозавершением и после этого начинают себя считать крутыми веб-программистами. И таких уникумов в последнее время развелось слишком много.
  • 0
    25-й пункт, наверное, должно быть «в цикле», а не «в рекурсии»?
    • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    «Cannot send session cookie — headers already sent by…» — пытаемся установить куки, когда заголовок уж послан браузеру — незаметили пустую строку или пробел перед первым тегом <?

    … или скрипт написан в UTF8 + BOM…
  • +5
    Мне так нравится, что в топ по PHP залазят люди, пишущие на других языках и пытаются его обосрать )

    Не бывает ПЛОХИХ и ХОРОШИХ языков программирования. Бывают ХОРОШИЕ И ПЛОХИЕ ПРОГРАММИСТЫ.
    Хорошие программисты используют язык как ИНСТРУМЕНТ. Плохие — как ПОНТЫ ;)
    • 0
      Хорошие программисты занимаются написанием кода, плохие программисты занимаются обсиранием хороших ;)
  • 0
    объясните «начинающему пхп-разработчику» как проверять залитые пользователями файлы, плс (пункт 9).
    • +1
      Самое простое:
      if ($_FILES['userfile']['type'] == "image/jpeg"){ //do upload stuff }else{ echo "Go away, hacker!" }
      • 0
        спасибо, общий смысл понятен
  • 0
    Для меня, как для программиста на Си и подобных языках, сложными для запоминания являются две вещи:
    1. то что, строки конкатенируются точками, а не плюсиками. Постоянно нахожу у себя такие мини-баги.
    2. то что, foreach нельзя использовать для обработки строк.
    • 0
      1) В js тоже плюсик, с засилием аякса ПХПист должен их обоих помнить и различать.
      2) — напишите свой foreach и носите с собой всегда
  • 0
    Используем простенький редактор с подсветкой синтаксиса — пора взрослеть и переходить на IDE — с IDE увеличивается скорость разработки, особенно в больших проектах, где не один десяток классов.


    Для начинающих? Сразу начинать с IDE? Интересно, что вкладывалось в понятие «начинающий», потому что начинающие в обычном, классическом понимании этого слова не начинают изучение языка или работу с ним с написания кучи классов и интерфейсов?
    • –2
      Я начинал с обычного блокнота — по-моему это для начинающих=)

      Теперь я пользуюсь немного более сложным HTMLpad Fisherman и ег всем советую. Для крупных проектов он наверное не подходит, но для небольших в самый раз! Имеет функцию нумерования стрк. подсветку множества языков(С, С++, ПЕРЛ, РНР, ЯВА, ЯВА СКРИПТ, ХТМЛ КСС, ХМЛ, ПАСКАЛЬ, DELPHI. SQL. ASP. VB, *.ini, даже синтаксис *.bat подсвечивает!)

      + Встроеные справочники по всем эти языкам
      + Возможность сразу с несколькими проектами\файлами работать
      + встроеные яваскрипт скрипты
      + древо цветов
      + дерево автотекста и т.д.

      Всем новичкам рекомендую!
  • 0
    Еще ошибки:

    Некоторые РНР програмисты, и не только РНР програмисты, забывают использовать табуляцию, от чего код становится трудночитаемым и неудобно его редактировать, особенно если несколько человек участвуют в разработке и обмениваются кодами

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.