Астронавт Скотт Келли провёл семь месяцев из запланированных двенадцати на Международной космической станции. Издание The Verge предполагает, что изоляция уже повлияла на психику астронавта: он надел маску и начал охотиться за членами экипажа. Так Скотт празднует Хэллоуин.

#HappyHalloween from @space_station! Have a great weekend, and be safe down there. #YearInSpace https://t.co/aRGMsRAF1D

— Scott Kelly (@StationCDRKelly) 30 октября 2015

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

В 2013 году итальянский космонавт Лука Пармитано нарядился в Супермена на Хэллоуин.

ссылка на оригинал статьи http://geektimes.ru/post/265052/

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

Теория информации.

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

Квантовая теория информации.

Квантовая теория информации развивалась примерно схожим образом. В 1995 году Бен Шумахер доказал аналог теоремы Шеннона о кодировании в отсутствии шума, по ходу дела определив квантовый бит (кубит) как реальный физический ресурс. Но, стоит отметить, что до сих пор нет аналога теоремы Шеннона о кодировании для канала с шумом применительно к квантовой информатике. Несмотря на это, была разработана теория исправления квантовых ошибок, позволяющая квантовых компьютерам эффективно проводить вычисления при наличии шума, а так же надежно передавать информацию.
Классические идеи исправления ошибок оказались очень важными и полезными при разработке и понимании кодов, позволяющих исправить квантовые. В 1996 году работавшие назависимо Роберт Калдербанк с Питером Шором и Эндрю Стин открыли важный класс квантовых кодов, называемых сейчас CSS-кодами по первым буквам их фамилий. Позднее данные коды были отнесены к категории симлпектических, или стабилизирующих, кодов. Данные открытия опирались в значительной степени на идеи классической теории линейного кодирования, что значительно способствовало быстрому пониманию кодов исправления квантовых ошибок и их дальнейшему использованию в области квантовых вычислений и квантовой информации.
Данная теория была разработана с целью защиты квантовых состояний от шума, но что насчёт передачи классической информации по квантовому каналу? Эффективно ли это вообще, а если да, то насколько? И вот тут-то и ждало несколько сюрпризов. В 1992 году Чарльз Беннет и Стив Уиснер объяснили миру, как передать два классических бита информации путем передачи только одного кубита. Это было названо сверхплотным кодированием.
Ещё больше вопросов и, соответственно, больший интерес вызывают результаты в области распределенных квантовых вычислений. Представьте, что у вас есть два компьютера, соединенных в сеть, на которых решается некоторая задача. Сколько передач по сети потребуется для её решения? Ответ на этот вопрос не столь важен, важно другое. Не так давно было показано, что для подобной квантовой системы может потребоваться экспоненциально меньшее количество времени для решения задачи, чем для классических сетевых компьютеров. Это определенно является очень значимым результатом, но тут есть один минус — к сожалению, эти задачи не представляют особого интереса в реальных условиях.

Сетевая квантовая теория информации.

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

Заключение.

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

ссылка на оригинал статьи http://geektimes.ru/post/265050/

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

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

Вводные

Основное приложение — нативное (не основанное на html), состоящее из ~ 20 экранов, на двух платформах: iOS, Android. Брендированное приложение делается для сетей кинотеатров уже существующих в основном приложении, по сути «фильтруя» основное приложение до размера конкретной сети кинотеатров.
Брендированная версия должна отличаться от основного приложения следующим:

• Иметь фирменный стиль кинотеатра
• Удовлетворять одному из 3х возможных типов:
  — для одного кинотеатра
  — для сети одноименных кинотеатров
  — для сети из кинотеатров с разным фирменным стилем
• Поддерживать кастомный функционал.

Оптимизация стоимости брендирования

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

Мы постарались заоптимизировать все:

1. Дизайн
2. Разработку
3. Менеджмент
4. Поддержку

1. Дизайн: в два клика, пожалуйста!

1.1 Макеты

Фирменный дизайн приложения варьируется:

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

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

1.2 Нарезка

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

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

2. Разработка и поддержка

2.1 Код

На обоих платформах оптимальная организация кода виделась в общем модуле кода с вынесением параметров брендированных версий в отдельный конфигуратор. В iOS используемая архитектура Viper позволила производить брендирование приложения простой заменой модулей отображения и сервисов.
Также были заложены основы модульной структуры для будущего «конструктора» возможных кастомных фич конкретного кинотеатра (в виде произвольного элемента в таббаре).

2.2 Использование автоматизированных средств разработки

Юнит тесты

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

Билд сервер

