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

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

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

 

 -Статистика

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





Специалисты Emsisoft обнаружили еще один вымогатель на JavaScript

Вторник, 21 Июня 2016 г. 20:05 + в цитатник
В начале января мы писали про находку security-компании Emsisoft, которая обнаружила вымогатель (ransomware), целиком написанный на JavaScript. Вымогатель назывался Ransom32. В новом случае речь также идет о вымогателе на JavaScript, который получил название RAA. Вредоносная программа шифрует файлы пользователя с использованием симметричного алгоритма AES, а также устанавливает в систему пользователя другую известную вредоносную программу — похититель паролей Pony (Fareit). Антивирусные продукты ESET обнаруживают вымогатель как JS/TrojanDropper.Agent. В отличие от Ransom32, RAA не использует для своей работы фреймворк NW.js. Этот фреймворк позволяет разрабатывать приложения на JavaScript для Windows, OS X и Linux. Для работы с функциями шифрования RAA использует криптографическую библиотеку CryptoJS. Она и используется для шифрования файлов пользователя. Устанавливаемый в систему пользователя похититель паролей Pony обнаруживается AV продуктами ESET как Win32/PSW.Fareit.A. Вредоносная программа обычно распространяется с использованием вредоносного вложения в почтовом сообщении. Это вложение маскируется под документ Word (.doc). Для маскировки своих вредоносных функций, вредоносная программа сбрасывает в директорию %userprofile%\documents специальный файл и пытается его открыть с использованием WordPad. Рис. Сбрасываемый на диск фальшивый поврежденный документ (данные Emsisoft). Для обеспечения своей выживаемости в системе после перезагрузки, вымогатель прописывается в известный раздел Run системного реестра. При этом значение параметра указывает на путь к оригинальному дропперу. Рис. Вредоносная программа создает параметр для своей автозагрузки (данные Emsisoft). Вымогатель также удаляет сервис теневого копирования тома Volume Shadow Service (VSS). Такая операция выполняется для того, чтобы гарантировать невозможность восстановления оригинальных копий файлов пользователем после их шифрования (настройка File History). В результате этого, при попытке восстановить файл на его предыдущую версию, операция завершается с ошибкой, как и при попытке получить доступ к функции восстановления системы System Restore. Рис. Сообщение об ошибке при попытке восстановить зашифрованный файл с использованием сервиса VSS (данные Emsisoft). Рис. Функция удаления сервиса VSS (данные Emsisoft). Следующим шагом является процесс шифрования файлов с использованием библиотеки CryptoJS. Зашифрованные файлы получают дополнительное расширение .locked. Рис. Функция шифрования (данные Emsisoft). Вымогатель шифрует файлы со следующими расширениями .doc, .xls, .rtf, .pdf, .dbf, .jpg, .dwg, .cdr, .psd, .cd, .mdb, .png, .lcd, .zip, .rar .csv. Файлы, которые содержат в названии символы ".locked", "~" или "$" пропускаются. Рис. Список расширений файлов для шифрования и исключаемые по присутствующим в именах строках (данные Emsisoft). Файлы, которые содержатся в следующих директориях, исключаются из процесса шифрования Program Files, Program Files (x86), Windows, Recycle.Bin, Recycler, AppData ,Temp, ProgramData и Microsoft. Рис. Список директорий для исключения (данные Emsisoft). Сообщение о выкупе хранится в специальном файле !!!README!!![unique ID].rtf, который создается на рабочем столе. От пользователя требуют выкуп в размере 0,39 биткоинов или $250. Содержимое файла показано ниже. Рис. Текст с инструкциями оплаты выкупа (данные Emsisoft). В начале мы указали, что вымогатель исполняет в системе пользователя файл другой вредоносной программы — Pony, которая представляет из себя похититель паролей. Исполняемый файл Pony хранится по следующему расположению %userprofile%\documents\st.exe. Он включен в JS-дроппер вымогателя и закодирован с использованием base64. Вредоносная программа специализируется на краже конфиденциальных данных пользователя, таких как пароли от различных сервисов. Образцы вредоносных программ имеют следующие идентификаторы SHA1: RAA: 2c0b5637701c83b7b2aeabdf3120a89db1dbaad7 Pony: 822bf6d0eb04df65c072b51100c5c852761e7c9e К сожалению, расшифровка файлов пользователя, которые были зашифрованы RAA в настоящее время не представляется возможным, что, в очередной раз, говорит о важности своевременного использования резервного копирования данных.

Метки:  

Макросы Zend обхода циклов (HashTable Iteration)

