Вы серьезно? Трекеры передают технические данные, которые не являются персональными и не позволяют идентифицировать человека.
Более того, вы держите в руках телефон с ОС, разработанной Google или Apple, и беспокоитесь о трекерах в сторонних приложениях? Сами ОС и встроенные приложения этих компаний передают им в разы больше данных.
С освещением комнаты менеджера сценарий довольно сомнительный. Допустим у вас там 1 управляемая линия, соответственно 1 реле, 1 датчик освещенности и 1 выключатель, 2 линии плк используются. Это в сумме тянет миниум на 5т/р если не считать расходы на установку. Скорее всего больше. Как скоро экономия 60% времени работы лампы в этой комнате окупит затраты на ее автоматизацию? Не проще ли было поставить менеджеру 2 хорошие светодиодные лампы на 15-20вт суммарно, потратив на это меньше тысячи рублей, при этом снизить энергопотребление?
В статье вы пишите, что целью создания технологии является в том числе обеспечение надёжного и безопасного канала сбора информации с датчиков. Как вы обеспечите надёжность передачи данных без даунлинка и квитанции о получении? И какой протокол вы хотите использовать для обеспечения безопасной передачи в отсутствии всякого хендшейка?
Даже если эти проблемы как-то решатся, как вы собираетесь конкурировать с другими сходными протоколами типа лоравана на уровне производителя? Если у меня есть линейка устройств, которые могут работать в режиме только на передачу, и рядом с ней линейка устройств которые могут работать в обе стороны, то я с большой вероятностью поставлю в обе линейки тот же лораван классов А и С соответственно. Мне это снизит стоимость разработки за счёт того, что не надо переучивать персонал и разрабывать шлюзы и ПО заново. А моему потребителю я смогу предложить шлюз который совместим со всеми моими линейками.
Довольно странно, что разгонный блок не согласует время включения двигателей с собственной ориентацией. Черт с ним, с углом поворота, это правда сложно реализовать правильно когда пишешь все на ассемблере или каком-нибудь модула-2. Но почему старт двигателям разрешен в нештатном положении блока относительно траектории?
На минуточку — разгонный блок это часто либо последняя ступень с двигателями, либо последняя ступень с двигателями досточной дельта-в. В спутниках которые крепятся в РБ, часто топлива только на калиброку и ориентацию. РБ должен уметь парировать все косяки траектории на которую его вывела ракета-носитель и тут выясняется, что он не просто не может понять как ему быстрее открутиться, но и включает двигатели просто по таймеру, то есть безотносительно текущей ситуации.
Мне кажется, вина в аварии лежит исключительно на софте (прошивке) разгонного блока.
Меня каждый раз удивляет один факт — почему они используют жидкий азот для охлаждения компонентов? Да, у него очень низкая температура кипения, но очень низкая теплоемкость — 1-2 кДж/(кг*К) против ~4.2 у воды. Плюс он еще вскипает на поверхности компонента, образует газовую прослойку и начинает охлаждать еще хуже.
Не лучше ли будет охлаждать просто очень холодной водой? Там, конечно не будет таких эффектных облаков, но, кажется что будет просто эффективней.
Для меня словосочетание «Драйвер для процессора» звучит так же как «Драйвер для коврика мыши». Кто-нибудь сможет объяснить для чего он операционной системе? ЦП, что, отображается в систему в виде различных устройств? При Таненбауме такого не было!
Чтобы заправляться в верхних слоях атмосфер газовых гигантов или прости, господи, фотосферах звезд, достаточно заточить двигатель под водород-гелиевую смесь. А двигаясь на скоростях порядка сотых световой, можно собирать достаточное количество водорода прямо из межзвездного пространства.
Не первый раз уже вижу пост от школьника/студента, который который показывается несколько часов пока его сольют и скроют в черновики. Мне кажется, что для сообществу, состоящему из инженеров разных мастей должно быть по плечу решить подобную системную проблему. Сам, когда получал аккаунт через песочницу 4 года назад, написал очень похожую статью, правда ее не слили.
А давайте представим, что на хабре есть специальный раздел, где вот такие вот совсем зеленые ребята могут выкладывать свои поделки и получать действительно полезные комментарии от специалистов и профессионалов, а не эти стенания о том, что это топ-1 IT ресурс страны? И вот этот вот пост выложен в этом гипотетическом разделе. Вот, например, мои замечания:
Слишком громкий заголовок статьи. Проект на 1 класс, использующий стандартный системный компонент не может считаться браузером
Метод донесения информации статьи. Было бы неплохо услышать про процесс реализации, даже вот такого неказистого проекта. Просто вываленный код неинтересно смотреть
Метод донесения исходного кода. В 2016-м году никто не будет смотреть код из архивов в дропбоксе. Нужно выложить на публичный хост, например github.com
Стиль кода и реализация. Тут все понятно — автору нужно еще многому научиться. Обязательны к изучению такие книги как «Чистый код» Мартина, «Филисофия Java» Эккеля, и fundamentals из документации Android.
Квантовая логика никогда не заменит классическую бинарную. В лучшем случае, квантовые процессоры будут работать в паре и под управлением обычного процессора. Естественно, при этом программы у них будут свои и оочень специфические типа криптографии, распознавания образов и пр.
Я так понимаю, вы используете AndroidStudio. У нее не было еще ни одного стабильного релиза. Она в бету-то вышла месяц назад. Вполне ожидаемо, что при ее обновлениях или обновлениях android-gradle плагина, могут возникнуть проблемы и несовместимости. Хотите стабильности — используйте эклипс и ант. Хотите быть на острие — смиритесь с нестабильностью не-релизных версий.
Общепринято, что АТД — это Алгебраический Тип Данных. Статью заминусили хаскелисты и люди, которым просто обидно за терминологию. Всячески поддерживаю. Сам полез внутрь узнать что-нибудь АТД в джаве и обломался :( А про абстрактные классы и интерфейсы в джаве уже ничего интересного написать невозможно — все обмусолено множество раз.
Более того, вы держите в руках телефон с ОС, разработанной Google или Apple, и беспокоитесь о трекерах в сторонних приложениях? Сами ОС и встроенные приложения этих компаний передают им в разы больше данных.
С освещением комнаты менеджера сценарий довольно сомнительный. Допустим у вас там 1 управляемая линия, соответственно 1 реле, 1 датчик освещенности и 1 выключатель, 2 линии плк используются. Это в сумме тянет миниум на 5т/р если не считать расходы на установку. Скорее всего больше. Как скоро экономия 60% времени работы лампы в этой комнате окупит затраты на ее автоматизацию? Не проще ли было поставить менеджеру 2 хорошие светодиодные лампы на 15-20вт суммарно, потратив на это меньше тысячи рублей, при этом снизить энергопотребление?
В статье вы пишите, что целью создания технологии является в том числе обеспечение надёжного и безопасного канала сбора информации с датчиков. Как вы обеспечите надёжность передачи данных без даунлинка и квитанции о получении? И какой протокол вы хотите использовать для обеспечения безопасной передачи в отсутствии всякого хендшейка?
Даже если эти проблемы как-то решатся, как вы собираетесь конкурировать с другими сходными протоколами типа лоравана на уровне производителя? Если у меня есть линейка устройств, которые могут работать в режиме только на передачу, и рядом с ней линейка устройств которые могут работать в обе стороны, то я с большой вероятностью поставлю в обе линейки тот же лораван классов А и С соответственно. Мне это снизит стоимость разработки за счёт того, что не надо переучивать персонал и разрабывать шлюзы и ПО заново. А моему потребителю я смогу предложить шлюз который совместим со всеми моими линейками.
На минуточку — разгонный блок это часто либо последняя ступень с двигателями, либо последняя ступень с двигателями досточной дельта-в. В спутниках которые крепятся в РБ, часто топлива только на калиброку и ориентацию. РБ должен уметь парировать все косяки траектории на которую его вывела ракета-носитель и тут выясняется, что он не просто не может понять как ему быстрее открутиться, но и включает двигатели просто по таймеру, то есть безотносительно текущей ситуации.
Мне кажется, вина в аварии лежит исключительно на софте (прошивке) разгонного блока.
Не лучше ли будет охлаждать просто очень холодной водой? Там, конечно не будет таких эффектных облаков, но, кажется что будет просто эффективней.
А давайте представим, что на хабре есть специальный раздел, где вот такие вот совсем зеленые ребята могут выкладывать свои поделки и получать действительно полезные комментарии от специалистов и профессионалов, а не эти стенания о том, что это топ-1 IT ресурс страны? И вот этот вот пост выложен в этом гипотетическом разделе. Вот, например, мои замечания:
Я так понимаю, вы используете AndroidStudio. У нее не было еще ни одного стабильного релиза. Она в бету-то вышла месяц назад. Вполне ожидаемо, что при ее обновлениях или обновлениях android-gradle плагина, могут возникнуть проблемы и несовместимости. Хотите стабильности — используйте эклипс и ант. Хотите быть на острие — смиритесь с нестабильностью не-релизных версий.