Компьютерный форум
Правила
Вернуться   Компьютерный форум > Форум программистов > Теория программирования > Общие вопросы создания ПО
Перезагрузить страницу Постпроектирование в web
Закрытая тема
 
Опции темы Опции просмотра
  (#1 (permalink)) Старый
Jeezekil Jeezekil вне форума
Member
 
Сообщений: 33
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 09.09.2002
По умолчанию Постпроектирование в web - 11.09.2002, 16:07

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

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

и вот тут возникает вопрос "постпроектирования"..
если этот самый контент-менеджер увидел, что в модели имеется серьезный изъян, что ползователи идут не те и не туда? нужно перепроектировать информационное поле. возможно изменить только его форму, но не содержание. и при этом не переделывать весь ресурс. да еще и сделать это хочется визуальными средствами, а не переносить вручную разделы с места на место..

такая вот есть идея. к проектированию ПО она конечно мало относится но все же это вопрос проектирования.

задумываюсь над реализацией.. но идея пока не созрела.
хотелось бы услышать здоровую критику и советы..
спасибо, что прочитали до конца!
  (#2 (permalink)) Старый
Guderian Guderian вне форума
Member
 
Сообщений: 47
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 06.09.2002
По умолчанию 13.09.2002, 12:48

Что-то я почти ничего не понял
Попробуем по порядку. Начнем с "информационного пространства веб-ресурса или структуры информационного поля". То, что следует после или, мне вообще перевести не удалось Что же касается информационного пространства, то оно скорее проектируется не для веб-ресурса, а для информационной системы, лежащей в бэкенде. Проведем пример с рад-инструментами вроде дельфи, вб, вс.нет и прочих. Есть понятие формы. Так вот, мое имхо гласит, что каждая веб-страница и есть некоторая форма представление информации. Что-то вроде классической парадигмы smalltalk'а mvc. Где совокупность страниц веб-ресурса - это комплекс различных view и отчасти controller. Model же лежит в недрах, скажем, корпоративной информационной системы.
Что же касается софта, то всевозможных cms-систем уже развелось навалом. Там все эти схемы сайтов реализуются в лучшем виде, еще и с поддержкой полной workflow. Но хранением непосредственно данных они не занимаются. Для этого служат субд и кбс. Например, у микрософта связка из Content Managment Server + SQL Server + SharePoint Portal Server.
Что же касается привлекательности информации, то тоже не очень понял. Взял, например, WebTrends Log Analyzer, логи веб-сервера и вперед. Узнаешь, почем фунт перцу
Некоторые, правда, uml умудряются использовать для проектирования всего и вся, но это, имхо, извращение. Хотя, с другой стороны, если в той же Rational Rose есть стереотип Form, то почему бы и не быть стереотипу WebForm. Но это низкоуровневое проектирование, пользы мало дающее. Другое дело - компонентно-ориентированное. В стиле vs.net или WebMatrix. Тут уже гораздо красивей смотрится с точки зрения практичности.

Давай немного переформулируем твою идею, чтобы она даже мне была понятна Тогда имхо интересная дискуссия может получиться. Поскольку проектирование в веб - почти отсутствующая дисциплина.
  (#3 (permalink)) Старый
Jeezekil Jeezekil вне форума
Member
 
Сообщений: 33
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 09.09.2002
По умолчанию 17.09.2002, 17:09

Цитата:
Originally posted by Guderian
[b]Начнем с "информационного пространства веб-ресурса или структуры информационного поля". То, что следует после или, мне вообще перевести не удалось
Ну сорри, не нашел я правильных терминов А слова красивые были, вот я и написал.
На самом деле речь идет о структуре информации которую видит пользователь, то есть о структуре веб-ресурса.
Если в терминах mvc, то это будет совокупность view, а не model.

Цитата:
Originally posted by Guderian
[b]Что же касается софта, то всевозможных cms-систем уже развелось навалом.
Что же касается привлекательности информации, то тоже не очень понял. Взял, например, WebTrends Log Analyzer, логи веб-сервера и вперед.
О написании своей CMS или анализатора логов тоже речь не идет, их действительно уже наплодилось тьма.
И о процессе их проектирования уже врядли смысл есть рассуждать - проще литературу почитать соответствующую.
А вот о проектировании контента сайта по-моему не много есть толковой информации. Не структуры данных, хранимых в СУБД, а именно контента, который видит пользователь. Точнее его структуры.
Обычно эту структуру изображают в виде дерева.и чаще всего дерево имеет один корень и 5-10 ветвей типа "главная страница" - "о нас" - "каталог товаров" и тд. Но и процесс проектирования автоматизировать - тоже дело не совсем интересное в данном случае.

Суть заключается в том, чтобы получить на вход эту вот изначально спроектированную структуру контента. В процессе наполнения ресурса информацией структуру уточнить. А в дальнейшем отображать на этой же структуре собираемую статистику.
Но статистику отображать не графиками, а визуально, прямо на структуре. Например, интерес пользователей к кадому объекту структуры отображать цветом. Если там относительная посещаемость раздела "разное->эротика" 80%, то отображать этот раздел насыщенным цветом, а если в раздел "о нас" почти никто не заходит, то делать его бледным.. И плюс к этому отображать пути продвижения пользователей по сайту (из той же статистики). И в зависимости от количества проходящих по каждой связи пользователей рисовать линию толще или тоньше.

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

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

Такую вещь неплохо конечно реализовать как компоненту для CMS, постороенной на dotNET или еще чем-то компонентном.

Опять получилось не очень систематизированно.. надеюсь хоть понятнее
  (#4 (permalink)) Старый
Guderian Guderian вне форума
Member
 
Сообщений: 47
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 06.09.2002
По умолчанию 17.09.2002, 19:46

Теперь понял. Ну что можно сказать. Мысль интересная. Правда, к проектированию, как таковому, имеющая опосредованное отношение. А с другой стороны, имплементация механизма проектирования в применении к частной задаче. Я даже термин умный придумал. Browseflow
Первое структура сайта. Это да, это притча во языцах. Что похожее, конечно, есть. Например, в том же мелкомягком cms в виде иерархической структуры + каналы. Но почему-то все разработчики считают, что она должна иметь вид дерева. Я с этим не совсем согласен. Это вполне может быть граф, flowchart или даже некое подобие экспертной системы. Ведь переход пользователя с одной страницы на другую обусловлен принятием им же некоторых решений. В общем, тема структуры сайта достаточно интересна.
Анализ посещяемости - тоже интересен. Причем не только заходы на страницу, но и переходы с одной на другую (как раз - принятие решения, если говорить в терминах экспертной системы). Т.е. не совсем полный путь (тот растет в экспоненциальном порядке), а именно переходы (квадратичен). Ну и т.д.
Что касается реализации, то дотнет - это пять, дотнет - это рулеззз Но одной компонентой здесь врядли обойдешься. Но зато хоть все стало на свои места. В смысле понятности
  (#5 (permalink)) Старый
Anonymous
Guest
 
Сообщений: n/a
По умолчанию 17.09.2002, 22:32

Цитата:
Originally posted by Guderian
[b]Правда, к проектированию, как таковому, имеющая опосредованное отношение.
Ну на прямое отношение к проектированию ПО я и не претендовал.
Назовем, значится, интересующий нас процесс Browseflow.

Цитата:
Originally posted by Guderian
[b]Но почему-то все разработчики считают, что она должна иметь вид дерева. Я с этим не совсем согласен.
..cut..
В общем, тема структуры сайта достаточно интересна.
Абсолютно согласен по поводу структуры сайта. Напоролся на эти грабли на практике в одном из последних проектов. Очень многие CMS опираются на иерархическую структуру, что и не позволило их использовать, потому что структура контента никак в дерево "не влазила". Если у тебя есть какая-либо информация по структуре - делись!
Потому что на самом деле это одна из зияющих дыр в моей идее. Я не могу определиться, как правильно представлять структуру и, соответственно, как ее отображать. Не хочеться накладывать ограничения на структуру контента.

Цитата:
Originally posted by Guderian+-->
Цитата:
Анализ посещяемости - тоже интересен. Причем не только заходы на страницу, но и переходы с одной на другую (как раз - принятие решения, если говорить в терминах экспертной системы). Т.е. не совсем полный путь (тот растет в экспоненциальном порядке), а именно переходы (квадратичен). Ну и т.д.
Да, именно о переходах и идет речь, т.к. полный путь на самом деле проблематично визуализировать, да и толку с него мало. ИМХО, для анализа гораздо привлекательнее информация о переходах между страницами.

<!--QuoteBegin-Guderian

[b]Что касается реализации, то дотнет - это пять, дотнет - это рулеззз Но одной компонентой здесь врядли обойдешься.
Количество компонент будем на месте уточнять
Ads.
  (#6 (permalink)) Старый
Guderian Guderian вне форума
Member
 
Сообщений: 47
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 06.09.2002
По умолчанию 18.09.2002, 19:28

Цитата:
Originally posted by Anonymous
[b]Абсолютно согласен по поводу структуры сайта. Напоролся на эти грабли на практике в одном из последних проектов. Очень многие CMS опираются на иерархическую структуру, что и не позволило их использовать, потому что структура контента никак в дерево "не влазила". Если у тебя есть какая-либо информация по структуре - делись!
Потому что на самом деле это одна из зияющих дыр в моей идее. Я не могу определиться, как правильно представлять структуру и, соответственно, как ее отображать. Не хочеться накладывать ограничения на структуру контента.
Черт его знает. У меня самого давно это тема любопытство вызывает, но никак до нее всерьез не доберусь. С одной стороны, логичным продолжением дерева мог бы быть граф. Вроде как снимает "деревянные" ограничения, но что он дает помимо этого? Вроде как ничего особенно. Другой вариант я уже озвучивал - flowchart. Сиречь что-то наподобие блок схем. Т.е. подзанять что-то из программирования. Геометрически - тот же граф. Семантически - нечто большее. Поскольку позволяет "спроектировать" тот самый browseflow. К тому же, при таком подходе можно опираться на интересы пользователей и на их основе получать карту сайта со всеми возможными переходами, а не наоборот, идти от структуры сайта, а там уж как-нибудь подгоним Другой вариант, который я правдо не знаю, куда подоткнуть - многомерные кбы в стиле olap. Т.е. юзер как бы последовательно строит срезы над общим информационным наполнением, постепенно сужаясь к нужной ему информации.
А может оба этих метода совместить. Пока все оченно запутанно. Как ужик в тумане.

Цитата:
Originally posted by Anonymous+-->
Цитата:
Да, именно о переходах и идет речь, т.к. полный путь на самом деле проблематично визуализировать, да и толку с него мало. ИМХО, для анализа гораздо привлекательнее информация о переходах между страницами.
Угумс. Поскольку как я уже говорил, каждый переход сродни принятию пользователем определенного решения. Зашел в корень, увидел меню, прикинул что ему нужно, втоптал нужную кнопку. Проанализировали переходы, получили, например, популярность того или иного раздела. Самое интересное может получиться при обратном анализе переходов. Например, со страницы 1 редко ходяд на страницу 3, но часто на страницу 2. А со страницы 2 часто на 3. Одна из возможных моралей - ссылка с 1 на 3 не совсем кузява или 3 служит логическим продолжением 2 и можно задуматься о слиянии. Ладно, это меня куда-то в лес понесло...

<!--QuoteBegin-Anonymous

[b]Количество компонент будем на месте уточнять
Голосую за две
  (#7 (permalink)) Старый
Gelezny Gelezny вне форума
Новичок
 
Сообщений: 2
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 19.09.2002
По умолчанию 19.09.2002, 16:51

Г-да!
Идея конечно поднята интересная...

Но на счет описания графов (просто как частная задача визуализации) вполне можно использовать XML-схемы и накладывая одну на другу при помощи DOM-прасера (правда все-таки деревья ) можно иметь разные точки входа.

Допустим назовем вторичные (накладываемые) схемы фильтрами.
Но на практике выходит что надо иметь столько фильтров сколько точек входом в граф. Т.к. ф DOM-дереве может быть только один корень...
  (#8 (permalink)) Старый
Jeezekil Jeezekil вне форума
Member
 
Сообщений: 33
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 09.09.2002
По умолчанию 19.09.2002, 17:53

Цитата:
Originally posted by Guderian
[b]Т.е. подзанять что-то из программирования. Геометрически - тот же граф. Семантически - нечто большее. Поскольку позволяет "спроектировать" тот самый browseflow.
хых. я сам ноконец-то въехал, кого мы назвали browseflow
я думаю, что достаточно будет направленного графа. заодно будет выплывать тот самый "обратный" анализ. видно будет, откуда и куда пользователи ходят.

Цитата:
Originally posted by Guderian
[b]Другой вариант, который я правдо не знаю, куда подоткнуть - многомерные кбы в стиле olap. Т.е. юзер как бы последовательно строит срезы над общим информационным наполнением, постепенно сужаясь к нужной ему информации.
да уж.. с этой теорией я совсем не силен.

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

только вот придется вводить понятия типа "группировки" связей. на случай, если одно меню должно присутствовать на всех страницах сайта. а то получится огромное количество пугающих вееров связей
  (#9 (permalink)) Старый
Guderian Guderian вне форума
Member
 
Сообщений: 47
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 06.09.2002
По умолчанию 19.09.2002, 18:27

Цитата:
Originally posted by Gelezny
[b]Г-да!
Идея конечно поднята интересная...

Но на счет описания графов (просто как частная задача визуализации) вполне можно использовать XML-схемы и накладывая одну на другу при помощи DOM-прасера (правда все-таки деревья ) можно иметь разные точки входа.
xml-схемы или xml-документы? Поскольку все-таки xml-схема, являясь реализацией xml, декларирует словарь и вряд ли может послужить основой для описания чего-либо отличного от описания собственно xml-документов. И чего-то с накладыванием одну на другую я не очень понял. Ну да ладно. В использовании xml мне не нравится один момент. Изложу на примере. Есть у нас сайт с публикациями технического характера. Публикации, например, делятся на статьи, faq, вопросы, идеи и еще какую-нибудь ересь. Помимо этого они могут освещать различные вопросы. Например, по Delphi, C, Васику и т.д. Вариант номер один - я специалист по Delphi. Значит я заходу в раздел по Delphi и уже внутри этого раздела вижу те самые статьи, faq и тр. и пр. Вариант два - я специалист венчурной компании. Тогда я захожу в раздел идеи и там, среди Delphi, C и ваиска ищу то, что мне интересно. Немного запутанно, но смысл думаю ясен. Мы, на самом деле рассматриваем двух-, трех-,...-направленную структуру. Такую схему в xml можно реализовать только одним способом.
Код:
<pages>
<page kind="issue" theme="Delphi"/>
<page kind="faq" theme="Basic"/>
...
</pages>
И уж по этой схеме делать SelectNodes("/pages/page[theme='Delphi']") или ...[kind="faq"]. Но это уже классическая реляционная модель. Какую пользу, спрашвается, дает нам xml? Может я что-то где-то упустил...

Цитата:
Originally posted by Gelezny
[b]Допустим назовем вторичные (накладываемые) схемы фильтрами.
Но на практике выходит что надо иметь столько фильтров сколько точек входом в граф. Т.к. ф DOM-дереве может быть только один корень...
И тут я что-то мимо тазика попал. Видать тугодумом становлюсь
  (#10 (permalink)) Старый
Guderian Guderian вне форума
Member
 
Сообщений: 47
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 06.09.2002
По умолчанию 19.09.2002, 19:12

Цитата:
Originally posted by Jeezekil
[b]хых. я сам ноконец-то въехал, кого мы назвали browseflow
я думаю, что достаточно будет направленного графа. заодно будет выплывать тот самый "обратный" анализ. видно будет, откуда и куда пользователи ходят.
Как один из вариантов - да. Давай прикинем как же тогда будет выглядеть процесс проектирования?

Цитата:
Originally posted by Jeezekil
[b]да уж.. с этой теорией я совсем не силен. :(

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

только вот придется вводить понятия типа "группировки" связей. на случай, если одно меню должно присутствовать на всех страницах сайта. а то получится огромное количество пугающих вееров связей :lol:
Угумс. К связи приписываешь - "сюда может пойти только дятел". А тебе система статистику - "среди посетителей обнаружено XXX дятлов" Вот это анализ, вот это я понимаю.

А что касается кубов - посмотри в моем ответе Железному. Там один из возможных вариантов. Как бы два измерения. Тип документа, тема документа. Двухмерный куб Срезали по типу - получили все документы данного типа. Срезали по теме - получили документы разных типов, но в тему. Короче, думать надо. А думать надо в определенном направлении. С какой стороны идти? Как пользователи осуществляют browseflow? Или каким мы видим инструмент для проектирования?
  (#11 (permalink)) Старый
Jeezekil Jeezekil вне форума
Member
 
Сообщений: 33
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 09.09.2002
По умолчанию 19.09.2002, 19:58

Цитата:
Originally posted by Guderian
[b]Угумс. К связи приписываешь - "сюда может пойти только дятел". А тебе система статистику - "среди посетителей обнаружено XXX дятлов" :lol: Вот это анализ, вот это я понимаю.
а че! для 70 процентов менеджеров наличие анализа дятлопосещаемости будет веской причиной покупки ситемы

Цитата:
Originally posted by Guderian
[b]А что касается кубов - посмотри в моем ответе Железному. Там один из возможных вариантов. Как бы два измерения. Тип документа, тема документа. Двухмерный куб
То есть квадрат
Вспомнил это дело. Давненько учил

Цитата:
Originally posted by Guderian
[b]Короче, думать надо. А думать надо в определенном направлении. С какой стороны идти? Как пользователи осуществляют browseflow? Или каким мы видим инструмент для проектирования?
Это уже следующий вопрос
Я пока не думал над автоматизацией самого проектирования. Да ведь и идея была в постпроектировании
Сегодня вот уяснил, как это все должно работать. По крайней мере для простого варианта с направленным графом.
Кубы сюда конечно интересно подключить.. возможно для этого нужно будет вводить разные типы связей.
И о проектировании теперь пора поразмыслить..
Но это уже завтра. сегодня голова сказала, что хватит
  (#12 (permalink)) Старый
Jeezekil Jeezekil вне форума
Member
 
Сообщений: 33
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 09.09.2002
По умолчанию 20.09.2002, 12:23

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

Да и вообще хочется это все реализовать хотябы в самом примитивном виде, чтобы посмотреть, как оно будет работать реально. Может и смысла нет
Ads
  (#13 (permalink)) Старый
Gelezny Gelezny вне форума
Новичок
 
Сообщений: 2
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 19.09.2002
По умолчанию 20.09.2002, 12:41

Цитата:
Originally posted by Jeezekil
[b]Мыслил я о кубах.
Сдается мне, что кубы и срезы должны быть реализованы внутри узлов. А в связи совать их смысла особого я пока не вижу.
вчера вечером поднял книжку О.Е.Акимова "Дискретна математика. логика, группы, графы".
в частности стр. 274 глава "Морфология графов" и пришел к такому же выводу.


Цитата:
Originally posted by Jeezekil
[b]Да и вообще хочется это все реализовать хотябы в самом примитивном виде, чтобы посмотреть, как оно будет работать реально. Может и смысла нет
не знаю, но я почему-то уперся в хранилище данных и начал поиск объектно-ориентированых баз данных.
  (#14 (permalink)) Старый
Jeezekil Jeezekil вне форума
Member
 
Сообщений: 33
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 09.09.2002
По умолчанию 20.09.2002, 15:13

необходимости в объектно-ориентированых субд я не вижу.

а вот со срезами внутри узлов я вспылил.. на самом деле срезы реализуются в этой схеме очень просто. нужно просто создавать узлы-срезы, которые будут иметь связи со всеми узлами, входящими в срез.
если взять за основу описанный выше XML, то узел "kind=issue" должен иметь связи во всеми узлами у которых kind=issue.
Т.е. струртура графа должна перестраиваться при изменении/добавлении/удалении узлов, а при отображении она используется как статическая.

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

крутизна идеи налицо!
  (#15 (permalink)) Старый
Guderian Guderian вне форума
Member
 
Сообщений: 47
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 06.09.2002
По умолчанию 20.09.2002, 19:28

Цитата:
Originally posted by Jeezekil+-->
Цитата:
а че! для 70 процентов менеджеров наличие анализа дятлопосещаемости будет веской причиной покупки ситемы :lol:
Дятлоаналитика - это, конечно, здорово. Но ты глубже смотри. Если заранее каждой связи привязать некий аналитический вывод, то такие отчеты можно будет по посещаемости получать, что ох.

<!--QuoteBegin-Jeezekil

[b]То есть квадрат
Это смотря в какой системе координат
Закрытая тема

Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Trackbacks are Вкл.
Pingbacks are Вкл.
Refbacks are Выкл.




Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Нardforum.ru - компьютерный форум и программирование, форум программистов