-Поиск по дневнику

Поиск сообщений в rss_rss_hh_new

 -Подписка по e-mail

 

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 17.03.2011
Записей:
Комментариев:
Написано: 51

Habrahabr/New








Добавить любой RSS - источник (включая журнал LiveJournal) в свою ленту друзей вы можете на странице синдикации.

Исходная информация - http://habrahabr.ru/rss/new/.
Данный дневник сформирован из открытого RSS-источника по адресу http://feeds.feedburner.com/xtmb/hh-new-full, и дополняется в соответствии с дополнением данного источника. Он может не соответствовать содержимому оригинальной страницы. Трансляция создана автоматически по запросу читателей этой RSS ленты.
По всем вопросам о работе данного сервиса обращаться со страницы контактной информации.

[Обновить трансляцию]

Rich Notifications, utm-метки, webhook и другие нововведения PushAll

Среда, 14 Июня 2017 г. 22:04 + в цитатник


За последние 5 месяцев произошло много изменений в PushAll. Много мелких изменений, правок ошибок и оптимизаций, но есть и крупные изменения, о которых мы опишем в статье. Каждый пункт выполнен в стиле how-to.



Rich Push Notifications.



Rich Notifications это уведомления с дополнительными элементами. Например стандартный набор состоит из иконки, заголовка и текста. Rich Notifications добавляет к этому набору кнопки и крупную картинку.

Мы очень долго тянули с этой «фичей», а зря. Демка в виде дополнения для хрома от 2014 года давно уже висит, и для Android, Rich Notifications были представлены еще в 2012 году. И только пол года назад они стали доступны для Web Push.

Мы сделали поддержку Rich Notifications для Chrome дополнения, Android приложения, Email (приходят уведомления с кнопками и большой картинкой) и для Web Push. Также такие уведомления доступны через историю уведомлений в любом браузере.



Это очень полезная функция. Например если у вас есть превью к вашей новости — вы можете его поместить на крупную картинку. Если ваше уведомление имеет ветвление — например вы обновили приложения сразу для iOS и Android и вы можете отправить одно уведомление с обоими ссылками. Также на основе этой механики можно делать опросы, или давать пользователю выбор, чтобы он мог отреагировать на уведомление. Например если у вас есть сервис для напоминаний то у уведомления могут быть 2 кнопки — отложить на час, и отменить, а по клику на само уведомление будут открываться подробности напоминания.

Нужно помнить, что на некоторых платформах, например iOS и Safari, такие кнопки не поддерживаются. Вы должны это предусмотреть это на вашей стороне, отображая подобный выбор по клику на уведомлении.



Такие уведомления можно отправить через ручную рассылку, используя кнопку «Дополнительные поля» и через API. Для этого нужно добавить в обычную структуру отправки любого уведомления поля bigimage и actions (внутри него массив кнопок с заголовком и ссылкой)

{  
   "bigimage":"https:\/\/urlimage",
   "actions":[  
      {  
         "title":"test",
         "url":"https:\/\/url1"
      },
      {  
         "title":"test2",
         "url":"https:\/\/url2"
      }
   ]
}


UTM-метки


Для отслеживания конверсий на клики ранее приходилось добавлять utm-метки вручную. Теперь по-умолчанию на бесплатном тарифе добавляется utm-метка utm_source=pushall, на платном тарифе это поле можно отредактировать.



А еще мы оптимизировали работу настроек распределив их на 4 отдельные секции. Это куда удобнее, чем одна большая лента настроек.



WebHook


Нам часто писали, что хорошо было бы сделать альтернативу callback-ссылке. Теперь вы можете привязать свой webhook-адрес и получать в реальном времени данные о подписке или отписке от канала.



Если у вас небольшой личный канал, вы можете получать уведомления о подписке или отписке.



Самое важное — вы можете передать вашу строку, которую вы получите через webhook. Просто добавьте 'authstring'. Например pushall.ru/news?authstring=teststring. И вы получите teststring вместе с другими публичными данными пользователя в виде JSON в postdata. Передача authstring доступна бесплатно до конца недели, далее в платном тарифе. Также эта строка будет передаваться в callback уже совсем скоро.

Также для платных тарифов будет доступны расширенные Webhook-действия, например смена статуса индивидуальных уведомлений (unicast). Это позволит отправить уведомление и в случае, если статус не сменился в течении 10 минут (если оно не было доставлено), отправить через другой канал связи, например, смс-сообщение.

Другие нововведения



Мы поправили множество ошибок в работе сервиса. После урагана в Москве мы сделали канал-зеркало твиттера МЧС Теперь мы компенсируем комиссию яндекса при пополнении баланса, то есть сколько вы потратили за перевод, столько и придет на баланс.




На платном тарифе можно редактировать цвета канала (только не переборщите).



Мы перешли на Let's Encrypt и включили шифрование для Email-рассылок.



Тем временем отправлено около 100 миллионов уведомлений.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330922/


Метки:  

[Перевод] Создание быстрых и более оптимизированных сайтов на WordPress

Среда, 14 Июня 2017 г. 19:34 + в цитатник
Большинство потребителей имеют уже сложившееся мнение о том, что касается услуг web-хостинга. Если вы будете искать отзывы о любом хостинг-провайдере, вы обнаружите десятки результатов. И обычно, негативных отзывов там намного больше, чем положительных. Я думаю, я смогу это исправить, поэтому делюсь с вами задачами, с которыми мне приходится сталкиваться как оператору поддержки хостинга для WordPress, а также их решениями.

Я собрал список плохих web-решений, а также рекомендаций о том, чего делать на вашем сайте не стоит. Список основывается на тысячах часов общения с клиентами, а также поддержки и устранения неполадок, с которыми я сталкиваюсь ежедневно. Что-то из предложенного будет достаточно примитивным, а какие-то вопросы будут более продвинутого уровня. Многое из описанного может отделять успешный сайт на WordPress от провального. Ведь, несмотря на то, что выбор правильного web-хостинга очень важен, вы должны уделять достаточно времени оптимизации сайта на WordPress, чтобы он был успешным.

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

1. Смена хостинга — не всегда решение проблемы
2. Работающие сайты не предназначены для разработки
3. Не разработчик? - Не лезь в код
4. Не экономьте на темах и плагинах
5. Контролируйте AJAX-запросы
6. Будьте аккуратны при работе с рекламными сетями и внешними сервисами
7. Чрезмерная оптимизация может нанести вред производительности
8. Популярные проблемы с производительностью легко диагностировать
9. Изменение ядра WordPress, это плохо
10. Обеспечьте совместимость с PHP 7 и HHVM до переноса сайта
11. Крупные сайты должны заниматься оптимизацией баз данных
12. Действительно ли вам необходима универсальная тема?
13. Лог ошибок - ваш друг
14. Google здесь не просто так
15. 123456 больше не допускается
16. Скрипты не всегда должны загружаться по всему сайту


1. Смена хостинга — не всегда решение проблемы


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

Администрируемый хостинг предоставит вам столько поддержки и помощи, сколько сможет, но не будет заниматься отладкой кода или плагинов. Написание хорошего кода на PHP, создание и редактирование функционала плагинов и тем, правка интеграции, а также наполнение сайта содержимым - не зона ответственности web-хостинга. Этим может заняться опытный разработчик, который вникнет в работу сайта, изучит проблему и решит её.


2. Работающие сайты не предназначены для разработки


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

Если вы не хотите использовать такие решения, вы можете воспользоваться локальной разработкой и тестированием, используя то, что некоторые называют LAMP или LEMP -стеком. Они предназначены для работы с Linux, Apache/Nginx, MySQL и PHP. А такие инструменты, как WAMP и MAMP упростят и ускорят сборку сервера для локальной разработки.

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

Чтобы избежать таких проблем, я рекомендую воспользоваться такими инструментами, как DesktopServer и Local, которые созданы исключительно для ускорения вашего рабочего процесса при локальной работе с WordPress. Они включают в себя упрощенные способы передачи данных рабочему сайту, а также имеют дополнительные функции, такие как работа с WP-CLI и встроенная поддержка режима мультисайтов. Поддержка мультисайтов сама по себе может быть бесценной, поскольку работа с большими локальными копиями WordPress иногда может быть довольно сложной.

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


3. Не разработчик? - Не лезь в код


Люди, которые либо не знакомы с WordPress, либо не знают основ программирования, не должны редактировать файлы. Одна из самых распространенных причин, по которой сайты на WordPress падают, это то, что кто-то занимается редактированием PHP-файла прямо из редактора внешнего вида в панели управления. Кроме того, вы не должны редактировать работающий сайт, как уже было сказано ранее.



Рекомендация для администраторов: поместите следующий код в файл wp-config.php с заменой edit_themes, edit_plugins, и edit_files привелегий для всех пользователей. Это помешает пользователям уронить сайт посредством редактирования кода.
define('DISALLOW_FILE_EDIT', true);


Также, отключите возможность редактирования файлов темы или установки плагинов для пользователей. Для этого поместите следующий код в файл wp-config.php.
define('DISALLOW_FILE_MODS', true);


Учтите, вышеприведенные команды также отключат редактор файлов для тем и плагинов. Больше информации в WordPress Codex.


4. Не экономьте на темах и плагинах


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

Очень часто устаревшие или некачественные темы и плагины подвержены внедрению вредоносов или занимаются установкой вредоносного контента и ссылок на ваш сайт. Согласно исследованиям WP Loop, почти половина из всех опубликованных плагинов, не обновлялась уже более двух лет. Это одновременно шокирует и пугает.



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

Ожидание обновлений установленных плагинов - это огромная проблема для пользователей WordPress, которые покупают решения в сторонних каталогах, вроде ThemeForest. Многие разработчики тем встраивают в них дополнительные плагины, такие как Revolution Slider или Visual Composer. Дело тут в том, что при обнаружении уязвимостей во встроенном плагине, пользователю приходится ждать обновления от разработчика темы, хотя сам плагин мог быть исправлен буквально сразу же. Это делает многие сайты очень уязвимыми для хакеров.


5. Контролируйте AJAX-запросы


Следите за тем, как используются AJAX-запросы на сайте, а также за плагинами, использующими AJAX. Например, API WordPress Heartbeat использует /wp-admin/admin-ajax.php для обращения к AJAX через браузер. Многие из этих обращений лишние. Особенно частое использование этого файла происходит при всплесках трафика и загрузке процессора. Это может существенно замедлить ваш сайт. Это чем-то похоже на запуск DDoS-атаки против себя самого.



Если есть сторонние плагины, использующие admin-ajax.php, убедитесь в том, что они взаимодействуют с ним правильно. Вы без труда можете отслеживать HTTP POST-запросы и, на основе имени, определять, каким плагином они вызваны. Например, тот, что обнаружил я, get_shares_count, оказался популярным плагином для взаимодействия с социальными сетями, который перегружал admin-ajax.php. На сайте с высоким трафиком, перегрузка выросла бы многократно.

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


6. Будьте аккуратны при работе с рекламными сетями и внешними сервисами


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

Вот краткое сравнение того, как рекламные сети могут повлиять на ваш сайт на WordPress.

Параметры тестирования: на тестовый ресурс я добавил три объявления из Google AdSense, размером 300x250. На сайте установлена тема по умолчанию - Twenty Sixteen. Я замерил скорость загрузки до установке AdSense, и после.

До AdSense (результаты тестирования)


  • Первая загрузка: 1,372 с.
  • Повторная загрузка: 1,013 с.


Разбивка содержимого по соединениям:


После AdSense (результаты тестирования)


  • Первая загрузка: 4,103 с.
  • Повторная загрузка: 3,712 с.


Разбивка содержимого по соединениям:



Просто установив 3 объявления Google AdSense, мы добавили 6 дополнительных подключений. Сайт на WordPress c рекламными объявлениями в 2,7 раза медленнее, чем без них. В основном это связано с дополнительным временем поиска DNS и использованием JavaScript на странице. Все это должно создать у вас картину происходящего на крупных сайтах, вставляющих 10 объявлений на одну страницу. Независимо от того, насколько быстрый хостинг вы используете, он не будет исправлять задержки от сторонних рекламных подключений.

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



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



Другим хорошим примером является сайт Huffington Post. Если вы проведете тест скорости загрузки, вы увидите огромное число HTTP-запросов к рекламным сетям. Быстрый тест показал скорость загрузки свыше 13 секунд!
  • Первая загрузка: 15,908 с. | 221 HTTP-запрос
  • Повторная загрузка: 13,957 с. | 66 HTTP-запросов


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

Пример асинхронного JavaScript:


src="example.js" async


Пример отложенного JavaScript:


src="example.js" defer


У Патрика Секстона есть другой метод отсрочки JavaScript. WordPress версии 4.1 и выше, имеет фильтр, с помощью которого вы можете легко добавить атрибуты async или defer к своим скриптам.

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


7. Чрезмерная оптимизация может нанести вред производительности


В Интернете есть тысячи статей, дающих “советы” о том, как ускорить и оптимизировать сайт на WordPress. Но нет ничего хуже, чем когда пользователи чрезмерно оптимизируют свои сайты. Да, это происходит гораздо чаще, чем вы думаете. Владельцам сайтов WordPress часто кажется, что добавив чего-то, он удвоит скорость загрузки.

Ниже я перечислил несколько проблем, с которыми встречаюсь регулярно:

Попытка закэшировать кэш


В отличии от типичных VPS или обычных серверов, многие хостинги WordPress имеют собственное кеширование, которое выполняется на уровне сервера (например, Redis или Memcache). Многие провайдеры запрещают использование кэширующих плагинов, потому что их использование может вызвать все типы проблем, но чаще всего, 502 Bad Gateway. Попытка “закэшировать кэш”, как я это называю, никогда не является хорошей идеей.

Плагины, такие, как WP Rocket и Cache Enabler, великолепны, но они разрабатывались для серверов, которым необходима дополнительная помощь в ускорении вашего сайта. Рекомендую почитать подробнее о том, что касается кэширования объектов - популярной серверной формой кэширования, часто используемой сегодня.

2x CDN = 2x скорость загрузки, верно?


CDN действительно могут значительно уменьшить время загрузки контента в разных географических регионах, но только при грамотной настройке. Один из самых популярных сервисов - Cloudflare, технически является прокси-сервером, и немного отличается от обычного поставщика CDN, поскольку вы направляете к нему весь свой DNS, а не только содержимое сайта.

Обычно я вижу, как пользователи подключают Cloudflare, затем добавляют KeyCDN или MaxCDN вдобавок. Это часто происходит из-за того, что они читают чьи-то сообщения в блогах, где видят рекомендации попробовать новые сервисы. Они устанавливают новые сервисы, забывая про уже подключенные, и, хотя эта комбинация может работать при определенных сценариях, чаще всего, все заканчивается беспорядком. В большинстве случаев, стоит использовать либо Cloudflare, либо стороннего поставщика CDN, каждый из которых имеет свои преимущества и недостатки.

Огромное количество SEO-плагинов не обеспечивает более высокую позицию в поисковой выдаче


Вы хотите доминировать в поисковой выдаче, это понятно. Но ведь добавление 3 плагинов для SEO не поможет вам достичь этой цели. На самом деле, есть много проблем с совместимостью, возникающих при использовании All In One SEO, Yoast и других плагинов для SEO одновременно, например, вывод дублирующих метатегов. Установка дополнительных плагинов не гарантирует улучшение вашей поисковой оптимизации.


8. Популярные проблемы с производительностью легко диагностировать


Даже если вы не являетесь продвинутым пользователем WordPress, общие проблемы с производительностью достаточно легко обнаруживать. Продвинутым пользователям я рекомендую пользоваться WebPageTest, поскольку он поддерживает последние протоколы HTTP/2. Для остальных подойдет Pingdom. Простой каскадный анализ покажет вам, есть ли у вас ненужные переадресации, отсутствующие файлы, избыток DNS-запросов или перегрузка сайта через сторонние скрипты или рекламные сети.

Взгляните на оценки производительности и коды ответов, и вы узнаете, с чего начать решение ошибок на вашем сайте.




9. Изменение ядра WordPress, это плохо


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


10. Обеспечьте совместимость с PHP 7 и HHVM до переноса сайта


