kn0ckn0ck

У этой связи нет специальной семантики (функциональности), более того, встроенными средствами видимо этот вопрос не решить. Ищите плагины, которые позволят выполнять действия над связанными тикетами.

Здесь вам нужен суррогатный первичный ключ в таблице Технологическая карта. Я не уверен, что это решение проблемы, возможно, здесь вообще реляционная модель некорректная.

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

Варианты какие есть:
1. Использовать облачный сервис типа Яндекс.Алисы (кстати, платный), поскольку готовые западные не поддерживают распознавание русского, а интеграция с Google-вым сервисом требует наличия постоянной привязки к доменному имени (хотя это конечно решаемый вопрос, теоретически)
2. Использовать библиотеку, расположенную на сервере в доме. Вариант отличный, поскольку не требует подключения к инету и всяких сложных настроек, но... к нему нет готовой интеграции к HASS (либо я не нашел).
3. Использовать телефон с каким-то приложением, использующий штатные возможности Android и iOS и отправляющий команды в HASS (не знаю, есть ли что-то готовое в природе), здесь тоже нужна локальная сеть и/или доступ в интернет и статический IP.

Если все сильно проще, то буду признателен за рекомендации где смотреть/копать.

Да, их много разных. Отличаются в основном контекстом применения - где-то лучше работает одно, а где-то другое, например:

1. просто - это User Story
2. чуть сложнее - UseCases, IEEE 830-1998
3. совсем тяжелый случай - ГОСТ 34, ГОСТ 19 или ГОСТ Р 51904-2002

Для эксплуатационной документации посмотрите РД 50-34.698-90

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

После этого вернитесь к мысли о гиках: какая должна быть технология, чтобы ею пользоваться и не быть гиком? Решения под ключ не просто так дороги, это именно готовые решения. Попробуйте повторить нечто аналогичное и не стать при этом гиком.

Так что варианта три:
1. купить под ключ и наслаждаться комфортом
2. собрать автоматизацию (не умный дом) простейшего сценария из "коробки" и успокоиться
3. стать гиком, сэкономить и наслаждаться комфортом

Выбирайте :)

Сместите акцент с железки на ценность для клиента. Сам по себе 3D-принтер это тот еще головняк. Потребность в них может быть только у технически подготовленных энтузиастов, а их очень мало. Более того, такой энтузиаст и без вас закажет себе принтер, а то и сам его соберет.

Для бизнеса вам нужна массовая поставка, то есть для массового сегмента. Массовый сегмент это вообще не про 3D-печать... пока вы существенно не упростите саму технологию или не покажете как на этом можно заработать.

Я бы предложил начать со второго. Сделайте одностраничник, который научит любого желающего гарантированно заработать на 3D-печати и заказы потекут рекой.

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

Вопрос очень не прост.

1. Разместить разные данные в одной таблицы - это про денормализацию и никакого отношения к деревьям не имеет. Денормализация может создать очень много проблем, в том числе большое количество логических ошибок.

2. Если вы хотите хранить деревья с дугами произвольной длины, то использование одной таблицы - самый простой, но самый неэффективный способ работы с иерархиями.

3. В зависимости от типа СУБД могут быть встроенные возможности работы с иерархическими данными, они накладывают требования на формат хранения данных. Это самый правильный путь организации хранения иерархий.

Знакомьтесь с задачей в два этапа:
1. Цель первого этапа: go / no go, то есть понять вам: тянете, хотите, интересно, есть ли профит и т.п. Это знакомство с задачей за ваш счет. Очевидно, что знакомиться долго не выгодно, однако, если получите контракт, то это время окупится.
2. Цель второго этапа - оценить стоимость. Этот этап нужно продать заказчику. Нет никакого смысла составлять ТЗ за свой счет, тем более, что это отдельная и самодостаточная услуга. Заказчик платит за ТЗ, вы существенно снижаете риски недооценки. Если заказчику ТЗ понравится, то контракт ваш на 90%.

Здесь есть важный психологический момент. Разработка ПО - это дорого, долго и сложно. Если какой-то стороне что-то не будет нравится, то вся сделка будет невыгодной. Разработка ТЗ - это проще и короче. Таким образом, начав с ТЗ, заказчик лучше познакомится с исполнителем, лучше поймет свою задачу и т.п. Возможно, после ТЗ будет ясно, что у него просто нет денег на все свои хотелки.

То есть схема простая и давно отработанная: интерес (2 часа) -> ТЗ (3 дня, $) -> код (3 месяца, $)

Конечно, средств полно. Важно уточнить - какого рода тестирования и на какой платформе вам требуется. Для этого используются различные средства: функциональное тестирование = Selenium, нагрузочное = JMeter, безопасность = Nessus и т.д.

Каждый инструмент сильно привязан к функциональности сайта и технологии, на которой он написан, поэтому что-то универсальное и повторно используемое - это вряд ли. Только если на уровне концепции. Задайте более конкретный вопрос на специализированном форуме.

Разговор с боссом можно строить по понятиям, а можно по общепризнанным стандартам.

Если идти по первому пути, то в качестве примеров можно привести описания вакансий QA director-ов из компаний, близких по размеру/индустрии.

