объяснялка

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

Для начала потребуется заключить договор с платежным провайдером. В России лидер Cloudpayments, заграницей — Stripe.

Для клаудпейментса нужно русское юрлицо и счет в российском банке, для страйпа — юрлицо и счет в банке в одной из 47 стран. Регистрация займет пару дней, приготовьте учредительные документы.

Для обоих систем доступны два основных метода интеграции:

1) Попроще, когда вы вставляете их формочку на сайт или в приложение буквально добавлением одной строки в код, с возможностью немного менять цвета;

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

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

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

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

Есть сотни узкоспециализированных провайдеров, которые лучше подойдут при большом числе транзакций, если у вас какой-то особенный бизнес (знакомства, например) или необходимо принимать физические карты, но это уже совсем другая история 💸

Вчера ночью сняли эмбарго с информации об уязвимостях процессоров.

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

Это страшно «облакам», суть которых как раз в том, что программы разных людей делят один физический сервер. Сейчас модно называть такой подход виртуализацией. Речь идёт о более эффективном расходовании серверов: если две программы (два клиента) могут поместиться на один физический сервер - так и делаем. Принципиальное обещание «виртуализации» в том, что ваши данные так же защищены, как если бы они были на отдельном сервере. Ага.

Самих дыр не достаточно - нужно сочетание многих условий для того, чтобы извлечь из неё какую-либо «выгоду». Думаю, многие «исследователи» в кавычках и без занимаются этим вопросом прямо сейчас. Будет ли идти речь о таргетированных атаках, когда отсифонят секретные данные конкретной жертвы и используют их для дальнейших этапов атаки или о каких-то «массовых изъятиях денег у населения» - пока говорить рано. Поживём-увидим. (Я бы назвал эти уязвимости popcorn time)

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

Строго говоря, речь идёт о 3 уязвимостях: bounds check bypass CVE-2017-5753, branch target injection CVE-2017-5715 и rogue data cache load CVE-2017-5754.

Интересно, что их одновременно нашли две независимые групп исследователей. Первая - звездный Project Zero из Google. Они отправили письма производителям процессоров ещё 1 июня (!) 2017. Вторая - группа исследователей из универов. Project Zero опубликовал классный технический разбор, а университеты максимально отработали PR-сторону, нагнав страху на массовую аудиторию «дизайнерским лендингом».

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

Готовил вчера отчет по техническому аудиту для одного нашего клиента. Хочу поделиться с вами абзацем, где мы объясняем трудности программирования на пальцах:

… «Лапша в бизнес-логике». Бизнес-логика в приложении — это цепочка вызова команд. Эти цепочки часто содержат больше 7 шагов. Это больше, чем человек может уместить в голове. Чтобы решить эту проблему, люди описывают цепочки в одном месте, последовательно: одна строчка — один шаг бизнес-процесса (пример на руби). В нашем проекте, сейчас, это не так. Логика бизнес-процессов кочует из файла в файл. Пример: … — в попытке отследить бизнес-логику платежей мы «прыгнули» по коду 11 (!) раз. Это бесчеловечно. …

Мне очень нравится, что мы с Федей привлекаем экспертов себе в помощь. Я уже писал об Антоне Давыдове, но если вдруг пропустили — вот его канал в телеге. Кайфую каждый раз, когда делаю что-то вместе с Антоном.

Microsoft и Sony объединят силы в создании облачной гейминговой платформе, будут вместе бороться с Google Stadia.

Microsoft и Sony — создатели и владельцы двух главных конкурирующих приставок — PlayStation и Xbox. Совместная работа — неслыханное дело.

Ох, жарко будет!

❧

Ключевой вопрос в облачном гейминге — latency [wiki] (более узко — input lag [wiki]). Это важный в программирование, UX и управление термин, для которого я не знаю хорошего перевода на русский. Лучший аналог — время ожидания, задержка. Это время, которое игра НЕ отвечает на ваши действия.