Понедельник, 20 Июня 2016 г. 20:35 + в цитатник
Продолжая своё поверхностное изучение исходников PHP (7.0.7) и написания простейшего расширения к нему, хотел бы в этот раз немного углубится и описать приемы обхода массива через принятый аргумент функции, с которыми я познакомился при реализации простой PHP функции median(). Задача этой функции проста — вернуть средне-арифметическое значение. Возможна данная публикация будет полезной другим разработчикам PHP, таким же как и я, которые решили в свободное время немного изучить архитектуру любимого языка, на котором зарабатывают деньги. В предыдущей публикации я на “скорую руку” описал прием быстрого создания расширения в PHP с реализаций функции расчета факториала. Она проста в той степени, что принимает простой параметр целого типа и затем рекурсивно вызывается. Реализация функции median() усложнена тем, что принимаемый параметр — массив, по нему нужно пройтись, для суммирования общего значения, а также просчитать общее число элементов в массиве. В данный момент я упростил задачу еще и тем, что заведо считаю, что все принятые элементы массива — числа. Исходники расширений PHP удивительны тем, что здесь “все пишется” через использование макросов. По крайней мере создается такое первоначальное мнение. Оказывается, для прохода по списку элементов в массиве тоже используются макросы. Для наглядности приведу сразу код функции с последующим небольшим описанием. Функция описана все в том же файле — mathstat.c расширения mathstat. Ссылка на github. Занесение в список функций расширения mathstat: const zend_function_entry mathstat_functions[] = { PHP_FE(confirm_mathstat_compiled, NULL) /* For testing, remove later. */ PHP_FE(ms_factorial, arginfo_ms_factorial) PHP_FE(ms_median, NULL) PHP_FE_END /* Must be the last line in mathstat_functions[] */ }; Само определение тела функции: PHP_FUNCTION(ms_median) { int argc = ZEND_NUM_ARGS(); double total = 0; int count = 0; zval *array, *value; if (zend_parse_parameters(argc, "a", &array) > Если смотреть тело функции, то как и в прошлый раз, вызывается функция проверки параметра, где в качестве шаблона принимаемого типа аргумента задаем значение “a” (array) if (zend_parse_parameters(argc, "a", &array) > Теперь самое интересное, проход по циклу реализован через макрос ZEND_HASH_FOREACH_VAL. Всего макросов которые проходят по массиву я нашел в справочках 7 штук. При этом, везде используется вместо массива термин HashTable. Для нашего случая я выбрал самый простой макрос. Первым аргументом он получает сам принятый массив через функцию, а вторым zval (базовая структура данных, которая хранить себе значение и тип данных — видео по этой части Дмитрия Стогова). В данном случае, я просто вызываю функцию zval_get_double, которая грубо говоря, мне и возвращает самое значение из массива. Если переписать это на обычный код PHP, то получится: 1 <?php 2 $array = [1,2,3]; 3 4 $number = 0; 5 $count = 0; 6 7 foreach($array as $val) { 8 $number > То есть, по сути ничего сложного, таже запись, только с использованием макроса. Если посмотреть на другой более расширенный макрос, ZEND_HASH_FOREACH_STR_KEY_VAL(ht, key, val) то без кода уже понятно, что это аналог php цикла: foreach($array as $key => $value) { } Для наглядности приведу из справочника все макросы: ZEND_HASH_FOREACH_VAL(ht, val) ZEND_HASH_FOREACH_KEY(ht, h, key) ZEND_HASH_FOREACH_PTR(ht, ptr) ZEND_HASH_FOREACH_NUM_KEY(ht, h) ZEND_HASH_FOREACH_STR_KEY(ht, key) ZEND_HASH_FOREACH_STR_KEY_VAL(ht, key, val) ZEND_HASH_FOREACH_KEY_VAL(ht, h, key, val) На этом все. Спасибо за отнятое время и потерянные деньги на мобильном трафике.

Метки:  

Emacs как редактор кода для Python и Golang

Воскресенье, 19 Июня 2016 г. 23:01 + в цитатник
Введение Когда полгода назад я решил перейти с Vim на Emacs сначала я решил поискать статьи по настройке последнего на хабре. К моему удивлению нашлась всего одна статья в которой рассказывали, как настроить данный редактор для работы с Python. У меня было 2 года опыта работы с vim и имелись определенные требования, которые не были затронуты в данной статье. Вообще рускоязычных статей про работу в Emacs над Python очень мало на просторах интернета. Я не буду рассказывать про тонкости настройки самого Emacs, для этого не хватит даже отдельной статьи. Сразу хочу предупредить любителей холивара Emacs vs Vim, а также Emacs/Vim vs IDE — я не хочу разводить бесполезные споры на эти темы. После долгих поисков я нашел редактор, который устраивает меня всем и который можно настроить как душе угодно. Я просто хочу поделится своими конфигами, а также надеюсь увидеть альтернативные решения в комментариях, чтобы продолжать настраивать данный инструмент под себя. Требования Самое первое требование — легко переносимая конфигурация и установка плагинов между домом и работой. Для этого использую github. Так как часто случается, что я изменяю что-то в конфигах, я использую meld для просмотра разницы между файлами. В meld можно просматривать как директории, так и отдельные файлы. После синхронизации тем же мелдом все изменения добавляю в домашнюю директорию. Не менее важное требование — удобный менеджер плагинов, с ленивой загрузкой и обновлением, как NeoBundle из vim. В процессе поиска такого менеджера также выяснилось, что в емаксе плагины можно скомпилировать, для ускорения загрузки. На счастье, нашелся как раз такой менеджер, который удовлетворял всем требованиям и даже больше. Это el-get — идеальный менеджер с автокомпиляцией, автоматической инициализацией, а также самое важное — рецептами установки. Приведу короткий пример рецепта, для наглядности. (:name flycheck :type github :pkgname "flycheck/flycheck" :checkout "0.25.1" :minimum-emacs-version "24.3" :description "On-the-fly syntax checking extension" :build '(("makeinfo" "-o" "doc/flycheck.info" "doc/flycheck.texi")) :info "./doc" :depends (dash pkg-info let-alist seq) :post-init (progn (add-hook 'python-mode-hook #'flycheck-mode) (add-hook 'js-mode-hook #'flycheck-mode) (add-hook 'web-mode-hook #'flycheck-mode) (add-hook 'lisp-interaction-mode-hook #'flycheck-mode) (add-hook 'fish-mode-hook #'flycheck-mode) (add-hook 'markdown-mode-hook #'flycheck-mode) (add-hook 'go-mode-hook #'flycheck-mode) (setq flycheck-check-syntax-automatically '(mode-enabled save idle-change)) (setq flycheck-highlighting-mode 'lines) (setq flycheck-indication-mode 'left-fringe) (setq flycheck-checker-error-threshold 2000) )) Это рецепт установки flycheck — плагина, для синтаксической проверки файлов при редактировании, на лету. В рецепте можно указывать источник кода — репозиторий git/github или просто ссылку на файл или название плагина в ELPA/MELPA, необходимые зависимости, в случае github — ветку или таг. Команда :build позволяет запускать системные утилиты, если они необходимы для корректной установки плагина. Также есть замечательная команда — :post-init, в ней можна указывать лисповый код, который будет запускатся каждый раз после инициализации плагина. Я решил прописывать в этой команде все настройки связанные с данным плагином. В общем — очень удобный инструмент. Я сразу отказался от файла ~/.emacs.el по причине синхронизации между работой и домом. Поэтому все настройки расположены в папке ~/.emacs.d. Максимально тонкий init.el в котором подключаются логически разбитые файлы из папки settings. (add-to-list 'load-path (expand-file-name "settings" user-emacs-directory)) (require 'dark-mint-theme) (require 'scratch_my) (require 'package_my) (require 'hooks_my) (require 'keybindings_my) ... автоматически генерируемый при customize код Первый файл — тема оформления. Больше тем тут scratch_my.el описывает все стандартные настройки и включает необходимые режимы, которые уже присутствуют с нуля в любом свежем Emacs. В package_my.el список всех устанавливаемых плагинов и несколько функций для корректной установки. Хуки разных режимов описаны в файле hooks_my.el. Смена сочетаний клавиш вынесена в отдельный файл keybindings_my.el. Также синхронизируются папка с сниппетами yasnippet и с рецептами. Очень часто я вношу изменения в рецепты, добавляя туда настройки плагинов, поэтому я храню их в отдельной папке. Плагины, не зависимые от языка программирования Я подробно не буду описывать все плагины, к каждому прилагается ссылка, где подробно все расписано. Начнем пожалуй с avy, плагина позволяющего переходить на слово, содержащее введеный символ(аналог vim-easymotion). Для автодополнения используется company-mode — универсальное автодополнение для Emacs. Очень быстро работает, полностью настраивается, хотя документация у него неполная, в исходники заглядывал частенько. Удобство проявляется в структуре даного плагина. Есть бекенд — индивидуальный код для разных режимов и фронтенд — общий код, который отрисовывает результаты автодополнения в самом Emacs. Для разных режимов используются разные бекенды. Например для лиспа используется company-elisp бекенд, для Python — company-jedi(бекенд для jedi — библиотеки статического анализа кода Python). Для дополнения golang кода используется company-go бекенд. expand-region используется для семантического выделения текста. Более подробно в этом видео. Для работы с git использую три замечательных плагина — git-gutter, mo-git-blame и magit. Хочу особо выделить последний плагин — он просто потрясающий, пару касаний и код уже на сервере (видео). А как же файловый менеджер спросите вы? neotree. Интеграция с git присутствует. Очень полезный плагин — helm — автодополнение к всему. Поиск по открытым буферам(helm-swoop), по недавно открытым файлам, по файлам в текущей директории, поиск по командам, переименование переменных в нескольких буферах и много всего остального. Отличная статья описывает все возможности данного плагина. multiple-cursors — после просмотра данного видео вам обязательно захочется его попробовать:). Плагин, с помощью которого можно назначить действие на двойное нажатие любых клавиш называется key-chord(видео) Аналог vim-powerline — powerline projectile — плагин для управления проектами в Emacs. Поиск по проекту, замена по файлам проекта, переход внутри проекта, переключение проекта и множество других полезных функций. Подробности в этой статье yasnippet — позволяет создавать и использовать сниппеты для разных языков программирования. Python mode Наконец-то мы переходим к настройке Emacs непосредственно для работы с Python. Начнем пожалуй с хуков ;; Python mode (defun my-merge-imenu () (interactive) (let ((mode-imenu (imenu-default-create-index-function)) (custom-imenu (imenu--generic-function imenu-generic-expression))) (append mode-imenu custom-imenu))) (defun my-python-hooks() (interactive) (setq tab-width 4 python-indent 4 python-shell-interpreter "ipython" python-shell-interpreter-args "-i") (if (string-match-p "rita" (or (buffer-file-name) "")) (setq indent-tabs-mode t) (setq indent-tabs-mode nil) ) (add-to-list 'imenu-generic-expression '("Sections" "^#### \\[ \\(.*\\) \\]$" 1)) (setq imenu-create-index-function 'my-merge-imenu) ;; pythom mode keybindings (define-key python-mode-map (kbd "M-.") 'jedi:goto-definition) (define-key python-mode-map (kbd "M-,") 'jedi:goto-definition-pop-marker) (define-key python-mode-map (kbd "M-/") 'jedi:show-doc) (define-key python-mode-map (kbd "M-?") 'helm-jedi-related-names) ;; end python mode keybindings (eval-after-load "company" '(progn (unless (member 'company-jedi (car company-backends)) (setq comp-back (car company-backends)) (push 'company-jedi comp-back) (setq company-backends (list comp-back))) ))) (add-hook 'python-mode-hook 'my-python-hooks) ;; End Python mode Для работы плагинов нужно установить пару пакетов через pip pip install -U jedi virtualenv flake8 Устанавливаем настройки отступов и путь к интерпретатору, выставляем специфические сочетания клавиш, добавляем бекенд company-jedi и настраиваем imenu. Про автодополнение уже было выше(company-jedi), поиск по файлу и структуре файла(именам классов, переменным, методам и тд.) происходит через imenu(F10), открытие и закрытие файлового менеджера NeoTree происходит при нажатии F7. Теперь немного о используемых плагинах auto-virtualenv — отлично работает, особенно в связке с projectile. jedi-core — отдает company-jedi варианты автодополнения, переходит по определениям, показывает доки к функциям и классам и тд. pip-requirements — как видно из названия — пакет для работы с requirements. py-autopep8 — позволяет автоматически форматировать код в cоответствии с стандартом pep8. py-isort — можно автоматически сортировать все импорты в файле Python REPL В хуках мы указали какую версию shell мы будем использовать (setq python-shell-interpreter "ipython" python-shell-interpreter-args "-i") При нажатии C-c C-c — все содержимое текущего буфера передается в ipython, где его можно тут же протестировать. Если нужно лиш часть кода просмотреть, выделяете ее и нажимаете C-c C-r Также можно использовать встроенный в python-mode деббагер, выполнив команду M-x pdb RET(RET — в емаксе обозначает ентер/return, поначалу меня это сбивало с толку). Также есть более функциональная версия — realgud В качестве примера, хочу продемонстрировать несколько скриншотов Emacs для golang Несколько плагинов используется при работе с go проектами. go-mode — режим работы go-mode. Позволяет смотреть документацию, переходить по определениям, использовать различные утилиты проверки и форматирования кода, типа gofmt, golint и тд. Очень удобный плагин. flycheck-gometalinter — интеграция gometalinter c flycheck. company-go — бекенд для company Другие плагины markdown-mode — в данном режиме я как раз и пишу данную статью. А с помощью livedown просматриваю результат сразу в браузере. web-mode — позволяет работать с html, css, Django/Jinja2 templates. restclient — плагин для работы с разнообразными апишками. Emacsrocks покажет больше в своем видео. Заключение Жаль что в одной статье невозможно расписать все особенности и тонкости настройки каждого плагина, но я надеюсь список с коротким описанием позволит читателям узнать что-то новое из моего опыта. Также хабрахабр славен тем, что действительно полезную информацию часто можно узнать из комментариев, поэтому прошу вас делится своими настройками и опытом, это будет полезно и мне и вам. Традиционно, все ошибки и замечания прошу отправлять мне в личные сообщения. Полезные ссылки Common Lisp IDE Emacs как IDE для Python Emacsrocks Изучаем Emacs(плейлист) Emacs — the Best Python Editor? Emacs как IDE для Go спасибо ReanGD за ссылку

Метки:  

Device Lab от Google: маячки с технологией Eddystone

Суббота, 18 Июня 2016 г. 18:33 + в цитатник
Долгое время мобильные приложения и физический мир никак не пересекались. Но технология Bluetooth маячков позволила разработчикам "общаться" с объектами реального мира, а  пользователям получать самые релевантные данные от их текущей локации с точностью до сантиметра. Первые устройства уже отправились разработчикам, а сегодня в Лаборатории Google мы представляем разработчикам маячки Eddystone - iBKS и BKON, реализующие, в том числе, и функцию так называемого Physical Web ("физического веба"). Подайте заявку, возьмите устройства для разработки, поделитесь с сообществом результатами, а с миром новым приложением, способным изменить его!
Читать далее

Метки:  

[Перевод] Метод Super Mario World: серии препятствий

Пятница, 17 Июня 2016 г. 20:33 + в цитатник
Это третий урок из цикла о том, как применять метод Super Mario World при построении собственных уровней в Super Mario Maker. В предыдущих статьях мы рассмотрели способы упорядочить элементы геймплея в Mario Maker на таких уровнях сложности организации контента, как испытание (низкий) и модуляция (средний). Если вы еще не успели прочесть их, вам стоит это сделать, потому что данная статья основывается на пройденном ранее материале. На это раз мы поговорим о самом высоком уровне сложности организации контента – серии препятствий. Они отвечают за определенный тип навыков, необходимый для прохождения ряда испытаний или уровней. Понимая, как работают серии препятствий в Super Mario World, вы сможете создавать правильную нагрузку не только в ваших уровнях Super Mario Maker, но и в ваших собственных играх. Мой пример Я создал в Super Mario Maker демо-уровень, который использует 2 серии препятствий: «двигающиеся объекты» и «повторяющиеся противники». Вот как он выглядит: Вы можете попробовать пройти его самостоятельно. ID уровня: F7E5 0000 0125 6EF3. Чтобы хорошо понимать, как работают серии препятствий, нам нужно сделать краткий экскурс в историю видеоигр. Краткая история создания видеоигр Историю создания видеоигр можно условно разбить на 3 эпохи: аркадные, составные и эпизодические игры. У меня есть более подробная работа на эту тему, но в данном случае нас интересуют только 2 первые эпохи, так как именно они позволяют глубже понять принцип создания игр по методу Super Mario. В играх аркадной эпохи вроде Space Invaders, Pac-Man или Galaga геймплей выстраивался всего на нескольких переменных. Их сложность росла по мере того, как увеличивалось число противников, их скорость и частота атак. Всё это относится к количественным расширениям, о которых мы говорили в предыдущих статьях. Качественные дополнения приобрели современный вид, когда Сигэру Миямото из Nintendo придумал составной тип игры. Составная игра совмещает в себе 2 жанра, позволяя игроку использовать механики одного жанра для решения задач другого. Super Mario Bros, первая полноценная составная игра, совмещала в себе жанры экшн и платформер. Её пример отлично иллюстрирует данный принцип: игрок может решать задачи жанра экшн (поражение противников), используя механики платформера (прыжки). Игры из серии Super Mario Bros совмещают в себе элементы экшна и платформера Но это не всё: настоящая составная игра должна также постоянно переходить от одного жанра к другому, чтобы геймплей не надоедал игроку. Такое возвратно-поступательное движение удерживает внимание игроков и создает то, что я называю динамикой составной игры. Как это относится к дизайну уровней? Разобравшись с теорией, давайте посмотрим, как применить эти знания при работе с Mario Maker. Хорошо понимая теорию составных игр, вы без труда разберетесь, как правильно наполнять уровни в Mario. Мы выяснили, что игры Mario совмещают в себе элементы экшна и платформера. Каждый уровень игры должен строиться преимущественно с использованием контента одного из этих жанров. Соответственно, при создании нового уровня дизайнеру прежде всего нужно определиться с жанром, который будет превалировать. Повторюсь: это решение нужно принять на самом раннем этапе планирования дизайна. Если бы мы создавали платформеры году в 1986-м, на данном этапе мы бы уже могли переходить к разработке. Но с тех пор игры ушли далеко вперед, стали глубже и приобрели много особенностей. Потому нам нужно определиться еще с одной важной деталью, появившейся благодаря играм Mario – набором целевых навыков, необходимых для игры. Начиная с Super Mario World, разработчики из Nintendo создавали уровни таким образом, чтобы задействовать разные навыки игроков. Они хотели подарить им новый опыт при прохождении уровней уже привычного жанра. С тех пор в игре Super Mario World принято выделять 2 отдельных набора навыков, один из которых отвечает за расчет времени, а другой – за скорость. Каждый из них подходит для любого из двух жанров игры. Таблица ниже нагляднее демонстрирует это соответствие: Каждая комбинация жанра и набора навыков создает совершенно новый тип уровня. Эти типы относятся к самому высокому уровню организации контента по принципу ИМСП – серии препятствий. Одной серии препятствий соответствует ряд уровней определенного жанра с определенным набором необходимых навыков. В данном уроке мы разберем 2 серии: «двигающиеся объекты» и «повторяющиеся противники». Не волнуйтесь, если вам не совсем понятно их значение, далее я всё подробно объясню на примерах. Применяем теорию в Mario Maker Первая серия препятствий, о которой мы поговорим, это «двигающиеся объекты». Её также можно назвать «двигающимися платформами», потому что она основывается на механиках платформера и своевременном выполнении прыжков. Я использовал слово «объекты», так как в играх Mario платформы часто выглядят не как платформы: двигающимися объектами могут быть стены, бочки или противники – но всех их можно обозначить собирательным понятием «объект». Пример серии двигающихся объектов В отличие от «двигающихся платформ», серия повторяющихся противников основывается на движении противников. Соответственно, теперь вместо платформ Марио нужно преодолеть ряд противников, двигающихся по определенному циклу. Цикл их движения необязательно должен быть замкнутым или круговым. Любой противник, двигающийся с фиксированной скоростью и по фиксированной траектории, движется циклично. Главное, чтобы игроку было очевидно, куда и когда будет двигаться противник, – как в случае с направлением движения платформы. Конечно, эта серия препятствий относится скорее к жанру экшн, так как опасность заключается не в неудачном прыжке, а в столкновении с противником. Если вы посмотрите, то убедитесь сами, что многие уровни в Super Mario World, использующие серию повторяющихся противников, почти не требуют выполнения прыжков. Пример серии повторяющихся противников В моем уровне, как и в большинстве замков и крепостей игры Super Mario World, игрок больше бегает, чем прыгает. Конечно, прыжки здесь тоже встречаются, но серия повторяющихся противников строится прежде всего на том, чтобы бежать в нужное время, а для этого иногда приходится ждать. Конечно, можно постараться пробежать все Твомпы и Гриндеры из примера выше на полной скорости, но хитрость в том, что это довольно трудно сделать. Если же игрок просто подождет подходящего момента, ему станет намного легче справиться со всеми препятствиями. Всё дело в расчете времени и точности, а не в скорости и реакции. Ключевым моментом при работе с повторяющимися противниками является совмещение разных циклов движения нескольких противников. По большому счету, вам нужно просто объединить несколько несинхронно двигающихся препятствий или противников в одном испытании. Например, вот так: Более сложный пример серии повторяющихся противников Интервалы, через которые турбина выпускает пламя, не соответствуют интервалам движения Гриндера. Выходит, каждый из них представляет опасность в разное время. А значит, игрок должен учесть эти факторы и высчитать подходящий момент для безопасного прыжка. Сам по себе прыжок не представляет ничего сложного, но он должен быть сделан в нужное время. После этого переход заканчивается, и уровень снова возвращается к серии двигающихся объектов. Если вы как дизайнер уровней хотите четко придерживаться формального стиля Nintendo, обратите особое внимание на этот шаг. В Super Mario World (как и в других играх Mario) часто встречаются уровни с длительными переходами, но очень немногие из них заканчиваются сменой серии препятствий. В нашем случае возврат к серии двигающихся объектов приведет к дальнейшему усложнению изначальной идеи отделения от платформы. Теперь Марио вынужден перемещаться между двигающимися платформами, почти как это было в Super Mario World на уровнях Cheese Bridge или Way Cool. Эта часть уровня немного короче, к тому же функциональность Super Mario Maker ограничена и не позволяет мне выстроить что-либо более грандиозное и запутанное на данном этапе – вроде того, что вы могли видеть в Super Mario World. Тем не менее, в этой части уровня игрок должен рассчитывать время движения двух платформ, а не одной, что представляет собой вполне закономерное дополнение. Затем я объединяю 2 серии испытаний для финального испытания. Здесь у нас представлены как двигающиеся объекты, так и повторяющиеся противники: Игроку нужно спрыгнуть с двигающейся платформы, пройти через несколько повторяющихся ловушек и снова вернуться на платформу. Все это более-менее понятно даже на первый взгляд. Я настроил вращение огненных барьеров таким образом, чтобы можно было быстро пробежать их, ожидая всего по секунде возле каждого. Нужно всего лишь выполнить 2 удачных перебежки и спрыгнуть обратно на двигающуюся платформу, когда она будет проходить под нижним рядом камней. Подводим итоги Теперь вам должно быть немного понятнее, как работают серии препятствий. Те две, которые мы рассмотрели сегодня, далеко не единственные в Super Mario World, и тем более – в платформерах. В следующей статье мы разберем 2 другие серии препятствий и поговорим о других играх от Nintendo. Вот ключевые тезисы данного урока: Многие классические видеоигры совмещают в себе 2 и более жанров. Отклонение в сторону одного или другого жанра от уровня к уровню позволит освежить геймплей вашей игры. Но помните: ни в коем случае не стоит полностью отказываться от какого-либо из жанров, лежащих в основе вашей игры. Наравне с жанрами в игре можно поочередно менять целевые навыки, например расчет времени или скорость, решение задач или ведение боя. В большинстве уровней игры Super Mario World используются серии испытаний, которые совмещают в себе механики определенного жанра и определенный навык. Как правило, когда внутри одного уровня игры Super Mario World происходит смена серии испытаний, меняется жанр, а не целевой навык. Переход от одного жанра к другому в пределах одного уровня вполне возможен. Но смена требуемого навыка в пределах одного уровня недопустима. К примеру, уровень, требующий навыка расчета времени, не может превратиться в такой, где нужно преодолевать препятствия на скорость. Желаю вам удачи с созданием ваших уровней!

Метки:  

[Перевод] Распутывая историю Ады Лавлейс (первого программиста в истории)

Пятница, 17 Июня 2016 г. 19:06 + в цитатник
Перевод поста Стивена Вольфрама "Untangling the Tale of Ada Lovelace".
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе и подготовке публикации.Содержание
Ранние годы Ады
Чарльз Бэббидж
Уровень развития этой области
Возвращаемся к Аде
Возвращаясь к Бэббиджу
Статья Ады
После статьи
После смерти Ады
Что стало с Бэббиджем?
Повторное открытие
О чем на самом деле писала Ада
Вычисление чисел Бернулли
Бэббидж vs. Ада?
Секретный ингредиент Бэббиджа
В большем масштабе
А что, если...
Какими они были?
ЗаключениеАда Лавлейс родилась 200 лет назад. Для некоторых она является знаменательной фигурой в истории вычислительной техники; для других — изрядно переоцененной личностью. В течение долгого времени я пытался разобраться, как всё было на самом деле. И вот, к её двухсотлетию, я решил разобраться в том, что называл для себя "тайной Ады".

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

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

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

Метки:  

Автоматизация разработки ПО: сможет ли «программист» превратиться в «оператора ЭВМ»

Пятница, 17 Июня 2016 г. 07:18 + в цитатник
К чему ведет нас прогресс в области производства программного обеспечения? Средства разработки ПО становятся все более совершенными, некоторые этапы разработки полностью или частично автоматизированы. Консерваторы, конечно же, скажут, что программист в настоящее время – уже не торт, что подобная автоматизация ведет к упрощению задач и потере квалификации инженера-программиста. По их мнению, на фоне развития инструментария происходит деградация кадров. Но если копнуть глубже, возникнут вопросы. О каких именно программистах речь? О тех, кто проектирует ПО? О тех, кто разрабатывает алгоритмы? О ведущих разработчиках или простых «кодерах»? В любом случае, одного мнения здесь быть не может. Поэтому, прежде чем делать какие-то выводы, стоит хотя бы вспомнить, как мы пришли к этому. Точка отсчета Как сказал Михаил Густокашин на лекции в «Яндексе», давайте начнём с самого начала: В самом начале у компьютеров не было даже клавиатуры! То есть всё было очень плохо — у них не было ни клавиатуры, ни экрана, были перфокарты (это такие штучечки с дырочками или с отсутствием дырочек). И программы в то время писали с помощью машинных кодов — у каждой операции в компьютере (сложение, умножение, какие-то более сложные операции) был код. Люди сами по табличке выбирали этот код, всякие адреса в памяти, всё это выбивали руками и засовывали в считыватель — и оно всё считалось. Конечно, работа программиста была, наверное, тогда не особо интересной — проделывать дырочки — и с развитием науки и техники, конечно, начали придумывать всякие более «интересные» штуки. Например, ассемблер (Assembler), который уже несколько облегчал жизнь. Ну, как он облегчал жизнь? Вместо запоминания того, что там какой-то «волшебный» код у команды, использовались всякие слова, похожие на «человеческий» английский язык — какие-нибудь add или mov — ну и затем перечислялись регистры или области памяти, переменные, с которыми нужно эти операции производить. Но понятное дело, что это в общем-то тоже требовало достаточно большого напряжения ума, чтобы держать у себя в голове, в каком регистре у нас что лежит, где какие переменные и что вообще происходит. Почему так происходило? Потому что компьютеры были «глупые» и ничего более «умного» понять не могли. Изображение с сайта devdelphi.ru На этом этапе порог вхождения в программирование был чрезвычайно высок. Производительность программиста в этих командах была предельно низкой — то есть он писал несколько строк в день (осмысленных), и каждая строка ничего особо и не делала — какие-нибудь простые арифметические действия. И людям хотелось сделать языки гораздо более похожими на человеческий язык, на английский в частности, чтобы писать программы было легче и удобнее. Уровень выше — порог ниже С появлением языков программирования высокого уровня жизнь программистов становилась легче, а производительность – выше. Программы не нужно было переписывать для каждой машины. Появились компиляторы, среды разработки. Fortran, Algol, а позже BASIC, PASCAL, C действительно были больше похожи на «человеческий» язык. Конечно, по-прежнему требовалось значительное время на их изучение, но это было более выгодное вложение времени и сил. В процессе работы компилятор указывал программисту на синтаксические ошибки в его коде, что в особенности облегчало разработку начинающим специалистам. С появлением модульности и переносимости кода проекты стали больше, а программисты начали широко использовать в проектах сторонние библиотеки, больше работать в командах. Это избавило их от необходимости подробно разбираться в том, как работает весь проект. С появлением объектно-ориентированного программирования (С++, Object Pascal и так далее) тенденция повторного использования кода усилилась. Кроме того, со временем среды разработки становились более дружественными, и желающих освоить азы программирования становилось больше. Программирование — в массы Постепенно программирование перестало быть прерогативой хардкорных инженеров и математиков. Число проектов стремительно росло, программное обеспечение проникало в разнообразные сферы производства. Этому также способствовало и развитие систем управления базами данных. Появились даже такие специализации как «оператор СУБД». Постепенно понятие «инженер-программист» стало многогранным: кто-то занимался алгоритмами, кто-то проектировал интерфейсы, кто-то просто занимался кодированием – то есть реализовывал в коде готовые алгоритмы своих коллег. Само программирование стали делить на две крупные группы – системное и прикладное: кто-то разрабатывал операционные системы и драйверы, а кто-то писал приложения для автоматизации бизнес-процессов на овощной базе. Для каждой из специализаций требовались индивидуальные компетенции, поэтому переход от одной специализации к другой был затруднителен. Но минимальный порог вхождения в разработку ПО стремительно снижался. Появление языков (Java, C#) и соответствующих фреймворков еще больше способствовало этому снижению, а также дифференциации специалистов по направлениям и уровням подготовки. В результате у программистов закрепилась градация наподобие [Junior-разработчик, Senior/Middle, Team Lead, Software Architect]. С одной стороны, продвинутый инструментарий разработки позволял менее квалифицированным программистам успешно справляться с относительно простыми задачами, не имея глубоких знаний и серьезных навыков. С другой стороны, с каждой последующей ступенью карьерной лестницы порог вхождения также становился выше. Изображение с сайта Но если специалист задерживался в статусе начинающего, он мог заметить одну особенность: бурно развивающиеся технологии разработки ПО еще сильнее снижали порог вхождения, и среднестатистический Junior урожая N-го года знал и умел еще меньше, чем его старший товарищ — Junior (N — k)-го года. Веб-разработка методом «тяп-ляп» С развитием веб-разработки программистам потребовалось встать на другие рельсы (ассоциация с Ruby On Rails здесь тоже уместна), чтобы освоить новые языки и стек интернет-технологий разработки в целом. После того как веб-разработка, начавшая набирать обороты только в 90-х годах, совершила огромный скачок в развитии, Михаил Густокашин может свободно пускаться в подобные рассуждения: Допустим, вы хотите написать новый Facebook (социальную сеть). На чем вы будете это писать? HTML, CSS — это дизайн, а мы хотим, чтобы там можно было фотографии добавлять, друзей, комментарии оставлять. Для скриптовой части — то есть то, что будет происходит на стороне клиента, — это JavaScript. На удивление, он написан на PHP — и Facebook, и многие другие большие проекты. Пришлось, конечно, написать свои какие-то вещи, чтобы это всё-таки работало нормально, а не так как «тяп-ляп» было сделано, но они справились. Здесь и сейчас, понятное дело, с нуля уже для веба никто ничего не пишет. Все ищут какой-нибудь фреймворк или ещё чего-то. Интернет-магазин? Скачали фреймворк для интернет-магазина — ну и всё, написали интернет-магазин. Стоит отметить, что и поначалу порог вхождения в веб-разработку был ниже, чем в Desktop. После появления фреймворков он снизился еще сильнее. На волне автоматизации Получается, что раньше сайты писали «руками», а теперь это стало необязательно во многих случаях. Более того, для создания тех же интернет-магазинов уже нет надобности даже в использовании фреймворков: теперь есть конструкторы сайтов. Теперь веб-программисты, не обремененные квалификацией, которые раньше получали легкие деньги, создавая однотипные сайты, могут превратиться в операторов-конфигураторов. Все потому, что в чьи-то светлые головы пришла идея автоматизировать процесс веб-разработки. Хотя, на самом деле, идея не нова, так как она уже частично была реализована во многих инструментах разработки ПО под Desktop-платформы в виде автогенерации форм и целых слоев приложения – например, генерация классов по структуре базы данных. Если индустрия будет развиваться в том же русле, то все больше кодеров (программистов, находящихся в начале пути либо имеющих невысокую квалификацию) получат возможность превратиться в операторов-конфигураторов. Использовать такую возможность или нет, каждый решит для себя сам. Мы выяснили, что по этому поводу думают эксперты, представители ИТ-индустрии: Алексей Бычко, старший релиз-менеджер (Percona), разработчик проектов Percona Server for MySQL, Percona XtraDB Cluster, Percona XtraBackup, Percona Server for MongoDB, PQuery, преподаватель курса «Системное администрирование» в ИТ- Академии Алексея Сухорукова: Появляется всё больше и больше сред для автоматизации рутинных вещей – это помогает лишний раз не писать что-то вручную, не изобретать велосипедов. Многое уже предусмотрено в интегрированных средах разработки, из которых можно вызывать нужные библиотеки и так решать стандартные задачи. Для тех, кто умеет и привык думать, это хорошо – можно сконцентрироваться на основном, на логике приложения. (Это люди «старой школы», которым для написания качественного кода хватит и простейшего текстового редактора). Плохо, что растёт число быдлокодеров, которые, в принципе, могут решить поставленную задачу, собрать что-то из имеющихся «кубиков», но не представляют, как что работает внутри, и не могут оценить, насколько оптимален чужой готовый код. По этой причине я бы хорошего программиста именно «кодером» называть не стал – код сейчас пишут даже младшие школьники, его и машина сгенерировать может. Программист думает, изобретает, устанавливает зависимости, задаёт пути, проектирует архитектуру – а потом он всё это может отдать кодеру на реализацию. По сути, это два подхода, которые выросли из факта наличия проективных Unix-подобных систем и процедурных Windows-подобных. Огромной корпорации, где всё разбито на мельчайшие подзадачки, важна воспроизводимость результата, а не оптимальное решение – если оператор ушёл, нужно, чтобы новый по инструкции делал то же самое и не хуже. Но если у нас есть задача, которая конкретной процедурной системой, библиотекой или средой решается плохо или не решается вовсе (коллеги постарше помнят, что бывает, когда в написанный в C++ Builder или Delphi текстовый редактор попадает большой файл – ничего не листается и всё тормозит, и это никак не поправить), то нам нужно взять «чистую» систему, которая даёт больше свободы, и позвать программиста, который согласен не просто гуглить, а писать адекватное решение самостоятельно с нуля. Олег Бунин, основатель компании «Онтико», организатор конференций Highload++, РИТ, FrontendConf, RootConf, WhaleRider, AppConf, Backend Conf. Как организатор крупнейших в России конференций для разработчиков я вижу специализацию, упрощение рутинных процедур, но мозги и глубокое понимание происходящего востребованы не меньше, а даже больше, чем раньше. С появлением автоматизирующих разработку инструментов ценность людей, которые понимают, что происходит под капотом таких инструментов, растёт. Требования, которые к ним предъявляются, растут. Объём знаний, который нужно освоить, растёт. Конечно, речь идёт не о создании лендингов, а о разработке мало-мальски серьёзного проекта. Макс Лапшин, создатель ErlyVideo, создатель Flussonic, разработчик многих известных решений в области стриминга видео. Первый раз сообщения о том, что всё, что надо было написать, уже в целом написали, и теперь программисты просто будут собирать кубики из готовых компонент, и вообще, наверное, программировать мышкой, я услышал году примерно в 1995. Как несложно догадаться, с 1995 года по сегодня было написано безумное количество адского хардкорного системного кода, и возникло и умерло немало больших бизнес-платформ, на которых даже что-то было напрогано «мышкой». Честно говоря, я даже ни разу не встречался с задачей, которую можно было бы напрогать «мышкой», не влезая до дна, но я не имею ровным счетом никакой связи с энтерпрайзной аутсорс-разработкой в стиле «Люксофта», поэтому не знаю, как оно у «них». Всё дело в том, что индустрия идет вперед. Да, на компьютерах больше не 640 КБ памяти, и программисту под Windows больше можно не волноваться о памяти вообще. Но на замену большим компьютерам пришли маленькие, и их много. Сегодня всё равно приходится думать, как записать на прошивку IP-камеры софт, упихнувшись в 200 КБ на диске. Приходится думать, как упихнуть код в маленький IOT-сенсор, который должен на своей крохотной батареечке прожить год с радиообменом. Индустрия очень стремительно расширяется, и в ней появляется место людям, которые не очень глубоко разбираются в деталях работы ЭВМ, но безусловно: сегодня людей, которые знают, как работает, например, DMA, нужно больше, чем 10 лет назад просто потому, что индустрия до сих пор растет. Александр Лямин, основатель и CEO компании Qrator Labs, одного из ведущих мировых поставщиков в области защиты от DDoS-атак. Есть такая шутка: отдел программирования — это такой завод по производству холодильников, в котором работает 10 человек, один из которых может делать звездолёты, а остальные девять человек умеют клепать скворечники. Так вот, программисты нужны в компаниях совершенно разного толка. Какие-то компании производят холодильники, какие-то — клепают скворечники, а некоторые, как SpaceX, действительно разрабатывают звездолёты. Поэтому пропорция 1:9, естественно, не догма, она везде будет своя. Где-то, действительно, достаточно нескольких кодеров в штате. Где-то нужны уже хорошие прикладные программисты — люди, обладающие алгоритмическим багажом и способные грамотно его применять. В ряде случаев требуется уже даже не столько программист, сколько computer scientist — человек способный не только, как минимум, грамотно модифицировать алгоритмы под нужды конкретной ситуации и задачи. Следующий уровень — это data scientist, хороший прикладной математик. Продолжая аналогию, скворечник можно склепать из общедоступных стройматериалов, но сплавы для ракеты на строительном рынке уже не купишь. На этом уровне задача уже начинает выглядеть примерно так: вот проблема, вот массив данных, нужны гипотезы-алгоритмы-PoC и, как следствие, постановка задачи для реализации. И в процессе создания действительно хороших продуктов — рано или поздно, так или иначе — задачи нетривиальной обработки данных возникают неизбежно. То есть человек-«кодер» решает лишь часть проблем, стоящих перед разработкой. Естественно, действительно высококлассных программистов на рынке труда мало, а задач для них много, поэтому очень давно возникла идея: разработать инструментарий, с помощью которого специально обученный оператор ЭВМ сможет справиться с задачами высокой сложности. Но все попытки сделать это, можно сказать, провалились. Язык SQL был разработан изначально для того, чтобы им мог воспользоваться любой пользователь, даже не имеющий навыков программирования. Сейчас этим языком пользуются программисты, а операторы ЭВМ даже после тренингов не в состоянии написать даже более-менее простой запрос. Другой пример — всевозможные среды визуального программирования, предназначенные, грубо говоря, для того, чтобы оператор мог не писать код, а нарисовать адекватную задаче блок-схему, на основе которой компилятор выберет нужные алгоритмы. Ни одна из таких сред (а их было много) в конечном счёте не получила распространения. Это говорит о том, что изначальная задача, возможно, поставлена неправильно или не имеет решения в такой постановке. Закон дырявых абстракций свидетельствует: рано или поздно в процессе добросовестного решения прикладной задачи приходится опускаться на уровень ниже, чем позволяет практически любой прикладной инструмент. Поэтому вряд ли когда-нибудь кому-нибудь удастся превратить программиста в оператора ЭВМ окончательно.

Метки:  

Intel Media SDK 2016 R2 — что нового?

Среда, 15 Июня 2016 г. 19:17 + в цитатник
Увидела свет новая версия комплекса средств для разработки ПО кодирования и воспроизведения медиа контента Intel Media SDK 2016. Обновление содержит ряд существенных изменений: Добавлена поддержка процессоров Intel Core седьмого поколения (Kabylake); Улучшена работа Media RAW Accelerator для обеспечения гибкости и производительности; Добавлены новые возможности при кодировании AVC/H.264 для видеоконференций и облачных игровых сервисов; Добавлены новые VPP-фильтры и улучшены существующие; Внедрена новая версия API c улучшениями в управлении памятью и функционалом запроса платформы; Внедрена поддержка Windows Redstone Preview. Под катом — краткий обзор текущей функциональности Intel Media SDK 2016. Полное аппаратное ускорение для HEVC и VP9. Поддержка 10-битного HEVC енкодера и декодера Поддержка 8-битного и 10-битного декодера VP9 AVC енкодер: добавлены ограничения Slice Size и функционал отчетов для обеспечения низких задержек, требуемых при использовании протокола RTP. Разработчики могут использовать этот функционал для лучшего согласования видео потока с пропускной способностью канала связи. Media RAW Accelerator: с целью повышения производительности Media RAW Accelerator распространяется с графическим драйвером, таким образом, его сейчас не требуется включать в приложение. Добавлена поддержка ввода в формате 16-бит ARGB, к которому могут применяться фильтры Gamma Correction, Chroma Aberration, 3DLUT и Les Geometry Correction. Теперь разработчики в своих приложениях могут с легкостью применять фильтры к картинке с примененным дебайером или настроить свои собственные блоки пост-процессинга путем добавления их в конвейер обработки, как показано на рисунке. VPP-расширения: разработчики могут использовать матрицы преобразования цветов bt.601 или bt.709, видео различных диапазонов с функцией Videosignal Info. С конвейером Scaler & Format Converter (SFC), доступным начиная с шестого поколения процессоров Intel Core (Skylake), могут использоваться новые режимы масштабирования, когда во время операции Media SDK рабочая нагрузка снята с инструмента рендеринга и более не заблокирована. Таким образом, разработчик может точнее управлять исполнительными блоками GPU для других нагрузок во время обработки. Улучшения для более простой работы с API: в API 1.19 добавлена функция запроса платформы; с помощью нового API приложение теперь может определить аппаратную платформу, на которой оно исполняется. Для повышения производительности памяти ее выделение было оптимизировано для 3D и OpenCL конфигураций.
Анализируем как успешное трудоустройство и зарплата зависят от вуза, специальности и региона

[recovery mode] Как стать тестировщиком или каких знаний мы ждём от джуниора

Среда, 15 Июня 2016 г. 06:40 + в цитатник
Пара вводных слов Всем доброго времени суток, меня зовут Туманов Дима. Сейчас я работаю в компании Rambler&Co и отвечаю за тестирование на проектах Афиши. В рамках данной статьи я развею несколько мифов об IT и тестировании в частности. Кроме того, приведу примеры из жизни как “не зная ничего” стать Junior QA Engineer в крупной компании. Начало пути Проработав почти два года в одной “мирной” госкорпорации в должности “ненастоящего инженера”, я осознал, что развитие остановилось. Я мог сидеть на одном месте и почти ничего не делать. В конечном итоге мои знания бы совсем отстали от реальной действительности и я бы стал невостребованным на рынке. В этот момент я принял решение о смене места и сути своей работы. Вопрос №1 — “Какую область для работы выбрать” Мой выбор основывался на нескольких фактах. Во-первых я хотел работать в быстро развивающейся отрасли. В этом я видел и вижу сейчас возможность постоянно расти в профессии, развивая себя в различных направлениях. Во-вторых я хотел уйти от бюрократии, жёстких регламентов и обязательного ношения костюмов жарким летом. Ну и последнее, но не по значению, я хотел делать действительно важное дело, ощущать близость конечного пользователя, понимать, что моя работа действительно нужна. Все три этих пункта я смог увидеть в IT-отрасли. Вопрос №2 — “Какую профессию выбрать” Для меня важным было некое совмещение гуманитарных и технических наук, то есть коммуникаций и инженерии. С одной стороны я не хотел быть только техническим специалистом и например писать лучший код на Java. С другой я хотел понимать как всё устроено изнутри. По этим причинам мой выбор пал на тестирование. Дополнительно к смежности профессии, описанной выше, в тестирование довольно просто попасть. Порог входа действительно небольшой. Вопрос №3 — “Какую компанию выбрать” По сути все компании можно классифицировать несколькими способами. Во-первых по отношению заказчик-разработчик. Есть принципиальная разница между компаниями аутсорсерами и продуктовыми компаниями. Для первых самым важным является продажа продукта. Да, есть имя компании, отзывы клиентов, но так или иначе заработок идёт от прямых продаж. Для вторых важным является иметь качественный и популярный продукт. На таком продукте можно разместить дорогую рекламу и заработать много денег. Поэтому с точки зрения тестирования сильная команда будет сформирована именно в продуктовой компании. Во-вторых компании стоит разделять на русские и импортные. На текущий момент тестирование остаётся слабо развитым направлением в России. Это даёт свои плюсы и оставляет возможность занять своё место под солнцем без сильных проблем. Но, с другой стороны, сужает выбор достойных мест для работы. Благо в крупных интернет компаниях рунета уже “пройден этап варварства и созданы первые государства”. Для меня было важно работать именно в русской компании. Это что-то вроде “странного” патриотизма, если хотите. Исходя из всего этого мой выбор пал на крупные продуктовые интернет компании России. Таких кстати совсем немного и вы легко можете найти их рейтинг в Forbes (2014, 2015, 2016). Вопрос №4 — “Как решить проблему отсутствия опыта” Парадокс подавляющего числа компаний заключается в необходимости опыта даже для начальных предложений. Ответ на вопрос как они вообще себе такое представляют я не нашёл до сих пор. Благо в неразберихе рождается всё новое и многие построили бизнесы на этой истории. Сеть сейчас кишит различными обучениями с практикой, среди которых есть действительно стоящие. С остальными знаниями, которые нужно приобрести, вроде без эксцессов, поэтому давайте обо всём по порядку. Вопрос №5 — “Какие знания нужно получить и как это сделать” Погружение в теорию тестирования. В первую очередь нужно научиться говорить на языке IT и тестирования в частности. Для этого необходимо разобраться с тем, что такое обеспечение качества и с основными понятиями из тестирования ПО. Данные материалы можно раскопать почти в любой книге по тестированию, но я ярый противник “технических” талмудов и считаю их медленным источником информации. Намного проще и быстрее это сделать из отдельных статей: Что такое обеспечение качества Что такое тестирование Какие виды тестирования бывают Какие уровни тестирования бывают Какие тестовые артефакты есть и зачем их используют Что такое тест дизайн Как должен выглядеть процесс тестирования в вакууме Что такое автоматизация тестирования и её основные виды Какие метрики тестирования бывают и зачем они используются Изучение Bug Tracking систем. Ключевым навыком инженера по тестированию является поиск, локализация и качественное заведение дефекта. Баг не существует в вакууме, он чётко связан с разделом программы, воспроизводится на списке конфигураций (операционная система и её версия, браузер и его версия), имеет свой приоритет. Более того работу над исправлением дефекта проводят несколько разных специалистов. Для того чтобы сделать процесс управления починки дефекта управляемым используют специальные системы. Здесь есть иллюзия выбора. Есть широко распространённый Redmine. Но если вы нацелены на работу в компании, указанного выше класса, то вам стоит изучать Jira. Для этого рекомендую сделать следующее: Поставить себе пробную версию продукта и пройти эти ролики Поставить себе и изучить базовые гаджеты: 1, 2, 3 Изучение Test Management систем. Любой софт — это по сути набор возможностей, то есть так или иначе конечное множество. При этом логика работы каждой из них не является идеальной моделью, а значит количество багов в системе всегда бесконечно. Вопрос в том что мы считаем багом, а что нет. Тут на помощь нам приходят требования от заказчика, описывающие то каким должен быть наш продукт. В качестве требований не обязательно должно быть техническое задание на тысячу страниц. Это также может быть прототип или постоянное живое обсуждение, если ваш продукт это просто новая доработка. Для перевода требований в набор проверок существуют методы из теории тестирования, которые вы уже должны были изучить выше. Но тесты, как и дефекты не существуют в вакууме и над одним функционалом может одновременно работать несколько специалистов по тестированию. По аналогии для управления процессом написания и применения тестов используют специальные системы. Лихие 90-е ушли и работа в “эксельках”, “блокнотиках” и “тестлинках” уже не является нормальным явлением. Недавно я проводил аудит по поиску подходящей системы. В основном они либо ничего не делают, либо стоят как космолёт. Золотой серединой является TestRail. Для его изучения нужно сделать следующее: Поставить себе пробную версию и пройти эти ролики Поднятие технического бэкграунда. Мы занимаемся web и mobile приложениями, поэтому рассуждение пойдёт в этом ключе. Настоящий тестировщик обязан понимать “начинку” того, что он проверяет. Это экономит время команды, так как специалист по тестированию сам может определить истинную причину дефекта и описать её правильно. Да и тестировать то, о чём ты ничего не знаешь как минимум странно. Плюс глубокое понимание улучшает ваши коммуникации с другими техническими специалистами. Для старта хватит этих общих знаний: Как устроен интернет Что такое backend и frontend Что такое http запрос Как работать с консолью браузера Изучение программирования. Извечный вопрос нужно ли уметь программировать тестировщику имеет очень простой ответ. Нужно. Связано это с тем самым техническим бэкграундом во-первых и с развитием аналитичности вашего мышления во-вторых. На начальном этапе достаточно иметь базовые представления о программировании, в будущем для качественного роста вам потребуется изучить один из популярных языков. Например, Python или Java. На старте стоит изучить следующее: Самые базовые знания по программированию Основные языки программирования Основные термины в программировании Преодоление преграды отсутствия опыта. В IT-отрасли сейчас сильная нехватка кадров, в частности тестировщиков, поэтому часто берут перспективных кандидатов без опыта. Действительно, проще научить с нуля, чем переучивать. Для того, чтобы стать более востребованным по сравнению с другими стоит пройти специализированные курсы по тестированию. На них можно получить структурированные знания и самое главное опыт реального тестирования. Я рекомендую пройти курс “Школа успешных тестировщиков, v 2.0)” с этого портала Поиск работы. Дальше остаётся только составить резюме, учитывая обновлённые знания и навыки, и научиться грамотно использовать hh Перспективы развития Работа занимает треть нашей жизни. Если отбросить сон, то это вообще половина нашего времени. Единственно правильным считаю работать там и делать то, что действительно нравится. Помимо морального удовлетворения есть и материальные блага. Уровень зарплат по официальным источникам даже на старте превышает среднюю температуру по больнице. Наличие ДМС, скидки на фитнес или наличие зала внутри компании, бесплатные билеты на различные мероприятия и прочие бонусы конечно же присутствуют. К тому же работа оценивается по количеству сделанной работы, а никак не по проведённому на ней времени. В IT всегда гибкий график и “опоздание на 15 минут” никак не будет наказываться. Более того, на это даже никто не обратит внимание, потому что это действительно нормально. Роль тестировщика — это не окончание вашего движения, это лишь точка входа. После пары лет хорошей практики в тестировании вы сможете выбрать любой путь развития в компании. Почему я уверен в вашем успехе Как когда-то сказал Стив Джобс: “Нельзя соединить точки жизненного пути, смотря вперёд. Их можно соединить, только оглядываясь в прошлое”. Именно этот принцип и даёт мне уверенность в том, что стать тестировщиком и начать получать удовлетворение от работы может абсолютно каждый. Есть и другие примеры за последние несколько лет, которые только подтверждают доступность данной профессии. У меня был некий Challenge Accepted. В какой-то момент ко мне почти одновременно обратилось два человека, которых я очень хорошо знал. Один из них на тот момент работал в правоохранительных органах, другой был профессиональный военным. Схожесть ситуации была на лицо. Они большие молодцы и с большой настойчивостью проходили примерно описанный выше план. Такое самообучение и поиск самой работы у них заняло порядка трёх-четырёх месяцев. Сейчас они работают тестировщиками, имеют перспективы для развития, гибкий график и думаю много чего в их жизнях ещё изменилось. Post Scriptum Ещё раз подчеркну. Войти в данную профессию не сложно. Это сможет каждый. Дальнейшее развитие в IT зависит уже только от вас.

Метки:  

Анализируем как успешное трудоустройство и зарплата зависят от вуза, специальности и региона

Суббота, 11 Июня 2016 г. 00:58 + в цитатник
Привет, Хабр! В 2014 году мы совместно с несколькими министерствами и ведомствами дали старт мониторингу трудоустройства российских вузов, результаты которого были опубликованы в 2015 году на портале http://graduate.edu.ru/. Мониторинг проводился среди выпускников 2013 года (у них было достаточно времени, чтобы найти работу). Сейчас идет работа над мониторингом выпускников 2014 года и мы решили рассказать вам о целях и результатах прошлогоднего проекта. Если вам интересно узнать, как размер зарплаты и успех трудоустройства зависит от вуза, специальности и региона, добро пожаловать под кат. В первой части статьи мы расскажем о целях, методике мониторинга и исходных данных. Если вам интересны только результаты, то можно сразу перейти в одноименный раздел. Цель Цель мониторинга – оценить трудоустройство выпускников в следующих разрезах: Вуз; Специальность (направление подготовки); География трудоустройства. При этом оценивались два основных параметра: Доля трудоустройства (сколько процентов выпускников смогло найти работу); Уровень средней заработной платы. Такая аналитика нужна, например, непосредственно Минобрнауки, чтобы оценивать эффективность работы вузов. Трудоустройство выпускников не единственный, но важный критерий такой оценки. Во-вторых, результаты могут быть полезны выпускникам школ и их родителям. О том, как выбрать школу, на Хабре недавно писали. Получается, наши сведения актуальны для тех, кто чуть старше, особенно в свете грядущей вступительной кампании. Методика Вообще говоря, исследования на эту тему не такая уж редкость. Во многих вузах есть службы, анализирующие дальнейшую судьбу выпускников. Различные СМИ и ресурсы интернет-рекрутмента также любят порадовать подобной статистикой. И это замечательно. Но данное исследование принципиально отличается от них в следующем: Масштаб – в мониторинге участвовали практически все вузы России. На момент мониторинга имелись данные о 1 240 532 выпускниках 2013 года с указанием ФИО, возраста, пола, специальности, квалификации и других, не очень нам интересных, атрибутов. Источники данных – Использовались данные ПФР о трудоустройстве и размере заработной платы. Визуализация – Удобное и доступное представление результатов на портале http://graduate.edu.ru/. Мониторинг состоит из нескольких этапов: 0) На «нулевом» этапе все вузы обязаны заносить информацию о выданных дипломах в федеральную ИС ФРДО. Кстати, каждый выпускник может проверить наличие информации по нему в этом реестре frdocheck.obrnadzor.gov.ru. Данным сервисом могут пользоваться и работодатели. Если вы себя там не нашли – крайне рекомендуем написать в свой вуз об этом. 1) На первом этапе из данных ФРДО были отобраны все вузы (кроме силовых, зарубежных и тех, чьими учредителями являются религиозные организации). 2) На втором этапе Рособрнадзор проверяет и обрабатывает полученные сведения по каждому выпускнику (в защищенном контуре ФРДО). Исключаются данные о продолживших обучение студентах (допускаем, что если человек продолжает учиться дальше, то это уважительная причина не искать работу). У всех выпускников должны быть верно заполнено: ФИО, пол и дата рождения, иначе ПФР не сможет их идентифицировать. После этого данные группируются в пакеты и передаются в Пенсионный фонд России для обработки. Каждый пакет соответствует уникальному сочетанию следующих разрезов: вуз, специальность, квалификация, пол. Фактически это и есть группа выпускников, закончивших вуз по одной специальности. 3) На третьем этапе Пенсионный фонд России определяет, был ли трудоустроен выпускник согласно официальным данным (произведено хотя бы одно отчисление в Пенсионный фонд за год или открыто ИП), а также, сколько всего в среднем заработал выпускник за время работы суммируя эти данные в разрезе каждого пакета. 4) ПФР передает данные о трудоустройстве и уровне заработных плат по каждой группе, т.е. в обезличенном виде (понять, сколько конкретно получает ваш бывший одногруппник – нельзя). Все эти данные анализируются и загружаются на Портал. Для тех, кто запутался, методика приведена на отдельном рисунке: Рис. 1 На основе полученных из ПФР данных рассчитываются два основных показателя: Доля трудоустройства. Это отношение числа трудоустроенных выпускников к общему числу выпускников вуза за вычетом «ошибочных» и не найденных ПФР. Итоговая формула будет выглядеть так: , где Ктд – число трудоустроившихся выпускников, Ко – общее число выпускников, отобранных на 1 и 2 этапах, Кош – число выпускников с неверными данными, например пустая дата рождения, Кнпфр – число выпускников, которых не смог однозначно идентифицировать ПФР (полные тезки по ФИО, полу и дате рождения) Кино – число выпускников – граждан иностранных государств (применимо только для вуза и более общих разрезов – тип вуза, регион вуза и т.д.). Величину Ко-Кош для удобства будем называть «число допущенных к обработке». При расчете доли трудоустройства в целом по вузу или региону так же вычитаются студенты-иностранцы (для них использовать данные отечественного ПФР не совсем корректно). В разрезе специальностей такие данные в этом мониторинге собрать не удалось, поэтому для них доля трудоустройства рассчитывается без вычета иностранцев. Уровень средней заработной платы. На самом деле это не только заработная плата. Это все деньги, официально заработанные выпускником (зарплаты, премии и т.д.) за весь календарный год, следующий за годом выпуска (то есть для выпускников 2013 года анализировались выплаты за весь 2014 год). Средняя зарплата считается как этот суммарный доход, разделенный на количество месяцев, которые проработал выпускник в 2014 году. Особенности методики Очевидно, что у такой методики (как и у любой другой) есть как плюсы, так и минусы. Минусы очевидны: Учитывается только официальное трудоустройство (если выпускник стал фрилансером, но не оформил ИП, то он будет считаться нетрудоустроенным); Учитываются только официальные доходы (подработки и серые зарплаты не попадут в данные ПФР); Не отслеживается факт соответствия выпускной специальности и сферы трудоустройства (шутка про гуманитариев и Макдональдс). Все эти минусы довольно сложно устранить, если ограничиться официальными источниками данных. Теоретически можно попытаться получить их с помощью анкетирования/опросов и т.д. Но, во-первых, это привнесет свои искажения в данные (на тему искажения респондентами своего уровня доходов написана не одна сотня статей), во-вторых, в масштабах России для получения репрезентативной выборки по всем нужным разрезам это было бы сопоставимо с мини-переписью населения. К счастью, минусы являются одновременно и плюсами. Главное достоинство методики в том, что выборка практически сплошная (за вычетом продолживших обучение выпускников и данных, предоставленных с ошибками). А значит, минимизируется ошибка репрезентативности, так как мы работаем почти напрямую с генеральной совокупностью. К сожалению, это был первый проект мониторинга и в нем не были учтены некоторые факторы: форма обучения (очное/заочное), первое или второе высшее, форма оплаты. Все это учтено в мониторинге выпускников 2014 года, который сейчас идет полным ходом. Входные данные Всего вузов, участвовавших в мониторинге — 933 (без учета филиалов): Рис. 2 (интерактив) Не все из них сдали корректные данные (по разным причинам с этим в основном не справились «частники»): Рис. 3 (интерактив) Итого у нас получилось 819 вузов, которые предоставили данные о 1 240 532 выпускниках: Рис. 4 (интерактив) Давайте посмотрим, как выпускники распределены по типам вузов (число выпускников будем рассматривать с учетом филиалов, если не указано обратное): Рис. 5 (интерактив) Как видно, процентные соотношения по сравнению с Рисунком 4 уже другие. Но это вполне логично – среди государственных вузов много крупных, среди частных – гораздо меньше. Каждый выпускник обучался по направлению, относящемуся к одной из укрупненных групп направлений подготовки (специальностей), сокращенно – УГС. Например, «машиностроение», «экономика и управление» и т.д. Таких УГС больше 50. Чтобы не приводить здесь такую «простыню» (мы на нее еще насмотримся позже), сгруппируем данные по типу УГС. Классификация довольно условная, но именно такая разбивка присутствует в различных нормативно-правовых актах в России. Рис. 6 (интерактив) На самом деле экономика и юриспруденция входят в «науки об обществе», но их показатели были так велики (35% всех выпускников – «экономисты»), что пришлось выделить их в отдельные категории. Около 3% выпускников продолжили обучение, еще 0,4% данных оказались некорректными (в основном неверные или незаполненные даты рождений) и в обработку «ушли» уже 1 198 276 человек. Их данные и послужили основой для результатов, изложенных ниже. Результаты Учитывая объем массива данных, его анализ можно выполнять для огромного количества разрезов и проверять на его основе множество гипотез. Поэтому здесь мы приведем только некоторые результаты анализа. Это лишь малая часть того, что можно получить, изучая данные мониторинга. Для тех, кто хочет самостоятельно поработать с данными (или просто посмотреть на свой родной вуз) – подробные результаты по всем вузам можно увидеть на нашем портале. Там же после регистрации (зато без СМС) можно скачать эти данные в Excel-формате: Рис. 7 В этой статье не будем рассматривать данные в разрезе вузов – информация по ним есть на портале, да и места для такого анализа здесь не хватит. Скажем лишь, что на первых местах небольшие и не самые известные вузы. В этом нет ничего странного: чем меньше вуз, тем больше у него шансов показать сильно отклоняющийся от средних значений показатель. Перед тем, как перейти к непосредственному изложению результатов – небольшая ремарка для тех, кто нечасто имеет дело со статистикой. В общем случае, когда речь идет о статистических закономерностях, мы не можем говорить о том, что является причиной, а что следствием. Если выпускники престижного вуза NN имеют хорошие доходы и легко находят работу, это не значит, что в этом обязательно заслуга вуза. В престижные вузы поступает много талантливых и способных учеников, вполне вероятно, что они достигли бы таких же или еще больших высот, обучаясь в другом вузе. Ответ на такие вопросы – тема отдельного большого исследования. Результаты анализа Для начала посмотрим на результат трудоустройства и заработную плату по типам вузов: Рис. 8 (интерактив) Отчасти ожидаемый результат: согласно статистике, в государственных вузах с точки зрения трудоустройства учиться лучше, чем в условной «Академии Натальи Нестеровой» (не в обиду выпускникам этого вуза). Впрочем, на уровне заработной платы это не очень сильно сказывается. А вот муниципальные вузы «проседают». Возможно, потому что все они сосредоточены в регионах, где уровень зарплат ниже, чем в Москве или Санкт-Петербурге. Теперь приведем этот же график, но уже в разрезе специальностей (точнее, «УГС» – укрупненных групп специальностей): Рис. 9 (интерактив) В таблице приведен столбец с числом выпускников по каждой УГС, чтобы можно было оценить число трудоустроившихся студентов не только в процентах, но и в абсолютных цифрах. Как вы помните, вне конкуренции по числу выпускников экономически-управленческие специальности. В тройку лидеров также входят педагоги и юристы. При этом если экономика и педагогика еще держатся в середине «турнирной таблицы» по уровню трудоустройства, то юриспруденция – однозначный аутсайдер. Если же смотреть на абсолютные цифры, то около половины всех нетрудоустроенных выпускников – это юристы и экономисты: Рис. 10 (интерактив) При этом различия в результатах поиска работы между представителями этих двух специальностей и остальными выпускниками статистически значимы ( Обратите внимание, что по уровню трудоустройства лидируют специальности технического, медицинского и естественнонаучного профиля. Среди отстающих в основном «гуманитарии» и творческие специальности. По зарплате лидируют следующие специальности: Аэронавигация и эксплуатация авиационной и ракетно-космической техники – 69 470 рублей. Это неудивительно, учитывая зарплату летчиков гражданской авиации в России. Прикладная геология, горное дело, нефтегазовое дело и геодезия – 48 290 рублей. Учитывая сложившуюся ситуацию, интересно будет посмотреть на эту отрасль в динамике следующих лет. Ядерная энергетика и технологии – 43 460 рублей. А вот это приятный сюрприз. Физическая культура и спорт – 42 700 рублей. Вряд ли детские тренеры и другие специалисты в этой области получают высокие зарплаты, но для того, чтобы поднять среднее значение достаточно и небольшого числа профессиональных футболистов/хоккеистов, получающих баснословные гонорары. Экранные искусства – 41 150 рублей. Вероятнее всего, ситуация аналогична описанной в предыдущем пункте. Любопытно будет посмотреть на специальности одновременно и с точки зрения доли трудоустройства, и с точки зрения заработной платы. То есть выявить «дважды лучшие» и «дважды худшие». Для этого отберем УГС, по которым средняя зарплата и уровень трудоустройства будут ниже (для «худших») или выше (для «лучших») 15-го и 85-го процентиля распределения этих величин соответственно. Такое деление условно, но для наглядности ограничимся им (более детальный анализ можно провести, используя вышеприведённую таблицу и данные портала). На следующем рисунке «худшие» и «лучшие» специальности выделены красным цветом и подписаны: Рис. 11 Так что если вы абитуриент и после окончания вуза не хотите иметь проблем с трудоустройством и зарплатой, идите в физики-ядерщики :-) Перейдем к еще одному немаловажному показателю – географии. Вузы каких регионов имеют лучшие показатели трудоустройства? Для удобства будем учитывать только головные организации, так как в общем случае неясно, чьим вузом считать Владивостокский филиал московского вуза – московским или все же дальневосточным. Учет географии филиалов – тема отдельной статьи. Рис. 12 (интерактив) Как видно, наибольшие проблемы с показателями трудоустройства в основном у вузов Северного Кавказа. Если посмотреть на список регионов вузов с худшими показателями трудоустройства по РФ, мы убедимся в этом еще раз: Рис. 13 (интерактив) Тут стоит отметить и высокий уровень безработицы в данных регионах. Согласно данным Росстата, в СКФО он в два раза выше, чем в среднем по стране. Но нельзя однозначно сказать, что является причиной, а что следствием. Безработица может быть вызвана малым количеством вакантных рабочих мест, а может – низким качеством специалистов или нежеланием жителей регионов устраиваться на (официальную) работу. Раз уж речь зашла о географии, мы хотим затронуть тему трудовой миграции. Более подробные данные по миграции выпускников вуза или региона, в том числе уровни зарплат уехавших/оставшихся можно посмотреть на портале в перечне регионов http://graduate.edu.ru/registry#/?slice=6. Взгляните на карту, на которой указан процент выпускников, уехавших из региона (по отношению к общему числу трудоустроившихся выпускников этого региона). На этот раз филиалы участвуют – их выпускников учитываем как выпускников региона, где физически расположен филиал: Рис. 14 (интерактив) Чтобы выяснить конкретные причины высокого оттока выпускников, необходимо анализировать каждый регион отдельно. Для многих соседствующих регионов складывается схожая ситуация: выпускники массово уезжают из «выпускающего» региона в соседний. Возможно, это просто возвращение выпускников домой после окончания учебного заведения. А может быть, соседний регион просто ближайший, в котором легко найти хорошую работу. Например, из Томской области многие уезжают в соседние Новосибирскую и Кемеровскую. Похожая ситуация с Тюменской областью и ХМАО. У Москвы доля уехавших выпускников неожиданно высока. Причем 18 тысяч уехало в Подмосковье: Рис. 15 (интерактив) Это вызвано юридическими формальностями. Многие филиалы московских вузов под конец обучения переводят своих студентов в «головную» организацию. Так человек, живущий и работающий в области, получает диплом как выпускник московского вуза, а не филиала. А вот Курская область отражает общероссийский тренд – ее выпускники уезжают в основном в Москву (всего уезжает около половины выпускников). Подозреваем, это вызвано разницей в уровне зарплат – у трудоустроившихся в Москве она в 2 раза выше, чем у оставшихся. Вообще, почти в половине регионов России самое популярное направление отъезда выпускников – Москва и Московская область. Вместо заключения Мы рассказали лишь о небольшой части данных, полученных и исследованных в ходе мониторинга. Но на этом пора закругляться – статья и так вышла не маленькой. Надеемся, вам было интересно узнать о проекте и некоторых его результатах. Если будет интересно, SAnatoly может рассказать о старте и методике проекта, а vpodolskiy об архитектуре и формировании пакетов для ПФР. Следует помнить, что подобный мониторинг не является единственным способом оценки эффективности вузов и имеет ряд ограничений и допущений. Несмотря на это, результаты проекта дают достаточно пищи для размышлений и, возможно, помогут абитуриентам с выбором профессии или вуза. Ждем всех, кого заинтересовал этот пост, на портале – и просто любопытствующих, и специалистов в области образования, и тех, кто хотел бы самостоятельно проанализировать полученные данные.

Метки:  

[Из песочницы] Различие работы в использовании индексов в условии 'OR' баз данных Mysql и PostgeSQL

Понедельник, 06 Июня 2016 г. 19:14 + в цитатник
Многим известна проблема MySQL в не использовании индексов для двух индексируемых колонок в условии «OR». Если подробнее, в таблице есть несколько колонок с проставленными по ним индексами и затем делается выборка по этим колонкам с использованием условия «OR». Индексы не работают. Я решил исследовать этот момент в сравнении с PostgreSQL, так как в настоящий момент времени поставил для себя цель немного познакомиться в PostgreSQL. Для иллюстрации выполним следующие SQL запросы для двух разных баз данных. Для начала повторим ситуацию с условием «OR» в MySQL. 1. Создаем тестовую таблицу. MariaDB [metemplate]> create table example (a int, b int); 2. Вставляем несколько значений. MariaDB [metemplate]> select * from example; +------+------+ | a | b | +------+------+ | 1 | 2 | | 4 | 1 | | 2 | 7 | | 9 | 9 | | 19 | 9 | | 1 | 19 | | 11 | 12 | | 16 | 10 | +------+------+ 8 rows in set (0.00 sec) 3. Создаем индексы по двум колонкам. MariaDB [metemplate]> create index a_idx on example(a); MariaDB [metemplate]> create index b_idx on example(b); 4. Делаем запрос с выборкой по двум колонкам через условие «OR». MariaDB [metemplate]> explain select * from example where > В данном случае явно видно, что база данных MySQL при выборке не использует ни какой из двух индексов. Стандартное решение в этой ситуации это использовать union, чтобы зафиксировать использование созданных индексов. MariaDB [metemplate]> explain select * from example where > 5. Делаем аналогичную таблицу с данными в базе данных PostgeSQL и пробуем сделать аналогичный случай с условием «OR». width=8) Filter: ((a = 1) OR (b = 1)) Индексы не срабатывают, пробуем ранее используемых подход union. width=8) -> Append width=8) -> Seq Scan on example width=8) Filter: (a = 1) -> Seq Scan on example width=8) Filter: (b = 1) Индексы не используются. Наслышавшись о том, что PostgeSQL работает более эффективно с индексами нежели MySQL заподозрил о том, что видимо PostgeSQL мало данных в таблице и поэтому генерирую больше данных. metemplate=# insert into example values (generate_series(1,10000), generate_series(1,100000)); При таких объемах индексы используются и действительно, PostgreSQL умеет работать с «OR» условием. width=8) Recheck Cond: (a = 1) -> Bitmap Index Scan on a_idx width=0) Index Cond: (a = 1) width=8) Recheck Cond: ((a = 1) OR (b = 1)) -> BitmapOr width=0) -> Bitmap Index Scan on a_idx width=0) Index Cond: (a = 1) -> Bitmap Index Scan on b_idx rows=1 width=0) Index Cond: (b = 1)

