SeoNews.com.ua - SEO & Search Engine News
Поисковая оптимизация
Популяризация токенов способна значительно повысить уровень безопасности в сфере электронной коммерции
Эксперты предлагают заменить передаваемые на торговые серверы финансовые данные электронными идентификаторами, не имеющими ценности для злоумышленников.

Как сообщает издание Network World со ссылкой на доклад одного из крупнейших производителей токенов безопасности, широкомасштабное внедрение такой меры, как дополнительные этапы идентификации, способно в значительной степени сократить количество успешных хакерских атак в сфере электронной коммерции.


Персональные данные граждан РФ будут храниться на российских серверах
Депутаты предлагают изменить дату вступления в силу закона «О персональных данных», согласно которому соцсети и сервисы электронной почты будут обязаны хранить личную информацию пользователей на российских серверах.

Как сообщает издание "Известия", депутаты Госдумы РФ выступили с предложением внести некоторые коррективы в закон «О персональных данных», согласно которому социальные сети и сервисы электронной почты будут обязаны сохранять информацию о конфиденциальных данных граждан РФ на серверах, которые располагаются на территории России. Указ был подписан В. Путиным в июле текущего года, и вступает в действие 1 сентября 2016 года. Тем не менее, госчиновники предлагают ускорить процесс и узаконить перенос личной информации пользователей уже с 1 января следующего года.

Пользователям Wi-Fi в московском метро скоро придется регистрироваться
По просьбе руководства столичного метрополитена компания «Максима Телеком» разработала программное обеспечение, посредством которого будет происходить аутентификация пользователей.

В скором времени все желающие воспользоваться услугами Wi-Fi в Московской подземке смогут сделать это только по регистрации. По просьбе администрации метро компания «Максима Телеком» разработала ПО для аутентификации пассажиров. Новая система будет распознавать посетителей подземки по IMEI-номерам их девайсов, пишут «Известия».

Зарубежным компаниям могут ограничить доступ к российским гостайнам
По предварительным данным, лишиться соответствующей лицензии могут четыре крупнейших аудитора - Deloitte, EY, KPMG и PwC.

Как сообщает издание «Ведомости» со ссылкой на собственных информаторов в двух компаниях из четверки крупнейших зарубежных аудиторов в РФ, отечественные силовые структуры усилили давление на компании и в перспективе могут лишить их возможности работать с данными, представляющими собой государственную тайну.
Началась последняя неделя льготной регистрации на конференцию CEE-SECR «Разработка ПО»
На конференции рассмотрят все аспекты разработки программного обеспечения.

Стартовала последняя неделя льготных летних цен на конференцию CEE-SECR «Разработка ПО» — одно из важнейших событий ИТ-индустрии в России.

До 31 августа регистрационный взнос будет ниже финальной цены на более чем 37%. Кроме того, продолжают действовать специальные предложения для студентов, аспирантов и групп от трех человек. Все скидки суммируются


Seo News
Facebook готовит исправление уязвимости, заставляющей iPhone совершать звонки
Разработчики социальной сети намерены устранить брешь в ближайшем обновлении мобильного приложения для iOS.

Как сообщают представители социальной сети

Facebook, разработчики компании намерены в ближайшее время выпустить обновление безопасности для своего мобильного приложения для iOS-устройств. Речь идет об опасной уязвимости, эксплуатация которой позволяет злоумышленникам удаленно совершать звонки со смартфонов iPhone, принадлежащих жертвам атаки. Для этого достаточно вынудить пользователя перейти по специально сформированной вредоносной ссылке.
95% электронных уведомлений от Facebook успешно шифруются

В Facebook отметили рост количества провайдеров, развертывающих шифрование с помощью STARTTLS.

95% посылаемых Facebook по электронной почте уведомлений, являются зашифрованными. Электронные письма шифруются с помощью свойства протоколов под названием «Совершенная прямая секретность» (Perfect Forward Secrecy, PFS) и строгой проверки подлинности сертификата. Об этом сообщил инженер Facebook Майкл Эдкинс (Michael Adkins), занимающийся вопросами неприкосновенности сообщений пользователей.

Microsoft представит Windows 9 в конце сентября

В ранней версии Windows 9 будет добавлено переработанное меню "Пуск" и, возможно, голосовой помощник Cortana.

