...

суббота, 7 февраля 2015 г.

[Перевод] Эффект капельного преобразования в CSS

Недавно мы рассказывали про морфинг форм в SVG, когда одна форма преобразуется в другую. А теперь давайте взглянем как формы могут перетекать друг в друга. Этот липкий тянучий амебный эффект многим знаком из видео c каплями ртути на поверхности.

image




Я точно не уверен, кто первый открыл этот способ применения в вебе, но изначально я ориентировался на демо от Lucas Bebber:


CodePen


Затем я увидел демо от Felix Hornoiu (GIF низкого качество для большей производительности в вебе):


image


Идея довольная проста — применить свойство filter для элемента одновремено со значениями blur и contrast.



Blur, что очевидно, производит эффект размытия, в то время как contrast придает очертание пятну в центре. При правильном балансе в итоге получается «достаточно острая» форма.

image

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


image


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



.stage {
/* обязательно должно быть указано для работы contrast */
background: white;

/* странным образом помогает при соединении границ, скрывает переполнение */
padding: 30px;

-webkit-filter: contrast(20);
filter: contrast(20);
}
.dot {
border-radius: 50%;
width: 50px;
height: 50px;

/* также необходимо для корректной работы contrast */
background: black;

-webkit-filter: blur(15px);
filter: blur(15px);
}


Финальный результат вы получите после того как анимируете ваши «капли». Вот демо на CodePen, где можно поиграться со значениями.


Поддержка браузерами



Радует, что теперь это работает не только на WebKit/Blink! Firefox 35 полностью поддерживает фильтры без флажков и прочих нюансов. Бета Aurora уже v35 и я проверил, что там работает все отлично.

Таким образом демо работает в Chrome / Safari / Opera / Firefox / iOS / Android. Не плохо. Не поддерживается только IE.


Предсказания по комментариям




Это не для практического применения!!! Успокойтесь.

Лично я просто без ума от данного трюка. Да, аналогичная реализация со множеством элементов прилично нагружает CPU, но с двумя окружностями все работает отлично.


Я уверен, существуют более совершенные способы реализации данной идеи.


Recommended article: Chomsky: We Are All – Fill in the Blank.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


[Из песочницы] Альтернативный бейдж для страниц Facebook

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

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



Исходники + Демо




Установка





  1. Загружаем свежую версию библиотеки FBplus.badge с репозитория проекта на GitHub

  2. Подключаем файл стилей





  3. Добавляем код виджета на страницу












* пример установки виджета можно посмотреть здесь

Настройка




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






































Название

атрибута
Значение

по умолчанию
Краткое

описание
Дополнительные сведения
data-width240 pxширина виджетазначение должно быть в диапазоне 160 — 420 пикселей
data-href---адрес страницыдопускается использование как полного адреса страницы так и только ее названия
data-relpageтип страницына данный момент виджет актуален только для facebook page
data-themelightтема оформленияможет принимать значения «light» или «dark»
data-langenязык виджетадоступны следующие значения:


  • «en» — английский язык

  • «de» — немецкий язык

  • «fr» — французский язык

  • «it» — итальянский язык

  • «es» — испанский язык

  • «pt» — португальский язык

  • «ru» — русский язык

  • «ua» — украинский язык




Поддерживаемые браузеры




Google Chrome, Firefox, Safari, Opera, Internet Explorer 8+

Дополнительно




Примеры внешнего вида виджетов при выборе темной темы оформления

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


P. S. Буду благодарен за конструктивную критику


Recommended article: Chomsky: We Are All – Fill in the Blank.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


STM32 и FreeRTOS. 5. Приносим пользу и добро!

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

Раньше было про потоки, семафоры, очереди и HAL


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



Вооружившись осциллографом, я полез внутрь.



Через некоторое время поиски привели к двум проводкам, которые были в жгуте, соединявшем блоки устройства. Осциллограмма показала, что в проводках почти обычный USART. Почти — потому что «туда» данные бежали на скорости 9600, а обратно на 115200.


Достал два usb-usart переходника, прицепил их входы к RX/TX и начал анализировать протокол. Задача осложнялась разными скоростями, асинхронностью и бинарностью протокола. В общем, через некоторое время я обнаружил, что у меня банально разъезжаются глаза, пытаясь отследить в терминалах, что за чем идет и что на что реагирует.


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


Работа сниффера будет простая: у STM32 куча встроенных USART. Пусть 2 их них слушают свои RX ножки и потом через USB выдают их наружу. А мы эти ножки прицепим к RX/TX изучаемого прибора.


Для начала берем уже (надеюсь) привычную плату STM32F3DISCOVERY и с помощью STM32Cube создаем заготовку. В этой заготовке должно быть следующее


5 потоков.


defaultTask — будет мигать светодиодиком «устройство работает и не повисло»

Usart1Rx — будет заниматься приемом данных на 1м порту

Usart2Rx — то же самое, то на 2м

UsbSend — тут будут обрабатываться и посылаться данные наружу

Usart3Tx — а это будет тестовый поток, который будет рассылать цитаты знаменитых роботов. Используем для проверки работоспособности первых двух портов «на вход». Ну или для баловства.


И одну очередь — в которую будут складываться посылки от «приемщиков» данных. Дабы не заморачиваться, я сделал такую структуру



typedef struct {
uint8_t usart;
uint8_t byte;
} myMes;


Для начала напишем самую важную функцию — посылку тестовых данных.