Известно, что PHP 7 и HHVM очень способствуют повышению производительности сайтов на WordPress. И конечно, всегда приятно использовать новейшее и самое лучшее. Но сначала стоит убедиться, что ваш сайт совместим с этими технологиями. Например, если вы обновляетесь с PHP 5.6 до PHP 7, вы должны протестировать все функции вашего сайта на WordPress в обкаточной среде или локально, чтобы убедиться, что проблем с совместимостью нет. Один устаревший, но очень важный для вас плагин, может не работать с PHP 7, что означает, что вам придется подождать его обновления, прежде чем переходить на более свежие технологические решения.


11. Крупные сайты должны заниматься оптимизацией баз данных


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

Вы можете конвертировать свои таблицы всего в несколько простых действий. Для начала, убедитесь, что вы используете MySQL 5.6.4 или более новую, а также, что вы сделали резервную копию, в качестве меры предосторожности. В этом примере используется таблица wp_comments. Просто запустите команду ALTER, чтобы преобразовать для работы с InnoDB.

ALTER TABLE wp_comments ENGINE=InnoDB;

Если же вы работаете с актуальной версией phpMyAdmin, вы можете открыть нужную таблицу, перейти во вкладку “Операции” и изменить механизм хранения там.



Еще один простой способ оптимизации - это отключение или ограничение количества хранимых исправлений в базе данных. Вы можете добавить в свой wp-config.php следующее, чтобы полностью их отключить.
define('WP_POST_REVISIONS', false );


Или просто измените их количество, хранимое для каждого поста или страницы:
define('WP_POST_REVISIONS', 3);


Мне попадалось множество сайтов с более чем 200 версий постов. Если у вашего хостинга нет внутренней оптимизации, настройки WordPress придется задавать вручную, ведь по умолчанию, он будет хранить неограниченное число исправлений.

Если на вашем сайте сохранено множество изменений, вы можете запустить этот сценарий в phpMyAdmin, чтобы их удалить:
DELETE FROM wp_posts WHERE post_type = "revision";


Вы также можете воспользоваться плагином WP-Optimize для этих целей.


12. Действительно ли вам необходима универсальная тема?


Существует огромная проблема, которую я наблюдаю в сообществе WordPress. Люди покупают универсальные темы, а используют лишь 1% её функционала или и того меньше. Они смотрят на демо-страницы и видят красивые слайдеры и кастомизированные блоки, которые убеждают их в необходимости приобретения, однако, на самом деле, эти возможности могут никогда им не пригодиться. Можно купить более простую и менее функциональную тему, и тем самым, сэкономить и деньги и время, которое, в итоге, будет затрачено на ее оптимизацию, ведь простая тема будет быстрее прямо “из коробки”.

Я не хочу сказать, что все универсальные темы плохие. На самом деле, при грамотной настройке, они могут работать очень быстро - вот пример с темой Avada, которая загружается за 700 мс.



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


13. Лог ошибок - ваш друг


Если вы знаете, как вести себя с файлами WordPress и файлом wp-config.php, журнал ошибок может сослужить вам хорошую службу. Регулярно проверяя его, вы спасете себя от всевозможных головных болей, а также глубже изучите работу WordPress. Мало кто из пользователей заглядывает в лог перед обращением за помощью к техподдержке хостинга. С помощью нескольких простых настроек в wp-config.php, вы сможете включить ведение журнала ошибок, который по умолчанию сохраняется в /wp-content/debug.log.

Включение логирования:
define( 'WP_DEBUG_LOG', true );


Вывод логов на странице:
define( 'WP_DEBUG_DISPLAY', true );

Подробнее в WP_DEBUG codex.


14. Google здесь не просто так


Не бойтесь искать ответы в Google. Интернет полон подсказок и решений. В течение пары минут, вы можете исправить большинство ваших проблем. Ответы на типичные вопросы, вроде “как изменить DNS в GoDaddy” или “как пользоваться sFTP”, легко могут быть найдены в Google.

В Интернете есть крупные ресурсы, посвященные работе с WordPress, такие, как StackExchange и WordPress Codex, не говоря уже о сотнях блогов с обучающими статьями.

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


15. 123456 больше не допускается


SpashData собирает список наиболее часто используемых слитых паролей (более 2 млн.) каждый год. Неудивительно, что в 2015 году самым популярным паролем был “123456” - тот же, что и в 2014 году. Это довольно неприятно для хостингов, так как использование таких паролей держит сайты буквально в шаге от взлома. Одним из лучших решений является использование KeePass или его аналогов. Зашифрованный пароль в облаке всегда намного безопаснее, чем “123456”.


16. Скрипты не всегда должны загружаться по всему сайту


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

Один из таких примеров - популярный плагин Contact Form 7. Как показано ниже, он загружает файлы CSS и JavaScript на домашнюю страницу сайта, хотя там не используется ни одной контактной формы.



Есть несколько способов это исправить. Первый - использовать функцию wp_dequeue_script(), введенную в WordPress 3.1. Она позволяет удалять скрипты из очереди загрузки на вашем сайте. Вот пример использования этой функции с Contact Form 7. Разработчик Contact Form 7 также имеет документацию о том, как использовать JavaScript и CSS только там, где это необходимо.

Второй способ - использовать специальные плагины для WordPress, например, Gonzalez или Plugin Organizer. Ниже приведен пример использования Gonzalez на нашем сайте. Удобное окно настроек позволяет за пару щелчков мыши убрать JavaScript и CSS файлы плагина Contact Form 7 со всех страниц, кроме страницы контактов, тем самым, увеличив скорость загрузки остального сайта.



Заключение


Существуют причины, по которым WordPress используется на более чем 28% всех веб-сайтов. Это очень надежная, удобная и многофункциональная CMS. Каждый, от авторов домашних блогов до нескольких сотен компаний, полагается на него каждый день. Но так же, как с большинством платформ, если использовать WordPress неправильно или не заниматься его оптимизацией, работа с ним может быстро превратиться в головную боль.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330918/


Метки:  

[Из песочницы] Динамическая таблица поверх Google Maps

Среда, 14 Июня 2017 г. 19:33 + в цитатник

Введение


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


К сожалению (или к счастью?), готовых решений я не нашёл. Google Карты позволяют накладывать маркеры и фигуры на карты, но эти способы представляют слишком мало информации. С Яндекс картами оказалось не лучше. Но Карты Гугл имеют механизм пользовательских наложений с HTML-содержанием. И для инкапсуляции этой работы с картами и наложениями я создал JavaScript библиотеку GMapsTable. Возможно, кому-нибудь она окажется интересной или полезной. Рабочий пример.


image


Условности

Чтобы не возникло путаницы, параметр zoom будем называть приближением карты, а scale — масштабом. Первый относится к Google Maps API, а второй к описываемой библиотеке.


Задача в целом


Итак, что у нас есть? Какой-нибудь источник данных (например, сервер с базой данных, обрабатывающий и посылающий данные в формате JSON) и веб-страничка с JavaScript, которая запрашивает данные и визуализирует их на Картах Гугл.


Данные имеют аккумулятивную природу (в моём случае каждой области можно поставить в соответствие: число заказов, клиентов и среднюю сумму). Поэтому данные могут и должны отображаться с разной детализацией для разных приближений.


Основное содержание HTML страницы для GMapsTable:


 ..в :



 ..в :

GMapsTable позволяет абстрагироваться от взаимодействия с GoogleMaps API. Вам нужно лишь предоставить подходящий объект с данными. Время перейти к JavaScript'y! Чтобы использовать GMapsTable, нужно получить объект DataContainer для Вашего div'a карты:


// Аргумент: ID div'а
//   и словарь параметров GoogleMaps,
//   это не обязательно
var container = new DataContainer("map", {
    zoom: 9,
    center: {lat: 55.7558, lng: 37.6173},
    mapTypeId: 'roadmap'
});

Затем нужно передать две функции:


container.dataLoader = function (scale, borders) {
    ... вызвать container.processData(some_data);
}

container.scaler = function (zoom) {
    ... return какое-нибудь число;
}

Но что именно писать внутри функций?.. Для начала разберёмся, как работает GMapsTable.


Data для DataContainer


DataContainer занимается отображением Ваших данных и заботится о том, когда оно должно быть обновлено. В самом начале и когда изменяются приближение и границы "камеры", он пробует использовать сохранённые данные, а если их нет, то вызывает функцию dataLoader. Вам нужно сгенерировать объект с данными и передать его функции DataContainer.processData. Структура объекта должна быть такая:


data: {
    minLat: float,
    difLat: float,
    minLon: float,
    difLon: float,
    scale: int,
    table: [
        [value, value, ...],
        [value, value, ...],
        ...
    ],
    tocache: boolean
}

Значением (value) может быть число, строка или любой объект, если вы укажите собственную функцию форматирования ячейки таблицы. Масштаб (sale) это целое число, говорящее, на сколько частей должны делиться единицы широты и долготы. Параметр tocache указывает, должны ли данные для текущего масштаба быть сохранены и более не запрашиваться.


Пример объекта данных
data: {
    minLat: 55.0,
    difLat: 2.0,
    minLon: 37.0,
    difLon: 1.0,
    scale: 2,
    table: [
        [1, 3, 0, 1],
        [0, 1, 2, 0]
    ],
    tocache: true
}

Здесь данные покрывают область от 55.0, 37.0 до 57.0, 38.0 и делят каждую единицу широты и долготы на 2 части (получается, одна клетка широты-долготы делится на 4 части). Также здесь указано, что для данного масштаба это полные данные, и они должны быть сохранены для использования в дальнейшем.


Перевод приближения в масштаб


Приближение (zoom) это параметр Google Maps API, целое число между 1 (карта мира) и 22 (улица). Запрашивать и хранить данные для каждой единицы приближения неудобно и нецелесообразно, поэтому GMapsTable переводит их в масштаб (scale) — число, указывающее, на сколько частей нужно делить единицу широты и долготы.


Сохранение данных


Чтобы отображение при изменении масштаба было моментальным, GMapsTable хранит наборы данных для некоторых (либо всех) масштабов. Например, у меня была база данных с координатами почти со всей России — около 42 тысяч ячеек для масштаба 10 (500 КБ, довольно легко хранится и обрабатывается у меня в десктопном браузере) и 17 миллионов для масштаба 200 (несколько МБ, вызывает значительные подвисания). Поэтому сервер оценивает число ячеек всех данных, и если их немного, отправляет данные из всей БД, иначе только для запрошенного региона. Получается такой алгоритм:


алгоритм обновления таблицы GMapsTable


Границы (bounds) — это объект JavaScript с полями minlat, maxlat, minlon, maxlon — текущими границами Google Maps и хорошим отступом про запас.


В Вашей реализации dataLoader Вы можете смело игнорировать аргументы, если нет нужды использовать разную детализацию для разных масштабов или если Ваши данные не покрывают такой большой регион. Просто передайте данные и их границы по широте и долготе и scale, на сколько разбиваете единицы широты-долготы. Но для полноты картины я предлагаю такое поведение функции dataLoader (или сервера, к которому она обращается):


алгоритм генерации объекта данных для GMapsTable


Список всех параметров


Вы можете указать такие параметры для DataContainer:


1) scaler(zoom) — переводит приближение из GoogleMaps в масштаб для GMapsTable. Оба целые числа.


2) dataLoader(scale, borders) — вызывается, когда нужны новые данные. Должен передать объект данных в DataContainer.processData(data).


Параметр borders это объект JavaScript с полями minlat, maxlat, minlon, maxlon — текущими границами Google Maps и хорошим отступом про запас.


3) tableBeforeInit(map, table, data) — вызывается перед тем, как таблица начинает заполняться ячейками. Аргумент map это объект Google Maps, table это HTML элемент таблицы, а data — предоставленный Вами объект данных для текущего масштаба.


4) cellFormatter(td, val) — вызывается для заполнения ячейки. td это HTML element, ячейка таблицы. val это данные из Вашего объекта данных.


5) boundsChangedListener(zoom) — вызывается, когда изменяются границы Google Maps.


6) minZoomLevel, maxZoomLevel — переменные для минимального и максимального приближения карты. Целые числа между 1 (карта мира) и 22 (улица).


Для успешной работы DataContainer необходимы только первые две функции.


Пример и исходники


Полный и хорошо прокомментированный пример использования: HTML-страничка и JS-код.
А также есть GMapsTable в GitHub.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330920/


Метки:  

Russian Minesweeper — мультиплеерная версия игры «Сапёр»

Среда, 14 Июня 2017 г. 18:27 + в цитатник
image
Здравствуйте, уважаемые читатели.
Искренне надеюсь, что среди читателей Хабра найдутся любители такой замечательной игры как «Сапёр».
Если верно помню, то впервые эта игра появилась на операционной системе Windows 3.1 ещё в далеком 1994-ом году. В то время эта игра позиционировалась как средство для обучения использованию компьютерной мыши и в целом графическому интерфейсу ОС. Выглядела она примерно так:
image
Принцип игры согласно Wikipedia
Плоское или объёмное игровое поле разделено на смежные ячейки (квадраты, шестиугольники, кубы и т. п.), некоторые из которых «заминированы»; количество «заминированных» ячеек известно. Целью игры является открытие всех ячеек, не содержащих мины.
Игрок открывает ячейки, стараясь не открыть ячейку с миной. Открыв ячейку с миной, он проигрывает. Мины расставляются после первого хода, поэтому проиграть на первом же ходу невозможно. Если под открытой ячейкой мины нет, то в ней появляется число, показывающее, сколько ячеек, соседствующих с только что открытой, «заминировано» (в каждом варианте игры соседство определяется по-своему); используя эти числа, игрок пытается рассчитать расположение мин, однако иногда даже в середине и в конце игры некоторые ячейки всё же приходится открывать наугад. Если под соседними ячейками тоже нет мин, то открывается некоторая «не заминированная» область до ячеек, в которых есть цифры. «Заминированные» ячейки игрок может пометить, чтобы случайно не открыть их. Открыв все «не заминированные» ячейки, игрок выигрывает.

Однако, время идет, популярность сапера падает, и хочется внести новую жизнь и краски в эту игру. Именно так и родилась мультиплеерная версия игры, именованная как "Russian Minesweeper", которая представляет собой браузерную онлайн игру.
Заинтересовавшихся прошу под кат.

Характеристики игры


Разумеется, чтобы какое-то количество игроков смогли вместе играть в эту игру, правила придется каким-либо образом модернизировать и вообще видоизменять. Однако, главное правило — существенный принцип оставить как в оригинале.
Таким образом, собственно, и был разработан комплекс правил, чтобы позволить нескольким игрокам одновременно играть на одном и том же поле.

Основные правила игры следующие:
  1. Цель игры — первым пометить все мины флагами и открыть пустые клетки.
  2. У каждого игрока свои (локальные) флаги.
  3. У игроков одно и тоже (глобальное) поле с минами.
  4. Игроки ходят по очереди (однако, сейчас ведется разработка «параллельного» режима).
  5. Если игрок кликнет по мине, он проиграет, а его оппонент выиграет соответственно.
  6. Время на ход игрока ограничено (~25 сек.) — необходимо ходиться как можно быстрее.
  7. Если игрок пропустит ход три раза подряд, он проиграет, а его оппонент выиграет соответственно.
  8. Если игрок пропустит шесть ходов за все время игры, он проиграет, а его оппонент выиграет соответственно.
  9. Ничья невозможна. Один из игроков в любом случае выставит флаги корректным образом быстрее чем другой.
  10. Первый ход достается случайному игроку.
  11. Игрок может сдаться в любой момент игры.


Также был разработан ряд характеристик минного поля для игры:
  1. Подрыв при вскрытии первой клетки в начале игры невозможен.
  2. Мины равномерно распределены по игровому полю.
  3. Свойства «пустоты», открываемой при первом клике:
    1. Размер от A до B пустых клеток (0 мин вокруг).
    2. Пустота не должна представлять из себя линию открытых клеток только по одной из сторон ориентации.
  4. Процент минных клеток (тип регулятора — вещественный) и размер поля регулируются в настройках приложения.


Таким образом, при текущей конфигурации, при первом клике открывается «пустота» от 3 до 12 «нулевых» клеток, а поле размера 32x20.