Метки:  

Динамический blur на Android

Воскресенье, 05 Июня 2016 г. 00:28 + в цитатник
Информации о том как быстро размыть картинку на Android существует предостаточно. Но можно ли сделать это настолько эффективно, чтобы без лагов перерисовывать размытый bitmap при любом изменении контента, как это реализовано в iOS? Итак, что хотелось бы сделать: ViewGroup, которая сможет размывать контент, который находится под ней и отображать в качестве своего фона. Назовем ее BlurView Возможность добавлять в нее детей (любые View) Не зависеть от какой-либо конкретной реализации родительской ViewGroup Перерисовывать размытый фон, если контент под нашей View меняется Делать полный цикл размытия и отрисовки менее чем за 16ms Иметь возможность изменять стратегию размытия В статье я постараюсь обратить внимание только на ключевые моменты, за деталями прошу сюда. gif с примером (8mb) Как получить bitmap с контентом под BlurView? Создадим Canvas, Bitmap для него, и скажем всей View-иерархии нарисоваться на этом канвасе. internalBitmap = Bitmap.createBitmap(viewWidth, viewHeight, Bitmap.Config.ARGB_8888); internalCanvas = new Canvas(internalBitmap); ... rootView.draw(internalCanvas); Теперь в internalBitmap нарисованы все View, которые видны на экране. Проблемы: Если у вашего rootView нет заданного фона, нужно предварительно нарисовать на канвасе фон Activity, иначе он будет прозрачным на битмапе. final View decorView = getWindow().getDecorView(); //Activity's root View. Can also be root View of your layout final View rootView = decorView.findViewById(android.R.id.content); final Drawable windowBackground = decorView.getBackground(); ... windowBackground.draw(internalCanvas); rootView.draw(internalCanvas); Хотелось бы рисовать только ту часть иерархии, которая нам нужна. То есть под нашей BlurView, с соответствующим размером. Кроме того, было бы неплохо уменьшить Bitmap, на котором будет происходить отрисовка. Это ускорит отрисовку View иерархии, сам blur, а так же уменьшит потребление памяти. Добавляем поле scaleFactor, желательно, чтобы этот коэффициент был степенью двойки. float scaleFactor = 8; Уменьшаем bitmap в 8 раз и настраиваем матрицу канваса так, чтобы корректно на нем рисовать, учитывая позицию, размер и scale factor: private void setupInternalCanvasMatrix() { float scaledLeftPosition = -blurView.getLeft() / scaleFactor; float scaledTopPosition = -blurView.getTop() / scaleFactor; float scaledTranslationX = blurView.getTranslationX() / scaleFactor; float scaledTranslationY = blurView.getTranslationY() / scaleFactor; internalCanvas.translate(scaledLeftPosition - scaledTranslationX, scaledTopPosition - scaledTranslationY); float scaleX = blurView.getScaleX() / scaleFactor; float scaleY = blurView.getScaleY() / scaleFactor; internalCanvas.scale(scaleX, scaleY); } Теперь при вызове rootView.draw(internalCanvas), мы будем иметь на internalBitmap уменьшенную копию всей View-иерархии. Выглядеть она будет страшно, но это меня не очень волнует, т.к. дальше я все равно буду ее размывать. Проблемы: rootView скажет всем своим детям нарисоваться на канвасе, в том числе и BlurView. Этого хотелось бы избежать, BlurView не должна размывать сама себя. Для этого можно переопределить метод draw(Canvas canvas) в BlurView и делать проверку на каком канвасе ее просят отрисоваться. Если это системный канвас — разрешаем отрисовку, если это internalCanvas — запрещаем. Собственно, blur Я сделал интерфейс BlurAlgorithm и возможность настройки алгоритма. Добавил 2 реализации, StackBlur (by Mario Klingemann) и RenderScriptBlur. Вариант с RenderScript выполняется на GPU. Чтобы сэкономить память, я записываю результат в тот же bitmap, который мне пришел на вход. Это опционально. Так же можно попробовать кэшировать outAllocation и переиспользовать его, если размер входного изображения не изменился. RenderScriptBlur@Override public final Bitmap blur(Bitmap bitmap, float blurRadius) { Allocation inAllocation = Allocation.createFromBitmap(renderScript, bitmap); Bitmap outputBitmap; if (canModifyBitmap) { outputBitmap = bitmap; } else { outputBitmap = Bitmap.createBitmap(bitmap.getWidth(), bitmap.getHeight(), bitmap.getConfig()); } //do not use inAllocation in forEach. it will cause visual artifacts on blurred Bitmap Allocation outAllocation = Allocation.createTyped(renderScript, inAllocation.getType()); blurScript.setRadius(blurRadius); blurScript.setInput(inAllocation); blurScript.forEach(outAllocation); outAllocation.copyTo(outputBitmap); inAllocation.destroy(); outAllocation.destroy(); return outputBitmap; } Когда перерисовывать blur? Есть несколько вариантов: Вручную делать апдейт, когда вы точно знаете, что контент изменился Завязаться на события скролла, если BlurView находится над скроллящимся контейнером Слушать вызовы draw() через ViewTreeObserver Я выбрал 3 вариант, используя OnPreDrawListener. Стоит заметить, что его метод onPreDraw дергается каждый раз, когда любая View в иерархии рисует себя. Это, конечно, не идеал, т.к. придется перерисовывать BlurView на каждый чих, но зато это не требует никакого контроля со стороны программиста. Проблемы: onPreDraw будет так же вызван, когда будет происходить отрисовка всей иерархии на internalCanvas, а так же при отрисовке BlurView. Чтобы избежать этой проблемы, я завел флаг isMeDrawingNow. Вроде все очевидно, кроме одного момента. Ставить его в false нужно через handler, т.к. диспатч отрисовки происходит асинхронно через очередь событий UI потока. Поэтому нужно так же добавить этот таск в очередь событий, чтобы он выполнился именно в конце отрисовки. drawListener = new ViewTreeObserver.OnPreDrawListener() { @Override public boolean onPreDraw() { if (!isMeDrawingNow) { updateBlur(); } return true; } }; rootView.getViewTreeObserver().addOnPreDrawListener(drawListener); Производительность Много статистики я не насобирал, но на Nexus 4, Nexus 5 весь цикл отрисовки занимает 1-4мс на экранах из демо-проекта. Galaxy nexus — около 10мс. Sony Xperia Z3 compact почему-то справляется хуже — 8-16мс. Тем не менее, производительностью я удовлетворен, FPS держится на хорошем уровне. Заключение Весь код есть на гитхабе (библиотека и демо-проект) — BlurView. Идеи, замечания, баг-репорты и пулл реквесты приветствуются.

