Balancer: Все сообщения за 7 Октября 2004 года

Но закачка пошла. Из pitt2 выкачалось 50Мб и из mig-25 - 38Мб.

Совместно и интенсивно качается упомянутый чуть позже aviation.-.su-27.flanker,.the.sukhoi.story.-.dd.video.-.film.in.english.-.by.redskies.avi Сейчас скачанные мною куски от меня 4 человека тянут

•  инфо
•  инструменты
• Ответить на сообщение

В принципе, вроде, одного IP достаточно должно быть - 83.237.174.69 порты стандартные - TCP=4662 UDP=4672

•  инфо
•  инструменты
• Ответить на сообщение

TEvg>А почему мой Seagate пальцы обжигает? Что за необходимость? Объем обеспечивает?

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

•  инфо
•  инструменты
• Ответить на сообщение

WiTL>Фаулз - не американец?

Англичанин.

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

WiTL>Просто беру Европу отдельно от России.

Тогда совсем непонятно

•  инфо
•  инструменты
• Ответить на сообщение

Начну пока рассуждать в конкретных направлениях.

Итак, мысли сейчас такие.

• Каждый объект системы, будь то страница сайта или топик форума может быть (задаётся или разработчиком, в случае страницы, или администратором, в случае форума) разного формата. Например, статику проще всего класть в HTML, динамику - в PHP и т.д.
• По умолчанию для большинства нужд предполагается статический HTML. Всё же, разница в быстродействии, даже при использовании всевозможных акселераторов, порой, идёт на порядки. Особенно, если сервером стоит не Апач, а что-то более скоростное.

Встаёт вопрос адресации этих страниц. Их где-то нужно хранить. Если для форума это не проблема, каждый топик выделяется номером, по этому номеру его и хранить можно, для скорости, ещё и порезав, скажем, на подкаталоги - site.ex/forum/0/1/2/5/012507/ то для сайта всё становится несколько сложнее. Во-первых, я сторонник "человекопонятных URL" ("ЧПУ"). Т.е. чтобы не ничего не значащие цифры в идентификаторе, а нормальное название, пусть и латиницей (хотя было бы хорошо, если бы к моменту завершения системы, большинство серверов по умолчанию поддерживало бы UTF-8, тогда и с национальными символами в URI никаких проблем бы не было - сами URI давно уже в UTF-8 по стандарту). Особенно этот вопрос актуален для меня, т.к. имеется уже развитая структура сайта со множеством ссылок. А потеря имеющихся URL для меня одна из самых больших неприятностей

Располагать же страницы по привычным каталогам не годится, т.к. это весьма усложнит чистку кешей и т.п. Т.е. страницы должны храниться в одном месте и по одному формату.

Выход я вижу пока такой: новые страницы располагаются в отведённом им месте, но не в деревьях, а плоско, с нарезкой по MD5 от их "виртуального пути". Т.е. бывшая страница вида "/hangar/russia/soukhoi/su-27" превратится во что-то типа "/cache/a/4/2/c/hangar-russia-soukhoi-su-27/"

(Да, лучше использовать формат с документами по умолчанию, чтобы всегда можно было быстро и безболезненно поменять формат документов, скажем, .shtml на .htm)

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

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

В общем, решение не столь очевидное.

Ещё одна промежуточная альтернатива - основными ссылками является, всё же, древовидная классическая структура, но обработка ссылок идёт общим скриптом. В общем, как сейчас, за той лишь поправкой, что скрипт не будет заниматься никакими извлечениями из БД и т.п., а будет тупо хешить запрашиваемый URI, получать из него новый URI в кеш и или переадресовывать запрос туда или загружать получившуюся страницу. Во втором случае, кстати, можно ещё кешировать и готовый gzip-пожаты вариант, несколько разгрузив сервер.

Но это всё равно будет медленнее, чем чистая статика.

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

•  инфо
•  инструменты
• Ответить на сообщение

Сейчас имеется полнофункциональная CMS (система управления контентом), частично интегрированная с форумом iPB. Особенности:

• Релизована объектная модель на базе MySQL. Движок выполнен в виде внешнего драйвера (хотя и весьма массивного) на двух уровнях:
• MySQL-интерфейс для простейших операций (вставить значение, извлечь значение и т.п.) - объём файла всего 258 строк. Фактически, переход на иные способы хранения (другие БД, plain/text файлы и т.п.) выполняется, в основном, его заменой. чтобы проще ссылаться - имя файла DataBase.php
• Интерфейс моей CMS - надстройка над DataBase.php, реализующая объектную модель. Т.е. для каждого объекта (страница, картинка и т.п.) есть набор атрибутов (ширина картинки, дата модификации страницы, URL страницы, описание, список родителей, список детей и т.п. - всего уже десятки параметров). 464 строки. Требуется доработка, т.к. есть несколько прямых запросов к MySQL минуя DataBase.php. Имя файла - DataBaseHTS.php (HTS - давнее обозначение моего формата разметки, ещё когда он был локальным, несерверным. HyperText Source)
• Модуль кеширования Cache.php - позволяет сохранять готовые наборы данных для быстрого их последующего извлечения. Сейчас хранит в MySQL, но легко может быть переписан на любой формат. Всего 60 строк.
• Модуль кеширования в памяти global-data.php - 40 строк. Используется для временного хранения данных модулями DataBase.php и DataBaseHTS.php для упрощения работы готовых скриптов - можно не задумываясь о временном хранении каждый раз извлекать нужные данные "из БД" (на самом деле, при повторном вызове из текущего скрипта - будет задействовано уже считанное значение)
• lcml.php - большая и гибкая система гипертекстовой разметки исходников. Т.е. преобразование HTS и BB-кода в HTML. Полноценный парсер, не регекспы. Соответственно, полноценно отрабатывает вложения, использование разметки в параметрах разметки и т.п. Сам файл 304 строки. Только парсер. Сами обработчики разметки подключаются из внешних, автоматически подключающихся файлов. Поддерживает следующие типы файлов:
• Файлы предварительной обработки, перед отработкой тэгов (скажем, преобразовать URL в квадратных скобках в нормальный вызов URL-тэга и т.п.) Порядок исполнения файлов может задаваться по их именам (обрабатываются по алфавиту)
• Файлы обработки тэгов двух форматов:
• Классический BB-код, как однотэговый ( [ br ] ), так и двухтэговый ( [ b ] ... [ /b ])
• Мой старый HTS-формат (#a Имя автора и т.п.)
• Файлы постобработки. Например, заменить все оставшиеся незаменёнными URL'ы на автоматические ссылки, с утягиванием их с сервера и т.п.

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

lcml-модуль написан довольно давно и часть кода сейчас довольно неряшлива, потребуется оптимизация и перепись (хотя недавно уже оптимизировал, повысив быстродействие раз в 50 )

• Система показа страниц пока совершенно виртуальная. Т.е. идёт rewrite для всех URL и перехват отсутствующих URL и перевод их в скрипт показа страниц. Тот на основе имеющегося URI выдёргивает нужную страницу из БД, оттуда же извлекает шаблон (шаблоны - обычные страницы системы), парсит шаблон через Smarty (с кешированием) и выдаёт в браузер.

Не смотря на реально большое число запросов к БД (в среднем - 40..60 против 10..12 у этого форума, скажем) запросы все простые и время генерации страницы обычно в несколько раз меньше, чем время генерации страницы форума.

Реально систему в работе можно увидеть на Авиабаза или Сайт расходящихся тропок // Balancer.Ru

Наверняка много чего ещё упустил - добавлю позже

•  инфо
•  инструменты
• Ответить на сообщение

Yuran>"Финансовый баланс Авиабазы - минус 150 дней хостинга"
Yuran>Нас что скоро прикроют? где собираться то будем ? :huh:

Да нет, просто я из своего кармана покрываю эти расходы

•  5
•  инфо
•  инструменты
• Ответить на сообщение

SergeVLazarev>А не скажи. ИМО Ан-124 один из самых востребованных самолетов.

Какой процент транспортных перевозок (можно даже в тоннокилометрах) выполняют Ан-124?

•  2
•  инфо
•  инструменты
• Ответить на сообщение

ПАСЕ приняла негативную резолюции о состоянии прав человека в Чечне

07.10.2004, 16.37

СТРАСБУРГ, 7 октября. /Спец. корр. ИТАР-ТАСС Юрий Ульяновский/. Парламентская ассамблея Совета Европы /ПАСЕ/ согласилась сегодня с оценкой автора доклада о состоянии прав человека в Чеченской Республике Рудольфа Биндига /Германия/. В принятой сегодня по этому докладу резолюции состояние прав человека в Чечне названо "катастрофическим".

Российская делегация подготовила особое мнение по докладу и предложила целую серию поправок. Однако почти все они были отвергнуты ассамблеей без долгих обсуждений. Европарламентарии проголосовали даже поправку, которая была включена совсем в другой список. Глава российской делегации, председатель думского Комитета по международным делам Константин Косачев считает, что при составлении документов их автор Рудольф Биндиг отнюдь не руководствовался стремлением внести вклад в урегулирование ситуации в Чечне и помочь людям.

Резолюция, как и представленный вниманию ассамблеи доклад на эту тему, выдержана в худших традициях прошлых лет и даже дословно повторяет некоторые положения документов, подготовленных ранее Биндигом на эту тему. Авторы документа утверждают, что в Чечне продолжаются "массовые нарушения прав человека", царит "обстановка полной безнаказанности".

// ИТАР-ТАСС : Страница не найдена / Page not found

•  1
•  инфо
•  инструменты
• Ответить на сообщение

В федеральный розыск объявлен офицер милиции, которого подозревают в избиении А.Пуманэ

В федеральный розыск объявлен офицер милиции, которого подозревают в избиении Александра Пуманэ. Как сообщает "Эхо Москвы", столичная прокуратура заочно предъявила обвинение майору Вячеславу Душенко в превышении должностных полномочий и причинении тяжкого вреда здоровью. Столичные прокуроры считают Душенко соучастником преступления, совершенного в ОВД "Пресненский". Напомним, именно туда был доставлен Александр Пуманэ после того, как его задержали в Москве в машине со взрывчаткой. Позднее он скончался от побоев

// Труд: Ошибка 404 (страница не найдена)

•  инфо
•  инструменты
• Ответить на сообщение

Valeryk>Замечательная цитата:

А ты знаешь хоть один пример работы любой службы в мире, где на празднике бы говорили "у нас всё плохо, всё неправильно, мы идиоты и надо нас всех поувольнять"?

•  инфо
•  инструменты
• Ответить на сообщение

SergeVLazarev>Что за намеки про коноплю?

Подпись у тебя, плюс недавно слышанный анекдот

SergeVLazarev>ЗА_СЧЕТ_ЧЕГО???

Скажем так - минус 10 Су-24 и плюс 50 МиГ-27М. Было бы весьма неплохо на мой взгляд. А так - ни того, ни другого реально нет. МиГ-27 порезали, а Су-24 - дорого.

SergeVLazarev>Насчет Ту-22М. Если бы стал вопрос - Су-24 или Ту-22М, как по-твоему решился бы вопрос?

С твоим подходом - Ту-22М. Остались бы в результате в Чечне вообще без авиации.

SergeVLazarev>а вот ФАБ-1500 в афгане на Су-24 была рядовой загрузкой.

ФАБ и КАБ - это как бы несколько разные вещи. В смысле - принципиально по отношению к мощности.

•  3
•  инфо
•  инструменты
• Ответить на сообщение

>>Хотя по "чистому" штурманскому расчету дальность полета МиГ-27М с полной заправкой только внутренних баков составляла 1750 км, а радиус действия с 1000 кг бомб - 800 км, в реальной обстановке приходилось принимать во внимание дополнительный расход топлива с учетом особой процедуры взлета, время, необходимое на сбор группы и, главное, поиск целей, который проводился исключительно самостоятельно
SergeVLazarev>400 км с ПТБ и 1000 кг бомб. Небольшой радиус. Да еще и по высокому профилю.....

Во всех источниках даётся радиус действия 580км по маловысотному профилю и до 800 по большая-малая-большая. Приведи источник своих данных. А то что-то ты совсем "один в ногу" пошёл...

•  инфо
•  инструменты
• Ответить на сообщение

davinchi>Я не помню чтобы Конгресс США призывал бы граждан к стукачеству

Я не про "де юро" (хотя уверен на 99.9%, что если поискать, то что-то подобное в последнее время найти можно - просто искать лень), а про "де факто". В т.ч. по отзывам тех, кто там живёт из присутствующих на Авиабазе.

•  3
•  инфо
•  инструменты
• Ответить на сообщение

В Долгопрудном бомбу подложили на подоконник одной из квартир
07.10.2004 16:42
Неустановленное взрывное устройство было подложено на подоконник одной из квартир жилого дома, находящейся на первом этаже. Об этом говориться в сообщении пресс-службы администрации Московской области, со ссылкой на заявление начальника Долгопрудненского ОВД О.Прокошева.

7 октября самодельное взрывное устройство сработало в подмосковном Долгопрудном около 9-этажного жилого дома, расположенным на Заводской улице. В результате взрыва осколками разбитого стекла ранена жительница квартиры первого этажа. В настоящее время, по словам врачей, жизнь женщины вне опасности.

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

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

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

Напомним, что бронированный "Мерседес" с дагестанскими милиционерами подорвался на фугасе в Подмосковье 6 октября.

// НТА-Приволжье ::

•  инфо
•  инструменты
• Ответить на сообщение

Vanish>Ок, тогда потихоньку начну задавть вопросы...

Поехали

Vanish>в общем то исходя из Smarty и ADODB, получается что только PHP, потому как эти вещи PHP ориентированы =)