Извиняюсь за огромное количество списков, однако, не могу не упомянуть, что игра помимо этого обладает следующим функционалом:
  • Аккорд — открытие более одной клетки за ход. Это возможно в случае клика (ЛКМ) по цифре в клетке на игровом поле, а кол-во флагов вокруг смежных клеток равно искомой цифре.
  • Чат — между игроками в режиме реального времени.
  • Nickname в игре.
  • Звуковое сопровождение в игре.


Технологии


Полный список технологий, используемых при разработке продукта, следующий:
  • C# .NET + ASP .NET – основа для веб-сервера.
  • HTML5 / CSS3 – для разработки интерфейса клиентской части.
  • JavaScript – для динамической работы клиентской части.
  • JSON – для сериализации/десераилизации пакетов клиент-сервер.
  • WebSocket – протокол используется как метод связи клиент-сервер.
  • HTML Canvas — технология для отрисовки минного поля.
  • jQuery – эффективное и быстрое взаимодействие между HTML и JS.
  • JSON Newton – библиотека для удобной работы с JSON.
  • Adobe Photoshop – для отрисовки графических элементов интерфейса.
  • GitHub – как удобная площадка для контроля версий проекта.
  • Microsoft Azure – для размещения веб-сервера в Интернете.
  • Яндекс.Метрика – статистика и анализ поведения игроков.
  • CloudFlare – в качестве CDN-прокси / SSL / Anti DDoS.
  • Microsoft Visual Studio – в качестве основной среды разработки.
  • Sublime Text – в качестве инструмента разработки под JavaScript.
  • Microsoft IIS – для разворачивания ASP. NET

image

Самими проблемными местами в проекте было нижеследующее:

  • Синхронизация игроков друг с другом
    • Проблема: как быстро оповещать игроков об изменениях на поле?
      Варианты: long polling; websockets; cyclic polling; etc
    • Решение: использовать WebSocket
  • Отрисовка минного поля и прочих элементов игры
    • Проблема: какие инструменты будут наиболее оптимальны?
      Варианты: HTML table/div; SVG; HTML5 Canvas; etc
    • Решение: HTML5 Canvas + JavaScript



Интересные цифры


  • 23 человека по меньшей мере принимали участие в тестировании.
  • 183 298 клика сделано по полю во время тестирования.
  • С 119-ой попытки минное поле было пройдено до конца.
  • Поле размером 32x20 наиболее оптимально для игры (эмпирическое наблюдение).
  • От 3 до 12 «нулевых» клеток лучше всего открывать при первом клике (эмпирическое наблюдение).

А также прикрепляю карту кликов от Яндекс.Метрики, по ней можно сделать ряд интересных умозаключений. Например очевидно, что основная область «битвы» это центр поля, а чат пользуется популярностью.
image

Планы на будущее


В будущем хочется доделать следующий функционал:
  • Реализовать комнату на N игроков.
  • Возможность создания «дружеской комнаты» и одиночного режима.
  • Оптимизация приложения под мобильные устройства.
  • Переход на более мощные сервера для реализации приложения в массы.
  • Создание баг-трекера.
  • Реализация удобной обратной связи с игроками.
  • Более детальная статистика использования приложения.


Заключение


image
В заключение хочу сказать следующее — будьте, пожалуйста, аккуратнее с сервером игры :)
Он получен бесплатно по подписке от Microsoft Azure и его мощности крайне скромны.
Искренне уповаю на то, что после этой статьи мы с вами вместе сможем насладиться этой игрой.
Напоминаю, что она доступна по адресу https://rmsweeper.tk, а также есть сообщество во «ВКонтакте».

Спасибо за внимание,
с Вами был Петр.
Умеете ли вы играть в классический сапер?

Проголосовало 4 человека. Воздержавшихся нет.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330910/


Метки:  

Потенциально опасные алгоритмы

Среда, 14 Июня 2017 г. 18:18 + в цитатник

Метки:  

Распределённые вычисления поверх Ceph RADOS и AsyncMessenger

Среда, 14 Июня 2017 г. 18:14 + в цитатник
Перемещение вычислений в сторону данных может приводить к снижению временных затрат на порядки за счёт исключения необходимости перемещения самих данных в сетевой среде. Этой цели служит класс RADOS, вызовы к которому могут выполняться функциями librados.
Асинхронная система сообщений существенно снижает накладные расходы сетевого уровня Ceph, а применение абстракций NetworkStack делает возможной реализацию различных протоколов стека (POSIX/ SPDK/ DPDK/ RDMA).


Программирование при помощи librados


Для достижения максимальной производительности и внутренней гибкости Ceph можно применять встроенные в библиотеку librados вызовы функций, доступные для большинства языком программирования, например, для C, C++, Python, PHP и Java. С этой целью вы сначала устанавливаете инструменты разработки. Например, для Debian- дистрибутивов:
$ sudo apt-get install build-essential
$ sudo apt-get install librados-dev
Затем в своём приложении вы:
  1. Выполняете необходимые подготовительные операции самого приложения (считывание параметров, подготовку справки об этом приложении и т.п.)
  2. Считываем файл настроек ceph.conf для получения мониторов
  3. Подключаемся к кластеру Ceph
  4. Открываем нужный пул RADOS
  5. Открываем образ для чтения/записи
  6. Выполняем необходимую операцию чтения/записи
  7. Закрываем соединение с пулом
  8. Закрываем соединение с кластером Ceph

(Пример приложения)
Порой приложение требует атомарности выполняемой операции, состоящей из нескольких действий, например, из записи собственно данных и их атрибутов. То есть, если в процессе выполнения атомарной (неделимой) последовательности действий происходит какое- либо прерывание или некий сбой, отвергаются все уже выполненные действия. Реальной записи или изменения не происходит. Долгое время разработчики Ceph не теряли надежды на поддержку атомарности за счёт средств btrfs, поскольку её реализация в рамках xfs приводит к снежному кому проблем, самой малой из которых является необходимость, как минимум, дублированной записи. В конце концов, начиная с выпуска Kraken для лежащее в основе OSD хранилища было принято решение по умолчанию отказываться от файлового хранения с применением POSIX файловых систем и применять упрощённую файловую систему BlueFS для хранения собственно данных и RocksDB для хранения метаданных и, возможно, отложенных записей (WAL, write-ahead log). Данное хранилище получило название
BlueStore (указывающая на Blочную природу хранилища, изначально имевшего незатейливое название NewStore). подробнее...
Теперь, имея в руках полноценную реализацию транзакций, не отягощённую избыточными накладными расходами, мы со спокойной совестью можем их использование в своих приложениях. Посмотрим как меняется скелет нашей программы:
  1. Выполняете необходимые подготовительные операции самого приложения (считывание параметров, подготовку справки об этом приложении и т.п.)
  2. Считываете файл настроек ceph.conf для получения мониторов
  3. Подключаетесь к кластеру Ceph
  4. Открываете нужный пул RADOS
  5. Инициализируем списки буферов обмена (по числу необходимых действий) и заполняем их данными
  6. Создаём транзакцию
  7. Последовательно записываем данные буферов обмена в транзакцию
  8. Фиксируем транзакцию
  9. Закрываем соединение с пулом
  10. Закрываем соединение с кластером Ceph

(Пример приложения)

Ещё одной достойной функциональностью librados является организация приложений наблюдатель- уведомитель ( watch — notify).
Работа наблюдателя организуется путём обратного вызова (callback). При создании наблюдателя через вызов соответствующей функции вы передаёте в таком вызове двумя параметрами ссылки на необходимые функции обратного вызова. Первая применяется для выполнения действия в случае получения уведомления, а вторая используется когда что-то пошло не так, в ней вы производите необходимые действия по отработке ошибок.
Например, таким образом вы создаёте моментальный снимок некоторого объекта. Клиент, которому требуется выполнить такой снимок, отправляет всем находящимся в ожидании для данного объекта клиентам (watcher) уведомления (выступая в качестве notifier), в котором он сообщает, что может сбросить свой кэш данного объекта и выполнить проверку на непротиворечивость данных.
(Пример приложения)

Распределённые вычисления при помощи классов RADOS Ceph


Библиотека librados работает с объектами, хранящимися в распределённой системе хранения RADOS (Reliable Autonomic Distributed Object Store), в основе которого лежат демоны хранения объектов (OSD, Object Storage Daemon), каждый из которых обслуживает некое собственное хранилище (например, уже упоминавшееся BlueStore).

Одним из примечательных свойств OSD является возможность локальной обработки хранимых в нём данных методами класса RADOS. Это открывает широкие возможности революционного увеличения производительности распределённой обработки хранимых данных, поскольку избавляет вас от необходимости обмена самими данными для такой обработки.
Например, вы можете вычислять хеш-значения и контрольные суммы данного объекта, осуществлять их проверку. Вы можете выполнять поиск в таких данных и их анализ, выставляя результаты, скажем, в метаданных самого объекта.

Одним из простейших способов такой разработки является применение языка сценариев Lua, который, начиная с выпуска Kraken встроен в класс RADOS. Данный сценарий, как правило, в виде строк JSON (скажем, в программе с применением librados на Python) передаётся в имеющийся объект класса RADOS, где он и исполняется.
Пример приложения изменения в объекте всех строчных букв на прописные. Отметим, что по умолчанию исполнение сценариев Lua в OSD отключено, для включения такой возможности необходимо внести приведённые в примере изменения в файлы настроек OSD.

К сожалению, в настоящее время функциональные возможности языка сценариев Lua достаточно ограничены. Для решения более сложных задач вам придётся скомпилировать исходный код Ceph со встроенным в него классом RADOS, написанным, например, на C или C++. В Примере приложения вычисления MD5 объекта приводятся пошаговые инструкции построения такого решения, а также сопоставляются результаты времён его работы в сравнении с аналогичным приложением, исполняющимся на клиенте, находящимся не на узле OSD и вынужденном считывать данные с OSD и записывать в него результат расчёта. результат сравнения даёт преимущество в абсолютных затратах времени в два порядка.

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

Ceph Async Messenger


Дополнительные средства для распределённой обработки данных предоставляет имеющаяся в Ceph система асинхронного обмена сообщениями. Например, таким образом реализован механизм применения RDMA в реализации Mellanox.

Первоначально AsyncMessenger, судя по всему, разрабатывался в качестве расширения epoll, призванного полностью вытеснить SimpleMessenger, являющийся первоначальной системой обмена сообщений и лежащей в основе сетевого протокола Ceph. Такая потребность вызвана тем фактом, что для каждой пары участников однорангового взаимодействия (peering) в SimpleMessenger создаются 4 потока (по два с каждой стороны). С ростом числа участников это приводит к экспоненциальному росту общего числа потоков (thread) в узлах участников.

В настоящее время все три метода реализуют сетевой протокол Ceph, при этом применяя один общий рабочий пул.

В протоколе AsyncMessenger участвуют сервер и клиент. Сервер выполняет инициализацию, привязывается к file descriptor (fd) и осуществляет ожидание уведомлений по нему (listen). В отличие от определённых POSIX методов select() и poll(), epoll предоставляет механизм обработки сообщений со сложностью O(1), в отличие от O(n) для SimpleMessenger, исключая перебор событий, не имеющих активных fd. AsyncMessenger применяет библиотеку libevent, предоставляемую средствами epoll.
Обработка события осуществляется сервером по получению уведомления на fd, либо по тайм- ауту. Помимо этого сервер может добавлять ожидание fd, принимать соединения, добавлять приём fd и осуществлять взаимодействие.

Клиент инициирует установление соединения и устанавливает его для выполнения взаимодействия. Весь обмен сетевого уровня приложений обрабатывается машиной состояний AsyncConnection. Статья Wei Jin акцентирует основные моменты данного типа взаимодействия.

Дальнейшим развитием механизма AsyncMessenger является развитие абстракции NetworkStack, которая позволяет осуществлять распределённую поддержку различных сетевых стеков (Posix/ DPDK/ RDMA), а также встроенной в BlueStore поддержки SPDK.
Данный уровень абстракции реализует понятия ServerSocket и
ConnectedSocket, причём первый ожидает поступления запросов, а второй собственно и осуществляет чтение и запись всех данных. Основные моменты реализации приложений с применением данных абстракций приводятся в статье Стек асинхронной системы сообщений Ceph того же Wei Jin.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330908/


Комиксы Даниэля Стори

Среда, 14 Июня 2017 г. 18:02 + в цитатник
Привет, Хабр! Мы подумали, что если среда — это маленькая пятница, значит можно немножко расслабиться и развлечься. Мы подготовили подборку юмористических IT-комиксов от Даниэля Стори (Daniel Stori). Желаем приятного просмотра.

Arduino-проект


Хайп Detected

«Скоро все будут использовать Docker»

Миграция в Облако (иногда бывают сложности)


TCP-приятели

Если вы случайно зашли на Хабр: TCP (Wikipedia) и список наиболее часто используемых сокращений в IT

Bash на Windows


Я обожаю Windows PowerShell


Дом Линуса Торвальдса

Вы когда-нибудь задумывались над тем, как выглядит дом Линуса Торвальдса? Даниэль Стори приоткрывает нам «окно» в скромный образ жизни знаменитого создателя Linux.


Сказки о DOS

Если вы молоды, то, возможно, не знаете о Дискетах 5 1/4 и игре Test Drive

Тестирование программного обеспечения


Продвинутые биологические виды


Разработчики


Автор немного сгущает краски, говоря о Cobol, но доля правды, конечно, присутствует.

Большие числа


Ловкий трюк для менеджеров по продаже SSL-сертификатов


Если вы не используете SSL, вы не можете быть уверены, что любая конфиденциальная информация, передаваемая на вашем сайте, не будет использована хакерами. Немножко о Kali Linux

Codeless-разработчик или опережая тренды


Реактивное программирование


Когда навыки уже не такие ценные


Когда нанял «неправильного» архитектора

О LAMP

Когда не все понимают, чем ты занимаешься


Как объяснить программисту, что вы расстаётесь и всё кончено


Как я встретил вашу маму


Как программист решает, что пора завести ребёнка


Как объяснить, что принтеры не твоя «стихия» или «посвящается моим родственникам...»
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330906/


Метки:  

Сервис сбора статистики с Flussonic

Среда, 14 Июня 2017 г. 17:57 + в цитатник
Всем привет, хочу рассказать про наш первый сервис, который мы собираемся оказывать нашим клиентам: сбор статистики и отчеты

Много лет мы только продавали софт, теперь мы приготовили к запуску сервис по сбору статистики и предоставлению отчетов. У нас берут Flussonic, запускают его на своих серверах, абоненты смотрят видео с этих инстансов Flussonic и создаются записи о сессиях просмотра.

Эти сессии как раз сливаются в наш сервис и мы покажем отчеты, сделанные по ним, в личном кабинете.



Включается легко: в личном кабинете есть большая кнопка «Включить статистику». После нажатия через минуту Flussonic начнет отправлять нам сессии и они будут надежно сохраняться.

image

В данный момент мы дадим лишь самые базовые отчеты: распределение по странам, по браузерам (и прочим устройствам), по каналам. Можем дать как сырой список сессий, так и агрегировать похожие друг на друга:



За две недели закрытого тестирования, у нас пока что скромный миллиард записей, но мы уверены, что справимся и с объёмом в 100 раз больше: пока что мы можем очень быстро показать даже уникальные сессии, а это очень недешевый отчет. Конкретно на этом скриншоте я показал, как выглядит склеивание похожих сессий в уникальные, т.е. если с одного и того же адреса, с тем же самым User Agent пытались смотреть одно и то же в узкий промежуток времени, то скорее всего это одна сессия, просто плохо учтенная.

Немного деталей



Мы уже столкнулись с очень неприятной проблемой парсинга заголовка User Agent: ведь у нас много приставок (Set-Top-Box) и прочих подобных штук, а они в обычных базах браузеров отсутствуют.

Так же всплыла неожиданная проблема с MaxMind: нельзя просто так купить у них полную базу и показывать вам результаты поиска по ней, это требует специальную лицензию от 30.000$.

Но это всё так, решаемые проблемы и мы сейчас со всем этим работаем.

