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

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

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

 

 -Статистика

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

Habrahabr/New








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

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

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

Дайджест продуктового дизайна, июль 2017

Четверг, 03 Августа 2017 г. 09:31 + в цитатник
Уже семь лет я публикую регулярные обзоры свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель 2010-июнь 2017.

Дайджест продуктового дизайна, июль 2017


Паттерны и лучшие практики


The Most Hated Online Advertising Techniques
Интересное исследование Nielsen/Norman Group на тему навязчивости разных форматов рекламы в вебе и на мобильных. Правда, оно делалось на базе wireframes, а не реальных баннеров, но в любом случае смотрели на влияние разных отвлекающих факторов и в целом анти-рейтинг выглядит логично.

The Most Hated Online Advertising Techniques

В продолжение темы:

Designing The Perfect Date And Time Picker
Виталий Фридман в деталях разбирает паттерны выбора даты и времени. Много интересных примеров и советов по выбору подходящего к конкретной задаче решения.

Designing The Perfect Date And Time Picker

В продолжение темы:

Design for Fingers, Touch and People, part 3
Окончание новой редакции статьи Steven Hoober о том, как пользователи работают с мобильными телефонами.

Mobile Subnavigation
Raluca Budiu из Nielsen/Norman Group разбирает паттерны навигации второго уровня на мобильных.

Five Degrees of User Assistance
Jim Ross приводит пять стадий вовлечения проактивного интерфейса в работу с пользователем — от простого предоставления справочной информации до самостоятельного решения проблемных ситуаций.

Small Pictures on Big Screens — Scaling Up from Mobile to Desktop
Amy Schade из Nielsen/Norman Group напоминает про важность оптимизации мобильных изображений для большого веба — иначе они обрезаются или занимают слишком много места.

Product Design for Sustainability
Артём Дашинский показывает, как улучшение интерфейсных решений способно помочь окружающей среде — например, экономить бумагу для принтера или оптимизировать маршруты.

Исследования Baymard Institute


Дизайн-системы и гайдлайны


Paradigm — дизайн-система Mail.Ru Group, часть 1: визуальный язык
Несколько лет портальная дизайн-команда Mail.Ru Group занимается обновлением и унификацией продуктов. У нас сформировалась дизайн-система, на которой работают медиа-проекты, мобильный веб и частично productivity-сервисы (постепенно подключаются и другие продукты), сформировался стиль пиктограмм и иллюстраций, стандартизируются промо-письма и промо-сайты. Конечно, ещё не во всех сервисах всё хорошо, а где-то первый редизайн не решил всех проблем, но огромный рывок за прошедшие годы трудно не заметить. Чтобы ускорить процесс обновления и сделать нашу работу публичной, мы открываем наружу часть нашей дизайн-системы Paradigm (это внутренний инструмент, мобильной версии пока нет).

Paradigm — дизайн-система Mail.Ru Group, часть 1: визуальный язык

Что такое дизайн-система в нашем понимании?
  1. Визуальный язык — определяет то, как мы создаём интерфейсы продуктов. Как и в обычном языке, у нас есть алфавит (переменные), слова (элементы интерфейса), предложения (компоненты) и цельные тексты (экраны и продукты). Алфавит неизменен, словарный запас постепенно меняется со временем, а вот предложения и тексты из них создаются всегда разные. Он показан на design.mail.ru/paradigm/.
  2. Единые компоненты на технологическом уровне — единственный источник правды. Дизайн «вшит» в них, сервисы получают и обновляют их из единого репозитория. Продукты под брендом Mail.Ru, которые используют их на практике: медиапроекты, мобильный веб, часть productivity-сервисов. Они пока доступны только внутри компании.
  3. Шаблоны для дизайнерских инструментов — способ быстро показать идею, просто высокоуровневые скетчи. В идеальной ситуации макеты не верстают, а собирают из единых компонентов. Мы писали о них в начале года.

Начав внедрение дизайн-системы в 2012 году, в 2015 году мы сформировали её целостное видение. Впереди немало дел, но публикация текущих наработок — приятная веха в развитии платформы (забавно, что ровно три года назад масштабно обновилась портальная навигация). Мы подробно описали общие принципы и текущее состояние на Хабре. Будем рады обратной связи и советам.

P.S. Кстати, запустили два новостных канала для анонсов дизайн-команды в Фейсбуке и в Твиттере. Ну и на всякий пожарный Медиум.

Adopting Design Systems
Одна из немногих статей на тему менеджмента процесса унификации продуктов с помощью дизайн-системы. Nathan Curtis описывает поэтапный план внедрения платформы и даёт советы по работе с продуктовыми командами. В продолжение темы:

Empty States? More like You-Have-No-Idea-How-Much-Work-Goes-Into-Those States, amirite?
Meg Robichaud рассказывает о работе над серией иллюстраций для нулевых состояний интерфейса Shopify. Очень интересный подход, где иллюстрация передаёт нужное настроение в текущем сценарии — успех, неудача, нейтральное сообщение.

Empty States? More like You-Have-No-Idea-How-Much-Work-Goes-Into-Those States, amirite?

Handling spacing in a UI component library
Chris Pearce размышляет на тему того, как описывать отступы между компонентами в дизайн-системе. Он разбирает три подхода: делать отступ частью компонента, делать отдельные элементы для отступов, определять расстояния на уровне «родителя». Мы используем первый подход.

Fractures
CSS-фреймворк для модульного дизайна.

Android O

Designing Adaptive Icons

iOS 11


Понимание пользователя


Updated Empathy Map Canvas
Dave Gray обновил свой популярный шаблон карты эмпатии. В него добавлены цели, порядок заполнения и подсказки.

Updated Empathy Map Canvas

Empathy Prompts
Коллекция мотивационных призывов для дизайнеров, направленных на внимание к пользователям с техническими и физическими ограничениями.

Media Use Habits — What, Why, When, and How People Read Online
Мои коллеги Олеся Куколева, Анна Преображенская и Ольга Сидорова опубликовали на UXmatters результаты недавнего качественного исследования того, как пользователи читают медиа. В ходе него респонденты вели дневники, собрав 83 часа видео реального чтения новостных сайтов.

Информационная архитектура, концептуальное проектирование, контент-стратегия


Which Maps Do You Really Need?
James Kalbach разбирает типы карт взаимодействия. Он делит их на три группы — модели пользователей, контекста и целей, а также будущего. В продолжение темы:

Information Architecture Lenses
Dan Brown обновил свою классификацию принципов информационной архитектуры и составил список 43 «линз», через призму которых можно оценивать эффективность интерфейсных решений.

Information Architecture Lenses

Service Design at a speed and scale
Diego Dalia рассказывает о том, как формировался подход к работе с проектированием услуг в IBM на базе их версии дизайн-мышления.

Service Design at a speed and scale

The Name Game
Stacey King Gordon рассказывает о подходе Facebook к названию продуктов, функций и экранов. Они должны быть достаточно простыми и не создавать лишних смыслов.

Проектирование и дизайн экранов интерфейса


Design Versioning — It’s true, it’s here, let’s talk and learn more about it
Caio Calderari сделал обзор инструментов контроля версий для дизайнеров. В основном они работают с макетами Sketch и основаны на Git.

Design Versioning — It’s true, it’s here, let’s talk and learn more about it

Kactus
Инструмент контроля версий для макетов в Sketch на базе Git. Базовая версия бесплатна.

Adobe XD

Sketch

Principle
  • Вышла версия 3.0. Тонна мелких и средних улучшений интерфейса.

Kite
  • Вышла версия 1.5. Из новинок — аналог драйверов из Principle, плюс новые события для создания интерактивных прототипов. Вообще, на стороне Kite немало преимуществ: куча событий для работы, большие возможности для работы с анимацией, включая path-анимацию. Плюс генерация кода, который худо-бедно (скорее худо) можно использовать в своём приложении. Из минусов — неполноценное мобильное приложение и упор на работу со свойствами и значениями в противоположность WYSIWYG Principle.

Figma










Framer

Omnigraffle

Vectr

Paper Sizes — The best resource for International Paper Sizes, Dimensions & Formats
Шикарная памятка по стандартным размерам бумажных форматов и документов.

Gifmock — Easily create high quality GIFs
Приложение помогает собрать анимацию интерфейса в оптимизированный по качеству и размеру GIF. Есть плагин для Sketch.

Ghost 1.0
Одна из самых перспективных блог-платформ Ghost вышла из многолетней беты.

Пользовательские исследования и тестирование, аналитика


Search-Log Analysis — The Most Overlooked Opportunity in Web UX Research
Хорошая методичка по анализу внутренних поисковых запросов на сайте от Susan Farrell из Nielsen/Norman Group. Где смотреть, что искать, какие выводы и улучшения делать.

Search-Log Analysis — The Most Overlooked Opportunity in Web UX Research

Tree Testing, part 2 — Interpreting the Results
Вторая часть обзора методик тестирования информационной архитектруры от Kathryn Whitenton из Nielsen/Norman Group. Она показывает, как собирать данные и сравнивать результаты тестов.

Cassette 2.0
Вышла вторая версия приложения с поддержкой большего количества языков и кучей других улучшений.

How We Conducted User Research in The Arab Market
Рассказ о пользовательском исследовании в Объединённых Арабских Эмиратах, в ходе которого UX Studio искали особенности местного рынка, чтобы вывести на него существующий продукт.

Another Lens
Набор структурированных советов по проведению пользовательских исследований в виде карточек от дизайн-команды Airbnb.

Визуальное программирование и дизайн в браузере


Ben Coleman и Dan Goodwin — Designing UX: PrototypingBen Coleman и Dan Goodwin — Designing UX: Prototyping
Издательство Sitepoint выпустило в марте 2017 книгу Ben Coleman и Dan Goodwin «Designing UX: Prototyping». UXmatters публикует главу 7 из неё, посвящённую HTML-прототипам.


Supernova Studio
Ещё один инструмент, который обещает превратить макеты в работающее приложение для мобильных платформ, хотя на них постоянно жалуются за неэффективный код. На этот раз — из макетов Sketch в React Native. Анонс.

Новые скрипты

CSS-анимация

Website Speed Test — Image Analysis Tool by Cloudinary
Сервис помогает оптимизировать графику на сайте. Он не только показывает проблемы, но и подсказывает, как решить их с приемлемым качеством, автоматически генерируя уменьшенные изображения. Как он работает и зачем создавался.

Tooltips & Toggletips
Heydon Pickering продолжает разбирать стандартные компоненты дизайн-системы на предмет учёта требований доступности. В этом выпуске — подсказки для элементов интерфейса.

Метрики и ROI


Monitoring User Experience Through Product Usage Metrics
Jerrod Larson приводит большую коллекцию метрик, которые полезно отслеживать продуктовому дизайнеру в своей работе. Для каждой из них он показывает, как именно и зачем их считать.

UX-стратегия и менеджмент


The Maturity of UX Organizations
Jeff Sauro запустил опросник на тему зрелости компаний в плане дизайна и приводит первые выдержки из опроса 150 дизайнеров. Получился интересный подход с распределением участников по уровню зрелости — такой же должен я планировал сделать на своём сайте о UX-стратегии. В другой выкладке говорится о соотношении дизайнеров и пользовательских исследователей к разработчикам.

Changing Company Culture Requires a Movement, Not a Mandate
Bryan Walker и Sarah A. Soule рассказывают, как IDEO помогли изменить корпоративную культуру фармацевтической компании Dr. Reddy.

Jennifer Mueller — Creative ChangeBook Review: Creative Change
В начале года издательство Houghton Mifflin Harcourt выпустило книгу Jennifer Mueller «Creative Change» о том, как не просто предлагать креативные и прорывные идеи, а добиваться их внедрения. UXmatters сделали её обзор.


Продуктовый менеджмент и аналитика


Making Good Decisions as a Product Manager
Продуктовый директор Shopify Brandon Chu рассказывает о своём подходе к принятию решений — как выделить быстрые, где не страшно ошибиться, и действительно важные, где нужно детально продумать последствия. Его шаблон для принятия решений учитывает UX.

Making Good Decisions as a Product Manager

Great PMs don’t spend their time on solutions
Paul Adams рассказывает, как строится процесс определения проблемы в Intercom. Они уделяют 40% времени понимают того, что и зачем нужно сделать, и только после этого переходят к проработке решения.

Great PMs don’t spend their time on solutions

Кейсы


Building for China
Vivian Wang рассказывает о запуске Airbnb в Китае и достаточно глубоком подходе к локализации продукта.

У нас новые онлайны!
Команда Медузы рассказывает о создании нового интерфейса текстовых трансляций. Другие кейсы:


История


How I Managed to Design the Most Successful Educational Computer Game of All Time
R. Philip Bouchard в деталях рассказывает о создании второй версии легендарной образовательной игры Oregon Trail, вышедшей в 1985 году.

How I Managed to Design the Most Successful Educational Computer Game of All Time

Тренды


Uncovering Voice UI Design Patterns
Joe Kappes и Jiwon Paik из Cooper разбирают паттерны взаимодействия с голосовыми интерфейсами. Это 5 приёмов, которые подходят для разных задач.

Uncovering Voice UI Design Patterns

Human-Centered Machine Learning
Josh Lovejoy и Jess Holbrook из Google здорово описали подход к работе с возможностями машинного обучения для дизайнера. Как общаться с разработчиками и аналитиками и прототипировать сервисы до того, как алгоритмы готовы.

Human-Centered Machine Learning

В продолжение темы:

Алгоритмический дизайн: Рассылка
Обновил сайт про алгоритмический дизайн кучей новых сильных примеров и запустил рассылку (будет выходить раз в месяц-полтора на английском). Подписывайтесь :)

The Newest Email Design Trends of 2017
Обзор визуальных трендов 2017 года в письмах рассылки.

The Newest Email Design Trends of 2017

Виртуальная реальность

Мессенджеры и боты

Умные часы и браслеты

What is Timeless Web Design?
Chris Coyier собрал мнения известных дизайнеров и разработчиков на тему того, можно ли создать сайт, который не устареет за 10 лет. Получилась занятная дискуссия.

Для общего и профессионального развития


Большой список Telegram-каналов для дизайнеров, менеджеров продуктов и аналитиков
Алексей Иванов составил список Telegram-каналов для дизайнеров.

Большой список Telegram-каналов для дизайнеров, менеджеров продуктов и аналитиков

A Rather Comprehensive Collection of Design Podcasts
Ste Grainer собрал приличную подборку подкастов по дизайну.

Desmentor — Find A Design Mentor
Проект помогает найти ментора начинающим дизайнерам.

Дэниэл Бурка, Google Ventures: «Дизайн сейчас создается не в фотошопе, скетче или коде»
Выдержки из интервью Daniel Burka из Google Ventures о его видении роли продуктового дизайнера.

What to Do When You’re the Only UX Designer on a Project?
Панельная дискуссия на тему того, что делать, если вы — единственный дизайнер в компании.

Enterprise UX Industry Report 2017-2018
UXPin провели опрос около 3000 дизайнеров в крупных и маленьких компаниях на тему внутренней организации. Вопросы местами странноваты (например, в одну кучу смешаны дизайн-системы и библиотеки паттернов), но есть интересные выводы.

Люди и компании в отрасли


IBM


Подписывайтесь на рассылку! Письмо приходит один раз в месяц.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334722/


Метки:  

Об «Элегантных объектах» и евангелистах

Четверг, 03 Августа 2017 г. 00:44 + в цитатник

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


Для себя я разделил полезную IT-литературу на три категории: ремесленная, научная и агитационная. Первая помогает улучшить процесс разработки, разобраться в каком-то языке программирования или технологии, вторая — глубоко погрузиться в какую-то задачу, понять основные принципы решения различных проблем, сформировать целостный взгляд на вещи. Эти два типа отличает сдержанный эмоциональный фон текста, богатый ссылками на другие источники контекст и основательно подкреплённые фактами из реальных успешных (или не очень) проектов описания подходов и методик. Книги третьего типа пишут евангелисты. Недавно мне довелось прочитать «Elegant Objects» Егора Бугаенко. Многие устоявшиеся вещи, которые мы привыкли считать лучшими практиками, просто и понятно названы в книге злом: геттеры, сеттеры, ORM, DI контейнеры и прочие, казалось бы, облегчающие работу программиста техники.


Впрочем, такие эмоционально насыщенные тексты, если в них есть последовательный подход (в «Elegant Objects» это пуристский взгляд на ООП), а не только шаманизм и истерия, обычно заставляют задуматься. Например, те же геттеры и сеттеры всегда выглядели для меня подозрительно. С одной стороны, что-то они всё-таки инкапсулируют. С другой — все частные свойства как будто бы и перестают быть частными. Вообще, когда я с помощью IDE автоматически создаю набор этих методов для свойств какого-нибудь DTO, меня начинают мучить сомнения в необходимости программистской человеческой прослойки между идеей продукта и её реализацией.


Если приехать в незнакомый город, то некоторые детали замечаешь лучше местных жителей, которые ходят по этим улицам каждый день. С привычным процедурно-имеративным подходом мы, возможно, не совсем правильно воспринимаем объекты. Автор «Elegant Objects» очень уважительно относится к ним, соблюдая границы их частных владений. Основной принцип — инкапсуляция, последовательно упоминается на протяжении всего текста. Все эти сверкающие чистотой стеклянные здания чистого ООП кажутся чужими в стране промышленной разработки программного обеспечения. И в этом смысле книга позволяет посмотреть на привычные вещи незамутнённым взглядом иностранца в незнакомом городе.


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


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

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

https://habrahabr.ru/post/334766/


Метки:  

Судьба программистов в РФ или как уехать из города Энска

Среда, 02 Августа 2017 г. 23:38 + в цитатник
В те давние времена, когда истории про солитера у отца Виндоуса были уже старыми, а Paradox DB был еще вполне в ходу, из разных школ город Энска и рядом расположенного города Эрска выпустились три будущих программиста – товарищи под псевдонимами S, G и V. Вряд ли кто-то из них знал, что будет именно программистом – никто из них не поступил на известный своей отдаленностью от цивилизации «программисткий» факультет университета города Энска.

TL/DR – чего учили 5-10-15 лет назад, и чего из этого пригодилось где-то около 2015 года при трудоустройстве в не самые мелкие кампании, в РФ и не в РФ.
Как работает трудоустройство и карьерный рост на трех примерах из жизни.
Ничего нового, даже список книжек старый. Серебряной пули не будет.


Товарищ S учился понемногу, чему нибудь и как нибудь, и начинал, как и многие, с B3QQ4. Закончил в итоге Высшее Учебное Заведение, с дипломом.
Товарищ G учился близко к теме — изготовление и программирование микроконтроллеров, специальность называется «вычислительные машины, комплексы, системы и сети». Мнение товарища: фишка в том, что название специальности откровенная ложь, она была жёстко заточена на микросхемы, и программирование изучали достаточно поверхностно. Была еще специальность «программное обеспечение», на которой как раз это учили, но она была очень илитне, я мог на неё поступить, но хотел с железом работать.
Самым образованным внезапно оказался товарищ V – он закончил университет в областном центре города Энска по специальности АСУ ТП, с них и начинал.

Начну с товарища G.
Особые приметы: при звуках группы Слот теряет волю.
Бородат.
Начинал программировать на basic под БК, потом спектрум, паскаль, дельфи. Потом – всякое разное. На первой работе почти сразу перешли на С#, когда он (С#) только вышел. На предпоследнем месте работы был занят программированием под IOS, с которого не менее внезапно перешел на Java под Android.
После чего, не менее внезапно (как внезапно – откликался на вакансии, см. ниже), был приглашен на 33 разных собеседований. Прошел собеседование со второго раза, сдал (после длительной учебы – упражнения, грамматика) IELTS на много баллов (кажется, 8.5), собрал носки и уехал в Голландию, где и пребывает по сей день, программируя для одной достаточно известной организации.

Чего учил и чего пригодилось:
Я специально не учился, у меня было много непрерывного стажа по специальности и, в силу специфики профессии, я осваивал несколько разных направлений программирования, которые случайно оказались правильными. Вот как можно добиться успеха? С моей точки зрения очень просто, надо сначала много и тяжело работать на опыт и репутацию, а потом осознать, что ты хочешь чего-то конкретного достичь — и начать этого достигать
Что учить, мне кажется, всё равно. Тут уместна цитата из гоблина: настоящий джигит плывёт не по течению и не против течения, а туда, куда ему надо. Иначе говоря, если тебе чего-то конкретного надо достичь, то, вероятно, надо учить то, что требуется для этого.
Например, когда я собеседовался на текущую работу, на телефонном интервью меня унизили полностью, но потом сказали — мы перезвоним через месяц, давай посмотрим чего ты выучишь. Я сделал выводы и выучил всё то, что они хотели.
Теоретический минимум безусловно помогает, но необходим баланс.
Про что надо знать — скажем что такое треды, что такое объекты, как выделяется память на объекты. Это в большинстве языков есть
Например, уровни сложности (алгоритма) — это одна из вещей, которые меня спрашивали на интервью и которые я не знал.
Но, по большому счёту, ты должен знать две вещи: первое что нужно чтобы сдать проект заказчику, и второе что нужно чтобы пройти интервью. Это две разные вещи, и я, до этой работы, знал только первую. К сожалению, значительное количество людей знает только вторую.

Про кадры и молодежь:
Я постоянно изучал новые технологии в зависимости от того что заказчик хотел.
но это было не так что типа надо развиваться!11 новые технологии! — как вот эти все юные и перспективные любят, а именно что у нас есть проект, надо сделать.
Отсев:
10% на первом интервью остаётся и 10% из этого количества на втором, согласно тому, что HR говорит. И всё равно *** кругом. Мистика
Оценка рынка РФ:
Рынок как рынок, но необходимо ехать в Москву, иначе работа будет по остаточному принципу. Для студентов впрочем нормально, я считаю. Как раз студенты все сразу недолго думая прут в Москву и очень глубоко удивляются что их там никому не надо.
У меня лично не было желания туда ехать, и я перерос возможности контор доступных в Энске.
На текущее и предпоследнее место работы попал через:
на linkedin и careers.google.com откликался и вот попал.
Кстати, неплохой способ — написать в контору, в которую ты хочешь, и попытаться туда устроиться. Если даже ты вообще не подойдёшь, ты будешь знать, чего тебе надо учить.

Товарищ V.
Не бородат.
Начинал, внезапно, почти по специальности – завод, программирование микроконтроллеров, испытательные стенды. Потом не менее успешно сбежал в зону тогда еще закрытой торговли, где освоил C#, C++, ASP и ASP.Net + MSSQL. Плюсом пришли Subversion, NUnut, SVN. Из дальних стран спустя пятилетку вернулся в родной Энск, где перешел на чистый С, немного Java, и все такое.
Сменил работу и полез глубоко-глубоко в Web — css3, doT, ajax, javascript, jquery и так далее.
После еще пятилетки сидения на печи почему-то решил, что в нем таки есть немного еврейских корней и поехал попрактиковаться в Израиль. Однако оказалось, что таки нет (Мнение: Во-первых, стресс, а во-вторых, тестов мало в Энске писал, а у них на все автотесты), поэтому собрал силы и переехал работать снова на Кипр, где и занимается redux, rxjs, typescript и все такое. Очень ругает Angular.

