Разбираемся, зачем экранам 500 Гц, почему телевизор не монитор, за сколько часов выгорит OLED и как вообще это всё работает.

Перевод обновлённого гайда Android по архитектуре приложений. Это — первая часть из пяти: обзор рекомендаций по архитектуре.

Мало просто сменить свою сферу работы на IT, желательно еще и стать хорошим разработчиком. Бывший тимлид и консультант Александр Усков рассказывает, как понять, что перед вами плохой разработчик и что с ним вообще можно делать

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

К старту курса по разработке на C# делимся материалом из блога .NET о том, как компилятор C# 10 и .NET 6 упрощают программирование, как они обращаются с форматированием, а также о причинах конкретных решений команды .NET. И это далеко не всё. За подробностями приглашаем под кат.

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

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

Как только наберу посты для вашей тематики IT, я вернусь. Так то у меня информации по вашей сфере только сколько стоит Коворгинг и как снять офис.

Informative

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

Внимание! Перед тем, как рассказать аудитории Хабра об этих проблемах, мной были предприняты попытки сообщить о них разработчикам через платформу HackerOne. Разработчики посчитали это все “не багами”, а репорты были закрыты в статусе “informative”, дважды!

• Можно ли НА САМОМ ДЕЛЕ украсть деньги, прислонившись POS-терминалом к карману? — мы попытаемся полностью воспроизвести этот сценарий мошенничества от начала до конца, с использованием настоящего POS-терминала и платежных карт в реальных условиях.
• В чем разница между физическими и виртуальными картами Apple Pay? — как происходит связывание физической карты и токена Apple Pay, и почему Apple Pay во много раз безопаснее обычной карты.
• Используем аппаратный NFC-сниффер (ISO 14443A) — воспользуемся устройством HydraNFC для перехвата данных между POS-терминалом и картой. Рассмотрим, какие конфиденциальные данные можно извлечь из перехваченного трафика.
• Разбираем протокол EMV — какими данными обменивается карта с POS-терминалом, используемый формат запросов, механизмы защиты от мошенничества и replay-атак.
• Исследуем операции без карты (CNP, MO/TO) — в каких случаях на самом деле(!) можно украсть деньги с карты, имея только реквизиты, считанные бесконтактно, а в каких нельзя.

Физически-корректный рендеринг

PBR, или физически-корректный рендеринг (physically-based rendering) это набор техник визуализации, в основе которых лежит теория, довольно хорошо согласующаяся с реальной теорией распространения света. Поскольку целью PBR является физически достоверная имитация света, он выглядит гораздо более реалистичным по сравнению с использованными нами ранее моделями освещения Фонга и Блинна-Фонга. Он не только лучше выглядит, но и дает неплохое приближение к реальной физике, что позволяет нам (и в частности художникам) создавать материалы, основанные на физических свойствах поверхностей, не прибегая к дешевым трюкам дабы заставить освещение выглядеть реалистично. Главным преимуществом такого подхода является то, что создаваемые нами материалы будут выглядеть как задумано независимо от условий освещения, чего нельзя сказать о других, не PBR подходах.

В свободное и не свободное время[1] я развиваю несколько своих проектов на github, а также, по мере сил, участвую в жизни интересных для меня, как программиста, проектах.

Недавно один из коллег попросил консультацию: как выложить разработанную им библиотеку на github. Библиотека никак не связана с бизнес-логикой приложения компании, по сути это адаптер к некоему API, реализующему определённый стандарт. Помогая ему, я понял что вещи, интуитивно понятные и давно очевидные для меня, в этой области, совершенно неизвестны человеку делающему это впервые и далёкому от Open Source.

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

Так что из себя представляет стильный, модный, молодёжный Open Source проект в 201* году?

 Введение

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

Введение