яндекс продолжает тенденцию, начатую настройкой вида своей стартовой страницы, и даёт юзерам возможность добавлять на неё свои блоки — виджеты. Сейчас интерфейс становится похожим на iGoogle: несколько стандартных блоков, каталог виджетов от независимых разработчиков, и возможность создать свой собственный виджет. К сожалению, в этот раз при выпуске новой фичи яндекс не стал использовать существующие стандарты (например, Я.Онлайн=Jabber), и повёл себя как крупные отечественные соцсети: изобрёл несовместимый велосипед
сейчас в мире есть два распространённых открытых стандарта виджетов: OpenSocial и Facebook. Первый из них поддерживается шире, но хуже. Тем не менее, в каждом случае можно реализовать только часть функций, ответственных лишь за контейнер, чтобы существующие простейшие виджеты работали сразу
но нет, судя по руководству разработчика яджетов, даже для вставки на страницу примитивного калькулятора нужно обрабатывать готовые решения напильником. Можно настаивать, что так стало проще, но плечи гигантов пользователям яндекса недоступны
я почти не пишу на питоне, но имею его в виду, в том числе почитываю разные интересные вещи о нём. Сейчас только что закончил читать пару презентаций David M. Beazley с PyCon. В первой из них он интересно рассказывает про генераторы в питоне, справедливо ругая обычные примеры про числа Фибоначи. Его собственные примеры про реализацию почти-unix-pipes на генераторах намного интереснее.
честно скажу, что вторую презентацию я не осилил до конца, но даже прочитанная часть стоила того. Сопрограммы (coroutines) — недавно введённая в питон фича, теоретические разработки которой делались в 60-70 годы, но почти забытая потом. Это нечто похожее на генераторы, но более мощное. В принципе, сам автор пишет про них:
I think a reasonable programmer could claim
that programming with coroutines is just too
diabolical to use in production software
тем не менее, ознакомиться с обоими презентациями полезно, особенно с учётом прихода генераторов в яваскрипт:
я понимаю, что ещё немногие люди дошли до того, чтобы подключать к компу более одного монитора. Очень зря, конечно, они многое теряют, но никого заставлять я не буду. Хотя некоторых программистов стоило бы, в особенности это касается флешеров
мне на глаза попадалось только несколько видеохостингов, но на каждом втором из них есть проблемы при разворачивании видео на весь экран. Я не знаю, какую математику применяют при этом, и какие возможности даёт флеш для определения доступных размеров, но многие делают одну и ту же ошибку. Люди! Флешеры! Вам отдаётся не весь рабочий стол, а только один монитор. Исходите из размеров монитора, а не рабочего стола! А то получится, как на ютюбе, или — не дай бог — яндекс-видео. Первый, хотя и кладёт картинку в конверт с соотношением сторон десктопа, но показывает её целиком на одном мониторе. Конечно, видео при этом увеличивается совсем немного, но его видно. А вот плеер яндекс-видео ошибается куда неприятнее
наверное, нужно затачивать очеловечиватель и под другие хостинги
последние несколько дней в списке рассылки OAuth шло обсуждение недавно открытой уязвимости. Что характерно, проблема заключается не в технической части, а в социальной. Вся криптография по-прежнему надёжна (сюрприз!), но есть способ получить доверенность на данные другого человека.
если коротко, то процесс OAuth состоит из трёх частей. Вначале вы говорите сервису-потребителю, что сейчас дадите ему доверенность использовать свои данные с другого сервиса. Потом вы отправляетесь на другой сервис и подписываете доверенность. И в конце отправляетесь назад с готовыми документами.
проблема здесь в том, что нет никакой гарантии, что сервису-потребителю вы дадите доверенность именно на свои данные. Образно говоря, можно подготовить пакет документов и подсунуть их на подпись ничего не подозревающему человеку. Если тот незнаком с процессом, он спокойно может доверить свои данные постороннему.
ниже следует более техническое описание.
регистрируемся на сервисе-потребителе данных. Говорим, что сейчас можно будет получить, например, свою адресную книжку от гугла. Сервис пытается отправить нас на гугл за подтверждением. Но мы на гугл не идём, мы берём этот урл и даём в блоге ссылку на него со словами типа «какие чудеса сервис ХХХ делает с адресной книжкой».
читатель блога заинтересовывается и переходит по ссылке. При необходимости логинится в гугл. Видит там запрос «сервис ХХХ хочет вашу адресную книжку». Всё кажется нормальным, и человек подписывает доверенность.
вот и всё: злонамеренному пользователю сервиса ХХХ выдана доверенность на пользование адресной книжкой другого человека.
окончательное решение этой проблемы ещё не придумано. Пока что есть несколько рекомендаций, которые уменьшают вероятность использования такой уязвимости. Например, сервис ХХХ должен сохранять у себя эту доверенность не на того человека, который начал процесс, а на того, кто пришёл по редиректу с доверенностью. Кроме того, поскольку злодею неизвестен момент выдачи доверенности, сервис может аннулировать ключи тогда, когда злодей проверяет наличие ещё не существующей доверенности.
во-первых, можно избавиться от всего того мусора, что гуглокарты кладут в глобальную область видимости: достаточно вместо параметра скрипта file=api писать file=googleapionly, и все нужные объекты насовсем переедут в google.maps.*
во-вторых, можно динамически подключать скрипты к странице: если передать скрипту параметр async=2, то он не будет использовать document.write
обидно, правда, что приходится так глубоко зарываться, чтобы найти эти фичи