На 11 МБитах грузится оооочень долго. Первую черепаху дождался, внутрянку жду уже минут 12. Может у них там канал просел?
Первая страница не впечатлила. Совсем. Ну топает черепаха, ну и что? Отрендерено похоже заранее (вот если бы на лету - вот тогда было бы очень круто), во флэшке, как я понимаю, понавставлено готовых роликов. Уверен, оптимизировать можно было бы все это раз в 100 по объему. Звуковое сопровождение слабое, а грузилось то, грузилось...
Поздняя правка - там всего 4 элемента анимированных: ноги, флаг на шпиле, цепь, дым из трубы. Остальное можно было запихать в статику. Думаю даже в 150 раз пожать это безобращие бы удалось, причем качество можно даже поднять!
В общем у меня пока четкая ассоциация с поделкой РБК, которую они рассылали на Новый Год своим клиентам - там стриптизерша елку наряжала. Тоже роликов наснимали и запихнули на веб. Было просто ужасно.
Возвращаясь к этой ссылке - вошел унутрь. Ничего поражающего пока не вижу. На вебе, конечно, такое встретишь нечасто, но для игрушек такая графика 3-4 года назад была актуальна. Сейчас это выглядит очень печально. Особенно убили часы посередине экрана, которые показывают текущее время, выполненные совершенно не в стиле. Что еще раз убедило меня в том, что художники были выше классом, чем флэшер.
Тормозит вся анимация конкретно, флэшевый движок не тянет отрисовку такого количества одновременных независимых роликов. Кроме того, было бы логично не анимировать все блоки с такой большой амплитудой, а заанимировать их слабее. А при наведении мышки сделать какой-то акцент на блоке. А то на экране сразу какой-то карнавал, а при нажатии короткая анимация. Единственное что немного понравилось - коробка с медведями, которая на тебя опрокидывается при нажатии. Остальное банально до ужаса.
Звук очень слабый. Луп основной темы, длиной в 5 секунд раздражает после четвертого повторения. Остальные звуки тупо наложены в ряд, хотя опять же напрашивается сложная процедура по смешиванию и уводу неактивного персонажа в звуковой фон.
Кстати, я не понял почему там прелоадер такой - собака катится на чьей-то голове.
И нет там никаких активных зон на главной. Там везде одна и та же надпись "Войти", куда не ткни - в одно и то же место попадешь. по сути я нашел только два экрана.
А теперь главный вопрос - чему посвящен сайт? Чем занимается компания-владелец?
И кстати по части контента - сайтик то пустой почти... Внутри есть пара страниц с небольшим наполнением, но, похоже, так его до конца и не довели.
Кстати говоря, да. Отменная защита от уродов.
Мои пять копеек:
1. Если человек неграмотен, он не сможет сделать нормального анализа юзабилити. Ссылки на какие-то там полушария мозга - полный бред.
2. Если ты торопишься, то лучше за работу не браться. По крайней мере потратить время на представление своего результата в плане грамотности намного более правильно, чем рисовать красивые баллоны с текстом на картинке.
3. Анализ на мой взгляд проведен совершенно бессистемно, бесцельно и непрофессионально. Замечания по конкретным моментам я писать не буду, для любого нормального человека все станет понятно после комментария к первой странице насчет ссылки "Купить" в главном меню. Если это нормальное ее положение, то я китайский летчик Джао-Да.
Примечание: есть принципиальная разница между анализом эргономики сайта и попыткой с умным видом высказывать свои мысли, которые кажутся тебе гениальными.
4. Большинство комментариев несут претензию на понимание психологии целевой аудитории ресурса. С моей точки зрения это а) мало вяжется с юзабилити-тестированием и б) исполнитель в данном случае явно не понимает этой самой психологии ЦА. Если нужны подобные комментарии типа "отталкивает ли людей словосочетание "пластическая операция" достаточно показать сайт 10 женщинам и собрать их естественные комментарии. Конечно, затем потребуется их систематизация и анализ. Но лучше делать это на реальной фактуре, чем опираться на предположения молодого человека, не имеющего никакого представления о теме и рассуждающего очень абстрактно. Но опять же - причем тут юзабилити?
5. Лично для меня анализ типа "тут плохо" никогда не был достаточен. Профессионал должен сказать "должно быть вот так" или "должно быть вот как на этом сайте" на худой конец. То есть вместо картинки с комментами "это лучше перенести сюда" я ожидаю увидеть сразу итоговую картинку "как это должно быть" (или хотя бы "как это могло бы быть").
Как ни странно, если это сделать, сайт, на мой взгляд, лучше не станет. А значит и мой вывод:
весь анализ данного сайта, вероятно, можно было свести к простой рекомендации сделать ресурс чисто информационным, либо, если он является имиджево-продажным - заказать нормальный дизайн за нормальные деньги. А не распыляться на поиск мелких недочетов попутно внося свои орфографические ошибки.
Долго ждать будете. У нас та же история уже третий месяц. У яндекса, похоже, какие-то конкретные проблемы. За месяц трижды были периоды по 2-3 дня, когда индексирующий робот вообще не ходил ни на один из 30 сайтов на нашем хостинге. Саппорт ссылается на истечение таймаута коннекта, но все остальные поисковики работают отменно, коннект из браузеров безпроблемный, логи все какие есть показывают что проблем никаких нет на хостинге. Пинги с хостинга до машин яндекса 2-3 мс, канал загружен в пределах допустимого. Все заголовки страниц перерыли.
В общем, уже все волосы на себе порвали, а новые сайты в выдаче не появляются. А те что есть - те индексируются по 1-2 страницы в неделю и то не все.
По-моему несложно взять основные браузеры и просто попробовать. Это займет меньше времени чем искать такой список.
Получить раззенденный код на выполненный проект, насколько я понимаю, в данном договоре - право заказчика. К примеру, у нас по договорам всегда четко сказано - система управления не отдается, а передаются права на использование системы, причем на одном конкретном проекте. Поэтому, если заказчик хочет взять исходный код - система в исходниках отдается ему без проблем. Он имеет право на изменение кода системы, если в том возникнет потребность. Никаких проблем. Но и отвечать в этом случае мы уже не будем, поскольку передача готового проекта на CD автоматически завершает наш договор на разработку проекта. Соответственно, заказчик может делать с проектом чего хочет ("Исполнитель не вправе ограничивать коммерческое использование результата работ"), только не использовать систему где-то еще отдельно от результата работ и не продавать ее как конечный продукт.
С поддержкой у нас всегда есть отдельный договор, где прописано, что в случае получения прямого доступа к коду системы (неважно будут ли там сделаны изменения или нет) мы ограничиваем свою ответственность только услугами хостинга. То есть если он чего сломает - его проблемы.
Если в договоре этого ничего нет, "дыра" как тут пишут, то как мне кажется нужно идти просто от здравого смысла и договариваться с заказчиком. Объяснить, что интересы обоих сторон не должны быть ущемлены, иначе вы не получите от них денег, а они не смогут получить никакой поддержки от вас. А самостоятельно с продуктом они не разберутся. Вряд ли заказчик планирует зарабатывать на продукте от своего имени, но этот момент, конечно, лучше уточнить. И в случае чего упереться и давить тем, что у вас есть в наличие.
Итоговую договоренность лучше заключить дополнением к договору. По крайней мере у вас же написано - доступа по FTP не даем. Хотите получить - подпишите отказ от претензий в случае чего. В противном случае ничего не дадим согласно договору.
Также в это соглашение смело вставляйте упущенные моменты касательно неиспользования движка в коммерческих целях отдельно от проекта и только после этого раззендивайте код. Собственно рычаги давления на заказчика у вас есть. Конечно, кое-где это будет смахивать на шантаж, если заказчик пойдет в конфронтацию. И, безусловно, это чисто ваша вина что не оговорили эти моменты ранее и не записали в договор. Но если заказчик не сильно тупой и агрессивный, то эту ситуацию вполне возможно полюбовно разрулить. А если тупой и агрессивный - как я уже написал, немного поругаетесь, но пока вы не отдали ему пистолет он в вас выстрелить не сможет.
дубль, видимо второй пост прошел
Самое распространенное заблуждение. Средства технически обеспечивающие связь это не достаточное условие для успешного совещания. И не необходимое, если можно просто собраться. В бытность руководителем в крупных компаниях много раз попадал в ситуации, когда неподготовленность совещаний приводила к пустому трепу и потере времени. Но еще больше потерь у меня было из-за лени человеческой. Это когда у человека на столе телефон стоит, он по внутреннему тебя набирает, а что спросить и чего он хочет, собственно, не знает. И дергают тебя по любому поводу, думая что оперативность общения заменит смысл самого общения. "Вася, ну как там, ну это, ну проект? А... работаете... Да нет, я так просто, позвонил спросить". Или "Блин, я смотрю тут косяк на косяке? Как это где? Ну на проекте? Как это на каком? Ну на вот этом. Как это какие косяки? Ну вот тут, слева, ну то есть справа внизу. Да не на этой странице, а на внутренней. Да не, наверное не тот вариант смотришь. Да блин я щас проще подойду к тебе и все покажу пальцем".
В общем у нас было 3 канала общения помимо живого:
- ICQ Corporate для обмена мелкими кусками информации типа URL, кода и т.п. Применялось в основном в рамках комнаты, когда народ понял что крики "Вася, у меня тут косяк" на всю комнату нереально отвлекают остальных от работы.
- Внутренний телефон: для обсуждения ОБЩИХ постановок задач. Типа для передачи ощущений
- Email: для документирования работы, отчетов и постановок задач
И кто делал не так - тому сразу по рукам.
+2 еще планерки в неделю, вживую, чтобы "в глаза смотреть, я сказал!". в пн планерка-планерка, а в птн - планерка-итог.
А вы говорите Skype все решит. Да ничего он не решит сам по себе. Каждому уровню коммуникаций нужно подбирать свое средство передачи данных. В случае с фрилансом все тоже работает, за исключением того, что к сожалению фриланс и удаленный сотрудник это две большие разницы. И когда фрилансер работает по другим НЕ ТВОИМ проектам (чего ты ему запретить не можешь), или еще хуже когда он на наемной работе работает - это, для профессий, где нельзя выделить конкретную большую задачу и бросить ее на выполнение почти без контроля - похороны компании. Или похороны конкретного менеджера, который эти риски разгребает.
Да и мозговой штурм, это, как правило, вообще не то, что привыкли называть мозговым штурмом у нас. У нас (где бы ни работал) собраться и потрепаться - это сколько угодно. А чтобы с результатом штурм провести - это крайне редко. Как на панацею всё больше на него кивают, типа щас сядем, поштурмим и проблема сама решится. Никто не готовится, результаты не фиксируются... А потом обычно тот кто за задачу конкретно и отвечает - делает по своему, как и задумал перед "штурмом". А те, кого привлекали как "экспертов" обычно понимают что это не их задача и им все пофиг. Хотя это конечно ИМХО, может у кого то позитивный опыт в этой области. У меня - очень мало.
Вспомнилось, вот к слову как на ПИТе нас гоняли с этим штурмом. Был такой предмет, Принципы Инженерного Творчества.
А вообще, тут правильно сказали. Ни одной серьезной конторы на чистом фрилансе нет. Вообще, я бы хотел посмотреть на фриланс в любом нормальном производственном бизнесе, где люди не на воздухе добавленную стоимость создают. Фиг бы самолет какой фрилансеры спроектировали. Или танк.
Технология тут не при чем. Есть протокол HTTP, реализовать отсылку заголовков и прием данных можно на любом языке и на любой технологии, хоть на BAT файлах. Понятно, что в любом веб-ориентированном языке или технологии будут средства это сделать - неважно PERL, PHP, ASP, JAVA, c# или еще что-либо. Это можно утверждать даже не зная языка.
2ТС: я так понимаю писать никто не взялся? Вы лучше на форуме девелоперов напишите такую задачу, все таки здесь не совсем то место где разработчики тусуются. Также поищите по сети что-то типа http proxy with cookies support. Наверняка такую задачу уже кто-то писал.
Программа, которая делает запрос к вашему сайту может в минимальном варианте не посылать вам никаких данных, поэтому веб сервер будет знать только то, что кто-то с определенного IP адреса запрашивает информацию с такой-то страницы. В "максимальном" варианте программа может указывать User-agent, принимаемые типы данных, поддержку сжатия, реферер (последний посещенный сайт) и другие параметры.
Поэтому в каком-то случае Вы сможете идентифицировать клиента, который получает данные с вашего сайта по совокупности известной о нем информации, а в каком-то ничего кроме IP вы о нем не узнаете.
Для серверного скрипта зная IP, как Вы правильно полагаете, Вы можете узнать на какой выделенной машине или на какой хостинг-площадке стоит граббер. И все. Если Вы заблокируете этот IP, то с этого хостинга никто данные от Вас получать не сможет. По идее, если Вы не предоставляете никаких данных для серверных скриптов, то есть если у Вам нет "легальных" и "нелегальных" грабберов - блокируйте и все. Пользователи все равно будут видеть то, что им нужно, а грабберы - нет.
Только это не очень эффективным способом окажется, если тот, кто писал граббер работает через анонимные прокси. Но для серверных приложений редкость полноценные решения, которые постоянно обновляют списки проксей и потому их все достаточно надежно можно вычислить и прибить через некоторое время с начала эксплуатации.
А вот поиск самих IP и их блокировка - работа нудная и требующая времени. Писать движок для распознавания таких грабберов та еще работенка. Проще придумать что-то типа авторизации на сайте, так, чтобы грабберы от людей отсеять.
