Если у вас плохо расположены выключатели, то где гарантия, что все остальное сделано нормально? Если электрик делал абы как, то скорее всего там все так сделано.
Ну я как-то и так за один поход все делаю Пришел, включил чайник. Пока чашку достал, пока то-се - он уже вскипел. Налил и ушел.
С выключателями - просто думать надо на этапе проектирования. Да, все включатели расположены так, чтобы ими было удобно пользоваться. В спальнях на основной свет вообще три стоит - один у входа (зашел-включил) и еще два у кроватей с каждой стороны (разделся-лег-выключил).
Лестница и прихожая - обычные проходные (на входе и выходе).
В общей комнате (большая гостиная с кухонной зоной) 4 группы основного света + 2 группы локальной подсветки. Да я задолбаюсь каждый раз объяснять этой дуре что именно надо включить...
Это не студия с одной лампочкой. Это дом с тремя спальнями, общей комнатой, кабинетом, двумя санузлами, прихожей, лестницей (две площадки...)
При правильном расположении выклчателей вообще никаких неудобств. Нужный моментально включается просто на ощупь в нужной точке.
Ну я так и подумал, что тестовые денные. С этой точки зрения я бы делал генератор, который подает эти данные на вход реальной системы У нас это называется "модуль внешнего ввода" - наша система ведения таблицы состоит из четырех модулей - интерактив, внешний ввод, валидатор и собственно занесение в таблицу. Данные могут как вводиться руками (модуль интерактивного ввода), так и подаваться извне в виде некой заполненной структуры (модуль внешнего ввода). Дальше они попадают в валидатор и оттуда, если не было ошибок, уже уходят в модуль записи.
И для полноты тест-кейсов в генератор нужно закладывать возможность генерации ошибочных данных. Именно для контроля валидатора.
Мои примеры - из моей жизни. Я (в том числе) занимаюсь клиентскими данными. А в банке это очень большой объем. Тут и ФИО/наименование, и контактные данные, и адреса (а их штук пять разных типов - почтовый, юридический, регистрации, фактического нахождения...), разные ИНН/СНИЛС/ОГРН и т.п. (для разных типов клиентов, а их тоже не два - физики, юрики, ипшники, банки, уполномоченные лица, третьи лица...), ДУЛы (документы, удостоверяющие личность) - основной, неосновные... В общем, там огромный зоопарк разных данных и вариантов разных противоречий огромное количество. Логика валидации достаточно сложная в общем случае - проверок разных очень много.
Естественно, все это покрыто достаточно объемными автотестами. Но сценарии пишем руками (обычно аналитики или тестировщик этим занимаются). В том числе есть сценарии которые должны приводить к ошибкам валидации - это тоже контролируется - ожидаемым результатом может быть и код ошибки определенный (что именно не прошло валидацию).
И у нас "карточка клиента" (это ведение клиентов - изменение или добавление записи) для каждого типа клиента отдельная. Отдельно для ОП, отдельно для ФЛ, отдельно для ЮЛ, для банков... Потому что и логика валидации отличается и набор данных. Да и хранится в разных таблицах в итоге с разной структурой (хотя есть и общая таблица клиентов и общая таблица допинфо по клиентам и общая таблица адресов, ДУЛов для тех типов у кого они есть...)
Идеальным примером бессмысленной автоматизации может служить концепция "умного дома" с подключёнными к интернету лампочками, розетками и шторами.
...
Вот это я недавно пытался объяснить одному "энтузиасту".
Какой смысл в "умном чайнике" если надо встать, дойти до чайника, налить в него воды, вернуться на диван, включить чайник с телефона (или сказать Алисе чтобы она включила чайник), дождаться оповещения что вскипело, встать, дойти до чайника, налить чай, вернуться на диван и выпить его...
Какой смысл в "умных выключателях" когда у меня на лестнице стоят обычные проходные - вверху и внизу. И проще просто подходя к лестнице внизу ткнуть рукой чтобы свет включился, подняться и отходя наверху опять ткнуть рукой чтобы выключился. Это дешевле, проще и быстрее чем вызывать дух условной Алисы и объяснять ей где именно мне надо включить или выключить свет.
И даже такие системы жизнеобеспечения как отопление и вентиляция строятся достаточно просто - на принципе обратной связи для данного конкретного устройства. Поддержание заданной температуры или влажности не требуют каких-то "серверов" и "сценариев". С этим вполне справляется обычный термостат или контроллер влажности. С очень примитивной (практически релейной) логикой. Та же влажность в двух санузлах с одним центральным вытяжным вентилятором реализована на двух тупых контроллерах (которым задается порог включения и порог выключения - копеечная коробочка с Али) а с вентилятором все это сопрягается на трех обычных релюшках (там же еще добавлена клавиша ручного включения на всякий случай, за пять лет не пользовался ни разу).
Я не говорю уже о том, что когда все это завязано на один сервер и если этот сервер вдруг гавкнется, то вся "автоматизация" идет по звезде. Что вообще противоречит всем принципам классической промавтомазизации (если что пару десятков лет занимался сначала разработкой, потом развитием системы мониторинга инженерного оборудования зданий, вообще с нуля делали и набили немало шишек на том, как все это на самом деле должно быть устроено и реализовано для надежной работы).
Пол настоящий, имя настоящее, диагноз из справочника. Просто вместе они дают человека, которого не бывает.
Сейчас все бывает :-)
А если серьезно - это про что вообще? Генератор каких-то тестовых данных? Или что?
В реальной жизни любой ввод данных должен проходить через валидатор. Который будет отслеживать такие вот противоречия (типа того как если вы заводите клиента ФЛ, но указываете ему 10-значный ИНН который может быть только у ЮЛ, или ставите гражданство Беларусь, но основной ДУЛ - паспорт РФ и т.д. и т.п.).
В целом все верно - для разного типа клиентов набор данных может быть сильно разным (например, в ЮЛ и ФЛ будут совершенно разные наборы данных, у мужчин и женщин разные наборы диагностических процедур и специалистов). И вам неизбежно придется ветвится в какой-то момент. В пределе - с самого начала (ввод клиента ФЛ и ввод клиента ЮЛ это разные процедуры, разные карточки, аналогично ввод пациента мужчины и пациента женщины).
Эксперименты с интерфейсом - да, раздражают. Мне комп не для игрищ с ним нужен, а как рабочий инструмент. Как в мастерской - должен знать что где лежит, а не искать каждый раз.
А с обновлениями (на 10-ке) как раз проблем не было никогда. Стояло "обновлять только обязательное" и "обновлять в период неактивности" (ночью - комп вообще не выключаю). Так я даже не замечал чего оно там и когда обновляет.
Все верно. Но "специальность" АСки не в ее объектности а совершенно в других вещах - интегрированной в ОС БД, например. Или работа в изолированных заданиях (job) - это чисто серверная история, оринтирована прежде всего на многопользовательское использование, для десктопа можно реализовать, но излишне.
А принцип "все есть объект" вполне универсален и может быть реализован в любой ОС. Нормальная система команд с едиными правилами мнемоники тоже может быть реализована в любой ОС
The IBM developers standardized the abbreviations used to create command names. Verbs like change are always rendered as CHG, display as DSP, work as WRK, create as CRT, etc. Subjects like program are always PGM, user is USR, module is MOD, server is SVR, etc. You can see every possible verb and subject used on the system in the VERB and SUBJECT menus, just enter the commands GO VERB or GO SUBJECT.
И сам принцип "команда есть оболочка для запуска программы" тоже может быть реализован в любой ОС. На уровне команды производится контроль ввода обязательных параметров, передача дефолтных значений для необязательных, контроль типов параметров и т.п. Тут тоже нет ничего специального.
Одноуровневая (SINGLE LEVEL) модель памяти с 128-бит указателями где кроме адреса еще некоторая служебная информация (теги) хранится. Тут тоже ничего "специального" нет.
Она не для того. Это вообще чисто серверная система для высокопроизводительных коммерческих серверов. У нее нет графического интерфейса. Работа только через терминал к удаленному серверу.
И при чем тут "объект печатная плата"?
"Все есть объект" - это про систему. Нет файлов - есть объекты. У каждого объекта есть тип, который определяет набор его свойств и набор допустимых действий с ним. Дополнительно к типу могут быть еще атрибуты.
Например, программа - есть объект типа *PGM.
Есть объекты типа *FILE - они все имеют одинаковую внутреннюю структуру и могут быть описаны на DDS (Data Defenition Specifications) но конкретная сущность описывается дополнительным атрибутом - pf-dta физический фал данных (таблица БД), lf - логический файл (индекс), pf-src - физический файл исходных текстов, prtf - принтерная форма, dspf - экранная форма...
Очередь данных - *DTAQ, очередь сообщений -*MSGQ...
Нет папок - есть "библиотеки" (библиотека - это тоже объект типа *LIB).
Если кому-то придет в голову рисовать там печатные платы (написать софт для рисования) - ну ок. Но каждая плата будет просто неким набором данных которые будут хранится в каком-то виде в БД.
Просто речь о том, что можно строить ОС на совершенно иных, по сравнению с виндой или линуксом (которые по сути достаточно похожи идеологически) принципах.
А еще в АСке стройная и логичная система команд с понятной мнемоникой для каждой где не надо запоминать все 100500 параметров для каждой команды. И если что и забыл или не знаешь - есть поиск нужной команды через SLTCMD.
После нее линукс воспринимается системой, написанной толпой рептилоидов контрибьютеров разной степени обкурки.
По-моему, все это решается на уровне админимстрирования.
Боевой и тестовые сервера физически разделены и между собой не пересекаются. Доступ к боевому серверу крайне ограничен - фактически он есть только у сопровождения. И только сопровождение может установить поставку на боевой сервер. По заявке и при условии заполнения длинного чеклиста (пройдены все уровни тестирования - компонентное, бизнес, интеграционное, нагрузочное...)
Тестовый сервер, в свою очередь, разделен на юниты с разными правами доступа. И у разработчика есть доступ на изменения только в песочницы - копии компонентных юнитов которые в любой момент можно пересоздать просто нажатием кнопки. Во все остальные (компонентные, бизнес, интеграционные и т.п.) юниты доступ профайлам разработчика только на чтение.
С QNX я знаком только поверхностно как бывший обладатель телефона Blackberry Z30.
А вот АС-ка - мой хлеб насущный последние 9 лет :-) Пишу под нее. В камменте ссылка на книжку Солтиса "Основы AS/400". Там очень много технических подробностей как оно устроено внутри.
Понятно, что все это не воспроизвести, но вдруг какие-то идеи возникнут...
С ней даже можно попробовать познакомиться вживую :-) Есть публичный бесплатный сервер PUB400 Достаточно зарегистрироваться и получить логин-пароль. А дальше можно подключаться к серверу телнетом (минимальный вариант) или взять официальный (бесплатный же) пакет IBM i Access Client Solutions в составе которого есть эмулятор терминала IBM5250.
Но там с кондачка может не сразу получиться :-) Специфическая (хотя и очень стройная, логичная и понятная) система команд, вместо файлов объекты разных типов, вместо папок - библиотеки, БЛ интегрирована в систему, компиляторы языков интегрированы в систему. В общем, очень мощная и интересная штука.
У нас наоборот. Административно входим в состав города - "Муниципальное образование г.Екатеринбург, пос.Палкинский торфяник..." Ходит городской автобус, асфальтовая дорога, от выезда из города 10км. Рядом еще ж/д станция. Есть интернет (оптика), все операторы мобильной связи (вышка в поселке). Даже кладбище свое есть.
Два магазина вполне нормальных для уровня "шаговой доступности". 10км до ближайшего ТЦ (Мега на выезде из города). Там де Лемана Про, Metro C&C. Чуть подальше еще один ТЦ (Радуга - О'Кей, Хофф и т.п.). Доставка, такси - все без проблем.
Земля тут дорогая, да и не продается практически ничего. Очень редко кто-то продает... Много постоянных жителей. Практически нет алкашей, воровства, все спокойно. Но вместе с тем нет лишнего пафоса.
В домах с монолитным каркасом звук отлично распространяется по этому самому каркасу.
Дочка у меня - главный инженер в УК. У них этих объектов на обслуживании... Когда себе квартиру искала, даже не смотрела в сторону всех этих новостроек. Только вторичка и только кирпич или блоки.
Ну вот жители современных монолитных домов и даже домов с каркасным монолитом жалуются на очень плохую звукоизоляцию по сравнению с любым кирпичным домом или домом из разного рода блоков (те же "хрущевки" по планировке у нас, например можно найти не только панельные, но и из шлакоблоков с очень толстыми стенами - вот там и теплоизоляция и звукоизоляция реально на высоте).
Если у вас плохо расположены выключатели, то где гарантия, что все остальное сделано нормально? Если электрик делал абы как, то скорее всего там все так сделано.
Он же беспроводной... И питание тоже, видимо...
И это, конечно, абсолютно бесплатно...
А электрика - пусть остается кривой, "и так сойдет" (с)
Хорошо когда "свет" это одна лампочка...
А городить "умный" дом будут? Это, кстати, если все по уму делать, намного сложнее чем перепроложить электрику.
Ну я как-то и так за один поход все делаю Пришел, включил чайник. Пока чашку достал, пока то-се - он уже вскипел. Налил и ушел.
С выключателями - просто думать надо на этапе проектирования. Да, все включатели расположены так, чтобы ими было удобно пользоваться. В спальнях на основной свет вообще три стоит - один у входа (зашел-включил) и еще два у кроватей с каждой стороны (разделся-лег-выключил).
Лестница и прихожая - обычные проходные (на входе и выходе).
В общей комнате (большая гостиная с кухонной зоной) 4 группы основного света + 2 группы локальной подсветки. Да я задолбаюсь каждый раз объяснять этой дуре что именно надо включить...
Это не студия с одной лампочкой. Это дом с тремя спальнями, общей комнатой, кабинетом, двумя санузлами, прихожей, лестницей (две площадки...)
При правильном расположении выклчателей вообще никаких неудобств. Нужный моментально включается просто на ощупь в нужной точке.
Ну я так и подумал, что тестовые денные. С этой точки зрения я бы делал генератор, который подает эти данные на вход реальной системы У нас это называется "модуль внешнего ввода" - наша система ведения таблицы состоит из четырех модулей - интерактив, внешний ввод, валидатор и собственно занесение в таблицу. Данные могут как вводиться руками (модуль интерактивного ввода), так и подаваться извне в виде некой заполненной структуры (модуль внешнего ввода). Дальше они попадают в валидатор и оттуда, если не было ошибок, уже уходят в модуль записи.
И для полноты тест-кейсов в генератор нужно закладывать возможность генерации ошибочных данных. Именно для контроля валидатора.
Мои примеры - из моей жизни. Я (в том числе) занимаюсь клиентскими данными. А в банке это очень большой объем. Тут и ФИО/наименование, и контактные данные, и адреса (а их штук пять разных типов - почтовый, юридический, регистрации, фактического нахождения...), разные ИНН/СНИЛС/ОГРН и т.п. (для разных типов клиентов, а их тоже не два - физики, юрики, ипшники, банки, уполномоченные лица, третьи лица...), ДУЛы (документы, удостоверяющие личность) - основной, неосновные... В общем, там огромный зоопарк разных данных и вариантов разных противоречий огромное количество. Логика валидации достаточно сложная в общем случае - проверок разных очень много.
Естественно, все это покрыто достаточно объемными автотестами. Но сценарии пишем руками (обычно аналитики или тестировщик этим занимаются). В том числе есть сценарии которые должны приводить к ошибкам валидации - это тоже контролируется - ожидаемым результатом может быть и код ошибки определенный (что именно не прошло валидацию).
И у нас "карточка клиента" (это ведение клиентов - изменение или добавление записи) для каждого типа клиента отдельная. Отдельно для ОП, отдельно для ФЛ, отдельно для ЮЛ, для банков... Потому что и логика валидации отличается и набор данных. Да и хранится в разных таблицах в итоге с разной структурой (хотя есть и общая таблица клиентов и общая таблица допинфо по клиентам и общая таблица адресов, ДУЛов для тех типов у кого они есть...)
Вот это я недавно пытался объяснить одному "энтузиасту".
Какой смысл в "умном чайнике" если надо встать, дойти до чайника, налить в него воды, вернуться на диван, включить чайник с телефона (или сказать Алисе чтобы она включила чайник), дождаться оповещения что вскипело, встать, дойти до чайника, налить чай, вернуться на диван и выпить его...
Какой смысл в "умных выключателях" когда у меня на лестнице стоят обычные проходные - вверху и внизу. И проще просто подходя к лестнице внизу ткнуть рукой чтобы свет включился, подняться и отходя наверху опять ткнуть рукой чтобы выключился. Это дешевле, проще и быстрее чем вызывать дух условной Алисы и объяснять ей где именно мне надо включить или выключить свет.
И даже такие системы жизнеобеспечения как отопление и вентиляция строятся достаточно просто - на принципе обратной связи для данного конкретного устройства. Поддержание заданной температуры или влажности не требуют каких-то "серверов" и "сценариев". С этим вполне справляется обычный термостат или контроллер влажности. С очень примитивной (практически релейной) логикой. Та же влажность в двух санузлах с одним центральным вытяжным вентилятором реализована на двух тупых контроллерах (которым задается порог включения и порог выключения - копеечная коробочка с Али) а с вентилятором все это сопрягается на трех обычных релюшках (там же еще добавлена клавиша ручного включения на всякий случай, за пять лет не пользовался ни разу).
Я не говорю уже о том, что когда все это завязано на один сервер и если этот сервер вдруг гавкнется, то вся "автоматизация" идет по звезде. Что вообще противоречит всем принципам классической промавтомазизации (если что пару десятков лет занимался сначала разработкой, потом развитием системы мониторинга инженерного оборудования зданий, вообще с нуля делали и набили немало шишек на том, как все это на самом деле должно быть устроено и реализовано для надежной работы).
Сейчас все бывает :-)
А если серьезно - это про что вообще? Генератор каких-то тестовых данных? Или что?
В реальной жизни любой ввод данных должен проходить через валидатор. Который будет отслеживать такие вот противоречия (типа того как если вы заводите клиента ФЛ, но указываете ему 10-значный ИНН который может быть только у ЮЛ, или ставите гражданство Беларусь, но основной ДУЛ - паспорт РФ и т.д. и т.п.).
В целом все верно - для разного типа клиентов набор данных может быть сильно разным (например, в ЮЛ и ФЛ будут совершенно разные наборы данных, у мужчин и женщин разные наборы диагностических процедур и специалистов). И вам неизбежно придется ветвится в какой-то момент. В пределе - с самого начала (ввод клиента ФЛ и ввод клиента ЮЛ это разные процедуры, разные карточки, аналогично ввод пациента мужчины и пациента женщины).
Эксперименты с интерфейсом - да, раздражают. Мне комп не для игрищ с ним нужен, а как рабочий инструмент. Как в мастерской - должен знать что где лежит, а не искать каждый раз.
А с обновлениями (на 10-ке) как раз проблем не было никогда. Стояло "обновлять только обязательное" и "обновлять в период неактивности" (ночью - комп вообще не выключаю). Так я даже не замечал чего оно там и когда обновляет.
Все верно. Но "специальность" АСки не в ее объектности а совершенно в других вещах - интегрированной в ОС БД, например. Или работа в изолированных заданиях (job) - это чисто серверная история, оринтирована прежде всего на многопользовательское использование, для десктопа можно реализовать, но излишне.
А принцип "все есть объект" вполне универсален и может быть реализован в любой ОС. Нормальная система команд с едиными правилами мнемоники тоже может быть реализована в любой ОС
И сам принцип "команда есть оболочка для запуска программы" тоже может быть реализован в любой ОС. На уровне команды производится контроль ввода обязательных параметров, передача дефолтных значений для необязательных, контроль типов параметров и т.п. Тут тоже нет ничего специального.
Одноуровневая (SINGLE LEVEL) модель памяти с 128-бит указателями где кроме адреса еще некоторая служебная информация (теги) хранится. Тут тоже ничего "специального" нет.
Она не для того. Это вообще чисто серверная система для высокопроизводительных коммерческих серверов. У нее нет графического интерфейса. Работа только через терминал к удаленному серверу.
И при чем тут "объект печатная плата"?
"Все есть объект" - это про систему. Нет файлов - есть объекты. У каждого объекта есть тип, который определяет набор его свойств и набор допустимых действий с ним. Дополнительно к типу могут быть еще атрибуты.
Например, программа - есть объект типа *PGM.
Есть объекты типа *FILE - они все имеют одинаковую внутреннюю структуру и могут быть описаны на DDS (Data Defenition Specifications) но конкретная сущность описывается дополнительным атрибутом - pf-dta физический фал данных (таблица БД), lf - логический файл (индекс), pf-src - физический файл исходных текстов, prtf - принтерная форма, dspf - экранная форма...
Очередь данных - *DTAQ, очередь сообщений - *MSGQ...
Нет папок - есть "библиотеки" (библиотека - это тоже объект типа *LIB).
Если кому-то придет в голову рисовать там печатные платы (написать софт для рисования) - ну ок. Но каждая плата будет просто неким набором данных которые будут хранится в каком-то виде в БД.
Просто речь о том, что можно строить ОС на совершенно иных, по сравнению с виндой или линуксом (которые по сути достаточно похожи идеологически) принципах.
Вот да. Только хотел упомянуть :-)
А еще в АСке стройная и логичная система команд с понятной мнемоникой для каждой где не надо запоминать все 100500 параметров для каждой команды. И если что и забыл или не знаешь - есть поиск нужной команды через SLTCMD.
После нее линукс воспринимается системой, написанной толпой
рептилоидовконтрибьютеров разной степени обкурки.По-моему, все это решается на уровне админимстрирования.
Боевой и тестовые сервера физически разделены и между собой не пересекаются. Доступ к боевому серверу крайне ограничен - фактически он есть только у сопровождения. И только сопровождение может установить поставку на боевой сервер. По заявке и при условии заполнения длинного чеклиста (пройдены все уровни тестирования - компонентное, бизнес, интеграционное, нагрузочное...)
Тестовый сервер, в свою очередь, разделен на юниты с разными правами доступа. И у разработчика есть доступ на изменения только в песочницы - копии компонентных юнитов которые в любой момент можно пересоздать просто нажатием кнопки. Во все остальные (компонентные, бизнес, интеграционные и т.п.) юниты доступ профайлам разработчика только на чтение.
Да было такое в 90-х. Тоже пользовался FTP over UUCP. Если совсем не отшибает память, там еще можно было поиск файла по ftp серверам заказывать...
Ну если что - в личку. Есть много документации разной.
С QNX я знаком только поверхностно как бывший обладатель телефона Blackberry Z30.
А вот АС-ка - мой хлеб насущный последние 9 лет :-) Пишу под нее. В камменте ссылка на книжку Солтиса "Основы AS/400". Там очень много технических подробностей как оно устроено внутри.
Понятно, что все это не воспроизвести, но вдруг какие-то идеи возникнут...
С ней даже можно попробовать познакомиться вживую :-) Есть публичный бесплатный сервер PUB400 Достаточно зарегистрироваться и получить логин-пароль. А дальше можно подключаться к серверу телнетом (минимальный вариант) или взять официальный (бесплатный же) пакет IBM i Access Client Solutions в составе которого есть эмулятор терминала IBM5250.
Но там с кондачка может не сразу получиться :-) Специфическая (хотя и очень стройная, логичная и понятная) система команд, вместо файлов объекты разных типов, вместо папок - библиотеки, БЛ интегрирована в систему, компиляторы языков интегрированы в систему. В общем, очень мощная и интересная штука.
У нас наоборот. Административно входим в состав города - "Муниципальное образование г.Екатеринбург, пос.Палкинский торфяник..." Ходит городской автобус, асфальтовая дорога, от выезда из города 10км. Рядом еще ж/д станция. Есть интернет (оптика), все операторы мобильной связи (вышка в поселке). Даже кладбище свое есть.
Два магазина вполне нормальных для уровня "шаговой доступности". 10км до ближайшего ТЦ (Мега на выезде из города). Там де Лемана Про, Metro C&C. Чуть подальше еще один ТЦ (Радуга - О'Кей, Хофф и т.п.). Доставка, такси - все без проблем.
Земля тут дорогая, да и не продается практически ничего. Очень редко кто-то продает... Много постоянных жителей. Практически нет алкашей, воровства, все спокойно. Но вместе с тем нет лишнего пафоса.
В домах с монолитным каркасом звук отлично распространяется по этому самому каркасу.
Дочка у меня - главный инженер в УК. У них этих объектов на обслуживании... Когда себе квартиру искала, даже не смотрела в сторону всех этих новостроек. Только вторичка и только кирпич или блоки.
Ну вот жители современных монолитных домов и даже домов с каркасным монолитом жалуются на очень плохую звукоизоляцию по сравнению с любым кирпичным домом или домом из разного рода блоков (те же "хрущевки" по планировке у нас, например можно найти не только панельные, но и из шлакоблоков с очень толстыми стенами - вот там и теплоизоляция и звукоизоляция реально на высоте).