for(;;)
{
// Wall-e: Eeeee... va?
uint8_t walle[]="Eeeee... va?\r\n";
// Short Circuit: Johny Five is Alive!
uint8_t johny[]="Johny Five is Alive! \r\n";
// StarWars
uint8_t c3po[]="Sir, the possibility of successfully navigating an asteroid field is approximately 3,720 to 1 \r\n";
HAL_UART_Transmit(&huart3,(uint8_t *)&walle,15,16); //PB10
HAL_UART_Transmit(&huart2,(uint8_t *)&johny,23,100); //PA2
HAL_UART_Transmit(&huart1,(uint8_t *)&c3po,97,100); //PC4
osDelay(1000);
HAL_GPIO_TogglePin(GPIOE, GPIO_PIN_15);
}


И проверим ее, просто поочередно зацепившись внешним usart-usb переходником за подходящие ножки. Это по крайней мере даст понимание того, чего ожидать на «приеме», если мы просто соединим ножки RX-TX прямо на плате.



Теперь перейдем к функции, которая принимает и оформляет полученное.



xQueueReceive( RecQHandle, &w, portMAX_DELAY );
if(oldusart!=w.usart || char_count>16)
{
oldusart=w.usart;
newline=1;
char_count=0;
}
buf[char_count++]=w.byte;




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

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


Теперь необходимо написать то, чем мы будем принимать данные.



void Usart1Rx(void const * argument)
{
/* USER CODE BEGIN Usart1Rx */
/* Infinite loop */
for(;;)
{
if(HAL_UART_Receive_IT(&huart1, &b1,1)==HAL_OK)
{
HAL_GPIO_TogglePin(GPIOE, GPIO_PIN_9);
}
osDelay(1);
}
/* USER CODE END Usart1Rx */
}




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

И наконец, обработчик прерывания от USART



void HAL_UART_RxCpltCallback(UART_HandleTypeDef *UartHandle)
{
myMes m;
HAL_GPIO_TogglePin(GPIOE, GPIO_PIN_14);
switch((uint32_t)UartHandle->Instance)
{
case (uint32_t)USART1:
HAL_GPIO_TogglePin(GPIOE, GPIO_PIN_10);
m.usart=1;
m.byte=b1;
xQueueSend( RecQHandle, &m, portMAX_DELAY );
// Do this need?
//HAL_UART_Receive_IT(&huart1, &b1,1);
break;
case (uint32_t)USART2:
HAL_GPIO_TogglePin(GPIOE, GPIO_PIN_12);
m.usart=2;
m.byte=b2;
xQueueSend( RecQHandle, &m, portMAX_DELAY );
HAL_UART_Receive_IT(&huart2, &b2,1);
break;
}
}


Обратите внимание на комментарий посредине и почему для второго порта она не закомментирована


Компилируем, собираем и глядим в терминал



Кажется, то что надо. Цепляем к 1му порту другой «источник данных» и просто копипастим строку в него.



Кстати, очень хороший вопрос для разбирательства «как работают прерывания» — почему строки от обоих портов не прерывают друг друга?


Но для подтверждения того, что не все так плохо, привожу другой скриншот, где я просто стучал по клавиатуре



Как видите, если «есть шо», то один порт может «перебить» другой.


И наконец, самая интересная фишка получившегося анализатора. Если в коде инициализации физического USART порта добавить следующие строки



huart1.Init.OneBitSampling = UART_ONEBIT_SAMPLING_DISABLED ;
huart1.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_AUTOBAUDRATE_INIT;
huart1.AdvancedInit.AutoBaudRateEnable = UART_ADVFEATURE_AUTOBAUDRATE_ENABLE;
huart1.AdvancedInit.AutoBaudRateMode = UART_ADVFEATURE_AUTOBAUDRATE_ONSTARTBIT;


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


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


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


PS На фотографии в заголовке макет прибора для лазерной хирургии, для которого мы в studiovsemoe.com писали прошивку. Он не имеет никакого отношения к тому самому прибору. Просто красивая картинка получилась.


Recommended article: Chomsky: We Are All – Fill in the Blank.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Официальный релиз первого телефона с Ubuntu Phone внутри

Дорогие друзья, хочется рассказать вам о том, что состоялся долгожданный и неоднократно откладываемый релиз Ubuntu Phone!

Вкратце о новинке




image

Первый телефон выпустила испанская компания BQ, он носит название Aquaris E4.5 Ubuntu Edition (вторая часть которого намекает, что телефон и ранее присутствовал на рынке и просто был адаптирован под UP). Сам по себе телефон имеет довольно скромные характеристики (которые можно увидеть под катом), однако и цена соответствующая — €169.90 (или примерно $190). Из этого несложно сделать вывод, что конкретно эта модель будет в первую очередь бороться за рынок бюджетных устройств (где доминирует Android и уже показывает неплохую конкуренцию Windows, например). Продажи начнутся в понедельник, 9 февраля.


Немного подробностей




Официальное видео:


Моя знакомая на G+ пишет:



it's quick and smooth, fantastic fealing using it





И немного фото от нее
image

image


Характеристики:



  1. Процессор 1.3GHz x 4

  2. Дисплей 4.5 дюйма (540 x 960)

  3. Внутренняя память 8Gb + слот для карты

  4. Оперативная память 1Gb

  5. Батарея 2150mAh

  6. Камера 8mp

  7. Две микро-сим




Немного ссылок:

http://ift.tt/1EN3try

http://ift.tt/1Ih5UWf

P.S. Обычно я не пишу такие статьи, но новости на главной не нашел.