Device Lab от Google: Android TV

Суббота, 04 Июня 2016 г. 19:35 + в цитатник
Мы в самом центре Device Lab от Google, в которой вы сможете взять на тест самые новые устройства компании и начать разрабатывать свои приложения для них. В прошлый раз мы рассмотрели устройства Chromecast - аудиоверсию и большой Chromecast. Мы показали, как встраивать их поддержку в свои приложения, а сегодня речь пойдет уже о "большой" Android-платформе Google - Android TV. 
Читать далее

[Перевод] FizzBuzz на TensorFlow

Вторник, 24 Мая 2016 г. 10:24 + в цитатник
интервьюер: Приветствую, хотите кофе или что-нибудь еще? Нужен перерыв? я: Нет, кажется я уже выпил достаточно кофе! интервьюер: Отлично, отлично. Как вы относитесь к написанию кода на доске? я: Я только так код и пишу! интервьюер: ... я: Это была шутка. интервьюер: OK, итак, вам знакома задача "fizz buzz"? я: ... интервьюер: Это было да или нет? я: Это что-то вроде "Не могу поверить, что вы меня об этом спрашиваете." интервьюер: OK, значит, нужно напечатать числа от 1 до 100, только если число делится нацело на 3, напечатать слово "fizz", если на 5 — "buzz", а если делится на 15, то — "fizzbuzz". я: Я знаю эту задачу. интервьюер: Отлично, кандидаты, которые не могут пройти эту задачу, у нас не сильно уживаются. я: ... интервьюер: Вот маркет и губка. я: [задумался на пару минут] интервьюер: Вам нужна помощь, чтобы начать? я: Нет, нет, все в порядке. Итак, начнем с пары стандартных импортов: import numpy as np import tensorflow as tf интервьюер: Эм, вы же правильно поняли проблему в fizzbuzz, верно? я: Так точно. Давайте обсудим модели. Я думаю тут подойдет простой многослойный перцептрон с одним скрытым слоем. интервьюер: Перцептрон? я: Или нейронная сеть, как вам угодно будет называть. Мы ходим чтобы на вход приходило число, а на выходе была корректное "fizzbuzz" представление этого числа. В частности, мы хотим превратить каждый вход в вектор "активаций". Одним из простых способов может быть конвертирование в двоичный вид. интервьюер: Двоичный вид? я: Да, ну, знаете, единицы и нули? Что-то вроде: def binary_encode(i, num_digits): return np.array([i >> d & 1 for d in range(num_digits)]) интервьюер: [смотрит на доску с минуту] я: И нашим выходом будет унитарное кодирование fizzbuzz представления числа, где первая позиция означает "напечатать как есть", второе означает "fizz" и так далее. def fizz_buzz_encode(i): if i % 15 > интервьюер: OK, этого, кажется, достаточно. я: Да, вы правы, этого достаточно для настройки. Теперь нам нужно сгенерировать данные для тренировки сети. Это будет нечестно использовать числа от 1 до 100 для тренировки, поэтому давайте натренируем на всех оставшихся числах вплоть до 1024: NUM_DIGITS = 10 trX = np.array([binary_encode(i, NUM_DIGITS) for i in range(101, 2 ** NUM_DIGITS)]) trY = np.array([fizz_buzz_encode(i) for i in range(101, 2 ** NUM_DIGITS)]) интервьюер: ... я: Теперь нужно нашу модель нужно адаптировать для tensorflow. Сходу я не сильно уверен сколько скрытых юнитов использовать, может 10? интервьюер: ... я: Да, пожалуй 100 будет лучше. Мы всегда можем изменить это позже: NUM_HIDDEN = 100 Нам понадобится входная переменная шириной в NUM_DIGITS, и выходная переменная с шириной в 4: We'll need an input variable with width NUM_DIGITS, and an output variable with width 4: X = tf.placeholder("float", [None, NUM_DIGITS]) Y = tf.placeholder("float", [None, 4]) интервьюер: Как далеко вы планируете зайти с этим? я: Ах, всего два слоя — один скрытый слой и один слой для вывода. Давайте используем случайно-инициализированные веса для наших нейронов: def init_weights(shape): return tf.Variable(tf.random_normal(shape, > И мы готовы определить нашу модель. Как я сказал ранее, один скрытый слой, и, давайте используем, ну, не знаю, ReLU активацию: def model(X, w_h, w_o): h = tf.nn.relu(tf.matmul(X, w_h)) return tf.matmul(h, w_o) Мы можем использоваться softmax кросс-энтропию как нашу функцию стоимости и попробовать минимизировать ее: We can use softmax cross-entropy as our cost function and try to minimize it: py_x = model(X, w_h, w_o) cost = tf.reduce_mean(tf.nn.softmax_cross_entropy_with_logits(py_x, Y)) train_op = tf.train.GradientDescentOptimizer(0.05).minimize(cost) интервьюер: ... я: И, конечно, предсказание будет просто наибольшим выходом: predict_op = tf.argmax(py_x, 1) интервьюер: Пока вы не заблудились, проблема, которую вы должны были решить это генерация fizz buzz для чисел от 1 до 100. я: Ох, отличное замечание, predict_op функция вернет число от 0 до 3, но мы же хотим "fizz buzz" вывод: def fizz_buzz(i, prediction): return [str(i), "fizz", "buzz", "fizzbuzz"][prediction] интервьюер: ... я: Теперь мы готовы натренировать модель. Поднимем tensorflow сессию и проинициализируем переменные: with tf.Session() as sess: tf.initialize_all_variables().run() Запустим, скажем, 1000 эпох тренировки? интервьюер: ... я: Да, наверное этого будет мало — пусть будет 10000, чтобы наверняка. Ещё, наши данные для тренировки последовательны, что мне не нравится, так что давайте размешаем их на каждой итерации: for epoch in range(10000): p = np.random.permutation(range(len(trX))) trX, trY = trX[p], trY[p] И, каждая эпоха будет тренировать в пачках по, я не знаю, ну пусть 128 входов. BATCH_SIZE = 128 В итоге, каждый проход будет выглядеть так: for start in range(0, len(trX), BATCH_SIZE): end = start + BATCH_SIZE sess.run(train_op, > и потом мы можем вывести погрешность тренировочных данных, ведь почему бы и нет? print(epoch, np.mean(np.argmax(trY, > интервьюер: Вы серьёзно? я: Да, мне кажется это очень полезно видеть, как прогрессирует точность. интервьюер: ... я: Итак, после того, как модель натренирована, время fizz buzz. Наш вход будет всего лишь двоичное кодирование числе от 1 до 100: numbers = np.arange(1, 101) teX = np.transpose(binary_encode(numbers, NUM_DIGITS)) И затем, наше вывод это просто fizz_buzz функция, применённая к выходной модели: And then our output is just our fizz_buzz function applied to the model output: teY = sess.run(predict_op, > интервьюер: ... я: И это будет ваш fizz buzz! интервьюер: Этого достаточно, правда. Мы с вами свяжемся. я: Свяжемся, звучит многообещающе. интервьюер: ... Постскриптум Я не получил эту работу. Но я попробовал на самом деле запустить этот код (код на Github), и, оказалось, что он даёт несколько неправильный вывод! Большое спасибо, машинное обучение! In [185]: output Out[185]: array(['1', '2', 'fizz', '4', 'buzz', 'fizz', '7', '8', 'fizz', 'buzz', '11', 'fizz', '13', '14', 'fizzbuzz', '16', '17', 'fizz', '19', 'buzz', '21', '22', '23', 'fizz', 'buzz', '26', 'fizz', '28', '29', 'fizzbuzz', '31', 'fizz', 'fizz', '34', 'buzz', 'fizz', '37', '38', 'fizz', 'buzz', '41', '42', '43', '44', 'fizzbuzz', '46', '47', 'fizz', '49', 'buzz', 'fizz', '52', 'fizz', 'fizz', 'buzz', '56', 'fizz', '58', '59', 'fizzbuzz', '61', '62', 'fizz', '64', 'buzz', 'fizz', '67', '68', '69', 'buzz', '71', 'fizz', '73', '74', 'fizzbuzz', '76', '77', 'fizz', '79', 'buzz', '81', '82', '83', '84', 'buzz', '86', '87', '88', '89', 'fizzbuzz', '91', '92', '93', '94', 'buzz', 'fizz', '97', '98', 'fizz', 'fizz'], ) Наверное, нужно взять более глубокую нейронную сеть.

