У нас в 2010 в Йоханнесбурге убили начальника южноафриканского отделения. Забрались в дом и пытали, чтоб узнать коды от электронных замков. Потом поехали в офис и выгребли всю оргтехнику, хорошо хоть семью не тронули. Даже колючая проволока и охранники на въезде в квартал не всегда помогают.
Конструкцию можно слегка упростить, а заодно и сильно смасштабировать.
Гелиостаты не нужны, будем просто греть солнцем. Плотность энергии будет поменьше, но скомпенсируем это увеличением нижнего бака.
Впрочем, нижний бак и не нужен — пусть солнце греет воду в озере или море. Зачем строить, если можно найти подходящее место в природе? Не герметично, конечно, но компенсируем потери радикальным увеличением размера установки.
На трубе для подъёма пара тоже можно сэкономить — пар тёплый, поднимется сам. Медленней чем по узкой трубе, но что-нибудь придумаем.
На место поднявшегося пара с прилегающих окрестностей устремится более холодный воздух. По сравнению с начальной конструкцией воздух стал двигаться медленней, но зато его теперь очень много. Первая турбина нужна другой конструкции — положим её горизонатально, уменьшим количество лопаток до трёх, но удлинним их метров до 80, назвав лопастями. Чтоб собрать энергию с больших объёмов воздуха турбину водрузим на стометровую башню. Можно поставить целый парк таких турбин.
Без верхнего бака тоже можно обойтись — на высоте атмосфера холодная и пар как-нибудь сконденсируется сам. Из-за отсутсвия стенок бака часть уйдёт в сторону и покинет установку, но есть и вероятность что к нам залетит "чужое" облако с дармовым паром. В среднем это скомпенсирует потери из-за отсутсвия бака.
Нисходящая труба тоже не нужна — сконденсировавшаяся вода сама выпадет дождём. Трудно предсказать куда, но мы знаем, что осадки будут стекать в сторону понижения рельефа, образуя реки.
Вот в русле реки мы и поставим вторую турбину. Построив плотину можно увеличить напор воды и ещё более поднять эффективности установки!
А что бы почитать про построение ETL систем? Чтоб не только базовый синтаксис SQL команд, а с упором на часто встречающиеся паттерны при необходимости синхронизировать данные между несколькими системами, включая историю изменений.
It’s easy to spot the difference between bad error-code-based code and not-bad error-code-based code: The not-bad error-code-based code checks error codes. The bad error-code-based code never does. Admittedly, it’s hard to tell whether the errors were handled correctly, but at least you can tell the difference between bad code and code that isn’t bad. (It might not be good, but at least it isn’t bad.)
On the other hand, it is extraordinarily difficult to see the difference between bad exception-based code and not-bad exception-based code.
Consequently, when I write code that is exception-based, I do not have the luxury of writing bad code first and then making it not-bad later. If I did that, I wouldn’t be able to find the bad code again, since it looks almost identical to not-bad code.
My point isn’t that exceptions are bad. My point is that exceptions are too hard and I’m not smart enough to handle them.
В прошедшем декабре энтузиасты ИИ начали решать задачи с Advent of Code при помощи ChatGPT и ему подобных, что вызвало негодование живых пользователей. Многие проходят AoC ради развлечения, но некоторые люди пришли действительно посоревноваться, а верхушка таблицы рекордов занимается роботами пока человеки всё ещё читают условие очередной задачи. Дней через пять, по мере усложнения задач, роботы сдулись, но успех всё равно впечатляющий.
Легко сделать парашют который будет служить пожизненно. Также этот принцип нетрудно распространить на автомобильные тормоза или газовые котлы. Вот с лампочками, да, будет трудновато.
Достаточно обязать законом указывать сроки производства запчасей и выпуска апдейтов на упаковке (плюс контроль за соблюдением), а там уж рынок порешает. Кто-то меняет телефоны раз в год и не хочет переплачивать за многолетнюю поддержку, а кому-то люб условный айфон и человек готов платить больше денег чтоб получать патчи и через пять лет.
Главное чтоб покупатель мог сделать осознанный выбор, а не действовать из худших предположений — иначе получим "рынок лимонов"
Несколько лет назад читал рассуждения на подобную тему, какжется в блоге у Kalzumeus, но навскидку статью не нашёл. Пересказываю по памяти:
Работникам поддержки платят за количество закрытых тикетов, с их точки зрения это единственный важный критерий. Отписываться бездумным копи-пастом вполне прагматичная стратегия — не надо напрягаться и когда-нибудь клиенту надоест и тикет можно будет закрыть из-за отсутсвия последующих обращений. Бесполезно ругаться с работникаи поддержки или угрожать — скорей всего они не работают в головном предприятии, а сидят где-нибудь в Индии и давно уже привыкли что люди с хорошим настроением к ним не обращаются.
Другое дело юристы — их работа отводить возможные угрозы от фирмы и уменьшать риски. Количество не так важно, ведь даже один проигранный иск может обернуться многомиллионными потерями. У юриста тоже есть выбор — вникать в суть жалобы, вспоминать законы и писать официальный ответ, который может положить начало длинной переписке и закончиться тяжбой в суде, или же позвонить менеджеру в соседний отдел, попросить разблокировать приложение чтоб клиент успокоился, и уже через минуту гордо докладывать начальству что была на корню устранена пусть и небольшая, но всё же ненулевая угроза судебного разбирательства. Ключевой момент в том, что юристы уже внутри фирмы (причём не последние люди) и для них метрикой успеха является скорейшее прекращение спора, особенно если фирме это ничего не стоит.
В статье советовалось при общении с поддержкой, если проблему с налёта решить не удалось, максимально ссылаться на параграфы правил и законы. Официально запрашивать максимум информации, сразу упоминая установленные законом сроки ответа. Цель игры — создать впечатление человека готовящего документы для судебного иска. Тогда ваш тикет перебросят юристам, а там шансы на успех намного больше, даже если ваши требования слабо подкреплены законом — достаточно чтоб они выглядели потенциально рискованными для фирмы и юристу было проще потратить пару минут на звонок чем разбираться в деталях.
Да, помню году этак в 1999 привезли к нам в Молдавию из России компьютеры марки Vist, на них был Диско Командир. Чем запомнился — в отличие от текстового FAR он работал в графическом режиме и лучше использовал разрешение мониторов 1024x768.
Целевой аудиторией продуктов Петера были инженеры, и образ мужика в рубашке с закатанными рукавами сразу стал запоминающейся торговой маркой. После поглощения Symantec те заменили его на свой логотип, но пользователи перестали узнавать бренд и новым эффективным менеджерам пришлось вернуть его назад.
Нашлось на полке
PS: До сих пор иногда пользуюсь Norton Commander для обмена файлами между Windows 10 и Olivetti M24 (1986 год, 8086, MSDOS 3.21). Чем возиться с пятидюймовыми дискетами, гораздо проще поднять Commander Link и перебросить файлы через COM-порт по нульмодемному кабелю.
Не всем подходит потогонный режим работы в компаниях Илона, но тоже думаю, что найдётся немало желающих получить ачивку «Работал инженером в Твиттере, ПОСЛЕ ТОГО, как Маск выгнал оттуда всех бездельников»
IBAN содержит контрольные цифры, фактически предотвращая ошибки при ручном вводе. Так что да, iban длиннее, но удобнее номера телефона.
Так "светлячков" и не заметят — любые непонятные вещи в небе на США по-привычке спишут на Китай.
Благодарю! Кимбал это как раз то что надо
Мы на техническом ресурсе, так что не помешает и видео где Бен Итер реверсит устройство и вычитывает из ПЗУ словарь блокируемых слов.
У нас в 2010 в Йоханнесбурге убили начальника южноафриканского отделения. Забрались в дом и пытали, чтоб узнать коды от электронных замков. Потом поехали в офис и выгребли всю оргтехнику, хорошо хоть семью не тронули. Даже колючая проволока и охранники на въезде в квартал не всегда помогают.
Конструкцию можно слегка упростить, а заодно и сильно смасштабировать.
При тяжёлом тросе сила на моторе/генераторе барабана будет зависеть от положения груза, что дополнительно усложняет механику и электронику.
А если дождь пойдёт, то осталось больше чем запасли!
А что бы почитать про построение ETL систем? Чтоб не только базовый синтаксис SQL команд, а с упором на часто встречающиеся паттерны при необходимости синхронизировать данные между несколькими системами, включая историю изменений.
Про исключения и старые добрые коды возврата хорошо написал Рэймонд Чен в заметке Cleaner, more elegant, and harder to recognize.
It’s easy to spot the difference between bad error-code-based code and not-bad error-code-based code: The not-bad error-code-based code checks error codes. The bad error-code-based code never does. Admittedly, it’s hard to tell whether the errors were handled correctly, but at least you can tell the difference between bad code and code that isn’t bad. (It might not be good, but at least it isn’t bad.)
On the other hand, it is extraordinarily difficult to see the difference between bad exception-based code and not-bad exception-based code.
Consequently, when I write code that is exception-based, I do not have the luxury of writing bad code first and then making it not-bad later. If I did that, I wouldn’t be able to find the bad code again, since it looks almost identical to not-bad code.
My point isn’t that exceptions are bad. My point is that exceptions are too hard and I’m not smart enough to handle them.
В прошедшем декабре энтузиасты ИИ начали решать задачи с Advent of Code при помощи ChatGPT и ему подобных, что вызвало негодование живых пользователей. Многие проходят AoC ради развлечения, но некоторые люди пришли действительно посоревноваться, а верхушка таблицы рекордов занимается роботами пока человеки всё ещё читают условие очередной задачи. Дней через пять, по мере усложнения задач, роботы сдулись, но успех всё равно впечатляющий.
Главное чтоб покупатель мог сделать осознанный выбор, а не действовать из худших предположений — иначе получим "рынок лимонов"
Работникам поддержки платят за количество закрытых тикетов, с их точки зрения это единственный важный критерий. Отписываться бездумным копи-пастом вполне прагматичная стратегия — не надо напрягаться и когда-нибудь клиенту надоест и тикет можно будет закрыть из-за отсутсвия последующих обращений. Бесполезно ругаться с работникаи поддержки или угрожать — скорей всего они не работают в головном предприятии, а сидят где-нибудь в Индии и давно уже привыкли что люди с хорошим настроением к ним не обращаются.
Другое дело юристы — их работа отводить возможные угрозы от фирмы и уменьшать риски. Количество не так важно, ведь даже один проигранный иск может обернуться многомиллионными потерями. У юриста тоже есть выбор — вникать в суть жалобы, вспоминать законы и писать официальный ответ, который может положить начало длинной переписке и закончиться тяжбой в суде, или же позвонить менеджеру в соседний отдел, попросить разблокировать приложение чтоб клиент успокоился, и уже через минуту гордо докладывать начальству что была на корню устранена пусть и небольшая, но всё же ненулевая угроза судебного разбирательства. Ключевой момент в том, что юристы уже внутри фирмы (причём не последние люди) и для них метрикой успеха является скорейшее прекращение спора, особенно если фирме это ничего не стоит.
В статье советовалось при общении с поддержкой, если проблему с налёта решить не удалось, максимально ссылаться на параграфы правил и законы. Официально запрашивать максимум информации, сразу упоминая установленные законом сроки ответа. Цель игры — создать впечатление человека готовящего документы для судебного иска. Тогда ваш тикет перебросят юристам, а там шансы на успех намного больше, даже если ваши требования слабо подкреплены законом — достаточно чтоб они выглядели потенциально рискованными для фирмы и юристу было проще потратить пару минут на звонок чем разбираться в деталях.
PS: До сих пор иногда пользуюсь Norton Commander для обмена файлами между Windows 10 и Olivetti M24 (1986 год, 8086, MSDOS 3.21). Чем возиться с пятидюймовыми дискетами, гораздо проще поднять Commander Link и перебросить файлы через COM-порт по нульмодемному кабелю.
… к
25-го октября7-го ноября по новому стилю.