Это время, которое проходит между нажатием на кнопку и отображением действия на экране (или звуком в динамиках, и говорят, что задержка в человеческом мозге для аудио ниже, чем для видео). Консенсус, кажется [wiki], в том, что задержка больше 200 миллисекунд (1/5 секунды) мешает играть, а задержка в 60 мс малозаметна. Средняя игра на приставке имеет задержку в 67-133 миллисекунды. Прямо сейчас мой рижский домашний интернет достукивается до ближайшего сервера гугла за 15 миллисекунд (8.8.8.8, благодаря сетевой магии этот адрес почти всегда отвечает ближайшим сервером). RTT (время туда-обратно) = 30 миллисекунд. Звучит реалистично!

Вы не поверите, но для российских игроков даже тут в дело вступает Роскомнадзор. Захотят ли Google и Sony держать эти серверы в России? Как отразятся на игре дополнительные задержки, если ближайшие серверы будут в Европе?

❧

Возможность не покупать приставку и поиграть немножко в AAA-эксклюзивы [wiki] меня лично очень привлекает. Это как не покупать машину и кататься на Яндекс.Такси. Наконец-то!

В контексте падения облаков, чем они лучше/хуже собственного железа?

Можно подумать, что я буду сейчас писать про отказоустойчивость. На самом деле, если ваш проект будет лежать, когда лежит весь GCP или AWS, — то для 99% проектов это абсолютно нормально, такие события происходят раз в несколько лет и длятся не больше пары часов. Мы ведь не кислородными масками управляем, верно?

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

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

Главное преимущество облаков в сравнении с «реальными серверами» — возможность быстро масштабироваться, то есть сегодня у тебя один сервер обрабатывает 1000 пользователей, завтра проект завирусился на миллионы, и ты за пару минут запускаешь десятки, сотни серверов.

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

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

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

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

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

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

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

Пример: классно наблюдать, как последние 3 года создатель важного фреймворка Ruby on Rails и культовой системы управления проектами Basecamp Дэвид Хейнемейер Ханссон (DHH) планомерно перевозит свои продукты с миллионами пользователей из облаков на собственные серверы.

Они объявили о планах выхода из Амазоновского облака AWS ещё в октябре 2022. На тот момент, они платили за Амазону 1,5 млн долларов в год! Для начала, они купили себе физических серверов на полмиллиона долларов (всего треть годового чека за облака!)

В июне 2023 объявили об успешном перевозе всех вычислений, а недавно купили специализированное железо для хранения данных и мае наконец перевезли хранилище файлов из AWS S3.

Другой яркий пример, с которым я сталкивался лично, — это стоимость трафика для медиа-проектов. Трафик в облаках для популярного медиа может стоить десятки тысяч долларов, и такой же объем можно обработать десятком арендованных серверов по 40 баксов каждый. Экономия в 100 раз. Но это всё имеет смысл только на масштабе. Так выпьем же за то, чтобы было на чем экономить!

Что отличает хорошие команды разработки от плохих?

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

Для меня в разработке важны два принципа, из которых можно вывести все остальное:

1. Заинтересованность в конечном результате. Способность и настроенность не «работу делать», а «получать результат, двигаться к результату». Не путать с горящими глазами! Восторженность не обязательна, но безразличие опасно.

2. Предсказуемость. Раньше я называл это «способность выполнять обещания», и это простой критерий, но как и любую формальную метрику его можно обмануть — например, не давать обещаний. И очень уж фонит трудным детством в казанских кварталах: «пацан слово дал» и вот это все. Предсказуемость включает в себя выполнение данных обещаний, но еще и прозрачность, проактивное обсуждение возникающих трудностей (а они точно будут), формирование реалистичных ожиданий.

А что для вас главное в разработке? Интересно, будут ли отличаться ответы разработчиков и продактов, бизнеса? Пишите пожалуйста в чатик @ctodailychat или в личку @samatg

Могут ли незрячие люди пользоваться смартфонами, компьютерами, интернетом?

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

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

Этот пост для того, чтобы побольше дизайнеров интерфейсов и программистов успели записаться на курс по доступности от Леры Курмак. С 6 февраля по 6 марта, 5 недель по выходным онлайн, 22тр. Лера шарит в теме и такая 🔥, что скучно точно не будет. Это — одна из супер редких реклам на этом канале, но она бесплатная и стоит того.