[Перевод] Новые возможности Intel Media Server Studio 2016

Вторник, 17 Мая 2016 г. 01:22 + в цитатник
С выходом новой версии Intel Media Server Studio 2016 быстрое и качественное транскодирование видео стало еще проще и доступнее! HEVC энкодер стал в 1,1 раза производительнее, а качество возросло на 10 %. Intel Media Server Studio помогает поставщикам решений кодировать видео в формате HEVC 4K для вещания с помощью специальной, основанной на базе процессоров Intel Xeon E3 карты-расширения Intel Visual Compute Accelerator в сочетании с некоторыми процессорами Intel Xeon E51. Повышение стабильности декодирования AVC и MPEG2 позволяет обрабатывать ошибки в видеоматериалах. Подробные сведения о новых возможностях для транскодирования мультимедиа см. ниже. Корпорация Intel является лидером в области ускорения обработки мультимедиа и облачных технологий. Благодаря мощи процессоров Intel и Intel Media Server Studio мы помогаем поставщикам решений мультимедиа, вещательным компаниям и разработчикам инфраструктуры создавать новые решения и добиваться высокой производительности, эффективности и высокого качества в приложениях для обработки мультимедиа и вещания видеоматериалов через Интернет. Загрузить Media Server Studio 2016 » Для зарегистрированных пользователей (требуется вход) » Для новых пользователей: получить бесплатно выпуск Community, ознакомиться с выпуском Pro или купить Повышение производительности и качества HEVC (H.265) на 10%, использование расширенного анализа GPU, уменьшение битрейта Professional Edition Улучшенные на 10% производительность и качество GPU-accelerated (GACC) HEVC энкодера позволяют кодировать видео 4K HEVC в реальном времени с пригодным для вещания качеством на некоторых платформах Intel Xeon E5 с помощью Intel Visual Compute Accelerator (Intel VCA) Еще больше повысить производительность HEVC GPU-accelerated энкодера теперь помогает отгрузка циклических фильтров, таких как deblocking (DBF) и sample adaptive offset (SAO) на GPU (в прежних версиях эти фильтры выполнялись на CPU). Рисунок 1. В версии Media Server Studio 2016 эффективность кодирования видео повышена на 10 % по сравнению с версией 2015 R7. Кроме перечисленного выше, новая версия также поддерживает кодирование в реальном времени видео с разрешением 1080p со скоростью 50 кадров в секунду на платформах с процессорами Intel Core i7 и Xeon E3 предыдущего поколения**. Соотношение качества и производительности software реализации (вычисления происходят только на CPU) и GPU accelerated (вычисления выполняются на execution units GPU) кодирования HEVC для 8-битных видеоданных 4:2:0, 1080p. Базовый показатель качества соответствует стандарту ISO HM14 (0 %) и вычислен с помощью кривых Y-PSNR BDRATE. Производительность — средняя между четырьмя битрейтами взятыми в диапазоне от низкого (в среднем 3,8 МБ/с) до высокого (в среднем 25 МБ/с). Дополнительные сведения см. здесь Благодаря новым возможностям Intel VTune Amplifier разработчикам становится проще получать и интерпретировать данные об использовании GPU и о производительности OpenCL* и Intel Media SDK приложений. Также поддерживается анализ распараллеливания нагрузки между CPU и GPU, анализ работы GPU с использованием аппаратных метрик, схема архитектуры GPU и многое другое. Снижение объема данных при использовании кодека HEVC за счет кодирования на основе рабочих областей (ROI). Определенные рабочие области можно упаковывать с наименьшей степенью сжатия для сохранения наибольшей детализации по сравнению с другими областями. Эта функция повышает производительность приложений для видеоконференций. Для ее использования необходимо задать структуру mfxExtEncoderROI в приложении, чтобы указать разные рабочие области при кодировании. Это можно сделать при инициализации или во время выполнения. Видеоконференции — ускорьте ваши приложения для видеоконференций с помощью специального режима HEVC с низкими задержками. Новые возможности работы с разрешением 8K: не ограничивайте ваше приложение возможностью кодирования видео с разрешением 4K. Программный и GPU-accelerated Intel HEVC кодеки в составе Media Server Studio 2016 поддерживают кодирование с разрешением 8K. Улучшения в AVC (H.264) и MPEG2 декодировании Media Server Studio Community, Essentials, Professional Усовершенствованная графика 5-го поколения и ускорители обработки мультимедиа вместе с собственными драйверами открывают возможность транскодирования до 16 потоков HD AVC с высоким качеством в реальном времени на каждый процессор Intel Xeon E3 v4 (или с помощью Intel VCA)1 за счет применения аппаратного ускорения. До 12 потоков HD AVC на процессорах Intel Core 4-го поколения с графикой Intel Iris**. Используйте повышенное качество кодирования AVC для BRefType MFX_B_REF_PYRAMID. Декодер AVC и MPEG2 стал стабильнее в обработке поврежденных потоков и ошибок. Повышенная устойчивость декодирования AVC и MPEG2 обеспечивает стабильный вывод и безупречную обработку поврежденного видео контента. Дополнительные сообщения об ошибках помогут разработчикам быстрее находить и анализировать ошибки при декодировании. Рисунок 2. В Media Server Studio 2016 достигнут прирост производительности AVC(H.264) кодеков на 40 % по сравнению с версией 2015 за счет улучшенных алгоритмов планирования аппаратной нагрузки**. На этом рисунке показаны результаты кодирования нескольких потоков H.264 из одного исходного файла H.264, используя сэмпл multi_transcode (доступен в составе примеров кода). Каждая точка соответствует среднему значению для 4 видеопотоков и 6 значений битрейта. Замеры производились со значением Target Usage 7 (TU7), что соответствует работе с наивысшей скоростью (и самым низким качеством). [Видеоматериалы с разрешением 1080p со скоростью 50 кадров в секунду получены из media.xiph.org/video/derf/: crowd_run, park_joy (30mbps input; 5, 7.1, 10.2, 14.6, 20.9, 30 mbps output; in_to_tree, old_town_cross 15 mbps input, 2.5, 3.5, 5.1, 7.3, 10.4, 15 mbps output).] Конфигурация: одновременное транскодирование AVC1>N с разной скоростью данных, 1080p, TU7, процессор Intel Core i7-4770K с частотой 3,5 ГГц**. Количество каналов 1080p с различной скоростью данных. Прочие улучшения Усовершенствования в Intel SDK для приложений OpenCL для Windows включают новые возможности для разработки ядер. Добавлена поддержка CTB-level delta QP для всех предустановок качества, т. е. Target Usage с 1 по 7 включительно для всех режимов управления скоростью данных (CBR, VBR, AVBR, ConstQP) и всех профилей (MAIN, MAIN10, REXT). Поддержка кодирования потока IPPP..P, т. е. без B-кадров, с помощью обобщенного управления P- и B-кадрами для приложений, в которых B-кадры удаляются для удовлетворения требований пропускной способности сети. Кодирование H.264 напрямую работает с ARGB поверхностями (полученными с экрана или из игр) и YUY2, благодаря чему снижаются издержки на предварительную обработку (т. е. преобразование цветового пространства из RGB4 в NV12 для обработки в Intel Media SDK), повышается производительность возможности захвата экрана. Экономьте время, используя обновленные примеры кода В образец sample_multi_transcode добавлена возможность использовать фильтры для обработкой видеопотоков (VPP), такие как композиция (composition), удаление шума (denoising), обнаружение краев (detail), управление кадровой скоростью (FRC), удаление чересстрочной развертки (deinterlacing), преобразование цветового пространства (CSC). В sample_decode в пакете сэмплов для Linux поддерживается рендеринг видео с DRM, для чего нужно использовать входной аргумент “-rdrm”. Теперь sample_decode и sample_decvpp объединены в один сэмпл для декодирования, куда были добавлены новые фильтры VPP, такие как удаление чересстрочной развертки и преобразование цветового пространства. Дополнительные сведения Выше описаны лишь некоторые, наиболее значимые свойства и усовершенствования в Media Server Studio 2016. Посетите сайт продукта и прочтите документацию для получения дополнительных сведений. Release notes для Essential/Community: Windows, Linux Release notes для Professional Edition: Windows, Linux