Отдельный момент с яваскриптовой мордой: это SPA React приложение, которое живет в отдельном микросервисе вместе с самим сервисом. Мы уже не первый компонент так делаем: яваскрипт, css живут и развиваются с самим бекендом сервиса и пользователю подключаются простой вставкой яваскрипта. Хитрости есть с авторизацией, потому что мы хотим не просто сообщать аккаунт, а заодно его права доступа, так что авторизационная сессия открывается при заходе пользователя в личный кабинет через межсерверное взаимодействие.

Планы


Планов на будущее у нас немало:

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


Если кто-то хочет попробовать, пощупать, но ещё не запускал Flussonic, то мы с радостью дадим бесплатный триал.

И, кстати, важно: сбор статистики и отчеты мы собираемся делать бесплатно!
Что вам было бы интересно от статистики видеостримингового сервера?

Проголосовал 1 человек. Воздержавшихся нет.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330898/


Метки:  

Спикеры #ITsubbotnik – о том, как технологии изменят мир через пять лет

Среда, 14 Июня 2017 г. 17:48 + в цитатник
В конце мая в Петербурге прошел четвертый #ITsubbotnik, в котором приняли участие более 400 человек. Это конференция ЕРАМ, где спикеры делятся знаниями, слушатели задают вопросы и получают ответы, знакомятся вживую и путешествуют по виртуальной реальности.

Спикеры #ITsubbotnik – инженеры ЕРАМ, которые не могут не делиться своим опытом с окружающими. Они рассказывают не только об успехах, но и о том, на какие грабли наступали и как справлялись с проблемами.

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



Кто-то любит прогнозировать, кто-то нет, а кто-то делает так, чтобы прогонозы сбывались или нет. Спикеры #ITsubbotnik рассказали, как то, что они делают сегодня, может изменить мир через пять лет.

Дома станут умнее и безопаснее



Сергей Чибирев, Android-разработчик. Тема доклада – «Умный дом своими руками».

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

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

Становится всё сложнее утаить, что такие системы – дешевые, и скоро эти технологии шагнут к нам в дома. Например, я вхожу в квартиру, открывается дверь, мне не нужен ключ: система опознала. Она приветствует меня голосовым сообщением и отвечает на мои голосовые команды, включает мою любимую музыку, зажигает свет. Она поддерживает нужную температуру и уровень влажности в доме. В общем, создаёт среду, в которой мне максимально комфортно. Такие технологии уже доступны. Пока люди относятся к ним, как к роскоши, но скоро привыкнут».



Андрей Ортяшов, Android-разработчик. Тема доклада – «Умный дом своими руками».

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

У людей появится больше свободного времени



Дмитрий Никитко, аналитик данных. Тема доклада – «Нейронные сети для извлечения структурированной информации из документов».

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

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

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

Мы будем делать больше спонтанных покупок



Дмитрий Яцюк, DevOps-инженер. Тема доклада – «Готовое комплексное инфраструктурное решение для Hadoop Big data и AWS с Cloudera CDH 5.x».

«Решение, о котором я рассказывал, рассчитано на крупных клиентов в области ритейла. Что оно изменит через пять лет? Возможно, мы станем больше покупать: нам будут активнее предлагать, рекомендации станут точнее. Это происходит уже сейчас: мы заходим, например, на «Яндекс.Маркет» и покупаем то, о чем даже не задумывались. Чем больше данных анализируют специалисты, тем точнее становятся рекомендации: будь это еда или песня в социальной сети».



Карточки в поликлиниках перестанут пропадать



Сергей Черноляс, Java-разработчик. Тема доклада – «JPA for NoSQL».

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

Искусственный интеллект будет тестировать искусственный интеллект



Антон Шапин, инженер по автоматизированному тестированию. Тема доклада – «Visualization, storage and comparison results of performance testing by using Grafana and InfluxDB».

«Через пять лет изменится все: IT-мир меняется каждый месяц. В QA так или иначе возникнет проблема при работе с большими объемами данных и при проверке искусственного интеллекта. Многие компании идут в область разработки искусственного интеллекта и нейросетей. Как все это тестировать, к сожалению, пока не совсем понятно. Чтобы тестировать искусственный интеллект, нужен будет другой искусственный интеллект. Выработка этих методологий – большой вызов QA-сообществу.

Ручные тестировщики полностью не исчезнут, потому что машина – это машина, а кто создает тесты? Человек. Кроме того, есть области, которые очень дорого проверять в автоматическом режиме, куда нет смысла вкладывать большие деньги».



Роман Иовлев, инженер по автоматизированному тестированию. Тема доклада – «Java edge in test automation».

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

Компании смогут быстрее получать обратную связь о продуктах



Роман Димитренко, DevOps-инженер. Тема доклада – «Building PaaS with the HashiStack».

«Continuous integration и continuous delivery – это то, что движет сейчас любой бизнес и способствует быстрым изменениям. Если говорить о веб-сайтах, то время с принятия решения о добавлении новой функциональности на сайт до его реализации существенно сокращается. В полностью автоматизированной среде речь идет уже не о часах, а о минутах. Все станет быстрее, вмешательства оператора и ручной работы не потребуется.

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

Станет доступен новый вид поиска в сети



Михаил Хлуднев, специалист в области search engines. Тема доклада — «Search LIKE %SQL%».

«Я рассказывал про поиск по подстроке. Это сложнее, чем обычный поиск по ключевым словам. По целому слову все умеют искать, а по его части нет: это очень долго. Я представил методику, как мгновенно находить огромные массивы документов по подстрокам. Что изменится через пять лет? Этот вид поиска будет доступен всем. Любая бабушка сможет сделать поиск по подстроке. Мне кажется, так справки из собеса искать очень удобно».

Хранить данные будет удобнее



Степан Ракитин, Java-разработчик. Тема доклада – «Создаем отказоустойчивые распределенные приложения вместе с Atomix».

«Сейчас есть очень мало баз данных, которые рассчитаны на большие данные и соответствуют принципу «strong consistency», при котором данные должны быть в единственно принятом состоянии среди всех узлов кластера. Я считаю, что в ближайшие годы будут активно развиваться системы хранения данных, гарантирующие отказоустойчивость. Данные будут находиться в актуальных состояниях на всех серверах».



Приложения станут более дешевыми и качественными



Рустам Кадыров, Java-разработчик. Тема доклада – «Как приструнить зоопарк из микросервисов».

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

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

У облаков будет достойный конкурент



Андрей Филатов, DevOps-инженер. Тема доклада – «Ансамбль солёных поваров: сравниваем Ansible, SaltStack и Chef».

«В своем докладе я сравнивал три ведущие, по моему мнению, SCM-системы: Chef, Ansible и SaltStack. В скором времени, мне кажется, эксплуатация практически полностью будет автоматизирована. Профессия системного администратора, который управляет сервисами в ручном режиме, наверное, просто перестанет существовать. Останутся только те, кто использует системы управления конфигурацией в автоматическом режиме. А возможно, всех нас заменят нейронные сети, которые будут генерировать код и управлять инфраструктурой. Этого не случится в ближайшее время, но если говорить о дальней перспективе – вполне возможно.

Сейчас мои персональные фавориты – докер-контейнеры и управление инфраструктурой при помощи контейнеризации. Использование облачных сервисов и контейнеризации решает одни и те же задачи, но разными способами. Контейнеры, например, более производительны по справнению с облаками».

Понадобится больше нефункциональных тестировщиков



Сергей Мишанин, инженер по автоматизированному тестированию. Тема доклада – «Report Portal. Руководство для адептов Cucumber».

«Я уже 10 лет работаю в тестировании ПО, из которых 9 лет занимаюсь автоматизацией. Когда я только начал работать в этой сфере, автоматизация казалась инновационной. Прошло девять лет, и, казалось бы, она должна уже быть везде, но это пока не так. Мы успешно прошли стадию Agile, когда все быстро, динамично, нет времени и ресурсов на тестирование вручную. Потребность в таких тестировщиках будет уменьшаться. Востребованы будут аналитики, но тесты должны выполняться автоматически. Мне кажется, через пять лет автоматизация будет везде. Кроме того, если сейчас мы говорим об автоматизации тестирования, мы, как правило, имеем в виду функциональные тесты. Я думаю, что будет стремительно развиваться потребность в нефункциональном тестировании. Это производительность, секьюрити и не только. В наш мир приходит интернет вещей, и машинам придется еще больше общаться с машинами».

Денис Клыков, инженер по нагрузочному тестированию. Тема доклада – «Visualization, storage and comparison results of performance testing by using Grafana and InfluxDB».

«Я верю, что сферу нагрузочного тестирования ждет большое будущее. В последние пять лет стало больше проектов, где заказчики уделяют много внимания нефункциональным требованиям к ПО. Бизнес начинает понимать, что скорость и другие характеристики производительности IT-систем важны для увеличения прибыли и привлечения инвестиций. Если раньше услуги нагрузочного тестирования пользовались спросом только у финансовых, телекоммуникационных компаний и интернет-гигантов, сейчас они востребованы ритейлом, мультимедиа, нефтегазовым сектором. А значит, и специалисты по нагрузочному тестированию будут все больше нужны рынку».
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330904/


Метки:  

Юмор для IT-специалистов

Среда, 14 Июня 2017 г. 17:06 + в цитатник
Привет, Хабр!
Мы подумали, что если среда — это маленькая пятница, значит можно немножко расслабиться. Поэтому мы подготовили несколько юмористических комиксов от Даниэля Стори (Daniel Stori). Желаем приятного просмотра.

Arduino-проект


Хайп Detected

«Скоро все будут использовать Docker»

Миграция в Облако (иногда бывают сложности)


TCP-приятели

Если вы случайно зашли на Хабр: TCP (Wikipedia) и список наиболее часто используемых сокращений в IT

Bash на Windows


Я обожаю Windows PowerShell


SQL Server на Linux


Дом Линуса Торвальдса


Вы когда-нибудь задумывались над тем, как выглядит дом Линуса Торвальдса? Даниэль Стори приоткрывает нам «окно» в скромный образ жизни знаменитого создателя Linux.


Сказки о DOS

Если вы молоды, то, возможно, не знаете о Дискетах 5 1/4 и игре Test Drive

Тестирование программного обеспечения


Продвинутые биологические виды


Разработчики


Автор немного сгущает краски, говоря о Cobol, но доля правды, конечно, присутствует.

Большие числа


Ловкий трюк для менеджеров по продаже SSL-сертификатов

Если вы не используете SSL, вы не можете быть уверены, что любая конфиденциальная информация, передаваемая на вашем сайте, не будет использована хакерами. Немножко о Kali Linux

Codeless-разработчик или опережая тренды


Реактивное программирование


Когда навыки уже не такие ценные


Когда нанял «неправильного» архитектора

О LAMP

Как объяснить программисту, что вы расстаётесь и всё кончено


Как я встретил вашу маму


Как программист решает, что пора завести ребёнка


Как объяснить, что принтеры не твоя «стихия»
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330896/


[Из песочницы] Современный CMake: 10 советов по улучшению скриптов сборки

Среда, 14 Июня 2017 г. 16:57 + в цитатник

CMake — это система сборки для C/C++, которая с каждым годом становится всё популярнее. Он практически стал решением по умолчанию для новых проектов. Однако, множество примеров выполнения какой-либо задачи на CMake содержат архаичные, ненадёжные, раздутые действия. Мы выясним, как писать скрипты сборки на CMake лаконичнее.


Если вы хотите опробовать советы в деле, возьмите пример на github и исследуйте его по мере чтения статьи: https://github.com/sergey-shambir/modern-cmake-sample

Совет №1: указывайте высокую минимальную версию CMake


Совет не относится к тем, кто пишет публичные библиотеки, поскольку для них важна совместимость со старым окружением разработки. А если вы пишете проект с закрытым кодом либо узкоспециальное опенсорсное ПО, то можно потребовать от всех разработчиков поставить последнюю версию CMake. Без этого многие советы статьи работать не будут! На момент написания статьи мы имеем CMake 3.8.


cmake_minimum_required(VERSION 3.8 FATAL_ERROR)

Совет №2: не вызывайте ни make, ни make install


Современный CMake умеет сам вызывать систему сборки. В документации CMake такой режим называется Build Tool Mode.


# Переходим из каталога myproj в myproj-build
mkdir ../myproj-build && cd ../myproj-build

# Конфигурируем для сборки из исходников в ../myproj
cmake -DCMAKE_BUILD_TYPE=Release ../myproj

# Запускаем сборку в текущем каталоге
cmake --build .

# Запускаем сборку, передаём ключ '-j4' низлежащей системе сборки.
cmake --build . -- -j4

Если вы генерируете проект Visual Studio, вы также можете собрать его из командной строки, в том числе можно собрать конкретный проект в конкретной конфигурации:


cmake --build . \
    --target myapp \
    --config Release \
    --clean-first

На Linux не используйте make install, иначе вы засорите свою систему. Об этом есть отдельная статья Хочется взять и расстрелять, или ликбез о том, почему не стоит использовать make install

Совет №3: используйте несколько CMakeLists.txt


Вложенность CMakeLists.txt — это нормально. Если ваш проект разделён на 3 библиотеки, 3 набора тестов и 2 приложения, то почему бы не добавить CMakeLists.txt для каждого из них? Тогда вам потребуется создать ещё один центральный CMakeLists.txt, и в нём выполнить add_subdirectory. Так может выглядеть центральный CMakeLists:


cmake_minimum_required(VERSION 3.8 FATAL_ERROR)

project(opengl-samples)

# Лайфхак: объявленные в старшем CMakeLists функции
#  будут видны в подпроектах, включённых через add_subdirectory
include(scripts/functions.cmake)

add_subdirectory(libs/libmath)
add_subdirectory(libs/libplatform)
add_subdirectory(libs/libshade)

# Инструкция enable_testing неявно объявляет опцию BUILD_TESTING,
#  по умолчанию BUILD_TESTING=ON.
# Вызывайте `cmake -DBUILD_TESTING=OFF projectdir` из командной строки,
#  если не хотите собирать тесты.
enable_testing()

if(BUILD_TESTING)
    add_subdirectory(tests)
endif()

# ..остальные цели..

Совет №4: не засоряйте глобальную область видимости


Не заводите глобальных переменных без крайней необходимости. Не используйте link_directories(), include_directories(), add_definitions(), add_compile_options() и другие подобные инструкции.


  • Используйте target_link_libraries для добавления статических и динамических, внутренних и внешних библиотек, от которых зависит цель
  • Используйте target_include_directories вместо include_directories для добавления путей поиска заголовков, от которых зависит цель
  • Используйте target_compile_definitions вместо add_definitions для добавления макросов, с которыми собирается цель
  • Используйте target_compile_options для добавления специфичных флагов компилятора, с которыми собирается цель

# Добавляем цель-библиотеку
add_library(mylibrary \
    ColorDialog.h ColorDialog.cpp \
    ColorPanel.h ColorPanel.cpp)

# ! Осторожно - непереносимый код !
# Добавляем к цели путь поиска заголовков /usr/include/wx-3.0
# Лучше использовать find_package для получения пути к заголовкам.
target_include_directories(mylibrary /usr/include/wx-3.0)

Стоит заметить, что target_link_libraries может добавить пути поиска заголовков библиотеки, если библиотека находится в вашем проекте и к ней были прикреплены пути поиска заголовков через конструкцию target_include_directories(libfoo PUBLIC ...).

Есть пример схемы зависимостей, взятый из презентации Modern CMake / an Introduction за авторством Tobias Becker:


Схема


Совет №5: включите, наконец, C++17 или C++14!


В последние годы стандарт C++ обновляется часто: мы получили потрясающие изменения в C++11, C++14, C++17. Старайтесь по возможности отказаться от старых компиляторов. Например, для Linux ничто не мешает установить последнюю версию Clang и libc++ и начать собирать все проекты со статической компоновкой C++ runtime.


Лучший способ включить C++17 без игры с флагами компиляции — явно сказать CMake, что он вам нужен.


# Способ первый: затребовать от компилятора фичу cxx_std_17
target_compile_features(${TARGET} PUBLIC cxx_std_17)

