У меня есть два одинаковых телефона Сони: один куплен в России, другой — в Гонконге. На обоих сегодня появилось одно и то же уведомление, сгенерированное стоковым приложением Support:



Уведомление отнесено к категории «miscellaneous» (прочие), отключить которые невозможно. Как и удалить или деактивировать само приложение Support (штатными средствами):

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)

Доброго времени суток, Хабр. Мы продолжаем цикл «Галоп Пикселя». Сейчас, находясь на старте 2019 года, можно с уверенностью говорить, что это не только цикл статей, но и многолетняя сага. Пространное повествование о пикселях, их жизни, способе их создания, приёмах и уловках в работе с ними. Мы не будем рассуждать о причинах первоначального «спринта», который затем превратился в многолетний марафон, ибо нет ничего более жизненного, чем сама жизнь. Кому нужны причины отсутствия или пауз, если можно просто вернуться к тому, что мы делали, в чём варились, и в чём, даст бог — будем наблюдаться и далее. В пикселях, конечно же!

Сегодняшняя публикация станет очередной, и возможно даже поворотной вехой в нашем повествовании. Наконец-то мы подошли к созданию полноценной анимации персонажей. Двумя предыдущими главами мы охватили анимацию света и тени, а также анимацию неподвижных персонажей (idle-animation) без ярко выраженных действий. Но сегодня наши персонажи пойдут, а в следующей части даже побегут, завоевав то, что уже давно их по праву рождения. Ещё один плодородный регион. И пройдут ещё одну точку, которая ознаменует окончание базового цикла. Наши пиксели наконец-то станут живыми.

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

Это перевод публикации «Les Forges Pixel Art Course».

Часть 1: Правильные инструменты
Часть 2: Линии и кривые
Часть 3: Перспективы
Часть 4: Тень и свет
Часть 5: Палитры цветов
Часть 6: Сглаживание
Часть 7: Текстуры и размытие
Часть 8: Мир тайлов

Часть 6: Сглаживание (Anti-aliasing)

Где весь ваш пиксель-арт становится красивым. Или нет. На самом деле это зависит от того, насколько ужасен он был прежде.

Введение

Я хочу представить вам результат своих экспериментов с алгоритмами распознавания образов с обучением с первого раза (так называемый One-Shot Learning). В результате экспериментов выработались определённые подходы к структуризации изображения и в итоге они воплотились в несколько взаимосвязанных алгоритмов и тестовое приложение на Android, которым можно проверить качество и работоспособность алгоритмов.

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

Привет!

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

Короче, у вас есть игра. Только в неё нельзя выиграть или проиграть. И в ней нельзя ничего поменять. И вы ни на что не влияете. Но при этом она интересная. Как игра, а не как фильм. Называется Firewatch.

Пошли, покажу этот оксюморон.

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

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

24 марта сего года произошло событие, которого мы все так давно ждали: в сервисе цифровой дистрибуции компьютерных игр Steam вышел очередной шедевр польского игростроя — Hydra Slayer. И хотя шедевр этот местами кривоват, да и ждали его далеко не все, а скорее три с половиной человека, всё же я полагаю его достойным своей статьи на Хабре. «Постойте-ка, любезный автор, — воскликнет сейчас человек по другую сторону монитора от меня, — а не спутали ли вы часом столь уважаемый сайт, как Хабрахабр, с каким-нибудь игровым порталом, где юноши от четырнадцати лет и младше делятся своими успехами в Майнкрафте, обильно используя ненормативную лексику?». Нет, не спутал. Этому материалу суждено особое место в хабе «Математика».

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

Многие люди пользуются электронной почтой уже на протяжение десятилетий — а значит, возникает вопрос о том, что анализ данных писем за долгое время может рассказать об эволюции конкретной личности. Журналист и создатель сервиса для разработки веб- и мобильных приложений Postlight Пол Форд в своем блоге на Medium опубликовал результаты эксперимента, в ходе которого он пытался создать динамическую систему поиска писем в своем почтовом ящике, в котором за 18 лет скопилось более 450 тыс. email-сообщений. Мы представляем вашему вниманию адаптированный перевод этой заметки.

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

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

Когда я делаю ошибку в коде, то обычно это приводит к появлению сообщения “segmentation fault”, зачастую сокращённого до “segfault”. И тут же мои коллеги и руководство приходят ко мне: «Ха! У нас тут для тебя есть segfault для исправления!» — «Ну да, виноват», — обычно отвечаю я. Но многие ли из вас знают, что на самом деле означает ошибка “segmentation fault”?

Чтобы ответить на этот вопрос, нам нужно вернуться в далёкие 1960-е. Я хочу объяснить, как работает компьютер, а точнее — как в современных компьютерах осуществляется доступ к памяти. Это поможет понять, откуда же берётся это странное сообщение об ошибке.

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

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

Лет эдак 20 назад довелось мне изучать высшую математику в вузе, и начинали мы с матриц (пожалуй, как и все студенты того времени). Почему-то считается, что матрицы — самая лёгкая тема в курсе высшей математики. Возможно — потому, что все действия с матрицами сводятся к знанию способов расчёта определителя и нескольких формул, построенных — опять же, на определителе. Казалось бы, всё просто. Но… Попробуйте ответить на элементарный вопрос — что такое определитель, что означает число, которое вы получаете при его расчёте? (подсказка: вариант типа «определитель — это число, которое находится по определённым правилам» не является правильным ответом, поскольку говорит о методе получения, а не о самой сути определителя). Сдаётесь? — тогда читаем дальше…

