Как стать автором
Обновить
125
0
Дмитрий Андриянов @dima117

Пользователь

Отправить сообщение
Единственное, если верстка очень сложная, браузер может тормозить из-за рендеринга большого количества DOM элементов. Но это обычно бывает, когда выводятся очень большие списки на одной странице (из тысяч элементов) и, как правило, говорит о плохо спроектированном UI приложения.
Когда были жалобы, на сервере было включено сжатие gzip? Как правило, это включается одной строчкой в конфиге и сильно сокращает объем трафика. Более того, т.к. текст очень хорошо сжимается, «облегченная» и «необлегченная» верстка в сжатом виде занимают примерно один и тот же объем.
Если честно, недостатки адаптивного дизайна высосаны из пальца.

В более менее крупных городах уже есть 4G (например), поэтому скорость загрузки будет в любом случае высокой. Переключение между полной/мобильной версией сайта есть в настройках браузера в телефоне (по сути, включает/выключает масштабирование). Юзабилити мобильной версии больше зависит от разработчика и предметной области, чем от адаптивной верстки.

Имхо, в большинстве случаев предпочтительнее вариант с адаптивной версткой (хотя, конечно, всегда нужно принимать решение, исходя из конкретной ситуации).
Я начинал с этих видео. Все очень легко и понятно.
Уже написали несколько вариантов.
Основная идея — с Вашим планшетом всегда работает один (или очень небольшое) количество человек.
В интернет-кафе людям предоставляется не только интернет, но и оборудование. Соответственно, усложняется процесс идентификации людей, пользующихся этим оборудованием (нельзя применить большинство технических решений, которые обычно используются). В общественных местах люди пользуются собственными устройствами, по которым их легко идентифицировать, поэтому предьявлять паспорт там нет необходимости.
Не совсем так: он имеет 32 канала для отправки команд и 4 канала для пирема информации с датчиками. Этот адаптер имеет 64 канала для приема информации, но не может отправлять команды.
RX2164 (как и RX1164) — это только приемник. Насколько я знаю, приемо-передатчика в ближайшее время все-таки не будет.

И старая, и новая модель адаптера — 64-канальные. Сколько максимум датчиков можно привязать к каждому каналу, сейчас не помню, но точно можно привязать несколько.
Можно использовать любую библиотеку для работы с HID устройствами. Логику периодического опроса адаптера нужно реализовать самому.

Для предыдущей модели написано много библиотек (вот пример под Linux). Для новой модели пока есть .NET API (еще не зарелизили, версия в репоззитории умеет работать с новым адаптером, сейчас тестируем).
Спасибо за обратную связь! Мы в курсе, на счет неидеального дизайна )

Внешний вид важен для хорошего восприятия пользователями, но сейчас дизайн — далеко не самая важная задача. Намного важнее качественно реализовать запланированный функционал и при этом сохранять систему простой. Мы выбрали bootstrap не потому, что там крутой дизайн, а потому, что это самый легкий способ быстро сделать приемлемый интерфейс (т.е. чтобы не писать самостоятельно стили для элементов интерфейса). Дизайн системы — отдельная большая задача, мы обязательно до нее доберемся в будущем.
Мы выбрали .NET для нашего проекта потому, что нет опыта программирования под другие платформы (если честно, вопрос выбора даже не стоял: просто убедились, что на .NET возможно решить задачу). Мы решили, что качественный проект на .NET лучше, чем кривой велосипед на других платформах.

Кроме того, как оказалось, .NET имеет еще несколько преимуществ над другими платформами (например, для .NET имеется отличный движок синтеза и распознавания голоса). В целом, по количеству достоинств и недостатков .NET примерно на одном уровне с другими платформами.
Не совсем понял, что значит «запускать будильники одним кликом».
На счет повседневных суенариев — согласен. Мы постоянно узнаем и придумываем новые сценарии. Если у Вас есть хорошие идеи — обязательно напишите их мне :)
Насколько я понимаю, к достоинствам можно отнести:
— верстка зависит от css-классов (дополнительный уровень абстракции) вся конфигурация находится в одном месте. Например, если вы захотите изменить значение минимальной ширины, то не нужно будет искать все media queries, где оно используется.
— можно навешивать дополнительные классы (например, зависящие от ориентации экрана, типа устройства или браузера, ОС и т.д.). Например, вместо применения css-хаков для старых версий ie можно пометить контейнер классом и прописать стили для него.

Как мне кажется, в небольших проектах потребность в таком функционале редко возникает. Я бы использовал media queries (чтобы не подключать в проект лишний скрипт). Но в проектах со сложной версткой такой подход может быть удобнее. Например, насколько я знаю, этот подход используют в outlook.com.
Очень интересно!
Можете рассказать подробнее, в каком все состоянии (и, если есть возможность, дать посмотреть исходники)?
Спасибо, про централизованное хранение исходников и загрузку обновлений на устрйоства — интересно.

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

Буду продолжать автоматизацию и следить за своими ощущениями. Возможно, действительно потом откажусь от центрального сервера.

Смотрели. Там нет поддержки из коробки нужного железа (т.е. все равно это реализовывать самостоятельно). На счет использования в качестве платформы — имхо, не очень гибкая платформа, перегруженная возможностями. Кроме того, написано на Java, хотелось бы .NET (из-за его средств разработки) — но это не критичный недостаток, если бы первых двух не было, то смирились бы с ним.

У каждого свои задачи (свое «железо», свои привычки, которые он хочет автоматизировать). Использовать универсальную систему с богатым функционалом будет неудобно, т.к. реально из всего функционала используестя 5-10%, а оставшиеся 90% накладывают ограничения и тратят время/нервы. Начали писать свою систему потому, что хотели простой «конструктор», из которого каждый может собрать то, что ему нужно (а если какой-то детали не хватает — самостоятельно ее сделать).
Почему?
При такой организации при большом количестве скриптов начинается бардак + возможно, начинаются проблемы производительности (из-за того, что все очень универсально и низкий уровень оптимизации).
Не расстраивайтесь, не все так плохо, посмотрите, комментарии чуть выше. .NET — просто одна из особенностей системы со своими «плюсами» и «минусами», причем «плюсов» не так уж и мало.
По поводу Windows — есть распространенный стереотип, что это ненадежная, ресурсоемкая ОС. Действительно, в 90-х годах так и было, но с тех пор уже прошло 15 (!) лет — не думаю, что есть повод волноваться.
Например, я несколько лет работаю с сервером на Windows Server 2008R2, он включен постоянно и перезагружался за пару лет 2-3 раза (нужно было при установке ПО). Также у меня ноутбук на Windows 8.1, который я не выключаю по пол года — никаких проблем с ресурсами замечено не было. Кроме того, вы же понимаете, что на управляющем устройстве умного дома у вас не будет браузера с сотней открытых вкладок, flash-плеера и других приложений, из-за которых появляются проблемы с производительностью.

И последняя причина… Согласитесь, написать программу, которая жрет память можно на любом языке программирования и в любой ОС. Платформа .NET имеет отличные средства разработки и огромное количество библиолтек готовых компонентов (в т.ч .open source). Visual Studio — лучшая IDE, из всего, что я видел. Я получаю удовольствие во время разработки. На мой взгляд, эта причина — удобство разработки — не менее важна, чем остальные.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Работает в
Дата рождения
Зарегистрирован
Активность