# Способ второй: указать компилятору на стандарт
set_target_properties(${TARGET} PROPERTIES
    CXX_STANDARD 17
    CXX_STANDARD_REQUIRED YES
    CXX_EXTENSIONS NO
)

С помощью target_compile_features вы можете требовать не C++17 или C++14, а определённых фич со стороны компилятора. Полный список известных CMake фич компиляторов можно посмотреть в документации.


Совет №6: используйте функции


В CMake можно объявлять свои функциональные макросы и свои функции. Есть лишь одно различие между ними: переменные, установленные внутри функции, являются локальными.


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


  • CMake 3.8 ещё не умеет передавать Visual Studio флаг /std:c++latest для включения C++17
  • при использовании std::experimental::filesystem в Clang/libc++ нужно указать компоновщику, что проект надо линковать с libc++experimental.a, поскольку в libc++.a модуля filesystem пока ещё нет; также нужно линковать с pthread, поскольку реализация thread/mutex и т.п. опирается на pthread

# В текущей версии CMake не может включить режим C++17 в некоторых компиляторах.
# Функция использует обходной манёвр.
function(custom_enable_cxx17 TARGET)
    # Включаем C++17 везде, где CMake может.
    target_compile_features(${TARGET} PUBLIC cxx_std_17)
    # Включаем режим C++latest в Visual Studio
    if (CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
        set_target_properties(${TARGET} PROPERTIES COMPILE_FLAGS "/std:c++latest")
    # Включаем компоновку с libc++, libc++experimental и pthread для Clang
    elseif (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
        set_target_properties(${TARGET} PROPERTIES COMPILE_FLAGS "-stdlib=libc++ -pthread")
        target_link_libraries(${TARGET} c++experimental pthread)
    endif()
endfunction(custom_enable_cxx17)

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


В крупных открытых проектах, например в KDE, применение своих функций может быть дурным тоном. Вы можете рассмотреть иные варианты: писать скрипт сборки явно по принципу "Explicit is better then implicit", либо даже предложить добавить свою функцию в upstream проекта CMake.

Совет №7 (спорный): не перечисляйте исходные файлы по одному


Мой коллега разрабатывает вне работы маленький 3D движок для рендеринга сцены с моделями и анимациями через OpenGL, GLES, DirectX и Vulkan. Однажды мы с ним обсуждали этот проект, и оказалось, что для сборки под все платформы (Windows, Linux, Android) он использует Visual Studio! Он недоволен тем, что Microsoft редко обновляет Android NDK, но не хочет отказываться от сборки через MSBuild по одной простой причине.


Ему не хочется сопровождать список файлов для сборки в двух системах сборки.


Когда-то я вёл портирование игры с iOS на Android, и мы поддерживали две системы сборки с помощью скрипта, который читал проект XCode и автоматически дополнял список файлов в Android.mk. Если вы используете CMake, то вам даже скрипт не нужно писать.


В CMake есть функция aux_source_directory, но она имеет недостаток: заголовки не добавляются в список и не появляются в любом сгенерированном проекте для IDE.


  • на выручку приходит file(GLOB ...), сканирующий файлы по маске
  • чтобы не замусорить новыми переменными глобальную область видимости, создадим функцию custom_add_executable_from_dir(name)
  • чтобы функция, размещённая в отдельном файле, использовала как точку отсчёта путь к текущему CMakeLists.txt, мы применим переменнуюCMAKE_CURRENT_SOURCE_DIR

function(custom_add_executable_from_dir TARGET)
    # Собираем файлы с текущего каталога
    file(GLOB TARGET_SRC "CMAKE_CURRENT_SOURCE_DIR/*.cpp" 
    # Добавляем исполняемый файл
    add_executable(${TARGET} ${TARGET_SRC})
endfunction()

Вы можете добавить функцию custom_add_library_from_dir для целей-библиотек аналогичным путём.


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


add_library(libfoo Foo.h Foo_common.cpp)
if(WIN32)
    target_sources(libfoo Foo_win32.cpp)
endif(WIN32)

Совет №8: не запускайте утилиты bash, запускайте cmake -E


Наверняка вам хотелось ради автоматизации вызвать из cmake команду Bash, чтобы создать каталог, распаковать архив или подсчитать md5 сумму. Но вызов утилит командной строки может лишить проект кроссплатформенности. Более переносимый метод — вызывать cmake -E команда, пользуясь Command-Line Tool Mode.


Совет №9: оставляйте больше гибкости пользователям своих библиотек


Совет относится к вам, если вы пишете публично доступные библиотеки. В этом случае вам стоит упрощать следующие сценарии:


  • программист хочет добавить вашу библиотеку как подмодуль и включить ваш CMakeLists.txt через add_subdirectory
  • программист хочет сделать кастомизации в сборке вашей библиотеки; наиболее популярные — полностью статическая или динамическая компоновка, сборка с тестами и примерами либо только библиотеки

Добавляя библиотеку, создавайте ещё и уникальный синоним:


# Добавляем цель-библиотеку
add_library(foo ${FOO_SRC})

# Добавляем синоним, содержащий имя выпускающей библиотеку организации
add_library(MyOrg::foo ALIAS foo)

Оставляйте пользователям библиотеки право использования опции BUILD_SHARED_LIBS для выбора между сборкой статической и динамической версий библиотеки.


При установке настроек компоновки, поиска заголовков и флагов компиляции для библиотек используйте ключевые слова PUBLIC, PRIVATE, INTERFACE, чтобы позволить целям, зависящим от вашей библиотеки, наследовать необходимые настройки:


  • PUBLIC означает, что зависящему от библиотеки проекту тоже нужны эти опции
  • PRIVATE означает, что опции нужны лишь для сборки библиотеки
  • INTERFACE означает, что опции не нужны для сборки, но нужны для использования библиотеки

target_link_libraries(foobarapp
    PUBLIC MyOrg::libfoo
    PRIVATE MyOrg::libbar
)

Совет №10: регистрируйте автотесты в CTest


Подсистема CTest не заставляет вас использовать какие-то особые библиотеки для тестирования вместо привычных Boost.Test, Catch или Google Tests. Она всего лишь регистрирует автотесты так, чтобы CMake мог запустить все тесты или выбранные тесты одной командой ctest.


Чтобы включить поддержку CTest по всему проекту, есть инструкция enable_testing


# Инструкция enable_testing неявно объявляет опцию BUILD_TESTING,
#  по умолчанию BUILD_TESTING=ON.
# Вызывайте `cmake -DBUILD_TESTING=OFF projectdir` из командной строки,
#  если не хотите собирать тесты.
enable_testing()

if(BUILD_TESTING)
    add_subdirectory(tests/libhellotest)
    add_subdirectory(tests/libgoodbyetest)
endif()

Чтобы исполняемый файл с тестом был зарегистирован в CTest, нужно вызвать инструкцию add_test.


# Исполняемый файл теста - это обычная исполняемая цель сборки
add_executable(${TARGET} ${TARGET_SRC})

# Регистрируем исполняемый файл в CMake как набор тестов.
#  можно назначить тесту особое имя, но проще использовать имя исполняемого файла теста.
add_test(${TARGET} ${TARGET})

Что ещё почитать?


Перед созданием статьи были прочитаны, опробованы и переосмыслены несколько англоязычных источников:



Некоторые советы из этих источников никак не отражены в статье. Поэтому после их прочтения вы определённо станете глубже разбираться в CMake.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330902/


Метки:  

[Перевод статьи] Лучшие IT-конференции для участия в Июне — Августе 2017

Среда, 14 Июня 2017 г. 16:38 + в цитатник
image

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

Если вы хотите обменяться личным опытом с коллегами, представить свои идеи ИТ-сообществу и/или получить финансирование, то этот список лучших IT-конференций для участия в 2017 году идеально подходит для вас.

Июнь 2017 г.



Apps World


Дата: 13 — 15 июня
Расположение: ExCeL, Лондон, Великобритания
Цена: lb 299 (без НДС)
Веб-сайт: tmt.knect365.com/apps-world/?_ga=2.137831033.810654168.1495789253-1085437954.1491224898

Почему стоит поучаствовать?
Apps World проводится в рамках нового фестиваля технологий Tech Tech Technology Technology TechXLR8, демонстрирующего сдвиг парадигмы в индустрии цифровых услуг. AW 2017 объединяет бренды, разработчики и предприятия, которые внедряют инновационные решения в многоплатформенной экосистеме, и заинтересованы в развитии технологии персональных ассистентов и чатботах, помогающих которые помогают максимально повысить точность и эффективность взаимодействия с потребителями.

Ключевые спикеры
  • Дэвид Лоу, главный евангелист в Amazon Alexa EU
  • Джеймс МакКлюр, GM Северная Европа в AirBnB


Cписок докладчиков: techxlr82017.mapyourshow.com/7_0/customlist.cfm?list=speakersbyeventtype&eventtype=0

Viva Technology Paris


Дата: 15 — 17 июня
Расположение: Париж, Франция
Цена: 120 евро — 245 евро (без НДС).
Веб-сайт: vivatechnology.com

Почему стоит поучаствовать?
VivaTech является центром инноваций в мире, любителей технологий и пионеров будущего. Он существует для создания отношений, которые изменят будущее бизнеса. В этом году Viva Tech соберет более 200 спикеров и 1000 стартапов.

Ключевые спикеры:
  • Эрик Шмидт, ИСПОЛНИТЕЛЬНЫЙ ПРЕДСЕДАТЕЛЬ в ALPHABET
  • Даниэль Чжан, генеральный директор ALIBABA GROUP


Cписок докладчиков: vivatechnology.com/speakers

Партнеры: Google, Orange, BNP Paribas, Sanofi.

Июль 2017 г.



Inspirefest


Дата: 7-9 июля
Расположение: Dublin, Ireland
Цена: € 150
Веб-сайт: inspirefest.com
Почему стоит поучаствовать?
Inspirefest — это уникальный международный фестиваль технологий, науки, дизайна и искусства, охватывающий ключевые направления от Infosec до Blockchain, от AI до робототехники и игр до профессионального развития.

Ключевые спикеры:
  • Эллен Пао, венчурный партнер компании Kapor Capital
  • Раджу Нарисетти, генеральный директор GIZMODO MEDIA GROUP


Список докладчиков: inspirefest.com

Партнеры: Intel, Facebook, Dropbox, Nokia Bell Labs, AdRoll

AnDevCon


Дата: 17-19 июля
Расположение: Washington D.C., USA
Цена: $ 895 (3-дневный билет)
Веб-сайт: www.andevcon.com/dc2017

Почему стоит поучаствовать?
Это одино из самых больших событий, связанных с Android.

Ключевые спикеры:
  • Викрам Бодичерла, старший инженер-менеджер по финансам Yahoo
  • Дэвид Кирпич, разработчик Android в Yelp


Список докладчиков: www.andevcon.com/dc2017/speakers

Партнеры: Clutch, DC Android, Android Tech News, журнал Linux.

Black Hat USA


Дата: 22 — 27 июля
Расположение: Нью-Йорк, NY, США
Цена: $ 2095 — $ 2795
Веб-сайт: www.blackhat.com/us-17

Почему стоит поучаствовать?
Black Hat является ведущим в мире событием по информационной безопасности, предоставляя посетителям самые последние исследования и разработки для ознакомления. Если вы хотите знать, как защитить личные и финансовые данные ваших мобильных приложений, нет другого выбора, кроме как забронировать рейс в Нью-Йорк и посетить эту конференцию.
Партнеры: Accenture Security, iBoss, CrowdStrike

August 2017



RESPAWN


Дата: 20-21 августа
Расположение: Кельн, Германия
Цены: € 169
Веб-сайт: www.respawngathering.com

Почему вы должны присутствовать?
Respawn — крупнейшая августовская конференция разработчиков игр в Центральной Европе. Более 1500 человек специализируются на мобильных, веб-, игровых и игровых играх. Темы конференции варьируются от разработки игр, разработки и тестирования до развития бизнеса и игрового промо.

Партнеры: Gamebusiness.de, Devcom

Топ-10 вещей, которые необходимо взять с собой на каждую конференцию, которую вы посещаете



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

1) Визитные карточки,
2) Брєндовые материалы (ролл-ап, стэнд и т.п.)
3) Сувенирная продукция,
4) Раздаточные материалы,
5) Ноутбук,
6) Портативное зарядное устройство,
7) 30-секундное представление вашей компании,
8) Список открытых вопросов для разговора с потенциальными клиентами,
9) Список участников,
10) План общения после конференции.

Источник >>>
Был ли вам полезен данный материал:

Никто ещё не голосовал. Воздержавшихся нет.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330894/


Метки:  

GeekUniversity открывает набор студентов на факультет Java-разработки

Среда, 14 Июня 2017 г. 16:30 + в цитатник


В нашем онлайн-университете для программистов открылся новый факультет. Теперь в GeekUniversity студенты смогут освоить Java-разработку на Middle-уровне и гарантированно начать карьеру сразу после обучения.

GeekUniversity — совместный образовательный проект Mail.Ru Group и IT-портала GeekBrains. Программу обучения и спецкурсы для факультета разрабатывают Avito, Альфа-банк, МТС, Тинькофф, DeliveryClub.

За время обучения студенты создают 2 самостоятельных и 2 командных проекта: сетевой чат, игра для мобильных устройств на Android, облачное хранилище данных, сайт электронной коммерции. Прогресс будет курировать наставник. После обучения выпускники умеют:

  • программировать на Java и Java Enterprise Edition;
  • создавать веб-приложения с использованием Spring Framework;
  • верстать на HTML, CSS и работать с Bootstrap;
  • использовать принципы ООП и паттерны проектирования;
  • работать с GIT;
  • проектировать архитектуру;
  • использовать шаблоны проектирования и принципы SOLID;
  • следовать code style.




Год обучения в GeekUniversity — год реального опыта Java-разработки для резюме и 4 проекта для портфолио. Выпускникам гарантируется дальнейшее трудоустройство в компаниях-партнёрах. Обучение длится год, занятия проходят 3-4 раза в неделю в вечернее время.

GeekUniversity обучает студентов на основании государственной лицензии № 038188. Выпускники получают свидетельство установленного образца и именной электронный сертификат портала GeekBrains и компании Mail.Ru Group.

Всем абитурентам предлагаем пройти тестирование по теории Java. Если тест не пройден, рекомендуем подготовительные курсы, где вы научитесь базовым конструкциям языка и основам ООП. Обучение на факультете подойдёт тем, у кого есть начальные знания программирования.

Оставить заявку и получить подробную консультацию можно здесь.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330890/


Метки:  

Найдена новая уязвимость в Intel AMT, связанная с режимом Serial-over-LAN

Среда, 14 Июня 2017 г. 16:17 + в цитатник
Исследователям из компании Microsoft удалось обнаружить вредоносное программное обеспечение, использующее в качестве «моста» для передачи информации Intel Serial-over-LAN (SOL), являющуюся частью инструментария Active Management Technology (AMT). Технология SOL работает таким образом, что трафик поступает в обход сетевого стека локального компьютера, поэтому его «не видят» и не блокируют файерволы и антивирусное ПО. Это позволяет беспрепятственно извлекать данные с зараженных хостов.

/ фото Andi Weiland CC

В начале года компания Intel уже сталкивалась с опасными уязвимостями в составе Intel ME. Тогда проблема затрагивала решения Intel Active Management Technology (AMT), Intel Standard Manageability (ISM), Intel Small Business Technology (SBT) и позволяла непривилегированному злоумышленнику получить удаленный доступ к управлению оборудованием. Уязвимость, получившую обозначение CVE-2017-5689, разработчики ИТ-гиганта пропатчили.

И вот была обнаружена новая уязвимость, связанная с Intel Serial-over-LAN. AMT SOL является частью Intel Management Engine (ME) — отдельного процессора, встраиваемого в CPU Intel, который работает под управлением собственной операционной системы. Технология была внедрена с целью упростить работу системных администраторов в крупных компаниях, управляющих сетями с большим числом станций.

Поскольку интерфейс AMT SOL функционирует внутри Intel ME, он отделен от основной операционной системы — то есть той среды, где запущены файерволы и антивирусное ПО. Более того, AMT SOL работает даже тогда, когда компьютер выключен, но по-прежнему физически подключён к сети — это позволяет транслировать данные по протоколу TCP, что открывает определенные возможности для злоумышленников.

