Любят программисты аналогии. А ещё они любят считать себя инженерами, а программы — результатом работы. И вот тут возникает нежданчик: Что является результатом работы «настоящего» инженера? Некий физический продукт, скажем, автомобиль или дом, или мост. Не абстрактный, а совершенно конкретный с конкретным серийным номером, адресом и географическими координатами. И с этим вроде бы все согласны и это вроде бы очевидно: сначала идёт проектирование, затем конструирование (то есть сборка, производство), контроль качества и приём в эксплуатацию.
У ненастоящих же инженеров названия некоторых из этих этапов притащены в их предметную область и они даже любят рассказывать о проектировании софта, разработке и приёме в эксплуатацию. Вот только процентный баланс в этих этапах кардинально иной.
К примеру, производство физического объекта занимает существенное время и требует существенных ресурсов; аналог же производства в программировании — это вовсе не написание кода, как многие считают! Производство программы — это компиляция и сборка! При этом результат компиляции — это ещё не финальный результат работы, а лишь артефакт для этапов тестирования и внедрения. И вот уже результат внедрения в виде конкретной работающей программы/системы на конкретном компьютере — вот это настоящий результат.
А что же такое проектирование и написание кода? А оба этих этапа мапятся на один — проектирование физического объекта. При этом исходный код — это по сути детальная документация по созданию программы, по этой документации другие системы (компилятор и система сборки) изготавливают бинарные файлы.
В итоге получаем такое. Для физических объектов на стадии проектирование—производство—тестирование—внедрение тратится примерно одинаковое время (скажем, по 25% для простоты), при этом на производство ещё и физические ресурсы уходят. А для программных объектов на этап проектирования уходит 70%, 1% на производство (=компиляция и сборка) и 20% на тестирование и 9% на внедрение.
Именно дешевизна производства (по сути просто копирование байтов) и является действующим фактором т.н. «софтварного пиратства». Производство софтварного продукта не стоит ничего, а проектирование стоит ВСЁ.
Когда кто-то сравнивает строительство дома и написание кода, плюйте ему в лицо. Строительство дома (укладывание кирпичей итп) нужно сравнивать с компиляцией. А вот написание кода надо сравнивать с работой архитектора зданий. Но поскольку строительство — это долго и затратно, архитектор зданий не беспокоится о частой тотальной переделке всего, в отличие от программиста, для которого вполне норма «снести здание программы» и построить его заново.
В этом и есть ключевое отличие производства физических объектов от производства софта.
У ненастоящих же инженеров названия некоторых из этих этапов притащены в их предметную область и они даже любят рассказывать о проектировании софта, разработке и приёме в эксплуатацию. Вот только процентный баланс в этих этапах кардинально иной.
К примеру, производство физического объекта занимает существенное время и требует существенных ресурсов; аналог же производства в программировании — это вовсе не написание кода, как многие считают! Производство программы — это компиляция и сборка! При этом результат компиляции — это ещё не финальный результат работы, а лишь артефакт для этапов тестирования и внедрения. И вот уже результат внедрения в виде конкретной работающей программы/системы на конкретном компьютере — вот это настоящий результат.
А что же такое проектирование и написание кода? А оба этих этапа мапятся на один — проектирование физического объекта. При этом исходный код — это по сути детальная документация по созданию программы, по этой документации другие системы (компилятор и система сборки) изготавливают бинарные файлы.
В итоге получаем такое. Для физических объектов на стадии проектирование—производство—тестирование—внедрение тратится примерно одинаковое время (скажем, по 25% для простоты), при этом на производство ещё и физические ресурсы уходят. А для программных объектов на этап проектирования уходит 70%, 1% на производство (=компиляция и сборка) и 20% на тестирование и 9% на внедрение.
Именно дешевизна производства (по сути просто копирование байтов) и является действующим фактором т.н. «софтварного пиратства». Производство софтварного продукта не стоит ничего, а проектирование стоит ВСЁ.
Когда кто-то сравнивает строительство дома и написание кода, плюйте ему в лицо. Строительство дома (укладывание кирпичей итп) нужно сравнивать с компиляцией. А вот написание кода надо сравнивать с работой архитектора зданий. Но поскольку строительство — это долго и затратно, архитектор зданий не беспокоится о частой тотальной переделке всего, в отличие от программиста, для которого вполне норма «снести здание программы» и построить его заново.
В этом и есть ключевое отличие производства физических объектов от производства софта.
Никогда больше не куплю домой роутер микротик. Инфернальное мерзейшее поделие для цискозадротов и линуксовых админов, у которых борода из витой пары уже растёт. Мучительный процесс конфигурации этого адского изделия приводит в бешенство.
Текущий роутер я даже не буду никому дарить, а просто выброшу, люди не должны с этим пересекаться.
Текущий роутер я даже не буду никому дарить, а просто выброшу, люди не должны с этим пересекаться.
Эксперимент с Adobe Reader на макоси закончился — глючная тормозная параша, некоторые баги совсем невыносимы (например, на больших файлов при скроллинге в нижнем правом углу постоянно возникает непонятный прогрессбар, который сильно раздражает и отвлекает), поэтому переключился на Foxit Reader.
Отличный цикл статей про мифы reusablity:
* https://www.ufried.com/blog/reusability_fallacy_1/
* https://www.ufried.com/blog/reusability_fallacy_2/
* https://www.ufried.com/blog/reusability_fallacy_3/
Один момент прям отдельно нужно выделить:
First of all, reusability is a deeply industrial belief. In the physical world, reusability is mostly interchangeable with standardization. Standardized parts support building the product at a lower price and can easily be reused in multiple products. On the other hand, any part that is designed with reusability in mind is a candidate for becoming a standardized part.
* https://www.ufried.com/blog/reusability_fallacy_1/
* https://www.ufried.com/blog/reusability_fallacy_2/
* https://www.ufried.com/blog/reusability_fallacy_3/
Один момент прям отдельно нужно выделить:
First of all, reusability is a deeply industrial belief. In the physical world, reusability is mostly interchangeable with standardization. Standardized parts support building the product at a lower price and can easily be reused in multiple products. On the other hand, any part that is designed with reusability in mind is a candidate for becoming a standardized part.
Ufried
The reusability fallacy - Part 1
Why the reusability promise does not work
Ну и вдогонку к https://t.me/fieryfiles/245 продолжаю утверждать, что аналогии между физическим миром и программированием не работают, как бы красиво они ни выглядели.
Мы сейчас наблюдаем в очень интересный случай — взрывной рост популярности продукта и вытекающие из этого проблемы. Речь, конечно, про софт для видеоконференций zoom.
Вплоть до последних недель это был нишевый корпоративный продукт, достаточно популярный, но не слишком. Но всё изменилось с коронакризисом, популярность взлетела буквально взрывным образом, и на сервис пристальное внимание обратили хкаеры и медиа-падальщики (журналисты). Из-за возросшей популярности вселенная резко потребовала возврата технического долга: принятые когда-то решения внезапно очень больно взорвались, когда хакеры начали находить уязвимости и разоблачать маркетинговый булшит, который раньше никем особо не замечался, а теперь вдруг на волне интереса все стали детально всё исследовать. Медиа-падальщики, естественно, мимо такого пройти не могли, а так как новости про чужие проблемы «продаются» лучше, все стервятники бросились писать про уязвимости и баги.
А если бы не коронакризис, то zoom бы развивался потихоньку, хакеры тихо эксплуатировали уязвимости, а сми писали умеренные статьи про сервис раз в год. Компания явно оказалась не подготовлена к популярности.
Вплоть до последних недель это был нишевый корпоративный продукт, достаточно популярный, но не слишком. Но всё изменилось с коронакризисом, популярность взлетела буквально взрывным образом, и на сервис пристальное внимание обратили хкаеры и медиа-падальщики (журналисты). Из-за возросшей популярности вселенная резко потребовала возврата технического долга: принятые когда-то решения внезапно очень больно взорвались, когда хакеры начали находить уязвимости и разоблачать маркетинговый булшит, который раньше никем особо не замечался, а теперь вдруг на волне интереса все стали детально всё исследовать. Медиа-падальщики, естественно, мимо такого пройти не могли, а так как новости про чужие проблемы «продаются» лучше, все стервятники бросились писать про уязвимости и баги.
А если бы не коронакризис, то zoom бы развивался потихоньку, хакеры тихо эксплуатировали уязвимости, а сми писали умеренные статьи про сервис раз в год. Компания явно оказалась не подготовлена к популярности.
#copypaste
Таможенный идиотизм безграничен, а тупость ее беспредельна. Много лет назад наша таможня закупала ДЛЯ СЕБЯ рентгеновские досмотровые аппараты через нашу фирму. Тем не менее, они должны были заплатить сами себе таможенную пошлину, а деньги на это не были выделены. Задача была совершенно нерешаемая, пока не сообразили, что аппараты будут стоять в таможенной зоне, и границу не пересекут. Мы из–за этого чуть ли не год не могли получить деньги...
Таможенный идиотизм безграничен, а тупость ее беспредельна. Много лет назад наша таможня закупала ДЛЯ СЕБЯ рентгеновские досмотровые аппараты через нашу фирму. Тем не менее, они должны были заплатить сами себе таможенную пошлину, а деньги на это не были выделены. Задача была совершенно нерешаемая, пока не сообразили, что аппараты будут стоять в таможенной зоне, и границу не пересекут. Мы из–за этого чуть ли не год не могли получить деньги...
У концепта knowledge base есть один трудный момент — это сложно, очень сложно. Сложно писать, сложно читать, сложно сопровождать (то есть поддерживать в актуальном виде). Полноценное использование KB подразумевает обученность пользователя, он должен уметь правильно спросить, чтобы получить нужный ответ. И вот эти когнитивно-психологические нюансы сильно сложнее технической сложности при реализации системы. И эта когнитивно-психологическая сложность концептуальная — в принципе невозможно сделать систему, которая будет читать мысли пользователя, чтобы понять, что именно ему нужно.
Как некоторую аналогию можно рассмотреть реляционные базы данных и SQL. Если вы не понимаете язык, то вы ответ никогда не получите. А если попытаетесь транслировать естественный язык в SQL, то получите неправильный ответ. Клиент должен уметь чётко и однозначно формулировать запросы.
Как некоторую аналогию можно рассмотреть реляционные базы данных и SQL. Если вы не понимаете язык, то вы ответ никогда не получите. А если попытаетесь транслировать естественный язык в SQL, то получите неправильный ответ. Клиент должен уметь чётко и однозначно формулировать запросы.
Нашёл офигенный ютубный канал про английский язык: Virginia Bēowulf · English Studies.
Там товарищ очень системно и с кучей примеров рассказывает про нюансы английского языка, а в комментариях другие умные товарищи и про русский тоже говорят.
Вообще, лингвистика естественного языка — это то ещё болото. Простой смертный может от рождения отлично говорить, но не сможет объяснить, почему он так говорит. Живая нейросеть в действии и желающие обучиться языку тоже должны тренировать себя как нейросеть, то есть на правильных и неправильных паттернах, фразах и конструкциях.
Там товарищ очень системно и с кучей примеров рассказывает про нюансы английского языка, а в комментариях другие умные товарищи и про русский тоже говорят.
Вообще, лингвистика естественного языка — это то ещё болото. Простой смертный может от рождения отлично говорить, но не сможет объяснить, почему он так говорит. Живая нейросеть в действии и желающие обучиться языку тоже должны тренировать себя как нейросеть, то есть на правильных и неправильных паттернах, фразах и конструкциях.
Apple таки реализовал «железное» отключение микрофона в новых айпадах, так они заявляют, по крайней мере:
iPad models beginning in 2020 also feature the hardware microphone disconnect. When an MFI compliant case (including those sold by Apple) is attached to the iPad and closed, the microphone is disconnected in hardware, preventing microphone audio data being made available to any software—even with root or kernel privileges in iPadOS or in case the firmware is compromised.
Надо дождаться отчётов независимых разборщиков, чтобы понять, что там действительно отключается.
iPad models beginning in 2020 also feature the hardware microphone disconnect. When an MFI compliant case (including those sold by Apple) is attached to the iPad and closed, the microphone is disconnected in hardware, preventing microphone audio data being made available to any software—even with root or kernel privileges in iPadOS or in case the firmware is compromised.
Надо дождаться отчётов независимых разборщиков, чтобы понять, что там действительно отключается.
#бесит
Если вы делаете документы для печати, не используйте серый цвет шрифта, используйте только настоящий чёрный! Просто попробуйте распечатать и посмотреть перед тем, как файл документа публиковать.
Это касается и шапок/колонтитулов, ваш прекрасный корпоративный дизайн может при печати буквально потеряться.
Если вы делаете документы для печати, не используйте серый цвет шрифта, используйте только настоящий чёрный! Просто попробуйте распечатать и посмотреть перед тем, как файл документа публиковать.
Это касается и шапок/колонтитулов, ваш прекрасный корпоративный дизайн может при печати буквально потеряться.
Десять заблуждений распределённых систем:
1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
6. Topology doesn't change
7. There is one administrator
9. Transport cost is zero
8. The network is homogeneous
Рекомендую этот список распечатать и на стенку повесить, чтобы всегда перед глазами был. Каждый из пунктов нужно обязательно предусмотреть и корректно обработать. Причём в наше время практически любая программа (с элементами асинхронности) является распределённой, даже если она работает в границах одной системы/контейнера.
1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
6. Topology doesn't change
7. There is one administrator
9. Transport cost is zero
8. The network is homogeneous
Рекомендую этот список распечатать и на стенку повесить, чтобы всегда перед глазами был. Каждый из пунктов нужно обязательно предусмотреть и корректно обработать. Причём в наше время практически любая программа (с элементами асинхронности) является распределённой, даже если она работает в границах одной системы/контейнера.
Есть стойкое ощущение, что принципы работы ipsec в мире хорошо понимает человек двадцать максимум. А настроить какую-нибудь нестандартную конфигурацию через, например, libreswan, вообще никто не может.
Чувствую, пора на этом поле покормиться и написать очередную бесполезную статью.
Чувствую, пора на этом поле покормиться и написать очередную бесполезную статью.
Современный постиндустриальный мир представляет собой систему фантастической сложности и связности. Представления обывателя о ней не просто маленькие, они ничтожные. Люди воспринимают всё происходящее вокруг как должное и практически никогда не сталкиваются с теми, благодаря кому мировая система существует и функционирует.
Обыватель максимум ходит в гипермаркет или строительный магазин, то есть, грубо говоря, работает с розницей. Ну ещё с консумерскими сервисами (парикмахерская и автомастерская, например). Связи между сегментами системы обычно не видны, но они есть, причём их нарушение приводит к коллапсу всей системы, включая вроде бы совершенно не связанные между собой отрасли.
Например, существует две практически никак не пересекающиеся между собой системы поставок: розничная и корпоративная (это слово я сейчас придумал, я не знаю адекватного слова, чтобы передать смысл: когда конечным покупателем является юрлицо).
Рассмотрим туалетную бумагу, например. Она производится двух видов: для продажи в розницу и для продажи юрлицам, которые используют её для заправки туалетов в сети торговых центров, например. Цепочки производства совершенно разные: в первом случае на выходе получаются стандартные упаковки по четыре рулона в пластиковой плёнке, а во втором — большие рулоны того размера и формы, на которые производитель договорился с покупателем-юрлицом.
А теперь на сцену внезапно выходит коронавирус и карантин. Что происходит: миллиарды людей перестают ходить в офис, в гипермаркет, в макдональдс, соответственно у производителей «офисной» туалетной бумаги резко падает спрос, а у производителей «домашней» наоборот резко вырастает. Потоки людей одномоментно перераспределяются из одного сегмента потребления в другой (а общее количество потребляемой бумаги остаётся примерно постоянным). При этом производитель «офисной» бумаги не может вдруг резко начать производство «домашней», так как для этого нужно перенастроить производственные линии, перенастроить упаковочные линии, перенастроить контроль качества и склады, заключить договоры с компаниями, которые перепродают «домашнюю» туалетную бумагу, как-то разобраться с прежними договорами, чтобы минимизировать убытки.
Туалетная бумага продукт не скоропортящийся, поэтому тут можно хотя бы «на склад» поработать. А что делать производителям молока, например? Эффективная цепочка производства-поставок большая и сложная, перенастроить её быстро невозможно, молоко для конечных покупателей-юрлиц проходит через совсем другие цепочки, а они все разорваны, спроса нет и производители в итоге вынуждены молоко просто сливать в землю, так как с ним буквально невозможно ничего сделать: его очень много, его нельзя просто так раздать или продать в другие цепочки по причине юридических или санитарно-медицинских ограничений. Молоко портится, а транспорт для его перевозки уже распланирован для других задач. И в итоге коллапс распространяется во все стороны, ломая цепочки поставок во вроде бы совершенно не связанных между собой областях.
Обыватель максимум ходит в гипермаркет или строительный магазин, то есть, грубо говоря, работает с розницей. Ну ещё с консумерскими сервисами (парикмахерская и автомастерская, например). Связи между сегментами системы обычно не видны, но они есть, причём их нарушение приводит к коллапсу всей системы, включая вроде бы совершенно не связанные между собой отрасли.
Например, существует две практически никак не пересекающиеся между собой системы поставок: розничная и корпоративная (это слово я сейчас придумал, я не знаю адекватного слова, чтобы передать смысл: когда конечным покупателем является юрлицо).
Рассмотрим туалетную бумагу, например. Она производится двух видов: для продажи в розницу и для продажи юрлицам, которые используют её для заправки туалетов в сети торговых центров, например. Цепочки производства совершенно разные: в первом случае на выходе получаются стандартные упаковки по четыре рулона в пластиковой плёнке, а во втором — большие рулоны того размера и формы, на которые производитель договорился с покупателем-юрлицом.
А теперь на сцену внезапно выходит коронавирус и карантин. Что происходит: миллиарды людей перестают ходить в офис, в гипермаркет, в макдональдс, соответственно у производителей «офисной» туалетной бумаги резко падает спрос, а у производителей «домашней» наоборот резко вырастает. Потоки людей одномоментно перераспределяются из одного сегмента потребления в другой (а общее количество потребляемой бумаги остаётся примерно постоянным). При этом производитель «офисной» бумаги не может вдруг резко начать производство «домашней», так как для этого нужно перенастроить производственные линии, перенастроить упаковочные линии, перенастроить контроль качества и склады, заключить договоры с компаниями, которые перепродают «домашнюю» туалетную бумагу, как-то разобраться с прежними договорами, чтобы минимизировать убытки.
Туалетная бумага продукт не скоропортящийся, поэтому тут можно хотя бы «на склад» поработать. А что делать производителям молока, например? Эффективная цепочка производства-поставок большая и сложная, перенастроить её быстро невозможно, молоко для конечных покупателей-юрлиц проходит через совсем другие цепочки, а они все разорваны, спроса нет и производители в итоге вынуждены молоко просто сливать в землю, так как с ним буквально невозможно ничего сделать: его очень много, его нельзя просто так раздать или продать в другие цепочки по причине юридических или санитарно-медицинских ограничений. Молоко портится, а транспорт для его перевозки уже распланирован для других задач. И в итоге коллапс распространяется во все стороны, ломая цепочки поставок во вроде бы совершенно не связанных между собой областях.
Прекрасная история про массовую панику: https://telegra.ph/Pro-pionerskie-galstuki-i-kontrrevolyuciyu-04-09
Telegraph
Про пионерские галстуки и контрреволюцию
Отрывок из книги «Опасные советские вещи. Городские легенды и страхи в СССР». В 1930-е годы пионерский галстук не нужно было мучительно завязывать специальным узлом. Для этого у школьников были специальные металлические зажимы, на которых был изображен горящий…
Космос получил незаслуженно большую долю хайпа за счёт писателей- и режиссёров-фантастов. В итоге у людей возникли запредельно нереалистичные ожидания, которые выливаются в недовольство, типа, где ТОТ САМЫЙ КОСМОС, КОТОРЫЙ МЫ ПОТЕРЯЛИ?! Так вот нет, не было ТОГО САМОГО космоса никогда, а были только фантазии авторов, которые начисто игнорировали реальность и проецировали вечные темы на несуществующую среду.
На текущий момент у человечества нет ни желания, ни необходимости в освоении космоса. Сравнивать это с освоением океана ещё слишком рано, вот когда появится по-настоящему прорывная технология, позволяющая легко и просто летать и перевозить грузы, тогда и начнётся, а пока только в телескоп смотреть и рассылать автоматические зонды в случайные концы вселенной.
На текущий момент у человечества нет ни желания, ни необходимости в освоении космоса. Сравнивать это с освоением океана ещё слишком рано, вот когда появится по-настоящему прорывная технология, позволяющая легко и просто летать и перевозить грузы, тогда и начнётся, а пока только в телескоп смотреть и рассылать автоматические зонды в случайные концы вселенной.
Немного философии.
Считается, что мы живём в трёхмерном мире. Если мы ограничимся кусочком на Земле, то у нас есть плоскость, параллельная поверхности (это два измерения) и третье измерение в направлении центра планеты. Мы можем условно «легко» двигаться в первых двух измерениях, и значительно тяжелее в третьем. Если у нас не будет опоры, то мы упадём, вот это направление падения можно считать естественным состоянием при движении по третьему измерению. Нас постоянно «тянет» вниз гравитация.
Если мы теперь добавим к трём основным измерениям время, то получим ещё один вектор «движения», сопротивляться которому не можем. По сути мы непрерывно «падаем» в будущее. Мы настолько привыкли к этой «темпоральной гравитации», что вообще не представляем, как можно ей противостоять. Главный вопрос здесь: как будет себя вести сознание при движении против темпоральной гравитации? Если двигаться против времени, можно ли это осознать? Хочется верить, что можем.
Считается, что мы живём в трёхмерном мире. Если мы ограничимся кусочком на Земле, то у нас есть плоскость, параллельная поверхности (это два измерения) и третье измерение в направлении центра планеты. Мы можем условно «легко» двигаться в первых двух измерениях, и значительно тяжелее в третьем. Если у нас не будет опоры, то мы упадём, вот это направление падения можно считать естественным состоянием при движении по третьему измерению. Нас постоянно «тянет» вниз гравитация.
Если мы теперь добавим к трём основным измерениям время, то получим ещё один вектор «движения», сопротивляться которому не можем. По сути мы непрерывно «падаем» в будущее. Мы настолько привыкли к этой «темпоральной гравитации», что вообще не представляем, как можно ей противостоять. Главный вопрос здесь: как будет себя вести сознание при движении против темпоральной гравитации? Если двигаться против времени, можно ли это осознать? Хочется верить, что можем.