egorinsk

Наверно хороший способ узнать это — изучить архитектуру существующих highload проектов. Держите ссылку: www.insight-it.ru/highload/

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

Выглядит, как будто кто-то отлаживает код и временно поставил var_dump(). Вы уверены, что это не временная проблема?

Если не временная. то разбирать, видимо, при помощи регулярок и (возможно) html_entities_decode.

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

class UserBlock {
public static function renderUserInfo($user) {
?>
… HTML код…
<?php
}
}

Пример использования:

<?php foreach ($users as $user): ?>
{div}<?php UserBlock::renderUserInfo($user); ?>{/div}
<?php endforeach ?>

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

Как вы себе представляете такое преобразование, если в PDF текст хранится строками с определенными координатами, а не абзацами, например? Также текст может храниться картинкой или векторным форматом. Таблицы хранятся набором кусков текста и линиями. Заголовок — просто строка текста чуть большего размера.

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

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

Резюмируя, выберите другой исходный формат, или откажитесь от мысли преобразовать PDF в осмысленный текст, преобразуйте его в картинку например. Иначе вы всю жизнь будете дописывать костыли, как только кто-то захочет подснуть вашей системе текст, сверстанный другим способом.

> его нужно загрузить на десяток разных сайтов, которые не поддерживают API

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

Сколько раз уже говрили людям, не сохраняйте пароли на фтп, не сохраняйте, все трояны первым делом лезут и выковыривают их, нет, все равно сохраняют. Ну не жалуйтесь теперь.

Есть мнение, что ценность большинства проектов далеко не в коде. Вот вижу я сервис, который мне понравился, например, вконтакте, беру N кодеров, даю им ТЗ, и через некоторое время получаю код.

Если же речь идет о более простом проекте, основанном на перепиленном Друпале/вордпрессе/форуме/whatever (пример: Хабр, рутрекер, Smashing magazine, Audiotuts), переписать его еще дешевле и быстрее.

Если кто-то очень захочет ваш сервис скопировать, он сможет это сделать, не имея доступа к коду.

> Так вот часто символы % и _ не заменяются и не экранируются, что приводит к следующему:

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

1) Соблюдать все рекомендации почтовиков, включая List-unsubscribe, настройку DNS, SPF.
2) Рассылать письма только тем пользователям, кто сам этого попросил (а не за кого поставили галочку или написали мелким шритом в углу страницы). Приличные сервисы первым делом просят подтвердить, нужна ли пользователю рассылка, а только потом шлют спам.

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

ideone.com/2zVf8C

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

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

Для шаблонов стоит использовать нативный PHP.

На PHP не стоит переносить подходы, применяемые в той же яве, когда на каждый чих содаются фабрики, объекты, билдеры и прочее. Это, конечно, возможно на PHP, но работает не очень быстро и пишется не очень быстро. Если вы не делаете мегапортал, то лучше применять более простые подходы.

Книгу про паттерны проектирования корпоративных приложений читали?

Вообще, как я понимаю, надо просто хорошо понимать что такое, как делается и зачем были придуманы штуки вроде N-tier architecture, MVC, DI, и принципы вроде loose coupling, DRY, KISS — по моему, это те теоретические вещи которые надо знать, и которых для веб-приложений достаточно, а дальше уже идет опыт вроде «мы использовали такой-то подход и наткнулись на такие-то недостатки».

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

И не стоит ограничиваться условием «именно на PHP». Архитектура она на то и архитектура, что не привязана к конкретному языку.

Правильное, но невыгодное финансово решение: не нанимать быдлокодеров и переделать сайт.

Быстрое и дешевое решение: написать/прикрутить фильтр, который не будет пропускать запросы со словами SELECT, where, JOIN, UNION (в любом регистре), script, onload, onerror, onmouseover (и все остальные JS-события), object, applet, iframe, frame и так далее. Список слов ищите в интернете. Если ваши посетители, например. общаются на русском, очевидно, такие слова они вряд ли используют.

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

Также, если вы умеете администрировать linux, можно на сервере засунуть веб-сервер и сервер БД в отдельные контейнеры и изолировать их (или даже selinux включить). Плюс зафаерволлить намертво. Это вообще идеальнй вариант — даже если ваш сайт представляет один большой бекдор, взломщик не сможет получить из него никакой выгоды. Если правильно настроить сервер, фаерволл и изоляцию, для написания кода можно нанимать хоть школьников.

> (не хочется, чтобы DDoSом на веб-морду можно было положить демона)

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

> Как именно лучше организовать взаимодействие между двумя этими серверами (RPC, Socket, что-то еще)?

Можно через HTTP/1.0 + JSON, например. Или бинарный протокол, если есть желание выжать максимум, но тогда надо демона переписать на Си.

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

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

Если речь о чужом кое-как написанном коде, то поиском по файлам.

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

Хотите schemaless? Просто делаете одну таблицу entities с 3 полями: id, type, blob (в blob сваливаете JSON версию объекта). Но вообще, schemaless — крайне дурацкая идея. БД предлагает дополнительный уровень проверки и организации данных, а ленящиеся изучить язык SQL кажем так, юные программисты, кричат, что им этот SQL не нужен.

Естественно, предложить нормальную альтернативу проверенным надежным решениями никто не может, а монго выглядит как примитивный Key Value storage с яваскриптом для игроделов (ибо эти товарищи даже SQL осилить не смогли). Все серьезные организации используют SQL.

PDO из коробки малоюзабелен и неудобен: не считает время и статистику запросов, не поддерживает ленивого соедиения, пула соединений, транзакций, нормальных плейсхолдеров. потому обертку писать стоит в 90% случаев.

А вот написать обертку, позволяющую прозрачно для кода менять СУБД, у вас не получится. В MySQL есть LIMIT, INSERT ON DUPLIATE KEY UPDATE и куча вещей, которых нет в других БД. Что вы с ними делать будете, чтобы заставить работать в оракле?

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

А клиент дергает простой скрипт, который проверяет по это таблице прогресс в процентах и выводит.

Я вам настоятельно рекомендую перед написанием своего велосипеда хотя бы ознакомиться с существующими способами решения.

Если бесплатный хостинг не позволяет запускать демоны, проще поменять его на нормальный VPS, а не изобретать неэффективные костыли.