С одной стороны, бессмысленно выдавать тестовое задание привязанное к своей системе, и ожидать что кандидат (который ни разу не видел вашу систему) сделает что-то разумное.
С другой стороны, я видел людей, которые видимо генетически не способны программировать (точно также, как не у всех есть достаточный музыкальный слух чтобы играть на скрипке). Нужно любым способ убедиться, что кандидат вообще способен программировать! И тут есть два варианта:
— Либо вы спрашиваете какую-то data science хрень — типа обращения двоичного дерева, написать приоритетную очередь на основе heap, и т.д. В этом случае вы получаете кандидата который гарантированно умеет программировать, но теряете кандидатов — которые уже забыли data science хрень, а могли бы принести немало пользы в проекте.
— Либо вы придумываете какую-то задачу, которую можно в целом решить за 15-30 минут на собеседовании. Например, предлагаете вывести на однострочный экран в 20 символов сообщение длиной 50. И дальше слушаете — может ли кандидат предложить какое-то решение, и набросать его элементы на бумаге/экране.
Я пришел за годы работы ко второму варианту. Ну плюс, в зависимости от позиции кандидата — разные общие больные для всех вопросы: асимптотическая сложность, сложности и опасности при параллельных потоках, и так далее.
Если производители будут лепить в IoT сборки open-source проектов (типа openWRT для маршрутизаторов домашнего класса) — то пользователя (возможно...) удастся надрессировать нажимать кнопку «Update» в интерфейсе камеры, а не путем скармливания файла. В идеале, пользователь станет совсем тупым, и не сможет перетащить в камеру файл из электронной почты! :-)
Я почему-то боюсь, что во-первых — осведомленность непрофессионалов о безопасности сетевых потребительских устройств всегда будет низкой. Если у человека будет выбор — купить устройство за X фантиков в белой коробке, или за 1.5X фантиков с надписью «секурити сертифайед» — 99% предпочтут сэкономить. :-( Во-вторых, это ж рынок — сейчас разведется куча мутных контор, которые будут выдавать «сертифайд» за небольшую мзду по фотографии устройства (как сейчас это делается с электробезопасностью — статьи тут, на хабре — только поискать...).
Уж если совсем радикально подходить — надо обязывать производителей ширпотреба публиковать прошивки в исходниках (ибо, положа руку на сердце — нет там никаких секретов кроме того, что повсюду говнокод...). Ну и дальше это приведет скорее всего к тому, что производители перестанут лепить свои прошивки, и будут делать типовую аппаратную часть под какой-то нормальный OpenSource проект. И вот это уже гораздо более жизненно с точки зрения безопасности!
Тут ключевым будет определение «надлежащего качества». Обычно производителя обязывают гарантировать только безопасность продукта при соблюдении правил и условий эксплуатации. То есть, например, литиевый аккум в ноутбуке при нормальных условиях является безопасным. А если вы его начнете разбирать, или бросать в огонь — тут производитель уже как бы ничего не гарантирует.
Понятно, что есть области, где от производителя и проектировщика требуется давать гарантии даже за пределами нормальной эксплуатации (атомщики, аэроспейс, медицинское оборудование). Но там существуют отраслевые стандарты на эту тему.
А вот как быть с ширпотребом типа камер — это прямо вопрос-вопрос… Фантазируя на эту тему, я бы обязал производителей депонировать исходный код прошивок и всего инструментария (включая, возможно, ключи для подписи прошивок если это релевантно) — с условием, что по окончании поддержки или отсутствии исправления ошибки с безопасностью, доступ к исходникам получают все желающие, чтобы делать исправления самостоятельно. Хотя тут тоже не без вопросов — например, публикация из-за одной дыры прошивки-решета в моменте сильно снизит защищенность пользователей, многие из которых не умеют или не хотят разбираться со своей камерой.
Предложение хорошее, но содержит в себе непростую юридическую коллизию. Дело в том, что подключение к чужой камере и ее взлом — это действия, являющиеся незаконными в подавляющем большинстве юрисдикций. А ответственность производителя за заведомо незаконные действия третьих лиц — по существующему положению дел — невозможна. Если бы камеры сами транслировали незащищенное видео при обычной эксплуатации — тогда да, причинение вреда по халатности без вопросов. А в существующей ситуации — ключи шифрования были, защита какая-то была… Нужно тогда вводить обязательные (или добровольные) требования к защищенности устройств такого класса и маркировать их на соответствие. Правда, в этом случае есть другая опасность — все будут выполнять только минимальные вмененные требования в безопасности (разумеется, путем использования каких-то сертифицированных библиотек). А потом найдут уязвимость в этом общем компоненте, и небезопасными станут сразу все устройства. :-) Сейчас хоть взламывать надо по-отдельности…
Директор — это такой человек, который хочет или не хочет, отвечает за то «чтобы было!». И да, он может чем-то не заниматься, если нанял человека, обучил его, мотивировал и контролирует. А если человека пока нет (например, уволился), новый не обучен или не мотивирован — то все сам, сам… Стратегически, конечно когда-то директор все наладит, и его не будет ничего касаться. В дале-е-ком таком будущем, если ситуация не изменится (hint: изменится, и не раз). А в моменте — чем только директор не занимается на самом деле.
Не путайте директора коммерческой организации с директором департамента какого-нибудь государственного или квазигосударственного образования (типа госкорпорации). Там да, если бумагой задница прикрыта, то можно уже ничего и не делать…
В целом, да. Скорее всего я видел обе статьи. Когда предполагается промышленное выращивание чего-то в подвале — есть смысл заморочиться энергоэффективностью, светодиодами CREE, и далее по списку. А если нам просто в квартире рассаду светить или салат на гидропонике — тогда см. выше: самые дешевые белые светодиоды, и может быть коррекция в красную сторону (если есть чем).
Юнит-тесты должны писать сами разрабы. Для мира Java — это вообще практически необсуждаемая норма. Если система проходит автотесты — релиз передается ручным тестировщикам, которые проверяют сценарии слишком трудозатратные для автоматизации. Пока система не проходит тесты самих же разработчиков — ее нет смысла отдавать людям. Пирамида тестирования же ж!
Проще — да. Но почему дешевле? То есть да, если считать трудозатраты на изготовление по часовой ставке, то лампы дешевле точно. А если это проходит по статье «хобби» и делается в выходные, и труд считается условно-бесплатным — то светильник на 24 диода выходит дешевле, чем если собирать на лампах.
Ну тут остается сказать только что другие платформы — которые выросли не из бухгалтерии, а как платформы общего назначения — позволяют получить доступ ко всем этим низкоуровневым функциям. Берете binding к своей любимой системной библиотеке, и пользуетесь ей из-под Java. Потому что в Java на самом деле есть и небезопасные операции с памятью, и динамическая генерация байт-кода, и много чего еще. И главное — есть сообщество, которое эти функции поддерживает и развивает. А в 1С это будет как-бы сложнее, потому что это фирма 1С должна решить — надо оно вам или нет, и если надо, то в каком виде.
А поскольку у 1С есть еще и коммерческий интерес — то оно делает то же, что и Microsoft в свое время: вместо того, чтобы дать доступ к существующим имплементациям — оно делает свое, немного кривое и несовместимое. Вы этим начинаете пользоваться — и вот уже цель достигнута: с платформы 1С вы никуда не денетесь. Ибо совместимость…
Это не в программистах дело! 1С (точнее, конфигурация) по дизайну не является testable system. Пока в системе есть ересь типа «модуль формы» и прочее, куда запихивается часть бизнес-логики — тестировать это можно только собирая конфигурацию и тыкая в кнопки на экране. Переделывать архитектуру под автотесты и полностью разделять логику и представления — огромный труд, на который 1С не пойдет примерно никогда!
А программисту долго тыкать в кнопки на экране некогда. Да и данные актуальные не всегда есть. Он поэтому написал — и отдал. Фатальных ошибок все-равно не будет: формула распровести-провести известна любому специалисту и бухгалтеру. Поэтому тестят все сами пользователи на боевой базе. :-)
Я всегда говорю, что 1С — это разновидность религии. Либо ты веришь, либо нет. :-)
Для многих разработчиков дико работать в системе, где платформа изолирует тебя от БД. Да, я понимаю, что у 1С исторически есть файловая БД, и все такое — но уже давно можно было поставить всем SQL и не брать за это денег… Маркетинг!
Опять же, в других средах автоматизации — есть выбор: хочешь, дай системе право за тебя таблицы делать, хочешь — прописывай маппинг к существующей таблице. В 1С — за вас разработчики лучше знают, чего вы на самом деле хотите.
Что касается SAP или Axapta — то это еще менее удачные и более монструозные системы чем 1С. Про SAP шутят, что его внедрение заканчивается только с банкротством заказчика. Axapta я лично видел как внедряли — а потом с середины месяца откатывались на 1С, чтобы хоть как-то работать.
Лично мне ближе концепция автоматизации не по принципу «одна платформа, один фюрер, один народ», а разработка федеративной (сервисной или микро-сервисной) архитектуры — где каждый модуль достаточно прост, а сложное поведение достигается их взаимодействием через общую шину или очереди сообщений. А 1С пусть живет там, где ей место — примерно в бухгалтерии, она в ней вне конкуренции — пока генералитет 1С сидит в общественных советах налоговой и правительства, и получает инфо об изменении нормативки раньше, чем простые смертные.
Я бы вот только немного поспорил про фитолампы = светодиодные лампы. Если делать светильник на 1w или 3w светодиодах типа bead на платах-звездах — то на 30-40 светодиодов можно поставить 1 (один!) драйвер. А в лампах E24 на 6-10 светодиодов приходится покупать отдельный драйвер. Опять же — вынесенному драйверу и разнесенным на шинах светодиодам легче обеспечить температурные режимы, чем в цоколе лампы.
Нет. См — диффузия. Водород пойдет между атомами в кристаллической решетке наружу, а заместится газовыми примесями оттуда же. В далекой перспективе будет достигнуто равновесие, и внутри тоже будет воздух вместо водорода.
Если совсем выжимки — то растения понимают свет не так как гуманоиды. Поэтому ватты и люксы им не очень интересны. Им интересны отдельные фотоны (для простоты, учитываемые в молях), которые они тратят на фотохимические реакции. Есть базовые спектры поглощения чистого хлорофилла (в красной и синей области). Есть спектры эффективности использования света живым растением (кривая McCree72). Из этой кривой получается, что энергетически выгоднее всего светить дальним красным светом. Ну потому что на одном и том же токе и количестве моль света — падение напряжения в два раза меньше. И в тот же энергетический бюджет можно поставить в два раза больше диодов.
На практике есть два препятствия. Первое — растения под монохроматическим светом не очень хорошо живут. Эволюция их готовила к солнечному свету, и что-то в тонкой химии на это завязано. Второе — кроме секты гроверов (не всегда законопослушных), далекие красные светодиоды мало кому нужны. Их мало делают, и цена на них выше. А белых светодиодов делают как грязи в любом китайском подвале — и стоят они (до войны!) копейки. Дешевые белые светодиоды с точки зрения растений — ничем особо не отличаются от дорогих.
Таким образом — алгоритм досветки растений простой: покупаем самые дешевые белые светодиоды до которых можем дотянуться. Запитываем их через драйвер с постоянным током (если светодиоды совсем китайские — то снижаем ток процентов на 15-20 путем замены токового шунта). Если купленные светодиоды оказались холодными (имеют явный уклон в синюшность) — меняем несколько светодиодов белых из расчета — один белый на пару deep red.
Включаем, наслаждаемся эффектом. При определенных условиях на кухне при работающей подсветке вечером даже свет верхний включать не нужно. В отличие от блевотного сине-красно-фиолетового у покупных светильников за зиллиард рублей.
Когда 1С жила в бухгалтерии — это было еще ничего. И действительно, весы, сканер — и этого хватало. Но сейчас оно пытается в рамках ERP поехать прямо на производство. И там тогда надо или разводить целый зоопарк из уровней автоматизации, чтобы 1С оставлась в уютном мире документов — либо пытаться подключать всякую промышленную фигню прямо к системе. Ну то есть, слушать сокеты, отрабатывать проблемы связи и все такое… И в рамках 1С — это тяжко, прямо вот тяжко… Понятно, что теоретически — бери VC и пиши бинарный драйвер для полного счастья, но это опять платформно-зависимо и непереносимо. Я поэтому скептически смотрю на попытки 1С стать полноценной платформой для автоматизации. В мире есть платформы лучше (единственный недостаток — нужно знать английский).
Или можно холодные, но добавить deep red. Основная выгода в том, что падение напряжения на красном светодиоде ~1.5 вольта, а на синем/белом ~ 3.5. Таким образом, за один белый светодиод можно поставить два красных, и еще кусочек останется.
Их в институтах готовят на специальностях типа «прикладная информатика в экономике». То есть они в первую очередь бухгалтеры/экономисты/финансисты — а 1С им дается сразу как инструмент. В целом, это разумно — потому что когда они придут на предприятие — там будет 1С с вероятностью 99.999%
С другой стороны, я видел людей, которые видимо генетически не способны программировать (точно также, как не у всех есть достаточный музыкальный слух чтобы играть на скрипке). Нужно любым способ убедиться, что кандидат вообще способен программировать! И тут есть два варианта:
— Либо вы спрашиваете какую-то data science хрень — типа обращения двоичного дерева, написать приоритетную очередь на основе heap, и т.д. В этом случае вы получаете кандидата который гарантированно умеет программировать, но теряете кандидатов — которые уже забыли data science хрень, а могли бы принести немало пользы в проекте.
— Либо вы придумываете какую-то задачу, которую можно в целом решить за 15-30 минут на собеседовании. Например, предлагаете вывести на однострочный экран в 20 символов сообщение длиной 50. И дальше слушаете — может ли кандидат предложить какое-то решение, и набросать его элементы на бумаге/экране.
Я пришел за годы работы ко второму варианту. Ну плюс, в зависимости от позиции кандидата — разные общие больные для всех вопросы: асимптотическая сложность, сложности и опасности при параллельных потоках, и так далее.
Если производители будут лепить в IoT сборки open-source проектов (типа openWRT для маршрутизаторов домашнего класса) — то пользователя (возможно...) удастся надрессировать нажимать кнопку «Update» в интерфейсе камеры, а не путем скармливания файла. В идеале, пользователь станет совсем тупым, и не сможет перетащить в камеру файл из электронной почты! :-)
Уж если совсем радикально подходить — надо обязывать производителей ширпотреба публиковать прошивки в исходниках (ибо, положа руку на сердце — нет там никаких секретов кроме того, что повсюду говнокод...). Ну и дальше это приведет скорее всего к тому, что производители перестанут лепить свои прошивки, и будут делать типовую аппаратную часть под какой-то нормальный OpenSource проект. И вот это уже гораздо более жизненно с точки зрения безопасности!
Понятно, что есть области, где от производителя и проектировщика требуется давать гарантии даже за пределами нормальной эксплуатации (атомщики, аэроспейс, медицинское оборудование). Но там существуют отраслевые стандарты на эту тему.
А вот как быть с ширпотребом типа камер — это прямо вопрос-вопрос… Фантазируя на эту тему, я бы обязал производителей депонировать исходный код прошивок и всего инструментария (включая, возможно, ключи для подписи прошивок если это релевантно) — с условием, что по окончании поддержки или отсутствии исправления ошибки с безопасностью, доступ к исходникам получают все желающие, чтобы делать исправления самостоятельно. Хотя тут тоже не без вопросов — например, публикация из-за одной дыры прошивки-решета в моменте сильно снизит защищенность пользователей, многие из которых не умеют или не хотят разбираться со своей камерой.
Не путайте директора коммерческой организации с директором департамента какого-нибудь государственного или квазигосударственного образования (типа госкорпорации). Там да, если бумагой задница прикрыта, то можно уже ничего и не делать…
А поскольку у 1С есть еще и коммерческий интерес — то оно делает то же, что и Microsoft в свое время: вместо того, чтобы дать доступ к существующим имплементациям — оно делает свое, немного кривое и несовместимое. Вы этим начинаете пользоваться — и вот уже цель достигнута: с платформы 1С вы никуда не денетесь. Ибо совместимость…
А программисту долго тыкать в кнопки на экране некогда. Да и данные актуальные не всегда есть. Он поэтому написал — и отдал. Фатальных ошибок все-равно не будет: формула распровести-провести известна любому специалисту и бухгалтеру. Поэтому тестят все сами пользователи на боевой базе. :-)
Для многих разработчиков дико работать в системе, где платформа изолирует тебя от БД. Да, я понимаю, что у 1С исторически есть файловая БД, и все такое — но уже давно можно было поставить всем SQL и не брать за это денег… Маркетинг!
Опять же, в других средах автоматизации — есть выбор: хочешь, дай системе право за тебя таблицы делать, хочешь — прописывай маппинг к существующей таблице. В 1С — за вас разработчики лучше знают, чего вы на самом деле хотите.
Что касается SAP или Axapta — то это еще менее удачные и более монструозные системы чем 1С. Про SAP шутят, что его внедрение заканчивается только с банкротством заказчика. Axapta я лично видел как внедряли — а потом с середины месяца откатывались на 1С, чтобы хоть как-то работать.
Лично мне ближе концепция автоматизации не по принципу «одна платформа, один фюрер, один народ», а разработка федеративной (сервисной или микро-сервисной) архитектуры — где каждый модуль достаточно прост, а сложное поведение достигается их взаимодействием через общую шину или очереди сообщений. А 1С пусть живет там, где ей место — примерно в бухгалтерии, она в ней вне конкуренции — пока генералитет 1С сидит в общественных советах налоговой и правительства, и получает инфо об изменении нормативки раньше, чем простые смертные.
Если совсем выжимки — то растения понимают свет не так как гуманоиды. Поэтому ватты и люксы им не очень интересны. Им интересны отдельные фотоны (для простоты, учитываемые в молях), которые они тратят на фотохимические реакции. Есть базовые спектры поглощения чистого хлорофилла (в красной и синей области). Есть спектры эффективности использования света живым растением (кривая McCree72). Из этой кривой получается, что энергетически выгоднее всего светить дальним красным светом. Ну потому что на одном и том же токе и количестве моль света — падение напряжения в два раза меньше. И в тот же энергетический бюджет можно поставить в два раза больше диодов.
На практике есть два препятствия. Первое — растения под монохроматическим светом не очень хорошо живут. Эволюция их готовила к солнечному свету, и что-то в тонкой химии на это завязано. Второе — кроме секты гроверов (не всегда законопослушных), далекие красные светодиоды мало кому нужны. Их мало делают, и цена на них выше. А белых светодиодов делают как грязи в любом китайском подвале — и стоят они (до войны!) копейки. Дешевые белые светодиоды с точки зрения растений — ничем особо не отличаются от дорогих.
Таким образом — алгоритм досветки растений простой: покупаем самые дешевые белые светодиоды до которых можем дотянуться. Запитываем их через драйвер с постоянным током (если светодиоды совсем китайские — то снижаем ток процентов на 15-20 путем замены токового шунта). Если купленные светодиоды оказались холодными (имеют явный уклон в синюшность) — меняем несколько светодиодов белых из расчета — один белый на пару deep red.
Включаем, наслаждаемся эффектом. При определенных условиях на кухне при работающей подсветке вечером даже свет верхний включать не нужно. В отличие от блевотного сине-красно-фиолетового у покупных светильников за зиллиард рублей.