P.S.S. Статья будет дополняться по ходу получения информации.

P.S.S.S. С хабами плохо получилась, принимаю советы по добавлению вариантов.


Recommended article: Chomsky: We Are All – Fill in the Blank.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Классификация знаний в области программирования

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

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


Но прежде, чем «запустить» материал, еще небольшое отступление. О том, почему вообще я все это писал. Дело в том, что у нас в странах бывшего СССР с образованием в области IT очень туго. С одной стороны нет программ обучения, которые подготовят специалистов на должном уровне (наверное, за очень редкими исключениями, которые можно отнести к погрешности). С другой стороны, из-за широких возможностей самообразования, программисты и не спешат учиться в ВУЗах — все стремятся начать практиковать как можно раньше. Часто изучается только одно направление (например PHP+Mysql — самое популярное) и в бой. Причем, на этом все заканчивается. В итоге у нас огромное количество программистов, которые и базовых вещей не знают. Отсюда вытекают проблемы с качеством кода, и с эффекивностью алгоритмов, с велосипедированием.


Но программирование — это полноценная область знаний, которая требует в том числе и инженерной подготовки. Точно так же, как строительство или телекоммуникации. Да, построить дом (особняк) можно своими руками и без образования. А поднять большинство сайтов можно прочитав пару книг по PHP и HTML. Но многоэтажку без специальной подготовки не построишь, как и Гугл не напишешь, не зная основ.


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


Поехали.


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


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


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


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


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


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


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


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


Первый уровень из CS (computer science) — Специальная база . Это стартовая площадка для любого программиста по четырем фронтам:



  1. арифметические основы ЭВМ (системы счисления и операции с числами, логические операции);

  2. физические основы ЭВМ (полупроводники, транзисторы, логические элементы, схемы, интегральные микросхемы);

  3. теория алгоритмов (алгоритмы и структуры данных; сложность, эффективность; способы представления информации в памяти);

  4. языки программирования (задача и понятие ЯП, уровни, типы языков, абстракция, уровни абстракции, трансляция/компиляция, шаблоны, принципы, парадигмы — обзор).


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


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



  1. архитектура ЭВМ (процессоры, микроархитектура, память, шины, ввод/вывод);

  2. обработка информации (теория информации, статистика, модели, поиск данных, лингвистические аспекты, обработка информации средствами табличных процессоров);

  3. основы C/C++ (базовые свойства языка, синтаксис, указатели, ввод/вывод, массивы, основы STL).


Следом за Основами идет Уровень 1 . Это первый прикладной уровень, и особо нетерпеливые могут начать коммерческую практику, овладев этим уровнем. Он включает 5 дисциплин:



  1. основы ASM (развитие архитектуры ЭВМ в направлении программирования, написание простейших драйверов и алгоритмов, ассемблерные вставки в C/C++);

  2. C/C++ (ООП, разработка прикладных приложений, библиотеки, WinAPI, make utils, параллельное программирование).

  3. операционные системы (архитектура ОС, процессы, межпроцессное взаимодействие, потоки, планирование, работы с памятью и переферией, POSIX-системы);

  4. системный анализ (предметная область, бизнес-процессы, потоки, диаграммы, принципы и теория системного анализа);

  5. базы данных (теория множеств, виды СУБД, реляционные СУБД, модели данных, SQL, конкретные БД).


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