Компоненты AMT SOL (Источник)

Функции AMT SOL по умолчанию отключены и активировать их может только системный администратор, что снижает уровень риска. Однако в крупных компаниях SOL часто используется по назначению. Сыграв на особенностях решения, группа хакеров написала вредоносный код, позволяющий красть данные через SOL.

Эксперты Microsoft утверждают, что за вредоносным ПО, использующим SOL для кражи данных, стоит группировка Platinum, которая уже несколько лет ведет активную деятельность на территории Южной и Юго-Восточной Азии. Впервые группа была замечена в 2009 году и с тех пор провела множество атак. В прошлом году сообщалось, что Platinum занимались установкой вредоносного ПО с помощью технологии «хотпатчинга» (hotpatching) — механизма, позволяющего Microsoft устанавливать обновления без необходимости перезагрузки компьютера.

SOL-протокол, реализуемый в инструменте Platinum, использует Redirection Library API (imrsdk.dll). Передача информации осуществляется с помощью вызовов IMR_SOLSendText() и IMR_SOLReceiveText(), которые являются аналогами send() и recv(). Используемый протокол идентичен протоколу TCP, за исключением добавленного заголовка изменяемой длины для отслеживания ошибок при передаче данных (CRC-16 и др.). В этом видео показано, как используется инструмент Platinum для отправки вредоносного ПО в систему.

Стоит отметить, что возможность такой атаки обсуждалась и раньше, однако до сих пор не было попыток использовать Intel AMT SOL для вывода данных.

«Это типичный пример того, как технология, призванная упрощать жизнь пользователям или системным администраторам, превращается в фактическую уязвимость, — отмечает Ксения Шилак, директор по продажам компании SEC-Consult. — И это, на самом деле, скверная новость: если бы использовалась какая-то уязвимость, ее можно было бы исправить. А в данном случае имеет место использование архитектурной особенности».

P.S. Другие материалы по теме из нашего блога:

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330572/


Метки:  

SQL Server Integration Services (SSIS) для начинающих – часть 3

Среда, 14 Июня 2017 г. 16:01 + в цитатник

-> Часть 1
-> Часть 2

В этой части я расскажу о работе с параметрами и переменными внутри SSIS-пакета. Узнаем, как можно задавать и отслеживать значения переменных во время выполнения пакета.

Также рассмотрим вызов одного пакета из другого при помощи «Execute Package Task» и некоторые дополнительные компоненты и решения.

Здесь тоже будет много картинок.

Продолжим знакомство с SSIS


Создадим в трех демонстрационных базах новую таблицу ProductResidues, которая будет содержать информацию об остатках на каждый день:
USE DemoSSIS_SourceA
GO

CREATE TABLE ProductResidues(
  ResidueDate date NOT NULL,
  ProductID int NOT NULL,
  ResidueAmount decimal(10,2) NOT NULL,
CONSTRAINT PK_ProductResidues PRIMARY KEY(ResidueDate,ProductID),
CONSTRAINT FK_ProductResidues_ProductID FOREIGN KEY(ProductID) REFERENCES Products(ID)
)
GO

USE DemoSSIS_SourceB
GO

CREATE TABLE ProductResidues(
  ResidueDate date NOT NULL,
  ProductID int NOT NULL,
  ResidueAmount decimal(10,2) NOT NULL,
CONSTRAINT PK_ProductResidues PRIMARY KEY(ResidueDate,ProductID),
CONSTRAINT FK_ProductResidues_ProductID FOREIGN KEY(ProductID) REFERENCES Products(ID)
)
GO

USE DemoSSIS_Target
GO

CREATE TABLE ProductResidues(
  ResidueDate date NOT NULL,
  ProductID int NOT NULL,
  ResidueAmount decimal(10,2) NOT NULL,
CONSTRAINT PK_ProductResidues PRIMARY KEY(ResidueDate,ProductID),
CONSTRAINT FK_ProductResidues_ProductID FOREIGN KEY(ProductID) REFERENCES Products(ID)
)
GO

И наполним таблицы в источниках тестовыми данными, поочередно выполнив на базах DemoSSIS_SourceA и DemoSSIS_SourceB следующий скрипт:
USE DemoSSIS_SourceA
--USE DemoSSIS_SourceB
GO

DECLARE @MinDate date=DATEADD(MONTH,-2,GETDATE())
DECLARE @MaxDate date=GETDATE()

;WITH dayCTE AS(
  SELECT CAST(@MinDate AS date) ResidueDate,10000 ResidueAmount

  UNION ALL

  SELECT DATEADD(DAY,1,ResidueDate),ResidueAmount-1
  FROM dayCTE
  WHERE ResidueDate<@MaxDate
)
INSERT ProductResidues(ResidueDate,ProductID,ResidueAmount)
SELECT
  d.ResidueDate,
  p.ID,
  d.ResidueAmount
FROM dayCTE d
CROSS JOIN Products p
OPTION(MAXRECURSION 0)

Допустим, что в таблице ProductResidues будет очень много строк, и чтобы каждый раз не перезагружать всю информацию и упростить процедуру интеграции, логику загрузки в таблицу ProductResidues в базе DemoSSIS_Target реализуем следующую:
  1. Если в принимающей БД еще нет записей, то загрузим все данные;
  2. Если в принимающей БД есть данные, то будем удалять данные за неделю (последние 7 дней) от последней загруженной даты и загружать данные из источника начиная от этой даты снова.

Неудобство интеграции таблиц типа ProductResidues в том, что в ней нет полей, по которым можно было бы однозначно определить, когда появилась запись, в ней нет никакого идентификатора типа ID, нет ни поля типа UpdatedOn, которое содержало бы дату/время последнего обновления записи (т.е. зацепиться особо не за что), иначе бы мы, например, могли вычислить для каждого источника, по данным базы DemoSSIS_Target, последний ID или последнюю UpdatedOn и уже загружать данные из источников начиная от этих стартовых значений. К тому же не всегда есть возможность внести изменения в структуру источников, подстроив их под себя, т.к. это могут быть вообще чужие базы, к которым у нас нет полного доступа.

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

Создадим новый SSIS-пакет и назовем его «LoadResidues.dtsx».

При помощи контекстного меню, отобразим область ввода переменных пакета (это можно сделать также при помощи меню «SSIS -> Variables»):


В данном пакете, нажав на кнопку «Add Variable», создадим переменную LoadFromDate типа DateTime:

По умолчанию переменной присваивается текущее значение даты/времени, т.к. мы будем переопределять значение внутри пакета, нам это не важно.
Так же стоит обратить внимание на Expression – если прописать в этом поле выражение, то переменная будет работать как формула и мы не сможем изменять ее значение при помощи присваивания. При каждом обращении к такой переменной ее значение будет рассчитываться согласно указанному выражению.

Значения переменных можно задавать при помощи компонента «Expression Task». Давайте рассмотрим, как это делается. Создадим элемент «Expression Task»:


Двойным щелчком откроем редактор данного элемента:

Пропишем следующее выражение:
@[User::LoadFromDate] = (DT_DATE) (DT_DBDATE) GETDATE()

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

Давайте так же посмотрим как можно отследить значение переменной во время выполнения пакета.
Создадим точку останова на элементе «Expression Task»:


Укажем, что точка должна срабатывать по окончанию выполнения данного блока:


Запустим пакет на выполнение (F5) и после остановке в нашей точке, перейдем на вкладку «Locals»:


Раскроем список Variables и найдем в нем свою переменную:


Для интереса можем поменять выражение элементе «Expression Task» на следующее:
@[User::LoadFromDate] = (DT_DATE) (DT_DBDATE) DATEADD("DAY", -7, GETDATE())
и также поэкспериментировать:


Точку останова убирается таким же образом каким и была установлена. Либо можно удалить сразу все точки останова, если их было несколько:


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


Так и локальный, внутри конкретного пакета:


Параметр может быть обязательный для задания – за это отвечает флаг Required. Если этот флаг установлен, то при создании задачи или при вызове пакета из другого пакета нужно будет определить входящее значение параметра (мы рассмотрим это далее).
В отличие от переменных значение параметров при помощи «Expression Task» менять нельзя.

Сохраним параметры и снова зайдем в редактор «Expression Task»:

Для примера я поменял выражение на следующее:
@[User::LoadFromDate] = (DT_DATE) (DT_DBDATE) DATEADD("DAY", - @[$Package::DateOffset] , GETDATE())

Думаю, на этом суть параметров и переменных ясна, и мы можем продолжить.

После того как мы поигрались с «Expression Task» мы его удалим.

Создадим «Execute SQL Task»:


Настроим его следующим образом:


Пропишем в SQLStatement следующий запрос:
SELECT ISNULL(DATEADD(DAY,-?,MAX(ResidueDate)),'19000101') FromDate
FROM ProductResidues

Т.к. данный запрос возвращает одну строку, установим ResultSet = «Single Row» и ниже на вкладке «Result Set» сохраним результат в значение переменной LoadFromDate.

На вкладке «Parameter Mapping» зададим значения параметров, которые в запросе обозначены знаком вопроса (?):

Параметры нумеруются, начиная с нуля.
Стоит отметить, что если при создании соединения воспользоваться другим видом провайдера, например, «ADO» или «ADO.Net», то вместо вопросов мы сможем использовать именованные параметры типа @ParamName и в качестве «Parameter Name» тоже могли бы указывать @ParamName, а не его номер. Но увы типом соединения с другим провайдером мы сможем воспользоваться не во всех случаях.

Теперь на вкладке «Result Set» укажем в какую переменную нужно записать результат выполнения запроса:


Здесь так же можем продебажить установив у этого компонента точку останова на «Break when the container receives the OnPostExecute event» и запустив пакет на выполнение:

Здесь я для удобства мониторинга значения переменной прописал название переменной в «Watch», чтобы не искать ее в блоке «Locals».

Как видим все верно в переменную LoadFromDate записалась дата «01.01.1900», т.к. строк в таблице ProductResidues на Target еще нет.

Переименую для наглядности «Execute SQL Task» в «Set LoadFromDate».

Создадим еще один элемент «Execute SQL Task» и назовем его «Delete Old Rows»:


Настроим его следующим образом:

SQLStatement содержит следующий запрос:
DELETE ProductResidues
WHERE ResidueDate>=?

И зададим значение параметра на вкладке «Parameters Mapping»:


Все, удаление старых данных за указанный конечный период у нас реализовано.

Теперь сделаем часть отвечающую загрузку свежих данных. Для этого воспользуемся компонентом «Data Flow Task»:


Зайдем в область данного компонента и создадим «Source Assistant»:


Настроим его следующим образом:


Нажав на кнопку «Parameters…» зададим значение параметра:


Для записи новых данных воспользуемся уже знакомым компонентом «Destination Assistant»:


Протянем стрелку от «Source Assistant» и настроим его:






Все, пакет для переноса данных с источника SourceA у нас готов, можем запустить его на выполнение:


Запустим еще раз:


Как видим при повторном запуске удалились и залились только данные за указанный период. Ну вроде все работает так как мы и хотели. На всякий случай сверимся, что данные получателя по количеству равны данным источника:


Дойдя до сюда, я понял, что я допустил ошибку. Кто понял в чем дело, молодец!

Но может это и хорошо, т.к. пример получился не таким перегруженным.

Ошибка в том, что я забыл учесть, что при интеграции данных таблицы Products у нас в Target формируются свои идентификаторы (поле ID с флагом IDENTITY)!

Давайте переделаем, чтобы все было правильно. Ничего страшного повторим, зато лучше запомним.

Забежим чуть вперед и добавим в пакет еще один параметр, который назовем «SourceID»:


Перенастроим «Set LoadFromDate»:


В SQLStatement пропишем новый запрос с учетом SourceID:
SELECT ISNULL(DATEADD(DAY,-?,MAX(res.ResidueDate)),'19000101') FromDate
FROM ProductResidues res
JOIN Products prod ON res.ProductID=prod.ID
WHERE prod.SourceID=?

Настроим второй параметр:


Теперь перенастроим «Delete Old Rows» аналогичным образом, чтобы учитывался SourceID:


В SQLStatement пропишем новый запрос с учетов SourceID:
DELETE res
FROM ProductResidues res
JOIN Products prod ON res.ProductID=prod.ID
WHERE ResidueDate>=?
  AND prod.SourceID=?

Настроим второй параметр:


Теперь зайдем в «Data Flow Task», удалим цепочку и добавим «Derived Column»:


Настроим его следующим образом:


Здесь я намеренно оставил тип «Unicode string», а не сделал преобразование как в первой части. Давайте за одно рассмотрим компонент «Data Conversion»:


Настроим его:


Теперь при помощи Lookup сделаем сопоставление и получим нужные нам идентификаторы продуктов:


Настроим его:






Теперь протянем синюю стрелку от Lookup к «OLE DB Destination»:


Выберем поток «Lookup Match Output»:


Настроим «OLE DB Destination», нужно перестроить Mappings:


Все, сделаем очистку таблицы от неправильно загруженных данных:
TRUNCATE TABLE DemoSSIS_Target.dbo.ProductResidues

И запустим пакет на выполнение:


И еще раз:

Похоже на правду. Можете самостоятельно проверить правильно ли разнеслись идентификаторы продуктов.

Так как структура DemoSSIS_SourceA и DemoSSIS_SourceB одинакова и нам нужно сделать для DemoSSIS_SourceB, то же самое, то мы можем при создании задачи создать два шага для пакета «LoadResidues.dtsx», в первом шаге настроить подключение к базе DemoSSIS_SourceA, а на втором шаге DemoSSIS_SourceB.

Откомпилируем и передеплоим SSIS проект:






Давайте теперь создадим новое задание в SQL Agent:


На вкладке Steps создадим шаг 1 для загрузки продуктов:


Создадим шаг 2 для загрузки остатков из SourceA:


На вкладке Configuration можем увидеть наши параметры:


Здесь от нас требуют ввести SourceID, т.к. мы указали его как Required. Зададим его:

Данные вкладки «Connection Managers» изменять для этого шаге не будем.

Создадим шаг 3 для загрузки остатков из SourceB:


Зададим параметр SourceID:


И изменим данные соединения SourceA таким образом, чтобы оно ссылалось на базу DemoSSIS_SourceB:

В данном случае мне достаточно было изменить ConnectionString и InitialCatalog, теперь они указывают на DemoSSIS_SourceB.

В итоге мы должны получить следующее – три шага:


Запустим эту задачу на выполнение:


Выполним запрос:
USE DemoSSIS_Target
GO

SELECT prod.SourceID,COUNT(*)
FROM ProductResidues res
JOIN Products prod ON res.ProductID=prod.ID
GROUP BY prod.SourceID

И убедимся, что все отработало как надо:


Теперь допустим, что базы DemoSSIS_SourceA и DemoSSIS_SourceB расположены на одном экземпляре SQL Server. Давайте переделаем «OLE DB Source»:



Текст команды:
DECLARE @SourceID char(1)=?

IF(@SourceID='A') USE DemoSSIS_SourceA
ELSE  USE DemoSSIS_SourceB

SELECT
  ResidueDate,
  ProductID,
  ResidueAmount
FROM ProductResidues
WHERE ResidueDate>=?

Зададим параметры:

Теперь наш пакет в зависимости от значения параметра SourceID будет брать данные либо из SourceA, либо из SourceB.

Для теста можете изменить значение параметра SourceB на «B» и запустить проект на выполнение:




Давайте теперь создадим новый пакет «LoadAll.dtsx» и создадим в нем «Execute Package Task» (переименуем его в «Load Products»):


Настроим «Load Products»:


Создадим в новом пакете 2 параметра:


В области «Control Flow» создадим еще 2 компонента «Execute Package Task» которые назовем «Load Resudues A» и «Load Resudues B»:


Настроим их задав у обоих название пакета «LoadResidues.dtsx»:


Зададим обязательный параметр SourceID для «Load Resudues A»:


Зададим обязательный параметр SourceID для «Load Resudues B»:


