Задать вопрос
  • Подключение кулера к адаптеру 12 вольт. Не сгорит?

    @nehrung
    Не забывайте кликать кнопку "Отметить решением"!
    Из комментариев видно, что вам непонятен практический смысл терминов "напряжение" и "ток". В этом случае разобраться помогает сравнение с потоком воды. Напряжение - это аналог давления, или разницы уровней выше-ниже плотины. А ток - аналог расхода воды (не зря созвучен слову "поток"). Если кран закрыт (выключатель выключен, цепь разомкнута) то какое бы ни было напряжение/давление, (по)тока не будет.
    Теперь с вашим примером. Есть адаптер 12 в, 0,5 а. Включаем его - на выходе 12 вольт, и никакого тока, хотя на нём написано 0,5 а - ещё не создан путь для потока. Подключаем кулер - пошёл такой ток, который затребовал кулер, т.е. 0,18 а, и не больше (поток течёт по размеру дырочки, которую ему открыли). Остальные 0,32 ампера пока не востребованы. Подключаем ещё один такой же кулер - ток возрос до 0,36 а (два потока по 0,18). Поскольку адаптер может обеспечить 0,5, всё нормально. Но если подключим ещё один такой же кулер, суммарный ток возрастет до 0,54 а, что больше допустимого для адаптера - он будет перегружен, от него требуют невозможного. Если через плотину перельётся поток больше, чем может прийти по реке, то поскольку вода ушла, верхний уровень над плотиной понизится. Аналогично при перегрузке по току выходное напряжение адаптера понизится и уже будет менее 12 вольт. Если защиты от перегрузки в схеме адаптера не предусмотрено, он просто перегреется и может сгореть. Если защита предусмотрена, то при перегрузке она сработает, адаптер отключится, выходной ток исчезнет.
    если врубаем напрямую, то нужно ли еще какой элемент в цепи, чтобы обезопасить сию конструкцию?

    Если встроенной защиты от перегрузки нет, то обычно последовательно в цепь включают такой элемент, как плавкий предохранитель. Сгорая сам, он защищает от повреждения остальную схему, гораздо более дорогую. В вашем случае полезно последовательно с выходной цепью адаптера включить предохранитель на 0,5 а. Но реальный ток сгорания у дешёвых плавких предохранителей не точен и может быть в пределах -30%... +80%. Так что не удивляйтесь, если увидите, что такой предохранитель сгорит при подключении всего двух кулеров или не сгорит вообще, когда уже весь адаптер будет в дыму.
    Ответ написан
    4 комментария
  • Контроль доступа в symfony, не совсем понимаю тебя?

    @Flying
    Symfony - это в первую очередь framework для обработки HTTP запросов и поэтому многие компоненты по-умолчанию "заточены" именно под этот сценарий.

    В конечном итоге вся Symfony Security построена вокруг понятия "токена" (TokenInterface) и большинство частей Security компонента достаточно абстрактны для того чтобы из них можно было собрать весьма разнообразные схемы разделения прав доступа.

    Вам необходимо определить для себя что означает "привязка привилегии к функционалу" с точки зрения кода приложения. Вы планируете оставить это разделение прав доступа на уровне "пускать / не пускать по определённому route" или вы будете в сервисах приложения вызывать что-то подобное Security::isAllowed()? Symfony по-умолчанию реализует первый подход, но ничто не мешает вам организовать собственную реализацию основных компонентов. Если вам нужен ACL (а именно так называется "привязка привилегии к функционалу") - то эта функциональность вынесена в отдельный ACL bundle в Symfony 4, скорее всего именно она вам и нужна.

    По поводу связки role = privilegy - нет, в общем случае это не так. Необходимо разделять процессы аутентификации (в результате которого подтверждается валидность пользователя и определяются его роли) и авторизации (в результате которого определяется может ли аутентифицированный пользователь получить доступ к тому или иному ресурсу).

    Если говорить о работе Symfony Security в контексте обработки HTTP запроса - то аутентификация производится в процессе прохождения запроса через т.н. firewalls, их задача - каким-либо образом определить что это за пользователь и сформировать token. Процесс авторизации построен вокруг т.н. voters которые "голосуют" за/против/воздержался по вопросу "пускать/не пускать", в документации есть целый ряд примеров. Надеюсь факт того что voters могут быть произвольными и иметь любую собственную логику - довольно очевиден. К примеру тот же ACL bundle как раз реализует voter который принимает решение о доступе на основе ACL list'а (который, конечно же, может находиться и в базе данных), но в целом это частный случай.
    Ответ написан
    1 комментарий
  • Как локально получить голос в asterisk?

    Francyz
    @Francyz
    Photographer & SysAdmin
    Покупаете микрофон за 300р и ставите на ПК какую нибудь IP звонилку (aka софтфон) и подключаете ее к вашему астериску.
    Ответ написан
    2 комментария
  • Абстракция в JavaScript?

    @TimurBaiguzhaev
    Backend Golang Developer
    Помните, как родители заставляли вас играть на фортепиано или учить стихи?.. Так вот, Абстрактные классы также как и многие родители вовсе и знать не знают зачем ребенку-потомку это будет нужно, и как он это будет использовать, но уверены, что так НАДО! Т.е. такие классы содержат абстрактные методы, которые являют собой объявление метода без самой реализации, как фантик без конфетки, тем самым обязывая потомка, этот метод реализовать. Как и в жизни, где родители нередко перекладывают на детей свои нереализованные мечты…

    Вот в такой шутливо-серьезной форме, мы затронули тему абстрактных классов и семейных отношений, как способ понять… и то и другое?.. А если серьезно, то разумеется, в программировании не должно быть случайных методов, и любые методы и свойства являются частью продуманной иерархии классов, которая как генеалогическое дерево, может давать возможности расширять функционал от поколения к поколению. А абстрактные классы, и еще более абстрактные – интерфейсы ( interface — вообще не содержит реализаций ), помогают программисту не потерять, не забыть реализовать общие необходимые для всех потомков умения в жизни, без которых особь умрет, а с ней и приложение.


    Источник : habrahabr.ru

    Abstract classes in JavaScript
    Ответ написан
    Комментировать
  • Как писать тесты?

    nonlux
    @nonlux
    Ну тесты бываю разными: и зелеными и красными. ))

    Все зависит от уровня абстракции, который хочется протестировать. Поэтому тесты и делятся на всяческие классификации. Например: юнит (модульные) тесты, интеграционные тесты и т.д. и т.п.

    Я как ярый сторонник BDD использую два типа тестов feature (читай интеграционные тесты) и spec (читай юнит тесты)

    Итак, features. Берем Behat и херачем кучу тестов по типу:
    Зашел на главную,
    Потыкал чего-то в форме регистрации
    Зашел в профиль и увидел свое имя и фотку на странице
    Profit!

    Вот в целом и получили: "Непосредственно регистрация с занесением в БД", только в этой ситуации нам абсолютно не важно что там в БД. Нам важно чтобы пользователь зарегистрировался и попал в закрытый раздел сайта.

    Для таких тестов хорошо иметь поддержку окружения (prodaction, development, test) в коде, чтобы например можно было капчу отключить или еще какую сложную лабуду не делать.
    Если система замудрена до ужаса придется здесь для тестов все окружение поднимать. А лучще вообще отдать CI такое делать пусть друг трудится.
    Плюс таких тестов например когда пишем сложный фронт - сложный бек и еще более сложнейший бек-бек, то можно одним чохом протестировать работу всего сервиса.

    Следующий уровень абстракции spec:

    Если нам в интеграционных тестах было немного пофиг на БД. Она как бы пишет, но что так за структура абсолютно пофиг. То в случае со спекими нам ВАЩЕ ПОФИГ.
    Мы берем наш класс (функцию) и проверяем что за результаты она отдает. Вместо объектов, с которыми подопытный (объект тестируемого класса), даем ему резиновую бабу (моки и т.п), и смотрим на результаты нашего труда.

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

    Вот как то так!

    P.S тесты надо бы писать до кода.
    Ответ написан
    2 комментария
  • Какой движок для блога стоит попробовать?

    vofka
    @vofka
    Посмотрите Webasyst Блог.
    Обзор на Хабре: habrahabr.ru/company/webasyst/blog/199028
    Ответ написан
    Комментировать
  • Перспективен ли Ruby как инструмента для заработка?

    lunaticman
    @lunaticman
    Дерзкий айтишник

    Если вас интересуют перспективы, то скорее всего вам нужно углубиться в изучение javascript'а. Фронт-ендщиков не хватает уже сейчас, а что будет дальше - страшно представить (особенно учитывая как html5 расползается на всякие девайся - телеки, мобильники и т.д.)

    Я лично на PHP только в универе писал, больше Java. Но за год практический полностью перешел только на Ruby - и недостатка в заказах не ощущаю (работаю правда на английских биржах).

    Ответ написан
    6 комментариев
  • Кто какой скрипт онлайн общения с посетителями сайта посоветует?

    Anonym
    @Anonym
    Программирую немного )
    Zopim можете посмотреть. Можно общаться через веб, есть интеграция с IM, цены довольно лояльные.
    Ответ написан
    3 комментария