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

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

В этой статье мы познакомимся с POSIX Threads для того, чтобы затем узнать как это все работает в Linux. Не заходя в дебри синхронизации и сигналов, рассмотрим основные элементы Pthreads. Итак, под капотом потоки.

До:



После:



Заинтригованы? Но обо всем по порядку.

t-SNE

t-SNE — это очень популярный алгоритм, который позволяет снижать размерность ваших данных, чтобы их было проще визуализировать. Этот алгоритм может свернуть сотни измерений к всего двум, сохраняя при этом важные отношения между данными: чем ближе объекты располагаются в исходном пространстве, тем меньше расстояние между этими объектами в пространстве сокращенной размерности. t-SNE неплохо работает на маленьких и средних реальных наборах данных и не требует большого количества настроек гиперпараметров. Другими словами, если взять 100 000 точек и пропустить их через эту волшебный черный ящик, на выходе мы получим красивый график рассеяния.

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

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

Не будем лукавить: JavaScript никогда не был идеальным языком программирования. Одним из слабых мест в JS была модульность, а точнее её отсутствие. Действительно, зачем в скриптовом языке, который анимирует падающие на странице снежинки и валидирует форму, заботиться об изоляции кода и зависимостях? Ведь всё может прекрасно жить и общаться между собой в одной глобальной области — window.

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

Эта статья появилась в результате общения с участниками TC39 и разработчиками фреймворков, а также чтения исходных кодов, блогов и книг. Мы рассмотрим следующие подходы/форматы: Namespace, Module, Detached Dependency Definitions, Sandbox, Dependency Injection, CommonJS, AMD, UMD, Labeled Modules, YModules и ES2015 Modules. Кроме того, мы восстановим исторический контекст их появления и развития.

Это перевод статьи, которую Марико Косака написала в качестве альтернативного введения в промисы JavaScript. Наброски иллюстраций она делала в своём блокноте во время чтения разных статей, посвящённых промисам. Если хотите изучить более подробно, в конце вы найдёте список полезных ссылок.

Недавно Марико участвовала в обсуждении того, как можно с помощью JavaScript сделать фичу, которая давала бы доступ к внешним данным (должна была быть асинхронной). Она сказала: «Ну, давайте используем fetch()… так что в коде… эээ...», и пока силилась вспомнить fetch API, собеседник сказал: «Будет возвращаться промис». По словам Марико, её мозг впал в ступор, и она сказала: «Честно говоря, не знаю, что ты имеешь в виду…»

Ей приходилось много раз писать код, основанный на промисах, но для полной картины нужные пазлы в её голове почему-то не соединились. Она поняла, что на самом деле не «въезжает» в суть.

В 1998 году Looking Glass Studios выпустила стелс-игру Thief: The Dark Project. В то время аппаратное 3D-ускорение только зарождалось, поэтому в процессе разработки оно не использовалось, игра рендерилась только программно.

Я был основным автором базовой технологии рендеринга Thief (хотя я и не писал рендереры объектов и персонажей), а также связанных с ней элементов. Тот же движок рендеринга, модифицированный другими людьми для использования аппаратного 3D-ускорения, также использовался для рендеринга System Shock 2 и Thief 2.

Движок был написан примерно в одно время с Quake (хотя игра вышла намного позже), и общий внешний вид сильно напоминает Quake. Многие технологии были скопированы из Quake или вдохновлялись им, но часто их работа немного или значительно отличалась.

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



Имея параметры видимости наблюдателя (направление взгляда, расстояние видимости и угол поля зрения), нам нужно найти видимую для него область, т.е. определить область видимости (field of view, FoV). Если препятствия отсутствуют, это будет сектор круга, состоящий из двух граней (радиусов) и соединяющей их дуги (см. Рис. 1). Кроме того, имея заданную точку мира, мы должны быстро определить, видима ли она для наблюдателя, т.е. необходимо обрабатывать запросы линии взгляда (line of sight, LOS) для заданной точки. Обе эти операции можно выполнить достаточно эффективно для использования при рендеринге в реальном времени.

Этот пост просто шутка и не пытается выставить инструменты, упомянутые здесь, в дурном свете. Я использую их постоянно, они великолепны, и я рекомендую их использовать. По мотивам It's the future @ CircleCI Blog

— Эй, я бы хотел научиться писать крутые веб-приложения. Слышал, у тебя есть опыт.

— Да, я как раз занимаюсь фронтендом, юзаю пару тулз.

— Круто. Я щас делаю простое приложение — обычный TODO-лист, используя HTML, CSS и JavaScript, и планирую заюзать JQuery. Это норм?

— Не-не-не. Это олдскул. Джиквери мёртв — никто не использует его теперь! Тебе нужен React. Это будущее.

— Окей, лады. А что это?

Часто встречается такой вопрос, когда заходит речь о современных астрономических возможностях, в спорах о высадке людей на Луне. Многих впечатляют красочные снимки с телескопа Hubble далеких галактик и планет на окраине Солнечной системы, и кажется уж на Луне-то мы можем вообще всё рассмотреть.

