Мне кажется что во втором случае поведение более правильное javascript:alert('Hello world!')
поскольку мало ли что там в JS будет делаться, например alert в данном случае выведет как написано "%20"
Всегда, при самой любимой работе в целом, встречаются неприятные моменты. Их можно решать, уменьшать аутсорсить :) но в целом избавиться от них полностью не получиться. Так что уметь делать неизбежные неприятности хотя бы нейтральными очень полезно.
Что бы я хотел сказать — не единым НЛП жив человек. Иногда причина банальна, а флуктуация модальность лишь ее проявление.
имхо
1. менять куку при успешном заходе ( спаролем или без ), обновляя срок жизни
2. использовать md5(uniqid()) — это 32 символа или 128 бит и 2^128 ~10^38 вариантов
добавление пары порядков картину не изменит.
IP может быть динамический или прокси/NAT.
а серверный скрипт на другом домене оборачивает данные, как было указано в виде функции с хэшем в параметре.
Смысл в том что домен чужой, класть туда свой скрипт нет возможности, поэтому ответ на запрос к нему нужно обернуть в вызов нашей функции. Имя которой и передается.
Именно в таком виде он и поддерживается jQuery и mootools, например. Причем в jQuery достаточно добавить =? в параметры и библиотека сама обернет success call-back в публичную функцию и передаст его в этот параметр. Впрочем dataType: 'jsonp' добавляет '=?' за Вас :)
Зачем все смешивать? Например теги для музыки и кода будут просто мешать друг другу, eg если любители PinkFloyd выпустят одноименный фреймворк. То есть придется организовывать namespaces. Но ведь это уже есть сейчас на уровне приложений!
Если кому-то удобнее теги, то это не повод удалять другую структуру. Иерархия — простой способ ограничить контекст. Можно тегами полностью сэмулировать иерархию, но сделав, например линейный список файлов с тегами, нам придется постоянно кэшировать запросы по тегам в поиске, оптимизируя которую мы придем к сохраненным выборкам, сохранив которые на диске, мы опять вернемся к существующей иерархии :)
Мне например дерево тоже не полностью удовлетворяет, но симлинки меня полностью устраивают.
к сожалению текущий web интерфейс uTorrent не позволяет указывать папку закачки и метку. Этого не хватает для нормальной автоматизации старта закачки в один клик…
ДНК не является уникальным идентификатором сама по себе, а уж методы исследования дают только вероятностную оценку. Разве что секвсестирование, но боюсь что оно дорого. К стати раньше вообще пользовали группу крови и ничего.
Да и банальных ошибок или халатности достаточно, что бы, например, Чикатило отпустили, а другого расстреляли.
Нужен обзор средств автоматического тестирования. Плюсы-минусы.
Про указанных в списке могу сказать только про Selenium — удобный, но неразвитый продукт. В частности записанный тест кейс спотыкается на iframe и редакторах, которые их используют. И если для фрейма можно допилить напильником, то редактор победить не удалось, похоже не умеет генерировать события правильно.
Также напильник нужен для AJAX-а. И вообще тесты требуют напильника и знаний/опыта как это работает. Рекламируемая простота — только для банальных хомяков.
Иногда тесты с отслеживанием событий, проверками и действиями с ожиданием, почему-то может не работать на Fast. Может быть и на Slow что-то не работает.
Не умеет работать с запросам к серверу, то есть GETы можно прописать вручную, но это наиболее легкая для автоматизации часть полностью упущена. Что-то есть для
А вообще тулза супер! :) Простые вещи делаются быстро, сложные — по-разному, как и бывает обычно. Добавить автоматическое тестирование запросов к серверу с параметризацией — цены бы ему не было.
Открытые исходники дают возможность допилить самому.
Не проверял, но рекламируется возможность удаленного тестирования на сервере и организовывать кластеры.
Зачем же вы всякое г предлагаете? Оно не умеет работать под нагрузкой.
Протоколов? IGMP хотя-бы. Но не в этом суть — дешевая железка как правило имеет очень маленький буфер под TCP на NAT и вследствии чего торренты упираются в его размер. Иногда так что даже tcp совсем ходить перестает.
Ну так всегда! Хотел посмотреть что же отечественный производитель может предложит для Metro Ethernet и обнаружил морально устаревшие рутеры и системы передач.
Я конечно понимаю что рутер дома выбирают уже по цвету лампочек, но где собственно нормальные тесты или параметры?
Хотя бы сколько NAT держит сессий TCP? а то понаставят торрентов и придеться перегружать постоянно. А судя по списку протоколов это самая что ни на есть
дешевая железка и очень вероятно что загнется.
Ну вообще-то некоторые проектные стандарты родились как требования к исполнителю гос заказа в Штатах. Например CMM.
Да, и я бы не стал делать выводы раньше времени. Почему там была вода и были или нет закрыты затворы и почему — отсюда лично мне многое неясно. Мне ясно одно — проблемы на ГЭС были серьезные, поскольку знающие люди драпанули, видимо ожидая самого худшего.
Слава Богу худшее не случилось, но люди погибли. И уважая их память, а также эмоции и здоровье тех кто так или иначе вовлечен, я призываю не делать поспешных выводов.
Вариантов собственно два:
либо сделать как хочет заказчик и вытащить стоимость издержек из него, либо сделать по контракту. В обоих случаях нехилые риски потерять либо денег, либо заказчика.
В крупной фирме, скорее всего затребуют гарантийное письмо на сверхконтрактные работы. Либо сделать, а потом перезаключить контракт с более строгой SLA = дороже.
Мелкой фирме или фрилансеру остается либо признать что деньги значительные, риски потерять их того не стоят и сделать как требует заказчик, либо «учить» — например вытянуть переписку, правильно отквотить, дабы было очевидно противоречие и отослать или сделать это устно.
Главное — обязательно выполнить все контрактные обязательства, как бы не складывались отношения в процессе, либо в соответствии контрактом его разорвать.
В целом такие заказчики рисковые — если они пытаются выиграть копейки на мелочи, то в случае серьезных проблем будет все намного хуже. Это важно, поскольку контракт обычно описывает рабочие процессы и очень редко когда закрывает все возможные прецеденты.
javascript:alert('Hello world!')поскольку мало ли что там в JS будет делаться, например alert в данном случае выведет как написано "%20"
Что бы я хотел сказать — не единым НЛП жив человек. Иногда причина банальна, а флуктуация модальность лишь ее проявление.
1. менять куку при успешном заходе ( спаролем или без ), обновляя срок жизни
2. использовать md5(uniqid()) — это 32 символа или 128 бит и 2^128 ~10^38 вариантов
добавление пары порядков картину не изменит.
IP может быть динамический или прокси/NAT.
в URL скрипта подставляется имя функции eg
some_another_domain.com/script_generator.php?param1=data1¶m2=data2&callback=showPriceа серверный скрипт на другом домене оборачивает данные, как было указано в виде функции с хэшем в параметре.
Смысл в том что домен чужой, класть туда свой скрипт нет возможности, поэтому ответ на запрос к нему нужно обернуть в вызов нашей функции. Имя которой и передается.
Именно в таком виде он и поддерживается jQuery и mootools, например. Причем в jQuery достаточно добавить =? в параметры и библиотека сама обернет success call-back в публичную функцию и передаст его в этот параметр. Впрочем
dataType: 'jsonp'добавляет '=?' за Вас :)Просто используйте другое представление.
Персональные поисковики уже лет 10 как существуют.
Если кому-то удобнее теги, то это не повод удалять другую структуру. Иерархия — простой способ ограничить контекст. Можно тегами полностью сэмулировать иерархию, но сделав, например линейный список файлов с тегами, нам придется постоянно кэшировать запросы по тегам в поиске, оптимизируя которую мы придем к сохраненным выборкам, сохранив которые на диске, мы опять вернемся к существующей иерархии :)
Мне например дерево тоже не полностью удовлетворяет, но симлинки меня полностью устраивают.
ДНК не является уникальным идентификатором сама по себе, а уж методы исследования дают только вероятностную оценку. Разве что секвсестирование, но боюсь что оно дорого. К стати раньше вообще пользовали группу крови и ничего.
Да и банальных ошибок или халатности достаточно, что бы, например, Чикатило отпустили, а другого расстреляли.
Про указанных в списке могу сказать только про Selenium — удобный, но неразвитый продукт. В частности записанный тест кейс спотыкается на iframe и редакторах, которые их используют. И если для фрейма можно допилить напильником, то редактор победить не удалось, похоже не умеет генерировать события правильно.
Также напильник нужен для AJAX-а. И вообще тесты требуют напильника и знаний/опыта как это работает. Рекламируемая простота — только для банальных хомяков.
Иногда тесты с отслеживанием событий, проверками и действиями с ожиданием, почему-то может не работать на Fast. Может быть и на Slow что-то не работает.
Не умеет работать с запросам к серверу, то есть GETы можно прописать вручную, но это наиболее легкая для автоматизации часть полностью упущена. Что-то есть для
А вообще тулза супер! :) Простые вещи делаются быстро, сложные — по-разному, как и бывает обычно. Добавить автоматическое тестирование запросов к серверу с параметризацией — цены бы ему не было.
Открытые исходники дают возможность допилить самому.
Не проверял, но рекламируется возможность удаленного тестирования на сервере и организовывать кластеры.
Протоколов? IGMP хотя-бы. Но не в этом суть — дешевая железка как правило имеет очень маленький буфер под TCP на NAT и вследствии чего торренты упираются в его размер. Иногда так что даже tcp совсем ходить перестает.
Хотя бы сколько NAT держит сессий TCP? а то понаставят торрентов и придеться перегружать постоянно. А судя по списку протоколов это самая что ни на есть
дешевая железка и очень вероятно что загнется.
Да, и я бы не стал делать выводы раньше времени. Почему там была вода и были или нет закрыты затворы и почему — отсюда лично мне многое неясно. Мне ясно одно — проблемы на ГЭС были серьезные, поскольку знающие люди драпанули, видимо ожидая самого худшего.
Слава Богу худшее не случилось, но люди погибли. И уважая их память, а также эмоции и здоровье тех кто так или иначе вовлечен, я призываю не делать поспешных выводов.
Вариантов собственно два:
либо сделать как хочет заказчик и вытащить стоимость издержек из него, либо сделать по контракту. В обоих случаях нехилые риски потерять либо денег, либо заказчика.
В крупной фирме, скорее всего затребуют гарантийное письмо на сверхконтрактные работы. Либо сделать, а потом перезаключить контракт с более строгой SLA = дороже.
Мелкой фирме или фрилансеру остается либо признать что деньги значительные, риски потерять их того не стоят и сделать как требует заказчик, либо «учить» — например вытянуть переписку, правильно отквотить, дабы было очевидно противоречие и отослать или сделать это устно.
Главное — обязательно выполнить все контрактные обязательства, как бы не складывались отношения в процессе, либо в соответствии контрактом его разорвать.
В целом такие заказчики рисковые — если они пытаются выиграть копейки на мелочи, то в случае серьезных проблем будет все намного хуже. Это важно, поскольку контракт обычно описывает рабочие процессы и очень редко когда закрывает все возможные прецеденты.
Имхо это сложнее и сбивает с ритма и черевато ошибками.