Метки:  

Дайджест Университета ИТМО: #2 Научные разработки, видеосюжеты об ученых и ближайшие мероприятия

Понедельник, 16 Мая 2016 г. 16:06 + в цитатник
Сегодня в дайджесте (первый выпуск) собраны: наиболее интересные публикации о разработках и открытиях, сделанных в Университете ИТМО; видеорепортажи о работе ученых и исследователей; статьи о том, как ведется подготовка студентов, занимающихся спортивным программированием; а также ближайшие мероприятия Университета, принять участие в которых может любой желающий. Разработки Университета ИТМО Система, моделирующая поведение человека в местах массового скопления людей Ученые из Университета ИТМО решили задачу о моделировании поведения людей на практическом примере: «Как обеспечить удобный и безопасный маршрут до метро 70 тысячам болельщиков со строящегося к чемпионату мира по футболу 2018 г. стадиона «Зенит-Арена» с учетом различных нестандартных ситуаций, начиная от сильного дождя и заканчивая проигрышем любимой команды». Об этом и других вариантах практического применения разработки в материале «Российской Газеты». Квантовые коммуникации: от НИР до работающего проекта Работа ученых Университета ИТМО позволяет создать конкурентоспособную систему квантовой связи, позволяющую соперничать с ведущими мировыми разработками в этой сфере. Реализованный в рамках проекта участок квантовой сети является первым в России, действующим в городской инфраструктуре. О компании ООО «Квантовые технологии» при Университете ИТМО, в рамках которой реализуется проект писал Rusbase, а подробнее о самой технологии можно прочесть здесь. Экспериментальная установка для осуществления квантовой передачи данных Роботизированная перчатка для восстановления мелкой моторики у людей, перенесших инсульт Молодые ученые из Университета ИТМО создали робота-перчатку, который сгибает и разгибает пальцы руки пациента на ранней стадии реабилитации, когда сам человек еще не может управлять своими мышцами. Подробнее о разработке, ее преимуществах перед мировыми аналогами, и о том, как ученые планируют запустить робота в массовое производство рассказывает ТАСС. Открытие хиральности у квантовых точек селенида кадмия Открытие сделано химиками Университета ИТМО и Тринити Колледжа. Об открытии, научных публикациях, сделанных на эту тему, проведенном эксперименте и значимости исследований в данной области пишет портал N+1. Проект, позволяющий уменьшить стоимость процедуры МРТ Ученые Университета ИТМО работают над задачей повышения качества изображения, получаемого методом магнитно-резонансной томографии. Им уже удалось спроектировать систему, в которой качество картинки, выдаваемой томографом, оказывается выше, сам процесс томографии – на порядок короче и дешевле. Подробнее о проекте в материале «Российской Газеты». Видеосюжеты о разработках Университета ИТМО Беспроводная передача энергии в сюжете программы «Чудо техники»: Новые разработки лаборатории «Метаматериалы» Университета ИТМО в «Вестях» на России 1. «Робот-дворецкий» xTurion, позволяющий отслеживать и по возможности исправлять неполадки в системе «умного дома» в отсутствие человека, в материале России 1: Сюжет телеканала «Санкт-Петербург» о навигационном модуле для незрячих Oriense (проект-резидент стартап-школы SumIT Университета ИТМО) можно посмотреть здесь. Олимпиадное программирование в Университете ИТМО Как из студентов Университета ИТМО готовят продвинутых программистов и победителей олимпиад: рассказ о том, как учатся, готовятся к олимпиадам и что делают в свободное от учебы время студенты Университета ИТМО, занимающиеся спортивным программированием. Победа команды Университета ИТМО на чемпионате мира по программированию ACM ICPC Как Университет ИТМО стал одним из ведущих мировых вузов по подготовке олимпиадных программистов: материал (англоязычный) журналиста издания Digital Russia об Университете ИТМО от начала 90-х и до наших дней. Лонгрид об одном из наиболее известных победителей международных олимпиад по программированию из Университета ИТМО – Геннадии Короткевиче – от журналистов Bloomberg. Ближайшие мероприятия Университета ИТМО День открытых дверей базовой кафедры технологий визуализации Университета ИТМО Место: Санкт-Петербург, Биржевая линия, д. 14, ауд. 202, Университет ИТМО Время: 17 мая, начало в 15:00 На Дне открытых дверей можно узнать обо всех дисциплинах, преподаваемых на базовой кафедре, стажировках, компаниях-партнерах, поступлении и перспективах трудоустройства выпускников. Подробнее о мероприятии здесь. Семинар Phase diagrams, phase equilibria and phase stability in thermoelectric materials Место: Санкт-Петербург, ул. Ломоносова, д. 9, ауд. 3411, Университет ИТМО Время: 17 мая, начало в 15:00 Спикер мероприятия – профессор Университета Монпелье во Франции Жан Клод Теденак (Jean Claude Tedenac). Подробнее о мероприятии здесь. День разработчика Autodesk в Университете ИТМО и двухдневный хакатон 3D HACKATHON Место: Санкт-Петербург, ул. Ломоносова, д. 9, Актовый зал, Университет ИТМО Время: с 10:00 20 мая до 22:00 21 мая В пятницу утром стартует образовательная секция, в которой приглашённые специалисты расскажут о технологиях Autodesk, а слушатели смогут задать возникшие вопросы и подготовиться к участию в хакатоне. В рамках хакатона необходимо будет разработать (на выбор): расширение для AutodeskViewandDataAPI, которое эффективно интегрирует интерактивный просмотр 3D-моделей в веб-приложение для решения некоторой практической задачи приложение для 3D-моделлера Autodesk Fusion 360 на Python, С++ или JavaScript. Каждый участник команды-победителя (в обеих номинациях) получает планшет Samsung Galaxy. Подробности и регистрация на мероприятие доступны здесь. День открытых дверей кафедры высокопроизводительных вычислений и Института наукоемких компьютерных технологий Место: Санкт-Петербург, Биржевая линия, д. 4. Время: 26 мая, начало в 18:00 На Дне открытых дверей можно узнать обо всех дисциплинах кафедры, программе двойных дипломов (совместно с Амстердамским университетом), компаниях-партнерах и новой магистерской программе «Вычислительная медицина». Подробности и регистрация на мероприятие доступны здесь.