Чего учил и чего пригодилось:
После детской книжки Вирта (Н.Вирт «Алгоритмы и структуры данных) научился более-менее писать простые алгоритмы, заодно узнал про поиск, сортировку, хеши.
Всякое по функциональному программированию — сейчас оно много где используется. Неглубоко, но основы знать стоит. Классика про ООП типа банды четырех —
  • Приёмы объектно-ориентированного проектирования. Паттерны проектирования (англ. Design Patterns: Elements of Reusable Object-Oriented Software).
  • Александреску А. Современное проектирование на С++: Обобщенное программирование и прикладные шаблоны проектирования = Modern C++ Design: Generic Programming and Design Patterns Applied
  • Гради Буч. Объектно-ориентированный анализ
  • Джеффри Рихтер. Программирование на платформе Microsoft.NET Framework 4.5 на языке C#»
  • Джеффри Рихтер. Windows для профессионалов. Создание эффективных Win32-пpилoжeний с учетом специфики 64-разрядной версии Windows
  • Мозговой М.В. Классика программирования — алгоритмы, языки, автоматы, компиляторы.


Оценка рынка РФ: работа есть, всякая. Есть и галеры, в смысле большие опен-спейсы, набитые программистами.
На текущее и предпоследнее место работы попал через:
Мой круг.
Мнение про текущие кадры:
6 из 10 не могут замену подстроки написать в онлайне. В редакторе и во время собеседования. Отсев — остается примерно 1 из 15-ти, найденных кадровиками. Кто-то отваливается после первого интервью, кто-то после тестового задания. Сделали простой онлайн-тест по js, чтоб лишний час на первое собеседование не терять.
Массовая проблема: непонимание нужности типизации в вебе — проверка типов с автовыводом типов, как в ts, flow, scala
Интересно, что хотя культура кода" везде более-менее и есть, требований нормальных почти нигде нет. Того, что называется управления требованиями и спецификации поведения.
Про недавний опросник на хабре: Собеседование для фронтенд-разработчика на JavaScript: самые лучшие вопросы
Хороший вопросник, но у нас по нему никто бы не прошёл. До вопросов средней сложности дошёл бы один из 15, а их прошёл бы один из 30-ти, может быть.

Товарищ S.
Не бородат.
После непродолжительной, но крайне интересной карьеры в фирме у одного общего знакомого, точнее во время этой карьеры, взял и выучил основы С, тогда даже без ++ и #, после чего устроился в одну более другую фирму на поддержку ПО, джуниором. Через пары-тройку лет учебы и работы переехал в Москву, там сменил пару работ, в итоге оказался в одном нефгазмяссервисе, в одном из многочисленных его подразделений, после чего перебрался в тот же нефгазмяс, но уже международный. Думает о релокации, и, похоже, вскоре переедет.
До сих пор пишет на всяком С, и заодно заведует всяким разным SQL.

Чего учил и чего пригодилось:
Сначала С, потом C++ / #. Весной сдал очередной экзамен по треку MS SQL.

Оценка рынка РФ: Работа есть, всякая.
На текущее и предпоследнее место работы попал через: hh.ru и кадровое агентство.
Мнение:
Нет универсального рецепта. Учить английский. Лет 15 назад все на рынке кричали что будущее за Oracle и надо учить в ту сторону, лет 7 начали топить за SAP, сейчас уже даже сложно что то одно выделить. Раньше рынок был более статичным — можно было научиться кодить под 1С и лет 15 пожинать плоды. В целом согласен в товарищем G. — сначала нарабатываешь опыт, потом понимаешь что тебе интересно и начинаешь усилено копать в эту сторону.
Ну и непрерывное самообразование

Что читать:
Энциклопедия профессора Фортрана.
Фигурнов В. Э. IBM PC для пользователя
Д. Кнут — Искусство программирования (1-й, 2-й том)
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334764/


Метки:  

[recovery mode] JavaScript как явление

Среда, 02 Августа 2017 г. 22:26 + в цитатник


Сообщество nodejs безумно, и судя по тому что в 2016-2017 годах в различных рейтингах JavaScript брал первое место по популярности вытеснив оттуда с небольшим отрывом Java — безумие в последнее время действительно станосится массовым. Казалось бы — не хочешь не кушай, пиши на своём любимом Elixir / Erlang / Lisp / Haskell / любом другом языкое с хорошим дизайном и в ус не дуй, но в текущей ситуации к сожалению это правило перестаёт работать и приходится прилагать некоторые усилия чтобы его соблюдать.

В чём причина популярности такого реально хренового языка как JavaScript? В принципе в том же в чём и причина популярности Java, да и вообще почти всех явлений культуры и общества — в бабле. Когда такие гиганты как Facebook, Google, Microsoft и Twitter методично вливают многомиллионные потоки кровавых долларов в JavaScript инфраструктуру, пишут фреймворки, библиотеки, придумывают стандарты и архитектуры — становится действительно трудно это игнорировать. Настолько сильное вливание бабла вызывает бешеный хайп-драйвен-девелопмент. Работодатель хочет видеть у себя React, Redux, Relay, Realm, Flux, Babel, Webpack / Grunt / Brunch и ещё с десяток модных слов от наших любимых корпораций которых я даже не знаю. И ещё всё это приправлено сверху кучей плагинов для этих же технологий, всех сортов и расцветок из нашего любимого npm. Технологии от корпораций для того чтобы у нас были технологии от корпораций и минифицированный js-бандл весом 15Мб для простого SPA, о да.

В какой-то момент огромный спрос на разработку на действительно ужасном языке породил огромное множество порой довольно странных компиляторов в JavaScript из других, более приемлимых языков. Вполне логично, разработчики мучимые сильнейшим когнитивным диссонансом ( хочу денег, но не хочу JS ) как-то пытались ( и пытаются ) уменьшить боль от разработки на JavaScript. Лично я пробовал довольно много языков из этого списка, какое-то время писал на CoffeeScript подобных языках, наиболее удачный пример LiveScript — из коробки карринг, пайпы, отсутствие дурацких скобочек, точек с запятой, циклов и return-ов. Пробовал даже PureScript — пример компиляции Haskell кода ( с иммутабельностью, монадами и чудесной системой сильных типов ) в JavaScript. На деле же конечно все эти языки не являются коммерчески востребованными по очевидным причинам — нет миллионных вливаний от корпораций в развитие инфраструктуры. Если бы таковые были — зуб даю, все поголовно бы писали на Haskell и рассказывали бы друг другу за чашечкой смузи покручивая спиннер о новых монадах и аппликативных функторах от Facebook.

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

  • однопоточный рантайм ( в 2017 году!!! )
  • отсутствие единой системы / стандартов реализации модулей ( опять же, 2017 год на дворе )
  • отсутствие единых стандартов структуры проекта ( все творят как хотят, в исходниках бывает очень сложно разобраться )
  • слабые типы с неявными ( и порой довольно странными ) преобразованиями
  • отсутствие нормальных классов / ООП
  • отсутствие единого вменяемого и работающего статического анализатора кода ( добро пожаловать в чудесный мир глупейших ошибок типа undefined is not a function )
  • отсутствие вывода типов в самом языке или в каком-либо инструменте
  • этот чудесный контекст this ( что это значит this в этом месте кода — объект? функция? )
  • абсолютно дурацкая реализация pattern matching ( паттерн матчишь пустой список / объект — без проблем, извлекаешь оттуда undefined, ты же именно это имел ввиду, да? ) и здесь опять привет cannot read property foo of undefined
  • отсутствие единой технологии работы с асинхронным кодом — колбэки, примисы, фьючерсы, async ( если в проекте более одной зависимости из npm то гарантированно в коде появятся все из них вперемешку )
  • const ( который на самом деле НЕ const )
  • абсолютно безумный npm с пакетами качества «братишка я тебе покушать принёс» ( и даже вот с таким )

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

В общем JavaScript ужасен как ни крути, но он имеет бешеную популярность благодаря баблу и низкому порогу входа. Когда у тебя перед носом водят пачкой зелёных купюр — трудно удержаться, но я держусь. Психическое здоровье дороже. Кстати недавно читал про активность Facebook в области языка Ocaml — так что возможно есть свет в конце тоннеля, но это не точно.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334760/


Метки:  

Больше макросов! Хороших и разных

Среда, 02 Августа 2017 г. 20:41 + в цитатник
image

Любители вы Сишные макросы, так как люблю их я?

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

Для решения этих проблем издревле повелось приводить константу к дроби с основанием степень двойки. Например число 0.4 приближенно можно представить как 102/256. Тогда умножение переменной «а» на 0.4, будет выглядеть следующим образом: (а*102)>>8.
Но при разработке реальных программ можно «выстрелить себе в ногу». Для сохранности ваших ног и всего остального рекомендую пользоваться следующими макросами.

Листинг файла «um.h» под катом
Листинг файла um.h
#ifndef __UM_H
#define __UM_H
//Макросы для умножения на дробную константу в целых числах

//константа кратная 1/8
#define UM8(CONST_FLOAT,CHISLO_INT) \
                 ((CONST_FLOAT+1.0/16)<(1.0/8))?((CHISLO_INT*0)>>3):\
                  (((CONST_FLOAT+1.0/16)<(2.0/8))?((CHISLO_INT*1)>>3):\
                    (((CONST_FLOAT+1.0/16)<(3.0/8))?((CHISLO_INT*2)>>3):\
                      (((CONST_FLOAT+1.0/16)<(4.0/8))?((CHISLO_INT*3)>>3):\
                        (((CONST_FLOAT+1.0/16)<(5.0/8))?((CHISLO_INT*4)>>3):\
                          (((CONST_FLOAT+1.0/16)<(6.0/8))?((CHISLO_INT*5)>>3):\
                            (((CONST_FLOAT+1.0/16)<(7.0/8))?((CHISLO_INT*6)>>3):\
                              (((CONST_FLOAT+1.0/16)<(8.0/8))?((CHISLO_INT*7)>>3):\
                                (CHISLO_INT)\
                               )\
                             )\
                           )\
                         )\
                       )\
                     )\
                   )

//константа кратная 1/16
#define UM16(CONST_FLOAT,CHISLO_INT) \
 ((CONST_FLOAT+(1.0/32))<(1.0/16))?((CHISLO_INT*0)>>4):\
(((CONST_FLOAT+(1.0/32))<(2.0/16))?((CHISLO_INT*1)>>4):\
(((CONST_FLOAT+(1.0/32))<(3.0/16))?((CHISLO_INT*2)>>4):\
(((CONST_FLOAT+(1.0/32))<(4.0/16))?((CHISLO_INT*3)>>4):\
(((CONST_FLOAT+(1.0/32))<(5.0/16))?((CHISLO_INT*4)>>4):\
(((CONST_FLOAT+(1.0/32))<(6.0/16))?((CHISLO_INT*5)>>4):\
(((CONST_FLOAT+(1.0/32))<(7.0/16))?((CHISLO_INT*6)>>4):\
(((CONST_FLOAT+(1.0/32))<(8.0/16))?((CHISLO_INT*7)>>4):\
(((CONST_FLOAT+(1.0/32))<(9.0/16))?((CHISLO_INT*8)>>4):\
(((CONST_FLOAT+(1.0/32))<(10.0/16))?((CHISLO_INT*9)>>4):\
(((CONST_FLOAT+(1.0/32))<(11.0/16))?((CHISLO_INT*10)>>4):\
(((CONST_FLOAT+(1.0/32))<(12.0/16))?((CHISLO_INT*11)>>4):\
(((CONST_FLOAT+(1.0/32))<(13.0/16))?((CHISLO_INT*12)>>4):\
(((CONST_FLOAT+(1.0/32))<(14.0/16))?((CHISLO_INT*13)>>4):\
(((CONST_FLOAT+(1.0/32))<(15.0/16))?((CHISLO_INT*14)>>4):\
(((CONST_FLOAT+(1.0/32))<(16.0/16))?((CHISLO_INT*15)>>4):\
(CHISLO_INT)\
  )))))))))))))))

//константа кратная 1/32
#define UM32(CONST_FLOAT,CHISLO_INT) \
 ((CONST_FLOAT+(1.0/64))<(1.0/32))?((CHISLO_INT*0)>>5):\
(((CONST_FLOAT+(1.0/64))<(2.0/32))?((CHISLO_INT*1)>>5):\
(((CONST_FLOAT+(1.0/64))<(3.0/32))?((CHISLO_INT*2)>>5):\
(((CONST_FLOAT+(1.0/64))<(4.0/32))?((CHISLO_INT*3)>>5):\
(((CONST_FLOAT+(1.0/64))<(5.0/32))?((CHISLO_INT*4)>>5):\
(((CONST_FLOAT+(1.0/64))<(6.0/32))?((CHISLO_INT*5)>>5):\
(((CONST_FLOAT+(1.0/64))<(7.0/32))?((CHISLO_INT*6)>>5):\
(((CONST_FLOAT+(1.0/64))<(8.0/32))?((CHISLO_INT*7)>>5):\
(((CONST_FLOAT+(1.0/64))<(9.0/32))?((CHISLO_INT*8)>>5):\
(((CONST_FLOAT+(1.0/64))<(10.0/32))?((CHISLO_INT*9)>>5):\
(((CONST_FLOAT+(1.0/64))<(11.0/32))?((CHISLO_INT*10)>>5):\
(((CONST_FLOAT+(1.0/64))<(12.0/32))?((CHISLO_INT*11)>>5):\
(((CONST_FLOAT+(1.0/64))<(13.0/32))?((CHISLO_INT*12)>>5):\
(((CONST_FLOAT+(1.0/64))<(14.0/32))?((CHISLO_INT*13)>>5):\
(((CONST_FLOAT+(1.0/64))<(15.0/32))?((CHISLO_INT*14)>>5):\
(((CONST_FLOAT+(1.0/64))<(16.0/32))?((CHISLO_INT*15)>>5):\
(((CONST_FLOAT+(1.0/64))<(17.0/32))?((CHISLO_INT*16)>>5):\
(((CONST_FLOAT+(1.0/64))<(18.0/32))?((CHISLO_INT*17)>>5):\
(((CONST_FLOAT+(1.0/64))<(19.0/32))?((CHISLO_INT*18)>>5):\
(((CONST_FLOAT+(1.0/64))<(20.0/32))?((CHISLO_INT*19)>>5):\
(((CONST_FLOAT+(1.0/64))<(21.0/32))?((CHISLO_INT*20)>>5):\
(((CONST_FLOAT+(1.0/64))<(22.0/32))?((CHISLO_INT*21)>>5):\
(((CONST_FLOAT+(1.0/64))<(23.0/32))?((CHISLO_INT*22)>>5):\
(((CONST_FLOAT+(1.0/64))<(24.0/32))?((CHISLO_INT*23)>>5):\
(((CONST_FLOAT+(1.0/64))<(25.0/32))?((CHISLO_INT*24)>>5):\
(((CONST_FLOAT+(1.0/64))<(26.0/32))?((CHISLO_INT*25)>>5):\
(((CONST_FLOAT+(1.0/64))<(27.0/32))?((CHISLO_INT*26)>>5):\
(((CONST_FLOAT+(1.0/64))<(28.0/32))?((CHISLO_INT*27)>>5):\
(((CONST_FLOAT+(1.0/64))<(29.0/32))?((CHISLO_INT*28)>>5):\
(((CONST_FLOAT+(1.0/64))<(30.0/32))?((CHISLO_INT*29)>>5):\
(((CONST_FLOAT+(1.0/64))<(31.0/32))?((CHISLO_INT*30)>>5):\
(((CONST_FLOAT+(1.0/64))<(32.0/32))?((CHISLO_INT*31)>>5):\
(CHISLO_INT)\
  )))))))))))))))))))))))))))))))



//константа кратная 1/64
#define UM64(CONST_FLOAT,CHISLO_INT) \
 ((CONST_FLOAT+(1.0/128))<(1.0/64))?((CHISLO_INT*0)>>6):\
