ээ подразумевается, что относительная ссылка <a href='/...' разбивает сайт надвое - http://site.ru и http://www.site.ru, тогда как абсолютная может пришивать всё именно к продвигаемому варианту..
Да где ж этот чёртов инвайт надыбать то??! :)
насчёт 301го незнаю, на 404й выдаёт "битая ссылка". страницу, на которую ведёт 404 редирект, не обрабатывает (имхо это правильно. иначе битых ссылок не будет видно).
Уважаемый автор программы!
некоторые небольшие ошибки:
1) если на странице вида http://www.somesite.ru/something/some/thing.html
есть ссылка вида <a href='/'>
то программа пытается по ней перейти на страницу http://www.somesite.ru/something/some/
а должна переходить на страницу http://www.somesite.ru
в результате
а) имеем в списке битых ссылок кучу шлака,
б) если программа и вес туда сливает, имеем неправильный расчёт веса.
2) если на странице есть ссылка вида <a href='/это ссылка такая.html'>, программа обрабатывает её до первого пробела. это неправильно, т.к. такие url тоже работают.
а) пишет в битые - ссылку "/это",
б) неправильно вес считает, если так..
Уважаемый автор программы ещё есть небольшие пожелания:
а) список страниц перенумерован, а список битых ссылок - нет, в результате непонятно, скока ваще битых ссылок программа нашла - 1000 или 100000.. (это нада знать если хочешь сравнить кол-во битых ссылок с кол-вом фактически найденных, т.е. определить, насколько их многа и надо ли их исправлять).
б) было бы очень замечательно если бы можно было ограничивать прогу по глубине обхода: если сайт очень большой, иногда имеет смысл отрезать листья и всякий мусор (иначе прога месяц такой сайт будет парсить)
в) было бы очень здорово и замечательно, если бы в программе можно было задавать свою формулу слива веса, как, например, в yazzle можно задавать свою формулу подсчёта стоимости ссылки. :) ну это так.. с жиру побеситься..
пасибо ждём
новой версии
непорали спалить уже алго? :)
неплохо было бы ещё сделать, чтобы уже на этапе работы (а не после завершения этого этапа) было видно, с какой страницей или какой ссылкой на сайте программа сейчас работает.
просто иногда прога в поисках страниц в такие дебри на сайте залезает, что аж жуть берёт, за голову хватаешься - и откуда они, черти, все взялись.. :)
вот если бы при "получении данных" было видно, где прога лазает сейчас, её можно было бы тормознуть и сайт почистить.... надеюсь, понятно объяснил.. спасибо.
угу, и пирожки горячие.. :)
прочитал все статьи, всем кто запостил спасибо и + в овощ.
(статейки кстате так себе. курсач так ваще убожество. ну всё равно спасибо)
так вот, товарищи! :)
согласно любой из этих статей, тексты, написанные с использованием операторов вида { | }, распознать в один прогон нельзя, даже если привлечь на свою сторону всемогущую статистику -
при дополнительном условии, конечно, что таковые тексты грамотно написаны и грамотно размножены.
видимо, Де Сад имелл ввиду всего лишь тексты с синонимами, т.е. составленные прогами-синонимизаторами втупую.. и, видимо, по Зипфу их рубит - за счёт в первую очередь их неудобоваримости..
ну что ж, туда им и дорога, но это ведь сильно упрощённый подход к делу, товарищи. всё равно что заявлять типа:
KupluSsilki добавил 02.12.2009 в 19:29
гы, ты б ещё сказал - мол, "если всё в двоичный код перевести, то рунет это сплошные дубликаты - ведь кругом одни нули и единицы.. :)"
каждая статья это комбинация слов. каждая новая статья это новая комбинация слов.
алгоритмы-то есть, чё.. сравнивай попарно тексты в рунете, и ищи каждый заведомо неслучайный шингл (длиной пять например), вот тебе и весь алгоритм. :)
это будет кол-во страниц по рунету в квадрате, да помножить на сто строк длиной пять в рамках страницы.. :) т.е. 10E6*10E6*100=где-то десять в пятнадцатой степени строковых операций.
если на одно сравнение у нас уходит 0.01сек, всего суммарно для рунета имеем 275 миллионов лет работы на одной машине. :) но рунет постоянно растёт, а количество сравнений, соответственно, растёт экспоненциально там - с учётом прироста в 40%/год имеем около миллиарда лет попарных сравнений в следующем году. и где тут алгоритмическая разрешимость-то..
алгоритмическая разрешимость проблемы определения комбинаторных искусственных текстов существовала бы,
если бы существовал такой алгоритм, который может вычислять тексты-дубликаты быстрее, чем они появляются.
тут была высказана мысль что сайт может после массового снятия ссылок подняться.
у мну такое бывало. а кто-нибудь ещё замечал?
если бы устроили трансляцию таких проблем бы не было. да и второго семинара не потребовалось бы наверн.
бесит.. :(
...вообще говоря, количество семинаров надо брать из расчёта (количество_желающих/вместительность зала). возможно, там и двумя семинарами не обойдётся..
