Для передачи данных по сети есть хорошо зарекомендовавшие себя стандарты - например, SOAP, gRPC, AMQP, REST, GraphQL.

При создании вебсайтов малой, средней и большой сложности с потоками данных к бэкенду и обратно в JSON формате обычно используются последние два с их вариантами. Верней, только варианты, потому что REST и GraphQL - ресурсо-ориентированные стандарты. Это как бы просто перенос элементарной работы с базой данных на клиента (хотя под "ресурсом" может пониматься и абстракция). Обычно таких запросов не больше трети от всего бэкенд API.

Попытка сделать весь API максимально RESTful страшно раздувает код и грузит сеть. Потому что остальные две трети запросов - в форме команд на бэкенд проделать какие-то действия, слабо отображающиеся на CRUD над некими ресурсами. И вариантов послать такие запросы достаточно много. Даже, чересчур.

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

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

Я некоторое время разрабатывал спортсбуки, а также их врагов (парсеры, сканеры, боты для ставок) и решил поделиться опытом.

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

Спортсбуки должны использоваться только легально.

Во время "самоизоляции" подумалось получить пару сертификатов. Посмотрел на одну из сертификаций AWS. Материала для подготовки очень много — видео, спецификации, how-to. Очень времязатратно. Но ведь самое эффективное при сдаче экзаменов, основанных на тестах — просто решать экзаменационные или похожие на них вопросы.

Поиск навел на несколько источников, предлагающих такую услугу, но все они оказались неудобные. Захотелось написать свою систему — удобную и эффективную. Об этом и ниже.

Данная статья является логическим продолжением этой статьи на Хабре о выдаче регистратором Р01 моих персональных данных третьему лицу. Пришлось дожидаться, пока закончатся суды (частично), чтобы описать, кому было интересно запросить мои персональные данные у доменного регистратора Р01 и зачем.

История простая — требование компенсации за нарушение авторских прав на изображения, но со своими забавными нюансами.

Ниже по тексту — как не надо зарабатывать на фотографиях. Пример, как надо — в спойлерах (16+)

Уроки, полученные от написания следующей основной версии Vue.js

Автор: Эван Ю (Evan You)

В течение прошлого года команда Vue работала над следующей основной (major) версией Vue.js, которую мы надеемся выпустить в первой половине 2020 года (эта работа продолжается на момент написания данной статьи). Идея новой основной версии Vue сформировалась в конце 2018 года, когда кодовой базе Vue 2 было около двух с половиной лет. Это может показаться не таким уж долгим периодом в жизни программного обеспечения, но идеи фронт-энда сильно изменились за этот период.

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

После регистрации домена в зоне .ru собственник-физическое лицо, проверяя его на whois сервисе, видит запись: 'person: Private Person', и на душе становится тепло и надежно. Private — это звучит серьезно.

Оказывается, эта защищенность иллюзорна — по крайней мере, когда дело касается третьего по величине в России регистратора доменных имен ООО "Регистратор Р01". И твои личные данные у него очень легко может узнать абсолютно любой человек.

В статье "Contemporary Front-end Architectures" рассмотрены архитектуры фронт-энда с точки зрения потоков данных в исторической ретроспективе.

Материал состоит из трех частей

1. Теория и история
2. Реализация

3. Перспективы