Все сервисы Хабра

Сообщество IT-специалистов

Ответы на любые вопросы об IT

Профессиональное развитие в IT

Удаленная работа для IT-специалистов

Войти на сайт
  • Все вопросы
  • Все теги
  • Пользователи

Хабр Q&A — вопросы и ответы для IT-специалистов

Получайте ответы на вопросы по любой теме из области IT от специалистов в этой теме.

Узнать больше
другие проекты хабра
  • Хабр
  • Карьера
  • Фриланс
Задать вопрос

Олег Правдин

  • 14
    вклад
  • 30
    вопросов
  • 21
    ответ
  • 57%
    решений
Лайки
  • Информация
  • Ответы
  • Вопросы
  • Комментарии
  • Подписки
  • Нравится
  • Достижения
  • Как правильно разделить компонент, хранилище и API запросы?

    Kozack
    Alex @Kozack Куратор тега Vue.js
    Thinking about a11y
    1. Достаточно ли зависит от вашего случая. Скажем, есть вероятность, что нужно будет изменить один сервер АПИ на друго? Или в принципе изменить схему АПИ?
    2. Что касается глобальных данных. Тут может быть по разному. Я придерживаюсь следующего подхода: каждый компонент должен сам загружать нужные ему данные. А во Vuex хранить поменьше. Тут нет какой-то четкой границы. Например можно вынести все операции по работа с апи во Vuex и использовать его как хранилище кэша. Но нужно ли? Не лучше ли сделать кэширование честью модуля по обращению к апи? Или, например, вам нужно хранить историю последних действий пользователя. Для этого, например, можно использовать IndexedDB API.
    3. Как по мне, то в том месте, где выполняется обращение. То есть, компонент, который запрашивает какие-то данные (сквозь сколько угодно абстракций), должен получать либо данные либо отчет об ошибке и сам решать как его обработать.
    Ответ написан 14 сент. 2020
    1 комментарий
    Нравится 1 1 комментарий
  • Как правильно разделить компонент, хранилище и API запросы?

    delphinpro
    Сергей delphinpro @delphinpro
    frontend developer
    2. Мнение обратное Alex :
    Я наоборот, предпочитаю все данные хранить в сторе. В компонентах только локальные переменные.
    Все запросы к API расположены в экшенах и соответственно данные сразу кладутся в стор.
    Обращение к стору только через геттеры. В компонент мапятся необходимые экшены и геттеры.

    3. Перехват ошибок удобно делать в перехватчиках (interceptors) Axios. Конфигурируем опцию validateStatus нужным образом и ловим все в одном месте.
    Ответ написан 14 сент. 2020
    2 комментария
    Нравится 2 2 комментария
  • Как недорого доставлять обновления игры и ее файлы если CDN просят от 3000 за ТБ?

    fzfx
    vreitech @fzfx
    18,5 дм
    bittorrent.
    Ответ написан более года назад
    7 комментариев
    Нравится 9 7 комментариев
  • Почему мне кажется, что Python быстрее C?

    wisgest
    wisgest @wisgest
    Не ИТ-специалист. Рабочий. Шизоидный психопат.
    Здесь узким местом является функция printf() и дело не только в выводе в консоль или куда-то ещё, но и в разборе строки форматов при каждом повторении и в преобразовании числа в строку.
    Ответ написан более года назад
    Комментировать
    Нравится 6 Комментировать
  • Что если в ручную поменять формат изображения, без конвертирования (из jpg в png)?

    Sanasol
    Александр Аксентьев @Sanasol Куратор тега Веб-разработка
    нельзя просто так взять и загуглить ошибку
    Будут, потому что они смотрят на заголовки внутри, а не на название файла.

    Только формат файла от этого и не поменяется, это будет jpg который обозван как png.
    Ответ написан более года назад
    2 комментария
    Нравится 5 2 комментария
  • В PHP канонично сначала проверить, потом сделать или попробовать и обработать ошибку?

    solotony
    Antonio Solo @solotony
    ушел пить чай %)
    первый случай это не обработка ошибки, а обработка ситуации "отсутствия файла" - например предлагается создать новый, спросить имя, выбрать путь и т.д.

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

    второй случай - это именно обработка ОШИБКИ.

    ---

    резюме: если цель открыть заведомо существующий файл, то 2-й способ "каноничнее".
    Ответ написан более года назад
    Комментировать
    Нравится 1 Комментировать
  • В PHP канонично сначала проверить, потом сделать или попробовать и обработать ошибку?

    profesor08
    profesor08 @profesor08
    Вариант 1 - ненужный, так как Вариант 2 обработает все. Более того, Вариант 1 гарантирует лишь то, что код условия не выполнится только тогда, когда файла, на момент проверки, нет и не было. Но может случиться так, что в период между проверкой и чтением файла, файл будет удален, или кеш не обновился, и тогда ты обломаешься со своей проверкой.
    Ответ написан более года назад
    Комментировать
    Нравится 1 Комментировать
  • В PHP канонично сначала проверить, потом сделать или попробовать и обработать ошибку?

    Minifets
    Александр @Minifets
    Hello world!!!
    Очень хорошие рассуждения, только вот они не учли один факт. Функции в php, которые работают с файлами не бросают Exception, а только Warning (да-да, при небольших модификациях можно из Warning сделать Exception).

    Поэтому в php канонично, если в функции/методе есть throw - ее нужно обернуть в try - catch, а если функция позвращает true/false, то использовать if.

    Ну и дополню, есть в функции есть throw, то проверки if, которые обходят этот throw, по своей сути - дублирование кода.
    Ответ написан более года назад
    Комментировать
    Нравится 2 Комментировать
  • Как передать компонент из родительского дочернему?

    MrGrump
    Mr. Grump @MrGrump
    Используйте систему слотов:

    В компоненте таблицы:
    ...
    <tr v-for="row in rows">
      <td v-for="header in headers">
        <slot :name="`cel_${header.key}`" :row="row"> {{ row[header.key] }} </slot>
      </td>
    </tr>
    ...


    Использование компонента таблицы:
    ...
    <table-component :rows="users" :headers="headers">
      <template slot="cel_full_name" slot-scope="props">
        <router-link :to="`/user/${props.row.id}`">{{ props.row.full_name }}</router-link>
      </template>
    </table-component>
    ...
    Ответ написан более года назад
    Комментировать
    Нравится 1 Комментировать
  • В PHP канонично сначала проверить, потом сделать или попробовать и обработать ошибку?

    FanatPHP
    FanatPHP @FanatPHP
    Чебуратор тега PHP
    Очень хороший вопрос и тема, в которой самое чудовищное количество самых дремучих северий на единицу кода.

    В общем случае, по умолчанию, никаких проверок и траев с кетчами быть не должно.

    Я понимаю, что это звучит богохульством для среднего пользователя похапе, но в реальности программы пишутся совсем по-другому.

    Пример: В обоих приведенных выше случаях мы имеем масло масляное: попытка подменить пхп в выборосе ошибки. Вопрос - зачем? Если файл не найден, то РНР сам прекрасно сообщит нам об ошибке, причем в подробностях, и скажет в чем конкретно заключается проблема. А по строчке "file not found" иди гадай - путь ли кривой или в имени файла опечатка, или вообще пустоту передали.

    Любые проверки надо делать только тогда, когда есть осмысленный сценарий их обработки.

    И обсуждать выше приведенные примеры имеет смысл только если автор вопроса предоставит такой сценарий. тупое error: file not found таким сценарием не является. Так что в общем случае оставляем код в покое и не устраиваем никакого карго культа из перехвата ошибок.

    Если чисто выбирать между двумя действиями (проверка и чтение) и одним (сразу читаем, потом ловим исключение),

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

    Но повторюсь, если нет никакого осмысленного сценария обработки ошибки, то ловить её не надо.
    Ответ написан более года назад
    6 комментариев
    Нравится 16 6 комментариев
  • В PHP канонично сначала проверить, потом сделать или попробовать и обработать ошибку?

    sergiks
    Сергей Соколов @sergiks Куратор тега PHP
    ♬♬
    В таком примере, как вы привели, if() проверяет только условие существования файла или директории. А try-catch обработает бОльшее число ситуаций: если это не файл, а директория, если права не позволяют читать, если устройство гакнулось и не прочиталось.
    пример автора вопроса
    # Вариант 1:
    f getFileContent(filename){
      if (!file_exists(filename)) {error: file not found}
      return file_content(filename)
    }
    
    # Вариант 2:
    f getFileContent(filename){
      try return file_content(filename)
      catch FileNotFoundException {error: file not found}
    }


    По замыслу if отличается тем, что проверяет предусмотренные варианты, а исключения кидаются в непредусмотренных. Все бросаемые исключения надо документировать, чтобы их кто-то где-то, в итоге, поймал.

    Условные операторы только для локальной логики внутри функции. Отлов исключений может иметь многоуровневую иерархию вне функции, класса. Например, случай не файла-а-папки отловится в одном, а случай нечитаемого сломанного устройства – на самом верхнем уровне всего приложения. И по-разному будут обработаны.

    Внешние материалы по теме:
    1. Пост по теме (на англ.)
    2. скорость выполнения с исключениями и без (без быстрее)
    3. Exception patterns, в частности:
      • Use Exceptions Instead Of Error Values
      • Don't Use Exceptions For Flow Control
      • Avoid Exceptions Whenever Possible
      • Code Without Exceptions


    Ответ написан более года назад
    6 комментариев
    Нравится 7 6 комментариев
  • Зачем нужен link preload, и что хочет от меня pagespeed?

    alexey-m-ukolov
    Алексей Уколов @alexey-m-ukolov Куратор тега JavaScript
    Что я делаю не так?
    Нужно добавить <link rel="preload" />, а не заменить ими ваши скрипты.
    Ответ написан более года назад
    Комментировать
    Нравится 4 Комментировать
  • Выбор программы для учёта финансов?

    krosh @krosh
    https://zenmoney.ru/
    Лучше всех.
    Ответ написан более трёх лет назад
    Комментировать
    Нравится 1 Комментировать
  • Какие есть практики интеграции статического сайта и динамического веб-приложения?

    Robur
    Robur @Robur
    Знаю больше чем это необходимо
    разделяете в голове одно от другого отдельно статика (html/js/ картинки, вот это все что лежит просто в файлах в том же виде в котором их получит клиент), отдельно HTTP api.
    Дальше ответы на большинство ваших вопросов приходят сами. в целом - как угодно, в зависимости от ваших условий, желаний и предпочтений.

    Можно статику отдавать по одному имени, а апи по другому. app.mydomain.com и api.mydomain.com
    или и то и другое по одному имени, но для апи будет отдельный путь /api например или и для апи и для статики будут разные пути mydomain.com/app и mydomain.com/api
    или на разные порты
    Можно разделение сделать на nginx/apache. А можно на уровне вашего бекенда.
    А можно статику вообще положить в облако и пусть они там думают про все. А бекенд положить в какие-нибудь контейнеры. Или вообще на serverless технологиях и вообще не знать где этот ваш код запускается и как к нему запросы идут, достаточно знать только урл.

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

    Но самый обычный способ - статика на один урл, апишка на другой.
    Ответ написан более года назад
    Комментировать
    Нравится 1 Комментировать
  • Какие технологии помогут сделать безопасный канал передачи данных?

    CityCat4
    CityCat4 @CityCat4 Куратор тега Информационная безопасность
    Если я чешу в затылке - не беда!
    Соединение поддерживается лишь на время передачи данных

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

    Это работа прикладного уровня

    А что касается остального - Вы говорите про IPSec, совершенно однозначно :) Не знаю, правда, как насчет ресурса микроконтроллера.
    Ответ написан более года назад
    6 комментариев
    Нравится 2 6 комментариев
  • Какие технологии помогут сделать безопасный канал передачи данных?

    athacker
    athacker @athacker
    Для этого используется TLS. Это спец-протокол, который решает все вопросы, которые вы хотите решить. Там есть возможность шифрования, взаимной аутентификации как клиента, так и сервера и всё такое. Минусы -- вычислительно сложно. Т. е. на слабых микроконтроллерах процесс установления TLS-сессии может занимать время, плюс расход батарей. Плюсы -- уже есть готовые либы под множество платформ/архитектур, которые можно использовать, чтобы не изобретать велосипеды и не писать своё.

    Гарантия от replay attack достигается тем, что для передачи команды сторонам нужно аутентифицироваться, т. е. это всегда двусторонний обмен. Технически сначала стороны обмениваются сертификатами, проверяют их, затем на основании алгоритма Диффи-Хэллмана формируют симметричный ключ шифрования, который будет использоваться для шифрования потока данных. В общем случае, в каждой сессии этот ключ будет разным. Есть механизмы кэширования и сохранения стейта, для ускорения установления TLS-сессии (допустим, на случай если клиент недавно уже подключался) -- это нужно, чтобы увеличить скорость согласования TLS-соединения), но это всё опционально и отключабельно.

    Внутрь TLS можно засунуть что угодно -- кастомный бинарный протокол на базе TCP/IP или REST API на базе HTTP -- без разницы.
    Ответ написан более года назад
    Комментировать
    Нравится 1 Комментировать
  • Какие технологии помогут сделать безопасный канал передачи данных?

    xmoonlight
    xmoonlight @xmoonlight
    https://sitecoder.blogspot.com
    Банально:
    Добавляйте подпись к запросу с временем и случайным набором символов.
    На стороне устройства - запрещайте повторные запросы лет на 10.
    Итог: даже зная что Вы отправили, нельзя это никак использовать.

    Хотите зашифровать само "тело" запроса (чтобы не читали) - шифруйте любым способом (главное при этом - не используйте TOKEN сеанса для шифрования!).
    Здесь подробно.
    Ответ написан более года назад
    Комментировать
    Нравится 1 Комментировать
  • Как получить уникальные значения JSON массива из ячейки MySQL?

    FanatPHP
    FanatPHP @FanatPHP
    Чебуратор тега PHP
    Не надо хранить в базе данных " массивы значений в JSON'е".
    MySQL - реляционная датабаза. Это означает, что база данных строится из связанных таблиц.
    И вместо колонки values должна быть отдельная таблица,
    table_id | value
    1 | 1
    1 | 2
    1 | 3
    2 | 2
    2 | 3
    2 | 4

    И тогда все выборки будут делаться примитивными SQL запросами, без малейших затруднений со стороны разработчика.
    Ответ написан более года назад
    6 комментариев
    Нравится 2 6 комментариев
  • Как получить уникальные значения JSON массива из ячейки MySQL?

    BojackHorseman
    Лентюй @BojackHorseman Куратор тега MySQL
    ...в творческом отпуске...
    json-типы в субд такая же бестолковая дань моде как и nosql-хранилища, которые пытаются обойти необходимость нормализации для снижения порога вхождения. в данном случае, слепое следование этой моде привело к печальным последствиям.

    но если все совсем плохо, то можно почитать про Secondary Indexes and Generated Columns
    Ответ написан более года назад
    6 комментариев
    Нравится 1 6 комментариев
  • Какому языку, в какой среде начинать учить ребенка программированию 10 лет?

    zkelo
    Александр @zkelo
    10 лет это 3 класс

    Отстаньте лучше от ребёнка. Ему всего лишь 10 лет - какое программирование? Пусть он сначала насладится детством. А уже после - сам начнёт ковыряться в том, что ему понравится
    Ответ написан более года назад
    8 комментариев
    Нравится 47 8 комментариев
Оценили как «Нравится»
  • 1
  • 2
  • 3
  • Следующие →
Самые активные сегодня
  • w3bsmes
    Alice
    • 24 ответа
    • 0 вопросов
  • Василий Банников
    • 9 ответов
    • 0 вопросов
  • saboteur_kiev
    Saboteur
    • 7 ответов
    • 0 вопросов
  • tumbler
    Сергей Тихонов
    • 7 ответов
    • 0 вопросов
  • IgorVader
    IgorVader
    • 6 ответов
    • 0 вопросов
  • Jump
    АртемЪ
    • 6 ответов
    • 0 вопросов
  • © Habr
  • О сервисе
  • Обратная связь
  • Блог

Войдите на сайт

Чтобы задать вопрос и получить на него квалифицированный ответ.
Войти через центр авторизации