egorinsk

Не проще ли нанять специального менеджера по мотивации и дать ему кнут? Или у вас не в офисе люди сидят?

Где-то в Яваскрипте бесконечный цикл

Надо запретить кеширование страниц, если пользователь залогинен.

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

ideone.com/2zVf8C

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

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

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

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

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

Referer смотрели? Может, просто кто-то на своем сайте разместил такую ссылку, а вы панику развели. Ну или у вас на странице есть форма с полем post как вариант.

Я считаю, что подстраиваться под косяки Гугла не самое разумное дело и надо просто игнорировать такие параметры — то есть, ничего не делать.

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

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

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

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

Не проще ли освоить алгоритмы вроде Nested Sets и подобных?

Если файл XML содержит ошибки, то это уже не файл XML.

Paypal придирается к вам или к вашим клиентам? Если к вам, то можно и потрепеть.

Как поменять образ деятельности:

1) Устроиться на работу в компанию, которая этим занимается, может вам разрешат хотя бы заваривать чай и разносить печеньки тамошним разрабочикам
2) Сделать свою успешную софтокомпанию, добиться известности и получить заказ на разработку какой-нибудь сложной системы.
3) Просто придумать какйю-то идею и пытаться ее реализовать.

«Хитроумное кеширование» — этого нет, кеширование не более чем костыль.

«Алгоритмы» — если вам интересны алгоритмы, решайте олимпиадные задачи, например на codeforces и читайте статьи по способы сортировки, поиска пути на графе, вроде на тему алгоритмов есть какой-то западный видеокурс по Computer Science.

Товарищу, который написал про геймдев, не верьте — российский «геймдев» не имеет ничего общего с компаниями врде Valve/id Software и занимается копипастингом зомбиферм, натягиванием моделей на купленные движки, убогоиграми для айфонов и прочей иногда впрочем хорошо оплачиваемой ерундой.

Про фриланс — тоже не верьте, там обычно задачи уровня «I need a plugin for my ecommerce site».

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

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

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

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

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

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

В таком простом случае — проще всего руками.

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

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

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

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

> 1. Я просто хочу, что бы IE678 игнорировали эти настройки, а именно использовали стили для 980px+ разрешения. Подходят ли данные средства CSS для этого?

caniuse.com/css-mediaqueries — IE 6-8 не поддерживают CSS media queries, потому они скорее всего будут игнорировать их. Для этого не надо дописывать ни одной строчки кода :) Соответственно, в Media Queries надо заключать условия для маленьких экранов, а без них — для больших.

> Какие разрешения вообще стоит использовать?

Имхо, только 2 разрешения: большой экран и маленький. Также, если вы хотите, чтобы айфон использовал стили для маленького экрана, а не имитировал большой браузер, надо дописать meta viewport что-то там.

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

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

Неизбежные накладные расходы.

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