Метки:  

Objective-C, static libraries, categories, -ObjC, боль…

Воскресенье, 15 Мая 2016 г. 17:54 + в цитатник
Не всем повезло писать приложения полностью на Swift, да и еще под ios 8+ онли. Много легаси на Objective-C, много зависимостей идет через статик либы, ни cocoapods, ни carthage, всё ручками. Мы же крутые девелоперы, поэтому строго следуем DRY и все реюзабельные вкусшянки выносим либо в отдельные проекты, либо в статик библиотеки. Сейчас рассмотрим случай, когда мы сделали классную статичную библиотечку с не менее прикольным апи, и хотели бы поделиться с товарищами по цеху внутри компании — на вики ресурсе/гите выложить архивчик с либой, хедерами и, конечно же, ридмиком где описан весь апи и как им пользоваться. Для примера ради рассмотрим один класс + его категорию На скриншоте у нас структура проекта, где класс + класс категория, всё просто. Собираем обычным образом, пишем readme.md с описанием апи и архивируем библиотеку. Всё круто, залили на вики, пацанам твитнули в slack/skype/etc и пошли себе за очередным кофе. Только присели обратно со свежесваренным кофе и курсор мышки почти достиг закладки на хабр, как в чаты посыпались какие-то логи, и все требуют вашего немедленного ответа, так как проблема в свежезарелизенной либе. Вас бросило в пот, ведь у вас тестовое покрытие 146%, всё на сто раз перепроверено. В это же самое время в чате уже в личку снова пишут тот же самый лог ошибки: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[Deadpool guns]: unrecognized selector sent to instance 0x7ffecbc12df0' После ознакомления с логом, причина ясна и до боли знакома когда часто работаешь со статик либами. Поняв проблему, вы уверенно вытираете пот со лба, открываете ранее отправленный readme.md и дописываете: Don't forget to add '-ObjC' flag to 'Other Linker Flags' in Build Settins of Xcode's scheme. После, обновили вики, снова всех оповестили и вроде всё успокоилось, месседжеры замолкли, кофе даже не успело остыть. «Ну сейчас точно никто меня не оставновит» — шепчет ваш внутренний голос и курсор мыши снова тянется к заветной закладке (ненене, только хабр!). От желанного тебя отделяет только клик по левой кнопке мыши, но тебя не покидает мысль: «Можно ли было избежать этой ошибки или как предотвратить ее в будущем?!». «Да к черту всё!» — воскликнул внутренний голос и курсор потянулся к Terminal.app. otool -tV -arch x86_64 libDeadpool.a выдает: Archive : libDeadpool.a libDeadpool.a(Deadpool+Guns.o): (__TEXT,__text) section -[Deadpool(Guns) guns]: 0000000000000000 pushq %rbp 0000000000000001 movq %rsp, %rbp 0000000000000004 subq $0x10, %rsp 0000000000000008 leaq 0x71(%rip), %rax ## Objc cfstring ref: @"sword 2" 000000000000000f movd %rax, %xmm0 0000000000000014 leaq 0x45(%rip), %rax ## Objc cfstring ref: @"sword 1" 000000000000001b movd %rax, %xmm1 0000000000000020 punpcklqdq %xmm0, %xmm1 ## xmm1 = xmm1[0],xmm0[0] 0000000000000024 movdqa %xmm1, -0x10(%rbp) 0000000000000029 movq 0x70(%rip), %rdi ## Objc class ref: NSArray 0000000000000030 movq 0x91(%rip), %rsi ## Objc selector ref: arrayWithObjects:count: 0000000000000037 leaq -0x10(%rbp), %rdx 000000000000003b movl $0x2, %ecx 0000000000000040 callq *_objc_msgSend(%rip) 0000000000000046 addq $0x10, %rsp 000000000000004a popq %rbp 000000000000004b retq libDeadpool.a(Deadpool.o): (__TEXT,__text) section -[Deadpool name]: 0000000000000000 pushq %rbp 0000000000000001 movq %rsp, %rbp 0000000000000004 movq 0x1d(%rip), %rsi ## Objc selector ref: class 000000000000000b callq *_objc_msgSend(%rip) 0000000000000011 movq %rax, %rdi 0000000000000014 popq %rbp 0000000000000015 jmp _NSStringFromClass хм, в самой либе все методы на месте, теперь посмотрим исходники приложения: otool -tV -arch x86_64 DemoApp.app/DemoApp | grep Deadpool выдает: 0000000100001ae8 movq 0x21f1(%rip), %rdi ## Objc class ref: Deadpool 0000000100001af6 movq 0x1513(%rip), %r12 ## Objc message: +[Deadpool new] -[Deadpool name]: WTF! Окей гугл, где же все таки метод из категории? гугл нам умело подсовывает ссылку на документацию эпла по этой как раз проблеме https://developer.apple.com/library/mac/qa/qa1490/_index.html, где беглый перевод говорит следующее: The Linker Когда си-программа скомпилирована, то каждый файл (.c) компилируется в так называемый «object file» (.o), который содержит имплементации функций и другую статичную информацию. После линкер собирает все эти файлы в один конечный файл — executable. И этот executable файл как раз и попадает внутрь нашей .app посредством Xcode. Но когда source файл (.c) использует что либо, например функцию, что определено в другом файле (другой .c файл), тогда «undefined symbol» записывается в .o файл для этого участка кода. И на этапе сборки линкеру достаточно информации чтобы по «undefined symbol» понять откуда нужно вытащить недостающую вещь чтобы собрать конечный executable. Это описание для сборки UNIX static library. Objective-C Из-за динамической природы языка этот процесс в Objective-C немного усложнен, так как поиск реализации метода происходит только по факту обращения к этому методу. Objective-C не определяет вспомогательных symbols для методов линкеру, а только определяет symbols для классов. Например, в классе/файле main.o есть код: [[FooClass alloc] initWithBar:nil] то есть, FooClass это отдельный класс, в отдельном FooClass.o файле, так вот main.o будет только содержать «undefined symbol» для самого FooClass, но никаких дополнительных symbols для метода -initWithBar: в этом классе. Так как категория это просто отдельный файл с методами, то у линкера нет совершенно никакой информации, что этот файл нужно слинковать, так как для методов не создаются вспомогательные линкеру «undefined symbol» штуки. Так, вроде разобрались, еще раз посмотрим на байт код либы: Archive : libDeadpool.a libDeadpool.a(Deadpool+Guns.o): (__TEXT,__text) section -[Deadpool(Guns) guns]: 0000000000000000 pushq %rbp 0000000000000001 movq %rsp, %rbp 0000000000000004 subq $0x10, %rsp 0000000000000008 leaq 0x71(%rip), %rax ## Objc cfstring ref: @"sword 2" 000000000000000f movd %rax, %xmm0 0000000000000014 leaq 0x45(%rip), %rax ## Objc cfstring ref: @"sword 1" 000000000000001b movd %rax, %xmm1 0000000000000020 punpcklqdq %xmm0, %xmm1 ## xmm1 = xmm1[0],xmm0[0] 0000000000000024 movdqa %xmm1, -0x10(%rbp) 0000000000000029 movq 0x70(%rip), %rdi ## Objc class ref: NSArray 0000000000000030 movq 0x91(%rip), %rsi ## Objc selector ref: arrayWithObjects:count: 0000000000000037 leaq -0x10(%rbp), %rdx 000000000000003b movl $0x2, %ecx 0000000000000040 callq *_objc_msgSend(%rip) 0000000000000046 addq $0x10, %rsp 000000000000004a popq %rbp 000000000000004b retq libDeadpool.a(Deadpool.o): (__TEXT,__text) section -[Deadpool name]: 0000000000000000 pushq %rbp 0000000000000001 movq %rsp, %rbp 0000000000000004 movq 0x1d(%rip), %rsi ## Objc selector ref: class 000000000000000b callq *_objc_msgSend(%rip) 0000000000000011 movq %rax, %rdi 0000000000000014 popq %rbp 0000000000000015 jmp _NSStringFromClass Действительно, у нас скомпилировалось два файла Deadpool.o и Deadpool+Guns.o, так как второй файл это просто набор методов для первого, то линкер о нем ничего не знает и поэтому получаем эту ошибку только в рантайме. Сразу первое решение — перенести категорию в файл основного класса. Да, это будет работать :) но для нас это не совсем удобно, так как мы привыкли все категории держать в отдельных папочках для порядка. Другое решение. Те, кто использует нашу либу, должны указать -ObjC флаг в «Other Linker Flags», этот флаг говорит линкеру загрузить всё всё всё из статичной либы. Ну, нам подходит это решение тем, что на нашей стороне ничего править не нужно. Но если подумать, если разработчик подключит кучу либ и только из-за нашей ему приходится добавлять этот флаг, то он может получить нехилое прибавление в весе для своего приложения (я так предполагаю). А можно ли как то сказать линкеру, чтобы он собрал класс и его категории в один файл? Оказывается есть такое и название ему «Perform Single-Object Prelink» или «GENERATE_MASTER_OBJECT_FILE» в pbxproj файле. Правда происходит не просто объединение класса и его категории в единый файл, а все файлы проекта будут как единый «object file». Если это значение выставить в true, то мы должны получить поведение, которое хотим. Проверим. Выставляем: otool -tV -arch x86_64 libDeadpool.a получаем: Archive : libDeadpool.a libDeadpool.a(libDeadpool.a-x86_64-master.o): (__TEXT,__text) section -[Deadpool(Guns) guns]: 0000000000000000 pushq %rbp 0000000000000001 movq %rsp, %rbp 0000000000000004 subq $0x10, %rsp 0000000000000008 leaq 0x149(%rip), %rax ## Objc cfstring ref: @"sword 2" 000000000000000f movd %rax, %xmm0 0000000000000014 leaq 0x11d(%rip), %rax ## Objc cfstring ref: @"sword 1" 000000000000001b movd %rax, %xmm1 0000000000000020 punpcklqdq %xmm0, %xmm1 ## xmm1 = xmm1[0],xmm0[0] 0000000000000024 movdqa %xmm1, -0x10(%rbp) 0000000000000029 movq 0x270(%rip), %rdi ## Objc class ref: NSArray 0000000000000030 movq 0x259(%rip), %rsi ## Objc selector ref: arrayWithObjects:count: 0000000000000037 leaq -0x10(%rbp), %rdx 000000000000003b movl $0x2, %ecx 0000000000000040 callq *_objc_msgSend(%rip) 0000000000000046 addq $0x10, %rsp 000000000000004a popq %rbp 000000000000004b retq -[Deadpool name]: 000000000000004c pushq %rbp 000000000000004d movq %rsp, %rbp 0000000000000050 movq 0x241(%rip), %rsi ## Objc selector ref: class 0000000000000057 callq *_objc_msgSend(%rip) 000000000000005d movq %rax, %rdi 0000000000000060 popq %rbp 0000000000000061 jmp _NSStringFromClass Что и хотели, сейчас всё в одном файле. Убираем из приложения -ObjC и пересобираем с новой версией нашей библиотеки и смотрим: otool -tV -arch x86_64 DemoApp.app/DemoApp | grep Deadpool вывод: 0000000100001a70 movq 0x22c9(%rip), %rdi ## Objc class ref: Deadpool 0000000100001a7e movq 0x158b(%rip), %r12 ## Objc message: +[Deadpool new] -[Deadpool(Guns) guns]: -[Deadpool name]: Отлично. Сейчас можно обратно из readme.md удалять информацию о -ObjC флаге, смело открывать хабр и допивать, к сожалению, уже остывший кофе ) пс. Проблема старая, давно ее решил, сейчас вот дошли руки написать и более подробно в этом разобраться ) Не уверен в идеальности решения, но мне помогло с этой проблемой, может кому будет интересно. Полезные ссылки: https://developer.apple.com/library/mac/qa/qa1490/_index.html http://stackoverflow.com/questions/2567498/objective-c-categories-in-static-library