Уровень 2 включает:



  1. разработку ПО (жизненный цикл ПО, этапы разработки, основы ведения программных проектов, инструменты);

  2. анализ данных (Data Mining, OLAP, машинное обучение, нейронные сети, ИИ);

  3. компьютерные сети (по уровням стеков TCP/IP и/или ISO/OSI “от и до”, протоколы, сетевое программирование на C/C++);

  4. языки программирования с управляемым кодом (управляемый код, виртуальные машины, сборщики мусора, юнит-тестирование, собственно практика на C# или Java);


Уровень 3 — последний уровень для среднего программиста. Он самый объемный и включает только те дисциплины, которые непосредственно связаны с разработкой ПО. Всего их получилось 6:



  1. разработка UI и юзабилити (принципы построения интерфейсов пользователя);

  2. управление командами и проектами (методологии разработки и другие вопросы управления);

  3. тестирование ПО (обзорно: виды тестирования, инструменты);

  4. веб-технологии (HTTP-протокол, веб-сервер, CGI, кэширование и проксирование, клиентское программирование);

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

  6. интерпретируемые языки программирования (особенности, основы по двум-трем языкам, практика по одному-двум языкам: JS, PHP, Python, Ruby).


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


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



  1. дает возможность понять, какие дисциплины нужны больше, какие меньше для работы в определенной специализации (просто выбрать основной предмет специализации и смотреть по связям и удаленности до других);

  2. дает понимание, как изучать компьютерные науки, если начинать не с фундаментальных основ, а с прикладных знаний (например, PHP) — можно двигаться по связям в стороны и вниз — собственно именно таким был мой личный путь развития (и я никак не могу назвать его самым легким, эффективным и оптимальным).


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



P.S. Убедительная просьба не развивать холивары на тему, что должен и что не должен знать программист. Это личный выбор каждого и статья совсем не об этом. Здесь приведена классификация знаний и взаимосви между ними. Это интересно не всем, это нужно не всем.


Recommended article: Chomsky: We Are All – Fill in the Blank.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Еще немного реверс-инжиниринга UEFI PEI-модулей на другом полезном примере

И снова здравствуйте, уважаемые хабрачитатели.

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

Если вас интересуют ответы и описание процесса их поиска — прошу под кат.


Краткая предыстория


Защита, о взломе которой пойдет речь в этом тексте, была введена HP около полутора лет назад, и (насколько мне известно) до сих пор считалась надежной. Пользователи ноутбуков HP с защищенным ей UEFI периодически наведывались на форум bios-mods.com в надежде на помощь в избавлении от белых списков оборудования или открытии скрытых настроек UEFI Setup, но с той же периодичностью получали ответ — защита стойкая и ничего не сделать. В начале лета 2014 года одному из администраторов bios-mods это надоело и он решил взять инициативу по взлому в свои руки. Процесс пошел, но крайне медленно, и результата публичного до сих пор не появилось, а он очень нужен ремонтникам, которые рады бы ставить на эти ноутбуки другие процессоры/видеокарты/модемы, но не могут, т.к. для их правильной работы нужна модификация DXE-драйверов, а после нее прошивка не стартует. В итоге мне эта ерунда надоела и я решил отломать защиту самостоятельно, благо, как выяснилось, ничего радикально сложнее предыдущей защиты HP придумать не смогли.

Ликбеза не будет


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

Что дано и что требуется найти


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

Конечная цель — прошивка должна работать после модификаций.

Поиски


Снова открываем прошивку в UEFITool и смотрим на панель Messages. Благодаря опыту, полученному в прошлой статье, утилита теперь умеет отображать нестандартные данные в дереве (т.е. не теперь не обязательно распаковывать весь DXE-том, что добраться до них) и сохраняет их при пересборке тома:


Как и в прошлый раз, подозрительные данные оказываются в самом конце DXE-тома, но теперь можно достать их непосредственно из дерева, что и делаем, получаем файл key.bin, который затем открываем в Hex-редакторе:


И снова перед глазами предстает неизвестный кусок данных размером 100h (похожий на RSA2048 public key), но теперь у него есть сигнатура — $HSS. Как я уже писал, данные такого рода могут быть найдены либо по сигнатуре, либо по смещению внутри тома, либо по абсолютному адресу (с учетом того, что последний байт микросхемы SPI-flash оказывается при старте по адресу FFFFFFFFh). Проверим сначала первый вариант, воспользовавшись поиском текста в UEFITool:


Находим 4 вхождения искомой строки, одно из которых мы уже посмотрели (то, которое внутри Non-UEFI data), нужно разобраться с остальными. Первое оказывается в DXE-драйвере по имени BiosImageInterface, но он сам находится в томе, который призван проверять, так что наличие там основной проверки весьма маловероятно. Если в других местах не найдем — надо будет к нему вернуться.

Последние же два вхождения указывают две копии одного и того же PEI-модуля, первая из которых находится в упакованной копии PEI-тома (она может использоваться для автоматического восстановления поврежденного PEI-тома), а другая — в «настоящем» PEI-томе. Вот и наш подозреваемый, все указывает на то, что целостность проверяет именно он, и нужно достать его содержимое в файл hss.bin для дальнейшего анализа.


В прошлый раз на этом месте мы загрузили полученный файл в IDA и начали анализировать его, но в данном случае так смогут сделать только обладатели IDA 6.7 и выше, т.к. именно в 6.7 появилась нативная поддержка формата Terse Executable, в котором и хранится наш PEI-модуль. Формат этот разработан авторами спецификации UEFI PI для экономии места в кэше процессора, по факту это PE32 с сильно обрезанным заголовком, от которого оставили только жизненно необходимые для правильной загрузки образа поля. Более того, большая часть производителей использует в фазе PEI крайне примитивный загрузчик исполняемых файлов, который не поддерживает relocation'ы, и потому его базовый адрес должен совпадать с физическим адресом. Все это замечательно, конечно, но нам нужен не непонятный TE, а понятный PE32, поэтому пришлось написать конвертер из TE в PE, который пытается восстановить заголовок PE-файла по тем данным, которые получилось найти в TE-файле. Утилита писалась за полчаса и под конкретный файл, так что за правильность конвертирования любого наперед заданного TE-образа поручиться не могу.

Вот теперь у нас есть файл pe.bin и можно открывать его в IDA и вести анализ. В этот раз пойдем немного другим путем и будем начинать не с точки входа, а с того места, где встречается сигнатура $HSS. Идем в Search -> Text... (или нажимаем Alt+T), вводим $HSS, ставим галку Find all occurences и… ничего не находим. Думаем немного и понимаем, что у нас LittleEndian-машина, и $HSS при загрузке в регистр будет выглядеть как SSH$ или 53534824h. Ищем этот вариант и вуаля, одно вхождение:


Переходим двойным щелчком на сообщении и попадаем вот сюда:


А вот и проверка на то, что по адресу из EBX лежит 53534824h, и если оно там действительно лежит — в переменную на стеке сохраняется EBX + 20h, т.е. как раз адрес первого байта ключа, а если не лежит — к EBX прибавляется 10h и проверяется снова. Видно также, что из другой ветки кода в ту же переменную может попасть значение FFF3DF00h, которое является физическим адресом первого байта ключа. Можно это проверить, для чего достаточно от 100000000h отнять FFF3DF00h и отступить полученные C2100h байт от конца файла — как и предполагалось, мы оказываемся точно на начале блока с ключом. Будет ли ключ найден по сигнатуре или абсолютному адресу — зависит от BootMode. Если текущий режим 20h, т.е. BOOT_IN_RECOVERY_MODE — ключ будет найден по абсолютному адресу, иначе — по сигнатуре.

Смотрим дальше:


А дальше происходит вызов функции из какого-то специфичного для HP PPI, которая и осуществляет проверку. Если эта функция вернула 0 (т.е. EFI_SUCCESS), то мы уходим с этого экрана вниз на return, если же проверка не удалась, все опять зависит от BootMode, в случае BOOT_IN_RECOVERY_MODE происходит вызов функции из другого PPI (которая, я подозреваю, постарается восстановить DXE-том из Recovery-образа). Затем уже независимо от BootMode вызывается его одна функция из второго PPI, после чего в стек кладутся 6 и 0CF9h и выполняется вызов коротенькой функции, в нашем случае выглядящей так:



mov al, 6
mov dx, 0CF9h
out dx, al




Если вдруг не узнали в гриме — это самый распространенный ныне способ hard reset'а через IO-порты. А если ресет вдруг не случился, случится бесконечный цикл, который сразу за ним.

Ну вот, с причинами ресета разобрались, теперь надо его обойти, причем так, чтобы вернуть EFI_SUCCESS в EAX из той функции, в которой это все происходит. На мой взгляд, самый простой способ достичь желаемого — поменять первый text eax, eax на xor eax, eax, в результате и в EAX появится 0, и JGE сработает в 100% случаев, а ресет станет мертвым кодом.

Тестирование и заключение


Сказано-сделано, меняем 85 C0 -> 31 C0, записываем вместо ключа нули, собираем прошивку (не забыв, что у нас две копии этого файла и заменить нужно обе) и отправляем нашим ремонтникам на тестирование. Через 5 минут приходит сообщение: «запускается и работает, большое спасибо». Вот теперь можно снова садиться и писать статью про крутые вендорские защиты, которые сначала держатся полтора года, а потом снимаются за полтора часа.

Спасибо за внимание, удачных вам прошивок и модификаций.
P.S. В качестве бонуса, фиговенькое фото запущенного ноутбука с замененным Boot Logo, хранящимся в DXE-томе. Показывает, что защита действительно снята.



Recommended article: Chomsky: We Are All – Fill in the Blank.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


[Перевод] Пуленепробиваемые тесты JavaScript

Писать тесты скорости JS не так легко, как кажется. Даже не касаясь вопросов кроссбраузерной совместимости, можно попасть во множество ловушек.

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



За кулисами jsPerf сначала использовал библиотеку на JSLitmus, которую я обозвал Benchmark.js. Со временем она обрастала новыми возможностями, и недавно Джон-Дэвид Дальтон переписал всё с нуля.


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


Шаблоны тестов




Есть несколько способов запустить тест части JS-кода для проверки на быстродействие. Самый распространённый вариант, шаблон А:

var totalTime,
start = new Date,
iterations = 6;
while (iterations--) {
// Здесь идёт фрагмент кода
}
// totalTime → количество миллисекунд, потребовавшихся на шестикратное выполнение кода
totalTime = new Date - start;


Тестируемый код размещается в цикле, который выполняется заданное количество раз (6). После этого дата старта вычитается из даты окончания. Такой шаблон используют тестировочные фреймворки SlickSpeed, Taskspeed, SunSpider и Kraken.


Проблемы



При постоянном повышении быстродействия устройств и браузеров, тесты, использующие фиксированное количество повторений, всё чаще выдают 0 ms как результат работы, что нам не нужно.
Шаблон B



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

var hz,
period,
startTime = new Date,
runs = 0;
do {
// Здесь идёт фрагмент кода
runs++;
totalTime = new Date - startTime;
} while (totalTime < 1000);

// преобразуем ms в секунды
totalTime /= 1000;

// period → сколько времени занимает одна операция
period = totalTime / runs;

// hz → количество операций в секунду
hz = 1 / period;

// или можно записать короче
// hz = (runs * 1000) / totalTime;


Выполняет код примерно секунду, т.е. пока totalTime не превысит 1000 ms.


Шаблон B используется в Dromaeo и V8 Benchmark Suite.


Проблемы



Из-за сборки мусора, оптимизаций движка и других фоновых процессов время выполнения одного и того же кода может меняться. Поэтому тест желательно запускать много раз и усреднять результаты. V8 Suite запускает тесты только один раз. Dromaeo – по пять раз, но иногда этого недостаточно. Например, уменьшить минимальное время выполнения теста с 1000 до 50 ms, чтобы больше времени оставалось на повторенные запуски.
Шаблон С



JSLitmus комбинирует два шаблона. Он использует шаблон А для прогона теста в цикле n раз, но циклы адаптируются и увеличивают n во время выполнения, пока не наберётся минимальное время выполнения теста – т.е. как в шаблоне В.
Проблемы



JSLitmus избегает проблем шаблона А, но от проблем шаблона В не уходит. Для калибровки выбираются 3 самых быстрых повторения теста, которые вычитаются из результатов остальных. К сожалению, «лучший из трёх» — статистически не лучший метод. Даже если прогнать тесты много раз и вычесть калибровочное среднее из среднего результата, увеличившаяся погрешность полученного результата съест всю калибровку.
Шаблон D



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

function test() {
x == y;
}

while (iterations--) {
test();
}

// …скомпилируется в →
var hz,
startTime = new Date;

x == y;
x == y;
x == y;
x == y;
x == y;
// …

hz = (runs * 1000) / (new Date - startTime);


Проблемы



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

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


Извлечение тела функции



В Benchmark.js используется другая технология. Можно сказать, что она включает лучшие стороны всех этих шаблонов. Мы не развёртываем циклы для экономии памяти. Чтоб уменьшить факторы, влияющие на точность, и разрешить тестам работать с локальными методами и переменными, мы извлекаем для каждого теста тело функции. К примеру:

var x = 1,
y = '1';

function test() {
x == y;
}

while (iterations--) {
test();
}

// …скомпилируется в →

var x = 1,
y = '1';
while (iterations--) {
x == y;
}


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


На что нужно обратить внимание




Не совсем верная работа таймера



В некоторых комбинациях ОС и браузера таймеры могут работать неверно по разным причинам. Например, при загрузке Windows XP время прерывания обычно составляет 10-15 мс. То есть, каждые 10 мс ОС получает прерывание от системного таймера. Некоторые старые браузеры (IE, Firefox 2) полагаются на таймер ОС, то есть, например, вызов Date().getTime() получает данные непосредственно от операционки. И если таймер обновляется только каждые 10-15 мс, это приводит к накоплению неточностей измерения.

Однако, это можно обойти. В JS можно получить минимальную единицу измерения времени. После этого нужно рассчитать время работы теста так, чтобы погрешность составляла не более 1%. Для получения погрешности нужно поделить эту минимальную единицу пополам. Например, мы используем IE6 на Windows XP и минимальная единица – 15 мс. Погрешность составляет 15 ms / 2 = 7.5 ms. Чтобы эта погрешность составляла не более 1% от времени измерения, поделим её на 0.01: 7.5 / 0.01 = 750 ms.


Другие таймеры



При запуске с параметром --enable-benchmarking flag, Chrome и Chromium дают доступ к методу chrome.Interval, который позволяет использовать таймер высокого разрешения вплоть до микросекунд. При работе над Benchmark.js Джон-Дэвид Дальтон встретил в Java наносекундный таймер, и сделал доступ к нему из JS через небольшой java-applet.

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


Firebug отключает JIT в Firefox



Запущенный аддон Firebug отключает встроенную компиляцию по системе just-in-time, поэтому все тесты выполняются в интерпретаторе. Они будут работать там гораздо медленнее, чем обычно. Не забывайте отключать Firebug перед тестами.

То же, хотя и в меньшей степени, касается Web Inspector и Opera’s Dragonfly. Закрывайте их перед запуском тестов, чтобы они не влияли на результаты.


Фичи и баги браузеров



Тесты, использующие циклы, подвержены различным багам браузеров – пример был продемонстрирован в IE9 с его функцией удаления «мёртвого кода». Баги в движке Mozilla TraceMonkey или кеширование результатов querySelectorAll в Opera 11 тоже могут помешать получению правильных результатов. Нужно иметь их в виду.
Статистическая значимость



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



Тестируйте скрипты на реальных разных версиях браузеров. Не полагайтесь, например, на режимы совместимости в IE. Также, IE вплоть до 8-й версии ограничивал работу скрипта 5 миллионами инструкций. Если ваша система быстрая, то скрипт может выполнить их и за полсекунды. В этом случае вы получите сообщение “Script Warning” в браузере. Тогда придётся подредактировать количество разрешённых операций в реестре. Или воспользоваться программкой, исправляющей это ограничение. К счастью, в IE9 его уже убрали

Заключение


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


Recommended article: Chomsky: We Are All – Fill in the Blank.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


[Из песочницы] Flickr API в Android App. Авторизация

Восстановление часов «Электроника 7»

image

На днях один знакомый принес мне часы на вакуумно-люминесцентных лапах ИВ-26 «Электроника 7-06М», а точнее то, что от них осталось. Это достаточно редкая модель часов является уменьшенной копией часов «Электроника 7-06К». Как не странно, но все сегменты исправно работали, но вот платы с логикой не было.




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





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

image

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

image

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

image

Далее, порывшись в оскудевших после переезда закромах, было найдено:

Резисторы на 10кОм и 2.2кОм, зарядка от «нокии», россыпь транзисторов «2т602а» и пять штук «КТ315А». Не густо, но хватит.

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

image

По базе ограничиваем ток резисторами на 10кОм.

Потом делаем управление включением сборок, использовав «КТ315А», через резисторы на 2.2кОма подключаем их на землю, через эти же 2.2кОма подключаем выводы с анодов, ток базы ограничиваем опять же 10кОмами. Супер-клей спасет планету, я в этом уверен.

image

В результате, пока на базе 0 — сборка горит, подали +5 — сборка потухла. Просто, как огурец.

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


Для управления всем этим великолепием была взята давно не используемая копия arduino leonardo с выжженным высоким «portc» и какими то странными глюками, заключающимися в том, что иногда без принудительного ребута ее прошить не возможно. Раньше использовалась для быстрой проверки всякого-разного, а так как внимательности мне никогда не хватало, частично умерла смертью храбрых, при не совсем выясненных обстоятельствах, работая в качестве прерывателя для DRSSTC. Досталась она мне в свое время «за бесплатно», поклонником этой платформы, а тем более этой платы (пламенный привет разработчикам за очень удобный маппинг портов например) не был, то «умер Трофим — да и черт с ним!».

Но для этой цели живых портов вполне хватит, а так как дешифратора не нашлось, то используем для знакогенерации целиком portD, который, хоть в разнобой, но все-же присутствует почти целиком на колодке, за исключением пина «5». Для включения-выключения сборок сегментов используем выводы «A0-A3» на плате. «А4» у нас будет получать показания с термопары. Также для четырех кнопок используем выводы «7-10» на плате: 9 и 8 — установка часов и минут, 7 — остановка хода часов, 10 — переключение показа температуры\часов.

image

Спустя пару часов была накидана прошивка и оно заработало! Осталось только откалибровать более-менее точность хода. Для этого был подцеплен частотомер и подобрано значение микросекунд контроллера, при котором оно соответствует 2 миллисекундам реальным.

image

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

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

В качестве источника питания для ардуины выступила старая зарядка от «нокии».

image


Готовое устройство умеет отображать время:

image


И температуру:

image

Из минусов — примерно в половину упавшая, по сравнению с заводским изделием, яркость (что логично — в оригинале используется статическая индикация, а не динамическая).


Оригинальные схемы «Электроника 7-06М» — http://ift.tt/1xCOwQf

Код прошивки для Леонардо — http://ift.tt/1ul8y6Z (для обработки данных с термопары был использован код товарища hookenful, за что ему огромное спасибо).


Recommended article: Chomsky: We Are All – Fill in the Blank.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Приключения на FOSDEM 2015

Странно, что в русскоязычных СМИ об этом никто не пишет, но несколько дней назад в Брюсселе с успехом прошло крупнейшее европейское мероприятие FOSDEM 2015.

Я уже посещал его раньше (в 2007 выступал с докладом про ReactOS, в 2009 — стенд ReactOS).

И, по сравнению с тем, что было раньше — популярность FOSDEM'а растёт из года в год.

Согласно официальной статистике в 2014 году к сети FOSDEM подключалось 8 тыс. уникальных MAC-адресов, а в 2015 — около 15 тыс!


Можете выбрать свой коэффициент устройств на человека, как вариант:

1.5 устройства на человека: 10 тыс. человек.

0.8 устройств на человека: 18 тыс. человек.


И это действительно ощущалось.






Например, садясь в трамвай (да, я иногда пользуюсь общественным транспортом! :-)) в центре Брюсселя (а это далеко от места проведения — университета ULB), в каждом вагоне и в субботу и воскресенье можно было встретить по нескольку человек, едущих на FOSDEM. Уже не говоря о том, что все отели, хостелы, кровать&завтраки, ночлежки были полностью раскуплены.


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