Прим. переводчика: Это перевод статьи Питера Брайта (Peter Bright) «How security flaws work: The buffer overflow» о том, как работает переполнение буфера и как развивались уязвимости и методы защиты.

Беря своё начало с Червя Морриса (Morris Worm) 1988 года, эта проблема поразила всех, и Linux, и Windows.



Переполнение буфера (buffer overflow) давно известно в области компьютерной безопасности. Даже первый само-распространяющийся Интернет-червь — Червь Морриса 1988 года — использовал переполнение буфера в Unix-демоне finger для распространения между машинами. Двадцать семь лет спустя, переполнение буфера остаётся источником проблем. Разработчики Windows изменили свой подход к безопасности после двух основанных на переполнении буфера эксплойтов в начале двухтысячных. А обнаруженное в мае сего года переполнение буфера в Linux драйвере (потенциально) подставляет под удар миллионы домашних и SMB маршрутизаторов.

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

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

(За перевод спасибо Алексею Ворсину)

Доброе утро и добро пожаловать на GovCon7. Меня зовут Сод Абдулли и я ведущий инженер по внедрению Palantir Technologies и это Palantir 101. Я хотел бы в ближайшие полчаса или сорок пять минут рассказать о том что это, кто мы, что такое Palantir, и что он делает для организаций, с которыми мы работаем, а также, ближе к концу мероприятия, мы проведем небольшую презентацию.

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



Первая история, — это история о шахматах.

Многие из вас знают, что в 1997 IBM создали суперкомпьютер Deep Blue, который одолел Гарри Каспарова, на тот момент, бывшего лучшим шахматистом в мире. Сейчас в простой мобильник могут быть установлены шахматы, играющие на турнирном уровне, и вопрос о том, кто сильнее в шахматах, человек или компьютер, уже не актуален.

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

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

Эти силы сочетаемы и команда человек/компьютер способна победить и команды сильнейших игроков и объединения сильнейших суперкомпьютеров.

— Не могли бы вы построить нам статистическую модель?
— С удовольствием. Можно посмотреть на ваши исторические данные?
— Данных у нас ещё нет. Но модель всё равно нужна.

Знакомый диалог, не правда ли? Далее возможны два варианта развития событий:

A. «Тогда приходите, когда появятся данные.» Вариант рассматриваться не будет как тривиальный.
Б. «Расскажите, какие факторы по вашему мнению наиболее важны.» Остаток статьи про это.

Под катом рассказ о том, что такое improper model, почему их красота устойчива и чего это стоит. Всё на примере многострадального набора данных о выживании пассажиров Титаника.

Если вам случалось пропустить дедлайн – в этом вы не одиноки.

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

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

В нашей компании Edgar мы полностью отказались от дедлайнов – и вы тоже можете так сделать.

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

Попробуем в нескольких статьях пройти путь от описания базовых идей, лежащих в основе всех сборщиков мусора, до разбора алгоритмов работы и возможностей тонкой настройки различных сборщиков Java HotSpot VM (вы ведь знаете, что таких сборщиков четыре?). И самое главное, рассмотрим, каким образом эти знания можно использовать на практике.

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

Недавно Владимир Подольский vpodolskiy, аналитик в департаменте по работе с образованием IBS, закончил обучение по специализации Data Science на Coursera. Это набор из 9 курсеровских курсов от Университета Джонса Хопкинса + дипломная работа, успешное завершение которых дает право на сертификат. Для нашего блога на Хабре он написал подробный пост о своей учебе. Для удобства мы разбили его на 2 части. Добавим, что Владимир  стал еще и редактором проекта по переводу специализации Data Science на русский язык, который весной запустили IBS и ABBYY LS.

Часть 1. О специальности Data Science в общих чертах. Курсы: Инструменты анализа данных (программирование на R); Предварительная обработка данных; Документирование процесса обработки данных.

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

Не так давно закончился мой 7-месячный марафон по освоению специализации «Наука о данных» (Data Science) на Coursera. Организационные стороны освоения специальности очень точно описаны тут. В своём посте я поделюсь впечатлениями от контента курсов. Надеюсь, после прочтения этой заметки каждый сможет сделать для себя выводы о том, стоит ли тратить время на получение знаний по аналитике данных или нет.

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

Для хищения информации использовалось приложение для прослушивания музыки под названием «Музыка ВКонтакте». Жертвы скачивали его из официального магазина Google Play, где собрано программное обеспечение (ПО) для Android-устройств. По грубым оценкам «Лаборатории Касперского», число пострадавших может исчисляться сотнями тысяч.

Кража данных происходила после того, как пользователь авторизовался в приложении, то есть вводил свои логин и пароль, установленные для доступа в свой аккаунт «ВКонтакте». Примечательно, что злоумышленники проверяли подлинность этих данных, отправляя их на легитимный сервер аутентификации oauth.vk.com, отмечают в «Касперском», а пользователи не догадывались о вредоносности программы, поскольку она справлялась со своей заявленной функцией — проигрывала аудиозаписи из «ВКонтакте».