Да у меня это как бы подразумевается. Особенно - учитывая нынешнюю распространённость языка Просто, на всякий случай этот вопрос открытым оставляю

>а допустим рутинные вещи вроде перевода старых топиков в статичный арихив можно и на Perl сделать.

В этом смысле Perl ничуть не лучше PHP Так что - без особой разницы.

Vanish>Не очень ясно про промежуточный интерфейс. Если я правильно понимаю будет попытка создания универсального интерфейса позволяющего работать с различными решениями вроде ADODB. Имеет ли это смысл?

Функциональности ADODB очевидно мало Во-первых, это уже явная заточка под SQL, что не обязательно для малых и мредних систем (моя система благополучно жила на плоских файлах года два, если не три ), во-вторых, там недостаёт функциональности. Так что вылезают следующие уровни:

• Уровень абстракции БД (без привязки к SQL!) - либо полностью автономный (как сейчас), либо надстройка над тем же ADODB, чтобы одним драйвером обеспечить, скажем, совместимость сразу с рядом SQL-систем
• Уровень работы с объектами, надстройка над ДБ-драйвером. Лучше не совмещать с ним, т.к. позволит вынести много общего кода, упростив написание драйверов под иные форматы хранения данных.
• Собственно, уровень приложения, когда скрипт системы обращается к БД, извлекает что надо и т.п.

