• JSON API – работаем по спецификации
    +1

    Да, это либо meta-информация, т.е. данные о данных.
    Либо можно указать ссылки на куски данных с этими фильтрами через links.


    Либо описать допустимые фильтры в документации к API.


    Ещё можно выдавать ошибку при использовании "неразрешённых" фильтров с указанием "разрешённых".

  • Docker для фронтендера. Часть 2. Что ты такое?
    +1

    Спасибо, что следите. :)


    В течение месяца будет.
    Я недавно провёл МК на РИТ++, сейчас подсоберу материал с подготовки к нему и сделаю третью часть.


    Что интересно, уже можно немного обновить первые две части. Например, Kitematic отлично заменяется на встроенный Docker Desktop Dashboard.

  • Мама, я теперь стример
    0

    Меня другое беспокоит. Говорят, слайды не нужны.
    https://youtu.be/HkuDzeBgAPs?t=914

  • Мама, я теперь стример
    0

    Вот примеры светильников для стрима:
    https://www.ozon.ru/context/detail/id/165823530/
    https://www.ozon.ru/context/detail/id/160481250/


    А вот топовая вебка, насколько, я слышал:
    https://www.logitech.com/ru-ru/product/brio


    Однако, даже с минимумом девайсов вполне можно жить.


  • The state of soft skills
    0

    Удивительно, что ответственность попала в "бесполезные навыки".
    Я именно по ней всегда определял профессиональный уровень разработчика.

  • Обзор видеоплееров для веба
    +1

    С ним всё ок. :)


    У нас тогда не работало несколько видеопотоков, и мы искали проблему. В том числе мы искали её и в плеере. hls.js пробовали как альтернативу и смотрели — заработает или нет. Оказалось, что проблема была в потоках, а оба решения (hls.js и videojs-contrib-hls) работают отлично.


    Я бы, наверное, взял hls.js отдельно, если бы мне нужно было сделать плеер, который просто хорошо показывает HLS, и без дополнительных наворотов.

  • Обзор видеоплееров для веба
    0

    Согласен, утверждение достаточно громкое получилось. Давайте считать, что это лично моя тройка финалистов.


    Посмотрел AblePlayer. Смутило, что он зависит от jQuery и не опубликован в NPM. Но, если он Вам подходит, то это отлично.


    Plyr, кстати, заявляет, что он accessible.

  • Обзор видеоплееров для веба
    0

    Спасибо за ссылки!


    Я пользовался поиском Гугла и собирал ссылки с обзоров и подборок, похожих на мою.


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

  • Обзор видеоплееров для веба
    0

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


    Был опыт использования его вместе с video.js через одну из интеграций. Мы тогда экспериментировали с форматами потоков и пробовали разные библиотеки для работы c HLS. Полёт нормальный.


    Но потом в итоге всё равно вернулись на то, что предоставляет video.js. Тогда это был videojs-contrib-hls, а сейчас новый videojs-http-streaming (VHS).

  • JSON API – работаем по спецификации
    0
    Они используются примерно для одной и той же цели и решают похожие проблемы
    Естественно, они похожи в чём-то. :)
  • JSON API – работаем по спецификации
    0
    Да, вы правы, в данной статье не освещены дополнительные операции над ресурсами.

    Могу сказать только, что в репозитории спецификации это обсуждалось вот тут. И продолжает обсуждаться в связанных issues (https://github.com/json-api/json-api/issues/745).
  • JSON API – работаем по спецификации
    0
    Спецификация не ограничивает вас 4-мя операциями.

    Does JSON:API take any position on URI structure, on rules for custom endpoints, which do not fit the paradigm of GET/POST/PATCH/DELETE on the resource URI, etc.?

    JSON:API has no requirements about URI structure, implementations are free to use whatever form they wish.

    jsonapi.org/faq/#position-uri-structure-custom-endpoints
  • Материалы с казанского митапа по фронтенду: Phoenix LiveView, фронтопс, JSON:API
    +3
    Спасибо за организацию! ИМХО, отличный локальный митап получился.
  • Пришло ли время забыть о React и перейти на Svelte?
    +8
    Сделали на Svelte несколько проектов. Впечатления самые приятные.

    Да, Svelte набирает популярность и он очень хорош, но есть ещё несколько графиков, которые показывают, что прекращать изучать React в данный момент не стоит.


    www.npmtrends.com/@angular/core-vs-react-vs-vue-vs-svelte
  • AvitoTech On Tour: митапы по Go и фронтенду в Казани
    +3
    До встречи на митапе! Буду рад выступить и пообщаться за JSON API. :)
  • Docker для фронтендера. Часть 2. Что ты такое?
    0
    Переходить на Mac совершенно не обязательно. Всё это верно и для Windows, и для Linux.
    Я выбрал для примеров Mac, т.к. сам сейчас им пользуюсь, и по моим наблюдениям, много фронтендеров тоже пользуются им.

    В первой части я как раз пытался ответить на вопрос «зачем?».
    Если вкратце, то я подобрал вот такие пункты:

    1. Быстро, без боли и в одну команду разворачиваем нужное окружение (API, БД, сервисы) на рабочем компьютере (Mac, Windows, Linux)
    2. Уменьшаем риск сломать хост-систему, ставя на компьютер абстрактную Java
    3. Сами готовим своё приложение к продакшену и отвечаем за его эксплуатацию
  • Docker для фронтендера. Часть 2. Что ты такое?
    0
    Отличный рецепт, спасибо!

    Могу посоветовать ещё посмотреть ещё в сторону Docker Compose.
    Он позволяет создать YAML-файл со всеми настройками и запускать связку контейнером одной командой

    Что-то вроде:

    # docker-compose.yml
    version: '3.7'
    services:
      db:
        ...
        ports:
          - 5432:5432
    
      app:
        ...
        volumes:
        - /Users/admin/Documents/WWW/:/home/www/
        - /Users/admin/Documents/WWW/virtual.conf:/etc/httpd/conf.d/virtual.conf
        - /Users/admin/Documents/WWW/15-xdebug.ini:/etc/php.d/15-xdebug.ini
        ports:
          - 80:80
    


    $ docker-compose up

  • Mail.ru запустит свой видеосервис по аналогии с YouTube в 2020 году
    0
    Только недавно сериал Холивар. История рунета. посмотрел, где обсуждался YouTube и попытки его контролировать. :) А тут и новость подоспела «к месту».

    www.currenttime.tv/a/loshak-o-runet-kholivar-film/30144134.html
    Но, безусловно, это будет 2019 год, это будет по большей части, насколько я сейчас себе представляю, история про ютуб, потому что ютуб – это, наверное, сейчас такая главная заруба, вокруг которой, мне кажется, будут ломаться копья, потому что непонятно, как его взять под контроль. Как взять под контроль Google, там еще не придумали.
  • Powered by NGINX
    0
  • Docker для фронтендера. Часть 1. Зачем?
    0
    Не уверен, но, думаю, можно попробовать сделать образ с SDK, который при старте инициализирует окружение.
  • Docker для фронтендера. Часть 1. Зачем?
    0
    Да, кстати, об это я не подумал. Хороший кейс.

    Локальное разворачивание позволяет развернуть у себя любую ветку API.

    Например, вот так:

    cd api
    git checkout feature/branch
    docker-compose build api
    make migrate
    docker-compose up api
    
  • Docker для фронтендера. Часть 1. Зачем?
    0
    Да, Вы правы. Плюс ещё примерно 4 ГБ на виртуалку на MacOS.

  • Docker для фронтендера. Часть 1. Зачем?
    0
    Отличное замечание, я про это не рассказал.

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

    Мы делаем вот так:

    1. docker-compose up api собирает связанные через depends_on образы и запускает их.
    2. Все команды на запущенных контейнерах стараемся убирать в Makefile.

    Что-то вроде:

    # Makefile
    migrate:
      docker-compose run api bundle exec rake db:migrate
    
  • Docker для фронтендера. Часть 1. Зачем?
    +2
    После доклада меня спрашивали несколько раз про этот подход, когда фронтенд-разработчик всё запускает не локально, а использует отдельный staging- или dev-сервер для разработки.

    Этот способ работает и имеет свои плюсы, но не лишен и недостатков.

    Вот некоторые из них:

    1. Невозможность работать офлайн или при плохом Интернете. Многие любят работать из дома, деревни или в дороге.
    2. Необходимость делить один и тот же ресурс с другими разработчиками и тестировщиками. У нас были случаи, когда приходилось создавать необходимую для разработки сущность новости с названием «НЕ УДАЛЯТЬ!», чтобы кто-то её случайно не грохнул. Но, всё равно это периодически случалось.
    3. Такой сервер достаточно хрупкий. Было несколько ситуаций, когда бекенд-разработчики или эскплуатация начинали шатать сервак. Или, к примеру, накатывали туда какие-нибудь ломающие изменения. Это останавливало разработку у всей команды.
  • Docker для фронтендера. Часть 1. Зачем?
    0
    Оно всё достаточно легковесное, в этом и прелесть Docker. Вот пример вывода docker stats.

    CONTAINER ID        NAME                                   MEM USAGE
    e4941ea92ce7        nginx_1                                3.16MiB
    1b023bfff38f        api_1                                  351.5MiB
    e07c6958e378        pg_1                                   18.64MiB
    1fa783f5fdbc        terminal-front_1                       14.89MiB
    72e9dfa0805a        adminer_1                              11.19MiB
    e9ce9f965867        admin-front_1                          1.312MiB
    3edacc59a77b        certbot_1                              1.547MiB
    

    Видим, что БД заняла 19 МБ, а API на Java — 352 МБ.

    У нас у разработчиков от 8 до 16 ГБ оперативной памяти. Обычно, этого хватает.

    По личному опыту, большую часть оперативной памяти во время разработки съедает IDE, Chrome, Telegram, Slack, а не запущенные docker-контейнеры.
  • GitHub переходит на GraphQL
    0
    Про REST полностью согласен. За эти два года я поумнел и лучше разобрался в теме. :)

    С сериализацией/десериализацией проблем особо не было никогда. Обыкновенная работа со структурами данных.

    Тут профит в том, что структура jsonapi-сущности документирована и исключает споры, тогда как «самых простых сериализаций» может быть несколько.
  • Конференции: начало пути
    +1
    Так вот почему всё время есть доклад про выгорание!
  • JSON API – работаем по спецификации
    0
    Эта задача в данный момент не описана в спецификации. Вот тут Вы можете почитать обсуждение и возможные решения этой проблемы.

    Мы используем загрузку файлов через Multipart.
  • JSON API – работаем по спецификации
    +2
    Сделай, спецификация JSON API это не запрещает. :) Она лишь говорит, что «если Вам нужны связи между представления, то вот так их можно сделать».
  • JSON API – работаем по спецификации
    0
    Нет никакой связи с БД.
    Relationships (считай join) связывает представления, которые могут быть получены откуда угодно.
  • JSON API – работаем по спецификации
    –1

    Stateless означает, что сервер не хранит никакого состояния о сессии клиента на стороне сервера.


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


    Это единственный способ масштабирования до миллионов одновременно работающих пользователей.


    Полее подробно с картинками описано в диссертации Роя Филдинга.

  • JSON API – работаем по спецификации
    0

    Да, конечно.
    REST — передача состояния представления.
    Естественно, представление может быть получено откуда угодно.

  • JSON API – работаем по спецификации
    0

    Это зависит от реализации сервера.
    RFC 3986 никак не определяет формат передачи массива через GET-параметры.


    В общем случае на сервер придёт строка вся query string.


    Если сервер разберёт её по аргументам, то, скорее всего, будет вот так:


    {
      'fields': 'title',
      'include': 'authors',
      'fields[author]': 'id,name'
    }

    Если игнорирование и будет, то только если оно специально так настроено.

  • JSON API – работаем по спецификации
    0

    http://springbot.github.io/json-api/extensions/bulk/#deleting-multiple-resources


    DELETE /articles
    Content-Type: application/vnd.api+json; ext=bulk
    Accept: application/vnd.api+json; ext=bulk
    
    {
      "data": [
        { "type": "articles", "id": "1" },
        { "type": "articles", "id": "2" }
      ]
    }

    Note: RFC 7231 specifies that a DELETE request may include a body, but that a server may reject the request. This spec defines the semantics of a server, and we are defining its semantics for JSON:API.
  • JSON API – работаем по спецификации
    0
    Спасибо за замечание. Согласен, слово «придумал» не очень корректно. Я имел ввиду, что он является одним из авторов.
  • JSON API – работаем по спецификации
    +1
    В докладе я говорю о том, что любое решение будет работать. Но вместо того, чтобы спорить по поводу правильных HTTP-кодов и названий полей, вроде isSuccess, лучше взять готовую спеку и начать делать то, что нужно заказчику.
  • JSON API – работаем по спецификации
    +1
    Не предлагается сразу всё запихивать. Большинство условий являются необязательными и просто иллюстрируют «как можно делать, если Вам нужно».
  • JSON API – работаем по спецификации
    –1
    Получается немного, да.
    Но я думаю, что при составлении спецификации решили, что в данном случае единообразие интерфейса и минимизация ошибок важнее избыточности.
  • JSON API – работаем по спецификации
    0
    В спеке есть про это, если я правильно понял Ваше замечание.
    Some clients, like IE8, lack support for HTTP’s PATCH method. API servers that wish to support these clients are recommended to treat POST requests as PATCH requests if the client includes the X-HTTP-Method-Override: PATCH header. This allows clients that lack PATCH support to have their update requests honored, simply by adding the header.
    jsonapi.org/recommendations/#patchless-clients

    На вопрос тоже нашёл ответ в спеке:
    Note: The above example URI shows unencoded [ and ] characters simply for readability. In practice, these characters must be percent-encoded, per the requirements in RFC 3986.
    jsonapi.org/format/#fetching-sparse-fieldsets
  • JSON API – работаем по спецификации
    0
    Про RPC было в ранней версии доклада, но пришлось убрать, чтобы уложиться в полчаса и донести мысль не очень скомкано. :)

    Остались только ссылки в конце презентации на спецификации XML-RPC и JSON-RPC для дальнейшего изучения.