Умеет, да. Но стоит около $300, если не ошибаюсь. К тому же иногда, к сожалению, конвертировать приходится не дизайнеру, а другому человеку, к тому же после запуска проекта, когда (внезапно!) оказывается, что сочные странички с оригинальной нарезкой слишком долго грузятся на телефонах или жрут трафик. Сервис может оказаться полезным.
Не смог нагуглить простое устройство для подключения нескольких аудио-источников к одному входу. Дорогие сложные микшеры от $50 не в счёт. Визуальное оформление не важно: полимерная или металлическая болванка, с четырьмя входами под кабели с 3.5мм джеками и одним выходом (гнездо 3.5мм). при цене до 5 у.е. Предназначение — подключение к одной акустической системе нескольких бытовых устройств, имеющих выходы под наушники или колонки (компьютеры, ноутбуки, плееры, даже смартфон).
Интересно. Не думали сделать недорогой малогабаритный 3.5мм микшер на 2-4 канала (с регуляторами громкости или без)? Какая примерно стоимость может быть у такого устройства?
Лайт не пробовали? Все функци вроде есть, работает где угодно, надёжность обеспечивается за счёт физической развязки (авторизация по enum).
Сам виртуалку с виндой держу только из-за ИЕ (тестировать).
Глядя на фото, возникает ощущение, что это не ультрабук, а недобук. Впрочем, не поюзав, трудно рассуждать об удобстве работы на такой машине. А по поводу фильмов — если там TN матрица и две пищалки, то о каких блокбастерах можно говорить? В дороге болокбастеры и на смартфоне в наушниках можно смотреть, а за $1000 можно купить для этого 50-дюймовую панель.
В смысле? Я не понял, причём тут ссылки (кстати, ссылки вроде рекомендуют делать DBRef-ом). Проблема в том, что бывают случаи, когда надо проверить условия, связанные с разными документами. Например, проверить состояние двух счетов, если один из них не меньше суммы, а второй не больше какого-то предела, то перечислить сумму. Или, например, при вступлении пользователя в группу, проверить максимальное число членов группы, флаг закрытия, а у пользователя — права на вступление в группы и ограничение на количество групп. Этого часто невозможно сделать атомарным запросом, даже если перелопачивать структуру данных на каждое такое нововведение.
«Появились» — я имел в виду, что к примеру, во время вычислений появилась необходимость обработать документы, о которых раньше не было известно.
Пример: у пользователя есть право на определённое количество голосов. При обработке запроса-голоса, производится проверка его оставшегося количества голосов и голосовал ли он за этот документ уже раньше. Если обе проверки проходят, происходят некоторые вычисления, изменения у пользователя и у документа, создание новых документов (в очереди уведомлений например), и т.д. Если некто посылает пачку одинаковых параллельных запросов, есть вероятность, что сначала будет несколько успешных проверок, а потом несколько изменений, что приведёт к недопустимым данным. Cпособ с findAndModify, по идее, должен решить такую проблему?
То есть, сначала найти все используемые в транзакции документы. При этом установить им флаг, что они используются. После чего, произвести расчёты. Если во время расчётов появились ещё документы, им тоже установить этот флаг. После чего, произвести изменения и снять эти флаги. При этом, вся остальная логика должна знать и помнить, что у документа есть такой флаг, который надо учитывать. Таким образом, вроде как можно защититься от аномалий. Я правильно понял логику? Это действительно удобно, надёжно и не создаёт проблем?
А как же целостность данных? В этих «маленьких и быстрых» нереляционных БД, в той же упомянтой Mongo, нет (пока) ни транзакций, ни даже блокировки на уровне документа.
В приглашении люблю видеть время на сервере ("\D{%Y-%m-%d %H:%M:%S}") и полный путь к текущей директории ("\w"), а команду люблю вводить с новой строки ("\n$ "). Раскрашиваю приглашения разных серверов в разный цвет ("\e[32m"… "\e[0m"), чтобы случайно в запарке не выполнить команду не там, где надо.
35. Одно и то же время может быть только один раз.
Сам виртуалку с виндой держу только из-за ИЕ (тестировать).
Пример: у пользователя есть право на определённое количество голосов. При обработке запроса-голоса, производится проверка его оставшегося количества голосов и голосовал ли он за этот документ уже раньше. Если обе проверки проходят, происходят некоторые вычисления, изменения у пользователя и у документа, создание новых документов (в очереди уведомлений например), и т.д. Если некто посылает пачку одинаковых параллельных запросов, есть вероятность, что сначала будет несколько успешных проверок, а потом несколько изменений, что приведёт к недопустимым данным. Cпособ с findAndModify, по идее, должен решить такую проблему?