Само мероприятие достаточно уникальное в своём роде:



  • Бесплатное участие для всех (а докладчикам даже компенсируют стоимость проживания и путешествия)

  • Для посетителей не требуется никакой регистрации

  • Университет ULB бесплатно предоставляет FOSDEM'у большинство своих площадей

  • 551 различных событий (доклады, сертификации и пр.)

  • Организована прямая трансляция всех докладов


И в тоже время:



  • Волонтёры всюду, помогают, дружелюбны

  • Чистота в помещениях

  • Ни одного инцидента — всё мирно, никаких криков «Долой Поттеринга!» или «Ненужно!»

  • Бесплатные автобусы, чтобы помочь тысячам людей спокойно разъехаться по домам

  • IPv6-only WiFi :-)


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



Выставка




Нашими соседями в этом здании стали:

Coreboot




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

CoreOS




Относительно новый проект, располагался по правую сторону от нас. Является форком ChromeOS, каждое приложение запускается внутри Докер-подобного контейнера. Думаю, что наиболее популярна и известна она благодаря разработанному в ней распределённому хранилищу конфигураций etcd.

В воскресенье их стол пустовал, а посетители спрашивали меня, знаю ли я, что с ними случилось. Получая отрицательный ответ некоторые говорили «likely a hangover from saturday night».