В компании Microsoft планируют представить следующую версию ОС Windows во время специального события для прессы, которое состоится в конце сентября. Как сообщает издание The Verge, ссылаясь на собственные источники, в настоящее время представители корпорации собираются рассказать об изменениях в новой версии Windows, получившей кодовое наименование «Threshold» («Предел»), 30 сентября этого года. Напомним, что следующая версия Windows в настоящее время находится в разработке, и в Microsoft планируют выпустить предварительную версию ОС для разработчиков (Developer Preview) 30 сентября или позже.

Google AdWords забанит пейнтбольное и прочее оружие
Менее чем через месяц Google запретит рекламу оружия для страйкбола и пейнтбола, пневматических пистолетов, боеприпасов, обойм и портупей. Жалобы на такую рекламу ранее поступали в Google AdWords Help.

Google опубликовал предварительную версию изменения политики, которая в настоящее время позволяет рекламировать такие товары на AdWords.

Вот образец письма, отправленного рекламодателям AdWords:

«Уважаемый рекламодатель AdWords,

Мы извещаем вас об изменении правил размещения рекламы Google, которые могут повлиять на ваш аккаунт AdWords.


Уязвимость в Windows продолжает создавать опасность для пользователей
Наиболее часто уязвимость CVE-2010-2568 эксплуатировали на ОС Windows XP.

Согласно документу, опубликованному Лабораторией Касперского, злоумышленники продолжают эксплуатировать уязвимость CVE-2010-2568 , несмотря на “возраст” бреши. Недавно Лаборатория Касперского обнаружила десятки миллионов эксплоитов, направленных на устранение ошибки в период с ноября 2013 по июнь 2014 года, которые не устранили ее. Жертвами кибератаки стали 19 миллионов пользователей по всему миру.

Search Engine News
Подпишись на рассылку и будь всегда в курсе наших новостей.

Яндекс о сервисе push-сообщений, качестве кода в автотестах и факторах ранжирования

Яндекс о сервисе push-сообщений, качестве кода в автотестах и факторах ранжирования
31 августа 2013 года в Минске прошел Я.Субботник, в ходе которого сотрудники минского, московского, питерского и симферопольского офисов Яндекса делились своим опытом. Для тех, кто не присутствовал на конференции, была организована онлайн-трансляция и трансляция в Твиттере по хэштегу #yasubbotnik.
Юрий рассказал, что архитектура мобильных приложений построена на клиент-сервере. Клиент посылает запрос на сервер и получает ответ, таким образом происходит взаимодействие. Основа этого взаимодействия - Pull-технология, когда мобильное приложение делает реквест на сервер, получает ответ, который анализируется, что-то записывается в базы, что-то выводится на экран.



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

Чтобы избежать этих минусов, используется Puch-технология, главное отличие которой заключается в том, что все взаимодействие инициирует сервер.



Сервер отправляет сообщение, и после этого клиент уже думает, что ему дальше делать. Плюсы такой технологии состоят в том, что разработчики на сервере могут контролировать приложение. Также плюсом является пассивный режим работы такого приложения, что обеспечивает квазимногозадачность, что особенно актуально для iOS-приложений. Эти плюсы позволяют также снизить энергопотребление на телефонах. А большим минусом является то, что необходимо иметь сервер управления сообщениями, и реализовывать взаимодействие можно только в асинхронном режиме.

Основным требованием, которое предъявляется к Push-серверам, является способность выдерживать высокие нагрузки, потому что предполагается наличие множества телефонов с Push-клиентом и множества приложений, которые на них реагируют. Push-сервер должен обеспечивать гарантию доставки, поэтому он обязательно должен поддерживать и offline-режим. Характерной особенностью всех Push-серверов является наличие собственной платформы, и многие из них требуют лицензирования. Немаловажной также является способность серверов предоставлять API для внешних разработчиков.

В доставке Push-сообщений участвуют четыре компонента:



Backend генерирует Push-сообщения и начинает сессию взаимодействия. Он посылает сообщение на Push-сервер, который обрабатывает Push-сообщения и доставляет их клиенту. Сообщения попадают на Push-сервис, который отправляет их в какое-то из приложений.

Далее Юрий рассказал, как организована генерация сообщений бэкенда на сервисе Яндекса.
Делается пост-запрос, в котором указывается четыре параметра:

