Вот была элементарная ситуация (правда, давно -- полгода назад).
Задача: Выходной день (суббота). Необходимо найти ближайшее работающее отделение Сбербанка, где можно сделать взнос наличными. И как можно скорее (до конца рабочего дня -- а в субботу он короткий).
Исходные данные: Есть только кнопочный телефон (не смартфон), интернета в доступности тоже нет. Карты Сбербанка (действующей) нет.
Голосовой помощник честно пытается помочь, то есть рекомендует посмотреть отделения в приложении или на сайте. Но это же не устраивает -- нет доступа ни к приложению, ни к сайту. А обойти эту рекомендацию никак не удаётся -- ходит по кругу, и не 1-2 раза, а не менее 10 раз. Неужели нельзя предусмотреть защиту от такого "зацикливания"? Просто соединив с оператором хотя бы после 3-го (ну, или 5-го) раза.
P.S. Добраться до оператора всё же удалось, наплетя помощнику какую-то несусветную чушь, в которой он не узнал ни одного слова.
Подход САПёров очень напоминает прокрустово ложе: есть "best practice", и все бизнес-процессы предприятия должны быть перестроены до соответствия этой лучшей практике.
Теоретически, конечно, можно "за-АБАПить" всё что угодно. Но в реальности это "что угодно" потребует даже не миллионы и не десятки миллионов, а гораздо больше. И, даже если удастся выделить достаточный бюджет, под такой проект не найдётся столько САПёров, чтобы его сделать в разумные сроки.
Так что реально -- только Best Practice. Ну, может быть, небольшая адаптация.
С учётом сказанного выше, внедрение SAP -- это всегда очень болезненно. И не всем по плечу.
Да, в этом чувствуется рука "эффективного менеджера".
Сэкономили на копейку, а ущерб получили на многие миллионы.
Нечто подобное было, например, в аварии на Фукусиме: при проектировании этой АЭС возможную потерю электроснабжения собственных нужд сочли "невероятным событием". А оно случилось и повлекло катастрофически последствия.
Вот недавно в ФБ такое случилось. Там тоже не админы?
Там гораздо хуже.
Свои внутренние данные, включая систему контроля доступа, хостить и DNS'ить вместе с пользовательскими базами -- это уже не ошибка и не поспешность. Это, как минимум, вредительство.
Там перечислено много запретов (например, упоминается, что иностранная организация не может работать на УСН -- но это именно иностранная организация, т.е. зарегистрированная в другом государстве). Запрещено применять УСН "дочкам" других организаций ("доля участия других организаций составляет более 25%").
Но вот про учредителей-иностранцев упоминаний нет.
У старых конденсаторов (советских К50-3, К50-6 и более старых КЭ-1, да и у зарубежных тоже) никаких насечек сверху не было.
Цилиндрическая алюминиевая "банка", закрыта фибровой крышечкой с выводами или выводом (второй электрод -- корпус) и завальцована. http://www.155la3.ru/ke1m.htm
Поэтому при "взрыве" оставалась на месте только крышечка с выводами, а всё остальное летело как петарда.
В 80-е годы у нас на ВЦ для охлаждения в окнах стояли Бакинские кондиционеры (по 6 штук в каждом окне). А в каждом -- по конденсатору размером с пивную банку. Лет через 5-6 лет эти конденсаторы подсохли, видимо. И началось... редкий день проходил без фейерверка (и вони). Но других-то кондиционеров не было, поэтому восстанавливали имеющиеся.
это полотно могло бы стать хорошим носителем для ветряков и/или солнечных панелей.
Возможности ВИЭ, к сожалению, несколько переоценены.
Энергию ветра имеет смысл использовать только там, где есть не просто ветер, а сильный ветер. Беда в том, что энергоэффективность ветровой генерации очень сильно зависит от его скорости: зависимость не линейная и даже не квадратичная, а кубичная! Переводя на язык цифр: при скорости ветра менее 8-9 м/с ветряк абсолютно не эффективен (даже себя не окупает). Именно поэтому ветряные электростанции размещают там, где наблюдается постоянный сильный ветер. Чаще всего это бриз -- а он бывает только в приморских районах. Вдоль Транссиба, например, такого нет.
Что касается солнечной генерации, то до последних лет она была экономически неэффективна (реально могла конкурировать только с ДВС-генерацией). Пример -- что стало с солнечной генерацией в Крыму? (Ответ: умерла.) Плюс для повышения КПД приходилось динамически ориентировать панель на солнце. А ещё регулярно очищать панели от загрязнений, способных снизить КПД в разы. Эксплуатационные расходы существенно повышали стоимость владения (TCO).
Впрочем, буквально год-два назад на рынок вышли какие-то новые солнечные панели -- тут важно не столько то, что у них больше КПД, как то, что они существенно дешевле. Дешёвых панелей можно поставить вдвое-втрое-впятеро больше, не заморачиваясь с ориентацией на солнце, а просто монтируя их вертикально (значит, не надо их обметать). Будем надеяться, что это -- начало небольшой энергетической революции.
Ну и, в любом случае, неплохо было бы прикинуть энергетический баланс: сколько энергии потребляет 1 км (или 100 км) линейного города и сколько он способен генерировать из своих источников. Тут, кстати, можно ещё вспомнить про переработку отходов и стоков -- из них ведь можно получать биогаз, это тоже вклад в энергетический баланс города.
Уголь содержит ещё одну очень "милую" примесь -- ртуть, содержание до 0,1 грамма на тонну (среднее -- 0,05 г/т). См. например http://www.nparso.ru/images/docs/Hg_7.pdf
Средняя ТЭЦ за отопительный сезон сжигает порядка 2 млн. т угля. Перемножите одно на другое?
у СУБД данные могут быть в памяти, но еще не оказаться корректно записанными на диск,
Ну, за все СУБД не скажу — а у MS SQL такое невозможно.
Первое действие, которое выполняется при изменении данных в базе — это запись в файл транзакций. Собственно, «метки оси времени» в этой СУБД учитываются в форме LSN (Log Sequence Number, номер записи в файле транзакций).
Это сделано специально: даже если «всё крахнет», данных с диска будет достаточно для корректного возобновления работы БД.
Да, транзакции сначала пишутся в файл транзакций. Только не при коммите, а именно в процессе обработки транзакции. Собственно, любое действие над БД начинается в памяти (в буфере), и потом фиксируется в файле транзакций, тем самым освобождая буфер.
Но сам процесс обработки каждой транзакции может быть очень длительным, к тому же одноврменно могут обрабатываться не одна, а несколько транзакций. Так что до момента коммита (или роллбэка) в файл транзакций может быть записано довольно много записей.
Кстати, с точки зрения механизмов СУБД сам коммит (или роллбэк) транзакции ничего особенного не делает — только снимает блокировки (а вот на чтение-запись не влияет никак).
А для файлов данных гораздо важнее скорость их считывания — но никак не записи. Их запись, вообще-то, асинхронно происходит. Планово. И довольно редко. Так что на скорость работы СУБД практически не влияет.
Подсчёт (и сравнение) общего количества методов (и модулей) в «старых» и «новых» конфигурациях получается не вполне корректным.
Дело в том, что в новых конфигурациях широко используются «библиотеки». И, если одна и та же библиотека входит в состав нескольких конфигураций — её модули и методы оказываются посчитаны многократно.
Было бы неплохо отдельно подсчитать статистику по библиотекам, хотя бы наиболее употребительным, вроде БСП, БПО, БРО и т.п. И исключить (или обособить) их при «обсчёте» конфигураций.
Я думаю, что следующий этап — это более массовое использование расширений.
И регламентированной отчётности, и драйверам из БПО там было бы самое подходящее место.
В отличие от хранения всего этого добра в БД, расширения можно (и нужно) подключать, не входя в режим Предприятие.
Буквально два дня назад для лечения ОРВИ назначили гриппферон (это альфа-интерферон в капельной форме) и... арбидол.
Правда, не ребёнку, а взрослому (женщина 40+ лет).
И -- да, это Россия.
Вот была элементарная ситуация (правда, давно -- полгода назад).
Задача: Выходной день (суббота). Необходимо найти ближайшее работающее отделение Сбербанка, где можно сделать взнос наличными. И как можно скорее (до конца рабочего дня -- а в субботу он короткий).
Исходные данные: Есть только кнопочный телефон (не смартфон), интернета в доступности тоже нет. Карты Сбербанка (действующей) нет.
Голосовой помощник честно пытается помочь, то есть рекомендует посмотреть отделения в приложении или на сайте. Но это же не устраивает -- нет доступа ни к приложению, ни к сайту. А обойти эту рекомендацию никак не удаётся -- ходит по кругу, и не 1-2 раза, а не менее 10 раз. Неужели нельзя предусмотреть защиту от такого "зацикливания"? Просто соединив с оператором хотя бы после 3-го (ну, или 5-го) раза.
P.S. Добраться до оператора всё же удалось, наплетя помощнику какую-то несусветную чушь, в которой он не узнал ни одного слова.
А что "SAP"?
Подход САПёров очень напоминает прокрустово ложе: есть "best practice", и все бизнес-процессы предприятия должны быть перестроены до соответствия этой лучшей практике.
Теоретически, конечно, можно "за-АБАПить" всё что угодно. Но в реальности это "что угодно" потребует даже не миллионы и не десятки миллионов, а гораздо больше. И, даже если удастся выделить достаточный бюджет, под такой проект не найдётся столько САПёров, чтобы его сделать в разумные сроки.
Так что реально -- только Best Practice. Ну, может быть, небольшая адаптация.
С учётом сказанного выше, внедрение SAP -- это всегда очень болезненно. И не всем по плечу.
Да, в этом чувствуется рука "эффективного менеджера".
Сэкономили на копейку, а ущерб получили на многие миллионы.
Нечто подобное было, например, в аварии на Фукусиме: при проектировании этой АЭС возможную потерю электроснабжения собственных нужд сочли "невероятным событием". А оно случилось и повлекло катастрофически последствия.
Там гораздо хуже.
Свои внутренние данные, включая систему контроля доступа, хостить и DNS'ить вместе с пользовательскими базами -- это уже не ошибка и не поспешность. Это, как минимум, вредительство.
Нет, те кто не делает бэкапы -- это "ещё не админы".
ИМХО картинка перевёрнута.
Так часто бывает -- верстают "чтобы кросиво", на надписи ноль внимания.
Простите, неудачно структурировал сообщение.
"Улетает", конечно же, относилось к ртути.
А кадмий, понятно, уходит в шлак.
Вы уверены?
Я в Налоговом кодексе не встречал ничего подобного. См. НК РФ, ст. 346.12, п.3 -- например http://www.consultant.ru/document/cons_doc_LAW_28165/a1d86f7078e645869b02fde85e8c972193557dee/
Там перечислено много запретов (например, упоминается, что иностранная организация не может работать на УСН -- но это именно иностранная организация, т.е. зарегистрированная в другом государстве). Запрещено применять УСН "дочкам" других организаций ("доля участия других организаций составляет более 25%").
Но вот про учредителей-иностранцев упоминаний нет.
У старых конденсаторов (советских К50-3, К50-6 и более старых КЭ-1, да и у зарубежных тоже) никаких насечек сверху не было.
Цилиндрическая алюминиевая "банка", закрыта фибровой крышечкой с выводами или выводом (второй электрод -- корпус) и завальцована. http://www.155la3.ru/ke1m.htm
Поэтому при "взрыве" оставалась на месте только крышечка с выводами, а всё остальное летело как петарда.
В 80-е годы у нас на ВЦ для охлаждения в окнах стояли Бакинские кондиционеры (по 6 штук в каждом окне). А в каждом -- по конденсатору размером с пивную банку. Лет через 5-6 лет эти конденсаторы подсохли, видимо. И началось... редкий день проходил без фейерверка (и вони). Но других-то кондиционеров не было, поэтому восстанавливали имеющиеся.
Возможности ВИЭ, к сожалению, несколько переоценены.
Энергию ветра имеет смысл использовать только там, где есть не просто ветер, а сильный ветер. Беда в том, что энергоэффективность ветровой генерации очень сильно зависит от его скорости: зависимость не линейная и даже не квадратичная, а кубичная! Переводя на язык цифр: при скорости ветра менее 8-9 м/с ветряк абсолютно не эффективен (даже себя не окупает). Именно поэтому ветряные электростанции размещают там, где наблюдается постоянный сильный ветер. Чаще всего это бриз -- а он бывает только в приморских районах. Вдоль Транссиба, например, такого нет.
Что касается солнечной генерации, то до последних лет она была экономически неэффективна (реально могла конкурировать только с ДВС-генерацией). Пример -- что стало с солнечной генерацией в Крыму? (Ответ: умерла.) Плюс для повышения КПД приходилось динамически ориентировать панель на солнце. А ещё регулярно очищать панели от загрязнений, способных снизить КПД в разы. Эксплуатационные расходы существенно повышали стоимость владения (TCO).
Впрочем, буквально год-два назад на рынок вышли какие-то новые солнечные панели -- тут важно не столько то, что у них больше КПД, как то, что они существенно дешевле. Дешёвых панелей можно поставить вдвое-втрое-впятеро больше, не заморачиваясь с ориентацией на солнце, а просто монтируя их вертикально (значит, не надо их обметать). Будем надеяться, что это -- начало небольшой энергетической революции.
Ну и, в любом случае, неплохо было бы прикинуть энергетический баланс: сколько энергии потребляет 1 км (или 100 км) линейного города и сколько он способен генерировать из своих источников. Тут, кстати, можно ещё вспомнить про переработку отходов и стоков -- из них ведь можно получать биогаз, это тоже вклад в энергетический баланс города.
Уголь содержит ещё одну очень "милую" примесь -- ртуть, содержание до 0,1 грамма на тонну (среднее -- 0,05 г/т). См. например http://www.nparso.ru/images/docs/Hg_7.pdf
Средняя ТЭЦ за отопительный сезон сжигает порядка 2 млн. т угля. Перемножите одно на другое?
А ещё в угле присутствует кадмий, его могут быть десятки грамм на тонну, см. например https://ru.wikipedia.org/wiki/%D0%98%D1%81%D0%BA%D0%BE%D0%BF%D0%B0%D0%B5%D0%BC%D1%8B%D0%B9_%D1%83%D0%B3%D0%BE%D0%BB%D1%8C
Всё это улавливается очень трудно -- в значительной части улетает с дымом.
Эйлер был швейцарцем (Базель), но жил и работал в России, а позже в Германии (точнее, Пруссии). Впрочем, из швейцарского подданства он не выходил.
Ну, за все СУБД не скажу — а у MS SQL такое невозможно.
Первое действие, которое выполняется при изменении данных в базе — это запись в файл транзакций. Собственно, «метки оси времени» в этой СУБД учитываются в форме LSN (Log Sequence Number, номер записи в файле транзакций).
Это сделано специально: даже если «всё крахнет», данных с диска будет достаточно для корректного возобновления работы БД.
Да, транзакции сначала пишутся в файл транзакций. Только не при коммите, а именно в процессе обработки транзакции. Собственно, любое действие над БД начинается в памяти (в буфере), и потом фиксируется в файле транзакций, тем самым освобождая буфер.
Но сам процесс обработки каждой транзакции может быть очень длительным, к тому же одноврменно могут обрабатываться не одна, а несколько транзакций. Так что до момента коммита (или роллбэка) в файл транзакций может быть записано довольно много записей.
Кстати, с точки зрения механизмов СУБД сам коммит (или роллбэк) транзакции ничего особенного не делает — только снимает блокировки (а вот на чтение-запись не влияет никак).
А для файлов данных гораздо важнее скорость их считывания — но никак не записи. Их запись, вообще-то, асинхронно происходит. Планово. И довольно редко. Так что на скорость работы СУБД практически не влияет.
Дело в том, что в новых конфигурациях широко используются «библиотеки». И, если одна и та же библиотека входит в состав нескольких конфигураций — её модули и методы оказываются посчитаны многократно.
Было бы неплохо отдельно подсчитать статистику по библиотекам, хотя бы наиболее употребительным, вроде БСП, БПО, БРО и т.п. И исключить (или обособить) их при «обсчёте» конфигураций.
И регламентированной отчётности, и драйверам из БПО там было бы самое подходящее место.
В отличие от хранения всего этого добра в БД, расширения можно (и нужно) подключать, не входя в режим Предприятие.
Когда же следующая глава?