Одновременная межсайтовая аутентификация (SSO), для чего же она нужна? Допустим у нас есть, назовём его анахроничным термином «портал», с блогами, фотками, фейлами (или файлами, кому как), назовём его fail.ru (не путать с одноимённым сервисом почты на букву М), причём всё это усложнено следующими факторами:
— функционал совершенно разный;
— код написан разными людьми, с испольованием разных технологий;
— работает всё это на разных серверах в разных датацентрах и с разными базами данных;
— сервера находятся на разных доменах.

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

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

Далее мы рассмотрим самописные альтернативы, OpenID, OAuth, SAML, и почему всё это в общем случае не слишком хорошее решение, вопросы хранения аутенитификационных данных, а также некоторые вопросы безопасности в которые без хороших знаний самому лезть не стоит, что такое вообще межсайтовая аутентификация, развеем некоторые мифы.

Глобальное освещение, динамический свет и декали (да, есть такое слово :) ) в действии.

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

Малейшего облегчения было достаточно, лишней пайки хлеба, тарелки крапивных щей, чтобы очнулась стиснутая до предела, замершая душа. И тогда с небывалым прежде восторгом, благоговением ценились простые радости: сухой чистый асфальт, оконная рама с целым стеклом, нагретая солнцем стена, зелень деревьев, ни в одну весну не были они такими зелеными, как в ту весну! Чудом была и кровать с чистыми простынями, и цветок, который можно было не рвать, не жевать, не готовить из него салат, а оставить просто цветком, который вырос на газоне.
Алесь Адамович, Даниил Гранин “Блокадная книга”

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

The distinguishing characteristic of industrial-strength software is that it is intensely difficult… the complexity of such systems exceeds the human intellectual capacity… we may master this complexity, but we can never make it go away.

Grady Booch

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

В последние два месяца лета в управлении хранилищ данных (Data Warehouse, DWH) Тинькофф Банка появилась новая тема для кухонных споров.

Всё это время мы проводили масштабное тестирование нескольких in-memory СУБД. Любой разговор с администраторами DWH в это время можно было начать с фразы «Ну как, кто лидирует?», и не прогадать. В ответ люди получали длинную и очень эмоциональную тираду о сложностях тестирования, премудростях общения с доселе неизвестными вендорами и недостатках отдельных испытуемых.

Подробности, результаты и некое подобие выводов из тестирования — под катом.

Эта статья — ревью на книгу «Growing Object-Oriented Software, Guided by Tests» (GOOS для краткости). В ней я покажу, как можно имплементировать проект-пример из книги без использования моков (mocks).

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

Версия на английском: ссылка.

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

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

Наркоторговля, отмывание денег, терроризм и педофилия.

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

Термин играет на сходстве с библейскими персонажами. Четыре всадника Апокалипсиса — это катастрофы и катаклизмы, предваряющие второе пришествие Иисуса Христа и Страшного суда. Четыре всадника Инфокалипсиса тоже сеют разрушения и хаос, но в глобальной Сети. Делается подобное с согласия и одобрения миллионов людей.

Впервые термин «Четыре всадника» начал употреблять Тимоти Мэй примерно в 1988 году при обсуждении слабой распространённости криптографических инструментов среди обычных людей. В 1994 году термин звучит в его «Шифрономиконе», документе криптопанков, который описывает идеи и эффекты криптоанархизма. «Шифрономикон» оформлен в формате вопросов и ответов. В документе начала девяностых обсуждаются цифровые валюты, право на частную жизнь в Сети и биржи убийств.

Блокировки в общем и мьютексы, как их частная реализация, имеют давнюю историю неправильной оценки скорости их работы. Ещё в 1986-ом году в одной из Usenet-конференций Matthew Dillon написал: «Большинство людей ошибочно уяснили себе, что блокировки работают медленно». Сегодня, спустя многие годы, можно констатировать, что ничего не изменилось.

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