app — имя пакета
app_tokens — cписок токенов приложения (device+apk)
ttl — время жизни сообщения в секундах 

data — payload нотификации в json формате


Официально Яндекс обеспечивает время хранения сообщений 30 дней. Это время можно уменьшить.



Push-клиент поставляется в виде библиотеки. Реализовать клиент можно на готовых сырцах, чтобы их было проще интегрировать (пример реализации).

Собственный сервис должен соответствовать определенным требованиям. Сервис Push-сообщений должен обеспечивать безопасное соединение, работать непрерывно и обрабатывать 100% входящих сообщений.

Сегодня служба Push-сообщений Яндекса находится в бета-тестировании, она была официально запущена 25 февраля вместе с релизом Яндекс.Store, и на данный момент предоставляется вместе с услугами магазина приложений. На сегодняшний день сервис работает на телефонах по всему миру, у него более 400 тысяч пользователей.

Алексей Витенко (разработчик Yandex.Store): «Синхронизация данных на клиенте»


Алексей рассказал о ситуации, когда у разработчиков несколько приложений, и возникает необходимость связать между собой все приложения, которые работают на одном устройстве, чтобы была возможность передавать между ними какие-то данные, либо использовать общие компоненты. Проблема заключается в том, что неизвестно, что пользователь может установить себе на устройство, сколько приложений, и каких именно.

Далее речь пошла об Account Manager'е, позволяющем работать со встроенными в систему аккаунтами. Это сервис, который встраивается в систему и позволяет добавлять аккаунт на устройство:



Еще одним примером общих компонентов является сервис Push-сообщений, о котором рассказывалось ранее. При тестировании выяснилось, что на одном девайсе может появиться сразу два магазина приложений, соответственно, два Push-сервиса. Каждый из них получает свой логин, и для сервера это выглядит, как два отличных друг от друга пользователя:



Клиентское же приложение в процессе своей жизни будет взаимодействовать как с одним, так и с другим, что противоречит Push-технологии.

Решение, которое предлагает Google — это все общие компоненты, сервисы, которые предположительно будут использоваться многими приложениями, выносить в отдельный пакет и устанавливать его отдельно. И даже лучше — все компоненты в свой отдельный пакет. Решение самое простое и надежное. Но так почти никто не делает, потому что это пугает пользователей.



Когда при установке приложения оно тут же предлагает скачать еще что-то, у пользователя могут возникать неприятные ассоциации с принудительной установкой бара, или еще чем-то подобным. Преимущество Google заключается в том, что он может сам ставить какие-то приложения, даже не уведомляя об этом пользователя. Большинство так делать не могут.

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

По словам Алексея решением может стать выделение главного приложения, приложения-флагмана. Флагманом может быть приложение, которое несет в себе все общие компоненты.



С случае, когда трудно выделить одно главное приложение, можно все общие компоненты вставить в каждое приложение. Но все равно придется выбрать главное по какому-то критерию, которое активирует в себе все эти компоненты, и все остальные приложения будут ходить к нему пользовательскими данными. Если же главное приложение будет удалено, то выбирается новый мастер.





Плюсом многократного дублирования будет то, что в системе будет один набор компонентов, сервисов. И это наиболее интересное решение с точки зрения разработки. Минусы же заключаются в том, что это наиболее сложное решение, так как нужно обеспечить надежную синхронизацию данных между всеми приложениями. Из-за синхронизации данных возникает дополнительная нагрузка, затраты на пересылку данных, хотя и незначительные. Увеличивается размер приложений. К тому же, нужно обеспечить безопасность синхронизации.

Механизмы обмена данными между андроид-приложениями:

SharedUserID
Content Providers -
Services
Broadcasts
SharedPreferences (до API 17)
Общее пользовательское ID обеспечивает защищенный доступ приложений к файлам и базам данных приложений с тем же UserID. Однако у этого решения есть большой минус — связывать надо сразу, до выпуска всех приложений потому, что дальше в процессе использования общего ID очень сложно обновлять версии. Теряется доступ к старым данным, и необходимо переустанавливать приложение вручную.

