api

Хорошая полемическая статья (aka trolling) на на тему «чем плох REST».

1. Переводить сложные операции на язык, в котором всего 4 глагола - то ещё развлечение.
2. В парадигме REST неестественно передавать изменения машины состояний, а это часто необходимо и ошибки на этом фронте могут быть фатальны.
3. Коммуникация ошибок и других особых состояний: «всегда HTTP 200 OK, а ошибка в теле» или придумаем свои коды?

https://medium.com/@pakaldebonchamp/rest-is-the-new-soap-97ff6c09896d

Мой вывод: парадигмы, правила и концепции - это наши рабочие инструменты. Не человек и дела для инструментов, но наоборот. Каждой задаче - свой инструмент. Черт, кажется это просится в инстаграм глубокомысленные цитаты. Сорян.

Amazon запустил API для стриминга, теперь можно сделать свой твитч за вечер. Правда, если он станет популярным — то вы быстро разоритесь; судя по рассчетам, стоимость одного популярного стрима — 30 тысяч долларов в день. Если зрителей немного — то это очень классное API. Когда же Amazon запустит API «сделать классно»?

Вчера мне пришло удивительное письмо:

Мой друг в составе команды исследователей шельфа северного ледовитого океана сейчас «болтается» в **, чуть западнее острова N на корабле Z. В море им быть ещё минимум два месяца. Говорит, без новостей с большей земли пухнет голова. У них есть интернет, через спутниковый телефон, но канал очень узкий. Если это не сложно для вашего технического отдела, не могли бы организовать отправку дайжеста новостей на электронную почту текстом в архиве на электронную почту xxx@xxx.ru размером письма не более 100 кБ?

Письма Вечерней Медузы за последнюю неделю весят в среднем 50-70KB. Львиная доля объема — код, что позволяет выглядеть письмам одинаково во всех почтовых клиентах; это почище кроссбраузерной верстки.

Давайте попробуем убрать всю красоту и оставим только текст и минимальные выделения. Текст ниже — для компьютерщиков. TL;DR: «вот так, с помощью нехитрых приспособлений...»

Откуда мы будем получать событие об отправке письма? Подойдет webhook в mailchimp, через который мы рассылаем вечерку. Настроим простенькое приложение webhook, которое будет ждать события, а при его получении — запускать нашу программу.

Что в самой программе? Зная ID почтовой рассылки мы можем через API мейлчимпа получить тело письма. Но оно не особо красивое и вычищать его не хочется. Как насчет API Медузы? И вправду, в plaintext версии письма последняя ссылка — всегда на это же письмо на сайте. Например, вот вчерашнее письмо https://meduza.io/brief/2017/09/05/vechernyaya-meduza.

Добавляем `api/v3/` в адрес новости после имени сервера и получаем адрес API https://meduza.io/api/v3/brief/2017/09/05/vechernyaya-meduza. Тут уж есть поля .root.mail.subject и body, которые содержат тему и тело письма, без лишних стилей. Отлично, вычленяем нужные поля с помощью утилиты парсинга json jq и схлопываем их вместе в готовый email.html файл утилитой cat.

