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

Сейчас некоторые компании стараются создать нечто качественно новое. Так, широко известна система Leap Motion, у которой, говорят, есть немало недостатков, несмотря на все достоинства. Здесь управление производится при помощи жестов. Сейчас появилась и другая система — Eye Tribe Tracker. Здесь управление производится при помощи взгляда, без необходимости совершать какие-либо телодвижения.

Писать многопоточные приложения нелегко. Некоторые средства статического анализа кода позволяют помочь разработчикам, давая возможность чётко определить политики поведения потоков и обеспечить автоматическую проверку выполнения этих политик. Благодаря этому появляется возможность отлавливать состояния гонки потоков или их взаимной блокировки. Эта статья описывает инструмент анализа потокобезопасности С++ кода, встроенный в компилятор Clang. Его можно включить с помощью опции командной строки −Wthread−safety. Данный подход широко распространён в компании Google — полученные от его применения преимущества привели к повсеместному добровольному использованию данной технологии различными командами. Вопреки популярному мнению, необходимость в дополнительных аннотациях кода не стала бременем, а наоборот, дала свои плоды выражающиеся в упрощении поддержки и развития кода.

Предисловие

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

Средства статического анализа кода помогают разработчикам определить политики потокобезопасности и проверять их при сборке проекта. Примером таких политик могут быть утверждения «мьютекс mu всегда должен использоваться при доступе к переменной accountBalance» или «метод draw() должен вызываться только из GUI-потока». Формальное определение политик даёт два основных преимущества:

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

Данная статья рассказывает о применении данного подхода в Clang, хотя изначально он был разработан для GCC, однако версия для GCC более не поддерживается. В Clang данная возможность реализована как предупреждение компилятора. В Google на данный момент вся кодовая база C++ компилируется с включенным по умолчанию анализом потокобезопасности.

Несколько вещей гарантированно будут увеличиваться со временем: расстояния между звёздами, энтропия вселенной и бизнес-требования к ПО. Многие статьи пишут «Не усложняйте!», но не пишут почему или как это сделать. Вот вам 10 ясных примеров.

1. Инженерам виднее

Мы, инженеры, считаем себя умнейшими людьми. Ну, поскольку мы создаём разные штуки. И эта ошибка часто приводит к оверинжинирингу. Если вы спланировали и построили 100 модулей — Бизнес всегда попросит у вас 101-ый, о котором вы никогда не задумывались. Если вы соберётесь с силами и решите 1000 проблем — они придут к вам и выложат на стол 10 000 новых. Вы считаете, что у вас всё под контролем, а на самом деле вы даже не представляете, в каком направлении вас завтра поведёт дорога.



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

Мораль: Казино (бизнес) всегда побеждает.

Компания планирует увеличить комфортность ВР и снизить нагрузку на вычислительные мощности при помощи имитации периферического зрения

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

Изначально, компании-производители ВР-шлемов гнались за четкостью изображения на экранах, скоростью обновления кадра и общим качеством картинки. Сейчас, когда продукция HTC, Oculus и Sony выходит на широкий рынок, пришло время задуматься об оптимизации, ведь не все могут позволить себе стационарный ПК стоимостью 1500-2500$ ради того, чтобы попробовать новый продукт. И это еще без стоимости самой гарнитуры.

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

Господа! Я рад сообщить, что наконец-то все желающие могут загрузить бесплатный учебник на более чем 1600 страниц, над переводом которого работало более полусотни человек из ведущих университетов, институтов и компаний России, Украины, США и Великобритании. Это был реально народный проект и пример международной кооперации.

Учебник Дэвида Харриса и Сары Харрис «Цифровая схемотехника и архитектура компьютера», второе издание, 2012, сводит вместе миры программного обеспечения и аппаратуры, являясь одновременно введением и в разработку микросхем, и в низкоуровневое программирование для студентов младших курсов. Этот учебник превосходит более ранний вводный учебник «Архитектура компьютера и проектирование компьютерных систем» от Дэвида Паттерсона и Джона Хеннесси, причем соавтор предыдущего учебника Дэвид Паттерсон сам рекомендовал учебник от Харрисов как более продвинутый. Следуя новому учебнику, студенты строят реализацию подмножества архитектуры MIPS, используя платы с ПЛИС / FPGA, после чего сравнивают эту реализацию с индустриальными микроконтроллерами Microchip PIC32. Таким образом вводится вместе схемотехника, языки описания аппаратуры Verilog и VHDL, архитектура компьютера, микроархитектура (организация процессорного конвейера) и программирование на ассемблере — в общем все, что находится между физикой и высокоуровневым программированием.

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

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

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

Занятно, что ваш разум может обмануть вас и сделать идею чего-либо более приятной, чем сам этот предмет, так что вы наслаждаетесь самой идеей, и не воплощаете её в жизнь. В своей новой книге «Эго – это враг» [Ego is the Enemy], Райан Холидэй [Ryan Holiday] объясняет, что главным препятствием на пути к успеху является представление об успехе.

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

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

В результате, пробуя непосредственно само действие, вы натыкаетесь на стену сопротивления. Чаще всего вы отвлекаете себя от этого дискомфорта неким сиюминутным удовольствием. Роберт Грин объясняет в своей книге «Мастерство» [Mastery], что можно научиться любить это внутреннее сопротивление. Он пишет: «Вы находите некое извращённое удовольствие в том, чтобы двигаться сквозь боль, которую это может принести».

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