Поскольку версий приложения становилось все больше, мы настроили build server, который при изменении кода в ядре проекта автоматически пересобирал билды всех брендированных версий, и выкладывал их в удобном виде для тестирования (Fabric рулит!). Тем самым сокращалось время на подготовку к тестированию и публикации.

3. Менеджмент

С третьей брендированной версии встал вопрос об их учете и контроле в удобной форме. Не мудрствуя лукаво, был выбран Google Sheet с таблицей с технической и управленческой информацией по ключевым вехам проекта.

4. Как мы улучшали взаимодействие с кинотеатрами

4.1 Инструкция кинотеатрам по получению собственного приложения

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

4.2 Корректировка ожиданий

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

• дизайна (только логотип и цветовая гамма)
• кастомного функционала (только webview)
• изменения приложения
• обновления приложения в сторах

Кастомный функционал

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

Развитие приложения и его обновления в App Store

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

4.3 Узкое место — аккаунты для публикации

После создания уже 1го приложения выяснилось, что узким местом в цепочке является предоставление кинотеатрами собственных аккаунтов для публикации в App Store и Google Play. Изначально планировалось, что приложение будет публиковаться в собственном аккаунте кинотеатра, что собственно было конкурентным преимуществом приложения.
Однако, на практике кинотеатрам оказалось крайне трудно согласовать настройку и оплату аккаунтов Android (25$ разово), не говоря уже об App Store (99$ ежегодно).

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

Результаты

Все описанные улучшения по созданию технологии брендирования дали свои плоды. С начальных 15 дней на первую версию затраты снизились, начиная с 4й брендированной версии, до ~ 4 часов на разработку кода новой версии для iOS и до ~ 6 часов для Android (на графике округлено до 1 дня разработки).

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

ссылка на оригинал статьи http://megamozg.ru/post/20808/

Дата презентации неоднократно сдвигалась, и в середине года SmartWatch4 «обещали» показать на IFA, затем слухи «перенесли» презентацию на ноябрь, а теперь говорят о том, что новые часы «Сони» выйдут в начале 2016. Они будут чуть более вытянуты, чуть лучше защищены от пыли и влаги, а также их «обременят» несколькими новыми датчиками. Прогнозы — внутри.

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

Есть основания полагать, что модель будет работать на базе Qualcomm Snapdragon 400, 1.2GHz, в них будет 512MB оперативной памяти, а к основным датчикам предыдущей модели добавятся высотомер и оптический пульсометр:

• Датчики внешней освещенности
• Акселерометр
• Компас
• Гироскоп
• GPS
• + Пульс
• + Высотомер

Модель частично наследует дизайн Sony SmartWatch3, однако станет тоньше и чуть более вытянута, сохранив старый аккумулятор на 420 mAh. В предыдущей модели его хватало до 2-х дней работы. Учитывая, что планируется возможность добавить поддержку 4G, время автономной работы может существенно сократиться.

Диапазон стоимости, который прогнозируют на данную модель от 300 до 350 долларов, или более 20 000 + рублей по текущему курсу, что практически вдвое превышает стоимость на модель SmartWatch3, которая в официальном магазине стоит сегодня 11 900 рублей.

Также модель оказывается дороже актуальных моделей от LG: Urbane — 18 990 рублей и Moto 360 — $299,99. При этом в контексте грядущей новинки Sony эти модели часто называются как эталонные, и критики утверждают, что время прямоугольных и квадратных моделей часов — прошло, приводя в пример также и Huawei.

Также напомню, что кроме третьей модели часов, которая аналогично работала на Android Wear, компания в 2013 году выпустила версию SmartWatch 2, которая работала в паре с Android устройствами и позволяла управлять функциями смартфона в радиусе Bluetooth, а также принимать и отвечать на уведомления. На CES-2012 были представлены первые Sony SmartWatch.

При этом известно, что Sony на март 2016 год запланировала старт продаж модели Wena — смарт-часов с аналоговым циферблатом.

ссылка на оригинал статьи http://geektimes.ru/post/265046/

Представьте: есть селект, который возвращает записи, каждую из которых нужно обработать, и то ли много записей, то ли обработка каждой записи занимает много времени, а процесс обработки одной записи не зависит от процессов других записей.
Классический пример для того, чтобы задействовать многопоточность или в случае баз данных выполнять обработку в нескольких сессиях. В Оракле для этого используется hint /*+ parallel() */ и pipelined functions. Это здорово, но если у вас Oracle standard edition(где parallel не работает) или вы хотите обработать не каждую запись по отдельности(из соображений, что лучше накопить работу, а потом в bulk, одним ударом, выполнить), а поделить весь вывод селекта на куски и каждый обработать отдельно?
Задача ставится так:
Написать Java stored procedure, которая получает следующие параметры:

• Текст селекта
• Имя процедуры, которая будет работать с порцией данных
• Колличество потоков(Thread)
• Данные, необходимые для подключения к базе

Сначала посмотрим, что можно сделать с pipelined функцией.

Java откроет по тексту селекта result set в default connection.
Первым делом надо выполнить
select count(*) from («Текст селекта»);
Создадим connection pool с размерностью, заданной в 3-м параметре.
Создадим отдельные сессии, присоединившись через jdbc connection.
Данные для этого возьмем из 4-го параметра, нам, по большому счету нужен только пароль, все остальное получим сами(может еще порт, если он отличен от 1521).
Будем получать данные из селекта в default connection и переписывать их в сессию из пула. Как только решим, что накопили достаточно, создадим thread, передадим ему эту connection как параметр и пусть работает, а мы продолжим со следующей сессией или, если все уже прочитано, подождем окончания всех потоков.
Напишем функцию обработки. Она получает все поля селекта как параметры.
Будет удобно, чтобы, например, первые два параметра были бы номер в порции и ее размерность. Это даст возможность в dbms info выводить процент выполнения в потоке.
По метадате селекта будем конструировать ее вызов в виде примерно так:
begin proc1(23,14000,’a1′,3,’tratata’,35,48); end;
Хранить будем только такую строку.
Вначале это был 2-х мерный массив (i,j), где i — это номер потока(в дальнейшем…). Потом я увидел, что при большом числе записей, затраты Oracle на поддержку большого массива становятся чрезмерными и решил пользоваться также временной таблицей(temporary table).
Я положил границу в 200,000 записей. Если селект count(*) возвращает меньше 200,000 Java в-runtime использует 2-х мерный String массив, если больше — пишет во временную таблицу с одним полем varchar2(4000).

Итак, в PL/SQL пакете создаем функцию
FUNCTION run_pipe_parallel(pi_Select_Txt VARCHAR2, pi_Proc_Name VARCHAR2, pi_Parallel_Count VARCHAR2, Pi_Password VARCHAR2) RETURN VARCHAR2 AS LANGUAGE JAVA NAME 'com.samtrest.ParallelRunner.run_parallel(java.lang.String, java.lang.String,java.lang.String, java.lang.String) return java.lang.String';
На стороне Java есть функция

  public static String run_parallel(String selectTxt,        String procedureName,        String threadCount,       String password) throws NumberFormatException, SQLException, ClassNotFoundException {     String rc = "OK";     ParallelRunner parallelRunner = new  ParallelRunner(selectTxt,procedureName,Integer.parseInt(threadCount),password);      try {       parallelRunner.runProc();     } catch (SQLException e) {       e.printStackTrace();       rc = e.getMessage();     } catch (ClassNotFoundException e) {       e.printStackTrace();       rc = e.getMessage();     }        return rc;   } 

Получение массива типов данных полей селекта

    res = stm.executeQuery();     ResultSetMetaData meta = res.getMetaData();     columnCount = meta.getColumnCount();     int [] types = new int[columnCount];     for (int k = 0; k < columnCount; k++) {       types[k] = meta.getColumnType(k+1);          }  

Так строим строку вызова:

    while (res.next()){       callStr =  "begin "+procedureName+"("+processSeq+","+(j+1)+","+chunkCount;       for (int k = 0; k < columnCount; k++) {         callStr = callStr+",";         String value = "";         if ( types[k] == java.sql.Types.VARCHAR || types[k] == 1){           value = res.getString(k+1);           if (value == null){             value = "null";           }else{             value = "'"+value+"'";           }         }else if (types[k] == java.sql.Types.NUMERIC){           BigDecimal number  = res.getBigDecimal(k+1);           if (number == null){             value = "null";           }else{             value = number.toString();           }         }else if (types[k] == java.sql.Types.DATE || types[k] == java.sql.Types.TIMESTAMP){           Timestamp date  = res.getTimestamp(k+1);           if (date == null){             value = "null";           }else{             value = "to_date('"+date.toString().substring(0,date.toString().indexOf('.'))+ "','yyyy-mm-dd hh24:mi:ss')";           }         }else{           System.out.println(""+types[k]);         }         callStr = callStr + value;       }        callStr = callStr + "); end;";  

Накапливаем в массиве или таблице

      if (rowCount > CHUNK_LIMIT){         insert.setString(1, callStr);         insert.executeUpdate();       }else{         chunks[i][j] = callStr;       } 

ссылка на оригинал статьи http://habrahabr.ru/post/269693/