Как отправить получившееся письмо? У сервиса отправки писем Amazon Simple Email Service есть отличный SMTP-интерфейс и я как раз недавно нашел программу sendemail (не путать с sendmail, которая позволяет отправлять письма через SMTP из командой строки.

Теперь исследователь севера каждый вечер будет получать «высушенную» версию Вечерней Медузы весом всего 15КБ.

А вы можете подписаться на красивую, сверстанную с любовью Вечерку в почте или в телеграм-канале @meduzaevening и узнавать новостную повестку дня за пару минут.

Google обновил в ноябре Firebase Cloud Messaging — одну из самых крутых систем для рассылки пуш-уведомлений в мобильные приложения и браузеры (при этом — бесплатную!).

В новой версии API можно в едином сообщении указать два разных payload; клиент получит свою версию в зависимости от платформы — iOS или Android. Ура! Ложка дёгтя: авторизация теперь богопротивным Oauth2 JWT.

P.S. Документация у Firebase — тихий ужас :(
P.P.S. Никогда не собирайте тестовые приложения с продакшен-ключами. Я сегодня таким макаром отправил в продакшен iOS Медузы тестовый пуш. Слава богу, не в канал «breaking». Слава богу, что тексты тестовых пуши — копии недавних легитимных, а не «тестовый пуш, йоу» или «alert('fuck')». Храни вас бог при тестировании пушей и почтовых рассылок. Аминь.

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

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

1. При попытке заплатить, наш сайт редиректит пользователя на страницу эквайринга с параметрами;

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

3. После успешного перевода, эквайринг редиректит человека на наш колбек URL, мы идем на бэк эквайринга, убеждаемся что всё ок и предоставляем услугу.

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

Некоторые провайдеры позволяют выводить доходы на обычный банковский счет, в этом случае действуют все стандартные процедуры KYC/AML.

Я нашел двух русских провайдеров и двух зарубежных:

1. CryptoCloud — судя по документации, самые большие и взрослые русские;

2. Bitbanker — тут моя сестренка работала, хорошая техподдержка; API;

Регистрация у обоих буквально в два клика, через имейл и телегу, никаких KYC AML. Рано или поздно это прикроют, но пока можно пользоваться.

Зарубежные сервисы:

3. Coinbase Commerce — эквайринг от одного из главных криптовалютных сервисов, самые красивые, API;

4. AdvCash Merchants — сервис формально из Белиза, но активный в СНГ, API.

Имейте в виду, что в России по закону платежи в крипте принимать запрещено.

Upd: дорогой Владислав накидал в чате типовых криптоэквайреров: whitepay, binance pay, b2binpay, coingate. Учтите, что у них всех KYC/AML как у взрослых.

Извините, начну с философии, прочитал вчера вечером и никак из головы не идет.

Компания AT&T (основанная в 1880 изобретателем телефона Александром Бэллом), с 1910-х владела почти всей телефонной сетью в Штатах. Мало того, она владела практически всеми телефонами в Соединенных Штатах. Надпись «собственность Bell - не для продажи» наносилась на корпус устройства прямо на заводе. Бюджет на исследования у Bell Labs был практически неограниченный, там работали лучшие ученые, а прибыли компании были фантастическими.

Ничего не напоминает?

Компании Facebook (Instagram, Whatsapp, etc.) и Google (Gmail, Youtube, Gmaps, Waze, etc.) владеют почти всеми личными данными на планете. Мало того, они запрещают подключать к своему API неофициальные программы, в которых, например, не будет рекламы или которые покажут ленту новостей по другому алгоритму.

В первом абзаце я рассказал только начало истории Bell. После войны произошли два важных события (немецкие магнаты считались одной из причин прихода Гитлера к власти): 1) Государственное решение о картерфонах, после которого стало можно подключать к телефонной сети любые устройства (а не только разрешенные Bell). Благодаря этому закону появились факсы, автоответчики и модемы. 2) В 1974 правительство подало в суд из-за нарушений антимонопольного законодательства и в 1984 компания согласилась разломаться на 8 частей (независимые региональные операторы и отдельно магистраль).

Монополию и её негативное влияние сложно оценить, когда пользователь ни за что не платит; прекрасные Google Maps и отличный Youtube достаются всем жителям земли без денежной оплаты. Но легко представить миллион конкурентов фейсбуку, которые появятся за пару месяцев, если Штаты отменят закон, по которому запрещается использовать данные сайта-источника, если он против. Показательно дело Craiglist v. 3Taps. 3Taps сделали хороший сервис на основе объявлений крейглиста (американский аналог авито) и крейглист замочил их в суде вместо того, чтобы сделать свой сайт лучше. Было ли это в интересах потребителей?

Сейчас GDPR заставляет сервисы предоставить статичную выгрузку данных пользователей по запросу в течении 30 дней. Я верю, человечество дорастет до того, что личная информация пользователей и её производные будут доступны в машиночитаемом формате по API по закону. Понятно, что сервис-первоисточник будет иметь право на «разумную плату», но это будет принципиально отличаться от текущего положения дел. Сегодня нет альтернативных приложений для просмотра фоточек в фейсбуке не потому, что их сложно сделать или у людей нет идей. ФБ запрещает это с помощью юристов.

Интересно, что история повторяется. Сейчас AT&T скупила обратно 11 региональных отделений из 22; политики не чувствую нужды бороться с вертикально интегрированными цифровыми гигантами. Но именно цикличность истории оставляет надежду.

Вдохновлено отличной статьей на Los Angeles Review of Books и обсуждением на HN.

В новом эпизоде подкаста — истории двух парней, которые разобрались в АПИ клабхауса.

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

Я узнаю подробности взломов у Димы и Саши и разъясняю устройство хакерских атак редактору подкаста, Юле Яковлевой.

Слушайте и подписывайтесь: Apple, веб-версия, Google, Castbox, Яндекс, Spotify, Overcast.

Картинка по запросу «хакер в интернете».

Перевёл сегодня интерфейс одного проекта с одного языка на другой с помощью Google Cloud Translation API.

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

Я попробовал несколько разных систем машинного перевода для этой задачи, самая хорошая - Google Translate. Она даже теги span и переменные в фигурных скобках не корёжит, переводит только тексты. Учитывая бесплатные полмиллиона символов перевода - даже с настройкой биллинга не придётся заморачиваться, скорее всего. Регистрируетесь в Google Cloud Platform, пишете небольшой питоновский скрипт и вперёд. Можете взять мой за основу.

Конечно, локализация (l10n) и интернационализация (i18n) проекта (разница между ними) — гораздо больше, чем просто перевод; а даже организация перевода для большого проекта с несколькими переводчиками — то ещё развлечение. Но это тема для гораздо более длинного поста.