Виктор Кузнецов

Вы такие варианты как Яндекс.Метрика или Google Analytics не рассматриваете?
Они дадут более качественную картину, чем ваше решение, слишком много всего нужно учесть чтобы получить качественную статистику.

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

а вот та же идея, только через css display

Отпишусь пожалуй о своем опыте.

Ситуация схожая, но изначально товаров нужно было 250 кпозицией. Анализ коробочных решений (который не я делал) показал, что либо коробка на таких объемах не может гарантировать быстрой работы, либо производители коробки хотят таких денег на энтерпрайз, что пилить свое дешевле. Собственно чем в настоящее время и занят.

Свое требует времени, но позволяет полностью контролировать движок и быть точно уверенным в нагрузках, которые он потянет. Кроме того гарантирует более выгодную схему модификации движка, т.е. супорт движка становиться проще как технически, так и финансово. А сапорт движка собственно и есть основная статья расхода для ПО. Что удалось получить на данный момент, так это каталог. Т.е. дерево категорий, карточки товара, админка для менеджеров (создать товар, добавить к товару атрибуты). Количество товаров не ограничено, количество и тип характеристик товаров так же не ограничено и ведется через админку (т.е. дополнительно кодить ни чего не нужно). Нагрузочные тесты показали, что при ~200 МБ ОЗУ под PHP движок держит 300 запросов/сек (при попадании в кэш страница генерится за 10-15 мс) долговременно (т.е. где-то до 25 миллионов хитов в сутки) и может держать пик в 1000 запрос, но не дольше 5 сек, потом начинаются валится 50-ые. Это при каталоге в 250 кпозиций по 10 характеристик на товар. В целом вся связка (веб сервер, субд, кэш) кушает 1-1,5 ГБ ОЗУ. При этом полная развязка данных и шаблонов, поэтому можно иметь сколько угодно вариантов верски, т.е. ни какой смеси из php+html нет.

Поэтому в нашем случае напиливание своего показывает себя оправданной стратегией. Я вот не вижу, каким образом можно было бы получить подобные показатели на коробочных решениях, пусть даже и допиленных. Потому как пилить ядро коробочного продукта нет смыла, а без его запилки архитектуру не изменить. Ну и модифицировать свой продукт все же проще, чем супортить чужое + дописывать под него модули.

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

Ждём совета «Comic Sans».

Если по делу, то будущее, киберпанк, фантастика — это ifont.ru/font-2297-0.html. Но он без киберпанка — шрифты советом выше лучше подходят под то определение.

Вы не поверите, но иногда на один запрос может быть и десяток вьюшек. Самый простой пример — разный тип возвращаемых данных (xml, html, json, etc.)

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

Также, вопрос, кто запрещает для разных действий использовать (если требуется) один шаблон? Никто не запрещает.

В любом случае, писать по 2 раза/кописпастить код — это неправильно.

Вот вам код что я наделал, хочу чтоб мой код работал вот так: скажите что мне делать.
Если хотите помощи, задайте вопрос правильно. Очень неинтересно копаться в чужом коде чтоб понять:
1. Чего человек хочет
2. Какие «различные проблемы» возникают
Итд.
Заведите себе обьект нечто типа:

var WindowManager = {
    windows: {
        'firstId': {'width': 100, 'height': 100, 'x': 100, 'y': 100},
        'secondId': {'width': 100, 'height': 100, 'x': 100, 'y': 100},
    },
    addWindow: function('id'){},
    checkWIndow: function(id){},
    attachWindow: function(id){},
    ...
}

В итоге логика станет понятней и короче.

Имхо, обычные способы бана по телефону бесполезны. Просто очень хорошо знаком с работой досок «изнутри» и с методами работы этих самых «некоторых товарищей».

Вот что эти товарищи будут делать, когда увидят сообщение «объявление не размещено, т.к. ваш номер телефона забанен на нашем сайте!»? Да они тупо возьмут другой номер и запостят своё объявление. И так до следующего раза.

На одном из своих проектов я решил проблему по-другому. Задача такая: максимально достоверно опознать «нехорошего человека».

Что я для этого делаю?

Если пользователь указал для своего объявления номер телефона, который у меня в чёрном списке, я:

1. ставлю ему бессрочные Cookie с меткой что данный пользователь — тот ещё петрушка;
2. также запоминаю в базе максимальное количество идентифицирующих его данных (IP, юзер агент браузера и т.д.);
3. его объявление сохраняю в базе и помечаю его как «полускрытое». Это значит, что объявление видно исключительно ему, для него создаётся видимость, будто всё прошло успешно и объявление опубликовано. На самом же деле, всем остальным пользователям сайта оно не показывается (в том числе незалогиненным);
4. если «нехороший человек» догадался, что я его обманул и теперь он вбивает очередной свой шлак, то, используя пункты 1 и 2 я снова его определяю, заношу в чёрный список уже новый номер, повторяю по новой пукнты 1 и 2.

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

сохранять яваскриптом в куки

1. На шифрованном разделе диска, доступном через CRM.
2. А чем плох договор Лебедева? Берите его. Ну или напишите свой. Вы ведь уже определились как будете работать с клиентом и исполнять свои обязательства?
3. Т.е. человек, который у вас будет заниматься фирстилем, никогда в жизни его не делал и у него нет ни портфолио, ни нужных шаблонов и т.д.?
4. А как вы будете проверять правильность задания, если вы не знаете кто вам нужен и ничего не понимаете в php? Добиться верного результата можно 10 разными кусками кода. Тесты с вариантами а, б, в, г, д бесполезны.
5. Конечно в сфере услуг нет конкуренции, вы однозначно правы. #lol
6. Исходя из пункта №5, вам не нужна никакая маркетинговая политика, реклама и вообще клиенты к вам сами попрут толпами, ведь у них нет альтернатив, кроме вас.

Предлагаю вернуться к первоначальной идее по продаже пирожков ;)

на Perl

Сложный вопрос :). Все зависит от Ваших требований к проекту. Данный в ссылке «вопрос» легко решается через JQuery. Если уж Вам так важно чтобы было как в заданном вопросе, то использование JQuery облегчит задачу, но для красоты, желательно сделать что-то типа «Loading», который исчезает после полной загрузки страницы.

А выжать все что можно из CSS хорошая идея. Почему бы Вам не скомпоновать их.

И еще одно — почему все так боятся использовать таблицы (как в заданном вопросе)? Они показывают прекрасные результаты и с точки зрения кода и просмотра страницы. Основная аргументация против таблиц идет в основном в том что они сильно грузят страницу и браузер — так не надо использовать их везде. Рациональное использование таблиц только ускорит загрузку и работу. Честно — я не понимаю этой «фобии». Если Вам нужны авторитеты, возьмите Гугл, яндекс да и тот же самый хабр :). Некоторые делают в десятки раз больше кода и грузят браузеры используя JQuery+CSS чтобы не использовать таблицы. По моему надо быть более рациональным и не упираться в ворота из-за каких-то догм.

Достигая этой отметки плеер выдает pup-up рекламу.

Список матерных слов можно почерпнуть из списка запрещенных доменов РФ:
bunnywrote.trp2.ru/stop-list.txt