Обратите внимание, что у стрелок тоже есть свои свойства, например, мы можем поменять свойство Value на Completion, что будет означать, что следующий шаг будет выполнен даже в том случае если на шаге «Load Resudues A» произойдет ошибка:


Все, можем запустить пакет на выполнение:


Думаю, объяснять, что здесь произошло нет смысла.

Иногда параметры для конкретного пакета удобно хранить в вспомогательной таблице и считывать их оттуда в переменные пакета, например, используя для поиска глобальную переменную «System::PackageName». Для демонстрации, давайте переделаем наш пакет таким образом.

Создадим таблицу с параметрами:
USE DemoSSIS_Target
GO

CREATE TABLE IntegrationPackageParams(
  PackageName nvarchar(128) NOT NULL,
  DateOffset int NOT NULL,
CONSTRAINT PK_IntegrationPackageParams PRIMARY KEY(PackageName)
)
GO

INSERT IntegrationPackageParams(PackageName,DateOffset)VALUES
(N'LoadResidues',7)
GO

Удалим параметр DateOffset из пакета «LoadResidues.dtsx»:


Создадим в пакете переменную DateOffset:


В область «Control Flow» добавим еще один элемент «Execute SQL Task» и переименуем его «Load Params»:


Настроим его:


Запрос в SQLStatement пропишем следующий:
SELECT DateOffset
FROM IntegrationPackageParams
WHERE PackageName=?

Настроим параметр запроса используя системную переменную «System::PackageName»:


Осталось сбросить результат выполнения запроса в переменную:


Теперь осталось перенастроить «Set LoadFromDate», чтобы в нем использовалась теперь переменная:




Все, можем тестировать новую версию пакета.

Вот мы и добрались до финиша. Мои поздравления!

Заключение по третьей части


Уважаемые читатели, эта часть будет заключительной.

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

Думаю, освоив это, далее вы уже без особого труда сможете освоить работу с остальными компонентами SSIS. В данных статьях я рассмотрел только самые важные компоненты (наиболее часто применяемые на моей практике), но зная только это вы уже можно сделать очень многое. По мере надобности изучайте самостоятельно другие компоненты, в первую очередь порекомендовал бы посмотреть следующее:
  • компоненты-контейнеры (Sequence Container, For Loop Container, Foreach Loop Container);
  • «Merge Join», который позволяет сделать операции JOIN, LEFT JOIN, FULL JOIN на стороне SSIS (это требует предварительно отсортировать два набора при помощи «Sort»);
  • «Conditional Split», который позволяет разбить один поток на несколько в зависимости от условий;
  • так же рассмотрите вкладку «Event Handlers», которая позволяет создать дополнительные области для определенного вида события пакета.

Доступного материала на эту тему очень много, используйте MSDN, Youtube и прочие источники.

Я не старался сделать подробный учебник (думаю, все это уже есть), а старался сделать такой материал, который позволит начинающим шаг за шагом создать все с самого нуля и делая все своими руками увидеть всю картину в целом, а после уже имея основу идти дальше самостоятельно. Очень надеюсь, что у меня это получилось и материал окажется полезен именно в таком ключе.

Я очень рад, что мне хватило сил осуществить задуманное и описать все так как я это хотел, даже получилось сделать большее, так как из-за допущенной в этой части ошибки возникли неожиданные повороты сюжета, но так я думаю, стало даже интересней. ;)

Спасибо за внимание! Удачи!

И возможно, до встреч в новых статьях…
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330840/


Метки:  

5 возможностей LESS, о которых вы могли не знать

Среда, 14 Июня 2017 г. 15:27 + в цитатник

Метки:  

[Перевод] Коллбэк в JavaScript… Что за зверь?

Среда, 14 Июня 2017 г. 15:26 + в цитатник
Если вы не очень хорошо представляете себе — что такое «коллбэки», и как ими пользоваться в JavaScript, сейчас у вас есть шанс их понять и научиться с ними работать.

image

Перейдём сразу к делу. Коллбэк — это функция, которая должна быть выполнена после того, как другая функция завершит работу. Отсюда и название, которое, в английском написании, может быть представлено как «call back», хотя обычно это — «callback». Среди вариантов перевода этого слова — «обратный вызов». В русскоязычных публикациях, допускающих использование жаргона программистов, весьма распространена калька с оригинального названия: «коллбэк». Если же обойтись без жаргона, то о чём мы говорим, называется «функция обратного вызова».

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

Зачем нужны функции обратного вызова?


Коллбэки нужны по одной очень важной причине: JavaScript — это язык, в котором огромную роль играют события. Это означает, что вместо того, чтобы ожидать, скажем, результата выполнения некоей функции, остановив при этом все остальные операции, JavaScript-программа работает, наблюдая за событиями и реагируя на них.

Взглянем на простой пример:

function first(){
  console.log(1);
}
function second(){
  console.log(2);
}
first();
second();

Как можно ожидать, функция first() выполняется первой, а функция second() второй. Запуск этого кода приводит к тому, что в консоль будет выведено следующее:

// 1
// 2

Пока, надеемся, всё понятно, но что, если функция first() содержит код, который нельзя выполнить немедленно? Например, там есть обращение к некоему API, причём, сначала нужно отправить запрос, а потом дождаться ответа? Для того, чтобы это сымитировать, воспользуемся функцией setTimeout(), которая применяется в JavaScript для вызова других функций с заданной задержкой. Мы собираемся отложить вызов функции на 500 миллисекунд.

Вот что получилось теперь:

function first(){
  // Имитируем задержку
  setTimeout( function(){
    console.log(1);
  }, 500 );
}
function second(){
  console.log(2);
}
first();
second();

Для наших целей особенности работы setTimeout() сейчас неважны. Главное — обратите внимание на то, что вызов console.log(1) будет выполнен с задержкой.

Вот что произойдёт при запуске этого кода:

// 2
// 1

Несмотря на то, что функция first() была вызвана первой, сначала в лог попало то, что выводит функция second().

Это не значит, что JavaScript вызывает функции не в том порядке, в котором мы расположили их вызовы в коде. Смысл в том, что система переходит к исполнению функции second(), не дожидаясь ответа от функции first().

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

Создаём функцию обратного вызова


Создадим собственную функцию обратного вызова.

Для начала — откройте консоль разработчика Chrome (Ctrl + Shift + J в Windows, или Cmd + Option + J в Mac) и введите следующее:

function doHomework(subject) {
  alert(`Starting my ${subject} homework.`);
}

Тут мы объявили функцию doHomework(). Эта функция принимает одну переменную — название предмета, по которому некто делает домашнюю работу. Вызовите функцию, введя в консоли следующее:

doHomework('math');
// Выводит сообщение: Starting my math homework.

Теперь добавим, в качестве второго аргумента функции doHomework(), параметр callback, который будем использовать для того, чтобы передать doHomework() функцию обратного вызова. Теперь код будет выглядеть так:

function doHomework(subject, callback) {
  alert(`Starting my ${subject} homework.`);
  callback();
}

Вызовем обновлённую функцию следующими образом:

doHomework('math', function() {
  alert('Finished my homework');
});

Сначала будет выведено сообщение с текстом Starting my math homework., потом — с текстом Finished my homework.

Функции обратного вызова совсем необязательно создавать непосредственно при вызове функций, которым они передаются. Такую функцию можно объявить и где-нибудь в коде:

function doHomework(subject, callback) {
  alert(`Starting my ${subject} homework.`);
  callback();
}
function alertFinished(){
  alert('Finished my homework');
}
doHomework('math', alertFinished);

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

Как вы можете видеть, тут, в качестве аргумента при вызове функции doHomework(), использовано имя функции alertFinished().

Функции обратного вызова в реальных проектах


Для программного взаимодействия с популярной социальной сетью Twitter используется специальное API. Выполняя обращения к этому API, мы вынуждены ждать ответа, и только после его получения можем выполнять с тем, что придёт от Twitter, какие-то действия. Вот материал, где рассмотрена работа с Twitter API в среде Node.js с использованием NPM-пакета twitter.

Рассмотрим фрагмент кода из этого материала. Полагаем, он является отличной демонстрацией практического применения функций обратного вызова.

T.get('search/tweets', params, function(err, data, response) {
  if(!err){
    // Именно здесь можно работать с тем, что вернёт нам Twitter
  } else {
    console.log(err);
  }
})
T.get()

— это функция, которая выполняет get-запрос к Twitter API. У функции три аргумента. Первый — 'search/tweets', представляет собой маршрут запроса. Здесь мы собираемся выполнить поиск по твитам. Второй аргумент — params — это параметры поиска. Третий аргумент — анонимная функция, которая и является функцией обратного вызова.

Функция обратного вызова здесь весьма важна, так как, прежде чем продолжать работу, нужно дождаться ответа от сервера. Неизвестно, будет ли обращение к API успешным, поэтому, после отправки параметров поиска по маршруту search/tweet с помощью get-запроса, приходится ждать. Как только Twitter ответит на запрос, будет выполнена функция обратного вызова. Если что-то пошло не так, в ней мы получим объект ошибок (err). Если запрос обработан нормально, в аргументе err будет значение, эквивалентное false, а значит, во-первых, будет исполнена ветвь if условного оператора, а во-вторых — можно будет рассчитывать на то, что в объекте response окажутся некие полезные данные, с которыми уже можно что-то делать.

Итоги


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

Уважаемые читатели! Если вы из тех, кто, до чтения этого материала, плохо представлял себе, что такое функции обратного вызова в JS, скажите — стало понятнее? А если коллбэки для вас — обычное дело, просим поделиться опытом с новичками.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330880/


Метки:  

Искусственный интеллект захватывает Уолл-стрит: как это скажется на сфере финансов и не только

Среда, 14 Июня 2017 г. 15:26 + в цитатник


Изображение:R~P~M, CC BY 2.0

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

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

Искусственный интеллект и рекордная доходность инвестиций


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

В марте исследовательская группа из университета Эрлангена-Нюрнберга в Германии разработала ряд алгоритмов, которые использовали архивные данные рынков для тиражирования инвестиций в режиме реального времени.

Одна из моделей позволила добиться 73% возврата инвестиций ежегодно с 1992 по 2015 год с учетом транзакционных издержек. Это сопоставимо с реальной рыночной доходностью в 9% в год. Прибыль была особенно высокой во время рыночных потрясений 2000-го (545% доходности) и 2008-го годов (681% доходности), что доказало повышенную эффективность количественных алгоритмов в периоды высокой волатильности, когда на рынках преобладают эмоции.

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

Идея использования компьютеров для торговли акциями не нова. Ее аналог – алгоритмическая торговля или черные ящики – используется уже более десяти лет и неуклонно набирает популярность. В 2012 году алгоритмическая торговля занимала 85% рынка.

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

Январское исследование Eurekahedge о 23 хедж-фондах, использующих искусственный интеллект, показало, что они демонстрируют намного лучшие результаты, чем те, что управляются людьми.

За последние шесть лет эти фонды добились годовой доходности в 8,44% по сравнению с обычными фондами, показатели которых составили от 1,62% до 2,62%. Авторы исследования связывают доминирование искусственного интеллекта в отрасли с тем, что он постоянно проводит повторное тестирование, а не просто накапливает данные. Это также может быть связано с недостатками традиционных квантовых подходов и применением торговых моделей, построенных с использованием неприбыльных бэктестов на исторических данных, которые не способны приносить прибыль в режиме реального времени.

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

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

Вот почему финансовые гиганты, такие как Goldman Sachs, запустивший торговую платформу Kensho на базе искусственного интеллекта в 2014 году, переходят на роботизированные системы, предсказывающие рыночные тренды и продающие значительно лучше людей.

Почему искусственный интеллект скоро вытеснит людей с биржи


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

«Люди всегда остаются предвзятыми и эмоциональными, вне зависимости от того, осознают они это или нет, — в интервью Bloomberg говорил Бабак Ходжат, сооснователь финансового стартапа Sentient и один из разработчиков Siri в Apple. — Всем известно, что люди совершают ошибки. По-моему, намного страшнее полагаться на догадки и интуицию, а не на данные и статистику».

Системы, вроде той, что разрабатывает компания Sentient может анализировать огромные объемы информации, включающие рыночные данные, объемы торгов, колебания цен, интернет-заявки SEC для всех компаний, данные соцсетей, новости и видео на YouTube. Цель — добиться того, чтобы алгоритм составлял оптимальный инвестиционный портфель на основе имеющихся знаний и регулярно оптимизировал его, исходя из ожидаемых новых данных за каждый месяц.

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

Например, фонд Medallion в Renaissance Technologies, использующий количественные методы анализа фондового рынка, может похвастаться одними из лучших показателей в инвестиционной истории. За 20 лет фонд смог вернуть +35% в годовом выражении. Это означает, что если бы вы вложили $10 тыс в 1997 году, сегодня у вас на руках было бы уже $4,04 млн.

Bridgewater Associates наняли команду, которая должна построить автономную ИИ-систему под руководством Дэвида Ферручи, в прошлом разработавшего для IBM компьютер Watson, победивший в интеллектуальной телевикторине Jeopardy.

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

Некоторые компании используют искусственный интеллект для обеспечения доходности через алгоритмическую торговлю. Фонд Sentinent Technologies, всего за несколько минут может сымитировать 1800 торговых дней, сталкивая триллионы виртуальных трейдеров между собой.

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

Как это работает на практике: 9 ИИ-компаний в сфере инвестиций


Numerai проводит соревнования для среди создателей торговых стратегий. Элементы лучших стратегий затем используются фондом в реальной торговле на бирже, а их создатели получают вознаграждение.

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

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

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

Компания Sentinent также запустила несколько приложений на своей платформе искусственного интеллекта. На развитие одного из них, связанного с алгоритмическими продажами, удалось привлечь $135 млн. Фонд создал несколько триллионов роботов-трейдеров, позже объединил их и собирается выделить этот проект в отдельную компанию.

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

Французский стартап Walnut Algorithms привлек $446 тыс, чтобы совместить машинное обучение с финансовой экспертизой и добиться абсолютного возврата инвестиций.

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

Aidyia, гонконгский хедж-фонд, использующий «общий искусственный интеллект», более точно имитирующий человеческий мозг, в 2015 году запустил фонд длинных/коротких инвестиций, торгующий акциями США и совершающий все биржевые сделки без вмешательства человека.

Канадская компания BUZZ Indexes собирает big data из социальных сетей, интерпретирует эти данные, используя искусственный интеллект, а затем определяет, у каких акций доходность вырастет. На основе этого строится индекс интереса в социальных медиа и определяются 75 самых популярных акций.

Система анализирует не только Twitter и Facebook, но и больше 50 тематических блогов, сайтов и новостных сервисов. После этого Buzz очищает данные и интерпретирует настроение пользователей по аналогии с Aspectiva, маркирующей все обзоры продукта в сети как положительные или отрицательные.

Если машины победят: лучшие «технари» смогут принести больше пользы


«Повсеместное внедрение искусственного интеллекта в финансовой индустрии приведет к тому, что трейдеры с огромными зарплатами лишатся рабочих мест из-за роботов так же быстро, как и фабричные рабочие. — говорит Марк Миневич, основатель Going Global Ventures и старший научный сотрудник американского Совета по конкурентоспособности США. — Влияние искусственного интеллекта в индустрии постепенно нарастает, но очень скоро он совершенно изменит ее».

Согласно исследованиям компании Coalition Development, сегодня средняя зарплата сотрудников в 12 крупнейших инвестиционных банках доходит до $500 тыс в год, причем у многих трейдеров доходы равняются нескольким миллионам. Например, в 2015 году как минимум пять менеджеров топовых хедж-фондов заработали $1 млрд. Мотивация отказаться от сотрудников, которые зарабатывают по $500 в час, и заменить их роботами, понятна.

В 2000 году у Goldman Sachs было 600 трейдеров, которые покупали и продавали акции по указанию крупных клиентов банка, сегодня осталось лишь два таких сотрудника, а всю остальную работу делают роботы. Как скоро то же самое произойдет со всеми остальными финансовыми компаниями, вопрос времени.

Такая тенденция, скорее всего, преобразит индустрию, потому что лучшие выпускники университетов потеряют интерес к Уолл-Стрит и предпочтут работу в медицине, энергетике, производстве и других полезных для общества сферах. Сегодня примерно треть выпускников десяти лучших бизнес-школ США идет работать в финансы, лишь 5% идет в медицину и еще меньшее количество – во все остальные отрасли.