(((CONST_FLOAT+(1.0/128))<(2.0/64))?((CHISLO_INT*1)>>6):\
(((CONST_FLOAT+(1.0/128))<(3.0/64))?((CHISLO_INT*2)>>6):\
(((CONST_FLOAT+(1.0/128))<(4.0/64))?((CHISLO_INT*3)>>6):\
(((CONST_FLOAT+(1.0/128))<(5.0/64))?((CHISLO_INT*4)>>6):\
(((CONST_FLOAT+(1.0/128))<(6.0/64))?((CHISLO_INT*5)>>6):\
(((CONST_FLOAT+(1.0/128))<(7.0/64))?((CHISLO_INT*6)>>6):\
(((CONST_FLOAT+(1.0/128))<(8.0/64))?((CHISLO_INT*7)>>6):\
(((CONST_FLOAT+(1.0/128))<(9.0/64))?((CHISLO_INT*8)>>6):\
(((CONST_FLOAT+(1.0/128))<(10.0/64))?((CHISLO_INT*9)>>6):\
(((CONST_FLOAT+(1.0/128))<(11.0/64))?((CHISLO_INT*10)>>6):\
(((CONST_FLOAT+(1.0/128))<(12.0/64))?((CHISLO_INT*11)>>6):\
(((CONST_FLOAT+(1.0/128))<(13.0/64))?((CHISLO_INT*12)>>6):\
(((CONST_FLOAT+(1.0/128))<(14.0/64))?((CHISLO_INT*13)>>6):\
(((CONST_FLOAT+(1.0/128))<(15.0/64))?((CHISLO_INT*14)>>6):\
(((CONST_FLOAT+(1.0/128))<(16.0/64))?((CHISLO_INT*15)>>6):\
(((CONST_FLOAT+(1.0/128))<(17.0/64))?((CHISLO_INT*16)>>6):\
(((CONST_FLOAT+(1.0/128))<(18.0/64))?((CHISLO_INT*17)>>6):\
(((CONST_FLOAT+(1.0/128))<(19.0/64))?((CHISLO_INT*18)>>6):\
(((CONST_FLOAT+(1.0/128))<(20.0/64))?((CHISLO_INT*19)>>6):\
(((CONST_FLOAT+(1.0/128))<(21.0/64))?((CHISLO_INT*20)>>6):\
(((CONST_FLOAT+(1.0/128))<(22.0/64))?((CHISLO_INT*21)>>6):\
(((CONST_FLOAT+(1.0/128))<(23.0/64))?((CHISLO_INT*22)>>6):\
(((CONST_FLOAT+(1.0/128))<(24.0/64))?((CHISLO_INT*23)>>6):\
(((CONST_FLOAT+(1.0/128))<(25.0/64))?((CHISLO_INT*24)>>6):\
(((CONST_FLOAT+(1.0/128))<(26.0/64))?((CHISLO_INT*25)>>6):\
(((CONST_FLOAT+(1.0/128))<(27.0/64))?((CHISLO_INT*26)>>6):\
(((CONST_FLOAT+(1.0/128))<(28.0/64))?((CHISLO_INT*27)>>6):\
(((CONST_FLOAT+(1.0/128))<(29.0/64))?((CHISLO_INT*28)>>6):\
(((CONST_FLOAT+(1.0/128))<(30.0/64))?((CHISLO_INT*29)>>6):\
(((CONST_FLOAT+(1.0/128))<(31.0/64))?((CHISLO_INT*30)>>6):\
(((CONST_FLOAT+(1.0/128))<(32.0/64))?((CHISLO_INT*31)>>6):\
(((CONST_FLOAT+(1.0/128))<(33.0/64))?((CHISLO_INT*32)>>6):\
(((CONST_FLOAT+(1.0/128))<(34.0/64))?((CHISLO_INT*33)>>6):\
(((CONST_FLOAT+(1.0/128))<(35.0/64))?((CHISLO_INT*34)>>6):\
(((CONST_FLOAT+(1.0/128))<(36.0/64))?((CHISLO_INT*35)>>6):\
(((CONST_FLOAT+(1.0/128))<(37.0/64))?((CHISLO_INT*36)>>6):\
(((CONST_FLOAT+(1.0/128))<(38.0/64))?((CHISLO_INT*37)>>6):\
(((CONST_FLOAT+(1.0/128))<(39.0/64))?((CHISLO_INT*38)>>6):\
(((CONST_FLOAT+(1.0/128))<(40.0/64))?((CHISLO_INT*39)>>6):\
(((CONST_FLOAT+(1.0/128))<(41.0/64))?((CHISLO_INT*40)>>6):\
(((CONST_FLOAT+(1.0/128))<(42.0/64))?((CHISLO_INT*41)>>6):\
(((CONST_FLOAT+(1.0/128))<(43.0/64))?((CHISLO_INT*42)>>6):\
(((CONST_FLOAT+(1.0/128))<(44.0/64))?((CHISLO_INT*43)>>6):\
(((CONST_FLOAT+(1.0/128))<(45.0/64))?((CHISLO_INT*44)>>6):\
(((CONST_FLOAT+(1.0/128))<(46.0/64))?((CHISLO_INT*45)>>6):\
(((CONST_FLOAT+(1.0/128))<(47.0/64))?((CHISLO_INT*46)>>6):\
(((CONST_FLOAT+(1.0/128))<(48.0/64))?((CHISLO_INT*47)>>6):\
(((CONST_FLOAT+(1.0/128))<(49.0/64))?((CHISLO_INT*48)>>6):\
(((CONST_FLOAT+(1.0/128))<(50.0/64))?((CHISLO_INT*49)>>6):\
(((CONST_FLOAT+(1.0/128))<(51.0/64))?((CHISLO_INT*50)>>6):\
(((CONST_FLOAT+(1.0/128))<(52.0/64))?((CHISLO_INT*51)>>6):\
(((CONST_FLOAT+(1.0/128))<(53.0/64))?((CHISLO_INT*52)>>6):\
(((CONST_FLOAT+(1.0/128))<(54.0/64))?((CHISLO_INT*53)>>6):\
(((CONST_FLOAT+(1.0/128))<(55.0/64))?((CHISLO_INT*54)>>6):\
(((CONST_FLOAT+(1.0/128))<(56.0/64))?((CHISLO_INT*55)>>6):\
(((CONST_FLOAT+(1.0/128))<(57.0/64))?((CHISLO_INT*56)>>6):\
(((CONST_FLOAT+(1.0/128))<(58.0/64))?((CHISLO_INT*57)>>6):\
(((CONST_FLOAT+(1.0/128))<(59.0/64))?((CHISLO_INT*58)>>6):\
(((CONST_FLOAT+(1.0/128))<(60.0/64))?((CHISLO_INT*59)>>6):\
(((CONST_FLOAT+(1.0/128))<(61.0/64))?((CHISLO_INT*60)>>6):\
(((CONST_FLOAT+(1.0/128))<(62.0/64))?((CHISLO_INT*61)>>6):\
(((CONST_FLOAT+(1.0/128))<(63.0/64))?((CHISLO_INT*62)>>6):\
(((CONST_FLOAT+(1.0/128))<(64.0/64))?((CHISLO_INT*63)>>6):\
(CHISLO_INT)\
  )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))

//константа кратная 1/128
#define UM128(CONST_FLOAT,CHISLO_INT) \
((CONST_FLOAT+(1.0/256))<(1.0/128))?((CHISLO_INT*0)>>7):\
(((CONST_FLOAT+(1.0/256))<(2.0/128))?((CHISLO_INT*1)>>7):\
(((CONST_FLOAT+(1.0/256))<(3.0/128))?((CHISLO_INT*2)>>7):\
(((CONST_FLOAT+(1.0/256))<(4.0/128))?((CHISLO_INT*3)>>7):\
(((CONST_FLOAT+(1.0/256))<(5.0/128))?((CHISLO_INT*4)>>7):\
(((CONST_FLOAT+(1.0/256))<(6.0/128))?((CHISLO_INT*5)>>7):\
(((CONST_FLOAT+(1.0/256))<(7.0/128))?((CHISLO_INT*6)>>7):\
(((CONST_FLOAT+(1.0/256))<(8.0/128))?((CHISLO_INT*7)>>7):\
(((CONST_FLOAT+(1.0/256))<(9.0/128))?((CHISLO_INT*8)>>7):\
(((CONST_FLOAT+(1.0/256))<(10.0/128))?((CHISLO_INT*9)>>7):\
(((CONST_FLOAT+(1.0/256))<(11.0/128))?((CHISLO_INT*10)>>7):\
(((CONST_FLOAT+(1.0/256))<(12.0/128))?((CHISLO_INT*11)>>7):\
(((CONST_FLOAT+(1.0/256))<(13.0/128))?((CHISLO_INT*12)>>7):\
(((CONST_FLOAT+(1.0/256))<(14.0/128))?((CHISLO_INT*13)>>7):\
(((CONST_FLOAT+(1.0/256))<(15.0/128))?((CHISLO_INT*14)>>7):\
(((CONST_FLOAT+(1.0/256))<(16.0/128))?((CHISLO_INT*15)>>7):\
(((CONST_FLOAT+(1.0/256))<(17.0/128))?((CHISLO_INT*16)>>7):\
(((CONST_FLOAT+(1.0/256))<(18.0/128))?((CHISLO_INT*17)>>7):\
(((CONST_FLOAT+(1.0/256))<(19.0/128))?((CHISLO_INT*18)>>7):\
(((CONST_FLOAT+(1.0/256))<(20.0/128))?((CHISLO_INT*19)>>7):\
(((CONST_FLOAT+(1.0/256))<(21.0/128))?((CHISLO_INT*20)>>7):\
(((CONST_FLOAT+(1.0/256))<(22.0/128))?((CHISLO_INT*21)>>7):\
(((CONST_FLOAT+(1.0/256))<(23.0/128))?((CHISLO_INT*22)>>7):\
(((CONST_FLOAT+(1.0/256))<(24.0/128))?((CHISLO_INT*23)>>7):\
(((CONST_FLOAT+(1.0/256))<(25.0/128))?((CHISLO_INT*24)>>7):\
(((CONST_FLOAT+(1.0/256))<(26.0/128))?((CHISLO_INT*25)>>7):\
(((CONST_FLOAT+(1.0/256))<(27.0/128))?((CHISLO_INT*26)>>7):\
(((CONST_FLOAT+(1.0/256))<(28.0/128))?((CHISLO_INT*27)>>7):\
(((CONST_FLOAT+(1.0/256))<(29.0/128))?((CHISLO_INT*28)>>7):\
(((CONST_FLOAT+(1.0/256))<(30.0/128))?((CHISLO_INT*29)>>7):\
(((CONST_FLOAT+(1.0/256))<(31.0/128))?((CHISLO_INT*30)>>7):\
(((CONST_FLOAT+(1.0/256))<(32.0/128))?((CHISLO_INT*31)>>7):\
(((CONST_FLOAT+(1.0/256))<(33.0/128))?((CHISLO_INT*32)>>7):\
(((CONST_FLOAT+(1.0/256))<(34.0/128))?((CHISLO_INT*33)>>7):\
(((CONST_FLOAT+(1.0/256))<(35.0/128))?((CHISLO_INT*34)>>7):\
(((CONST_FLOAT+(1.0/256))<(36.0/128))?((CHISLO_INT*35)>>7):\
(((CONST_FLOAT+(1.0/256))<(37.0/128))?((CHISLO_INT*36)>>7):\
(((CONST_FLOAT+(1.0/256))<(38.0/128))?((CHISLO_INT*37)>>7):\
(((CONST_FLOAT+(1.0/256))<(39.0/128))?((CHISLO_INT*38)>>7):\
(((CONST_FLOAT+(1.0/256))<(40.0/128))?((CHISLO_INT*39)>>7):\
(((CONST_FLOAT+(1.0/256))<(41.0/128))?((CHISLO_INT*40)>>7):\
(((CONST_FLOAT+(1.0/256))<(42.0/128))?((CHISLO_INT*41)>>7):\
(((CONST_FLOAT+(1.0/256))<(43.0/128))?((CHISLO_INT*42)>>7):\
(((CONST_FLOAT+(1.0/256))<(44.0/128))?((CHISLO_INT*43)>>7):\
(((CONST_FLOAT+(1.0/256))<(45.0/128))?((CHISLO_INT*44)>>7):\
(((CONST_FLOAT+(1.0/256))<(46.0/128))?((CHISLO_INT*45)>>7):\
(((CONST_FLOAT+(1.0/256))<(47.0/128))?((CHISLO_INT*46)>>7):\
(((CONST_FLOAT+(1.0/256))<(48.0/128))?((CHISLO_INT*47)>>7):\
(((CONST_FLOAT+(1.0/256))<(49.0/128))?((CHISLO_INT*48)>>7):\
(((CONST_FLOAT+(1.0/256))<(50.0/128))?((CHISLO_INT*49)>>7):\
(((CONST_FLOAT+(1.0/256))<(51.0/128))?((CHISLO_INT*50)>>7):\
(((CONST_FLOAT+(1.0/256))<(52.0/128))?((CHISLO_INT*51)>>7):\
(((CONST_FLOAT+(1.0/256))<(53.0/128))?((CHISLO_INT*52)>>7):\
(((CONST_FLOAT+(1.0/256))<(54.0/128))?((CHISLO_INT*53)>>7):\
(((CONST_FLOAT+(1.0/256))<(55.0/128))?((CHISLO_INT*54)>>7):\
(((CONST_FLOAT+(1.0/256))<(56.0/128))?((CHISLO_INT*55)>>7):\
(((CONST_FLOAT+(1.0/256))<(57.0/128))?((CHISLO_INT*56)>>7):\
(((CONST_FLOAT+(1.0/256))<(58.0/128))?((CHISLO_INT*57)>>7):\
(((CONST_FLOAT+(1.0/256))<(59.0/128))?((CHISLO_INT*58)>>7):\
(((CONST_FLOAT+(1.0/256))<(60.0/128))?((CHISLO_INT*59)>>7):\
(((CONST_FLOAT+(1.0/256))<(61.0/128))?((CHISLO_INT*60)>>7):\
(((CONST_FLOAT+(1.0/256))<(62.0/128))?((CHISLO_INT*61)>>7):\
(((CONST_FLOAT+(1.0/256))<(63.0/128))?((CHISLO_INT*62)>>7):\
(((CONST_FLOAT+(1.0/256))<(64.0/128))?((CHISLO_INT*63)>>7):\
(((CONST_FLOAT+(1.0/256))<(65.0/128))?((CHISLO_INT*64)>>7):\
(((CONST_FLOAT+(1.0/256))<(66.0/128))?((CHISLO_INT*65)>>7):\
(((CONST_FLOAT+(1.0/256))<(67.0/128))?((CHISLO_INT*66)>>7):\
(((CONST_FLOAT+(1.0/256))<(68.0/128))?((CHISLO_INT*67)>>7):\
(((CONST_FLOAT+(1.0/256))<(69.0/128))?((CHISLO_INT*68)>>7):\
(((CONST_FLOAT+(1.0/256))<(70.0/128))?((CHISLO_INT*69)>>7):\
(((CONST_FLOAT+(1.0/256))<(71.0/128))?((CHISLO_INT*70)>>7):\
(((CONST_FLOAT+(1.0/256))<(72.0/128))?((CHISLO_INT*71)>>7):\
(((CONST_FLOAT+(1.0/256))<(73.0/128))?((CHISLO_INT*72)>>7):\
(((CONST_FLOAT+(1.0/256))<(74.0/128))?((CHISLO_INT*73)>>7):\
(((CONST_FLOAT+(1.0/256))<(75.0/128))?((CHISLO_INT*74)>>7):\
(((CONST_FLOAT+(1.0/256))<(76.0/128))?((CHISLO_INT*75)>>7):\
(((CONST_FLOAT+(1.0/256))<(77.0/128))?((CHISLO_INT*76)>>7):\
(((CONST_FLOAT+(1.0/256))<(78.0/128))?((CHISLO_INT*77)>>7):\
(((CONST_FLOAT+(1.0/256))<(79.0/128))?((CHISLO_INT*78)>>7):\
(((CONST_FLOAT+(1.0/256))<(80.0/128))?((CHISLO_INT*79)>>7):\
(((CONST_FLOAT+(1.0/256))<(81.0/128))?((CHISLO_INT*80)>>7):\
(((CONST_FLOAT+(1.0/256))<(82.0/128))?((CHISLO_INT*81)>>7):\
(((CONST_FLOAT+(1.0/256))<(83.0/128))?((CHISLO_INT*82)>>7):\
(((CONST_FLOAT+(1.0/256))<(84.0/128))?((CHISLO_INT*83)>>7):\
(((CONST_FLOAT+(1.0/256))<(85.0/128))?((CHISLO_INT*84)>>7):\
(((CONST_FLOAT+(1.0/256))<(86.0/128))?((CHISLO_INT*85)>>7):\
(((CONST_FLOAT+(1.0/256))<(87.0/128))?((CHISLO_INT*86)>>7):\
(((CONST_FLOAT+(1.0/256))<(88.0/128))?((CHISLO_INT*87)>>7):\
(((CONST_FLOAT+(1.0/256))<(89.0/128))?((CHISLO_INT*88)>>7):\
(((CONST_FLOAT+(1.0/256))<(90.0/128))?((CHISLO_INT*89)>>7):\
(((CONST_FLOAT+(1.0/256))<(91.0/128))?((CHISLO_INT*90)>>7):\
(((CONST_FLOAT+(1.0/256))<(92.0/128))?((CHISLO_INT*91)>>7):\
(((CONST_FLOAT+(1.0/256))<(93.0/128))?((CHISLO_INT*92)>>7):\
(((CONST_FLOAT+(1.0/256))<(94.0/128))?((CHISLO_INT*93)>>7):\
(((CONST_FLOAT+(1.0/256))<(95.0/128))?((CHISLO_INT*94)>>7):\
(((CONST_FLOAT+(1.0/256))<(96.0/128))?((CHISLO_INT*95)>>7):\
(((CONST_FLOAT+(1.0/256))<(97.0/128))?((CHISLO_INT*96)>>7):\
(((CONST_FLOAT+(1.0/256))<(98.0/128))?((CHISLO_INT*97)>>7):\
(((CONST_FLOAT+(1.0/256))<(99.0/128))?((CHISLO_INT*98)>>7):\
(((CONST_FLOAT+(1.0/256))<(100.0/128))?((CHISLO_INT*99)>>7):\
(((CONST_FLOAT+(1.0/256))<(101.0/128))?((CHISLO_INT*100)>>7):\
(((CONST_FLOAT+(1.0/256))<(102.0/128))?((CHISLO_INT*101)>>7):\
(((CONST_FLOAT+(1.0/256))<(103.0/128))?((CHISLO_INT*102)>>7):\
(((CONST_FLOAT+(1.0/256))<(104.0/128))?((CHISLO_INT*103)>>7):\
(((CONST_FLOAT+(1.0/256))<(105.0/128))?((CHISLO_INT*104)>>7):\
(((CONST_FLOAT+(1.0/256))<(106.0/128))?((CHISLO_INT*105)>>7):\
(((CONST_FLOAT+(1.0/256))<(107.0/128))?((CHISLO_INT*106)>>7):\
(((CONST_FLOAT+(1.0/256))<(108.0/128))?((CHISLO_INT*107)>>7):\
(((CONST_FLOAT+(1.0/256))<(109.0/128))?((CHISLO_INT*108)>>7):\
(((CONST_FLOAT+(1.0/256))<(110.0/128))?((CHISLO_INT*109)>>7):\
(((CONST_FLOAT+(1.0/256))<(111.0/128))?((CHISLO_INT*110)>>7):\
(((CONST_FLOAT+(1.0/256))<(112.0/128))?((CHISLO_INT*111)>>7):\
(((CONST_FLOAT+(1.0/256))<(113.0/128))?((CHISLO_INT*112)>>7):\
(((CONST_FLOAT+(1.0/256))<(114.0/128))?((CHISLO_INT*113)>>7):\
(((CONST_FLOAT+(1.0/256))<(115.0/128))?((CHISLO_INT*114)>>7):\
(((CONST_FLOAT+(1.0/256))<(116.0/128))?((CHISLO_INT*115)>>7):\
(((CONST_FLOAT+(1.0/256))<(117.0/128))?((CHISLO_INT*116)>>7):\
(((CONST_FLOAT+(1.0/256))<(118.0/128))?((CHISLO_INT*117)>>7):\
(((CONST_FLOAT+(1.0/256))<(119.0/128))?((CHISLO_INT*118)>>7):\
(((CONST_FLOAT+(1.0/256))<(120.0/128))?((CHISLO_INT*119)>>7):\
(((CONST_FLOAT+(1.0/256))<(121.0/128))?((CHISLO_INT*120)>>7):\
(((CONST_FLOAT+(1.0/256))<(122.0/128))?((CHISLO_INT*121)>>7):\
(((CONST_FLOAT+(1.0/256))<(123.0/128))?((CHISLO_INT*122)>>7):\
(((CONST_FLOAT+(1.0/256))<(124.0/128))?((CHISLO_INT*123)>>7):\
(((CONST_FLOAT+(1.0/256))<(125.0/128))?((CHISLO_INT*124)>>7):\
(((CONST_FLOAT+(1.0/256))<(126.0/128))?((CHISLO_INT*125)>>7):\
(((CONST_FLOAT+(1.0/256))<(127.0/128))?((CHISLO_INT*126)>>7):\
(((CONST_FLOAT+(1.0/256))<(128.0/128))?((CHISLO_INT*127)>>7):\
(CHISLO_INT)\
 ))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))\
)))))))))))))))))))))))))))))))))))))))))))))))))

//константа кратная 1/256
#define UM256(CONST_FLOAT,CHISLO_INT) \
 ((CONST_FLOAT+(1.0/512))<(1.0/256))?((CHISLO_INT*0)>>8):\
(((CONST_FLOAT+(1.0/512))<(2.0/256))?((CHISLO_INT*1)>>8):\
(((CONST_FLOAT+(1.0/512))<(3.0/256))?((CHISLO_INT*2)>>8):\
(((CONST_FLOAT+(1.0/512))<(4.0/256))?((CHISLO_INT*3)>>8):\
(((CONST_FLOAT+(1.0/512))<(5.0/256))?((CHISLO_INT*4)>>8):\
(((CONST_FLOAT+(1.0/512))<(6.0/256))?((CHISLO_INT*5)>>8):\
(((CONST_FLOAT+(1.0/512))<(7.0/256))?((CHISLO_INT*6)>>8):\
(((CONST_FLOAT+(1.0/512))<(8.0/256))?((CHISLO_INT*7)>>8):\
(((CONST_FLOAT+(1.0/512))<(9.0/256))?((CHISLO_INT*8)>>8):\
(((CONST_FLOAT+(1.0/512))<(10.0/256))?((CHISLO_INT*9)>>8):\
(((CONST_FLOAT+(1.0/512))<(11.0/256))?((CHISLO_INT*10)>>8):\
(((CONST_FLOAT+(1.0/512))<(12.0/256))?((CHISLO_INT*11)>>8):\
(((CONST_FLOAT+(1.0/512))<(13.0/256))?((CHISLO_INT*12)>>8):\
(((CONST_FLOAT+(1.0/512))<(14.0/256))?((CHISLO_INT*13)>>8):\
(((CONST_FLOAT+(1.0/512))<(15.0/256))?((CHISLO_INT*14)>>8):\
(((CONST_FLOAT+(1.0/512))<(16.0/256))?((CHISLO_INT*15)>>8):\
(((CONST_FLOAT+(1.0/512))<(17.0/256))?((CHISLO_INT*16)>>8):\
(((CONST_FLOAT+(1.0/512))<(18.0/256))?((CHISLO_INT*17)>>8):\
(((CONST_FLOAT+(1.0/512))<(19.0/256))?((CHISLO_INT*18)>>8):\
(((CONST_FLOAT+(1.0/512))<(20.0/256))?((CHISLO_INT*19)>>8):\
(((CONST_FLOAT+(1.0/512))<(21.0/256))?((CHISLO_INT*20)>>8):\
(((CONST_FLOAT+(1.0/512))<(22.0/256))?((CHISLO_INT*21)>>8):\
(((CONST_FLOAT+(1.0/512))<(23.0/256))?((CHISLO_INT*22)>>8):\
(((CONST_FLOAT+(1.0/512))<(24.0/256))?((CHISLO_INT*23)>>8):\
(((CONST_FLOAT+(1.0/512))<(25.0/256))?((CHISLO_INT*24)>>8):\
(((CONST_FLOAT+(1.0/512))<(26.0/256))?((CHISLO_INT*25)>>8):\
(((CONST_FLOAT+(1.0/512))<(27.0/256))?((CHISLO_INT*26)>>8):\
(((CONST_FLOAT+(1.0/512))<(28.0/256))?((CHISLO_INT*27)>>8):\
(((CONST_FLOAT+(1.0/512))<(29.0/256))?((CHISLO_INT*28)>>8):\
(((CONST_FLOAT+(1.0/512))<(30.0/256))?((CHISLO_INT*29)>>8):\
(((CONST_FLOAT+(1.0/512))<(31.0/256))?((CHISLO_INT*30)>>8):\
(((CONST_FLOAT+(1.0/512))<(32.0/256))?((CHISLO_INT*31)>>8):\
(((CONST_FLOAT+(1.0/512))<(33.0/256))?((CHISLO_INT*32)>>8):\
(((CONST_FLOAT+(1.0/512))<(34.0/256))?((CHISLO_INT*33)>>8):\
(((CONST_FLOAT+(1.0/512))<(35.0/256))?((CHISLO_INT*34)>>8):\
(((CONST_FLOAT+(1.0/512))<(36.0/256))?((CHISLO_INT*35)>>8):\
(((CONST_FLOAT+(1.0/512))<(37.0/256))?((CHISLO_INT*36)>>8):\
(((CONST_FLOAT+(1.0/512))<(38.0/256))?((CHISLO_INT*37)>>8):\
(((CONST_FLOAT+(1.0/512))<(39.0/256))?((CHISLO_INT*38)>>8):\
(((CONST_FLOAT+(1.0/512))<(40.0/256))?((CHISLO_INT*39)>>8):\
(((CONST_FLOAT+(1.0/512))<(41.0/256))?((CHISLO_INT*40)>>8):\
(((CONST_FLOAT+(1.0/512))<(42.0/256))?((CHISLO_INT*41)>>8):\
(((CONST_FLOAT+(1.0/512))<(43.0/256))?((CHISLO_INT*42)>>8):\
(((CONST_FLOAT+(1.0/512))<(44.0/256))?((CHISLO_INT*43)>>8):\
(((CONST_FLOAT+(1.0/512))<(45.0/256))?((CHISLO_INT*44)>>8):\
(((CONST_FLOAT+(1.0/512))<(46.0/256))?((CHISLO_INT*45)>>8):\
(((CONST_FLOAT+(1.0/512))<(47.0/256))?((CHISLO_INT*46)>>8):\
(((CONST_FLOAT+(1.0/512))<(48.0/256))?((CHISLO_INT*47)>>8):\
(((CONST_FLOAT+(1.0/512))<(49.0/256))?((CHISLO_INT*48)>>8):\
(((CONST_FLOAT+(1.0/512))<(50.0/256))?((CHISLO_INT*49)>>8):\
(((CONST_FLOAT+(1.0/512))<(51.0/256))?((CHISLO_INT*50)>>8):\
(((CONST_FLOAT+(1.0/512))<(52.0/256))?((CHISLO_INT*51)>>8):\
(((CONST_FLOAT+(1.0/512))<(53.0/256))?((CHISLO_INT*52)>>8):\
(((CONST_FLOAT+(1.0/512))<(54.0/256))?((CHISLO_INT*53)>>8):\
(((CONST_FLOAT+(1.0/512))<(55.0/256))?((CHISLO_INT*54)>>8):\
(((CONST_FLOAT+(1.0/512))<(56.0/256))?((CHISLO_INT*55)>>8):\
(((CONST_FLOAT+(1.0/512))<(57.0/256))?((CHISLO_INT*56)>>8):\
(((CONST_FLOAT+(1.0/512))<(58.0/256))?((CHISLO_INT*57)>>8):\
(((CONST_FLOAT+(1.0/512))<(59.0/256))?((CHISLO_INT*58)>>8):\
(((CONST_FLOAT+(1.0/512))<(60.0/256))?((CHISLO_INT*59)>>8):\
(((CONST_FLOAT+(1.0/512))<(61.0/256))?((CHISLO_INT*60)>>8):\
(((CONST_FLOAT+(1.0/512))<(62.0/256))?((CHISLO_INT*61)>>8):\
(((CONST_FLOAT+(1.0/512))<(63.0/256))?((CHISLO_INT*62)>>8):\
(((CONST_FLOAT+(1.0/512))<(64.0/256))?((CHISLO_INT*63)>>8):\
(((CONST_FLOAT+(1.0/512))<(65.0/256))?((CHISLO_INT*64)>>8):\
(((CONST_FLOAT+(1.0/512))<(66.0/256))?((CHISLO_INT*65)>>8):\
(((CONST_FLOAT+(1.0/512))<(67.0/256))?((CHISLO_INT*66)>>8):\
(((CONST_FLOAT+(1.0/512))<(68.0/256))?((CHISLO_INT*67)>>8):\
(((CONST_FLOAT+(1.0/512))<(69.0/256))?((CHISLO_INT*68)>>8):\
(((CONST_FLOAT+(1.0/512))<(70.0/256))?((CHISLO_INT*69)>>8):\
(((CONST_FLOAT+(1.0/512))<(71.0/256))?((CHISLO_INT*70)>>8):\
(((CONST_FLOAT+(1.0/512))<(72.0/256))?((CHISLO_INT*71)>>8):\
(((CONST_FLOAT+(1.0/512))<(73.0/256))?((CHISLO_INT*72)>>8):\
(((CONST_FLOAT+(1.0/512))<(74.0/256))?((CHISLO_INT*73)>>8):\
(((CONST_FLOAT+(1.0/512))<(75.0/256))?((CHISLO_INT*74)>>8):\
(((CONST_FLOAT+(1.0/512))<(76.0/256))?((CHISLO_INT*75)>>8):\
(((CONST_FLOAT+(1.0/512))<(77.0/256))?((CHISLO_INT*76)>>8):\
(((CONST_FLOAT+(1.0/512))<(78.0/256))?((CHISLO_INT*77)>>8):\
(((CONST_FLOAT+(1.0/512))<(79.0/256))?((CHISLO_INT*78)>>8):\
(((CONST_FLOAT+(1.0/512))<(80.0/256))?((CHISLO_INT*79)>>8):\
(((CONST_FLOAT+(1.0/512))<(81.0/256))?((CHISLO_INT*80)>>8):\
(((CONST_FLOAT+(1.0/512))<(82.0/256))?((CHISLO_INT*81)>>8):\
(((CONST_FLOAT+(1.0/512))<(83.0/256))?((CHISLO_INT*82)>>8):\
(((CONST_FLOAT+(1.0/512))<(84.0/256))?((CHISLO_INT*83)>>8):\
(((CONST_FLOAT+(1.0/512))<(85.0/256))?((CHISLO_INT*84)>>8):\
(((CONST_FLOAT+(1.0/512))<(86.0/256))?((CHISLO_INT*85)>>8):\
(((CONST_FLOAT+(1.0/512))<(87.0/256))?((CHISLO_INT*86)>>8):\
(((CONST_FLOAT+(1.0/512))<(88.0/256))?((CHISLO_INT*87)>>8):\
(((CONST_FLOAT+(1.0/512))<(89.0/256))?((CHISLO_INT*88)>>8):\
(((CONST_FLOAT+(1.0/512))<(90.0/256))?((CHISLO_INT*89)>>8):\
(((CONST_FLOAT+(1.0/512))<(91.0/256))?((CHISLO_INT*90)>>8):\
(((CONST_FLOAT+(1.0/512))<(92.0/256))?((CHISLO_INT*91)>>8):\
(((CONST_FLOAT+(1.0/512))<(93.0/256))?((CHISLO_INT*92)>>8):\
(((CONST_FLOAT+(1.0/512))<(94.0/256))?((CHISLO_INT*93)>>8):\
(((CONST_FLOAT+(1.0/512))<(95.0/256))?((CHISLO_INT*94)>>8):\
(((CONST_FLOAT+(1.0/512))<(96.0/256))?((CHISLO_INT*95)>>8):\
(((CONST_FLOAT+(1.0/512))<(97.0/256))?((CHISLO_INT*96)>>8):\
(((CONST_FLOAT+(1.0/512))<(98.0/256))?((CHISLO_INT*97)>>8):\
(((CONST_FLOAT+(1.0/512))<(99.0/256))?((CHISLO_INT*98)>>8):\
(((CONST_FLOAT+(1.0/512))<(100.0/256))?((CHISLO_INT*99)>>8):\
(((CONST_FLOAT+(1.0/512))<(101.0/256))?((CHISLO_INT*100)>>8):\
(((CONST_FLOAT+(1.0/512))<(102.0/256))?((CHISLO_INT*101)>>8):\
(((CONST_FLOAT+(1.0/512))<(103.0/256))?((CHISLO_INT*102)>>8):\
(((CONST_FLOAT+(1.0/512))<(104.0/256))?((CHISLO_INT*103)>>8):\
(((CONST_FLOAT+(1.0/512))<(105.0/256))?((CHISLO_INT*104)>>8):\
(((CONST_FLOAT+(1.0/512))<(106.0/256))?((CHISLO_INT*105)>>8):\
(((CONST_FLOAT+(1.0/512))<(107.0/256))?((CHISLO_INT*106)>>8):\
(((CONST_FLOAT+(1.0/512))<(108.0/256))?((CHISLO_INT*107)>>8):\
(((CONST_FLOAT+(1.0/512))<(109.0/256))?((CHISLO_INT*108)>>8):\
(((CONST_FLOAT+(1.0/512))<(110.0/256))?((CHISLO_INT*109)>>8):\
(((CONST_FLOAT+(1.0/512))<(111.0/256))?((CHISLO_INT*110)>>8):\
(((CONST_FLOAT+(1.0/512))<(112.0/256))?((CHISLO_INT*111)>>8):\
(((CONST_FLOAT+(1.0/512))<(113.0/256))?((CHISLO_INT*112)>>8):\
(((CONST_FLOAT+(1.0/512))<(114.0/256))?((CHISLO_INT*113)>>8):\
(((CONST_FLOAT+(1.0/512))<(115.0/256))?((CHISLO_INT*114)>>8):\
(((CONST_FLOAT+(1.0/512))<(116.0/256))?((CHISLO_INT*115)>>8):\
(((CONST_FLOAT+(1.0/512))<(117.0/256))?((CHISLO_INT*116)>>8):\
(((CONST_FLOAT+(1.0/512))<(118.0/256))?((CHISLO_INT*117)>>8):\
(((CONST_FLOAT+(1.0/512))<(119.0/256))?((CHISLO_INT*118)>>8):\
(((CONST_FLOAT+(1.0/512))<(120.0/256))?((CHISLO_INT*119)>>8):\
(((CONST_FLOAT+(1.0/512))<(121.0/256))?((CHISLO_INT*120)>>8):\
(((CONST_FLOAT+(1.0/512))<(122.0/256))?((CHISLO_INT*121)>>8):\
(((CONST_FLOAT+(1.0/512))<(123.0/256))?((CHISLO_INT*122)>>8):\
(((CONST_FLOAT+(1.0/512))<(124.0/256))?((CHISLO_INT*123)>>8):\
(((CONST_FLOAT+(1.0/512))<(125.0/256))?((CHISLO_INT*124)>>8):\
(((CONST_FLOAT+(1.0/512))<(126.0/256))?((CHISLO_INT*125)>>8):\
(((CONST_FLOAT+(1.0/512))<(127.0/256))?((CHISLO_INT*126)>>8):\
(((CONST_FLOAT+(1.0/512))<(128.0/256))?((CHISLO_INT*127)>>8):\
(((CONST_FLOAT+(1.0/512))<(129.0/256))?((CHISLO_INT*128)>>8):\
(((CONST_FLOAT+(1.0/512))<(130.0/256))?((CHISLO_INT*129)>>8):\
(((CONST_FLOAT+(1.0/512))<(131.0/256))?((CHISLO_INT*130)>>8):\
(((CONST_FLOAT+(1.0/512))<(132.0/256))?((CHISLO_INT*131)>>8):\
(((CONST_FLOAT+(1.0/512))<(133.0/256))?((CHISLO_INT*132)>>8):\
(((CONST_FLOAT+(1.0/512))<(134.0/256))?((CHISLO_INT*133)>>8):\
(((CONST_FLOAT+(1.0/512))<(135.0/256))?((CHISLO_INT*134)>>8):\
(((CONST_FLOAT+(1.0/512))<(136.0/256))?((CHISLO_INT*135)>>8):\
(((CONST_FLOAT+(1.0/512))<(137.0/256))?((CHISLO_INT*136)>>8):\
(((CONST_FLOAT+(1.0/512))<(138.0/256))?((CHISLO_INT*137)>>8):\
(((CONST_FLOAT+(1.0/512))<(139.0/256))?((CHISLO_INT*138)>>8):\
(((CONST_FLOAT+(1.0/512))<(140.0/256))?((CHISLO_INT*139)>>8):\
(((CONST_FLOAT+(1.0/512))<(141.0/256))?((CHISLO_INT*140)>>8):\
(((CONST_FLOAT+(1.0/512))<(142.0/256))?((CHISLO_INT*141)>>8):\
(((CONST_FLOAT+(1.0/512))<(143.0/256))?((CHISLO_INT*142)>>8):\
(((CONST_FLOAT+(1.0/512))<(144.0/256))?((CHISLO_INT*143)>>8):\
(((CONST_FLOAT+(1.0/512))<(145.0/256))?((CHISLO_INT*144)>>8):\
(((CONST_FLOAT+(1.0/512))<(146.0/256))?((CHISLO_INT*145)>>8):\
(((CONST_FLOAT+(1.0/512))<(147.0/256))?((CHISLO_INT*146)>>8):\
(((CONST_FLOAT+(1.0/512))<(148.0/256))?((CHISLO_INT*147)>>8):\
(((CONST_FLOAT+(1.0/512))<(149.0/256))?((CHISLO_INT*148)>>8):\
(((CONST_FLOAT+(1.0/512))<(150.0/256))?((CHISLO_INT*149)>>8):\
(((CONST_FLOAT+(1.0/512))<(151.0/256))?((CHISLO_INT*150)>>8):\
(((CONST_FLOAT+(1.0/512))<(152.0/256))?((CHISLO_INT*151)>>8):\
(((CONST_FLOAT+(1.0/512))<(153.0/256))?((CHISLO_INT*152)>>8):\
(((CONST_FLOAT+(1.0/512))<(154.0/256))?((CHISLO_INT*153)>>8):\
(((CONST_FLOAT+(1.0/512))<(155.0/256))?((CHISLO_INT*154)>>8):\
(((CONST_FLOAT+(1.0/512))<(156.0/256))?((CHISLO_INT*155)>>8):\
(((CONST_FLOAT+(1.0/512))<(157.0/256))?((CHISLO_INT*156)>>8):\
(((CONST_FLOAT+(1.0/512))<(158.0/256))?((CHISLO_INT*157)>>8):\
(((CONST_FLOAT+(1.0/512))<(159.0/256))?((CHISLO_INT*158)>>8):\
(((CONST_FLOAT+(1.0/512))<(160.0/256))?((CHISLO_INT*159)>>8):\
(((CONST_FLOAT+(1.0/512))<(161.0/256))?((CHISLO_INT*160)>>8):\
(((CONST_FLOAT+(1.0/512))<(162.0/256))?((CHISLO_INT*161)>>8):\
(((CONST_FLOAT+(1.0/512))<(163.0/256))?((CHISLO_INT*162)>>8):\
(((CONST_FLOAT+(1.0/512))<(164.0/256))?((CHISLO_INT*163)>>8):\
(((CONST_FLOAT+(1.0/512))<(165.0/256))?((CHISLO_INT*164)>>8):\
(((CONST_FLOAT+(1.0/512))<(166.0/256))?((CHISLO_INT*165)>>8):\
(((CONST_FLOAT+(1.0/512))<(167.0/256))?((CHISLO_INT*166)>>8):\
(((CONST_FLOAT+(1.0/512))<(168.0/256))?((CHISLO_INT*167)>>8):\
(((CONST_FLOAT+(1.0/512))<(169.0/256))?((CHISLO_INT*168)>>8):\
(((CONST_FLOAT+(1.0/512))<(170.0/256))?((CHISLO_INT*169)>>8):\
(((CONST_FLOAT+(1.0/512))<(171.0/256))?((CHISLO_INT*170)>>8):\
(((CONST_FLOAT+(1.0/512))<(172.0/256))?((CHISLO_INT*171)>>8):\
(((CONST_FLOAT+(1.0/512))<(173.0/256))?((CHISLO_INT*172)>>8):\
(((CONST_FLOAT+(1.0/512))<(174.0/256))?((CHISLO_INT*173)>>8):\
(((CONST_FLOAT+(1.0/512))<(175.0/256))?((CHISLO_INT*174)>>8):\
(((CONST_FLOAT+(1.0/512))<(176.0/256))?((CHISLO_INT*175)>>8):\
(((CONST_FLOAT+(1.0/512))<(177.0/256))?((CHISLO_INT*176)>>8):\
(((CONST_FLOAT+(1.0/512))<(178.0/256))?((CHISLO_INT*177)>>8):\
(((CONST_FLOAT+(1.0/512))<(179.0/256))?((CHISLO_INT*178)>>8):\
(((CONST_FLOAT+(1.0/512))<(180.0/256))?((CHISLO_INT*179)>>8):\
(((CONST_FLOAT+(1.0/512))<(181.0/256))?((CHISLO_INT*180)>>8):\
(((CONST_FLOAT+(1.0/512))<(182.0/256))?((CHISLO_INT*181)>>8):\
(((CONST_FLOAT+(1.0/512))<(183.0/256))?((CHISLO_INT*182)>>8):\
(((CONST_FLOAT+(1.0/512))<(184.0/256))?((CHISLO_INT*183)>>8):\
(((CONST_FLOAT+(1.0/512))<(185.0/256))?((CHISLO_INT*184)>>8):\
(((CONST_FLOAT+(1.0/512))<(186.0/256))?((CHISLO_INT*185)>>8):\
(((CONST_FLOAT+(1.0/512))<(187.0/256))?((CHISLO_INT*186)>>8):\
(((CONST_FLOAT+(1.0/512))<(188.0/256))?((CHISLO_INT*187)>>8):\
(((CONST_FLOAT+(1.0/512))<(189.0/256))?((CHISLO_INT*188)>>8):\
(((CONST_FLOAT+(1.0/512))<(190.0/256))?((CHISLO_INT*189)>>8):\
(((CONST_FLOAT+(1.0/512))<(191.0/256))?((CHISLO_INT*190)>>8):\
(((CONST_FLOAT+(1.0/512))<(192.0/256))?((CHISLO_INT*191)>>8):\
(((CONST_FLOAT+(1.0/512))<(193.0/256))?((CHISLO_INT*192)>>8):\
(((CONST_FLOAT+(1.0/512))<(194.0/256))?((CHISLO_INT*193)>>8):\
(((CONST_FLOAT+(1.0/512))<(195.0/256))?((CHISLO_INT*194)>>8):\
(((CONST_FLOAT+(1.0/512))<(196.0/256))?((CHISLO_INT*195)>>8):\
(((CONST_FLOAT+(1.0/512))<(197.0/256))?((CHISLO_INT*196)>>8):\
(((CONST_FLOAT+(1.0/512))<(198.0/256))?((CHISLO_INT*197)>>8):\
(((CONST_FLOAT+(1.0/512))<(199.0/256))?((CHISLO_INT*198)>>8):\
(((CONST_FLOAT+(1.0/512))<(200.0/256))?((CHISLO_INT*199)>>8):\
(((CONST_FLOAT+(1.0/512))<(201.0/256))?((CHISLO_INT*200)>>8):\
(((CONST_FLOAT+(1.0/512))<(202.0/256))?((CHISLO_INT*201)>>8):\
(((CONST_FLOAT+(1.0/512))<(203.0/256))?((CHISLO_INT*202)>>8):\
(((CONST_FLOAT+(1.0/512))<(204.0/256))?((CHISLO_INT*203)>>8):\
(((CONST_FLOAT+(1.0/512))<(205.0/256))?((CHISLO_INT*204)>>8):\
(((CONST_FLOAT+(1.0/512))<(206.0/256))?((CHISLO_INT*205)>>8):\
(((CONST_FLOAT+(1.0/512))<(207.0/256))?((CHISLO_INT*206)>>8):\
(((CONST_FLOAT+(1.0/512))<(208.0/256))?((CHISLO_INT*207)>>8):\
(((CONST_FLOAT+(1.0/512))<(209.0/256))?((CHISLO_INT*208)>>8):\
(((CONST_FLOAT+(1.0/512))<(210.0/256))?((CHISLO_INT*209)>>8):\
(((CONST_FLOAT+(1.0/512))<(211.0/256))?((CHISLO_INT*210)>>8):\
(((CONST_FLOAT+(1.0/512))<(212.0/256))?((CHISLO_INT*211)>>8):\
(((CONST_FLOAT+(1.0/512))<(213.0/256))?((CHISLO_INT*212)>>8):\
(((CONST_FLOAT+(1.0/512))<(214.0/256))?((CHISLO_INT*213)>>8):\
(((CONST_FLOAT+(1.0/512))<(215.0/256))?((CHISLO_INT*214)>>8):\
(((CONST_FLOAT+(1.0/512))<(216.0/256))?((CHISLO_INT*215)>>8):\
(((CONST_FLOAT+(1.0/512))<(217.0/256))?((CHISLO_INT*216)>>8):\
(((CONST_FLOAT+(1.0/512))<(218.0/256))?((CHISLO_INT*217)>>8):\
(((CONST_FLOAT+(1.0/512))<(219.0/256))?((CHISLO_INT*218)>>8):\
(((CONST_FLOAT+(1.0/512))<(220.0/256))?((CHISLO_INT*219)>>8):\
(((CONST_FLOAT+(1.0/512))<(221.0/256))?((CHISLO_INT*220)>>8):\
(((CONST_FLOAT+(1.0/512))<(222.0/256))?((CHISLO_INT*221)>>8):\
(((CONST_FLOAT+(1.0/512))<(223.0/256))?((CHISLO_INT*222)>>8):\
(((CONST_FLOAT+(1.0/512))<(224.0/256))?((CHISLO_INT*223)>>8):\
(((CONST_FLOAT+(1.0/512))<(225.0/256))?((CHISLO_INT*224)>>8):\
(((CONST_FLOAT+(1.0/512))<(226.0/256))?((CHISLO_INT*225)>>8):\
(((CONST_FLOAT+(1.0/512))<(227.0/256))?((CHISLO_INT*226)>>8):\
(((CONST_FLOAT+(1.0/512))<(228.0/256))?((CHISLO_INT*227)>>8):\
(((CONST_FLOAT+(1.0/512))<(229.0/256))?((CHISLO_INT*228)>>8):\
(((CONST_FLOAT+(1.0/512))<(230.0/256))?((CHISLO_INT*229)>>8):\
(((CONST_FLOAT+(1.0/512))<(231.0/256))?((CHISLO_INT*230)>>8):\
(((CONST_FLOAT+(1.0/512))<(232.0/256))?((CHISLO_INT*231)>>8):\
(((CONST_FLOAT+(1.0/512))<(233.0/256))?((CHISLO_INT*232)>>8):\
(((CONST_FLOAT+(1.0/512))<(234.0/256))?((CHISLO_INT*233)>>8):\
(((CONST_FLOAT+(1.0/512))<(235.0/256))?((CHISLO_INT*234)>>8):\
(((CONST_FLOAT+(1.0/512))<(236.0/256))?((CHISLO_INT*235)>>8):\
(((CONST_FLOAT+(1.0/512))<(237.0/256))?((CHISLO_INT*236)>>8):\
(((CONST_FLOAT+(1.0/512))<(238.0/256))?((CHISLO_INT*237)>>8):\
(((CONST_FLOAT+(1.0/512))<(239.0/256))?((CHISLO_INT*238)>>8):\
(((CONST_FLOAT+(1.0/512))<(240.0/256))?((CHISLO_INT*239)>>8):\
(((CONST_FLOAT+(1.0/512))<(241.0/256))?((CHISLO_INT*240)>>8):\
(((CONST_FLOAT+(1.0/512))<(242.0/256))?((CHISLO_INT*241)>>8):\
(((CONST_FLOAT+(1.0/512))<(243.0/256))?((CHISLO_INT*242)>>8):\
(((CONST_FLOAT+(1.0/512))<(244.0/256))?((CHISLO_INT*243)>>8):\
(((CONST_FLOAT+(1.0/512))<(245.0/256))?((CHISLO_INT*244)>>8):\
(((CONST_FLOAT+(1.0/512))<(246.0/256))?((CHISLO_INT*245)>>8):\
(((CONST_FLOAT+(1.0/512))<(247.0/256))?((CHISLO_INT*246)>>8):\
(((CONST_FLOAT+(1.0/512))<(248.0/256))?((CHISLO_INT*247)>>8):\
(((CONST_FLOAT+(1.0/512))<(249.0/256))?((CHISLO_INT*248)>>8):\
(((CONST_FLOAT+(1.0/512))<(250.0/256))?((CHISLO_INT*249)>>8):\
(((CONST_FLOAT+(1.0/512))<(251.0/256))?((CHISLO_INT*250)>>8):\
(((CONST_FLOAT+(1.0/512))<(252.0/256))?((CHISLO_INT*251)>>8):\
(((CONST_FLOAT+(1.0/512))<(253.0/256))?((CHISLO_INT*252)>>8):\
(((CONST_FLOAT+(1.0/512))<(254.0/256))?((CHISLO_INT*253)>>8):\
(((CONST_FLOAT+(1.0/512))<(255.0/256))?((CHISLO_INT*254)>>8):\
(((CONST_FLOAT+(1.0/512))<(256.0/256))?((CHISLO_INT*255)>>8):\
(CHISLO_INT)\
 ))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))\
)))))))))))))))))))))))))))))))))))))))))))))))))\
 )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))\
)))))))))))))))))))))))))))))))))))))))))))))))))  

#endif // __UM_H



Теперь для умножения переменной «а» на 0.4, с точностью до 1/256 достаточно написать «UM256(0.4, а)». И пускай за вас думает компилятор, у него мозгов много! При компиляции эти много букв макроса соберутся в простое выражение "(а*102)>>8", которое на большинстве процессоров компилируется в три команды.

Быстрого кода вам, коллеги!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334758/


Метки:  

Серия вебинаров о SAP Cloud Platform и рынке PaaS

Среда, 02 Августа 2017 г. 18:58 + в цитатник
Привет, Хабр! Приглашаем присоединиться к нашей серии вебинаров о платформе SAP Cloud Platform. Эксперты SAP и представители партнёров расскажут о рынке решений PaaS (platform-as-a-service, платформа как сервис) и о возможностях SAP Cloud Platform. Пять вебинаров по 60 минут каждый охватят актуальные темы: от знакомства с облачной платформой до интеграции с существующими приложениями.

На первом вебинаре, который начнётся уже завтра в 18:00 по московском времени, будут затронуты такие темы:

  • Текущее состояние рынка PaaS (platform-as-a-service, платформа как сервис)
  • Какую роль PaaS играет в цифровой трансформации бизнеса
  • В чём ценность SAP Cloud Platform как корпоративной платформы как сервиса

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

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

https://habrahabr.ru/post/334754/


Метки:  

Разработка персонажей для игры «Аллоды Онлайн»

Среда, 02 Августа 2017 г. 18:20 + в цитатник
image

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

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

Основы


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

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

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

Всё, что вы делаете, должно быть красивым, логичным и рациональным. Важно развивать в себе художника, независимо от того, чем вы будете заниматься — моделлить, текстурить или анимировать. Нельзя достичь успехов, механически перенося концепт в 3D: появится много ошибок, которые измучают и вас, и заказчика. Нужно постоянно развивать ЧУВСТВО ПРЕКРАСНОГО, смотреть работы успешных художников, вникать в них, разбираться, как это сделано. Художественное образование станет хорошим подспорьем. Без него, конечно, сложнее, но только потому, что у людей с образованием эти трудности уже позади. Есть много примеров, когда люди без художественного образования, но с сильным желанием научились круто рисовать, потратив на самообучение даже меньше времени. Разбираться во всём самостоятельно сложнее, никто не ответит на вопросы, всё придется искать самим. Это требует много терпения и смекалки, мозг будет работать на полную катушку, а не просто воспринимать готовые рецепты. Но зато поймёте, как не надо делать, а это важный опыт. В общем, натренируете и ум, и терпение!

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

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

В любой непонятной ситуации ЗАДАВАЙТЕ ВОПРОСЫ! Любые, даже самые нелогичные, какие придут вам в голову. Невозможно рассказать всё про всё в одном документе.

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

Моделлинг


  1. Мы принимаем модели в формате *.mа для MAYA 2012 версии или ниже. У нас стоит лицензионная Maya, и нельзя просто поставить новую версию, её надо купить за охулиарды Много Тысяч Долларов. Делать это каждый год слишком дорого. Кроме того, конвертирование из OBJ или FBX подразумевает много рутинных операций: приведение к нужным трансформациям, создание и назначение материалов. Это отнимает много времени и сил, особенно если приходится конвертировать одну и ту же модель несколько раз в день.

    • Рекомендуем настроить Maya следующим образом. Единицы измерения — сантиметры, ось вверх — Z, частота кадров — 30 FPS (это больше для анимаций).

    • Высота персонажа должна быть адекватной. Обычно на концептах «Аллодов Онлайн» схематично рисуют человечка ростом 1,8 метра, из его размеров и нужно исходить. В среднем боссы не выше 15 метров и не ниже 3.
  2. Модель должна передавать ощущение, создаваемое концептом. Важнее всего соблюсти пропорции элементов на концепте, углы граней относительно друг друга, радиусы кривизны, расположение одних элементов относительно других. Всё должно быть максимально близко к концепту хотя бы с одного ракурса. Если с заданием высылается модель и указано, что это «пример детализации», то она служит как исходный материал, из которого надо собрать свою модель, похожую на концепт. Образец служит для ускорения начала работы, не рекомендуется оставлять всё как есть («ну вы же сами мне это дали»). Проверяйте пропорции, поставив модель рядом с концептом в одном ракурсе, приближая нужные участки, сравнивая и ища отличия.







  3. Сохраняйте преувеличенные динамичные формы, предусмотренные художником и стилистикой проекта. Не стоит всё усреднять и выпрямлять.



    Если вам кажется, что персонаж или объект кривоваты, контуры на концепте намеренно искажены, то надо передать это именно так, может, даже немного преувеличить. Если же на концепте изображён геометрически правильный объект, не нужно вносить отсебятину, моделируйте ровно и аккуратно.
  4. Представляйте персонажа в игре, когда обдумываете детализацию и моделируете элементы. Проанализируйте, какие из элементов стоит смоделировать и это будет заметно, а какие достаточно отрисовать на текстуре, учитывая не только максимальное количество полигонов, но и требования по топологии. Старайтесь представить, как текстура будет выглядеть на элементах, получится ли передать задумку концепта. Не стесняйтесь спрашивать. Лучше не смоделировать некоторые мелочи, чем сделать слишком много. Экономьте время и полигоны, но без фанатизма!
  5. Учитывайте позу, в которой модель будет представлена в игре большую часть времени. Например, если руки персонажей в основном свисают вниз, а не вытянуты вверх или в стороны, то мешковатые рукава и подобные элементы одежды должны «свисать» в сторону ладони, а не перпендикулярно руке, и не быть надутыми в середине рукава, как будто рука поднята.

  6. Делайте модель аккуратно, всё должно быть на своих местах, располагаться логично, понятно и конструктивно. Зачастую у новичков возникают проблемы со стыками, сочленениями, шарнирами и т. д. В воздухе не должно ничего висеть, если только это не предусмотрено на концепте.
  7. Используйте референс для моделирования ракурсов персонажа, не изображенных на концепте. Бывает, что на концепте какой-то элемент не дорисован или перекрыт другим. Как его моделировать? В таких случаях нужно руководствоваться логикой, собственным опытом, а лучше всего — найти референс из реального мира. Если не уверены в выборе решения, то обязательно УТОЧНИТЕ, что надо сделать. Например, попросите выслать примеры подобных ассетов. Если на костюме не нарисована обратная сторона, то чаще всего сзади нужно отобразить то же самое, что и спереди, но немного по-другому. Вот несколько примеров.

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

    • Тут на виде анфас полный ахтунг: это не дракон, а демоническая собака-кусака, так делать не надо.

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

  8. Обязательно соблюдайте ЭЛЕМЕНТАРНЫЕ правила низкополигонального моделирования для игровых проектов.
    • Каждый полигон должен задавать объем или иметь значение для исправления потяжек меппинга.



      В основном это относится к твёрдым недеформируемым объектам. На гибких объектах надо делать дополнительные сегменты, чтобы при анимации всё гнулось плавнее.

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



    • Весь мех и волосы делайте альфой, объёмными элементами целесообразно передавать только крупные локоны или косы.





      То же самое относится и к мелкой детализации. Например, этот элемент висит у персонажа на поясе и размером примерно с ладонь.

    • Плашки для альфы лучше делать достаточно широкими, чтобы на них можно было нарисовать интересный силуэт. Но если они станут слишком широкими, то впустую потеряется текстурное пространство.
    • Удаляйте невидимые полигоны, если они не будут видны во время анимации. Также ни в коем случае не должно быть двойных полигонов, т. е. расположенных в одном и том же месте и с одинаково направленными нормалями. Такие полигоны возникают случайно, при неаккуратной работе. На всякий случай проверяйте, есть ли они, с помощью специальных скриптов.
    • Любой выступ должен быть заметен на фоне остального рельефа модели — или от него лучше вообще избавиться. Избегайте прямых углов между гранями выступающих элементов, так лучше читается объём. Вообще, углы между гранями в 90 градусов и меньше рекомендуется делать только на стыках материалов или на очень сильных изломах. Дело в том, что в игре свет на таких рёбрах «ломается», выглядит это отвратительно, как несведённый текстурный шов. Если на концепте нарисовано абсолютно гладкое кольцо, то неважно, сколько у вас полигонов получилось в сечении, все грани должны быть сглаженными/мягкими либо иметь одну группу сглаживания.

    • Не пытайтесь облегчить себе жизнь, моделируйте заметные элементы, задающие объём, а не рисуйте их на текстурах.

  9. Важные требования к топологии сетки.
    • Сетка должна быть удобной для сетапа. Если при оптимизации полигонов модель деформируется, то такая оптимизация нецелесообразна.

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

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

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

    • У цилиндрических элементов количество граней в сечении делайте кратным двум, а лучше четырём. Небольшим цилиндрическим элементам достаточно не более восьми граней.

    • На сгибах/суставах рук/ног/пальцев и т. п. делайте по три полигона снаружи сгиба и два внутри. Если сделать один сегмент, то при сгибе больше 90 градусов весь объём сплющится, и выглядеть это будет очень неестественно.

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





      При пересечении крупных элементов, которые будут деформироваться, лучше делать их единым мешем. Иначе при деформации на стыках могут появиться некрасивые швы. Вообще, деформируемые элементы рекомендуется делать с достаточным количеством полигонов, чтобы можно было сшить их без особых проблем.
      • Если есть группа элементов, изображённых на концепте близко друг к другу и не нуждающихся в анимации, то можно делать их простым единым объёмом. Конечно, при условиях, что они формируют какой-либо объём и возможно нарисовать все эти элементы на текстуре с достаточной детализацией и без артефактов при величине одного метра в Maya не более 1/3 экрана.

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



      Кучка снега у порога:



      Висящий на поясе контейнер:

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

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

    • Старайтесь избегать вытянутых полигонов, делайте сетку более-менее равномерной. Конечно, это не касается переходных полигонов между большими и маленькими, иначе ломается игровое освещение.
  10. Конструкция некоторых элементов иногда требует анимации, поэтому сначала обязательно уточняйте, что именно будет анимировано. Само собой, модель нужно сделать так, чтобы можно было анимировать все необходимые элементы и чтобы на скрытых частях модели можно было нарисовать текстуры, если те станут видимыми в каких-либо анимациях.
  11. При внесении правок рекомендуем сначала ещё раз изучить концепт. Например, если нужно добавить фаску на грани, то не надо делать её чересчур широкой: скорее всего, достаточно сделать её просто более заметной на модели, не более того.



    Но не надо делать фаску и слишком мелкой, когда её почти не видно, лучше пусть будет чуть пошире, на 15—30 %, а не на 200—300 %.

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

Меппинг


  1. Основное правило — экономия текстурного пространства за счёт дублирования элементов. Это помогает увеличить детализацию и уменьшить объём работ по текстурам. Все одинаковые или почти одинаковые элементы при меппинге должны быть разложены на одно и то же место. Даже если модель элемента будет немного отличаться, текстура всё равно окажется сильно похожа.





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

  3. Полукруглые элементы, ветки, ленты — всё, что изогнуто, рекомендуется мепить в линию, чтобы не тратить впустую текстурное пространство. Текстура будет потянута, но зато плотность её станет выше и швов окажется меньше.

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







    • На мелких низкодетализированных элементах потяжки вполне допустимы, если они служат для исправления более важных проблем, например для избавления от шва или для упрощения рисования текстуры. Остальные потяжки обязательно исправляйте.

    • Проверять меппинг лучше всего вот этим чекером:

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

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



    Если альфа не является полным продолжением тела (например, брови или клок шерсти на спине или локте), то эту альфу лучше разложить отдельно, чтобы не резать поверхность лишними швами.



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



      То же самое можно сказать и про места, где будут простые заливки и плавные градиенты без детализации. Обычно они видны на концепте, но не стесняйтесь уточнять. Если же эти скрытые поверхности окажутся видны во время анимаций и их нужно детализировать, то там меппинг придётся делать нормальным, этот момент тоже надо обязательно уточнять!
    • Всегда делайте более высокую детализацию головы персонажа и всего, что на ней находится. То есть на меппинге увеличивайте в 1,2—1,4 раза, вместе с волосами, головными уборами и прочими аксессуарами.
    • Нижнюю часть персонажа, ниже колен, на меппинге вполне можно уменьшить примерно в 0,7 раза. Ноги от пояса до колен — в 0,8—0,9 раза. Но лучше не надо уменьшать все предметы, что висят в районе пояса.
    • Для остальных элементов рекомендуется сделать одинаковую детализацию. Небольшая, незаметная для визуального осмотра погрешность вполне допустима.
  9. Целесообразно удерживать расстояния между элементами меппинга в пределах 3—8 пикселей. Для этого придётся узнать, какого разрешения будет текстура, и исходя из этого прикидывать расстояния.
  10. Старайтесь минимизировать пустые участки, в первую очередь за счёт перекомпоновки элементов. Если такой возможности нет, то можно немного увеличивать мелкие элементы.
  11. Текстура НЕОБЯЗАТЕЛЬНО должна быть квадратной. Можно сделать её вытянутой, с соотношением сторон 1: 2, 1: 4 или 1: 8. В этом случае разложите меппинг на половину или четверть ширины квадрата и полную высоту, а в конце растяните его по одной оси, полностью заполняя квадрат. Это бывает полезно, когда надо разложить длинные объекты, не разделяя их меппинг на куски, или для увеличения плотности текстуры в два раза, а не в четыре (как это происходит при увеличении обеих сторон текстуры).
  12. На прямых элементах меппинг рекомендуется делать прямым.


  13. На углах более 60 градусов придётся исправлять потяги анврапа (unwrap).
  14. Для проверки меппинга рекомендуется выбрать такой масштаб текстуры чекера, при котором потяжки будут наиболее заметны.


Текстуры


Текстурщик в первую очередь должен быть Художником. Рисуя текстуры, вы не механически переносите концепт на модель, а создаёте произведение искусства! Текстуру надо проработать лучше, чем концепт. Только не переборщите с улучшениями. Например, можно усовершенствовать освещение, но в целом модель и концепт должны быть очень похожи.

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

Базовые требования к текстурам


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

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



    Однако не надо делать вот такие наплывы:



    Возможно, с какого-то ракурса они помогут сгладить, но с других ракурсов это может выглядеть совсем плохо.
  4. Не надо переносить на текстуры перспективные искажения, которые были нарисованы на концепте. Круги должны быть кругами, а не овалами. Если на ровной плоскости надо нарисовать пазы/углубления/выступы/ступени, т. е. любые объёмные элементы, не выдавленные полигонами, обязательно рисуйте ВСЕ их боковые грани, в том числе те, что на концепте не видно. Так вы создадите иллюзию объёма при взгляде с любого ракурса, а не только с того, что использован на концепте.



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



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

  6. Старайтесь стремиться к живописности текстуры. Живописность проявляется в преобладании цветовых или светотеневых пятен над чёткой линией, в мягкости переходов, в перетекании и незамкнутости выходящих в пространство объёмов, в асимметрии и динамике планировки и свободно расчленённых композиционных элементов и форм. В широком смысле слова живописность — свободная живая выразительность, яркая образность, красочность.
  7. Продумывая детализацию, не забывайте опираться на референсы из реального мира. Рисуя существ, учитывайте анатомию животных: где какие мышцы, кости, как они влияют на внешний облик. Зная анатомию, надо учитывать телосложение: персонаж может быть толстый, худой, старый, молодой, высокий, низкий, сильный, слабый и т. д. То же самое относится и к насекомым, ведь у них своя биомеханика. Даже технику нужно рисовать осмысленно, соблюдая здравый смысл и руководствуясь логикой при изображении механических соединений, поршней, трубок и т. п.
  8. Даже если в игре насыщенная цветовая гамма, открытые цвета лучше не использовать. Например, в «Аллодах» все объекты должны иметь градиент, тоновой и/или цветовой, как правило, сверху вниз — от светлого к темному. На крупных деталях вполне уместны внутренние градиенты, но не стоит увлекаться их количеством и разнообразием, локальный цвет должен хорошо читаться, а лишние мелкие градиенты создают ощущение грязи.
  9. Важное правило: графичность в текстурах недопустима. Конечно, если только это не подразумевается концептом. Также не рекомендуется использовать однотонные полоски для обозначения границ, лучше делайте переходами градиентов и разностью тонов плоскостей.

  10. Старайтесь по всей текстуре разнообразить формы и объёмы, ведь однообразие выглядит плохо, неинтересно. Посмотрите на это слишком однообразное пузо жука:



    Здесь можно порекомендовать убрать сегменты на груди и сделать единую пластину. К тому же и сам жук сделан анатомически неправильно, в природе такого не бывает.
  11. Иногда приходится дорисовывать то, чего не было на концепте, чтобы элемент получился законченным. Чаще всего это делается уже по результатам фидбека, реже — по дополнительной информации в ТЗ. А вот самодеятельность не всегда приветствуется.



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


Освещение


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

  2. Важно учитывать, в какой позе модель представлена в игре большую часть времени. Как и в случае с моделированием одежды, для освещения персонажа поза тоже важна. Например, если его руки в основном свисают вниз, а не вытянуты вверх или в стороны, то освещение должно это учитывать. В этом случае растяжки по яркости и насыщенности будут тянуться вдоль рук, к ладоням.
  3. Старайтесь делать персонажей как можно более «вещественными», чтобы зритель явно считывал материалы. Для этого их надо разделять по тону и насыщенности. Важно понимать особенности того или иного материала: насколько он дорогой, тщательно обработанный или простой, со следами грубой ковки, новый или старый, полированный или матовый и т. д.

  4. Не забывайте про вертикальный градиент по яркости и насыщенности. В реальном мире объекты освещаются солнцем сверху вниз, и наш мозг воспринимает это как естественное освещение. Поэтому модель должна быть освещена сверху светлее, а снизу темнее. То же самое и с насыщенностью.
  5. Желательно не делать общее освещение резким, достаточно, если оно хорошо читается, подчёркивает форму объекта.
  6. Рекомендуется избегать чёрных теней и белых бликов. В играх может быть своё освещение, которое высветлит светлые участки, поэтому значения яркости в текстуре лучше держать между 40 и 230. Другими словами, текстуры должны быть созданы с такой яркостью, как в светлый облачный день.
  7. Целесообразно разбивать освещённость элементов по планам: переднему и заднему. Поверхности в глубине модели, т. е. на заднем плане, должны быть темнее тех, что снаружи.
  8. Поверхности, расположенные под разными углами, должны заметно различаться по тону, т. е. по силе освещения источником света. В этом примере верхняя поверхность должна быть ярче боковых, так как основной свет идёт сверху, к тому же нам надо подчёркивать геометрию, а не скрывать её, освещая всё в один тон.

  9. Иногда объём и освещение на концепте прорисованы не на всех элементах, а только на основных. В этом случае на остальных элементах объём придётся передавать с помощью текстур.
  10. Старайтесь сделать контраст максимальным в «точках интереса», а не равномерным по всей модели. У существ и персонажей (как правило) такие точки — это голова и верхняя/передняя часть торса (хотя и не всегда, тут нужно анализировать концепт, чтобы понять, что именно художник хотел подчеркнуть). В костюмах (опять же, как правило) это шлем — плечи — верхняя часть нагрудника / украшение в нагрудном слоте. К ногам контраст и общий тон текстуры можно снижать.
  11. Не пренебрегайте рефлексами — отражениями света от соседних поверхностей. Речь не о бликах от источников света, они должны присутствовать сами собой, а об отражённом свете от поверхностей, освещённых каким-либо источником и из-за этого тоже превратившихся в своеобразные источники, но менее яркие.

  12. Нужно аккуратно работать с бликами. Излишнее их количество создаёт ощущение каши. Неправильное расположение ломает форму и ощущение света на объекте. То же самое касается и рефлексов.

  13. Избегайте ситуаций, когда объём отдельных детализаций элемента ломает общий объём этого элемента.
  14. Используйте «чистые» цвета. Ощущение «грязного» цвета возникает, когда его затемняют снижением тона, т. е. уводят в серый. Корректнее добавлять в тени холодные цвета вроде фиолетового или тёмно-зелёного.



    Это же правило помогает избежать монохромности, блёклости, тусклости и получить интересную, яркую картинку игры. Можно добавлять разные оттенки в разные по яркости места текстуры, например как на пузе TermiteQueen.



    Выглядит очень круто и интересно. Или вот ступа, вроде ничего особенного, но получилось нескучно:

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



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


Детализация


  1. Задача текстурщика — создать иллюзию объёма, иллюзию большого количества полигонов при их отсутствии.
  2. Детализацию в центрах композиции и интереса лучше делать выше, чем в менее важных местах. Но это не значит, что можно всё сделать заливками в остальных местах и оставлять неоправданно пустые участки без какой-либо фактуры или складок, так модель будет выглядеть недоделанной. На меппинге более детализируемые места рекомендуется раскладывать с большей плотностью текстуры.
  3. В «Аллодах» стилистика игры исключает фотореализм, поэтому фактурность поверхностей достигается с помощью цветовых пятен. Зачастую фактурами можно пользоваться, но только в дополнение к основной детализации, после того как определено общее освещение и цвет.
  4. Концепты — не эталон, поэтому свойственные им артефакты — неаккуратные мазки кистью, ступенчатые переходы — нужно преобразовывать в аккуратную фактуру и градиенты света, а не переносить тщательно на модель.

  5. Основной ориентир для детализации — это размер текстуры. Если он позволяет, то детализацию лучше всего увеличивать. Избегайте замыленности текстуры, если её разрешение позволяет сделать лучше.
  6. Детализация не должна быть слишком мелкой или чересчур равномерной. Обязательно должна присутствовать крупная, средняя и мелкая детализация. Лучше всего работать от общего к частному, от крупной детализации к средней, а затем к мелкой. Не стоит переходить к рисованию складок до того, как решены основные цветовые и тоновые отношения.
  7. Избегайте излишней контрастности деталей, чтобы они не ломали общую форму, не влияли на общую яркость и насыщенность элементов, не «пачкали» цвета. Копоть, патина, потёртости, царапины и прочие следы времени очень оживляют текстуру, однако их избыток приводит к неаккуратной, грязной картинке.
  8. Тип детализации должна подсказывать логика. Для ткани, например, это могут быть швы, складки, потёртости, заплатки. Для металла — выбоины, царапины, содранная краска, тусклые или полированные участки и т. д.
  9. При работе с альфой нужно в первую очередь создать интересный силуэт, не стоит резать её равномерно мелко.
  10. Чтобы избежать нежелательной кромки вокруг вырезанных на альфе деталей, рекомендуется неиспользованное пространство заливать цветом, близким к цвету текстуры непрозрачных элементов.
  11. Повторяющиеся элементы целесообразно делать одинаковыми по размеру, но разнообразными по цвету и/или форме. Однообразие выглядит скучно и зачастую неестественно, а вот разный размер пуговиц нелеп, если только так не задумано. Элементы, выглядящие одинаково на концепте, нужно так же отразить и на модели.
  12. Избегайте разброса в размерах общих элементов (отбивки, заклёпки). Отбивки/бордюры в большинстве случаев должны быть одинаковой толщины по всему элементу.


Технические нюансы и требования


  1. Чтобы с текстурой удобно было работать в дальнейшем, лучше делать её в формате PSD с разделением на несколько слоёв: отдельно слои с каждым материалом, слой с тенями от обвеса на теле, слой с детализацией/фактурой. Разбиение позволяет корректировать слои по отдельности, при необходимости что-нибудь поправить или сделать из этой текстуры что-то новое. Правило не обязательное, но чаще всего достаточно не сливать несколько слоёв перед отправкой текстуры. Если вы рисуете всё сразу в одном слое, то это повод пересмотреть свой подход, поскольку те же правки будут вноситься быстрее, если текстура разбита по слоям.

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

  3. Самый нижний слой лучше сделать бекграундом:

  4. Прозрачность целесообразно рисовать в альфа-канале:

  5. В отношении моделей маунтов и костюмов нужно помнить, что большую часть времени на них смотрят сзади, так что этому виду нужно уделять достаточно внимания (впрочем, это не значит, что можно обращать меньше внимания на все остальные ракурсы).
  6. Рядом с осью симметрии персонажа стоит быть аккуратнее с детализацией, чтобы симметрия не бросалась в глаза.
  7. Швы элементов, логически переходящих друг в друга, рекомендуется сводить. Вот так делать не надо:

  8. Также советую сводить жёсткие швы на элементах. Например, тут лучше добавить тень на лице и подсветить волосы:

  9. Желательно, чтобы большая часть пикселей находилась в средней части диапазона яркостей, примерно 60 % гистограммы. Пик гистограммы для более тёмных объектов сместится левее, для более светлых — правее.
  10. Удостоверьтесь, что при просмотре модели не возникает артефактов текстуры при величине одного метра в Maya не более 1/3 экрана.
  11. Скрытые части элементов и плоскостей тоже не забудьте затекстурить, если они будут показываться во время анимаций.
  12. В местах пересечения ног и юбки штаны лучше всего рисовать тем же цветом, что и юбку, чтобы избежать резких переходов, когда нога пролезает сквозь юбку.

Как рисовать быстрее


  1. Крайне рекомендую использовать планшет, если не умеете — учитесь, даже самый простой планшет позволяет рисовать гораздо быстрее, чем мышью.
  2. Хороший монитор — must have. Желательно с IPS-матрицей или лучше. Он позволит вам видеть больше нюансов в цветах, вы станете замечать разницу между красивым и «не очень».
  3. Используйте горячие клавиши вместо кликанья кнопок на экране и таскания ползунков. Это дважды экономит вам время: во-первых, мгновенно выбираете нужный инструмент или настройку, во-вторых, не приходится отдыхать от возни курсором по экрану. Посчитайте, сколько раз надо хотя бы менять прозрачность кисти, а это же делается просто цифрами на клавиатуре.
  4. ВСЕГДА ИЩИТЕ РЕФЕРЕНСЫ. Срисовывать с образца гораздо быстрее, чем придумывать абы что. Одновременно вы пополняете свою визуальную библиотеку. С референсами вы учитесь рисовать и зарабатываете деньги! Сегодня трудно придумать что-то новое, и скорее всего, оно уже придумано и улучшено. Так что вам придётся потратить кучу времени, чтобы сделать так же. Рекомендую сначала посмотреть, что придумано до нас, а потом уже пытаться придумывать что-то новое, комбинируя эти знания и используя фантазию.
  5. Цвета можно и нужно брать прямо с концепта, используя их для текстуры.
  6. Если спроецировать концепт на модель в ZBrush, 3DCoat или других подобных программах, а потом доработать, то это существенно ускорит начало работы.
  7. Разбивайте текстуру на слои с разными материалами, это поможет быстрее вносить правки (изменять оттенок или яркость), не придётся выделять этот материал по всей текстуре. Не самый полный пример, но всё-таки:


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

Примеры и руководства


Наши внутренние

Общедоступные уроки

Разные ресурсы для вдохновения и с примерами, «как надо»

P. S.


Когда глядишь на крутую работу, кажется, что сделать её очень сложно, почти невозможно. И да, и нет. Сложно перестроить своё сознание и подход к делу, но зато потом всё становится просто и понятно. Для упрощения работы лучше разобрать её на части, элементы, участки, градиенты. Затем просто возьмите нужный цвет, нарисуйте в нужном месте пятно/линию/узор нужной кистью с нужной прозрачностью нужное количество раз, доводя её до нужного вида. Экспериментируйте, набирайтесь опыта в подборе и смешении цветов, достижении изящности линий, формировании объёма. Наконец, просто запоминайте наработанные приёмы и образы.

Запомнить — наверное, сложнее всего. Я бы сказал, это главная проблема. Хорошая память — самое важное в жизни. Чтобы что-то запомнить при плохой памяти, приходится делать одно и то же по несколько раз, а то и несколько десятков раз! Вы тратите на это уйму времени своей недолгой жизни. Хорошая память — ключ к успеху в любом деле. Хорошая память — это хорошее кровообращение чистой крови и отсутствие отвлекающих факторов вроде информационного мусора, шума, любых болезней. Для этого нужно полное погружение в тему, наушники и здоровый организм. Оградите себя от новостей и тупых сериалов, почаще оставайтесь наедине с собой, общайтесь с людьми, увлечёнными тем же делом. Избавьтесь от вредных привычек, к которым относятся не только очевидные — курение, алкоголь и наркотики, — но и, например, малая подвижность и переедание. Проходите/пробегайте каждый день 5—10 километров на свежем воздухе, 10—15 минут уделяйте физическим упражнениям, спите 7—8 часов в сутки, живите подальше от загазованных улиц, дышите свежим воздухом, пейте чистую воду, ешьте побольше растительной пищи — не злоупотребляйте мясом, сахаром и мучными изделиями. Берегите себя в физическом плане, всякие переломы и серьёзные травмы сопряжены с пребыванием под наркозом, который вредит мозгу гораздо больше, чем вредные привычки, наравне с сильными наркотиками, даром что без привыкания.

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

Позволяйте себе иногда маленькие радости, чтобы видеть хоть какой-то смысл возвращаться к работе и совершенствоваться, чтобы работать меньше, получать больше. Всё-таки живем не для того, чтобы только работать. Лень — двигатель прогресса: ищите, придумывайте новые техники и способы рисовать круче и быстрее! Да не только рисовать, это относится ко всем видам деятельности! Изучение новых или комбинирование старых функций в новых версиях знакомых программ позволяет делать привычные вещи в разы быстрее. Ищите, изучайте, экспериментируйте, пробуйте нестандартные подходы, разбирайтесь, как что работает на уровне элементарных составляющих, пикселей и цифр, тогда поймёте, как это сделано и что нет ничего невозможного. Совмещение совершенно разных областей знаний может дать удивительные результаты, подтолкнуть к новым идеям. Например, узоры фракталов так интересны и разнообразны, кто бы мог подумать, что этим мы обязаны математике. Химия, физика, биология, история могут подкинуть множество идей и решений. Невозможно знать всё, но надо знать, что всегда есть откуда почерпнуть что-то новое. Не зря в школе нам преподают так много всего, просто школьник не понимает, зачем ему это нужно. Расширяйте кругозор, живите интересно!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334712/


Метки:  

Приглашаем на митап «Java и Linux – Борьба за микросекунды»

Среда, 02 Августа 2017 г. 18:20 + в цитатник


Привет, Хабр!

Я, Алексей Рагозин, и мой коллега – Сергей Сорокин приглашаем вас на открытое мероприятие по теме «Java и Linux – Борьба за микросекунды». Мероприятие пройдет во вторник 8 августа в 19.00 в офисе Технологического Центра Дойче Банка. Все подробности и регистрация по ссылке.

Вот о чем мы планируем говорить.

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

Многим знаком термин высокочастотная торговля (high frequency trading). В этом классе счет времени отклика идет на микросекунды, но и стоимость владения подобными системами очень велика. Специализированное сетевое оборудование, размещение серверов на хостинге торговой площадки, высокооптимизированный код, — все это экономически оправданно только для ограниченного числа торговых систем.

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

На встрече 8 августа в Технологическом Центре Дойче Банка в Москве мы расскажем об особенностях разработки систем, которые должны обеспечивать низкое время отклика, используя обычные сервера и программную платформу Linux + Java. В частности, речь пойдет об архитектуре систем управления заявками.

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

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

В данном контексте малое время отклика — это сотни микросекунд (обычно до 1 миллисекунды)  на обработку события в прикладном процессе (не считая сетевого взаимодействия).

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

Традиционная архитектура систем управления заявками существенно отличается от классического JEE. Ключевым моментом является исключение «медленной» базы данных с критического пути. Данные для обработки транзакций хранятся в оперативной памяти, а ACID характеристики обеспечивает надежная очередь передачи сообщений.

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

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

Подводя итог, на этой сессии мы расскажем об особенностях создания решений с низким временем отклика на неспециализированном железе, Java и Linux.

До встречи!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334740/


Метки:  

5 простых способов испортить шрифт

Среда, 02 Августа 2017 г. 18:10 + в цитатник
В этой статье я покажу самые популярные ошибки, которые совершаются при работе со шрифтами, и научу тому, как их избежать. Статья будет полезна не только начинающим дизайнерам, но и всем, кто хочет знать основные правила работы с текстом.
image


1. Деформация шрифта


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

Даже незначительные деформации заметны. Как по высоте:
image

Так и по ширине:

image

Многие думают: «Да никто даже не заметит!». Осознанно может и нет, однако наш мозг точнее глаз подмечает такие несоответствия. Из-за этого восприятие текста заметно ухудшается.

Пример из жизни:

image

2. Применение эффектов



Эффекты к шрифтам неприменимы, за редким исключением. Опять же, отталкиваемся от цели: «Максимально доступно донести информацию».

Такие эффекты, как тени, имитация 3D и текстуры только мешают воспринимать текст:
image

Пример из жизни:

image

3. Плохое сочетание текста и фона


«Отличный» способ испортить взаимодействие с текстом — поместить его на фон, прочесть с которого что-то будет невозможно. Рассмотрим на примерах:

image

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

image

Решением проблемы может быть плашка под текст:

image

Но лучше всего — подобрать подходящий фон:

image

Пример из жизни:

image

4. Неправильная расстановка интервалов


Внимание к отступам играет большую роль в восприятии текста. Проще всего испортить текст если слепить его в одну кучу (или, наоборот, переборщить с расстоянием между буквами), а также не сделать отступы от краев или между строками. В таком случае текст сольется в одну массу, и читать его будет очень не комфортно:

image

Кстати, мы писали об этом в статье «Теория близости»


Пример из жизни:
image

5. Использование только прописных букв


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

image

Пример из жизни:

image

Подготовил Баранов Данила для Логомашины

Если вам понравилась эта статья — читайте про «4 популярные ошибки в дизайне визиток»
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334750/


Метки:  

О потреблении ТВ-контента теми, кто что-то понимает

Среда, 02 Августа 2017 г. 17:48 + в цитатник
Я много пишу о телевизионной отрасли с профессиональной точки зрения. В последнее время среди задач все чаще попадаются темы о контенте и моделях его потребления. И почти в каждой статье те или иные специалисты высказываются относительно общей массы абонентов какой-либо услуги, как и что они предпочитают смотреть. На основе этих данных строятся прогнозы популярности сервисов, разрабатываются бизнес-модели и интерфейсы. Но юмор ситуации в том, что о модели потребления, хоть сколько-нибудь близкой к моей, я не слышала ни разу.
Конечно, я вряд ли могу отнести себя к большинству. У меня вон за спиной жужжит собственноручно собранный в декрете 3D-принтер (скучно стало). Но при этом по всем статистическим параметрам я отношусь к платежеспособному населению, наиболее интересному создателям разных сервисов и рекламодателям. Дайте мне сервис, отвечающий хотя бы существующим потребностям (молчу про предугадывание моих желаний), и я за него заплачу. Но вместо этого рынок предлагает мне платить за сервисы, созданные на основе совместного статистического анализа потребления контента бабульками, домохозяйками и теми, кто только привыкает к нелинейному просмотру. Не то!
Подобным размышлениям место в профессиональном издании, вроде ТелеСпутника. Но там надо еще доказать, что моя модель потребления сколько-нибудь популярна. Я не хочу этим заниматься (тем более, я действительно не уверена в том, что моему примеру могут последовать массы). Я просто оставлю свои соображения здесь в надежде, что создатель очередного ОТТ-сервиса или устройства для ТВ наткнется на них и, вероятно, учтет в какой-то степени в дорожной карте своего проекта… или просто примет к сведению.
А зрителям, уставшим от однообразия ТВ-эфира, предлагаю почерпнуть несколько идей для усовершенствования своих “телевизионных” вечеров.

Добро пожаловать под кат.


А где телевизор?


Железячно-софтовый раздел

Рассказ о просмотре ТВ-контента начну, пожалуй, с того, что телевизора (в привычном понимании этого термина) у нас нет. Панель на стене подключена в качестве единственного монитора к специально собранному под это дело системнику.
Как так получилось?
Лет 5 назад ТВ у нас собирал пыль, при том, что смотрели мы в основном скачанные фильмы и сериалы на ноутбуке с маленьким экраном — а все потому, что телек нормально не подключался к этому ноутбуку.
В какой-то момент встал вопрос, что делать.

Smart TV? Никогда!


Первым делом я тогда заболела идеей купить Smart TV — судя по рекламе производителей это уже тогда должен был быть и комп, и телевизор в одном флаконе. Так сложилось, что именно в тот момент “умным” телевизором обзавелись мои родители (между прочим, одной из последних моделей) — и мне довелось вдоволь поиграться с ним перед гипотетической покупкой. Мой вердикт: вообще не то!
Почему? Слишком медленный софт, слишком кривой интерфейс. Чтобы добраться до YouTube, надо минут 10 — потом еще надо будет с пульта поисковый запрос вводить… Чтобы просто запустить ребенку мультик с подключенного жесткого диска — минут 5 (за это время шустрый трехлетка уже забудет, что хотел мультик, убежит и разнесет пол кухни).
Где обновления, обещанные производителем? Почему приложения из официального магазина запускаются через раз? С чего вдруг камера для Skype на телевизоре стоит таких космических денег? Почему для подключения по WiFi надо покупать отдельную железку за, опять же, космические деньги (спросите у китайцев, сколько голый модуль на плате стоит…)?
Тот неудачный опыт показал, что Smart TV доступных производителей при всем своем функционале в первую очередь — телевизор. Там и пульт, и интерфейс заточены на то, чтобы чаще смотреть линейные каналы. К слову, основные пользователи того телевизора довольны как удавы — у них теперь и любимые передачи, и фильмы с жесткого диска в одном флаконе. А нам нужен был в первую очередь комп, поскольку потребление контента нелинейное принципиально.
Встроенные мощности Smart TV за прошедшие годы явно выросли, но общая идея построения интерфейса осталась та же: по умолчанию загрузка телевизора; пульт с кнопками каналов под большим пальцем и т.п. Пока лед в этом направлении не тронется, я в сторону Smart TV даже смотреть не буду…

Важная мысль 1. Чтобы продать мне (или таким, как я) ТВ технику или сервис, уберите оттуда совсем — или задвиньте в самый дальний уголок интерфейса — просмотр обычного линейного телевидения. Продавая нелинейные функции, сосредоточьтесь на главном — на самих нелинейных функциях.

Приставка vs системник


Классическая ТВ-приставка — вещь в себе. Действительно, рядовой пользователь не любит подключать к телевизору дополнительные устройства. Если эту тему обсуждают специалисты, тут обычно следуют разглагольствования о лишних проводах, только что сделанном ремонте и т.п. И вот мы уже получаем вывод, что приставки не продаются, потому что они приставки.
А вот я скажу, что приставки (среди меня) не продаются, потому что они не компы!
Как мне с точки зрения потенциального пользователя видится приставка? Это черный ящик от непонятного производителя с непонятными ресурсами (а хватит ли их на фильм в HD 60 кадров в секунду- именно этот?). Нерасширяемый, не обновляемый… просто черный ящик, поддерживающий определенные стандарты сейчас. Гипотетически я и 10, и 20 тыс. рублей готова заплатить за “головное устройство”. Но, пардон, техника идет вперед. Тут вот HD еще не все освоили, а уже 4K на пороге. Новые стандарты кодирования и все такое… Мне предлагается выкинуть приставку целиком и купить новую, когда захочется чего-то новенького (вместе со встроенным жестким диском…)? Я не вижу подтверждений, что мои немалые затраты не станут очень-краткосрочным вложением.
Ответ на это сомнение один: в сад ваши ТВ-приставки. Либо уж сразу игровую с контроллером движения (XBox с кинектом или аналоги от других производителей), либо самостоятельный системник. У них больше ресурсов, они расширяемы и обновляемы. Там с ПО можно делать много разных интересных вещей (ТВ-приставки с Android с точки зрения ПО интереснее общей массы, но замечание про обновляемость от этого никуда не девается).
Игровые приставки принципиально лучше телевизионных тем, что развиваются они крупными корпорациями. А значит, у меня, как у пользователя, есть гарантия обновлений, нового софта и т.п. Опять же, контроллер движения… Честно скажу, на этапе выбора этот фактор чуть было не стал определяющим в сторону игровой приставки. Но “контентная” составляющая подкачала. На тот момент самыми популярными источниками у нас были YouTube и Вконтакте, а с ними проще на обычной настольной системе. Плюс при беглом поиске я не нашла игру для контроллера движения, которая меня бы зацепила. Да и видеонаблюдение в квартире тогда хотели запустить — и комп в роли “ТВ-приставки” выглядел более перспективным.

Важная мысль 2: Телевизионную приставку в существующем виде я не куплю. И дело не в цене. Дело в том, что мои требования к функционалу довольно высоки (хранить видео, получать информацию о нем с интернета, хранить точки остановки просмотра и т.п.), но устройства от условно-маленького (по сравнению с каким-нибудь Microsoft или Google) производителя, с моей точки зрения, имеют неясные перспективы развития. А я согласна платить, только если затраты закроют вопрос лет на 5-7 совсем (с учетом возможных обновлений стандартов и форматов)… или же купленный комплект можно будет хотя бы частично использовать при обновлении.

Системник!


Системник собирался по принципу минимального шума и возможного будущего использования хотя бы некоторых частей в следующей версии “головного устройства” (как минимум, корпуса, БП и жесткого диска):
  • небольшой корпус. Брали горизонтальный, чтобы поставить на него телек, но впоследствии системник прибили на стену в коридоре — из кухни, где размещен телек, туда через дверной проем идет вязанка кабелей — благо расстояние сантиметров 30 — 40. Собственно, можно было и ящик из фанеры сделать…
  • материнка со встроенным процом с радиатором, но без вентилятора. Среди актуальных на момент покупки платформ выбрали ту, что по отзывам просто нормально декодирует 1080p под виндой — за последними новинками не гнались. Когда-то во времена Универа мне удавалось запускать на 386-м под DOS просмотр видео, которое под Win просто не открывалось (глючный плеер открывал его в перевернутом виде и, не имея других средств перекодирования, мы переворачивали вверх ногами ЭЛТ-монитор… это было забавно!). По аналогии была надежда при необходимости видео большего разрешения запустить под Linux/Ubuntu. Мысль эта в фоне все еще имеется — если мы обновим ТВ и фильмы с новым разрешением уже не пойдут, будем экспериментировать;
  • блок питания в корпусе был с тихим вентилятором, но тот быстро сломался… новый я при установке подключила к разъему на материнке, чтобы из биоса снижать скорость вращения — этот Франкенштейн громко жужжит только до загрузки биоса. И работает без нареканий уже года 3;
  • встроенный жесткий диск на терабайт;
  • дополнительный внешний жесткий диск на терабайт — это наследие домашнего офиса (использовался под бекапы до появления в семье хорошего платного облака).

С телевизионными задачами (телек — 720p; видео — 720p и 1080p) справляется набортная видяха. Дополнительно подключен звук 5.1 (“приданое” мужа), веб-камера для скайпа. Звук, кстати, идет через набортную звуковуху. И прошу тут не метать известную субстанцию на вентилятор, качества современной набортной звуковухи более чем достаточно для просмотра дурацких детских мультиков — о HiEnd я тут ни слова не скажу (есть у меня подозрение, что это еще и заведомо лучше звука, который может издавать ТВ-приставка, если у нее вообще предусмотрена такая функция).

Ключевой момент — софт


Откровенно говоря, комп — тоже не предназначен для комфортного просмотра контента. Он тоже неудобен. Клавиатура и мышка на обеденном столе — неудобно; набирать строку в браузере с комфортного для просмотра расстояния могу в семье разве что я со своими супер-зрением. Так что тут специалисты правы: немногие будут тыкаться с разнородными софтовыми плеерами, плей-листами и т.п., поэтому делать отдельное приложение, допустим, для своего ОТТ-сервиса под комп нет смысла — достаточно того, что он будет доступен в браузере. Однако эти самые специалисты часто упускают из виду, что держать зоопарк плееров и плей-листов и не требуется. Нужно просто один раз поставить подходящий интерфейс, эмулирующий Smart TV, но с лучшей его стороны (и не замороженный производителем из-за желания сэкономить).
В моем случае этим софтом стал Kodi. Не буду расписывать плюсы и минусы (для этого в сети полно обзоров). Для меня было важно, что:
  • он ест все видео, которое набралось на двух наших терабайтниках (всеяден к форматам);
  • он регулярно обновляется — исправляются косяки, интерфейс становится удобнее;
  • подтягивает информацию о контенте из интернета — причем ему можно скармливать не по одному файлу, а папками. Мне было важно не столько оригинальное название и описание, сколько автоматическое объединение серий сериала, циклов кинофильмов и прочих подобных друг другу сущностей в одно целое для последующего просмотра всей кучей;
  • запоминает место просмотра в каждом видео / серию в цикле. Это удобно, когда дома несколько человек что-то смотрят. Вдвойне удобно, что не надо ни в какие профили заходить — общий профиль на всю семью… иначе полдня будет уходить на перелогины;
  • собирает просматриваемое на отдельной странице (можно параллельно смотреть несколько фильмов в короткие перерывы между делами, не забывая, что смотришь);
  • интерфейс удобен и для мышки, и для клавиатуры — причем все, что нужно, видно с “козырных” мест за столом, т.е. издалека. Шрифт крупный, элементы интерфейса — тоже; при желании управлять можно только мышкой (берем беспроводную; убираем вообще клавиатуру со стола).


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

Kodi — на самом деле тоже не панацея. Несмотря на обновления, некоторые проблемы у нас до сих пор не решены. К примеру, не получается сделать управление голосом, а хотелось. Тут мешает целый комплекс глюков, главный из которых на Kodi вообще не завязан. Инфу о контенте (в том числе название для поиска) он получает из интернета через плагины. На русском языке можно получить данные только с Кинопоиска — а у тех какая-то кривая система борьбы с ботами и агрегаторами. В итоге пропустить через плагин всю базу контента у меня так и не получилось (после 1 обновленного фильма плагин получает отлуп на сутки). Зато информация отлично подгружается пакетом с IMDB на английском языке. Русский-английский — технически без разницы. Но голосовой поиск видео в Kodi можно сделать через программку для смартфона, которая в свою очередь использует Google API. И этот API автоматом работает для того языка, какой по умолчанию стоит на смартфоне. Установили русский — фиг вам, а не англоязычный поиск (т.е. поиск по англоязычным названиям).
Еще один вопрос — плагин к YouTube. Он есть, работает, но неудобно. Это как раз тот случай, когда интерфейс выбивается из общей концепции… и как себя не мотивируй, все равно через неделю ролики снова смотришь в браузере.
Также Kodi не предназначен для аудиокниг, иногда очень хочется поставить ребенку сказку в аудио, без визуального ряда. Было бы здорово, если б он из коробки работал с длинными аудио-файлами как с фильмами — запоминал место остановки, собирал на отдельную страницу “то, что слушается сейчас”.

Kodi — штука кроссплатформенная. Но именно у нас пока установлена Винда — до сих пор она живет только из-за еженедельной связи по Skype с бабушкой из другого города. Видеосвязь Skype с зоопарком камер во время тестов Ubuntu как-то не очень пошла. Быть может, эта проблема уже решена, а я и не знаю… Но уж ковыряться буду, если поставим IP-камеру с управлением обзором со смартфона — был такой отдаленный план.

Полезные фичи


Помимо непосредственно просмотра контента, Kodi у меня реализует несколько полезных фич из разряда “хочу с перламутровыми пуговицами”.

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

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

В качестве хранителя экрана опять же плагином подключается подборка фотографий. До рождения детей мы много путешествовали, так что в загашниках лежат гигабайты красивых картинок. В паузах между просмотром запускается слайдшоу, на которое дети залипают даже лучше, чем на некоторые мультики. Опять же, познавательный элемент: “Мама, а это что? А где тут папа? А это море?”…

Kodi поддерживает UPnP, поэтому при наличии нужного софта на смартфоне я не только могу запустить следующий мультик детям из другой комнаты, но и одновременно(!) досмотреть на смартфоне серию контента не для малышей (ресурсов на это, как ни странно, хватает, если речь не идет о тяжелом 1080p).

Вместо резюме по софту и железу


Не исключено, что мой комплект, формирующий “головное устройство”, безбожно устарел. Но в этом тоже есть сакральный смысл: пользователи вообще и я в частности по своей природе консервативны. Я не буду гоняться за последними новинками техники, только потому что вышел новый стандарт (допустим, 4К). Учитывая всякие семейные обстоятельства, я панель до 1920*1080 обновить уже года 3 собираюсь, да все никак не соберусь (сейчас — 720 по короткой стороне). За новинками обычно гоняется лишь небольшая часть аудитории — люди определенного склада интересов. Т.е. продать мне что-то “потому что оно поддерживает вот эту последнюю фичу, без которой вы точно жить не можете” — не прокатит.
Однако когда я начну выбирать обновление для своей техники, я посмотрю, что вообще появилось на рынке с последнего моего взгляда в ту сторону… и подумаю, какие из новых функций мне нужны. Т.е. заявлять о функциях таки надо. Причем, важное — вперед.

Как мне продать подписку на сервис


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

Почему нет любимого телеканала?


Мы не смотрим ни одного телевизионного канала. Но вовсе не из соображений “там ничего нет”. Просто телепрограмма — слишком уж неудобный способ ориентироваться в многообразии контента, особенно для мира, где есть поиск по видео YouTube, подсказки с рекомендациями потенциально интересного контента (на основе уже просмотренного) и т.п.
Помню, энное количество лет назад была попытка навесить все эти функции на обычное спутниковое телевидение — свои идеи реализовывала компания Рикор. Там сидел целый штат модераторов, который “причесывал” телепрограмму, проставлял теги и т.п. Проект не взлетел (насколько вообще можно так сказать о спутниковом ТВ, проработавшем несколько лет). Но рассказывать, как это плохо, я тут не буду — их продукт все равно не то, что нам надо. Они, опять же, слишком зациклились на идее улучшения телевидения с его привычной линейной моделью. Итогом их работы становился персональный канал. А чтобы продать мне (таким, как я) ТВ-сервис, надо вообще отказаться от идей телевидения в виде линейного потока — только контент по запросу, обернутый в хороший (ХОРОШИЙ!) рекомендательный сервис.
Про рекомендации хочу сказать отдельно.
Потенциально сервис рекомендаций — штука очень интересная. Но правду говорят исследования: если несколько раз хорошо ошибиться, пользователя можно потерять навсегда. С рекомендациями важно доверие. И я пока не видела ничего, что не ошибалось бы. IMHOnet выдавал мне жизнеспособные рекомендации, но процент ошибок все же был довольно велик. Плюс проблема имхонета в том, что надо выставлять оценки. Рано или поздно заносить впечатления от просмотра нового надоедает, и рекомендации зависают на определенном уровне — не поддерживают постепенной эволюции вкусов. YouTube в этом смысле действует немного грамотней, опираясь на последние просмотры.

Важная мысль 3: Традиционно считается, что есть 2 возможных варианта потребления контента. Либо человек не знает, чего хочет, и смотрит линейные телеканалы (федеральные или тематические). Либо человек четко знает, что хочет. Мы же не попадаем ни в одну из этих групп. Не знаем, чего именно хотим, но готовы слету определить критерии поиска желаемого. Проблема в том, что они настолько узки, что им не отвечает ни один даже очень нишевый канал.

Важная мысль 4. Значение рекомендательных сервисов сложно переоценить. Но здесь ключевую роль играет качество подсказок. Нельзя просто показать похожие видео и этим ограничиться — продавать такой сервис не будет. Сюда надо вкладываться. Искать специалистов, платить им за разработку. Не уверена, что экономика в рамках одного оператора сойдется. Но чем черт не шутит, может “взлетит” независимый сервис на базе big data, предоставляющий услуги бизнесу…

Какой контент нам нужен?


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

Я смотрю и пересматриваю избранные сериалы из разряда Элементарно, Шерлока, Теории большого взрыва и т.п. Пополнить подборку и рада бы, но последний десяток рекомендаций от сервисов капитально промахивались.
Новые фильмы смотрю редко — не нравится мне идея франшиз в кино (и N+1 серий одного и того же сюжета), а на авторские фильмы не хватает моральных сил. Желание посмотреть фильм, который недавно шел в кинотеатре — явление редкое. И держится оно не так уж долго. Чем быстрее фильм появится в ОТТ-прокате, тем с большей вероятностью желание его смотреть доживет до “интернет-премьеры” (и я с большей вероятностью заплачу за него денег).
Вопреки статистике, которая говорит, что домохозяйки с головой интересуются новостями и иногда даже политикой, новости я читаю со смартфона в туалете, но никогда не потребляю в виде новостного выпуска или отдельных роликов по ТВ. Потому что в доме дети и я хочу на данной стадии фильтровать картинку, которую они воспринимают (фото из Альп в этом смысле мне кажутся более достойным выбором).

Муж, смотрит авторские передачи. Как мне кажется, его привлекает идея циклов познавательного — даже в чем-то обучающего — контента (не надо с нуля решать, что посмотреть) в рамках заданной темы. Я обратила внимание, что определяющим фактором для него является спикер в передаче. Если уж ему понравились кулинарные шоу Джейми Оливера — то пересмотрит все, вне зависимости от канала, продюсера и других параметров. В этом смысле YouTube полностью закрывает его потребность в новых роликах. Но там не показывают кино, поэтому ему приходится делить внимание с другими инструментами (с той же домашней подборкой в Kodi). В отличие от меня, он как раз следит за новинками кино, но из-за недостатка времени порой ограничивается обзорами известных ему критиков (опять на YouTube). Мужу кино нужно как можно быстрее после премьеры (пока оно на слуху) — наследие старой профессии дизайнера, когда надо было быть “в теме”. Зато вот качество картинки для него не определяющий фактор (как и всех, HD 60 кадров в секунду его притягивает и завораживает, но он не требует от всего контента такого эффекта).

Дети смотрят мультики. Есть любимые и не очень. Полнометражные и сериалы. Но поколение, видевшее линейное телевидение только в гостях, не понимает, как может быть, что в данный момент не посмотреть мультик, допустим, про паровозики? Для них понять это сложнее, чем принять сенсорные экраны, концепции дистанционного управления, да и 3D-принтер, из которого появляются новые детали для железной дороги. Я думаю, они уже никогда не будут полноценными телезрителями (как мы радиослушатели — только в машине, и то изредка).

Каким должен быть НАШ сервис


Возможно ли соединить все это в рамках одного сервиса? И да, и нет.
Одним из основных параметров, на которые мы смотрим при поиске нового сервиса для подписки, — база контента. Посмотрели многое, но пока глаз падал только на Амедиатеку (несколько раз брали подписку на него, чтобы посмотреть определенные сериалы). Другим не хватает рейтинговых новинок. Понятно, что тут роль играет экономика: хочешь рейтинговые новинки — плати. Но вы дайте мне не одну новинку в полгода, а полностью закройте мои контентные потребности, и я заплачу. Думаю, и тысяча, и 1,5 тыс. рублей в месяц была бы нормальной суммой (но, внимание, потребности надо закрыть ПОЛНОСТЬЮ!). Плюс нужен комфорт использования.
Амедиатека так и не стала постоянной статьей расходов, поскольку опять где-то что-то неудобно. В частности, неудобно переключаться между Kodi и личным кабинетом сервиса на ПК (это относится не только к Амедиатеке, но и ко всем, кто показывает контент в браузере).

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

Важная мысль 6. Сейчас конкурентное преимущество ОТТ-сервиса — контент. Понимая это, сервисы перетягивают друг у друга контракты, как одеяло в холодную ночь. В итоге востребованный контент рассредоточен по разным ресурсам. Нет какого-то лидера рынка, который бы собрал под собой большую часть рейтингового содержания. Видимо, должно пройти время, прежде чем рынок немного консолидируется и можно будет выбирать, кому нести деньги на регулярной основе. А пока я готова платить только за разовые просмотры (сколько то рублей серия / фильм, а не подписка на месяц). В пределах 100 рублей за серию хорошего сериала, на мой взгляд, нормально. Но с условием, что просмотр будет доступен не 3 дня, а, скажем, год или хотя бы месяц. Вряд ли я воспользуюсь возможностью что-то пересмотреть, но мне очень не нравится, когда меня зажимают в сроках. Текущий ритм моей жизни на это не рассчитан.
На мой взгляд, продажа подписок — это все то же наследие линейного телевидения… желание продать контент потребителю оптом. Разве вам в продуктовом предлагают макароны брать только с соусом болоньезе и никак иначе? Думаю, и продажа каналов a la cart в свое не пошла ровно потому, что это натягивание одной модели на другую: линейное телевидение мы пытаемся продать как нелинейное (ориентируемся на нелинейную аудиторию, но пытаемся ей оптом втюхать линейный продукт — последовательность передач).


Прочие устройства


Некоторое время назад ОТТ-сервисы массово ринулись на карманные устройства — планшеты и смартфоны. В нашем варианте это работает только в рамках домашней сети. Т.е. дома что-то на дополнительном устройстве очень редко досмотреть можно. А тут достаточно UPnP.
Для мультиков в дороге у нас есть USB-флешка с мультиками и OTG-переходник для смартфонов. Желание воспользоваться мобильным телевидением (Мегафон ТВ) возникло за все время ровно один раз — когда я лежала со старшим ребенком в больнице, почему-то отправившись туда без ноутбука. Ребенка надо было как-то отвлекать от капельницы. Кстати, до сих пор не понимаю, почему мобильные операторы не догадываются раскладывать в таких заведениях памятки для родителей (о том, что такая услуга есть, сколько стоит и как подключиться). Не обязательно же из этого рекламу делать: можно, например, игровую комнату в больнице обставить; игрушки обновить. А за это договориться о размещении одного текстового объявления.

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

Вместо заключительного дисклаймера


Я смотрю на ситуацию как конечный пользователь. А уж как на эти идеи натягивать экономику — надо думать отдельно.
Все описанное волшебство существует (и может существовать) только в комплексе. Не будь нормального железа и интерфейса — не будет и по-настоящему нелинейного потребления (максимум — просмотр роликов с YouTube). Как сделать разработку такого “комплексного” продукта более-менее рентабельной? Наверное, через партнерство разных сервисов и поставщиков. Вряд ли это под силу одной компании.

Важная мысль 7. Не достаточно дать только устройство или только сервис. Они должны идти в паре. И одно должно дополнять другое!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334746/


Метки:  

[Из песочницы] Как мы мультиплеер для NFS MW писали

Среда, 02 Августа 2017 г. 17:27 + в цитатник

Метки:  

[Перевод - recovery mode ] Пора восстанавливать данные. Вы знаете, где они?

Среда, 02 Августа 2017 г. 17:26 + в цитатник
Создание резервной копии данных — только начало. Вам необходимо убедиться в том, что резервные копии содержат в себе необходимые данные и совместимы с приложениями, которые будут пользоваться ими.

image

Итак, вы регулярно создаете резервные копии, но однажды вам придется восстанавливать данные. Знаете ли вы, где они находятся? Можете ли вы пользоваться ими?

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

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

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

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

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

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

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

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

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

Несколько важных рекомендаций о резервном копировании и восстановлении:

  • Помните формулу «4, 3, 2, 1» — расширенный вариант формулы «3, 2, 1» («дед, отец, сын» или «бабушка, мать, дочь»). Ее смысл состоит в том, что вам необходимо иметь не менее четырех копий защищаемых данных как минимум трех версий (точек восстановления), из которых как минимум две находятся на различных серверах, хранилищах, носителях или системах, а как минимум одна — в другой среде (подключенной или неподключенной).
  • Уменьшайте объем данных на исходной и целевой системах с помощью сжатия, дедубликации и других методов.
  • Пересматривайте стратегию защиты данных: что, где, когда и для чего вы защищаете, как часто создаете резервные копии, как долго храните их и каков уровень детализации резервного копирования (полные копии, образы, файлы, объекты или базы данных). Помните, что центры обработки и инфраструктуры данных, среды, организации и даже отдельные приложения имеют свою специфику. Не пытайтесь применять одни и те же правила защиты данных ко всем приложениям, данным, настройкам и конфигурациям.
  • Собирайте информацию с помощью аналитических инструментов. Автоматизируйте функции обнаружения и отображения количества резервных копий, их версий, местоположений, сроков хранения и другой служебной информации.

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

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

Напоследок последний тезис: помните, что только вы можете предотвратить потерю данных.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334742/


Метки:  

Дайджест событий для HR-специалистов в IT-области на август 2017

Среда, 02 Августа 2017 г. 17:21 + в цитатник
image

Август — время отпусков и отдыха, но HR-специалистам некогда отдыхать. Хотя событий в августе меньше, чем обычно, «Мой круг» публикует для всех, кто ещё не уехал на море или уже успел вернуться, перечень полезных и интересных мероприятий для HR-специалистов, которые проходят в августе.



В поиске все средства хороши или где еще не ступала нога рекрутера


Когда: 6 августа, 18:00
Где: Санкт-Петербург, Большой Сампсониевский проспект, д. 61 к.2, БЦ «Бекар», коворкинг GrowUp
Условия участия: Бесплатно
Организатор: «Мой круг»

Успешные рекрутеры делятся опытом по использованию различных средств поиска кандидатов.

  • Егор Яценко, со-основатель агентства Wanted: Profi, расскажет о своем опыте рекрутинга в мессенджерах.
  • Евгения Остроумова, IT-рекрутер агентства GMS, расскажет о том, зачем разработчикам Twitter и как через нетворкинг искать интересных кандидатов.
  • Анна Атрошкина, со-основатель агентства INDEX, расскажет о приемах и секретах поиска на «Моем круге» и «Хабрахабре».

Подробности и регистрация



Препарируем профессию Skala Developer (семинар)


Когда: 8 августа, 18:00
Где: Москва, место проведения уточняется
Условия участия: Бесплатно
Организатор: Spice IT

Докладывает Алексей Фомкин из Scala User Group.

Подробности мероприятия (в группе Moscow IT HR Community на Facebook, группа закрытая, требуется вступление)



Секреты IT-подбора (тренинг)


Когда: 24-25 августа, 11:00
Где: Москва, улица Новый Арбат д. 21, стр. 1, HYUNDAI MOTORSTUDIO
Условия участия: стоимость обучения 10 900 рублей
Организатор: IT Recruiter School

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

Подробности и регистрация



Препарируем профессию Product Manager (семинар)


Когда: 28 августа, 18:00
Где: Москва, место проведения уточняется
Условия участия: Бесплатно
Организатор: Spice IT

Докладывают Марк Тен из Sports.ru и Харитон Матвеев из SkyEng.

Подробности мероприятия (в группе Moscow IT HR Community на Facebook, группа закрытая, требуется вступление)



Об организаторах мероприятий

  • Мой круг — сервис поиска ИТ-специалистов, часть экосистемы Хабрахабра.
  • GMS — рекрутинговое агентство, специализируется на поиске ИТ-специалистов.
  • INDEX — рекрутинговое агентство, специализируется на поиске ИТ-специалистов; у агенства также есть INDEX School, где обучают HR специалистов, которые работают в ИТ-сфере.
  • IT Recruiter School — школа ИТ-рекрутинга.
  • Spice IT — рекрутинговое агентство, специализируется на поиске ИТ-специалистов; у агенства есть сообщество Moscow IT HR Community, объединяющее московских HR специалистов.
  • Wanted: Profi — рекрутинговое агентство, специализируется на поиске ИТ-специалистов.

Если мы пропустили какие-то события для HR-специалистов в области ИТ, которые проходят в августе, пожалуйста, добавляйте их в комментарии.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334732/


Метки:  

В разрезе: новостной агрегатор на Android с бэкендом. Система последовательной интеграции

Среда, 02 Августа 2017 г. 17:00 + в цитатник
Вводная часть (со ссылками на все статьи)

«Система последовательной интеграции», не уверен, что перевод правильный – лучше называть система непрерывной интеграции (continuous integration).
С ними первый раз я столкнулся в начале своей работы, когда 5-7 программистов усиленно писали код и тесты, меняли конфигурационные файлы и лили все свои результаты в trunk/master. В итоге частенько (так частенько, что аж бесило) в основной ветке появлялось нечто нерабочее. Причём выявлялось это тогда, когда нужно было развернуть тестовый стенд, что сильно замедляло работу группы тестирования (ждали исправления) и разработчиков (соответственно исправляли). Т.е. работоспособность кода не контролировалась после помещения его в репозиторий.

image
Тогда на помощь нам пришёл Hudson (http://hudson-ci.org/) (сейчас более известен как Jenkins (https://jenkins.io/), хотя формально сам Hudson остался, но не так популярен и не так активно развивается) – он осуществлял множество дел:
  • выполнял сборку и запуск модульных тестов после каждого коммита;
  • после коммита в ветку с релизами убивал старый и запускал новый тестовый стенд для команды тестировщиков;
  • генерировал отчёты по исходным кодам (покрытие тесами, показатели соответствия стандартам тестирования);
  • генерировал документацию для wiki.
  • кроме того через его интерфейс можно было отслеживать кто какие коммиты вносил, как со временем менялось покрытие тестами, за какое время осуществлялась сборка и прогон тестов и самое главное — из-за кого был сломан билд.


Это было реальным шагом вперёд в части повышения качества и прозрачности работы команды разработчиков (я уже не говорю про минимизацию вероятности появления «каши» в master/trunk’е):
  • удалось выяснить, что какие типовые ошибки допускал при работе с системой контроля версий (кого-то наказали, кого-то обучили);
  • для предотвращения совместного редактирования одного большого файла с конфигурациями было выполнено его разделение, а так же изменена логика сборки;
  • были разработаны и зафиксированы правила работы с ветками (ранее работали по принципу «ведь все понимают…», т.е. официальных правил не было).


Но это всё было ранее. Теперь вопрос: в чём смысл использования системы непрерывной интеграции при работе в одиночку?
До определённого момента смысла не было реально никакого. До тех пор пока проект не разросся (даже при участии одного разработчика) и тут наличие сервера интеграции показало свою реальную ценность:
  • в связи с тем, что стенд для запусков интеграционных тестов формируется с помощью конфигурационных файлов, в которых прописаны версии других компонентов, которые потом подтягиваются системы хранения готовых артефактов (на базе Nexus Sonatype) – достаточно важным вопросом стало корректное указание версий компонентов и проверка их совместной работоспособности. Однако эта проверка вещь затратная по времени (время на закачку артефактов, сборку стенда, запуск, прогон интеграционных тестов). Поэтому на сервере интеграции я настроил задачу на свою рабочую ветку, в которую иногда сливаю, по моему мнению, рабочие варианты и продолжаю работу. По истечении какого-то времени могу проверить – верно ли моё предположение о работоспособности или нет;
  • запуск модульных тестов для локального кластера с Apache Storm, даже с подменой всех компонентов через Dependency Injection на Stub/Mock, занимает порядочное количество времени и я иногда забываю запускать их все целиком, что приводит (так же иногда) к неработающему коду в master – при наличии CI это выявляется моментально после «git push»;
  • (не систематично, но пару раз было) с учётом наличия в git не только кода, но так же и конфигурационных файлов и файлов с данными, при корректировке «.gitignore» возникали ситуации, когда из репозитория исключались вместе с ненужными и нужные файлы. При этом на моей машине они сохранялись и тесты работали, а вот на сервере CI – моментально этот факт отслеживался.


Дополнительным интересными особенностями Jenkins является его интерфейс, позволяющий наблюдать за:
  • временем выполнения pipeline и её стадий
    image;
  • графическим отражение количества отработанных/пропущенных/отработанных тестов
    image;
  • табличным отражение количества отработанных/пропущенных/отработанных тестов
    image;
  • детальными данными по последним коммитам, вызвавшим сборку
    image;
  • детальными данными по коммиту, вызвавшему конкретную сборку с возможностью перехода в тот же GitHub для детального изучения изменений
    image.


Pipeline


Самым значительным функциональным улучшением Jenkins по прошествии некоторого времени его неиспользования стало для меня появление plugin’а «Pipeline», который позволяет либо через интерфейс самого Jenkins, либо через отдельный конфигурационный файл самого проекта (файл Jenkinsfile) определить, что будет выполняться/запускаться/проверяться сервером CI при получении кода вашего проекта/модуля.

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

Например, в одном из моих под-проектов файл Jenkinsfile имеет следующее содержание:
#!groovy
node {
   def projectName = 'glr_parser'
   def gradleHome = tool name: 'gradle', type: 'gradle'
   stage('Checkout') { // for display purposes
      // Get some code from a GitHub repository
	  // parent directory
	  checkout changelog: true, poll: false, scm: [$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'CleanBeforeCheckout']], submoduleCfg: [], userRemoteConfigs: [[url: 'story_line2_build.github.com:fedor-malyshkin/story_line2_build.git']]]
	  // project itself
	  checkout changelog: true, poll: true, scm: [$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'RelativeTargetDirectory', relativeTargetDir: "${projectName}"]], submoduleCfg: [], userRemoteConfigs: [[url: "story_line2_${projectName}.github.com:fedor-malyshkin/story_line2_${projectName}.git"]]]
	  // deployment
	//   checkout changelog: true, poll: false, scm: [$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'RelativeTargetDirectory', relativeTargetDir: 'deployment']], submoduleCfg: [], userRemoteConfigs: [[url: 'story_line2_deployment.github.com:fedor-malyshkin/story_line2_deployment.git']]]
   }
   stage('Assemble') {
	   dir(projectName) {
	   // Run the maven build
	   sh "'${gradleHome}/bin/gradle' -Pstand_type=test assemble"
	   }
  }
  stage('Test') {
	  dir(projectName) {
	   try {
		   sh "'${gradleHome}/bin/gradle' -Pstand_type=test test"
	   }
	   finally {
		   junit "build/test-results/test/TEST-*.xml"
	   }
	   }
  }
}

Как видите – это фактически несколько модернизированный groovy (DSL для Jenkins). Pilpeline состоит из этапов, шагов и узлов. При этом этапы отражаются в Stage View Plugin’е, который все так любят показывать в презентациях и прочих выступлениях.

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

Tips


  • Проблемой при настройке задач Jenkins для меня была необходимость предоставления доступа на чтение к закрытому репозиторию GitHub (при этом забивать пароли с учётными записями в настройки не было ни малейшего желания), это было решено с использованием GitHub Deploy Keys (см. мою более раннюю статью)
  • Для отслеживания статуса задач на мобильном устройстве (Android) использую на удивление хороший клиент с очевидным именем Jenkins.
    Пара скриншотов:
    image
    image
    image
  • Есть ещё интересный толстый клиент для PC для отслеживания статуса сборки CatLight (но опыта использования нет).


На текущий момент из минусов Jenkins можно отметить лишь недостаточную документацию на продукт: часто в разделе документации на сайте разработчика можно увидеть надпись: «This is still very much a work in progress». Однако это не должно отталкивать от, по-настоящему, гибкого и мощного продукта.

Спасибо за внимание!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334730/


Метки:  

Организация мероприятий — ниша для IT-решений

Среда, 02 Августа 2017 г. 16:57 + в цитатник
image

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

Маркетинг активно ищет новые решения


Надо понимать, что для бизнеса ивенты — это маркетинг. А маркетинг – сфера крайне разносторонняя по широте своих интересов. Ее участники находятся в постоянном поиске новых решений и делают это очень активно. Здесь сосредоточены большие бюджеты, поэтому повод для активности есть.
Кризис, который затронул большинство отраслей экономики и принудил к жестким ограничениям, не сократил емкость рынка маркетинговых коммуникаций. Данные относительно его реальных значений сильно разобщены. Обобщенная статистика из открытых источников представлена в виде диаграммы.


Динамика рынка маркетинговых коммуникаций в России, в т.ч. BTL-сегменте (по данным совета РАМУ)

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

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

Почему BTL-Event-маркетинг перспективен


Добровольно засунув голову в пасть дракона Приняв решение реализовывать свои IT-интересы в BTL-event-маркетинге, я стал вникать в кухню друзей-ивенторов. И открыл для себя два термина, перспективных из-за близости к IT, – это «механика мероприятия» и «геймификация» (game-фикация). В обоих случаях спецам из IT есть повод принять непосредственное участие.

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

Ради привлечения внимания ивенторы готовы на все


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

Со времён «Generation П» в рекламной кухни, по своей сути, ничего не изменилось. Все участники этого рынка находятся в поиске технологии, которая обеспечит «WOW-эффект» людям, в целом, и посетителям их мероприятия, в частности. «WOW-эффект» — настоящая фата-моргана ивенторов, потому что заказчики хотят от них именно этого — ВАУ.

Время от времени появляются технологии, способные обеспечить подобный эффект. Ивенторы непрерывно мониторят рынки на предмет появления таких технологий, собираются на ежегодные конференции, чтобы разглядеть и обсудить потенциал новинок. Статистика международных исследований свидетельствует, что за использование digital-технологий на мероприятиях выступают 87% ивенторов. Потому что понимают – включение их в механику мероприятия автоматически означает перенос wow-настроения заказчика на свою репутацию. Это вторая цель, ради которой ивенторы предпринимают свои титанические усилия. Первая – банальная и вечная – деньги!

Вращаясь на рынке BTL-event-маркетинга с 2011 г., мне удалось подытожить личные наблюдения.

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

Выступая на мероприятиях, к примеру, в Крокус-Экспо, где присутствуют множество участников-супербрендов – Nissan, Toyota, Infiniti и т.д. наблюдаю очередное соревнование числа телевизоров и эффектности авто-шоу-герлз. А вот технологий, похожих на «WOW-эффект», пока не видел. Публику авто-девушки и огромные плазмы давно не впечатляют, люди равнодушно проходят мимо.

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

У event, digital и интернета много общего


К использованию digital существуют разные мотивации.

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

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

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

Преимущества digital-технологии в механике мероприятия


Когда обсуждаем с заказчиком event-digital-маркетинг в нашей WiFi-услуге, то обещаем вот что:

  1. «Склеить» с помощью digital-технологий абстрактную аудиторию гостей мероприятия с их профилями в соц. сетях. И получить в свое распоряжение огромное количество разнообразной информации.
  2. Вовлечь всю аудиторию в общение между собой.
  3. Прилепить аудиторию к себе, чтобы и по окончанию мероприятия иметь возможность дотянуться до них своим промо. Потому что сегодня в тренде и считается профессиональным выстраивать коммуникацию с человеком не с помощью навязчивых mail-рассылок и смс, а через конкретный профиль в соц. сетях.
  4. Вовлечь в маркетинг бренда дополнительную аудиторию: онлайн-друзей посетителей мероприятия.
Расскажу об этом на конкретных примерах.

Кейс ТНТ


Мой опыт использования digital-технологий начался с промо-мероприятия канала ТНТ в клубе Space Moscow в октябре 2014 года. В механику события была зашита продвинутая game-фикация.

В то время фишкой телеканала считалась заставка с красным диваном, сидя на котором разные персонажи шоу-бизнеса произносили фразу: «ТНТ – почувствуй нашу любовь». На своем мероприятии телеканал сделал ставку на популярность дивана и придумал следующее. Имитируя настроение рекламы, на танцполе был установлен этот предмет мебели и узнаваемый задник. Гости получили возможность предстать в роли медийных лиц ТНТ и делать селфи на мобильные устройства. Далее фото предлагалось разместить в Instagram, снабдив #ТНТ_почувствуй_нашу_любовь.

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

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

Выбранным #Почувствуй_нашу_любовь также дополнительно пропиарен слоган канала ТНТ.

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

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

Кейс «Связной»


В отличие от промо-формата мероприятия ТНТ, «Связной» определил свой формат как внутренний. То есть промоушн бренда был не нужен. Задача состояла в том, чтобы удивить гостей богатством интерактива.

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

Приложение создавалось нашими партнерами и, по сути, представляло собой мини соц. сеть со следующими возможностями:

  • видеть остальных участников мероприятия;
  • добавлять фото и видео;
  • обмениваться сообщениями и другими материалами;
  • участвовать опросах;
  • задать вопрос спикеру.

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

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

В целом, за интерактив на мероприятии отвечали:

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

Результат использования digital-технологий на закрытом мероприятии «Связного» – полностью авторизированные 600 гостей, чью активность мы могли наблюдать и анализировать.

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

Тренд: все ищут что-то новое, но как его найти


Сегодня на BTL-event-рынке существует устойчивый тренд – разыскать что-то интересное из digital. На практике часто это выглядит таким образом: крупный бренд или заказчик объявляет тендер на поиск исполнителя, способного обеспечить разработку digital-360 по продвижению бренда на мероприятиях в течение года. Но в условиях тендера нет конкретики – что именно хочет заказчик. Есть только основные векторы или общие слова. Предлагается самим предложить стратегию в рамках заданного брендом бюджета, основные надежды возлагаются на креативность event’оров.

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

В понимании event’ора digital-тренды – это следующее.

  1. Разные способы вовлечения аудитории в виртуальную реальность. Самые традиционные из них – сайты, хэштеги, и т.д., включая создание специальных компьютерных игр под мероприятия. Тогда часть мероприятия происходит в офлайн-режиме, а другая – в компьютерной игре, digital-пространстве.
  2. Использование соц. сетей — до сих пор в тренде. Хотя «WOW-эффект» там вряд ли возможен, соц. сети рано списывать со счетов event-рынка.
  3. VR — один из бесспорных лидеров среди обсуждаемых трендов. Загвоздка в малочисленности идей для их использования в BTL-event-маркетинге.
  4. Тренд с геймификацией — стопроцентный мэйнстрим. Он очень перспективен, но пока недостаточно востребован. Тот, кто сумеет предложить event-рынку разные сценарии для встраивания в механику мероприятия – оседлает волну.
  5. Визуализация аудитории, чат-боты вместо приложений и умный браслет, анализирующий эмоции посетителей.

Чем здесь заняться IT-шнику: прогнозы


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

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

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

PS Буду рад вашим комментариям. А в ближайшее время в планах продолжение об имеющихся технических практиках. Расскажу и о том, какие грабли не обошёл стороной и что за ноу-хау приходилось применять для обеспечения мероприятий техническими решениями.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/329810/


Метки:  

[recovery mode] Почему исправление орфографических, грамматических и пунктуационных ошибок в продукте очень важно

Среда, 02 Августа 2017 г. 16:50 + в цитатник
Проделав отличную работу и придумав понятное, лаконичное название для текущего текста – а это, по заверениям специалистов писать тексты, уже очень многое – я могу тотчас же изложить свою гипотезу. Некогда я читал, что «продукт может быть хорошо спроектирован, эффективно выполняя свои функции, но неправильная терминология или отсутствие запятых в нужных местах подрывают доверие пользователя к нему». Вот одна из версий, почему это происходит.

Профессиональные сообщества, зачастую состоящие из «узких» специалистов, очень чутко относятся к своей области. Это, конечно, не уникальных признак, а скорее универсальное человеческое стремление привести в порядок свой мир, в том числе, путем использования строгой терминологии внутри него. По крайней мере, специфический язык внутри их профессиональной области позволяет приобрести им некоторую упорядоченность, придать стандартизированность и достичь высокой эффективности в окружающем их хаосе. Более того, это помогает для личной самоидентификации, когда те или иные групповые особенности являются носителями принадлежности к уникальной группе. Через них человек сам приобретает определенную уникальность. И эпизоды, когда некто извне, некто, не принадлежащий их кругу, врывается в их священное место, в их уникальную, неповторимую группу, — врывается, совершая ошибки, — могут справедливо восприниматься как ярко выраженные акты неуважения, порождая раздражение и неприязнь. Это известная защитная реакция на покушение на ценности. Не надо лезть на чужую кухню без специальной подготовки. К тому же, и это вторая причина высокого уровня раздражения, которое вызывают не какие-то функциональные или usability недочеты, а приземленные «пиши «чк», «чн» без мягкого знака», — это очевидные и доступные ошибки. Неудобно работающая функциональность или группировка кнопок по принципу «винегрет» для пользователя приносят значительные неудобства и слабо помогают выполнению их задач. Однако не редко они сами этого не знают и довольствуются тем, что есть. В этом одна из причин большого количества некачественно спроектированных программных продуктов. Алан Купер назвал этот феномен «Танцующим медведем», и заключается он в том, что пользователь пользуется программой, совершенно не представляя ее потенциальных возможностей и того, как еще более лучше она может служить ему. Она уже работает, и, кажется, работает не так уж плохо. Так почему бы мне не радоваться уже этому? Слепое следование инструкциям без внятного понимания, для чего нужные некоторые действия, можно назвать «компьютерной магией», фактически же, лучшее название для этого – ритуал. И он неприкосновенен. Иное дело, когда человек видит явно отсутствующую запятую в некоем сообщении с одной кнопкой «Ок». Он не замечает, как только что эта ошибка выбила его из рабочего процесса и переняла на себя его главную монету – внимание. Он не замечает, что бессмысленность неинформативного сообщения без возможности выбора команды для компьютера, кроме «Ок», кажется, достигает своего абсолютного статуса. Он не замечает, что продукт своим мерзким сообщением плюнул ему в лицо, обвинив в глупости и переложив собственный недочет на его шею. Об этом пользователь может и не догадываться. Сейчас он видит явную пунктуационную ошибку. И единственный вопрос тревожит его сейчас – вопрос о профессионализме разработчиков.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334736/


Метки:  

«Горшочек, вари»: 50 инструментов для управления разработкой

Среда, 02 Августа 2017 г. 16:11 + в цитатник
Неэффективность бизнес-процессов, по данным исследовательской компании IDC, «съедает» от 20 до 30% доходов бизнеса. Одним из ключевых источников низкой эффективности являются рутинные задачи, которые могли бы быть автоматизированы. Автоматизация может сэкономить время, деньги и спасти от головной боли. Это факт. По данным McKinsey, автоматизация процессов может обеспечить снижение затрат до 90%. Поэтому инвестиции в соответствующие инструменты с лихвой себя оправдывают.

На корпоративном уровне популярностью пользуются решения, позволяющие автоматизировать важнейшие сервисные процессы компании в финансовом, юридическом, кадровом секторах. Например, одним из таких инструментов является платформа ServiceNow, внедрением функционала которой занимается компания «ИТ Гильдия».

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

/ Flickr / Florian Richter / CC

Технология — это ключ к росту эффективности в организации. Так считают 96% опрошенных независимым исследовательским агентством Loudhouse руководителей. Согласно исследованию, 53% из тех, кто в своих программах по повышению эффективности делает ставку на технологии, больше уверены в успехе, чем их менее открытые к технологическим инструментам коллеги.

Управление задачами


  • Trello: инструмент для ведения проектов и распределения задач между членами команды.
  • Asana: еще один планировщик задач, ориентированный на командные проекты.
  • Basecamp: онлайн-инструмент для управления проектами.
  • Runrun.it: делегирование задач с подробным описанием и сроками.
  • Evernote: инструмент помогает контролировать персональные задачи.
  • TimeCamp: управление проектами с определением бюджетов и отчетами.
  • Ecamm Call Recorder : запись деловых звонков для последующего учета задач.
  • Standup: генерация отчетов о ходе разработки.

Организация рабочего времени


  • Calendly: инструмент для организации виртуальных встреч.
  • Freeter: собирает все необходимое для работы над проектом в одном месте.
  • Mighty Networks: платформа для комплексной подготовки к встречам.
  • Timeneye: эффективный способ тайм-менеджмента.

Работа с почтой


  • IFTTT + Google Drive: экспортируйте файлы из писем.
  • DragApp: менеджмент потока входящих сообщений.
  • Cleanbox: инструмент для отписки от всех рассылок в один клик.
  • Boomerang: покажет, прочитал ли получатель письмо.

Сбор, синхронизация и подготовка данных


  • Tiny Reminder: сбор задач и файлов у заказчика в удобной форме.
  • Agenty Chrome Plugin: плагин, извлекающий информацию с любого сайта.
  • Beyond Compare: сравнение файлов и папок с помощью простых команд.
  • Syncthing: инструмент для синхронизации и резервного копирования данных.
  • Koala App: кроссплатформенное приложение для автоматической компиляции файлов.
  • Cyberduck: FTP-клиент, обеспечивающий удобную передачу файлов.

Создание прототипов


  • Axure: прототипирование интерфейсов.
  • InVision: для командной оценки идей перед непосредственным созданием продукта.
  • Visual Studio: проектирование элементов пользовательского интерфейса.
  • TranslateKarate: набор инструментов для быстрой локализации контента.

Написание кода


  • StackEdit: бесплатный онлайн-редактор, поддерживающий разметку.
  • Eclipse: Java IDE для автокомплита, рефакторинга и проверки синтаксиса.
  • Jet Brains Resharper: сниппеты и шаблоны кода.
  • Source Code Generator: генерация исходного кода для любого языка.
  • Snippets: менеджер сниппетов.
  • Postman: платформа для упрощения разработки API.
  • Gulp: инструмент для автоматизации трудоемких задач в процессе разработки.

Работа с базами данных


  • DaDaBIK: упрощает миграцию баз данных.
  • Devart: инструмент для сравнения баз данных.
  • OFFSCALE: контроль баз данных.

Выявление ошибок и проблем


  • Pivotal Tracker: оптимизация работы в команде.
  • Code Climate: автоматический анализ кода.
  • FindBugs: поиск багов в коде на Java.
  • Rollbar: отслеживание багов в реальном времени.
  • Monit: мониторинг и автоматическое обслуживание серверов.

Тестирование


  • BrowserStack: обеспечение совместимости с большинством устройств.
  • JUnit: интегрированная среда модульного тестирования.
  • Selenium: среда для тестирования на различных браузерах и платформах.
  • Rational Functional Tester: автоматизированное тестирование со множеством программных сред.
  • CircleCi: простое и быстрое автоматическое тестирование.
  • Hurl: инструмент для тестирования API.

Сбор фидбека


  • Satismeter: оценка удовлетворенности пользователей за счет анализа фидбэка.
  • UserVoice: инструмент для сбора и анализа данных от пользователей.
  • User Testing: анализ данных об использовании продукта.



P.S. Вот еще несколько материалов об автоматизации работы из нашего блога:



Используете ли вы инструменты для автоматизации рабочих процессов?

Проголосовало 5 человек. Воздержалось 5 человек.

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

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

https://habrahabr.ru/post/334518/


Метки:  

Развитие компании с помощью Open Source

Среда, 02 Августа 2017 г. 15:20 + в цитатник
Одним из самых больших препятствий, стоящих на пути роста небольших аутсорсинговых компаний является поиск клиентов. Каждая компания решает эту проблему по-своему. Кому-то достаточно работать с уже существующими клиентами и не думать о проблемах роста. Кто-то штурмует Upwork с бесчисленным количеством заявок, пытаясь найти стоящего клиента с интересным продуктом. Кто-то открывает отдел продаж, работники которого каждый день пишут сотни писем, делают десятки холодных звонков, которые, как вы знаете, далеко не всегда конвертируются в подписанный контракт.

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

Предыстория


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

В одной из компаний, в которых я работал, был долгий период застоя. У нас было много «свободных рук» (людей, не занятых на внешних проектах), мы штурмовали UpWork, но дело шло слишком медленно. Мы решили заняться разработкой шаблона (админки) для themeforest, разработка шла долго, мы сделали бесчисленное количество версий. Ни одна из версий не прошла проверку themeforest (и даже wrapbootstrap).

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

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

Тактика продвижения продукта на GitHub


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

  • Полезность. Люди любят продукты, которые решают их проблемы и делают жизнь проще.
  • Соответствие трендам. Иногда популярные слова решают все. Даже не самый полезный продукт может стать достаточно популярным, если использует подходы/технологии которые сегодня являются самыми горячими темами для разговоров.
  • Дизайн. Некоторые проекты делают то же самое, что и сотни других, но «выстреливают потому, что они по-настоящему красивы.

У вас есть отличный продукт, но его должны заметить люди. Что для этого сделать? Сначала нужно написать запоминающийся Readme.

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

Теперь у вас есть замечательный продукт с потрясающим Readme. Начинается самая ответственная часть.

У GitHub есть страница trending, которую ежедневно просматривают тысячи людей. Попав туда, ваш проект (если он хорош), имеет все шансы стать по-настоящему популярным. Страница trending имеет множество подкатегорий, но самый большой эффект дает именно главная страница. Чтобы попасть туда, необходимо набрать как минимум (цифры меняются день ото дня) 130 звезд, а желательно еще больше, чтобы подняться как можно выше и быть заметными максимально долго.

Для начала нужно туда попасть, вот что может вам помочь:
— Подумайте над ресурсами, которые вы собираетесь использовать при раскрутке. Обычно, помогает reddit, hackernews и другие, но заходить туда нужно с умом и для каждого ресурса существуют свои специфические правила публикации.
— Попросите ваших друзей помочь. Чем больше друзей-разработчиков поставят вам заветную „звездочку“, тем короче ваш путь до trending.
— Выберите день. Учтите, что посещаемость GitHub падает в выходные дни. На выбор дня запуска проекта влияют также те ресурсы, которые вы используете при раскрутке.
— Выберите время. У вас есть сутки — ваши друзья живут в одном часовом поясе, а пользователи Reddit (или другого ресурса) в совершенно другом. Вы должны это учитывать.
— Отвечайте на вопросы. Чем лучше вы будете общаться с аудиторией тех ресурсов, которые вы используете для раскрутки, тем больше будет и отдача от них.

Что дальше?


Имея популярный opensource-проект вы способны на многое. Не останавливайтесь! Попробуйте зайти на producthunt, чтобы сократить расстояние от продукта до клиента. Растите сообщество и сарафанное радио обязательно сработает. Используйте ваш продукт как портфолио — вас не связывает дурацкий NDA.

Я искренне надеюсь, что мои советы помогут вам и через некоторое время обязательно расскажу о том, помог ли наш собственный opensource-продукт моей компании.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334550/


Метки:  

Или Meteor

Среда, 02 Августа 2017 г. 15:00 + в цитатник

React без Redux, как водка без пива — деньги на ветер. Если React решает вопрос "интерфейс — функция состояния", то Redux предлагает архитектуру приложения. Но вот незадача, что выбрать для взаимодействия с бекендом? В случае с REST-API, можно дергать Fetch, можно взять чуть более функциональный Axios. Для WebSocket-ов есть Socket.io (крайне рекомендую к прочтению). А какие могут быть инструменты уровнем повыше? Реализация транспорта данных между фронтeндом и бекендом — не наша печаль.


Например, FeatherJS — можно переключать внутри протокол между REST и SocketIO без изменения API взаимодействия клиента, там просто Redux-интерфейс. Ещё есть Apollo и Logux, как две противоположности, но их тоже объединяет Redux-интерфейс.


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


А если вспомнить изоморфный Meteor (с которым я попрощался год назад): Data Distribution Protocol,
Pub/Sub-взаимодействие и MiniMongo на клиенте с Optimistic Updates. Как обстоят дела в Meteor сейчас: React там давно, но что про подключение Redux?


Индийский разработчик Abhi Aiyer опубликовал на Medium серию статей, вроде бы разобрав все аспекты (насколько я проштудировал Meteor-форум):



  • Replace Minimongo/Tracker/ReactiveVar/Session
  • Microservice Feature Development
  • Get on Apollo
  • For Legacy systems that still need DDP, use Asteroid, if you want to share login state between this SPA and your main Meteor app (comment down below I can help you out). With Asteroid you can still hit your Meteor backend for legacy pub/sub and meteor methods. (But you should be using GraphQL right?)

Пожалуйста, поделитесь опытом применения React+Redux в Meteor.


P.S. Да, я знаю о существовании MobX, не применял на практике, может оно и упростит магию реактивности в Meteor, но пока видится совсем избыточным и неидематичным :)

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

https://habrahabr.ru/post/334726/


Метки:  

Virtuozzo: Каковы реальные преимущества распределенного хранилища?

Среда, 02 Августа 2017 г. 14:57 + в цитатник
image

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

Для начала стоит сказать о том, что же такое Virtuozzo Storage (в среде разработчиков — VZ Storage). Решение представляет собой распределенное хранилище, использующее ту же самую инфраструктуру, на которой работают ваши виртуальные машины и контейнеры (так называемую, гиперконвергентную инфраструктуру — hyper-converged). Изначально продукт развивался вместе с виртуализацией Virtuozzo. Однако, если вам не нужна полноценная система виртуализации, теперь проект доступен и в виде отдельного распределенного хранилища, которое может работать с любыми клиентами.

Если говорить в общем, то VZ Storage использует диски в тех же самых серверах, которые обслуживают систему виртуализации. Таким образом, у вас пропадает необходимость закупать отдельное оборудование, например, дорогостоящий контроллер SAN/NAS, чтобы создать сетевую среду хранения. Одна из отличительных особенностей VZ Storage заключается в выборе способа хранения данных (схему избыточности) для разных категорий данных. Временные логи, например, можно вообще не резервировать, а для важных данных предусмотрены различные технологии защиты – репликация (полное дублирование) или самовосстанавливающиеся коды (Erasure Coding).

Железо

Так как VZ Storage является гиперконвергентной системой хранения, она может быть развернута с использованием любых серверов стандартной архитектуры x86. Впрочем, чтобы работа системы была эффективной, в каждом сервере должно быть установлено как минимум три жестких диска не менее 100 Гб емкостью каждый, двухъядерный процессор (одно ядро отдаем хранилищу), и 2Гб оперативной памяти. В более мощных конфигурациях мы рекомендуем ставить одно процессорное ядро и 4ГБ памяти на каждые 8 жестких дисков. То есть, используя на узле, например, 15 дисков для создания хранилища, для поддержки работы кластера хранения вам потребуется всего 2 ядра и 8ГБ RAM.

Поскольку мы говорим о распределенном хранилище, серверы должны быть объединены в сеть. Теоретически можно использовать ту же самую сеть передачи данных, на которой работает кластер виртуализации, но намного эффективнее иметь второй сетевой адаптер с пропускной способностью не менее 1Гб/c, ведь скорость чтения и записи данных будет напрямую зависеть от характеристик сети. Кроме этого отдельная сеть будет полезна и с точки зрения безопасности.

Архитектура

Распределенная архитектура VZ Storage подразумевает, что мы устанавливаем разные компоненты системы на физические или виртуальные серверы: панель управления с графическим интерфейсом, сервер хранения данных (Chunk Server – CS), сервер метаданных (MetaData Server – MDS), монтирование хранилища для чтения/записи данных (Client). Один узел может запускать несколько компонент в любом сочетании. То есть, один сервер, например, может одновременно хранить и данные, и метаданные, и запускать виртуальные машины, и предоставлять панель управления кластером.

image

Все данные в кластере разбиваются на блоки фиксированного размера («chunks» — чанки). Для каждого «чанка» создается несколько реплик (его копий), причем размещаются они на различных машинах (чтобы обеспечить отказоустойчивость в случае выхода из строя целой машины). При установке кластера вы задаете параметр нормального и минимального количества реплик. Если какая-то машина выходит из строя или перестает работать диск, силами кластера все утраченные реплики будут воспроизведены на оставшихся – вплоть до параметра нормального количества (обычно 3). В это время система по-прежнему позволяет писать и часть данных без задержек. Но, если же из-за сбоя количество копий упало ниже минимального значения (обычно 2), то есть произошел одновременных отказ двух компонент, кластер позволяет только читать данные, а для записи клиентам придётся подождать пока не будет восстановлено хотя бы минимальное количество копий. Система восстанавливает такие чанки, с которыми идёт работа, с наивысшим приоритетом.

Количество CS и MDS на каждом сервере определяется количеством физических дисков. VZ Storage привязывает один компонент к одному накопителю, создавая тем самым четкое разделение ресурсов и реплик между разным физическим оборудованием.

В чем плюсы?

Мы немного познакомились со структурой и требованиями VZ Storage, и теперь возникает вопрос, зачем все это нужно? Какие плюсы дает система? Самое главное преимущество VZ Storage – это надежность. Используя то же самое оборудование (возможно, добавив в него сетевые контроллеры и диски), вы получаете высокоэффективную легко-масштабируемую систему с отлаженным механизмом работы с данными, метаданными. VZ Storage позволяет обеспечить постоянное и надежное хранение данных, включая диски ВМ и данные контейнерных приложений для Docker, Kubernetes или Rancher.

Второй плюс – это низкая стоимость владения (TCO). Кроме того, что для работы решения не нужно приобретать отдельное дорогостоящее «железо» и вы можете выбирать опции резервирования для различных данных, в VZ Storage имеется возможность использования erasure coding (кодов избыточности, таких как Reed-Solomon). Это позволяет снизить требования к общей емкости, сохраняя возможность восстановления данных в случае сбоя. Метод подходит для хранения больших объемов данных, когда высочайшая скорость доступа – это далеко не самое главное.

Какие именно плюсы дает erasure coding (EC)? Erasure codding позволяет значительно сократить расход использования дискового пространства. Достигается это счёт специальной обработки данных.

image

При формуле избыточности M+N[/X], EC позволяет использовать намного меньше дискового пространства. Если M – это количество блоков данных, N – количество блоков специальных контрольных сумм («Parity»), а X – параметр допустимости записи (он характеризуется тем, сколько узлов системы хранения могут быть недоступны, когда клиент по-прежнему может записывать данные в свои файлы). Чтобы система работала, минимальное количество узлов в VZ Storage должно составлять 5 (в этом случае M=3,N=2, или “3+2”). На картинке изображен пример, где M=5, N=2 или “5+2”.

На примере инсталляции системы с конфигурацией 5 + 2 и включенным EC, мы можем гарантировать дополнительную нагрузку на емкость лишь в 40%, создавая только 2Гб резервных данных на каждые 5Гб данных приложений).

В этом случае для защищенного хранения 100 Тб данных вам потребуется всего 140 Тб емкости. Такой подход помогает оптимизировать бюджет или обеспечить хранение больших объемов данных в тех случаях, когда в кластер уже физически нельзя установить больше дисков, в стойку – больше серверов, в серверную – больше стоек. При этом мы сохраняем высокую доступность данных – даже при выходе из строя двух элементов системы хранения, оставшиеся узлы системы позволят восстановить все данные вплоть до бита, не останавливая работу приложения. В таблице приведены значения резервной емкости, и, как вы можете видеть, результаты использования erasure coding оказываются действительно впечатляющими, когда в кластере используется много машин. Например, в конфигурации 17+3 с erasure coding резервная емкость составляет всего 18%

image

Другое дело – производительность. Конечно, erasure coding повышает нагрузку на ЦП, но совершенно незначительно. За счёт SSE инструкций на современных процессорах одно ядро может обрабатывать до ~2GB/s данных.

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

Проголосовало 16 человек. Воздержалось 5 человек.

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

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

https://habrahabr.ru/post/334724/


Метки:  

Поиск сообщений в rss_rss_hh_new
Страницы: 1437 ... 1077 1076 [1075] 1074 1073 ..
.. 1 Календарь