С экранированием да, проблема. А вот вторая, кажется, частично решена. Недавно был пост о phpdaemon, с помощью которого как-то (так и не вник ещё) реализуются песочница.
А в качестве хобби — опишите в чём суть проекта, может у профессионального дизайнера такое хобби и он согласится помочь, потому что ему интересно будет работать (грубо говоря, он второй, после вас, пользователь вашего сайта :) )
Английский будет именно перевод (то есть русская статья есть всегда, а английской может и не быть) или абсолютно независимый контент (может быть английская без русской)? Если перевод, то должен ли совпадать url у статей? Расширение списка языков возможно или ровно 2 на 100 лет вперёд?
XSLT интересный вариант, но сколько раз не пытался освоить на живых проектах, всё как-то не идёт, видимо потому, что приходится решать две задачи одновременно — представление объектов/массивов в виде XML (например решать, должен ли контроллер выдавать один XML файл, где есть всё для формирования страницы, или допустить вызов других контроллеров из шаблона (да ещё непонятно как это лучше сделать), то есть распределить ответственность между котнроллерами, представлять значения полей в виде атрибутов или вложенных элементов и т. д. и т. п.) и преобразование его в HTML (вроде сделал удобно читаемый человеком XML, но начинаешь вытягивать из него данные и ужасаешься на XPath).
А распарсенные шаблоны можно, наверное, хранить в кэше типа memcache или xcache/eaccelerator.
Винда известна своим дефолтным стремлением освобождать физическую память даже когда это не требуется текущим сценарием использования. За 10+ лет знакомства с WinNT 4+, ни разу не видел, чтобы своп файл вообще не использовался (если он включен :) ), особенно если есть неактивные процессы — такое ощущение, что винда старается освободить память для возможного запуска другого приложения заранее, чтобы избежать обвинения в большом времени запуска…
Ну, крупную информационную систему писать без знания языка естественно не очень разумно, но относительно простые CRUD приложения (типа «бложика») я могу написать на многих языках (используя фреймворки, конечно и документацию к ним), но Java в их список не входит. Вообще самыми полезными, имхо, являются обучающие статьи/книги, показывающие разработку простенького, но законченного приложения, в котором реализован часто встречающийся функционал. Чуть ли не идеальным в этом плане считаю цикл статей про php фреймворк symfony — www.symfony-project.org/jobeet/1_4/Doctrine/ru/ посмотрите, может общая подача материала понравится
Везде уже года 3 используем utf8 и никаких проблем с файловыми системами и ftp клиентами (хотя лично я предпочитаю просто монтировать удалённый каталог локально), без всякой дополнительно настройки — что мы делаем не так?
В SVN (наверняка и других системах тоже) есть разграничения прав доступа для разных пользователей, правда у нас такая задача не стояла, поэтому про подробности, насколько она полноценна и удобна, не скажу, знаю только что при использовании апача есть возможность устанавливать доступ на уровне папок.
Заставить коммитить просто: нет файла в репах — работа не сделана, нет ни одного коммита за день — считай прогул :) Заставить делать чекаут перед правками, да даже просто перед чтением, сложнее (особенно если совместная работа допускается, но по факту редко применяется), но после разрешения нескольких конфликтов версий, которых можно было бы избежать своевременным чекаутом, или «просто» принятия неверных решений из-за устаревшего документа (новая версия которого уже месяц лежит в репах) как-то все быстро привыкают делать чекаут хотя бы утром, в начале рабочего дня (а коммиты, соответственно, вечером, в конце).
У вас, судя по всему, Windows, тут только в теории могу подсказать:
— создаёте нужные иерархии папок, например Менеджер/Заказчик/Проект/ТипИнформации, ТипИнформации/Проект, Заказчик/ИсходящийНомер, Год/ИсходящийНомер и Год/Проект/ТипИнформации
— одну из них (как правило самую детальную и с которой чаще всего приходится работать, ) назначаете главной, именно в ней физически файлы создаются
— при создании файла в главной в соответствующих дополнительных директориях создаются ссылки на него (в винде, кажется, пкм-отправить-создать ссылку, в итоге получаем файл .lnk)
В принципе решение чисто административное (в смысле управленческое), у нас, например, издали приказ по фирме «Об обороте электронных документов», провели краткий ликбез по SVN и некоторым функциям ОС и обязали всех работать именно так. Сотрудники повозмущались, но после пары «показательных порок», когда начальство не нашло нужных документов в ожидаемых местах, свыклись. Ну а потом написал небольшой скрипт для автоматической генерации ссылок, который повесил в контекстное меню «проводника» — простая форма, где на основе пути к «главному файлу» заполняется часть «тегов», другая часть заполняются вручную и по нажатию ОК генерируются все нужные ссылки на основании «тегов». Сложность с «тегами» была только для исходящих номеров, но решили опять административными методами, запретив сотрудникам отправлять/принимать официальные документы самостоятельно, только через секретариат. SVN сложнее было внедрять, но в основном потому что нет нормального просмотра различий версий для многих используемых типов документов — для чего-то нашли нормальные решения, где-то костыли, а где-то бегают между компами. А вообще главная сложность была (да и остаётся) разобрать существующую «помойку», но народ понял преимущества и довольно активно в свободное время систематизирует свои материалы.
Может быть не вина руководителя, а стратегическое решение: получить, например, 80 человеко-часов заплатив за 64, то есть держать только 8 работников (работающих по 10 часов), там где, по-хорошему, нужно 10 (работающих по 8 часов) — 20% экономии на фонде ЗП
Придерживаюсь мнения, что если проект требует использования БД более серьезного, чем «простое» хранилище данных с минимальным интеллектом (типа SELECT a+b AS c FROM ...), то значит в проект пора приглашать программиста БД. Исключения, имхо, редки и чаще всего тот же функционал можно реализовать малой кровью (при нормальной архитектуре) и на «обычном» ЯП, пускай с немного меньшей эффективностью выполнения, но с куда более понятной «простому» программисту поддержкой. Может я и не прав, и «простой» программист обязан хорошо знать и эффективно использовать все тонкости целевой БД, а не ставить DBAL, а затем ORM поверх него, но я предпочитаю ставить, а при просмотре чужого кода задавать вопросы «А так ли необходимо было завязываться на конкретную версию конкретного движка? Сколько выиграли, 5%?»
Ваш случай попадает, по крайней мере если нет явного запрета на модификацию конфигурации, если есть, то сложнее — не понятно к чему относится «если иное не предусмотрено договором с правообладателем» — то ли ко всему пункту, то ли только к исправлению ошибок
Mongo эффективен, когда один объект (или массив объектов) можно вложить в другой и первый без второго не имеет никакого смысла. Примеры — профиль в учётной записи, комменты к постам, адреса и телефоны в адресной книги. В таком случае связанные данные хранятся вместе и осуществляется, грубо говоря, одна операция поиска по идентификатору («первичному ключу») и получения объекта (с разной глубиной вложенности в зависимости от цели запроса) — эффективность можно сравнивать с денормализованной РСУБД. Если же используются ссылки («внешние ключи»), то таких операций нужно производить несколько — по сути от JOIN ничем не отличается. Хотя, конечно, можно денормализовать и Mongo базу или использовать для вашего примера в качестве «первичного ключа» категорий их название, а в качестве первичного ключа сайтов их урлы (тогда типичные задачи «вывод деталей сайта и названия его категорий» и «вывод деталей категории и урлы входящих в неё сайтов» будут осуществляться за одну операцию)