Этим летом вышла очередная игра из серии Batman Arkham, в ПК версии которой оказалось столько багов, что было принято беспрецедентное решение снять её с продаж. Я решил посмотреть, что же там такого ужасного.

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

На скриншоте изображён этот момент: вместо того, чтобы лететь вперёд, Бэтмен повернулся вниз головой, демонстрируя полнейшее пренебрежение к происходящему. Аналогичный баг был в предыдущей игре (Arkham Origins), и он до сих пор не исправлен. Видимо тот же самый кривой код был перенесён в новую игру. Попробуем найти, какие ошибки делают программисты в играх такого уровня, и исправить их.

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

Основные проблемы, которые встречаются в библиотеках валидации данных

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

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

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

Проблема №4. Валидация останавливается на первом же поле с ошибкой. Такой подход не дает возможности подсветить сразу все ошибочные/обязательные поля в форме.

Проблема №5. Нестандартизированные сообщения об ошибках. Например, «Field name is required». Такую ошибку я не могу показать пользователю по ряду причин:

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

То есть, нужно возвращать не сообщение об ошибках, а стандартизированные коды ошибок.

Проблема №6. Числовые коды ошибок. Это просто неудобно в использовании. Я хочу, чтобы коды ошибок были интуитивно понятны. Согласитесь, что код ошибки «REQUIRED» понятней, чем код «27». Логика аналогична работе с классами исключений.

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

Проблема №8. Ограниченный набор правил. Стандартных правил всегда не хватает. Валидатор должен быть расширяемый и позволять добавлять в него правила любой сложности.

Проблема №9. Слишком широкая сфера ответственности. Валидатор не должен генерировать формы, не должен генерировать код, не должен делать ничего, кроме валидации.

Проблема №10. Невозможность провести дополнительную обработку данных. Практически всегда, где есть валидация, есть необходимость в какой-то дополнительной (часто предварительной) обработке данных: вырезать запрещенные символы, привести в нижний регистр, удалить лишние пробелы. Особенно актуально — это удаление пробелов в начале и в конце строки. В 99% случаев они там не нужны. Я знаю, что я до этого говорил, что валидатор не должен делать ничего кроме валидации.

3 года назад, было решено написать валидатор, который не будет иметь всех вышеописанных проблем. Так появился LIVR (Language Independent Validation Rules). Есть реализации на Perl, PHP, JavaScript, Python (мы на python не пишем — фидбек по ней дать не могу). Валидатор используется в продакшене уже несколько лет практически в каждом проекте компании. Валидатор работает, как на сервере, так и на клиенте.

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



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

Операция слияния (merge), выполняемая стандартными средствами git, хорошо работает для текстовых файлов, содержащих исходные тексты программ. Но слияние текстовых файлов, содержащих жестко структурированные данные, в частности JSON — это большая головная боль.

Для решения этой проблемы можно подключить к git'у отдельный инструмент слияния для JSON-файлов, который не работает построчно, а учитывает структуру JSON-объектов.

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

Перевод поста Эда Пегга Младшего (Ed Pegg Jr) "Martin Gardner’s 100th Birthday"

Я думаю, содержание этого поста будет интересно всем, кто любит математику и ее красоту, всем, кто знаком с замечательными книгами и задачами Мартина Гарднера, а также будет полезно учителям, школьникам и студентам. Все ссылки в данном посте ведут на сайты Wolfram Demonstrations Project (коллекция бесплатных интерактивных демонстраций, созданных пользователями системы Mathematica на языке Wolfram Language с помощью технологии Computable Document Format (CDF), при этом для вас доступны исходные коды всех демонстраций, а значит, вы можете каждую из них скачать, изучить и изменить под себя) и Wolfram MathWorld (крупнейшая и самая авторитетная онлайн-энциклопедия по математике).

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

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

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

Что это?

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

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

Одним прекрасным вечером, не предвещающим ничего интересного, в наш чатик поступило предложение от автора публикации «Переводим в код 5 действительно полезных шаблонов адаптивной разметки», написанной им весной 2012 года, написать статью-ремейк, но с применением FlexBox и сопутствующим пояснением что и как работает. После некоторой доли сомнений, интерес глубже разобраться в спецификации все таки победил и я благополучно сел верстать те самые примеры. В ходе погружения в эту область стало выясняться множество нюансов, что переросло в нечто большее чем просто переверстать макетики. В общем в данной статье хочу рассказать о такой чудесной спецификации, под названием «CSS Flexible Box Layout Module» и показать некоторые ее интересные особенности и примеры применения. Всех кому интересно, любезно приглашаю под хабракат.

Предлагаю юмористическую фантастику на тему финансов для всех, в том числе для инопланетян. Написано (мной) еще в 2003 г., впервые опубликовано в 2012, сборник «Об экономике с улыбкой».

Сегодня автором был выложен в открытый доступ фильм «Полигон 27». Особенность его в том, что режиссером, сценаристом, оператором, композитором и специалистом по спецэффектам является один человек — Артем Мирошин, а актерами — энтузиасты из города Хабаровска.

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