Ultimaker




Куда сейчас без 3D-принтеров?! Ребята печатали без перерыва на протяжении всех двух дней. Мы договорились, чтобы они распечатали наш логотип ReactOS, но к сожалению, мы не смогли так быстро нарисовать трёхмерную модель. А было бы здорово!

PostgreSQL




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

Наш стенд




Последний раз мы участвовали с ReactOS на этом мероприятии пять лет назад, и вот — мы снова там!

Из нашей команды приехали:



  • Giannis «smiley» Adamopoulos (Янис)

  • Aleksey «Fireball» Bragin (я)

  • Colin Finck (Колин)

  • Pierre «HeisSpiter» Schweitzer (Пьер)


Первым на место событий около 11 часов субботнего утра пришёл Колин и обнаружил отсутствие столика «ReactOS». Поискал слева, поискал справа и сел в сугроб выяснил, что наши коллеги из проекта Coreboot за соседним столом решили невзначай занять чуть больше места :-) Ребята из Coreboot быстро восстановили справедливость и как раз в этот момент пришёл я, принёс всякую атрибутику, заранее сделанную в Москве — баннер и флаги.


Развесив и расставив всё это — ноутбуки, листовки, флаги, баннер, наш стенд готов к приёму посетителей! А мы готовы рассказать на какой версии ядра Linux основан ReactOS о наших успехах.



