«Люби и знай свой инструмент!» Настоятельно рекомендую любую книжку Дэвида Пога про ОС 10—это базовые вещи, после них ОСь будет казаться намного комфортнее.
У меня есть PowerBook G4 2003 года с родной зарядкой—до сих пор прекрасно себя чувствует, но да, пластик у провода по ощущениям другой, как-будто более гладкий. До сих пор работает на Тигре, вполне себе печатная машинка. Кстати, у тех PowerBook'ов была лучшая клавиатура на мой взгляд.
Наверное в том, что пропал возможность привязать перетаскивание к жесту. Раньше у меня перетаскивание было настроено на «Три пальца», после обновления вообще пропала возможность перетаскивать.
Тогда же отказались от Ethernet, это главная претензия к Эиру была. Для меня Эир наоборот переоткрыл понятие ноутбука: маленький, как лист А4, лёгкий, можно в карман положить, и работал по пять часов от батарейки.
Вообще, вроде MagSafe I не страдал так сильно от перетирания, у меня уже семь лет живёт. Так что это просто регресс: MagSafe I -> MagSafe II -> USB Type C
Да, я знаю про jOOQ, но ни разу не видел его использование хоть в чем-то, напоминающем продакшен. Возможно потому что это полу-платный новодел без JSR, возможно по другой причине.
В защиту jOOQ'а скажу, что во всю используем в продакшене энтерпрайза: гораздо очевиднее, чем JPQL/Criteria Builder, а в сочетании с правильной готовкой миграций даёт управляемую работу с БД. Почему-то JPQL/Criteria Builder считают, что разработчики не могут в SQL, поэтому предлагают навернуть абстракций там, где можно обойтись понятным и проверяем (во время компиляции) кодом.
Расскажите лучше, всегда один и тот же ли номер карты вам показывает Apple Pay? Вроде там на каждую транзакцию сгенерируется новый PAN из определённого пула номеров.
Ничего не синхронизируется: Apple Pay в оффлайне генерирует криптограмму, которую и отправляет. Авторизацией является ваш отпечаток пальца, которому МастерКард (и только МастерКард) доверяет как введенному пин-коду. Про ApplePay и Visa отдельный разговор.
В современных картах с чипом практически всегда (или всегда) есть Java-апплет от ПС, плюс один или более апплетов от эмитента. Например, могут быть кобрендовые карты, где вместе с апплетом эмитента стоит апплет партнёра (типа карт РосБанка для Окея).
Дело не в лимите списания. Никто так не делает: эмитент с радостью получит свои 15€ сверху за каждое представление о возврате платежа, а эквайер даже не подумает его оспаривать, так как слишком дорого будет потом арбитраж оплачивать. Для борьбы с такими атаками у всех эквайеров есть служба финмониторинга, и я ни разу не слышал, чтобы кто-то реально пытался такое провернуть.
Все операции, которые антифрод эквайера посчитал безопасными. Критерии могут быть разными, вот примерный список: MCC (merchant category code) продавца, сумма, «похожесть» операции на предыдущие, история платежей с устройства, с которого совершается платёж, геопозиция, оборот продавца. Для крупных ритейлеров а-ля 6pm.com ваш chargeback на 50$ никто не заметит и спишет в чистый убыток.
У iCloud и Steam обычные рекурренты (новый платёж с привязкой к старому). У Стима нет своего PCI DSS, подозреваю, у Эппл тоже, все пользуются услугами сторонних PSP.
В PCI DSS как раз номера можно хранить в зашифрованном виде, нельзя хранить CSC (опять же с некоторыми оговорками). Но можно хранить т. н. синонимы карт.
Можно, но в какой-то момент начинаешь очень сильно предпочитать явное неявному.
В защиту jOOQ'а скажу, что во всю используем в продакшене энтерпрайза: гораздо очевиднее, чем JPQL/Criteria Builder, а в сочетании с правильной готовкой миграций даёт управляемую работу с БД. Почему-то JPQL/Criteria Builder считают, что разработчики не могут в SQL, поэтому предлагают навернуть абстракций там, где можно обойтись понятным и проверяем (во время компиляции) кодом.