Создаем собственную систему отслеживания ошибок на PHP

Владимир | | Ajax, CodeIgniter, JavaScript, MySQL, PHP, Web разработка.

bug_tracker_logo

Приветствую всех!

Это первая статья о создании полнофункционального web приложения, которое будет представлять собой систему отслеживания ошибок (bug tracking system).

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

Система отслеживания ошибок (англ. bug tracking system) — прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки (баги), найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий.

Почему именно баг трекер?

Очень хороший вопрос 🙂 Вообще-то, причин две.

Первая – это приложение не «hello world». И на его примере можно показать совместное использование PHP, JavaScript, AJAX, работу с базой данных и т.д.

Вторая – такое web приложение можно сделать достаточно простым (реализовать минимум функций), но в то же время вполне работоспособным. Ведь основная задача этого цикла статей – показать пример создания полноценного приложения, но в тоже время хотелось бы удержать его объем в каких-то разумных рамках 😉

Постановка задачи.

Это, наверное, самый сложный этап. И дело не в том, что сложно составить перечень функций, для этого можно просто почитать описание к любой существующей bug tracking системе. Проблема в том, как сократить его до минимума, и в тоже время сохранить работоспособность.

После нескольких неудачных попыток у меня получился такой эскиз.

bug_tracker

Давайте рассмотрим его подробнее.

Прежде всего, хочу отметить, что наше приложение будет одностраничным. Т.е. все функции, в т.ч. и пагинация (перелистывание) будут реализованы с помощью AJAX запросов.

Теперь обратите внимание на выделенные красным цветом пункты. Они будут доступны только в режиме администратора, их мы реализуем в последнюю очередь.

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

Форма для отправки сообщений о багах. Содержит 4 поля: заголовок, имя автора, категорию ошибки и её описание.

Список сообщений об ошибках. Каждый пункт этого списка можно будет свернуть и развернуть. В свернутом состоянии посетитель увидит только заголовок, в развернутом – всю остальную информацию, в том числе и ответы.

Ответы также можно будет сворачивать и разворачивать. Удалять их и сообщения о багах смогут только администраторы.

Кстати, обратите внимание на ссылку «Ответить». При клике на неё появится форма отправки ответа.

Теперь пару слов об инструментах.

Для серверной части скрипта будем использовать PHP, фреймворк CodeIgniter и, конечно, MySQL.

На клиентской – JavaScript и библиотеку jQuery.

Кроме того, при необходимости, будем использовать и другие библиотеки. Например, HTML Purifier.

В следующий раз мы рассмотрим установку фреймворка, создадим базу данных и подробно разберем её структуру.

Продолжение следует…