Янис и Пьер подошли попозже, в течение дня, и мы уже вчетвером общались с посетителями. На селфи слева-на-право: я, Янис, Колин.



Наш баннер было хорошо видно как изнутри (он подсвечивался светом с улицы)…



Так и снаружи здания:



Сотня компакт-дисков, заботливо изготовленная Hermès Bélusca-Maito и Colin Finck, разошлась ещё до того, как стемнело на улице в первый день FOSDEM'а. Это было совершенно неожиданно, из опыта предыдущих выставок и конференций, да и вообще того факта, что компакт-диски уже выходят из обращения.


Видимо, работающий Microsoft Excel в ReactOS слишком сильно привлекал внимание:



Но, ReactOS не был бы ReactOS'ом, если бы мы не смогли придумать выход из ситуации! Этим же вечером Колин с Пьером пошли в центр Брюсселя в поисках магазина, работающего в выходной день и продающего болванки и наклейки на них. И ведь нашли! Купив ещё 100 болванок, мы использовали все пишущие приводы ноутбуков, которые были у нас в распоряжении (Пьер и Колин частично записывали ночью, и весь день в воскресенье уже вместе со мной). А персонал FOSDEM нам очень помог, дав нам принтер, на котором мы смогли распечатать наклейки на диски. Так что, в итоге, мы раздали чуть менее 200 дисков.