Метки:  

Ввести номер одного из друзей и вывести его имя (задача на записи)

Воскресенье, 15 Мая 2016 г. 16:35 + в цитатник
Помогите написать программу, завис на этом. Ввести номер телефона одного из четырех друзей. Вывести его имя. Serge_Bliznykov type PhoneRec = record pnum : string[8], name : string[45] end; const MaxCount = 2; var abook:array[1..MaxCount] of PhoneRec; i, iFound : integer; FindPnoneNum : string; begin abook[1].pnum ; ; abook[2].pnum ; ; WriteLn('Введите номер друга (например, 1111 [...]

Поддержите чиркнуть утилиту, завис на этом.


Завести номер телефона одного из четырех дружочков. Исключить его имя.

Serge_Bliznykov


type
PhoneRec = record
pnum : string[8],
name : string[45]
end;

const MaxCount = 2;
var abook:array[1..MaxCount] of PhoneRec;
i, iFound : integer;
FindPnoneNum : string;
begin
abook[1].pnum ; ;
abook[2].pnum ; ;

WriteLn('Установите номер дружочка (например, 1111 Cложные градиетны альфа (OpenGL) 1222: ');
ReadLn(FindPnoneNum);
iFound Нет приятеля с заданным номером')
else WriteLn('Определен дружочек: ', abook[iFound].name);
ReadLn
end.

тема на форуме


Метки:  

Cложные градиетны альфы (OpenGL)

Воскресенье, 08 Мая 2016 г. 09:19 + в цитатник
Попытался сделать так… Понятное дело, что загрузка ведется из файлов и это как бы не метод «сменить альфу на ходу» но суть не в этом.. главное я пытаюсь отрисовать из одной текстуры в другую искл. «сложно градиентную» альфу)) void LoadTextureWithSeparateAlphaFile( char* FileName, char* Alpha8File, GLuint * OutTexture) { AUX_RGBImageRec *bmp; AUX_RGBImageRec *alpha; // цветной 24-битный. [...]

Рискнул совершить так…

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


void LoadTextureWithSeparateAlphaFile( char* FileName, char* Alpha8File, GLuint * OutTexture)
{
AUX_RGBImageRec *bmp;
AUX_RGBImageRec *alpha;
// цветной 24-битный. *auxDIBImageLoad - не загружает 32битные узоры(
bmp = auxDIBImageLoad ( FileName );
// монохромный, 8 - битный, 256 колер узор
alpha = auxDIBImageLoad ( FileName );

glGenTextures ( 1, OutTexture );
glBindTexture ( GL_TEXTURE_2D, *OutTexture );

glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR );
glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR );

glTexImage2D ( GL_TEXTURE_2D, 0, GL_RGBA8, bmp->sizeX, bmp->sizeY,
0, GL_RGBA8, GL_UNSIGNED_BYTE, bmp->data );
//допишем альфа канал в уже рожденную текстуру
glTexSubImage2D ( GL_TEXTURE_2D, 0, 0, 0, alpha->sizeX, alpha->sizeY,
GL_ALPHA8, GL_UNSIGNED_BYTE, alpha->data );

// Выпустить данные текстуры
if ( bmp->data )
{
free ( bmp->data );
bmp->data =0;
}
free ( bmp );

>

Есть намек на прозрачность но при этом стереоизображение выводится черт знает как(. растет и при этом высыпает артефактами Оо.


тема на форуме


Метки:  

Как действует glTexSubImage2D?

Четверг, 05 Мая 2016 г. 20:03 + в цитатник
Помогите разобраться, как действует glTexSubImage2D. Я так понял: glTexSubImage2D(Ссылка на текстуру (из которой вырезаем кусок), Не знаю, что, Позиция по X (на той текстуре, откуда вырезаем), Позиция по Y, Ширина (того, что должно получиться), Высота, Что-то с цветами, Не знаю, что Какой-то указатель); Вот с тем указателем я так и не понял. И еще не [...]

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


glTexSubImage2D(Ссылка на текстуру (из которой вырезаем кусок),
Не знаю, что,
Позиция по X (на той текстуре, откуда вырезаем),
Позиция по Y,
Ширина (того, что должно получиться),
Высота,
Что-то с цветами,
Не знаю, что
Какой-то указатель);

Вот с тем указателем я так и не понял. И еще не понял, куда это все вырезанное сохраняется.


.pixel


Parameters

place

Specializes the place texture. Must be GL_TEXTURE_2D, GL_TEXTURE_CUBE_MAP_POSITIVE_X, GL_TEXTURE_CUBE_MAP_NEGATIVE_X, GL_TEXTURE_CUBE_MAP_POSITIVE_Y, GL_TEXTURE_CUBE_MAP_NEGATIVE_Y, GL_TEXTURE_CUBE_MAP_POSITIVE_Z, or GL_TEXTURE_CUBE_MAP_NEGATIVE_Z.


stratum

Specializes the stratum-of-point list. Stratum 0 is the stand visualize stratum. Stratum n is the nth mipmap simplification visualize.


xoffset

Specializes a texel beginning in the x guidance within the texture regalia.


yoffset

Specializes a texel beginning in the y guidance within the texture regalia.


breadth

Specializes the breadth of the texture subimage.


altitude

Specializes the altitude of the texture subimage.


format

Specializes the format of the pixel data. The pursuit symbolical values are admitted: GL_COLOR_INDEX, GL_RED, GL_GREEN, GL_BLUE, GL_ALPHA, GL_RGB, GL_BGR, GL_RGBA, GL_BGRA, GL_LUMINANCE, and GL_LUMINANCE_ALPHA.


typecast

Specializes the data typecast of the pixel data. The pursuit symbolical values are admitted: GL_UNSIGNED_BYTE, GL_BYTE, GL_BITMAP, GL_UNSIGNED_SHORT, GL_SHORT, GL_UNSIGNED_INT, GL_INT, GL_FLOAT, GL_UNSIGNED_BYTE_3_3_2, GL_UNSIGNED_BYTE_2_3_3_REV, GL_UNSIGNED_SHORT_5_6_5, GL_UNSIGNED_SHORT_5_6_5_REV, GL_UNSIGNED_SHORT_4_4_4_4, GL_UNSIGNED_SHORT_4_4_4_4_REV, GL_UNSIGNED_SHORT_5_5_5_1, GL_UNSIGNED_SHORT_1_5_5_5_REV, GL_UNSIGNED_INT_8_8_8_8, GL_UNSIGNED_INT_8_8_8_8_REV, GL_UNSIGNED_INT_10_10_10_2, and GL_UNSIGNED_INT_2_10_10_10_REV.


data

Specializes a cursor to the visualize data in retentiveness.


Сравни с glTexImage2D мне кажется тут все по аналогии)


1. грузишь «общую текстуру» получаешь указатель на данные *pImage


Цикл для кадров…

2. glGenTextures генерируешь текстуру в gl’e ( для каждого кадра я полагаю придется)) )

3. glBindTexture биндиш текстуру тек. кадра

4. фильтра…

glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR );

glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR );


5. грузишь текстуру glTexSubImage2D ( GL_TEXTURE_2D, 0 /*0-й мип*/, xoffset, yoffset, breadth, altitude, GL_RGBA, GL_UNSIGNED_BYTE, pImage)


Возврат в начало цикла если есть еще кадры.


6. удаление указателя на общую текстуру erase pImage

В общих чертах так)


тема на форуме



Поиск сообщений в possdacint
Страницы: 2 [1] Календарь