Если выпускники MBA уйдет с Уолл-Стрит, но останутся в Нью-Йорке, это поможет ему соперничать с Сан-Франциско и не страдать от недостатка специалистов, что особенно важно сейчас, когда технологическая индустрия может лишиться притока инженеров из-за визовых ограничений новой администрации президента США.

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

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

Другие материалы по теме финансов и фондового рынка от ITinvest:


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330884/


Метки:  

[Из песочницы] Дневник одной разработки, или Xamarin как он есть

Среда, 14 Июня 2017 г. 15:04 + в цитатник
Хотелось бы поделиться первым опытом разработки на Xamarin. До этого мной не было написано ни одного приложения для мобильных устройств, тем не менее, как оказалось, с Xamarin можно достаточно легко и быстро написать приложение. Разработка велась в основном по вечерам и, периодически, на выходных, поэтому, не смотря на то, что дней в дневнике много, фактически было затрачено небольшое количество часов.

Итак, дневник…


День 1


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

День 2


Решил, что что-то нужно менять. Нет, правда, сколько можно бесцельно проживать жизнь? Думал на тему того, что может мне помочь. Ничего не придумал. Загрустил. Поел печенек. Отпустило.

День 3


Собрав волю в кулак, мыл посуду. В сознании начала вырисовываться идея некоторого приложения, в котором можно как-то учитывать свои действия. Например, помыл посуду — +1 очко к мытью. Потягал гантели – +1 к… спорту. Погуглил. Не нашел ничего нормального. Загрустил.

День 4


Вновь собрав волю в кулак, решил сам написать приложение для Android. Ну а что, там дел-то совсем немного. Вверху шапка с общим прогрессом, под ней список с навыками. По клику увеличиваем навык на +1. Впереди 3 дня праздников, быстренько сделаю на Xamarin-е.

День 7


За день тоже можно успеть. Наверное.

День 8


Ну… Я что-то не подумал, что не знаю Xamarin. Как-то привык, что обычно в программировании встает вопрос «Зачем?», а вопрос «Как?» в последнее время всплывает редко и остается между строк. Нет, не то чтобы вообще ничего не получилось. Начал писать на Xamarin.Forms, позиционировать элементы научился, шапку сделал… Но, кажется, так быстро как планировал написать не получится. Загрустил. Поел печенек. Отпустило.

День 9


Сделал список навыков через ListView. Возможно, все не так уж плохо и к концу недели доделаю.

День 11


Не, как так-то? Ну почему ListView такой тормознутый? Cashing Strategy менял, layout менял, все равно остался раздражающий лаг. Переделал на TableView. Стало лучше. Обрадовался. Поел печенек.

День 12


Решал вопрос с хранением списка навыков. Простят меня боги, но я решил сохранять их все вместе в одном параметре в конфиге. Да, при любом изменении навыка мне приходится перезаписывать все навыки. Да, так не делается. Да, боль от содеянного пронзает мне душу.

День 13


Сделал добавление и удаление навыков в интерфейсе. Сделал анимацию. Анимация выкидывает ошибку. Грущу.

День 14


Осознал, что ошибку выкидывает двойное использование анимации при быстром нажатии кнопок. Т.е., скажем, вот так работает:

await grid.RotateYTo(grid.RotationY + rotation, 125);
longTapGrid.IsVisible = true;

А вот так уже нет:

await grid.RotateYTo(grid.RotationY + rotation, 125);
longTapGrid.IsVisible = true;
await grid.RotateYTo(grid.RotationY + rotation, 125);

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

Обратился к духам. Они велели сделать так и не задавать вопросов:

await grid.RotateYTo(grid.RotationY + rotation, 125);
longTapGrid.IsVisible = true;
await Task.Run(async () => await grid.RotateYTo(grid.RotationY + rotation, 125));

Что тут сказать… 1:0 в пользу духов.

День 15


Исправлял ошибки. Примирился с практически полным отсутствием описания ошибки и стека исключения и привык использовать Device Log.

День 16


Исправлял ошибки, порожденные предыдущим исправлением ошибок.

День 17


Радовался, что почти все готово и ел печеньки.

День 18


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

День 19


Для Xamarin есть компоненты, которые позволяют рисовать шикарные графики. Колонки с chartjunk, круговые диаграммы такой красоты, что начинают слезиться глаза. Правда, они немного платные, где-то от 300-400$. Смахивая скупую слезу, подключил бесплатный Oxyplot к проекту. Потом отключил. Потом снова подключил. Вариантов особо нет.

День 21


В принципе, практически все готово. Наводил лоск, ел печеньки, и думал, что делать дальше.

День 22


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

Все рухнуло. Но, пожалуй, начну по порядку.

Итак, погуглив, как делается реклама, я добавил Xamarin.GooglePlayService.Ads к проекту. После этого у меня что-то случилось с References в проекте. То ли что-то криво добавилось, то ли что-то еще произошло, но некоторые ссылки стали неразрешимы… В общем, посмотрев на это, я сделал ошибку. Решил обновить все компоненты в проекте, в надежде на то, что ссылки исправятся. Не делайте так.

Что было дальше, помню смутно. Помню, сломался Nuget и перестал удалять/изменять компоненты, а на все мои действия выдал неизменно выводящую меня из себя ошибку «This collection is read-only».
Ну кто так делает? Вот о чем он? Какая коллекция read-only? Больше всего раздражало слово «This». Оно словно намекало на то, что всем должно быть понятно, что именно за коллекция. На втором месте по раздражительности был тот факт, что не было указано ни место ошибки, ни какой-либо код ошибки. В привычном месте, где должна быть эта информация, было пусто.

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

После этого было еще много ошибок. Например, «java.lang.outofmemory» (решилось увеличением heapsize), или «java.exe exited with code 2» (решилось удалением Xamarin.GooglePlayService.Ads, при этом Xamarin.GooglePlayService.Ads.Lite остался), или Proguard начинал в качестве ошибки выдавать кракозябры (решилось переносом sdk в корень диска, чтобы путь к нему не содержал пробелов). Так же были совсем странные ошибки, связанные с обновлением компонентов до последней версии.
Так или иначе, к вечеру все исправил и вернулся к тому, с чего начинался день.

День 23


Добавил рекламу и протестировал релизную сборку. Никаких проблем. Вот и что это вчера было?

День 24


Заливал в Google Play. Долго философски размышлял, является ли приложение игрой или нет. Очень хотелось, чтобы было игрой, но, пожалуй, это не так. Скрипя сердцем, поставил категорию «Стиль жизни», обрекая приложение на безызвестность. Впрочем, не в скачиваниях счастье… Хотя, надо признать, они бы потешили мое самолюбие. Главное – полученный опыт разработки на Xamarine… Ну и, разумеется, само приложение, я надеюсь, так же будет небесполезно мне.

День 32, или Заключение


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

Первые дней 5 скачиваний не было. Это несколько демотивирует и огорчает, и даже печеньки не спасают.

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

Даже если это всего лишь двадцать человек. Даже если это будет всего один человек.

P.S. Не гарантирую, что все было точно как описывается. На самом деле, я не люблю печеньки.
P.P.S. Ну да, кроме печенек, все так и было.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330882/


Метки:  

May the Code Review be with you

Среда, 14 Июня 2017 г. 14:58 + в цитатник
Code review может быть большой болью для команды, которая только начинает его внедрять. Вы в любом случае наступите на много граблей: будете проводить ревью дольше, чем пишете код, устраивать смертельные споры про расположение скобочек и разбираться, можно ли сливать ветку в master до аппрува команды или нет. Я собрал ряд практик, которые помогут вам сделать процесс адаптации чуть менее болезненным — по крайней мере, мне они точно помогли.
 
Этот материал — краткая выжимка моего опыта, накопленного за несколько лет работы в крупных командах мобильной разработки. Опыт по большей части в мобильной разработке, что оказало влияние на используемые примеры и ссылки. Для тех, кто предпочитает не читать, а смотреть, в течение пары месяцев должно появиться видео с конференции Mobius, где я рассказываю доклад на эту же тему, но с кучей подробных практических примеров.
 


Цели Code Review


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

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

  3. Обмен знаниями в команде
    У каждого в команде есть чему поучиться. Кто-то хорош в алгоритмах, кто-то разбирается в метапрограммировании, а кто-то джедай MVC. Возможность посмотреть на решения друг друга и задать вопросы — отличный способ поднять технический уровень всей команды.

  4. Обнаружение ошибок
    Наиболее очевидная цель — обнаружение ошибок разной степени критичности. Именно об этом в первую очередь думает ваш менеджер, когда вы предлагаете ему заложить определенный процесс времени на code review.

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

Ну а теперь — к делу.
 

Модели организации Code Review в разных командах


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

Небольшая команда


Первый случай, наверное, самый часто встречающийся. Это команда из нескольких человек — скажем, до четырех, которые работают над одним проектом. Здесь уже обычно вовсю расцветает Git Flow, задачи разрабатываются независимо друг от друга в отдельных ветках, а по окончании сливаются в develop.
 

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

Несколько отдельных команд


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

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

Большая команда


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

 
Большим вопросом остается определение конкретных ревьюеров — они могут выбираться как рандомно, кто первый откликнется, так и специально автором ревью. Можно автоматизировать этот процесс, чтобы избежать споров и быть более объективными. Как пример — определять владельца кода по данным истории системы контроля версий или системы для code review.

Разработчик-одиночка


Последний случай — самый грустный. Разработчик работает один в команде. Во-первых, сразу отпадает такая цель, как коллективное владение кодом — нет коллектива, нет и владения. Остальные цели тоже становятся довольно вырожденными — но, тем не менее, сторонний взгляд на код поможет найти часть ошибок и повысить технический уровень в целом.
 

 
В таком случае разработчику нужно обращаться за помощью в открытое сообщество. Я советую три канала.

  1. Различные чаты и сообщества разработчиков
    Два моих любимых — Slack-чат Cocoa Developers Club и Telegram-чат iOS Good Talks.

  2. Встречи разработчиков
    Например, Peer Lab, который проводится в Москве каждую неделю.

  3. Совместная работа с коллегой из другой функции
    Можно подключить своего коллегу, который занимается разработкой под другую платформу — Android, Web или Backend. Но будьте осторожными — не все готовы и хотят погружаться в контекст проблем из другой области разработки.
 

Практики проведения Code Review


Работа по расписанию


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

 
Решает ситуацию расписание. Каждый разработчик в команде определяет промежуток дня, в который он будет смотреть ревью. Расписание всей команды можно держать в одной таблице, чтобы, ориентируясь на это, можно было подбирать себе ревьюеров или рассчитывать время проверки задачи. Я, к примеру, всегда выделял час времени с утра, сразу после прихода на работу — как раз помогало войти в рабочий ритм.
 
Конечно, есть случаи, когда этот механизм не работает — некоторые ревью действительно нужно смотреть максимально быстро. Главное — придерживаться такого режима, чтобы возникновение подобных ситуаций не становилось привычкой.
 

Архитектурные review


Я уверен, что вы сталкивались с ситуацией, когда после реализации задачи выясняется, что нужно было ее сделать абсолютно по-другому. Code Review — не самое подходящее место, чтобы спорить по поводу глобальных архитектурных решений. Код уже написан, задача почти доделана, переписывать все с нуля — слишком затратно. Такие вещи нужно не оставлять на потом, а обсуждать заранее.
 
Как вариант — проведение архитектурного review, защиты своего компонента перед командой либо на словах, либо в виде схемы. Конечно, бывают случаи, когда кого-то осеняет уже во время ревью — тогда это предложение, если оно действительно ценное, стоит задокументировать в issue-трекере и никогда к нему больше не возвращаться.
 
В качестве участников можно привлекать технического лидера проекта, разработчиков, непосредственно заинтересованных в реализации этой задачи, и просто всех желающих из команды.

Ограничение размера review


Есть один замечательный парадокс — чем меньше кода на review, тем больше к нему оставляется комментариев. Это правило остается неизменным практически в любой команде. Для нескольких строк кода характерно наличие огромных и развесистых дискуссий. При увеличении объема изменений до нескольких тысяч строк количество комментариев резко падает до отметки одного-двух, на которой и остается.
 

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

Self review


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

Описание review



 
Когда проводишь code review на постоянной основе, сложно фокусироваться на фактическом смысле изменений — об этом я уже упоминал. Еще один способ помочь ревьюерам удерживать фокус — детально описывать смысл изменений. Обычно я работаю по следующему шаблону:

  • Название review
  • Краткое описание изменений
  • Вещи, требующие особого внимания
  • Связанные задачи и материалы

Чек-листы и их автоматизация


Чек-листы — это круто. Используйте их и для code review. Примеры вопросов из такого чек-листа: «Есть ли закомментированный код?», «Покрыта ли бизнес-логика тестами?», «Обрабатываются ли все ошибки?», «Вынесены ли строчки в константы?». Запоминайте все вопросы, которые часто возникают у команды на review, и заносите их в список.
 
Главное — не давать этому чек-листу разрастаться. Думайте о способах автоматизации каждой из перечисленных там проверок — если приложить достаточно усилий, большую часть потребностей вы сможете закрыть. Есть огромное количество инструментов, которые могут помочь в этой работе — линтеры, статические анализаторы, детекторы дублирующегося кода.

Измерение эффективности Code Review


Внедрение любого процесса должно сопровождаться сбором метрик его эффективности и их дальнейшим анализом. Сам процесс — не самоцель. Code review — не исключение, важно уметь понять, насколько сильно он помогает команде в ее работе.
 
Удобный вариант — исходить из целей, которых мы хотим достичь при внедрении code review. В качестве шпаргалки можно использовать те, которые я обозначил в первом разделе. Один из способов измерения эффективности достижения таких целей — использование подхода Goal-Question-Metric. Состоит он из трех этапов — определение цели, которую мы хотим измерить, постановка вопросов, которые помогут понять уровень достижения цели, и определение метрик, которые помогают ответить на поставленные вопросы. Разберем на примере.
 
Сначала нужно определить намеченную цель. Как пример — «Повысить уровень переиспользования кода». Можно и даже нужно использовать сразу нескольких целей — и измерять их независимо друг от друга.
 
Затем сформулируем вопросы, на которые нужно ответить, чтобы понять, достигаем ли мы цели. В нашем случае это «Используем ли мы общие библиотеки в проекте?», «Вынесены ли визуальные стили в отдельный компонент?», «Много ли кода дублируется?».
 
Ну и последнее — определение метрик, которые помогут ответить на вопрос. В нашем случае это количество общих библиотек, количество мест, где остались захардкоженные стили, уровень дублирования кода.
 
Использовать фреймворк довольно просто. Измеряем обозначенные метрики до внедрения процесса, определяем желаемый результат, и периодически, раз в месяц или в квартал, повторяем эти измерения. Если их можно автоматизировать — еще круче. Спустя какое-то время анализируем результат и определяем, достаточно ли изменились метрики, чтобы счесть процесс эффективным.
 

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

  • Inspection rate — скорость проведения review,
  • Defect rate — количество найденных проблем на час времени, потраченного на review,
  • Defect density — количество найденных проблем на строчку кода.


 
Если собирать такие данные по каждому ревью, то можно вполне адекватно оценить уровень вовлеченности в процесс у каждого участника команды. Ряд систем для проведения code review автоматически собирает такие данные — например, Crucible от Atlassian.

Заключение


Как я уже упоминал во введении, эта статья — краткая выжимка моего выступления, в котором я затрагиваю еще и различные инструменты для автоматизации процесса, правила и нормы поведения в команде и прочие аспекты проведения code review. Чтобы не пропустить появление записи — подписывайтесь на мой Telegram-канал, куда я обязательно выложу его по готовности. Если у вас остались вопросы — приходите на наш митап в субботу, 17 июня, и обсудим их в неформальной обстановке.

Полезные ссылки


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330846/


Метки:  

Поиск сообщений в rss_rss_hh_new
Страницы: 1437 ... 1006 1005 [1004] 1003 1002 ..
.. 1 Календарь