Пьер приклеивает наклейку на свежезаписанный LiveCD…



… кладёт его в конвертик, тем временем Янис записывает следующий диск, а Колин с немецкой пунктуальностью отвечает на вопросы посетителей:



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


Собрались как-то русский, немец, француз, португалец и сингапурец...




В субботу вечером мы запланировали встречу с товарищем Nuno Brito, который любезно заказал нам столик в прекрасной таверне на Grand Place. Там же я познакомился с Harish Pillay (Global Head of Arch and Leadership at RedHat). В очередной раз убедился — национальность, предпочтения Linux/BSD/ReactOS не влияют на дружескую атмосферу. Хотя на тему национального колорита мы много говорили — о стереотипах восприятия разных наций, о языках, жизни в разных странах, и прочих интересных вещах.


Ещё в пятницу был Friday Beer Event, но с него репортажи делать как-то не принято :-)



С удовольствием отвечу на ваши вопросы!


Recommended article: Chomsky: We Are All – Fill in the Blank.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


[Из песочницы] Unreal Engine 4 для развития своих способностей

Доброго времени суток, Хабр!

В этой статье я бы хотел поговорить с вами о недавно вышедшем Unreal Engine 4, который на данный момент набирает все большую популярность среди разработчиков игр. И хотя статья о UE4, однако она совсем не про игростой, хоть и связана с ним.



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


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

Итак, приступим.



О себе




Меня зовут Александр и мне сейчас 20 полных годиков. Вся жизнь ещё впереди и самое время определиться со своим будущим. Года три назад я начал увлекаться 3х-мерным моделированием и к сегодняшнему дню, на мой взгляд, добился хороших результатов. Ещё с детства я любил играть во всякие компьютерные игры и, как и многие, мечтал сделать что-то подобное. Поэтому моя специальность направлена в основном на real-time моделирование.

Однако для создания полноценных игр мне этого не хватало, так как я не знал языков программирования, хотя мат. мышление было на хорошем уровне. Я пытался познать PHP, C++, Lua, RubyOnRails, JS. Но максимум, на что меня хватило, это Jquery, да и тот через неделю после курса умудрился забыть. Все это довольно таки разочаровывало, но я не сдавался, продолжая тем временем совершенствовать свои способности в 3х-мерной графике.


Меньше года назад вышел UE4 и я, как поклонник Unreal Tournament и самого Unreal Engine, очень обрадовался. Побежал учить. Тут я бы хотел проводить вас к следующим пунктам, которые расскажут, что может дать UE4, помимо самих игр.


Программирование и логика




Как некоторые знают, в движке можно писать игровую логику на С++, а так же с помощью визуальной системы программирования — Blueprint. Для тех, кто не знает, выглядит она так:



Алгоритм сортировки (методом вставки) по цене предметов в инвентаре


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


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


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


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


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


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


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


Давайте взглянем на другой пример — Материалы:



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


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


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


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


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



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


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


Дизайн и творчество




Вам когда-нибудь хотелось построить свой дом, походить в нем? Снять свой фильм? Или просто создать красивую или мрачную сцену что бы выплеснуть накопившиеся эмоции? Если да, то Unreal Engine 4 вам тоже сможет чем-то помочь.

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



А так же в сфере визуализации архитектуры:



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


Сам же Unreal Engine 4 предоставляет некоторый набор, благодаря которому можно создать что-то свое, не прибегая к стороннему софту (не считая текстур). Не хочу вдаваться в подробности, которые вы сами сможете изучить, если заинтересуетесь, однако упомянуть все же стоит.


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


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


Для тех, кто знаком с 3х-мерным моделированием, в UE4 будет ещё больше возможностей. Простота в импортировании (через формат FBX), простота установки, наложение материалов, да и их создание тоже не такое сложное, если разобраться, работа со светом, запекание и многое другое.


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


image

Работа пользователя The_Distiller с официального форума


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


Конечно, тут можно придумать ещё множество преимуществ. Например, визуализация архитектуры в реальном времени на примере видео, что было выше. Снятие красивых 3д роликов без многочасового рендера. Даже есть поддержка VR очков, благодаря чему можно сделать виртуальный тур. А представьте, если этот тур будет по той реалистичной квартире? Словом, для творческих людей тут тоже найдется местечко.


Подводим итоги




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

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


Сам я изучаю UE4 не больше 7-ми месяцев и преуспел во многих сферах внутри редактора, даже открыл свое сообщество. Однако ещё много чего не изучено, поэтому в будущем от меня могут быть дополнительные статьи. Если и эта статья вам понравится, конечно.


Recommended article: Chomsky: We Are All – Fill in the Blank.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.