• Основная библиотека подходит для широкого семейства техник машинного обучения, а не только для глубинного обучения.
• Линейная алгебра и другие внутренности хорошо видны снаружи.
• В дополнение к основной функциональности машинного обучения, TensorFlow также включает собственную систему логирования, собственный интерактивный визуализатор логов и даже мощную архитектуру по доставке данных.
• Модель исполнения TensorFlow отличается от scikit-learn языка Python и от большинства инструментов в R.

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

Как работает TensorFlow? Давайте попробуем разобраться, посмотреть и понять, как работает каждая часть. Мы изучим граф движения данных, который определяет вычисления, через которые предстоит пройти вашим данным, поймем, как тренировать модели градиентным спуском с помощью TensorFlow, и как TensorBoard визуализирует работу с TensorFlow. Наши примеры не помогут решать настоящие проблемы машинного обучения промышленного уровня, но они помогут понять компоненты, которые лежат в основе всего, что создано на TensorFlow, в том числе того, что вы напишите в будущем!

Представляю вашему вниманию перевод своей статьи Amazon software engineer interview, изначально опубликованной на английском на sobit.me.

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

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

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

Превью

Здравствуй, Хабр! 25-го апреля 2016 года закончилось 3-х месячное напряженное соревнование Home Depot Product Search Relevance в котором нашей команде Turing Test (Igor Buinyi, Kostiantyn Omelianchuk, Chenglong Chen) удалось не только неплохо разобраться с Natural Language Processing и ML, но и занять 3-е место из 2125 команд. Полное описание нашего решения и код доступны тут, краткое интервью тут, а цель этой публикации не только рассказать о решении, которое принесло нам такой результат, но и о тех трудностях и переживаниях, через которые нам довелось пройти во время соревнования.

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

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

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

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

/ фото Ozzy Delaney CC

Мы в 1cloud много рассказываем о собственном опыте работы над провайдером виртуальной инфраструктуры и тонкостях организации внутренних процессов. Сегодня мы решили немного поговорить об оптимизации БД.

От автора: перевод статьи «Функциональное программирование непопулярно, потому что оно странное» вызвал бурное обсуждение. В нескольких комментариях весьма справедливо замечалось, что при обсуждении недостатков функционального программирования хорошо бы опираться на современные и развитые функциональные языки (в оригинальной статье примеры были на шаблонах C++) и что Хаскель, например, последние пять лет широко используется в индустрии. В связи с этим я хотел бы обратить внимание на две очень предметные статьи из другого блога (от автора книги F# for Scientists): (i) "Недостатки чистого функционального программирования" и (ii) "Почему Хаскель так мало используется в индустрии". Перевод первой из них я как раз и хотел бы представить ниже.

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

Перевод поста Стивена Вольфрама "What Is Spacetime, Really?".
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе и подготовке публикации.

Примечание: данный пост Стивена Вольфрама неразрывно связан с теорией клеточных автоматов и других смежных понятий, а также с его книгой A New Kind of Science (Новый вид науки), на которую из этой статьи идёт большое количество ссылок. Пост хорошо иллюстрирует применение программирования в научной сфере, в частности, Стивен показывает (код приводится в книге) множество примеров программирования на языке Wolfram Language в области физики, математики, теории вычислимости, дискретных систем и др.

---

Содержание

Простая теория всего?
Структура данных Вселенной
Пространство как граф
Может быть, нет ничего, кроме пространства
Что есть время?
Формирование сети
Вывод СТО
Вывод ОТО (Общей теории относительности)
Частицы, квантовая механика и прочее
В поисках вселенной
Ок, покажите мне Вселенную
Заниматься физикой или нет — вот в чем вопрос
Что требуется?
Но пришло ли время?

---

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

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

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

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

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

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

Введение

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

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

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

Итак — эти 7 правил:

1. Скука убивает
2. Прежде чем начать, выясните точно для себя, какие действия вы ожидаете от читателя, осилившего ваш труд
3. Пишите в соответствии с правильно сформированной структурой
4. Избегайте неоднозначных местоимений
5. Ясность = иллюстрации + слова
6. Когда имеете дело с понятиями, концепциями и т.п., используйте логическую иллюстрацию и пример
7. Не опасайтесь переделок

Асинхронный код – сложный. Все это знают. Писать асинхронные тесты – еще сложнее. Недавно я починил мигающий (flaky) тест и хотел бы поделиться некоторыми мыслями по поводу написания асинхронных тестов.

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

Тестируем throttler

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

Ничего личного, просто бизнес

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

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

Допустим, я знаю о девушке две вещи — симпатична она мне или нет, а также, есть ли о чём мне с ней поговорить. Если есть, то будем считать это единицей, если нет, то — нулём. Аналогичный принцип возьмем и для внешности. Вопрос: “В какую девушку я влюблюсь и почему?”

Можно подумать просто и бескомпромиссно: “Если симпатична и есть о чём поговорить, то влюблюсь. Если ни то и ни другое, то — увольте.”

Автор этой статьи — Бренден Маллиган, один из создателей LaunchKit, пакета инструментов для iOS-разработчиков. Он также работает над мобильным и веб-приложением Cluster, которое позволяет создавать личные соцсети на основе общих интересов и опыта. Также Бренден является автором проектов ArtistData и OneSheet.

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

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

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