Ну, от балды, простейший реальный пример:

1. <?
2. $page = 'http://airbase.ru/hangar/';
3. $hts = new DataBaseHTS();
4. $title = $hts->get_data($page, 'title');
5. ?>

Класс DataBaseHTS при создании, если нужно, создаст экземпляр класса доступа к БД, если уже таковой есть - возьмёт ссылку на него из глобального кэша.

метод get_data() - нормализует URL, считает идентификатор, соответствующий этому URL, заберёт данные, хранящиеся в нужной таблице. Если же такие обращения уже были, то заберёт данные из кеша.

Вообще, высокий уровень абстракции делает программирование системы очень простым и компактным, а за счёт возможности потратить свои временные ресурсы на оптимизацию алгоритмов - ещё и быстрым. Скажем, весь код вывода страниц сайта у меня укладывается в 158 строк (работа со Smarty).

Vanish>phpBB скины достаточно близки по идеологии к шаблонам Smarty, чего не скажешь о IPB. Стоит ли вообще заниматься этой проблемой, ведь можно убить кучу времени и при том не получить универсального конвертера.

ИМХО, стоит. В случае успеха выигрышь будет колоссальным. Сотни скинов от основных фаворитов. От лаконичных phpBB до наворочанных iPB.

В случае iPB, конечно, придётся повозится, но оно того стоит.

Vanish>Далее одной из задач которая ставится - скорость работы. Smarty и ADODB функциональны, но и в то же время снижают скорость работы. Более того наврятли будут использоваться более 50% возможностей того же Smarty...

Ну, у меня пока Smarty только ускоряет работу и мою и скриптов Во-первых, у него очень хорошая система кеширования, которая легко управляется моим движком, во-вторых, он очень экономит время разработки. Я не на 50%, я, дай Бог, на 20% использую этот движок. Но я на нём сэкономил, м.б. месяц времени разработки и имею очень хорошую производительность

>ADODB универсальная обертка для работы с различными БД серверами, это хорошо с одной стороны свобода выбора, но с другой стороны пользователь будет использовать в конечном итоге определенный сервер и лишний функционал по поддержкуе скажем Oracle или PostgreSQL ему уже не нужен будет.

Вот про ADODB ничего не скажу, сам его прямо не использовал, только в сторонних продуктах.