Одна из причин заблуждений о скорости работы блокировок состоит в том, что многие программисты не отличают понятия «легковесный мьютекс» и «мьютекс, как объект ядра ОС». Всегда используйте легковесные мьютексы. К примеру, если вы программируете на С++ под Windows, то ваш выбор это критические секции.

Второй причиной заблуждений могут служить, как это ни парадоксально, бенчмарки. К примеру, далее в этой статье мы будем измерять производительность блокировок под высокой нагрузкой: каждый поток будет требовать блокировку для выполнения любого действия, а сами блокировки будут очень короткими (и, в результате, очень частыми). Это нормально для эксперимента, но такой способ написания кода — это не то, что вам нужно в реальном приложении.

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

• Асинхронные сервис интерфейсы
• Выполнение вызовов сервиса в едином потоке
• Неразделённое владение данными
• Асинхронный Web
• Асинхронная платформа исполнения сервисов
  

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

// просто сравните длину строк
this.this.this.this.
var s=this;s.s.s.s.

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

Игра почти готова, осталось всего-то пару дней не спать...

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

Переходим ко второй:



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

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

Предыдущие части

• Глава 1
• Глава 2
• Глава 3
• Глава 4
• Глава 5

Темой доклада Василия Лукьянчикова является индексирование в MySQL и расширенные возможности EXPLAIN, т.е. нашей задачей будет ответить на вопросы: что мы можем выяснить с помощью EXPLAIN'а, на что следует обращать внимание?

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

По индексам мы пройдемся очень кратко, исключительно в плане того, какие нюансы есть в MySQL, в отличие от общей теории.

Доклад, таким образом, состоит из 3х частей:

• Архитектура;
• Основы индексирования;
• EXPLAIN (примеры).

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

Конечная цель любой балансировки игры – увеличение возврата игроков или времени партии. То есть играбельности механики:

• Не должно быть однозначной ультимативной стратегии победы, иначе игра потеряет вариативность и интерес.
• Игрок должен чувствовать, что от его действий и навыков зависит игра. Иначе получится Mass Effect, который, скорее, фильм, нежели RPG.
• Баланс должен быть «амортизированным», то есть прощать некоторые ошибки – иначе запоздалый на миллисекунду клик в Starcraft по первому рабочему из-за «эффекта бича» вызывал бы проигрыш через 4 часа идеальной партии. Наша настольная формула – 5-7 важных решений за игру, в двух можно ошибиться.
• У настолок есть ещё социальное условие: игроки не должны выпадать по ходу пьесы – интересно должно быть всем и до конца.

Теперь – методы.

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

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

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

Всем привет! Я Иван Бакаидов. И сейчас я расскажу как я помогаю людям с двигательными нарушениями и нарушениями речи. Но сначала немного обо мне:

• Мне 17 лет
• ДЦП — у меня самопроизвольно сокращаются мышцы тела… Все
• Неразборчивая речь. Понимают только мама, брат и одноклассница
• Node.js, Java, Android dev, Unity3d
• Выступал на гуманитарном саммите ООН с посланием о правах человека с нарушениями речи и важности AAC

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

В качестве одного из примеров попробуйте ответить на простой вопрос: «откуда возникает подъемная сила в крыле самолета»?



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

В этой статье исследуется текущее состояние разработки искусственного интеллекта, рассматриваются вызовы и угрозы, а также особенности работы наиболее признанных учёных, и описываются основные прогнозы, в каком виде может предстать перед нами ИИ. В целом это переработанная и сокращённая версия состоящего из двух частей эссе, написанного Тимом Урбаном для “Wait But Why”.

Доброго времени суток! Представляю вашему вниманию вольный перевод статьи от GDE (Google developer expert) Dmytro Danylyk. Собственно, вот оригинал. Статья описывает правильные подходы для работы со strings.xml и особенно полезно это будет разработчикам, которые разрабатывают мультиязыковые приложения. Прошу под кат.