У меня такая же байда на большом сайте. Анализ показал, что дело не в длине тайтла и не в его лаконичности. Так что далеко не обязательно, что это из-за косяков вашего тайтла. Дело похоже в статистических алгоритмах самого Гугла: он просто на основе своих статистических данных считает, что несколько другой заголовок будет более эффективен для конкретного посетителя. Кстати, я по своему сайту не уверен, какой из заголовков лучше - оригинальный (начало которого точно соответствует запросу) или гугловский вариант (обрезанный и упрощенный). Чтобы сказать точно, надо проводить тестирование А/Б, чем Гугл вероятно и занимается, выдавая разные варианты заголовков.
Х.З., документы на фотоаппарат хорошо конечно приложить, если есть. Чем больше косвенных доказательств, тем лучше. А вообще если не ошибаюсь, то в ГК где-то (о, нашел статья 1257) написано, что автором признается лицо, имя которого указано на экземпляре произведения, если не доказано иное. Поэтому имхо достаточно указать свой автограф на экземпляре и обеспечить доказательства приоритета по дате, т.е. существование экземпляра с вашим автографом на определенный момент времени. Если кто с этим не согласен, пусть доказывает обратное.
Если наличие raw файла не доказывает авторства, то аналогично и никакие бумаги и серийные номера не доказывают авторства. Поймите, что нет и не может быть железных (100%-х) доказательств авторства. Все доказательства авторства могут быть лишь косвенными.
100chuk, у них уплата этого процента действительно несколько запутанно организована: автоматом в поле суммы оплаты взносов эта сумма 1-го процента не добавляется, просто ниже дается информация о нем, но добавлять надо самому вручную. У меня тоже накладки с этим были, правдя я поквартально плачу.
Еще были накладки с автоматическим импортом платежек этих страховых выплат из банка. Я оформил в сервисе платежку, сделал экспорт в банк, в банке платеж прошел, но следующим днем, в итоге из-за разных дат при последующем импорте из банка система не определила, что это дубли, и эти платежки у меня в системе продублировались - как бы я два раза заплатил страховые взносы. И я эту двойную сумму чуть было не вычел из налога.
Поэтому я всегда проверяю примерные итоговые суммы. Если не совпадают, тогда детально копаю.
Честно говоря, просто для ведения дел в большинству простых ИПэшников можно легко обойтись без подобных сервисов, особенно после первого года работы.
Но я с ними работаю в основном из-за бухгалтерских консультаций, а они там реально хороши.
В большинстве случаев заказчик получает на бОльшую часть кода права по неисключительной лицензии. Т.е. если вы заказываете сайт, то исключительных прав в большинстве случаев на движок не получите, если конечно не платите миллионы именно за разработку движка с нуля.
Поэтому этот пункт очень важен.
Имхо всё понятно. Если не пытаться натягивать сову на глобус, то:
1) Разработка сайтов - подходит только в части программирования логики работы сайта и верстки. Всё остальное (дизайн и прочее) я бы сюда не относил. Но это под вопросом. Сайт по своей природе - составной продукт, под который всё что угодно можно подвести - например работу фотографов, журналистов, писателей и т.д. Но очевидно, что эта работа хоть может потребоваться для создания сайтов, она вряд ли подпадает под этот патент.
2) Контекстная реклама - сама по себе нет, не подходит. Подходят только услуги по адаптации рекламного кода к сайту.
3) SEO - само по себе тоже не подходит. Подойдут только услуги по написанию программ, автоматизирующих процесс, и подобное .
Вне наследуемого класса - никак. Т.к. доступ к методу защищен.
Зачем загонять всё сразу в массив? У ПХП массивы жрут весьма много памяти. Используйте построчное чтение из файла.
Друпал - это не совсем CMS. Это гибрид цмс с фреймворком. Многий функционал можно изменить хуками и написанием своих модулей. Но проблема возникает, если переопределять придется много чего. Поэтому я бы внимательно посмотрел возможности ядра и модулей друпала. Например, имеющиеся сборки. Если основа покрывает ваши нужды, то заточка вряд ли вызовет проблемы. Там конечно есть проблемы с кривизной и избыточностью модулей, но всё же это не с нуля писать.
А писать движок с нуля на фреймворке - боюсь, по бюджету не уложитесь. 200 тысяч - это всего пара-тройка месяцев работы программиста. Что за это время можно успеть? Ну, или он вам на своем движке код выкатит с соответствующей привязкой к нему не только в плане дальнейшей поддержки, но и в плане авторских прав на движок. Движок же с нуля за эти деньги вам вряд ли кто в здравом уме писать будет.
И вы уверены в успехе проекта? Это я к тому, что может лучше начать с недорогого решения?
tysson, Посещаемость у вас копеечная, я под большой подразумевал сотни тысяч посетителей в день и выше.
Функционал в целом также стандартный, пока не вижу смысла в самописе. Подобные сборки по недвижимости и продаже авто я видел на телдери за копейки (меньшы тысячи рублей). Также на этом форуме в разделе купли-продажи такие сборки видел. Посмотрите, даже купите для теста, - если в целом функционал подойдет, то под свои нужды скорей всего не сложно будет заточить. В итоге цена вопроса будет весьма скромной.