P.S. Любые советы, замечания и предложения всегда приветствуются 🙂

  • Уф блин, если у вас получится действительно все это написать, то я, пожалуй, наконец то начну пользоваться фреймворками, все никак раньше руки не доходили, страшновато было самому пробовать) а так, под четким руководством..)

    • be3

      Зря боялись, Codeigniter — user friendly framework +) Даже будучи далеким от php, можно создать простенькое приложение.

  • Уф блин, если у вас получится действительно все это написать, то я, пожалуй, наконец то начну пользоваться фреймворками, все никак раньше руки не доходили, страшновато было самому пробовать) а так, под четким руководством..)

    • be3

      Зря боялись, Codeigniter — user friendly framework +) Даже будучи далеким от php, можно создать простенькое приложение.

  • Поддерживаю ваше начинание! Согласен и со splean — сам пишу всякие штуки, чуствую, что дорос уже до фреймворков, но никак не начну. опять же что именно выбрать…
    А эскизы рисовали в граф.редакторе, или в какой-то спецпроге?

  • Поддерживаю ваше начинание! Согласен и со splean — сам пишу всякие штуки, чуствую, что дорос уже до фреймворков, но никак не начну. опять же что именно выбрать…
    А эскизы рисовали в граф.редакторе, или в какой-то спецпроге?

  • Nemnogo ne v temu, no mzhno pointeresovat'sya v chem Vy sdelali etot eskiz? Prosto v Photoshop nabrosali ili kakoi to special'noi programmoi?
    Spasibo

  • Nemnogo ne v temu, no mzhno pointeresovat'sya v chem Vy sdelali etot eskiz? Prosto v Photoshop nabrosali ili kakoi to special'noi programmoi?
    Spasibo

  • плохая идея делать всё на одной странице, разве что сделаешь умный ajax, потому что на ошибки нужно заходить чаще по урлу http://stite.my/bag/id/666/ и не забудь, что нужно скриншоты загружать.

  • плохая идея делать всё на одной странице, разве что сделаешь умный ajax, потому что на ошибки нужно заходить чаще по урлу http://stite.my/bag/id/666/ и не забудь, что нужно скриншоты загружать.

  • Big_Shark

    Должна быть не кнопка удалить а кнопка «Исправлено» или что либо такое.
    Должен быть статус типа «Не подтвержденная»,Подтвержденная»,»Исправляется» или «Исправления запланировано на #####» и конечно «Исправлено в версии ####».
    Также рекомендована уведомления при ответе.
    Ну и конечное ссылка на определенный баг.
    Также необходимо чтобы поисковики нормал хавали.
    ну и на по следок можно добавить RSS подписку или e-mail подписку.
    Что та по моему я разошелся.

  • Big_Shark

    Должна быть не кнопка удалить а кнопка «Исправлено» или что либо такое.
    Должен быть статус типа «Не подтвержденная»,Подтвержденная»,»Исправляется» или «Исправления запланировано на #####» и конечно «Исправлено в версии ####».
    Также рекомендована уведомления при ответе.
    Ну и конечное ссылка на определенный баг.
    Также необходимо чтобы поисковики нормал хавали.
    ну и на по следок можно добавить RSS подписку или e-mail подписку.
    Что та по моему я разошелся.

  • Плохая идея изобретать велосипед 🙂
    оглянитесь вокруг, есть Trac, Mantis куча остальных… лучше не сделаете, вечно будет чего-то не хватать, что есть удобнее у других… Конечно под себя сделаете, нестандратно, в этом и суть, что никто пользоваться и не будет так как непривычно

  • Плохая идея изобретать велосипед 🙂
    оглянитесь вокруг, есть Trac, Mantis куча остальных… лучше не сделаете, вечно будет чего-то не хватать, что есть удобнее у других… Конечно под себя сделаете, нестандратно, в этом и суть, что никто пользоваться и не будет так как непривычно

  • Big_Shark

    Trac отпадает ибо «Написана на Python»
    Mantis не такой уж сложный и интересный продукт.
    Пользоваться будут те кому это нужно.
    Большинство баг трекеров самопистные.
    Слушайте а зачем вообще делать сайты вот уже все создано до нас.
    Вон тебе и почтовые сервесы и поисковики и сайты где я могу за 2 клика сделать себе хом пейдж и вот баг трекеры есть.
    Все есть.
    2MpaK Вы скорее всего не 1 нормального продукта в своей жизни ни сделали а только использовали чужое.

    • DVF

      Тоже склоняюсь к мнению, что если уже существуют аналоги, тратить силы на написание своего продукта стоит только в случае, если аналоги уж совсем неудобные/криво написанные.

      Достаточно интересная штука Eventum от создателей MySql, её сейчас и использую. Проще Mantiss, только проекты разделяются не так удобно и дерева проектов нет.

      P.S. Я тоже как-то написал свой баг-трекер. Правда на MSVC++ и MSSQL. Из за чего на неделю не уложился в срок сдачи основного проекта.

    • нет конечно 🙂 я ничего за свои 16 лет изучения программирования не написал, и не работаю веб-программистом 🙂 я лох… 🙂 думаю, стоит сперва думать, прежде решать о достижениях других людей.

      я не увидел, что-то такого в этом проекте чего нет у других, пусть они и писаны на Питоне, это разве проблема-то?

      Проект чисто академический, не более.

      • Я в общем-то так и написал, что это будет пример.
        Описывать разработку реального приложения с новым оригинальным функционалом просто не реально (во всяком случае для меня).

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

  • Big_Shark

    Trac отпадает ибо «Написана на Python»
    Mantis не такой уж сложный и интересный продукт.
    Пользоваться будут те кому это нужно.
    Большинство баг трекеров самопистные.
    Слушайте а зачем вообще делать сайты вот уже все создано до нас.
    Вон тебе и почтовые сервесы и поисковики и сайты где я могу за 2 клика сделать себе хом пейдж и вот баг трекеры есть.
    Все есть.
    2MpaK Вы скорее всего не 1 нормального продукта в своей жизни ни сделали а только использовали чужое.

    • DVF

      Тоже склоняюсь к мнению, что если уже существуют аналоги, тратить силы на написание своего продукта стоит только в случае, если аналоги уж совсем неудобные/криво написанные.

      Достаточно интересная штука Eventum от создателей MySql, её сейчас и использую. Проще Mantiss, только проекты разделяются не так удобно и дерева проектов нет.

      P.S. Я тоже как-то написал свой баг-трекер. Правда на MSVC++ и MSSQL. Из за чего на неделю не уложился в срок сдачи основного проекта.

    • нет конечно 🙂 я ничего за свои 16 лет изучения программирования не написал, и не работаю веб-программистом 🙂 я лох… 🙂 думаю, стоит сперва думать, прежде решать о достижениях других людей.

      я не увидел, что-то такого в этом проекте чего нет у других, пусть они и писаны на Питоне, это разве проблема-то?

      Проект чисто академический, не более.

      • Я в общем-то так и написал, что это будет пример.
        Описывать разработку реального приложения с новым оригинальным функционалом просто не реально (во всяком случае для меня).

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

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

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

  • Чего Вы ополчились то) Я лично смотрю на это не с практической стороны — откровенно говоря для себя я вообще не вижу смысла использовать багтрэкеры, не приучен — а со стороны обучения фреймворку.

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

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

    • Согласен. Программист же должен на чем-то учиться. А если во время учебы ставить себе цель сотворить какой-нибудь второй WordPress, да еще чтобы лучше был в несколько раз — то от такого обучения можно получить только разочарование.

      • А вы думаете вордпресс так сложен. Блог можно написать за пару часов на нормальном фреймворке, с плагинами несколько труднее.

        • Ну, про пару часов вы все равно погарячились. Если нормально подходить к делу, то времени уйдет больше, даже без плагинов, но со всем функционалом нормального блога — комментариями с премодерацией, рсс-лентами, многоуровневой системой категорий и тегами.

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

        • 🙂 почему-то не могу ответить на твой ответ. ссылки нету, видимо виноват вордпресс 😉
          ну да, пару часов — это если хорошо знаешь фреймворк, а так CI+Doctine и не на такое способны, можно поискать примеры в сети, особенно на ROR

  • Чего Вы ополчились то) Я лично смотрю на это не с практической стороны — откровенно говоря для себя я вообще не вижу смысла использовать багтрэкеры, не приучен — а со стороны обучения фреймворку.

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

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

    • Согласен. Программист же должен на чем-то учиться. А если во время учебы ставить себе цель сотворить какой-нибудь второй WordPress, да еще чтобы лучше был в несколько раз — то от такого обучения можно получить только разочарование.

      • А вы думаете вордпресс так сложен. Блог можно написать за пару часов на нормальном фреймворке, с плагинами несколько труднее.

        • Ну, про пару часов вы все равно погарячились. Если нормально подходить к делу, то времени уйдет больше, даже без плагинов, но со всем функционалом нормального блога — комментариями с премодерацией, рсс-лентами, многоуровневой системой категорий и тегами.

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

        • 🙂 почему-то не могу ответить на твой ответ. ссылки нету, видимо виноват вордпресс 😉
          ну да, пару часов — это если хорошо знаешь фреймворк, а так CI+Doctine и не на такое способны, можно поискать примеры в сети, особенно на ROR

  • Вопросик по ходу, чисто из интереса: Оставлять сообщение сможет любой пользователь? Или будет какая-то регистрация/логин?

    Еще раз повторю чей-то вопрос: в какой программе было нарисовано?

    На счет проблемы ajax-одностраничной-архитектуры с ее невозможность получить доступ к конкретной структуре через URL. Я тоже сталкивался с таким, когда встраивал в один проект поисковую систему. Тогда тоже с ходу сделал на ajax, потом пришлось переделывать, так параметров поиска было куча, а доступа к конкретной страничке с поисковыми результатами нет.

    Выход может быть таким: мы создаем запись о новом баге, появляется сам баг в списке, под заголовком написано ВАШ БАГ ДОСТУПЕН ПО АДРЕСУ http:чего-то там.

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

  • Вопросик по ходу, чисто из интереса: Оставлять сообщение сможет любой пользователь? Или будет какая-то регистрация/логин?

    Еще раз повторю чей-то вопрос: в какой программе было нарисовано?

    На счет проблемы ajax-одностраничной-архитектуры с ее невозможность получить доступ к конкретной структуре через URL. Я тоже сталкивался с таким, когда встраивал в один проект поисковую систему. Тогда тоже с ходу сделал на ajax, потом пришлось переделывать, так параметров поиска было куча, а доступа к конкретной страничке с поисковыми результатами нет.

    Выход может быть таким: мы создаем запись о новом баге, появляется сам баг в списке, под заголовком написано ВАШ БАГ ДОСТУПЕН ПО АДРЕСУ http:чего-то там.

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

  • Честно говоря, не ожидал такого количества комментариев. Попробую ответить всем сразу.

    1) Я, наверно, не очень удачно использовал термин «полноценное приложение». Основная идея этого цикла постов — показать пример создания работающего web приложения, а не сделать аналог системы вроде Bugzilla.

    Приведу простой пример. Недавно я читал книгу Thomas Myer «Professional CodeIgniter». В ней более 300 страниц и основную часть занимает всего один пример — создание интернет-магазина. Причем реализованы только основные функции.

    Здесь ситуация такая же, с той разницей, что я планирую уложиться стараниц в 20-30. По предварительному плану получается, что цикл растянется постов на 6 минимум, скорее всего будет больше. Поэтому в первую очередь будет реализован минимум функций, которые нужны чтобы приложение просто заработало.

    2) @splean, @normal
    Скажу прямо. Если вы только начинаете использовать фреймворки, то этот цикл — не лучший выбор. Это не означает, что нет смысла его читать 🙂 Просто я предполагаю, что читатели хотябы в общих чертах знакомы с архитектурой MVC. И кроме того, уже написано много очень подробных статей о CodeIgniter (например, посмотрите самые первые посты в этом разделе (http://www.simplecoding.org/category/code-igniter)).

    3) Картинку рисовал в photoshop'е. Никаких специальных инструментов не использовал. Custom Shapes и шрифт, похожий на рукописный.

    4) @AmdY
    В первом варианте загрузки скриншотов не будет. Но позже её можно будет добавить (я планировал вариант асихронной загрузки через iframe). А вот насчёт ссылок вы правы. Дело в том, что я не хотел делать отдельную страницу для каждого бага. Так, конечно, проще, но при этом пропадает смысл в сворачивании/разворачивании полей, а этот пример мне хотелось бы включить. В общем, посмотрю, что можно сделать.

    5) @Big_Shark
    Статус сообщения безусловно нужен и соответствующее поле будет в базе данных. Но, опять же, в первом варианте приложения поддержки этой функции не будет. Ссылка «Удалить» нужна обязательно иначе флуд удалить не получится.

    6) @MpaK
    Понимаете, если бы мне была нужна bug tracking система ПРЯМО СЕЙЧАС, то я бы использовал готовое решение. А это приложение сейчас будет просто демонстрационным, а потом — посмотрим по результатам. В любом случае я планирую заложить возможность достаточно удобного наращивания функционала.

    7) Сообщение оставлять сможет кто угодно без регистрации. Удалять — только администраторы.

    • формы можно попробовать сделать с плагином jqForm, но чёт у меня возникли проблемы с ними, там же есть и ajax загрузчик файлов. мот у тебя выйдет лучше.
      урлы можно делать через #bag/666/
      а идею поддерживаю, плевать, что это энный багтрекер, видел бы каким убожеством мы пользуемся на работе, 😉 зато на .net. только сделай возможность назначать тикеты пользователям

      • Плагин обязательно попробую.
        Насчет «убогих багтрекеров». Часто забывают, что переход на любой другой софт всегда связан как минимум с потерей времени. Людям нужно будет привыкать к новому интерфейсу, пусть даже он в 100 раз лучше. Конечно, если новый багтрекер позволяет сэкономить время (за счет дополнительных функций, например), то переходить нужно, но если он будет использоваться точно так же как и старый, то нем смысла что-то морочить себе и людям голову.

  • Честно говоря, не ожидал такого количества комментариев. Попробую ответить всем сразу.

    1) Я, наверно, не очень удачно использовал термин «полноценное приложение». Основная идея этого цикла постов — показать пример создания работающего web приложения, а не сделать аналог системы вроде Bugzilla.

    Приведу простой пример. Недавно я читал книгу Thomas Myer «Professional CodeIgniter». В ней более 300 страниц и основную часть занимает всего один пример — создание интернет-магазина. Причем реализованы только основные функции.

    Здесь ситуация такая же, с той разницей, что я планирую уложиться стараниц в 20-30. По предварительному плану получается, что цикл растянется постов на 6 минимум, скорее всего будет больше. Поэтому в первую очередь будет реализован минимум функций, которые нужны чтобы приложение просто заработало.

    2) @splean, @normal
    Скажу прямо. Если вы только начинаете использовать фреймворки, то этот цикл — не лучший выбор. Это не означает, что нет смысла его читать 🙂 Просто я предполагаю, что читатели хотябы в общих чертах знакомы с архитектурой MVC. И кроме того, уже написано много очень подробных статей о CodeIgniter (например, посмотрите самые первые посты в этом разделе (http://www.simplecoding.org/category/code-igniter)).

    3) Картинку рисовал в photoshop'е. Никаких специальных инструментов не использовал. Custom Shapes и шрифт, похожий на рукописный.

    4) @AmdY
    В первом варианте загрузки скриншотов не будет. Но позже её можно будет добавить (я планировал вариант асихронной загрузки через iframe). А вот насчёт ссылок вы правы. Дело в том, что я не хотел делать отдельную страницу для каждого бага. Так, конечно, проще, но при этом пропадает смысл в сворачивании/разворачивании полей, а этот пример мне хотелось бы включить. В общем, посмотрю, что можно сделать.

    5) @Big_Shark
    Статус сообщения безусловно нужен и соответствующее поле будет в базе данных. Но, опять же, в первом варианте приложения поддержки этой функции не будет. Ссылка «Удалить» нужна обязательно иначе флуд удалить не получится.

    6) @MpaK
    Понимаете, если бы мне была нужна bug tracking система ПРЯМО СЕЙЧАС, то я бы использовал готовое решение. А это приложение сейчас будет просто демонстрационным, а потом — посмотрим по результатам. В любом случае я планирую заложить возможность достаточно удобного наращивания функционала.

    7) Сообщение оставлять сможет кто угодно без регистрации. Удалять — только администраторы.

    • формы можно попробовать сделать с плагином jqForm, но чёт у меня возникли проблемы с ними, там же есть и ajax загрузчик файлов. мот у тебя выйдет лучше.
      урлы можно делать через #bag/666/
      а идею поддерживаю, плевать, что это энный багтрекер, видел бы каким убожеством мы пользуемся на работе, 😉 зато на .net. только сделай возможность назначать тикеты пользователям

      • Плагин обязательно попробую.
        Насчет «убогих багтрекеров». Часто забывают, что переход на любой другой софт всегда связан как минимум с потерей времени. Людям нужно будет привыкать к новому интерфейсу, пусть даже он в 100 раз лучше. Конечно, если новый багтрекер позволяет сэкономить время (за счет дополнительных функций, например), то переходить нужно, но если он будет использоваться точно так же как и старый, то нем смысла что-то морочить себе и людям голову.

  • Идея отличная! Буду следить за развитием системы.

  • Идея отличная! Буду следить за развитием системы.

  • Денис Чистяков

    Спасибо за начало интересного цикла. Думаю у вас получится отличный образовательный цикл по CI.
    Сам в работе применяю Mantis — вполне устраивает, но с удовольствием почитаю, хотя бы что бы немного лучше узнать CI, сейчас мне пока ближе Zend, но мнение может и изменится 😉

  • Денис Чистяков

    Спасибо за начало интересного цикла. Думаю у вас получится отличный образовательный цикл по CI.
    Сам в работе применяю Mantis — вполне устраивает, но с удовольствием почитаю, хотя бы что бы немного лучше узнать CI, сейчас мне пока ближе Zend, но мнение может и изменится 😉

  • Задача архиважная и я буду в первых рядах желающих поблагодарить.

  • Да, отлично было бы. Так как протестить на баги на 100% не получается. А этот инструмент откроет новые горизонты, так сказать.