Передача данных через Content-провайдеров — это второй вариант решения, стандартный механизм для предоставления доступа к данным приложения. Все резервные сервисы обращаются к главному и копируют себе его данные. Это решение хорошее, только если данные одной структуры. Минус состоит в том, что при таком решении каждое резервное приложение должно обратиться к главному и вычитать из него данные. Если в процессе что-нибудь произойдет с главным приложением и оно будет удалено, то резервные приложения останутся без новых данных. Системный баг в самом Андроиде, также является серьезной проблемой, которая была решена только в четвертой версии OS.

Было решено использовать бродкасты. Их предназначение — уведомление о случившихся событиях, но вместе с ним можно передать небольшой пакет данных.



Плюс использования бродкастов в том, что исчезает зависимость от состояния отправителя. Бродкаст примут резервные приложения и вычитают из него данные. Минус состоит в том, что размер отправляемых данных ограничен, в большинстве случаев 512 килобайтами.

Артем Кошелев (QA Team Lead): «Качество кода автотестов»


Артем считает, что главным в тестирование является обратная связь. Основным свойством обратной связи является время обратной связи, потому что, чем меньше это время, тем обратная связь эффективнее. Если смотреть на обратную связь в процессе разработки, то в целом ее можно разделить на два подхода: статический и динамический анализ, куда входит классическое ручное тестирование или написание автотестов. То есть, когда уже выполняется код в каком-то окружении, и можно анализировать, как ведет себя приложение.

Статический анализ. Если расположить виды обратной связи на некоторой шкале обратной связи, на которой есть КПД и время, то КПД тем выше, чем меньше анализ занимает времени:



Компилятор, подсветка синтаксиса — это обратная связь, которая получается моментально.

Статический анализ может быть автоматическим и ручным. Автоматический анализ позволяет обеспечить понятность и простоту разрабатываемого кода. Понятность кода напрямую вытекает из следования стандартам. Каждый язык заточен под определенные задачи, соответственно, у каждого есть какой-то свой стандарт. Для Python это — РЕР 8, Perl — Perlstyle, Js — Framework depend, .NET — MSDN, Java — Oracle.

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

В целом, стандарт состоит из шести правил:

именование
отступы/скобки
пробелы
коменты
магические числа
размер
Цикломатическая сложность вычисляется по формуле С = е - n + 2.



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

При разработке тестов ограничение на сложность — 1, то есть, тесты должны абсолютно линейными, простыми. Если тесты делать сильно сложными — есть некоторая вероятность того, что они будут более сложными, чем тестируемый код.

Ручной статический анализ (Code-review) ведет к хорошей архитектуре.

Юрий Картынник (руководитель бригады разработки): «Факторы ранжирования: основы»


Юрий рассказал о разработке и внедрении факторов ранжирования. По его словам, качество поисковой системы можно измерять различными способами, туда входит объем поисковой базы, качество сниппетов, качество ранжирования.

Ранжирование — это выбор и упорядочивание наиболее релевантных результатов для запросов. Из огромного количества проиндексированных страниц нужно выбрать 10 лучших документов по запросу. Решать эту задачу и помогают факторы ранжирования.

Факторы ранжирования — это числовые или категориальные характеристики пары «документ-запрос», причем, можно еще включить регион пользователя или пользовательский идентификатор.

Классификация факторов ранжирования по источнику данных:

1. Текстовые (одни из самых важных)

Соответствие текста запроса и текста документа
Тематическая классификация запросов и документов
Язык, длина...
2. Ссылочные

Цитируемость документа
PageRank и другие факторы на ссылочном графе
Аналоги текстовых факторов по текстам ссылок
3. Статистические

Популярность запроса
Популярность сайта
4. Географические

5. Временные

Можно подсчитывать статистику, насколько данный запрос популярен среди пользователей даже в данное время суток, или насколько данный сайт популярен среди пользователей Яндекса по результатам поиска.

Виды факторов по месту расчета:

Статические (один раз при индексировании)
Запросные (один раз на запрос)
Динамические (все пары запрос-документ)


Функция ранжирования по набору факторов определяет оценку релевантности

Инструменты факториста:

1. C++, Python и др. (в экспериментах)

2. Платформы распределенных вычислений

MapReduce (над большими таблицами)
Mesh (на графах)
3. Платформа FML

Тестовая реплика поискового индекса
Инфраструктура подбора формул
Эксперименты, мониторинг