Можно ещё предварительно анализировать на стандартные 100% правила, полагаю, это должно улучшить показатели, так как не придется гадать, там где однозначно известен ответ.
-35 8
-30 20
-25 31
-20 47
-15 67
-10 60
-5 119
0 34
(от +15 до 0 = 211 дней)
Для интереса, собрал статистику погоды за 2 года (2013-2015) по Караганде.
Итого: 538 дней за два года можно пользоваться кондером и 59 печкой :)
Ёкарный бабай, так эти таблицы надо было в самом начале писать, вот же жуки-то. Не понятно, зачем заявлять -25, если он уже при -10, даже половину мощьности ели выдает.
Если даже по Вашим расчетам: при -20, 78 Вт на кв. метр * 80 квадратов = 6,24 киловат/час тепла.
Зубадан, MSZ-FH50VE / MUZ-FH50VEHZ
Тепловой насос
5.0 кВт (охлаждение)
6,0 кВт (обогрев)
Потребляемая мощность 1.55 кВт (при 3 руб киловатт днем, и 50 копеек ночью) — получается даже дешевле угля :)
Единственное не нашел, сколько у него реальная производительность при -20, вроде не меньше 80%. И так как внутренний блок один, то не понятно куда его поставить, чтобы 80 квадратов равномерно отопить.
После -20, да даже и в -20, уже использовать угольную печь. Дом жилой, поэтому автономность ему не нужна.
>>А что делать там не id пользователя, а условие?
1. Только сотрудник с ролью Куратор.
Указываем в метаинформации, не конкретного сотрудника, а группу/роль и т. п. Хотя я так не делают, так как согласование должно проходит достаточно быстро (день, неделя, месяц). Поэтому маловероятно, что роль будет меняться так часто. Поэтому указываю конкретного человека из настроек/по условию (прям в wwf) на момент создания кнопки.
Если, что-то изменилось очень срочно, то есть два стандартных механизма для решения таких проблем:
— Замещение.
— Изменить ответственного через службу поддержки (в данный момент это 1 человек на, где-то, 700 ежедневных уникальных пользователей системы, к сожалению, общее количество работающих с системой не знаю). Пока справляется, даже совмещать с другой должностью успевает.
2. В случае отсутствия куратора согласует начальник департамента
Решается через общий механизм замещения.
3. Можете выложить код, как проводите обработку мета-данных?
Выбрать все кнопки, где пользователь является ответстенным. Плюс выбрать все кнопки, где ты замещаешь ответственного. Вот и получается перечень твоих задач.
CREATE VIEW Tasks WITH SCHEMABINDING
AS
SELECT
b.Employee,
t.Card AS CardID,
t.InstanceID As WWFID,
i.Description as [Digest],
i.CardTypeID AS CardTypeID,
t.Status,
d.CreationDateTime,
COUNT_BIG(*) AS cBig
FROM dbo.[dvtable_{39857033-BDD0-4771-8654-482957FD1338}] as t
INNER JOIN dbo.[dvtable_{E6CEA68A-49EE-4E5C-8F54-E73EFB7EA78F}] as b on b.InstanceID = t.InstanceID
INNER JOIN dbo.dvsys_instances as i on i.InstanceID = t.Card
INNER JOIN dbo.dvsys_instances_date as d on d.instanceid = i.InstanceID
WHERE (i.Deleted IS NULL or i.Deleted = 0) and i.template = 0
GROUP BY
b.Employee,
t.Card,
t.InstanceID,
i.Description,
i.CardTypeID,
t.Status,
d.CreationDateTime
GO
CREATE UNIQUE CLUSTERED INDEX IDX_Tasks ON Tasks(Employee, CardID, WWFID);
4. Иногда мы делаем так же, но это не лучший вариант.
Почему не лучший? Я даже маленький парсер сделал, чтобы можно было задавать не только последовательное согласование, но и смешанное.
Коэффициенты, это хорошо, когда строишь новый дом :) А когда дом старше тебя в 3 раза, есть подозрение, что вычислить получится плюс/минус киллометр. Например, часть дома щитовой (крагис, воздух, крагис, воздух, крагис и т. п.), по расчетам должно быть достаточно тепло, а вот фиг, где-то гуляют сквозники через щели. Где-то балки в фундаменте подгнили и теперь есть щели на улицу. Кто знает, правильно ли утеплили крышу или тоже там всё как и везде :)
Конечно, можно все это утеплить, но, как я понимаю, денег нужно достаточно много, а если топить печь, то в принципе, особой разницы нет, закинуть три ведра или четыре угля.
Да и на -31, это конечно слишком, таких дней в году у нас не больше десятка, соответственно можно и печь затопить. А вот до -20, наверное 80% зимы, как раз должен потянуть зубадан.
Поэтому хотелось бы хоть примерно понять, сколько нужно потратить денег на утепление и, например, зубодан. Чтобы по киловатам не сильно превысить зартаты на уголь :) А для этого, надо понять сколько сейчас реально теплопотери.
За 20 часов, может просто дом не успел остыть? Переживаю за ванну с туалетом.
На счет мощьности — интересно, а можно как-то посчитать текущие теплопотери в домашних условиях, без всяких инфракрасных камер? Интересно, если включить, например, электрообогреватель и посмотреть сможет ли он прогреть дом, соответственно получить примерные теплопотери. Если двух киловатный обогреватель не справляется, значит потери больше двух киловатт, тогда поставить второй и посмотреть. Или я что-то упускаю?
Тоже в начале думал поставить теплые полы или инфракрасники на потолок. Но, рекомендуемая мощьность, для постоянно обогрева — 100 ватт на 1 кв метр. Что даже на «хрущевке» выливается в 6,5 киловатт/час. Жутко дорого выходит.
А какая площадь помещения? Жутко хочется поставить себе зубаданчик, чтобы хотя бы до -15 не думать о печке :) Но, ставить воздух-вода за 200 000 рубликов, жаба задушит.
А вот воздух-воздух, за 70к рублей, не понятно как будет обогревать всю площадь, не будет ли так, что в одной комнате жара, а в других холод?
Сейчас точно не скажу, но вроде проблемы были следующие:
— делегату нужно подсунуть отдельно созданную активити, а жутко не хотелось процесс дробить на несколько файлов;
— не уверен, работают ли закладки во вложенных процессах, вроде как запускает отдельный процесс.
Проблему с bookmarks решил достаточно просто: когда устанавливаю закладку, то сохраняю мета информацию в базу (всё в транзакции).
Проблему с определением того, кто может нажать — в мета информации сохраняется ид пользователя, который может нажать на данную кнопку.
Мета информация примерно следующая:
— название кнопки;
— кто может нажать;
— срок;
— права, которая дает кнопка;
— валидации (например, что должны быть заполнены определённые поля);
— форма запрос (комментария, файла обонования, каких-нибудь пользователей и т. п.).
Соответственно одним запросом по базе можно узнать, кто, что и где может нажать.
Проблему с определением кто ещё должен согласовать и изменением перечня согласующих удалось решить, отказавшись от выделения состояния для каждого вида согласования. Есть просто статус Согласование, а перечень лиц, вообще определяется в настройках системы (или задается пользователем). Соответственно, если нужно подкорректировать процесс, пользователь заходит в настройки и указывает других согласующих лиц. Кстати, это так же позволило сильно снизить количество изменений в процессе, так как его частая изменяемая часть, вообще вынесена в настройки.
Единственное, что красиво пока не удалось решить, это вложенное согласование, так как WWF не поддерживает рекурсии в процессах.
Вы просто думайте о том, что это языки для разных целей.
Я, как-то пробовал использовать C# для скриптования простых задач (для сборки проектов), так жутко… Столько лишних действий, по сравнению с msbuild, хотя там используется синтаксис xml!
Так же и использования C# для простых действий: добавить-удалить узел, обработать событие и т. п. — слишком сложно. Но если Вы делаете громадное приложение в браузере, то использовать javascript очень сложно. Поэтому используют разные конвертеры из языков с типизацией и т. п.
Внезапно в голову закралась мысль, а вдруг, вот эти данные и эти функции, это нечто большее, чем алгоритмы, и решают они какую-то определённую задачу! А может это объект и их можно объединить!? Тут сзади удар чем то тяжелым! И злобное хихиканье javascript'а:" я не позволю тебе думать объектами!".
А Вы знаете, что можно программировать используя принципы ООП совершенно без поддержки со стороны языка! Например, на Assembler'е или в Pascal используя ручную эмуляцию виртуальных функций (так же храним ссылки на методы).
Как мне кажется под ООП подразумевают изменение мыслей в сторону объектов. Если раньше мы размышляли алгоритмами, данными, то теперь стараемся думать объектами. Вот, например, какой-то манеджер, вот словарь, вот интерфейс, вот описание нашего объекта. Полагаю именно это видение позволило думать иначе, строить менее связанные системы, разруливать обязанности и т. п. Хотя так же встречается мнение, что это хорошо проданное под соусом обычное структурное программирование (хотя какая нам разница, главное помогает решать часть проблем).
Есть структурный полиморфизм (утиная типизация)! :)
Да, с виртуальными функция сложнее, но сейчас многие рекомендуют не создавать больших иерархий объектов, не больше двух уровней (интерфейс и реализация). А вместо наследования реализовывать ассоциацию. Причем достаточно много классов в C# помечены атрибутом sealed, запрещающим наследование.
Читал множество критики наследования, всяких уток от птиц и т. п. Так что похоже можно жить без него :)
Вот тут описал их http://pikabu.ru/story/eshchyo_odin_variant_prokhozhdeniya_sapera_3027351
Вот тут моя реализация этих правил на C#
https://www.dropbox.com/s/d4fype0rjfhuc5p/MinesFounder.rar?dl=0
-30 20
-25 31
-20 47
-15 67
-10 60
-5 119
0 34
(от +15 до 0 = 211 дней)
Для интереса, собрал статистику погоды за 2 года (2013-2015) по Караганде.
Итого: 538 дней за два года можно пользоваться кондером и 59 печкой :)
www.zubadan.ru/indexz.php?page=models&model=1718
Теплопроизводительность, кВт 6.00
Потребляемая мощность (обогрев), кВт 1.610
Гарантированный диапазон наружных температур: обогрев -25 … +15°C WB
ай, цена 222 234 (3390 USD) :((
Зубадан, MSZ-FH50VE / MUZ-FH50VEHZ
Тепловой насос
5.0 кВт (охлаждение)
6,0 кВт (обогрев)
Потребляемая мощность 1.55 кВт (при 3 руб киловатт днем, и 50 копеек ночью) — получается даже дешевле угля :)
Единственное не нашел, сколько у него реальная производительность при -20, вроде не меньше 80%. И так как внутренний блок один, то не понятно куда его поставить, чтобы 80 квадратов равномерно отопить.
После -20, да даже и в -20, уже использовать угольную печь. Дом жилой, поэтому автономность ему не нужна.
1. Только сотрудник с ролью Куратор.
Указываем в метаинформации, не конкретного сотрудника, а группу/роль и т. п. Хотя я так не делают, так как согласование должно проходит достаточно быстро (день, неделя, месяц). Поэтому маловероятно, что роль будет меняться так часто. Поэтому указываю конкретного человека из настроек/по условию (прям в wwf) на момент создания кнопки.
Если, что-то изменилось очень срочно, то есть два стандартных механизма для решения таких проблем:
— Замещение.
— Изменить ответственного через службу поддержки (в данный момент это 1 человек на, где-то, 700 ежедневных уникальных пользователей системы, к сожалению, общее количество работающих с системой не знаю). Пока справляется, даже совмещать с другой должностью успевает.
2. В случае отсутствия куратора согласует начальник департамента
Решается через общий механизм замещения.
3. Можете выложить код, как проводите обработку мета-данных?
Выбрать все кнопки, где пользователь является ответстенным. Плюс выбрать все кнопки, где ты замещаешь ответственного. Вот и получается перечень твоих задач.
4. Иногда мы делаем так же, но это не лучший вариант.
Почему не лучший? Я даже маленький парсер сделал, чтобы можно было задавать не только последовательное согласование, но и смешанное.
Пользователь1, Пользователь2=Пользователь3, Пользователь4
Почти все достаточно легко разобрались в этом и очень активно используют.
Конечно, можно все это утеплить, но, как я понимаю, денег нужно достаточно много, а если топить печь, то в принципе, особой разницы нет, закинуть три ведра или четыре угля.
Да и на -31, это конечно слишком, таких дней в году у нас не больше десятка, соответственно можно и печь затопить. А вот до -20, наверное 80% зимы, как раз должен потянуть зубадан.
Поэтому хотелось бы хоть примерно понять, сколько нужно потратить денег на утепление и, например, зубодан. Чтобы по киловатам не сильно превысить зартаты на уголь :) А для этого, надо понять сколько сейчас реально теплопотери.
На счет мощьности — интересно, а можно как-то посчитать текущие теплопотери в домашних условиях, без всяких инфракрасных камер? Интересно, если включить, например, электрообогреватель и посмотреть сможет ли он прогреть дом, соответственно получить примерные теплопотери. Если двух киловатный обогреватель не справляется, значит потери больше двух киловатт, тогда поставить второй и посмотреть. Или я что-то упускаю?
А вот воздух-воздух, за 70к рублей, не понятно как будет обогревать всю площадь, не будет ли так, что в одной комнате жара, а в других холод?
— делегату нужно подсунуть отдельно созданную активити, а жутко не хотелось процесс дробить на несколько файлов;
— не уверен, работают ли закладки во вложенных процессах, вроде как запускает отдельный процесс.
Проблему с bookmarks решил достаточно просто: когда устанавливаю закладку, то сохраняю мета информацию в базу (всё в транзакции).
Проблему с определением того, кто может нажать — в мета информации сохраняется ид пользователя, который может нажать на данную кнопку.
Мета информация примерно следующая:
— название кнопки;
— кто может нажать;
— срок;
— права, которая дает кнопка;
— валидации (например, что должны быть заполнены определённые поля);
— форма запрос (комментария, файла обонования, каких-нибудь пользователей и т. п.).
Соответственно одним запросом по базе можно узнать, кто, что и где может нажать.
Проблему с определением кто ещё должен согласовать и изменением перечня согласующих удалось решить, отказавшись от выделения состояния для каждого вида согласования. Есть просто статус Согласование, а перечень лиц, вообще определяется в настройках системы (или задается пользователем). Соответственно, если нужно подкорректировать процесс, пользователь заходит в настройки и указывает других согласующих лиц. Кстати, это так же позволило сильно снизить количество изменений в процессе, так как его частая изменяемая часть, вообще вынесена в настройки.
Единственное, что красиво пока не удалось решить, это вложенное согласование, так как WWF не поддерживает рекурсии в процессах.
ну или typescript!
Я, как-то пробовал использовать C# для скриптования простых задач (для сборки проектов), так жутко… Столько лишних действий, по сравнению с msbuild, хотя там используется синтаксис xml!
Так же и использования C# для простых действий: добавить-удалить узел, обработать событие и т. п. — слишком сложно. Но если Вы делаете громадное приложение в браузере, то использовать javascript очень сложно. Поэтому используют разные конвертеры из языков с типизацией и т. п.
Внезапно в голову закралась мысль, а вдруг, вот эти данные и эти функции, это нечто большее, чем алгоритмы, и решают они какую-то определённую задачу! А может это объект и их можно объединить!? Тут сзади удар чем то тяжелым! И злобное хихиканье javascript'а:" я не позволю тебе думать объектами!".
:)
Как мне кажется под ООП подразумевают изменение мыслей в сторону объектов. Если раньше мы размышляли алгоритмами, данными, то теперь стараемся думать объектами. Вот, например, какой-то манеджер, вот словарь, вот интерфейс, вот описание нашего объекта. Полагаю именно это видение позволило думать иначе, строить менее связанные системы, разруливать обязанности и т. п. Хотя так же встречается мнение, что это хорошо проданное под соусом обычное структурное программирование (хотя какая нам разница, главное помогает решать часть проблем).
Да, с виртуальными функция сложнее, но сейчас многие рекомендуют не создавать больших иерархий объектов, не больше двух уровней (интерфейс и реализация). А вместо наследования реализовывать ассоциацию. Причем достаточно много классов в C# помечены атрибутом sealed, запрещающим наследование.
Читал множество критики наследования, всяких уток от птиц и т. п. Так что похоже можно жить без него :)