Если по второму, то в РФ есть профстандарты и, в частности, 40.010. В нем много букв, не поленитесь и посмотрите.

Например, там описаны трудовые функции начальника отдела контроля качества продукции. Если ваша деятельность соответствует этим функциям, то это лучшее обоснование вашей должности.

За пол дня собрал такой сервис: https://github.com/cutecare/gas-map, под капотом:
1. elasticsearch принимает данные (json post) и отдает их в карту, либо на аналитику (kibana)
2. на Яндекс.Карте отмечаются кружками данные, которые берутся из elasticsearch

Работает очень быстро, 700 тыщ в сутки - это десткий лепет для Elasticsearch. Есть масса альтернатив конечно.

Первая проблема: это не гениальная идея, ее легко повторить. Именно так и делают всякие сервисы защиты, предлагаемые Microsoft, Яндекс и подобными. Что ты противопоставишь этим конкурентам и как защитишься от новых?

Вторая проблема: чью боль ты хочешь лечить этим продуктом? Частников? Микро-бизнес? Малый бизнес? Средний бизнес? Корпорации? От этого зависит вся бизнес-модель.

Третья проблема: это серьезная бизнес-история, а ты спрашиваешь как это монетизировать... Посмотри сначала на это как на бизнес, а не как на проект - многие ответы появятся автоматом.

База данных состоит их схемы и данных. Данные могут быть разные: управляющие, пользовательские и т.п. За схему и управляющие данные (справочники, например) отвечает миграция. С этим как я понял у вас Ok.

Зависимость кода от данных - это очевидный антипаттерн дизайна, который необходимо устранить. Тем более, если код зависит от пользовательских данных, типа ID пользователя.

С другой стороны, разработчики предпочитают работать с данными, приближенными к боевым. Однако, здесь могут быть риски, например, отправка тестового письма реальному пользователю. Процесс выглядит обычно так:

1. сливаем дамп с боевой базы данных;
2. загружаем его на тестовый сервер;
3. запускаем процедуру обфускации (удаления чувствительных пользовательских данных);
4. загружаем управляющие данные, соответствующие тестовому окружению (если это нужно).

Чем что-то покупать я бы предложил сразу определиться:
1. вам с серьезной перспективной или поиграться?
2. вам своими руками хочется все сделать или купить готовое и не париться?

Если поиграться и своими руками, то проектов подобных этому немало: view24.ru
Если серьезно и своими руками, то MajorDoMo или HomeAssistant
Если поиграться и купить, то какие-то доступные китайские наборы или отдельные устройства типа Xiaomi или Sonoff
Если серьезно и купить, то выбор здесь безграничен, на любую сумму, в инете рекламы полно.

Можете также глянуть на этот обзор вариантов решений.

Дно, ха-ха :) Я так полагаю, что 80% аудитории в этом случае такое же "дно".
Если человеку нравится кодить, то нужно идти туда, где требуется кодер на C/C++. Это вполне нормально и полно в банках, у разработчиков мед. софта, у разработчиков встраиваемого ПО/оборудования, у военных (во, может ему в науч. роту?)
Вот когда накодится поуши, тогда можно что-то дальше думать. А может там и останется и это нормально для развития профессионала, напишет потом что-нибудь в духе Александреску :)

Это не один продукт, это целый класс систем под названием Application Lifecycle Management (ALM). Суть в том, что на общей платформе (или общей базе данных) или тесно интегрированных отдельных инструментах, организуется процесс разработки от стадии сбора первичных требований до стадии эксплуатации и поддержки готового решения.

Другое дело, на сколько каждая из ALM-систем удобна/пригодна/доступна в каждом конкретном случае - вот это всегда большой вопрос. ALM именно под веб-разработку мне не встречались, обычно это какие-то универсальные решения.

Основной причиной тут мне видится изолированность этапов производства ПО. Обычно отдельно от всего формируется ТЗ, отдельно и кем-то там создается UI/UX, потом отдельно еще кем-то эти все фантазии имплементируются и еще потом кем-то там это все поддерживается.

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

Кстати, есть и позитивный пример, это Siemens PLM. Один производитель мега-ПО, используемого в промышленном производстве (самолеты, машины, ЖДТ и т.п.). В этом сегменте все по-другому, потому что там все сильно зарегулировано и конечный исполнитель скорее работает по системе, а не настраивает/выбирает что-то под себя.

Если целью вашего вопроса было получить расчет бизнес-плана, то уровень нужно было ставить "Сложно", иначе ответы получаются в духе сложности :)

Для расчета бизнес-плана тут явно отсутствуют некоторые константы и переменные. Так что вряд-ли что-то путное выйдет. Например:

1. ни слова про маркетинг (стоимость привлечения), видимо ваше приложение настолько крутое, что сразу попадет в топ-10, чтобы за год миллион собрать
2. ни слова про конверсию и ЦА, тут можно для начала начать с 0.5% (из бесплатных в платные)
3. не ясно будут ли приятели работать и за что: за еду или деньги? Много ли или дорого ли они едят?
4. ничего нет про технологию, значит не ясны расходы на оборудование

Короче, почти ничего не известно - таким образом, ответ:
1. перспективы туманны,
2. дохода может не быть вообще