Но всё ещё проще. Драйвер БД будет отдельным и изначально ориентированным на MySQL (хотя бы потому, что ADODB сейчас не совместим с MySQL 4.1.x, который я использую ), но его, после переноса в него части кода из объектного драйвера, будет легко переписать под любую систему. Как нативную БД, так и универсальный лейер. В любом случае непосредственно сейчас я этим заниматься не буду Нам бы запустить функционал форума на MySQL

Vanish>Остальные наработки читаю, из них вывод сделал, что будет использован ООП подход при разработке, очевидно, что что то очень близкое к MVC модели.

Не слышал про MVC, или слышал, но не ассоциирую название

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

Сейчас система подключаемых модулей реализована в компиляторе языка разметки. Там все модули подключаются разом. Пре- и постобработка просто обрабатывают текст. Функции обработки тэгов компилируются, и вызываются парсером по мере надобности (т.е. обработка тэгов, которые не встречаются в тексте не происходит)

Что приходит в голову по дальнейшей декомпозиции:

• Вынос в модули функций создания страниц (т.е. тот же нынешний Smarty-модуль)
• Разделение нынешнего объектного модуля на три части (считывание данных, запись данных и обработка данных) и вынос их в отдельные модули. Это позволит легко и прозрачно переключаться от одного метода хранения данных к другому.

>Что понимается под ядром системы и какие функции оно должно реализовать.

Связка всех модулей

Vanish>В голове еще крутятся вопросы, уже более по техническому подходу, но они наверное могут быть сформированы только после того как узнаю ответы на более общие вопросы.

Ещё поройся в топике Что есть работающего в данный момент

•  инфо
•  инструменты
• Ответить на сообщение

Vanish>Имеется ввиду вывод содержимого ветки, потому как списки форумов и списки тем в форумах из статичной информации содержат только название, а счетчики ответов/тем, даты последнего ответа как бы к неизменяющейся данным не относятся. Не говоря уж о том что когда в топик добавляется ответ
Vanish>он должен в списке подниматься наверх...

Это всё на статике реализуется легко. При каждом изменении топика, скажем, система перестроит и страницы, которые от него зависят - список топиков форума, список форумов, страницу последних изменившихся и т.п.

Другое дело, что я, всё же, не уверен ещё, что полностью статический контент оправдан. Это, вдобавок к уже упоминавшимся проблемам, создаст проблему проверки обновлений и т.п. Скажем сейчас, при изменении в скине, все страницы автоматически и незаметно для поситителя перекомпилируются при первом обращении к ним. Ну, подумаешь, грузится она не за 0.06 сек, а за 0.6 А с HTML всё будет смотреться некрасиво - JavaScript в начале страницы проверяет версию, если изменилась - запустит перекомпиляцию, а страница-то к этому времени уже грузится, уже показывается - т.е. будет лишний релоад и т.п.

Т.е., возможно, я остановлюсь, всё-таки, на версии, при которой контент будет храниться статическим, но отдаваться будет общим скриптом. Т.е. так, как реализовано сейчас. Разве что управление отдачей перенесу со Smarty на свой код.

Vanish>Кстати довольно интересный подход в выводе содержимого топиков сделан на ixbt и forum.3dnews.ru. Там за построение страницы отвечает JavaScript, выигрышь в трафике, ну и генерация осуществяется на стороне клиента, хотя тут больше экономия на спичках чем реальный плюс подхода.

Это абсолютно неприемлимый способ На сегодня ещё довольно много браузеров, не поддерживающих JavaScript, а дальше их будет ещё больше. Тот же рынок КПК и смартфонов. Да и Опера с их форумом совсем недавно только заработала.

•  инфо
•  инструменты
• Ответить на сообщение

Новая работа Акуаку

Кто догадается, к какому это произведению?
Я, тормоз, сразу не догадался...



Хотя название картины, казалось бы, столь очевидно...

•  1
•  инфо
•  инструменты
• Ответить на сообщение

TEvg>Так же в 90% случаев ношение прозрачных маечек выше пупа имеет следующие объяснения - так модно, это круто, так все ходят - что довольно ясно характеризует умственные способности носительниц таких маечек, заниматься же научной работой они не способны.

Я как бы знаю несколько случаев, когда девушки из этой категории занимались именно научной работой и занимались хорошо

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

•  инфо
•  инструменты
• Ответить на сообщение

исправил

•  инфо
•  инструменты
• Ответить на сообщение

На глаза посмотри Потом - на название

•  инфо
•  инструменты
• Ответить на сообщение