Комментарии 199
По поводу деепричастных оборотов читайте здесь. Есть ещё очень распространённая ошибка с мягким знаком (или его отсутствием) в глаголах, оканчивающихся на «ться» и «тся». И про это тоже есть сайт, правда, я далеко не первый, кто на него ссылается. Эту ошибку, всё-таки, хотя бы иногда замечают и исправляют.
И это программист. Страшно предстаить, что там в коде :)
Это я к тому, что Вы уверены в своей правоте, хотя, вполне возможно, ошибаетесь, не обладая достаточной информацией.
Это нехорошо. Не надо так.
Я на работе уже всех выдрессировал называть I2C «ай-ту-си» или «и-два-цэ», а не «и-два-эс». Потому что есть I2S.
Никогда конечный юзер не будет играть с алгоритмами. Во первых он в этом не разбирается, во вторых ему это не интересно.
Труднее всего приходится так называемым «продвинутым пользователям», то есть людям, склонным относиться к технике ответственно и изучать инструкции по эксплуатации перед тем, как пользоваться техникой. Мне всегда очень больно наблюдать страдания моего пожилого отца, который не умеет совершать простые манипуляции с собственным Андроид-смартфоном, потому что не знает, как, но который достаточно квалифицирован, чтобы жать «куда попало» (то есть использовать интуицию), на что эти интерфейсы и рассчиланы.
А ещё было время, когда великие врачи, чьи имена вписаны в историю человечества, сами своими руками изготавливали целебные настои и точно знали как они действуют на организм человека, доверяя своему опыту, а не бездушным инструкциям-вкладышам…
Уж не знаю, к сожалению ли или к радости, но сейчас наступила эпоха готовых решений. Мне это тоже не по душе. Я помню как сам писал и обучал нейронные сети, реализовывал генетические алгоритмы, точно знал все нюансы своих программ. Но современный рынок требует умения пользоваться готовыми решениями. И я пользуюсь стандартными библиотеками.
Это наша реальность и приходится с ней мириться. Хотя, знание основ — это огромный плюс, так как это возможность создать новое готовое решение для новой проблемы, которое будем использоваться многими, кто даже не задумается, как там всё устроено.
— Технически-подкованный водитель и сейчас знает об устройстве своего автомобиля ровно столько, сколько нужно, чтобы на этом автомобиле успешно передвигаться. И даже поменять колесо в экстренной ситуации.
Они доверяют ремонт авто работникам сервисов не потому, что не знают, как что работает, а потому, что справдливо полагают, что работники сервиса чинят лучше.
— Я никому не пожелаю иметь дело с врачом, не понимающим биохимические и фармакинетический свойства выписываемых им препаратов. Опять же, фармакомпания делает, а понимать должны все, кто выписывает (и, кстати, неплохо бы, чтобы хоть немного понимали даже те, кто принимает).
Не обязательно знать каждый ньюанс в том, что ты используешь. Но основоположные вещи нужно знать обязательно. Иначе случится катастрофа. За примером далеко ходить не надо. И он, к слову, произошел еще до «айтишной революции».
Но, если абсолютно всё делать самому от и до, то можно очень сильно отстать от современности. Приходится находить компромисс между своим опытом и доверием другим специалистам, предлагающим нам готовые решения.
И разработчик обязан знать как ДОЛЖЕН работать используемый им продукт. А вот работает ли он так на самом деле? В этом, приходится доверяться разработчику продукта. Ибо воссоздать все технологии одному человеку — непосильная и абсурдная задача. Вот тут-то и появляются «магические строчки»… Как механизм приспособления к окружающей нас действительности.
Автор статьи посетовал на то, что существуют «боги из машины», которые «магически» делают ваш код лучше (не слишком понятно, какую цену приходится за это заплатить) и что большинство людей в индустрии не понимают, как они работают.
Так что, строго говоря, никто из этих людей определенному вами долженствованию не удовлетворяет. Не могут они знать, как их продукт должен работать. Если только вы под «должен» не подразумевали техзадание — тут даже менеджер знает, как что «должно работать».
Менеджер: Когда нибудь придёт время, когда программисты станут не нужны. Я напишу полную и точную спецификацию программы и она сама заработает.
Программист: знаешь как называется самая полная и точная спецификация программы? «Код», это называется «код».
Мой отец может разобрать и собрать машину отечественного производства и иностранного до 90х годов. Любую, где не используется компьютер. Заменить ГРМ, перебрать клапана, починить карбюратор из подручных средств — для него не проблема, и экстренно починить заглохший двигатель с помощью гвоздя и резинки тоже (сам видел). При этом скажет сколько она проедет до следующей такой же проблемы. И он, отец, не механик, а простой советский инженер. При этом при обращении с современными машинами, он вынужден обращаться в сервис, и вынужден доверять тем специалистам которые обслужат машину, и их квалификацию, как и результат может проверить только очень поверхностно, как работают эти контроллеры и компьютеры он не знает, при этом постоянно проверяя за сервисными работниками то, что он знает. При этом мой знакомый который работает в мастерской и настраивает электронику в машинах — говорит что все делает по документации и не лезет внутрь.
Так вот, к чему я это написал. В современном мире мы все дальше уходим от понимания принципов работы системы даже среднестатистическим инженером, не говоря уже о конкретном пользователе, и дальше будет хуже.
Мы будем использовать продукты в рамках инструкций не разбираясь в запасах прочности и допусках и вариантах замены в экстренных ситуациях. Мы не сможем экстренно починить заглохший двигатель с помощью гвоздя и резинки.
Это не хорошо и не плохо, просто особенность любой сложной системы, переход на новый уровень абстракции. Примерно также как инженер, разрабатывающий электронную схему на базе микросхем вряд ли вникает во внутреннее устройство каждой. Аналогично с машинами — на работает блок, на замену. И да починить заглохший двигатель с помощью гвоздя и резинки теперь не получится, но это цена прогресса. Зато мы получаем на много больше плюшек )
А по сути — вы совершенно правы. Это в самом деле цена прогресса. Преимущество гвоздя перед атомным реактором в том, что в гвозде выходить из строя совершенно нечему. Но энергию он, гад такой, не производит.
А с другой стороны, у меня есть друг, который может как ваш отец — натурально всё собрать, разобрать, — он даже модификации в конструкции своей машины сделал — теперь гаишники прикапываются. А еще для него совершенно не проблема программировать микроконтроллеры. И он чудесным образом может починить багу в системе «умного» впрыска топлива, например. Просто, он другого поколения, чем ваш отец.
В плане возможности поддержки и ремонта техники ситуация, когда один человек неспособен разобраться во всем устройстве, преодалена только в одном типе устройств — в компьютерах. Вот там сложность такова, что никто уже толком не понимает, как что работает (кроме пары гениев, которые стояли у истоков, всю жизнь разрабатывали процессоры и чипсеты и еще не ушли на пенсию). И, откровенно говоря, текущее состояние платформы PC немного удручает. Куча глюков, в том числе, — аппаратных, проблемы с софтом, тормоза… В общем, плохо, когда никто не может понять всю систему целиком и хорошенько ее «отрефакторить».
Вот мой отец например. Он привык в советское время постоянно быть в гараже, перебирать двигатель, коробку передач, все эти лебёдки, ключи, масло… И вот появилась у него японская машина 20-летней давности. И не знает, что с ней делать в гараже. Ведь по привычке надо в ней копаться, а не «докопаешься». Вот и протирает он её тряпочкой и она всегда чистенькая и блестящая. Трудно ему, непривычно.
Есть ещё такие австралопитеки, которые на полном серьёзе считают, что машину с механической коробкой передач обязан уметь управлять каждый водитель.
Все обстоит не иначе, а зависит от страны проживания.
В США более 90% машины — автомат. Причем подавляющее большинство водителей вообще не имеют представление как работает механика, и им нафиг это сдалось. Причем для многих моделей, вариант с механикой отсутствует в принципе.
В Японии процент автомата еще больше.
Умение водить механику нужно не столько для самого умения водить. А просто потому что пока еще встречаются ситуации, когда в доступности есть только механика. Частая история в прокатах, например. Когда механики в использовании не останется, никакой нужны уметь ей управлять и не будет. Ну и не нужно это тем, кто использует машину только передвижения с дома на работу и даже не задумывается о том, чтобы взять другую машину и где-то на ней ездить.
Контроль на механике обычно заключается в том, что передача в ненужный момент не сменится. На автомате это тоже достижимо (если там есть толковый ручной режим), но мало кто этим пользуется.
В любом случае, механические коробки уже даже с мотоциклов будут уходить. Лет через 5 в большинстве автошкол цивилизованных стран вряд ли будут обучать вождению на механике в рамках общей программы.
Однако, вы немного отстали от жизни;) У Хонды есть коробка DCT, ее уже пару лет ставят на NC700 и VFR1200X. Это робот с двумя сцеплениями, который показал себя надежным и сейчас вот ставят на новую литровую Африку. Железно работает она прекрасно (переключения моментальные, без рывков, запутать робот, переключая передачи туда-сюда у меня не вышло). Есть проблема с алгоритмом работы при активной езде на дороге, но его со временем решат. Не Хонда, так БМВ (которая, в отличие от Хонды, в машинах автомат настраивает очень неплохо).
Хонда тут новатор, остальные ставят на мотоциклы квикшифреты — дополнение к механике, позволяющее переключать передачи без сцепления и не меняя газ. По сути, упрощающее и ускоряющее переключение по технике квикшифтинга, когда кратковременно сбрасывают газ при переключении вверх. Но это временное решение, работает оно хуже, чем робот.
Учитывая, что Хонда начала ставить робот на многие новые модели, остальные производители не будут долго с этим тянуть. Тем более, что многие имеют возможность позаимствовать решения у автомобилей и наверняка давно ведут разработки. Хонда просто умудрилась первой выпустить толковую и компактную коробку.
А большинство машин производится именно за бугром, и механика понемного уходит.
Лично я буду ездить на механике, пока это будет возможно, но я понимаю почему существует тенденция в сторону автомата, и вполне предполагаю, что в будущем автоматов будет гораздо больше, если не полностью.
Когда между вашей ногой, жмущей на «газ» и колесами присутствует только двигатель и зубчатая передача, передаточным числом которой вы управляете сами, чувство контроля (притом, совершенно обоснованное) гораздо выше, чем когда вас с колесами разделяет сложная, «интеллектуальная» система, которая, к тому же, имеет «наглость» адаптироваться к вашему стилю вождения (то есть менять свое поведение «на ходу»).
прошло 5 лет — следующая машина будет с автоматом, потому как нафига делать самому то, что робот может делать в разы лучше?
С уважением, ваш Австралопитек.
И вообще, чем проще устройство — тем приятнее с ним иметь дело. Сложность — неизбежное зло, на которое приходится идти с целью безопасности и комфорта.
А вот брат мой — гонщик класса ралли, — покупая себе новую машину, снял с нее АБС. Потому что привык тормозить импульсами сам. И этот самый АБС ему бы мешал, а не помогал.
А отключать надо потому, что если человек до спинного мозга привык к импульсному торможению ногой (чему вообще-то должен был учиться любой водитель до-АБС-ной эпохи, не только профессионал), то наложение на его «долбящую ногу» алгоритма импульсов АБС-а приведет уже не к сокращению, а к увеличению тормозного пути.
то наложение на его «долбящую ногу» алгоритма импульсов АБС-а приведет уже не к сокращению, а к увеличению тормозного пути.
Или вы не знаете физику процесса работы АБС или я не знаю. Берем твердое покрытие (асфальт — сухой, мокрый или мерзлый, неважно. Где-то уж найдем его) и симулируем торможение по нему. Любая блокировка колеса тормозной путь увеличит (почему — в Вики написано в статье про АБС). Если блокировки нет, АБС не срабатывает — датчики у него достаточно точные для этого.
Как прерывистое торможение может быть ухудшено АБСом?
Повторюсь, у вашего брата проф. деформация. Раллийщики ездят по сыпучему и мягкому покрытию, там АБС может сделать хуже и тормозить лучше прерывисто. Как и в снегу. Но на асфальте и другом твердом покрытии ситуация иная.
Основная идея в том, чтобы всё время держать колесо в состоянии, когда скорость движения его поверхности относительно земли была близка к нулю. То есть колесо должно немного прокручиваться. При этом, как ни странно, оно будет терять энергию движения машины быстрее, чем при проскальзывании «юзом».
1. Как этого эффекта достигает человек?
Человек нажимает на тормоз, чувствует, что машина потеряла часть скорости, машина входит в проскальзывание, человек отпускает педаль, проскальзывание прекращается, человек снова нажимает педаль…
Та самая «долбёжка по тормозу». Ее тренируют при прохождении начального курса экстремального вождения.
2. Как этого эффекта достигает система АБС?
Примерно так же. Она блокирует колесо, фиксирует напряжение на оси, когда напряжение падает, ослабляет «хватку» колодок, затем снова усиливает. Та же самая «долбежка», только без педали (возможно, более плавная/высокочастотная, но сути это не меняет).
3. А теперь вместе.
АБС включится при нажатии на «тормоз» и выключится при отпускании. Водитель, инстинктивно «долбящий» педаль не даст АБС-у найти оптимальное напряжение оси. Автоматика просто не успеет понять, насколько сильно надо тормозить. В результате тормозить толком не будет никто.
Тормозной путь станет не короче, чем при проскальзовании, а длиннее.
Теперь по последнему пункту. Опять.
Вы, насколько следует из профиля, живете не в России. Напомню, что в нашей стране зимой любая, даже самая хорошая дорога содержит на себе либо слякоть (в лучшем случае), либо полсантиметра снега. Снег бывает раскатанный и скользкий, а бывает плохопримятый. В любом случае, российские водители рассматривают вождение на сухом асфальте как роскошь. Лично мне вообще никаких улучшений моего транспортного средства в условиях сухой летней дороги и хорошей видимости не нужно. Тормозной путь в 15-20 метров при скорости в 90 км/ч — просто роскошь.
У нас все водители с ралли!
Иллюстрация:
P.S. Летом в плохую погоду эта же дорога может быть покрыта примерно таким же слоем скользкой грязи.
АБС основана на том обстоятельстве, что трение покоя гораздо больше, чем трение скольжения. Пока колеса катятся по асфальту без юза, на них действует именно сила трения покоя. Это как шкаф двигать, гораздо легче идет если сорвать.
Дальше, АБС срабатывает очень быстро и так же быстро выключается. Т.е. он минимизирует время, которое колесо находится в состоянии трения скольжения и при этом не дает сильно ослабить тормозное усилие, пока оно не приводит к срыву колеса. Это приводит к тому, что колесо проводит в трении скольжения минимально возможное время. Гораздо меньше, чем если тормозить прерывисто самому. И тормозной путь будет меньше, чем у любого ралийщика, как бы он не тормозил (в идеале, тормозной путь будет примерно равен и это лучшее, чего сможет добиться человек).
Когда человек тормозит прерывисто с АБС он конечно мешает работать АБС, но в моменты, когда колесо блокируется, АБС все равно экономит тормозной путь, пусть и меньше, чем если бы водитель ему не мешал.
Теперь о ралли. На мягком и сыпучей поверхности, сцепление с дорогой гораздо хуже и что трение покоя что качения достаточно слабое и не позволяют нормально затормозить. Но, колеса в юзе могут нагребать перед собой небольшую горку из песка, снега или того, по чему катится колесо. Вот за счет этой горки и обеспечивается немалая часть замедления. Потому, в ралли и другом оффроаде нужно допускать небольшой юз колеса и торможение крупными рывками будет эффективнее, чем если использовать АБС. Только на покрытии, которое позволяет набрать эту горку перед колесом. Не на асфальте!
А то, что в России нет дорог конечно повторять любят. И мне возможно было бы приятно так думать. Но к несчастью для себя я знаю, что дороги там все же есть, кроме некоторых регионов. Но в тех регионах на легковой технике и не ездят, как правило. А для тех сравнительно редких ситуаций, когда вы таки решите понаваливать по рыхлому снегу, часто есть кнопка отключения этого самого АБС. Но ей обычно пользоваться не стоит т.к. она отключает еще и систему стабилизации (если такая есть в машине), а без нее наваливание по рыхлому снегу на гражданской машине может закончиться плохо даже для раллийщика (если мы говорим о скоростях 80 км/ч и выше).
Пойду, сообщу брату-гонщику, что его личные эксперименты и опыт товарищей — ерунда, потому что некий эксперт из интернета так решил. Интересно, что он ответит.
>А то, что в России нет дорог конечно повторять любят.
Я не говорил, что в России нет дорог. (Кстати, речь идет о городе Москве, где дорожное покрытие вполне годное почти везде.) Я имел в виду, что зимой в России дорожные службы не справляются с их расчисткой. Дороги завалены снегом, сцепления почти нет.
В довершение процитирую мнение одного очень старого водителя, который когда-то учил меня так: «Смотри, выпал снег и лег. Пришла зима. Если не хочешь беды, про тормоза до весны ты должен забыть». Очень релевантное мнение, кстати.
В средней полосе России абсолютно не имеет значения, насколько хорошо ваша машина тормозит летом в сухую погоду. Потому что на то, как вы управляете машиной, влияют следующие навыки:
1. В городах и на крупных трассах — аквапланирование летом и езда по мокрой снежной каше зимой.
2. За городом — умение на глаз отличить глубокую грязь от мелкой летом, езда по глубокому снегу зимой.
Я про езду по бездорожью выше даже не упоминал. Говорил исключительно про случай, когда под снегом/водой/грязью есть хороший асфальт без выбоин и колеи.
Да и машина за городом нужна иная. С высоким подъемом и полноприводная.
Любая блокировка колеса тормозной путь увеличит
Вы пишите ерунду. Вот вам картинка из авторевю, там тесты проводили, а не википедию читали, смотрите туда, где про лед. Сама статья убрана из свободного доступа, к сожалению.
АБС не уменьшает тормозной путь. АБС делает торможение управляемым. Как и прерывистое торможение. Хватит уже мифологию разводить.
При прирывистой блокировке энергия, всё же, теряется…
Из «Фауста» Гёте, монолог Фауста:
Отец мой, темный труженик, в тиши
Над тайнами природы тщетно бился;
В ее круги святые он стремился
Проникнуть всеми силами души —
По-своему, но честно. Меж адептов
Сидел он в чёрной кухне взаперти
И силился бальзам целительный найти,
Мешая разных множество рецептов.
Являлся красный лев — и был он женихом,
И в теплой жидкости они его венчали
С прекрасной лилией, и грели их огнем,
И из сосуда их в сосуд перемещали.
И вслед — блиставшую лучами всех цветов
Царицу юную в стекле мы получали:
Целительный напиток был готов.
И стали мы лечить. Удвоились мученья:
Больные гибли все без исключенья,
А выздоравливал ли кто,
Спросить не думали про то.
Вот наши подвиги леченья!
Средь этих гор губили мы
Страшней губительной чумы!
Я сам дал тысячам отраву:
Их нет — а я живу… И вот —
В моём лице воздал народ
Своим убийцам честь и славу!
вопросы подняты, конечно, интересные, жизненные, но боюсь ответы на них скорее философские нежели практические.
Про софт. Довелось поддерживать продукт 15-ти летний. Видел в нем как раз то, что новые функции открывают новые баги, и т.п. Дык вот, коли такое происходит, я считаю жизненный цикл ПО подошел к концу. Не потому он не нужен, просто нужно пересмотреть архитектуру, и да, переписать версию 2.0 с учетом хотелок и ошибок. Что-то выбросить, что-то добавить — это нормально я считаю.
И вообще — нет ничего идеального…
Тот, кто работает в сосисочном цехе, никогда не ест сосиски.
Врачи вот тоже могут много «забавного» рассказать, но только в своём кругу.
Не надо бояться технологий и программистов. Весь этот процесс абсолютно нормален.
Так что присаживайтесь по удобнее, едем дальше.
Еще забавен тот факт, что сложение двух чисел на C++ в некоторых случаях undifined behaviour (чисто теоретически может отформатировать жесткий диск):D
Точка.
Пример: В США, в некоторых штатах водителям большегрузов запрещено самим менять пробитые колеса, независимо от того, может человек, или нет. Этим занимается специальная служба, шофер — ведет машину.
Еще раз, вдумайтесь. Если врачи, которые лечат ваши уши, не будут знать физиологию всего тела (а зачем?) или, скажем учитель математики вашего ребенка не будет уметь грамотно писать (или учитель литературы не будет уметь считать) — вы полагаете, это и есть то «светлое будущее» с разделением труда?
В таком случае нам с вами определенно не по пути. Потому что мир, в котором люди не понимают (хотя бы приблизительно) проблемы и задачи друг друга, похож на Вавилонскую Башню.
Вам же автор статьи привел пример проекта, который накрылся медью из-за того, что инженеры-«жестянщики» в упор не понимали, чем занимаются программисты. Или этот пример не иллюстрирует проблему?
Но это не означает, что они НЕ ПОНИМАЮТ, как сменить колесо.
Вовсе необязательно. Могут и не понимать. Разделение труда приводит к специализации. Это повышает эффективность обучения и производительность труда.
Еще раз, вдумайтесь. Если врачи, которые лечат ваши уши, не будут знать физиологию всего тела (а зачем?)
При этом они не знают другие части тела так же хорошо, как и «свои». «Знать физиологию» — это игра словами, основанная на неоднозначности слова «знать» в этом контексте.
скажем учитель математики вашего ребенка не будет уметь грамотно писать (или учитель литературы не будет уметь считать)
Это некорректный примерю Навыки письма и счета — базовые для всех людей. Мы же говорим о профессиональной деятельности, и тут — о ужас — да, учитель математики не умеет учить детей литературе.
В таком случае нам с вами определенно не по пути. Потому что мир, в котором люди не понимают (хотя бы приблизительно) проблемы и задачи друг друга, похож на Вавилонскую Башню.
Путь в обратную сторону — дорога в средневековье. Вы просто пытаетесь определить набор навыков, иметь которые по-вашему «нормально» (вида «нормальый мужик умеет починить кран и прибить полку», только в применении к другим сферам), я же говорю о профессиональной деятельности, производстве продукта/услуг.
Вам же автор статьи привел пример проекта, который накрылся медью из-за того, что инженеры-«жестянщики» в упор не понимали, чем занимаются программисты. Или этот пример не иллюстрирует проблему?
Этот пример демонстрирует проблему отсутствия человека, координирующего действия тех двоих. Потому что инженеру (не в сфере ПО) также знаком итеративный процесс решения проблемы, поиск альтернатив; это означает, что между ними нет неразрешимых противоречий, это обычная communication проблема.
А навыки оперирования с алгебраическими выражениями общие для всех, кто занимается точными науками.
А знание анатомии обязательно для всех, кто имеет дело с телом человека. Даже если он всю жизнь смотрит исключительно в рот.
А элементарные слесарные навыки обязательны для всякого водителя (во всяком случае если он хочет быть уверенным, что выберется из по-настоящему нештатной ситуации).
>Вы просто пытаетесь определить набор навыков, иметь которые по-вашему «нормально» (вида «нормальый мужик умеет починить кран и прибить полку», только в применении к другим сферам)
Я пытаюсь определить набор навыков, который определяет околопрофессиональный кругозор человека, занимающегося деятельностью, близкой к моей.
А вы бросаетесь в крайности.
И, кстати, поделитесь мыслью, каким таким волшебным способом этот третий человек, координирующий двоих, справится со своей задачей, не имея хотя бы базовой экспертизы в областях, которыми занимаются они оба. Я за время своей работы сменил около десятка руководителей, но такого чуда чудесного не встречал. Все они более-менее разбирались в том, чем управляли. И слава богу.
А знание анатомии обязательно для всех, кто имеет дело с телом человека. Даже если он всю жизнь смотрит исключительно в рот.
Проблема в том, что вы определяете «элементарные навыки» волюнтаристский. Я уже обозначил это, указав на использование вами слова «знание», но вы этого не поняли.
Я пытаюсь определить набор навыков, который определяет околопрофессиональный кругозор человека, занимающегося деятельностью, близкой к моей.
Так я не против, непонятно, на что вы возражаете здесь.
А вы бросаетесь в крайности.
Отнюдь, это делаете вы. Я как раз не против расширения области, захватывающей что-либо, что позволит людям разных специализаций состыковаться.
А вот ваши примеры-контраргументы — как раз полярные, крайность.
Что такое «знание анатомии», что такое «элементарные слесарные навыки»? Вы бросаетесь абсолютно неопределёнными фразами — это крайне непрофессионально, если на то пошло.
Знание анатомии — что это? Профессиональный гинеколог должен знать какие участки головного мозга за что отвечают? Нейрофизиолог должен знать то, как работает человеческий иммунитет так, чтобы иметь например возможность рассказать без недельной подготовки по этой теме лекцию?
Элементарные слесарные навыки — что это? Нестандартная ситуация — какая это? В машине произошла поломка инжектора/коробки передач/бортового компьютера/электродвигатель отказал — это ещё настолько нестандартные ситуации, чтобы с ними необходимо было уметь справиться профессиональному водителю или ещё нет? И не в копейке, выпущенной лет 20 назад, а в современной среднестатистической иномарке, в которой иногда и подобраться к нужным деталям без спецоборудования не так то просто.
>третий человек, координирующий двоих >базовой экспертизы
Опять неопределённость, уточните должность и что такое «базовая экспертиза»?
Хотя это можно вообще-то долго продолжать. Я думаю, уже давно понятно, что без умения пользоваться предоставленными другими людьми абстракциями никто в современном мире не сможет успешно продолжать свою деятельность. А то, абстракциями насколько высокого уровня должен уметь оперировать человек на определённой должности, точно решит уже скорее всего только рынок.
Вовсе необязательно. Могут и не понимать. Разделение труда приводит к специализации. Это повышает эффективность обучения и производительность труда.Если впадать в крайности то у нас на каждый чих, по такой логике, будет специалист.
Путь в обратную сторону — дорога в средневековье. Вы просто пытаетесь определить набор навыков, иметь которые по-вашему «нормально» (вида «нормальый мужик умеет починить кран и прибить полку», только в применении к другим сферам), я же говорю о профессиональной деятельности, производстве продукта/услуг.а что собственно плохого в «нормальном мужике»? почему нельзя сочетать это качество и быть хорошим специалистом в своей области? В Японии, слышал, практикуется система «горизонтального» роста: каждые пять лет инженер меняет специализацию и начинает все с нуля. А самое главное Вы не должны забывать чем вызвано это производство продуктов/услуг. По-моему из-нас делают потребителей этих самых продуктов/услуг. Такое ощущение что миром начинает править маркетинг. Про путь в обратную сторону- не это имел ввиду bigfatbrowncat. Я думаю, что смысл в том что нужно оглядываться назад, двигаясь вперед. Наша нация (я не делаю здесь ударения), если помните, всегда отличалась смекалкой. Вспомните великие битвы и войны за нашу родину. Сколько раз мы выживали благодаря нашему менталитету (собственно, порою оказываемся в *опе из-за него же). Я не понимаю как можно, например, дать замерзнуть своему ребенку на трассе, зимой просто из-за того, что ты не умеешь заменить колесо (если уж речь зашла о замене колес).
Этот пример демонстрирует проблему отсутствия человека, координирующего действия тех двоих. Потому что инженеру (не в сфере ПО) также знаком итеративный процесс решения проблемы, поиск альтернатив; это означает, что между ними нет неразрешимых противоречий, это обычная communication проблема.Нужен не просто координатор, а человек развитый во многих областях, который понимает проблемы того или иного направления/специализации. Талантливый и действительно сведущий ГИП, project manager, руководитель проекта (называйте как хотите) большая редкость нынче.
Ну и по теме статьи: эту проблему можно проецировать практически на любую область, будь то производство или проектирование. Но конкретно в сфере ПО думаю что технологии производства микропроцессоров в будущем «упрутся» в невозможность производства более производительных систем. И вот тогда наступит время кодеров которые будут по-настоящему оптимизировать код. До этого времени объем кода будет только увеличиваться.
А «водителям большегрузов запрещено самим менять пробитые колеса» — это уже навязывание кем-то.
Водитель может сам решить насколько выгодно ему ждать спец. службу или же поменять колесо самостоятельно. Или же его работодатель решит, если водитель недостачно компетентен.
Банальный и самый яркий для меня пример — умножение матриц.
Пока проходили первый раз в техникуме, сдал почти на отлично. Через год писал практическую — пришлось лезть в конспекты, потому что забыл. Еще через год писал программу строящую графики поверхностей — читал заново. Через год писал демки на OpenGL — заново. Проходили и в институте — ничего не помнил. Позже попал в геймдев контору, писали свой 2д движок — читал википедию. Через пол года писал бенчмарк для luajit с перемножением матриц — заново. С год назад писал биндинги к glfw — вспоминал заново. И если спросить меня о об умножении матриц сейчас, я все равно не смогу сказать сходу, полезу в вики.
И похожие провалы почти во всем — стоит не трогать css с пол года, и я едва помню что-либо кроме основных селекторов и свойств. Пытаюсь бороться с этим, записывая краткие конспекты в простенький outliner, всплывающий на ctrl+shift+z (Flashnote).
Это у меня реально проблема, или я просто себя накручиваю?
Проблема у тех, кто считает, что для умножения матриц требуется немного пыли пикси и щепотка тертого философского камня. Или у тех, у кого слово «матрица» ассоциируется только с творчеством братьев Вачовски.
Общая эрудиция, достаточная для нахождения необходимого решения поставленной задачи — это именно то, что достаточно специалисту. Остальное вам даст справочная литература.
А эпоха «Сайрусов Смитов» давно закончилась, да. Подготовка современного инженера не подразумевает способности восстановить технологический уровень современного обества на необитаемом острове.
Общая эрудиция, достаточная для нахождения необходимого решения поставленной задачи — это именно то, что достаточно специалисту. Остальное вам даст справочная литература.
Серьезно? Вам
определеннонепо пути
с человеком, который не знает, как перемножаются матрицы?
irony, отсылка к разговору выше, если что.
Я помню формулу перемножения матриц. Но при необходимости всё равно уточню в справочнике — моя память со мной уже не раз играла дурную шутку. Но я точно помню, из чего эта формула состоит — там были линейные комбинации членов строк одной и столбцов другой… как-то так ведь, правда? То есть, я точно знаю, что не нужно, скажем, возводить элименты в квадрат. Или брать экспоненту. И этого вполне достаточно.
Я могу выдавать вполне квалифицированное мнение о задаче, связанной с перемножением матриц, даже если не помню деталей.
К нашему разговору выше — я не требую от преподавателя математики знания названий правил русского языка из учебника. Всего лишь писать грамотно. И врач, который лечит меня антибиотиком, не обязательно должен в деталях знать, как этот антибиотик изготовлен. Но он должен понимать, каков принцип действия, а не просто, как многие современные врачи, увы, делают, назначать по принципу «это — от головы, а это — от живота».
Вы мне говорите о разделении труда, я не возражаю (было бы глупо), но пытаюсь вам доказать, что разделение труда — не самоцель, а суровая необходимость. Если бы возможности мозга были бы безграничны, все были бы Сайрусами Смитами. Вернее, все, кто стремится достичь вершин в своей профессии, изучали бы ее, начиная от атомов.
Я всегда старался максимально расширять свой кругозор. Со школы. Программирование — супер. Физика — интересно. Графический дизайн — почему бы нет. Звук, музыка, видео… И так далее. Я осознавал, что пяти профессий быть не может. Но вот, в чем штука — уже неоднократно оказывалось так, что на работе кто-то куда более квалифицированный, чем я, сталкивается с проблемой, которую не может разрешить в силу своей узкой специализации. А я подсказываю человеку идею, как можно обойти препятствие. Не потому, что я чем-то «круче», а просто потому, что немножко шире изучал вопрос.
Скажем, мои познания в дизайне неоднократно помогали мне убеждать в своей правоте UX команду в тот момент, когда напарники, понимая, что господа-дизайнеры придумали ересь (потому что, в свою очередь, не понимали предметную область), не имели весомых аргументов. Просто не знали, как сформулировать проблему.
Вот такое вот разделение.
Вы меня там, выше, не поняли — может хоть здесь поймете
Почему же? Я отлично понял вашу позицию; вы не поняли моего возражения.
То есть, я точно знаю, что не нужно, скажем, возводить элименты в квадрат. Или брать экспоненту. И этого вполне достаточно.
Я же написал — irony. Ваш набор необходимого субъективен — в одном случае вы говорите «это можно посмотреть в справочнике», в другом «я расширяю кругозор, потому что это нужно».
К нашему разговору выше — я не требую от преподавателя математики знания названий правил русского языка из учебника. Всего лишь писать грамотно.
Вы непоследовательны. Речь шла о разделении труда и о том, что умение писать — это не специфичный для профессии учителя навык, это навык, специфичный для всех современных людей. Он вне профессии. А вот навык преподавания математики или русского языка — специфичен, и здесь есть разделение труда, специализация. Это не я перехожу в крайности, это вы представляете мой аргумент таковым, вероятно, по ошибке.
не обязательно должен в деталях знать, как этот антибиотик изготовлен. Но он должен понимать
Принцип изготовления антибиотика не является специфичным для его профессии, применение — является. Поэтому он должен иметь это знание, а не просто «потому что» или «для кругозора».
но пытаюсь вам доказать, что разделение труда — не самоцель, а суровая необходимость.
Это очевидно, вы тратите свое и мое время. Это необходимость, вызванная ограниченными возможносятми человека.
Если бы возможности мозга были бы безграничны,
Если бы… это невозможно. Знаете байку про экзамен в физтех с шуткой о кошке?
Я всегда старался максимально расширять свой кругозор
И это замечательно. Что не отменяет того, что вы специализируетесь в какой-то области. И чем сложнее будут вещи, с которыми мы работаем, тем более глубокая специализация потребуется.
Возможно, я зря ломлюсь в открытую дверь в случае спора с вами, но обычно следом за утверждением об «обязательном разделении труда» идет утверждение о том, что специалист «должен заниматься только своим делом», то есть умывать руки всякий раз, когда задача выходит на миллиметр за пределы его формальной компетенции.
А это называется «итальянская забастовка».
Для этого стараюсь не использовать сторонний код без необходимости.
Особенно это касается фреймворков PHP.
Так что вся эта тревога о качестве в данном случае была совершенно ни к чему. Качества несуществующего продукта измерить нельзя.
Зураб Ираклиевич сидел за столом. В руке у него была курительная трубка. Он мне напомнил одного своего соотечественника, очень популярного в свое время. В кабинете было все, что нужно для жизни. Цветной телевизор, бар, кресла, диваны, журнальный столик, книжный шкаф, натюрморты на стенах и тому подобное.
Мы тепло поздоровались, и я вынул из портфеля три экземпляра отчета.
– Вот, – скромно сказал я. – Нам удалось кое-что сделать.
Зураб Ираклиевич взял отчет и взвесил его в руке. Потом он перелистал его, выражая удивленное внимание. Меглишвили делал в это время то же самое, пользуясь вторым экземпляром отчета. Зураб Ираклиевич нажал кнопку и сказал в микрофон:
– Чхилая ко мне.
В кабинете возник Чхилая. Он почтительно взял отчет и стал рассматривать кривые, цокая языком.
– Как ви оцениваете? – спросил Зураб Ираклиевич.
– Именно то, что нам нужно, – быстро сказал Чхилая.
– Ми тоже так думаем, – сказал Зураб Ираклиевич.
Он взял все три экземпляра, подошел к книжному шкафу, открыл его ключом, поставил отчеты на полку и снова закрыл шкаф. По тому, как он это делал, я понял, что отчеты никогда больше не покинут этого шкафа.
– Ви свободны, – сказал он Чхилая. Тот провалился.
Зураб Ираклиевич взял меня за локоть и повел по направлению к бару, расспрашивая о Юрии Тимофеевиче, о его здоровье и прочем. Я стал рассказывать о свадьбе Милы. Это всех заинтересовало. Щелкнули автоматические дверцы бара, засияли зеркальные стенки, заискрились вина и коньяки.
– Что будете пить? – спросил Зураб Ираклиевич.
– Замороженный дайкири, – сказал я, вспомнив один из романов Хемингуэя.
Зураб Ираклиевич слегка склонил голову, оценив во мне знатока. Мой заказ не застал его врасплох. Двигаясь на редкость элегантно, он приготовил три дайкири, и мы уселись за столик, потягивая коктейли из соломки. На столике лежали сигареты «Филип Морис» в коричневой пачке. Разговор шел о погоде, тбилисском «Динамо» и грузинских марках коньяка. Некоторые мы тут же дегустировали. Никто не заикнулся о моей работе. Будто ее и не было.
– Да, чуть было не забыл! – сказал я. – Нужно оформить акты.
Я достал бланки. Зураб Ираклиевич изучил их и положил к себе на стол.
– Завтра вам передадут, – сказал он. – Ну что же… Вам надо познакомиться с Тбилиси. Гия, чтобы все было… понимаешь?
Гия понимающе зажмурил глаза.
…
Я пришел в нашу комнату и показал Чемогурову акты.
– Они даже отчет как следует не посмотрели, – сказал я.
– Ты наивный человек, – сказал Чемогуров. – У них оставались лишние двадцать тысяч рублей. Приближался конец года. Вот они их и потратили. Все довольны – и они, и мы.
– Я недоволен, – сказал я.
Таже ядерная физика — можно вообще всю жизнь учиться, и не научиться проектировать ядерный реактор. А если научиться, то хрен соберешь команду, финансирование и вообще возможность построить полноценный проект.
Раньше все было как в точной науке. А теперь — бетон не такой привезли, арматура с примесями и ржавчиной, окна вроде бы те, но по размерам чуток не совпадают, и надо допиливать.
К примеру очень много правил ПДД написано на крови. Если бы авторы пдд пытались предусмотреть все возможные ньюансы изначально, возможно до сих пор ходили бы пешком. Грустно но правда
Личные воспоминания о серьёзных проектах от микроконтроллеров до Qt в очередной раз показывают, что наша индустрия всё ещё молода, ведь в самом деле, как уже отмечали, невозможно себе представить, чтобы сегодня хирург делал операцию на сердце, а завтра — на мозге.
Получается, что мы работаем несколько «по-ковбойски»: что-то делаем, оно как-то работает, никто не понимает как, и слава богу. Макконнелл считает, что всё будет двигаться в сторону более строгой бюрократической системе разделения работ на основе лицензируемости. Ну, мы уже видим это на примерах всяких сертификатов Oracle или IBM, но в целом, как мне кажется, он впадает в другую крайность.
Я думаю, что проблема будет решаться по кусочкам. Во-первых, есть вопрос денег. Если вы строите у себя амбар на участке, нет смысла нанимать архитектурное бюро и заставлять инженеров просчитывать сопромат. Упадёт — ну и ладно, новый поставим. Так и у нас, глядя на поделия, то есть, гм, инструментарий для внутренних нужд, можно потерять веру в человечество; но мы же понимаем разницу между амбаром на заднем дворе и продуктом на продажу. При этом и вопрос денег тоже решается по-разному. Скажем, китайцам, которые производят ширпотреб десятками или сотнями тысяч единиц, почему-то проще перевести инструкцию гугл-транслейтом, вместо того, чтобы нанять хорошего переводчика всего на один день (!) Видимо, не считают эти космические затраты целесообразными, что тут сказать. В IT ведь всё то же самое: ну хорошо, наймите отдельного специалиста, который разбирается досконально в Qt (и больше ни в чём), но сначала решите, стоит оно того или нет.
Во-вторых, есть вопрос интерфейсов, документированности и обязательств. Пример с «магической строкой» показывает, что не всё здесь ладно, потому что не хватает культуры производства, и это не только авторов Qt проблема, пока попросту нет всеми принятого подхода, и каждый крутится как умеет. Скажем, мне нравится (хотя бы на идейном уровне) подход к документации библиотеки C++ STL. Для каждого алгоритма указаны чёткие требования по входным данным, гарантии выходных данных и асимптотическая сложность алгоритма. При этом почти везде гарантируется, что самостоятельная реализация того же алгоритма вряд ли будет намного лучше, т.е. мысли «переписать STL» в большинстве случаев возникать не должно. То есть мы имеем чётко определённые «кирпичи» с заданными характеристиками, и лезть внутрь такого «кирпича» совершенно незачем. Сравните это с ситуацией в Python, где сам автор языка последовательно перебирает различные «волшебные» строки с целью ускорить алгоритм (не всегда представляя себе ожидаемый результат).
Иными словами, разделение ответственности и ликвидация «волшебных» строк в целом возможны. Но всё это требует больших усилий, денег и дисциплины. Кому-то удаётся лучше, кому-то — так себе. В общем, ужас, но не ужас-ужас-ужас.
О, мой любимый пример — GPS! Вам вовсе не обязательно быть специалистом в радиосвязи, ракетостроении и конструкциях спутников, чтобы получать данные от GPS в своем приложении для смартфона. Но вся система, в целом, в таком случае, становится становится некой "магической" средой, где для достижения результата нужно знать определенные "заклинания". Мы живем в интересное время, когда технологии становятся не менее абстрактными, чем идеи, но лично меня это не пугает. Главное — дружить и говорить на одном языке с теми "демонами", с которыми вы имеете дело, а остальной мир пусть остается "волшебным", это же весело! Ну и то, что называется "технологической сингулярностью", ИМХО, давно уже наступило, в глобальном плане. Это было неизбежно, и главное не тормозить с адаптацией собственного мышления к новой среде.
Не все возможно доживут, но уж точно мир не рухнет.
ЗЫ: эта статья отличается от прочих в лучшую сторону тем, что в ней хотя бы пара строк кода есть.
Да, бывают и курьезы, например, собраный на коленке из чего-то там и палок RLE для несжатых текстур оказался выгоднее всех существующих. До сих пор не могу себя заставить от него избавиться.
я пишу для чужих либ тесты, бенчмарки и собственные реализации
Весьма интересный подход к насущному вопросу.
Но вот в чём другой вопрос: смысл чужих либ как раз таки в том, чтобы не писать свои самому — насколько окупается написание тестов и собственных реализаций? Всегда ли есть на это время? Если нет — то как поступаете?
Возможно, не будь я программистом, мне не было бы так страшно…
А теперь представьте, как страшно жить химикам, особенно тем, кто связан с производством. В университетский курс входит изучение 3-7 различных направлений химии в семестр. Достаточно, чтоб разбираться в свойства всего, что нас окружает: строй материалы, отделочные, мебель, пищевая химия и экология, лекарственные средства, косметические средства и много другое.
Вы правы на все 100%. И от этого грустно. Потому что всем плевать: живут здесь и сейчас, а что будет завтра — не важно: перепишем, перекодируем, пере-, пере-, пере...
Стыдно сказать, что я даже AngularJS знаю очень и очень поверхностно просто потому что реальных проектов с ним не было, а вот-вот прийдёт 2ая версия и может сложиться так, что 1ая мне никогда и не понадобится.
Другая проблема — это компетенция самих разработчиков и команды в целом. Я работал в проектах, где были сильные программисты, середнячки и откровенно слабые. И если у части команды возникали вопросы о том, как будет работать система в целом, какие плюсы и минусы есть у данного решения и т.д, то у некоторых этих вопросов не возникало и они просто кодили или даже собирали пазл из раннее написанного кода и того, что нашли в интернете. Всё это приводило к скрытым и плавающим багам и даже к проблемам в архитектуре. И такого кода много в любой крупной системе.
Поэтому чем больше мы внедряем ПО в нашу жизнь, тем больше вероятность что какие-то из этих ошибок выстрелят и приведут к очень печальных последствиям. Конечно входить в высотные здания и летать на самолёте я пока ещё не очень боюсь, а вот пользоваться онлайн-банкингом побаиваюсь значительно сильнее. (Опять же примерно представляя качество продукта, которым приходится пользоваться).
Но тем не менее — не думаю, что всё вышеописанное — плохо. Это как с автомобилем — все знают что достаточно одного неверного решения или действия — и вы можете погибнуть, но тем не менее все продолжают ими пользоваться потому что удобство от использования перевешивает страх.
должно быть вот так примерно
/>
Это происходит от нежелания людей вникать в нюансы, от непрофессионализма, от жадности, от глупости…
Да, мы ограничены. Да, мы не всегда понимаем, что мы делаем. Да, сложность зашкаливает, и мы не можем её победить. Ну и что? Это мешает нам делать мир лучше? Каждый чертов день мы можем все больше и больше, и я счастлив принимать в этом участие.
А по теме — с ростом сложности происходит разделение по уровням. Пример — сетевая модель OSI. Каждый из её уровней сам по себе очень сложен, но как то они уживаются вместе. И конечно включается естественный отбор. Та же Qt — библиотека смогла выжить, она поддержана большим сообществом разработчиков и позволяет разрабатывать сложные проекты.
Вообще может появиться новая научная специальность — разработка абстрактных моделей программных систем, которая позволит хоть немного причесать хаос и займёт такое же место в программировании,, которое в Большой Физике занимают ядерная и квантовая физики. Кое что есть уже сейчас — пример — сетевая модель OSI, или модель STL.
У "железных" и строительных инженеров тоже есть свои баги — только называются они по другому — можно погуглить "обрушение", "потеря прочности", "Избранные проблемы прочности современного машиностроения".
Но вот идея о том что программа должна точно соответствовать спецификации — здравая, просто программированию до этого состояния ещё далеко. И у строителей и у машиностроителей была в их проф-й истории такая же "эпоха хаоса" — до того как они начали активно внедрять стандартизацию и сертификацию всего и вся. Сейчас, в связи с развитием интернета вещей, повышения уровня ответственности за жизнь и здоровье людей и повсеместное внедрение 3д принтеров (тут то — в этой точке, и повстречаются программисты с машиностроителями...:) а потом и со строителями) и прочих новомодных штук типа автопилотов или строительных роботов — попоболь от несоответствия стандартам усилится, и это положит начало новому витку стандартизации при котором, например, за применение нестандартного и неодобренного языка начнут "расстреливать на месте без разговоров и без сбора особой тройки — в простом порядке: матрос, винтарь, патрон".
Огромная разница между софто-инженерами и строителями заключается в том, что строители стараются всё просчитать, но не всё получается. Софто-инженеры же зачастую делают на "прокатит".
— О, Вась, смотри — новая либа, давай её внедрим!
— Но Иван Иванович сказал пользоваться тем, что у нас давно оттестировано и слажено работает.
— Вааась, Иван Иванович старпёр со своим С++/C#/Fortran'ом (нужное подчеркнуть) — не идёт в ногу со временем! Эту либу используют все популярные мордокниги/файлохранилки/инстаграмушки.
— Ну не знааю, ну давай…
Такая типичная ситуация: слить старое только потому, что оно не новое. Плевать на тесты, плевать на баги. Главное внедрить очередную новинку — даже не задумываясь о последствиях.
Гуглите "провальные стройки", "failing construction" — там можно найти случаи на любой вкус и цвет.
Ну а, о том, каков вообще уровень ответственности, моральное давление в этой сфере, можно узнать гугля:
"Enjineer suicide on business reasons and circumstances"
"инженер самоубийство"
Машинист товарного(!) поезда, подъезжая к мосту, останавливался.
Помощник машиниста пешком переходил мост и ждал на другой стороне моста.
Машинист поезда давал самый малый ход составу и сам выпрыгивал из кабины паровоза.
Помощник машиниста, на другой стороне моста, на ходу, вспрыгивал в кабину паровоза и, при окончании прохождения всем составом моста, останавливал состав для ожидания, когда к паровозу пешком подойдёт машинист.
Вот так происходил проезд моста в Штатах, сравнительно недавно.
Потом появилась наука по строительству мостов…
Зависит от специфики проекта и компании.
«Будем ли мы бояться летать на самолетах и ездить в беспилотных автомобилях? Можно ли верить медицинским приборам? Не побоимся ли мы входить в систему онлайн-банка? „
В области авиации и медицины очень высокие стандарты обеспечения качества. В области банковских услуг пониже, но всё-равно больше чем в большинстве проектов, и, зачастую, потери вызванные из-за программной ошибки возмещаются банком.(торги на электронных биржах не в счёт)
https://geektimes.ru/post/279548/
https://habrahabr.ru/company/pvs-studio/blog/307788/
считаю, что ПО от которого зависят жизни и здоровье людей (автопилоты самолётов, электронные помощники в авто, управление медтехникой и реакторами АЭС) должно быть либо открытым (чтобы любой заинтересованный мог проверить логику его работы), либо быть написаным специалистом, подписавшим договор о персональной административной/имущественной/уголовной ответственности за последствия работы его программы.
Желаю автору не болеть всю жизнь.
Иначе без анализов (которые делаются медицинскими приборами) доктора его
“пошлют» — и останется только что то вроде «нетрадиционной медицины»
Впрочем, проблемы бывают не только при невыполнении правил, но и при некоторых предположениях, закладываемых в логику работы приборов.
Про цветок.
Да, Вы объяснили силой тяжести и его ростом причину его падения, но разве Вы знаете откуда взялась сила тяжести и/или почему он рос? Знание причин почему что-то работает никогда полным не будет.
Так почему это это должно быть проблемой именно в программировании?
Это не проблема, это реальность, и тут самое главное суметь ее принять.
«premature optimization root of evil» по большому счету оттуда же, от желания все сделать идеально правильно, но именно поэтому эта идея и проваливается.
Некоторое количество погрешностей будет всегда и без понимания этого нет самого важного — понимания что с этими погрешностями надо работать и как надо с ними работать.
Упрощая… допустим Вы не знаете почему этот цветок падает, но раз Вы можете предусмотреть такую возможность, просто привязываете горшок веревкой.
Подумайте только, что происходит, когда вы смотрите котиков на ютубе. Огромное число элементов взаимодействуют друг с другом: железо сервера от разных производителей (оператива, процессор, сетевая карта, хранилище, шины данных), firmware для этого железа, ОС с тысячами библиотек, написаных разными людьми, веб-сервер, каналы связи, маршрутизаторы со своим ПО, железо вашего компа со всем его firmware, ОС, браузер, кодеки. Все это передает данные друг другу по разным протоколам, использует разные технологии. На самом деле это только верхушка айсберга. Если разбирать каждый элемент этой системы — он сам по себе представляет сложную систему взаимодействующих частей.
Все, что происходит, я могу назвать только волшебством. Не потому, что я не понимаю, как это работает, а как раз наоборот — потому что я более-менее знаю, что происходит. Мне не дает покоя один вопрос: какого лешего это всё не ломается уже сейчас?
Сразу отвечу насчет стандартизации и тестирования — это не панацея. Все мы знаем, что идеального ПО не существует.
Представьте себе, что в алгоритме одной библиотеки есть ошибка: при определенной последовательности входных данных на выход вылетает мусор. Сможем мы протестировать эту последовательность, если она встречается довольно редко? Нет. Мы не может потестировать все пространство входных данных, иначе в этом алгоритме не было бы смысла: достаточно было бы взять матрицу вход/выход из тестов. Все ПО, которое использует библиотеку расчитывает на корректность ее работы. Что в итоге? UB работы всей системы.
Это простой случай. А теперь более сложый. Если эту последовательность не тестировали, потому что она никогда не должна была поступить на вход? Но случилось так, что элемент системы от которого пришли данные тоже имел небольшую ошибку. Эта область пересечения нескольких ошибок разных частей и вызвала крах всей системы. Такие вещи практически непредсказуемы.
А теперь представьте, что в современных гипер-сложных системах сотни (если не тысячи) таких точек возможного слома. Просто они спят и ждут своего часа. Еще не страшно? Сейчас-сейчас… А давайте мы добавим в систему более непредсказуемые элементы навроде нейронных сетей? Сдобрим это все генетическими алгоритмами? И заставим системы больше взаимодействовать с реальным миром и друг с другом, добавив тем самым сложности и случайности?
Завидую людям, которые не заглядывают на другие уровни абстракции. Как же им проще: они уверены, что когда что-то используют — все будет хорошо. Вы как хотите, а я пойду выбирать себе талисман на удачу :)
P.S. только что наткнулся на статью, которая сильно перекливается с моими мыслями
Если вы думаете, что оно должно сломаться, а оно все никак не ломается — это не волшебство, это вы неправы.
У каждой системы есть срок службы, в конце концов.
Хотите свежий пример? Есть смартфон от фирмы S с номером 7. Думаю, вы в курсе новостей. Тестировали ли аккумулятор во время разработки? Конечно да. Сам смартфон? Определенно. Контроллер зарядки? Да. Все вместе? Конечно!
Почему же он взрывается? Дело не в качестве отдельных частей, но в их объединение. Это объединение создало сложную систему не только с новыми свойствами, но и с новыми потенциальными ошибками.
Почему же эти ошибки не нашли во время тестирования? Отдельные части были протестированы и, думаю, работали хорошо. Насколько я помню, число бракованых смартфонов составляет 25 на миллион. Как вы думаете, какова была вероятность наткнуться на этот баг во время тестов всего смартфона? Очень мала. Смарт выпустили на рынок — и тут сработал закон больших чисел.
Почему же он взрывается?
Брак при производстве. Который выразился в сильном сжатие батареи (при её производстве), что и приводит к возгоранию.
Причина: При производстве не проводился достаточный(!) контроль на деформацию батареи.
Виновные наказаны (расстреляны?) — но осадочек и не слабый то, остался.
Если программисты и далее будут писать микроконтроллеры на Node.js, то да, всё плохо. Выбор языка программирования не решает всех бед, но позволяет существенно повлиять на доверие к поведеню программ. Скажем, сильная типизация Rust позволяет избежать множества ошибок ещё до тестирования, а также гарантирует определённое поведение при исключительных ситуациях (паника).
Отставив проблемы человеческих отношений в сторону (это отдельная тема), я вижу большой потенциал в развитии парадигм программирования и инструментов, их реализующих. Скажем, если вы в функциональном языке вызываете чистую функцию с определёнными параметрами, то во-первых можете быть уверены, что результат при тех же аргументах не изменится; а во вторых, что она не станет ломать пентагон и нажимать на красную кнопку.
Вот, например, автор боится идти по мосту, потому что программисты, которые писали программы проектирования мостов, не знали до конца, что именно они делают, а заказчик программы (по сути — конечный её пользователь) вообще не разбирается в программировании.
Но при этом автор забывает, что мост проектировала не только программа, но и люди. И не поверите — 99% проектировщиков мостов и других сооружений и зданий не являются специалистами в теории упругости. Да многие (очень многие) не вспоминают даже простого сопромата при проектировании строительных конструкций. А еще очень мало кто из них является специалистом в материаловедении и не представляет себе ни состава используемой стали, ни процесса прокатки двутавровых балок. Конечно, проектировщик, который знает всю подноготную строительства от добычи ископаемых до покраски фасадов ценится выше. Но таких, честно скажу, не много.
Да, у нас, у проектировщиков, все то же самое — разделение труда и совершенно слепое использование чужих наработок. Один институт разрабатывает состав бетона, второй разрабатывает технологию его укладки, третий — сталь для арматуры, четвертый — профиль арматуры, пятый — формирует серию на изготовление железобетонных плит, шестой — просто применяет их в проекте. Всё то же, что и в программировании — есть низкоуровневая разработка, есть высокоуровневая, есть библиотеки готовых
А заказчики у нас техзадание вообще писать не умеют. Совершенно. Абсолютно. Приходят и просят проектную организацию саму себе задание написать и ставят под ним подпись.
И это в любых областях нашей жизни так — терапевт в районной поликлинике — не микробиолог и может не представлять себе, как именно лекарство будет воздействовать на ваши клетки. А вы, как заказчик работы терапевта — тем более.
Так что еще можно поспорить, кто быстрее погубит мир))
Я осознал это в первый раз, когда мне ученный(доктор наук) физик ядерщик не смог во время одной из дискуссии ответить, как при помощи закона Гука рассчитать прикладываемую силу к пружине, при известной степени деформации.
Однако были и нюансы:
Эти нюансы по хорошему должен разрешать специальный человек, который называется «инженер-системотехник». Именно он и должен был обеспечить коммуникацию между вами и «железячниками», и разбираться с тем, что Вы назвали «Бедой N2».
Вообще, странно, что вы задались этим вопросом только сейчас, потому что на самом деле наш мир работает так уже достаточно давно. Если взять любую сложную систему, то мы вряд ли найдем человека досконально понимающего нюансы работы всех ее подсистем. Взять даже ассемблер, когда Вы пишите команду, думаете ли Вы о том, когда конкретно процессор ее вычитает, во что преобразует ее декодер инструкций, что произойдет с ней в конвейере, в каких физических регистрах окажется результат, и так далее? Думаю, что вряд ли, и процессор для Вас тоже своего рода «черный ящик», но ящик привычный, и потому не вызывающий вопросов и опасений «а вдруг там баг», а вот библиотека — ящик непривычный, отсюда и опасения.
На самом деле, если начать задумываться о том, сколько «деталей» и процессов должно быть задействовано, чтобы отправить или прочесть это сообщение, сколько тысяч людей понадобилось, чтобы все эти «детали» создать, сколько подводных камней им пришлось обойти, чтобы заставить это заработать, и сколько во всем этом мест, где что-то может сломаться, недолго заработать тяжелую форму паранойи.
>>Эй! Коллега программист! Это что еще за хрень?
Об этой «хрени» наверняка есть где-то целый раздел в документации (где, возможно, и строчечки те волшебные приведены), который эти две кодомакаки, по обыкновению, не читали. А потом им «что-то слишком сложно и непонятно все, я боюся чо-то». (Да, я знаю, что бывают баги в либах, но чаще всего виноваты все же не они, а сами макаки.)
А вообще, есть такая хорошая книжка Гради Буча, называется «Объектно-ориентированный анализ и проектирование». Он там наглядно (в смешных картинках с котиками), но очень толково объясняет, как программист может понимать, почему (не)работает система, не разбирая в деталях устройство ее компонентов, и почему пользователю сложная система может казаться простой и понятной (и это правильно). Так что снизу доверху знать, «как работает программа», не нужно.
Не понимаю в чём пафос статьи.
Были времена, где программист мог объяснить поведение своей программы с точностью до ячейки памяти.
Те времена канули в лету.
Следовательно, знать от и до, как работает программа, вообще невозможно.
Этот «товарищ» вам все сказал правильно, слово «инкапсуляция» вам о чем-то говорит?
Но я могу оценить подходы в разработке: качество кода, покрытие тестами, общую архитектуру, число тикетов на багтрекере, насколько их быстро закрывают, кто эту библиотеку разрабатывает в конце концов. И это срабатывает в большинстве случаев.
В случае закрытого ПО я не смогу этого сделать. Мне приходится верить. Что-что, а обещать в современном мире красивых презентаци и лендингов умеют все. Вот я даже не смогу исправить ошибку в библиотеке, если на нее наткнусь.
Еще один совет: когда вы собираетесь выложить свою библиотеку в открытый доступ — помните, что какой-то чудак может использовать ее на атомной станции :) Пишите хороший код.
А если серьезно, вам уже миллион раз написали, что у всего есть свои сценарии использования (т.е. интерфейс) и сфера применения.
То, что библиотека ведет себя так, как описано в доках, и используется в тысячах проектов, у вас не срабатывает? Хотя вот, например, openssl… Ах да, она же открытая.
Я как раз таки осознаю свою некомпетентность. Я не понимаю как ее преодолеть. Преодолеть можно, но это время, которого на самом деле почти нет.
Смотрите, предположим меня просят участвовать в проекте с использованием Qt, который я ранее не использовал. Однако руководство считает, что мне нужно временно помочь коллегам с этим проектом. Естественно я как могу быстро пытаюсь понять, что такое Qt и как это работает.
По собственному опыту или по собственной не компетенции могу сказать, что некоторые компоненты Qt работают довольно загадочно. По крайней мере для меня.
Например: QMediaPlayer воспроизводит локальные видео файлы точно как описано в документации, можно делать паузу, воспроизведение и менять позицию воспроизведения. Однако, если вместо локального файла использовать QUrl указывающий на сетевой ресурс, то воспроизведение начинается, но сменить позицию воспроизведения setPosition() уже не получается. Почему? Почему QMediaPlayer не следует документации Qt? К слову в документации Qt фообще нет упоминания про воспроизведение из сетевых ресурсов. Может это вообще нельзя?
Это происходит в Windows c Qt мультимедиа бэкендом dsengine_plugin.
Если же ту же самую программу без изменений компилировать и запускать в Linux, с мультимедиа бэкэндом gstreamer, то все работает: и setPosition() так же замечательно работает. Что за такая кроссплатформенность в Qt, которая по разному себя ведет на разных платформах? И как я это должен чинить? Нам просто повезло, что оказывается Qt предлагает для виндовс на выбор второй мультимедиа бэкэнд wmfengine_plugin, который и в виндовс ведет себя достойно. Но почему он в Qt библиотеках по умолчанию не стоит? Для меня это сплошное недоумение.
Должен ли я не разобравшись до конца, почему один бэкэнд лучше другого просто плюнуть и использовать второй? Или нужно тратить время и разбираться где баг в библиотеке Qt?
Да, я согласен. Моя не компетенция. Но эта такая «не компетенция» которая занимает полторы недели безрезультатного поиска в гугле и чтения документации Qt, в которой про воспроизведение из сети вообще ничего нет.
Кстати в примере с компьютером «Специалист» есть фраза — «я знал о программе всё», но это наверняка это не так. Например, как выполняются команды внутри процессора? Так что принципиально ничего не изменилось. Мы создаём новые продукты на основе того, что кто-то сделал раньше.
Некомпетентность ваша не в том, что вы не понимаете, как оно работает.
Она в том, что вы пытаетесь найти workaround вместо того, чтобы искать _надежное_ решение (да, найти другое стороннее решение, которое работает, как заявлено, или написать свое). Системы, построенные методом тыка, и работают, как попало — тут вы никакой Америки не открыли, капитан.
«Гы-гы хрень какайто нук тыкни суды чо будит» — типичный технарь-стайл говночистов по компьютерам (может быть, это в самом деле и не так, но я сужу по тому, что вы написали). И вы пишете так, как будто это нормально и неизбежно. Я тысячу раз видел, как люди ругали инструменты и пытались методом тыка что-нибудь «порезолвить» из-за собственных «кривых рук» и превратного восприятия.
QMediaPlayer::seekable() что возвращала? Если false, все ок, все по документации. Где написано, что любой media source можно прокручивать? Там еще seekableChanged() есть (заметили ее вообще?), что как бы намекает нам, что media source может совершенно внезапно стать/перестать быть seekable, и библиотека вас уведомит, когда это произойдет.
Года три назад я себе представить не мог, что увижу такое на хабре.
мой приятель живет в Москве
У вас что-то с чуством юмора случилось. Я спрашивал адрес квартиры, где деньги лежат.
В итоге, он накопил и купил квартиру в МСК, без всякого кредита.
Это тут вообще при чем? Если бы деньги лежали на депозитах, он бы накопил еще быстрее. При стоимости квартир в Москве, он бы в районе миллиона в год только процентов имел.
Но история больше на сказку похожа. Сдается мне, либо вы нам лапшу на уши вешаете, либо ваш приятель вам. С зарплатой админа копить на мало мальски приличную квартиру в Москве нужно лет 10, как минимум. За это время половину денег, лежащих под подушкой, просто сожрет инфляция. Именно для борьбы с этой самой инфляцией и берется ипотека или деньги вкладываются в инструменты с доходностью выше оной.
В общем, ваш приятель везучий глупец-сказочник. Почитайте сводки по квартирным кражам и задумайтесь про ошибку выжившего (погуглите, что это такое), стоя следующий раз перед АТМ-кой.
посредственный начальник: — И чтоб через 3 месяца было готово!
непосредственный начальник: — Мы не сможем обрабатывать абсолютно все записи — и будем терять по миллиону в квартал на недовыставленных счетах
посредственный начальник: — Плевать, мы платим 3 миллиона в квартал за аренду софта, который выставляет все счета правильно
Технологии, за которыми всё труднее угнаться и полностью постичь хотя бы одну из них, — это порождение коллективного разума, которое живёт своей жизнью, обладает своими механизмами саморегуляции.
Стремительная метаморфоза из постиндустриального в информационно-ориентированный уклад жизни действительно выглядит как крах фундаментальных устоев, но это далеко не первая «революция» которую переживает человеческое сознание.
И как предлагал Платон довериться «человеку-познающему», сейчас настало время довериться «технологии-развивающейся». Рынок и коллективный разум естественным образом будет поддерживать только правильные технологии, наиболее актуальные и развитые.
И хоть каждому отдельному специалисту и тяжело с пониманием технологии в целом (хотя это и не означает, что не надо профессионально развиваться), человеческое сообщество и наш уклад жизни сейчас действует как своеобразный инкубатор: питательная (для развития) и в меру агрессивная (для естественного отбора) среда, в которой происходит процесс эволюции информационных технологий.
Неразумное африканское племя не может нарушить биобаланс планеты, но разумные европецы и американцы — вполне могут, обладают технологиями сжигания топлива в непомерных количествах и всякими ЯО. Кто больше всего генерирует мусора? Думаю именно экономически развитые цивилизации и государства.
Все, что человек делает за свою жизнь — приближает крах.
Даже человек с профессией «учитель», развивая интерес к знаниям у учеников не безвреден. Вот выучится кто-то любознательный под влиянием хорошего учителя и изобретет какое нибудь «мюонное топливо», военные из него как водится сделают бомбу и испытают ее.
Программисты, находясь на передовой всяких научных исследований приближают конец прогресса.
Прогресс движется вверх не линейно, а в квадрате или в кубе от пройденного времени.
Остановить это к сожалению или к счастью нельзя, как нельзя сказать дереву «не расти».
Так уже.
Домашний компьютер, Windows 10: выдает тихий звук. Переустановка драйвера возвращает звук в норму. На следующий день опять тихо.
IDE Eclipse for Java Developers: раз в несколько дней зацикливается, приходится убивать процесс.
Лифт в здании, где я работаю: иногда отказывается везти на 4 этаж.
Накачал музыкальных обучающих программ — ни одна не работает как следует.
Он так себя уже лет 15 ведёт. ;-)
«История этой IDE началась в далеком 1995 году. В 2000 году она перешла в руки Sun, а в 2009 году Oracle забрала ее вместе с Java в рамках сделки с Sun.
И вот теперь Oracle один за другим отказывается от проектов, перешедших ей от Sun: OpenSolaris, технологии виртуализации, OpenOffice. Выпуск новой версии самого главного продукта, Java, постоянно переносится. Настал черед и NetBeans. Среда разработки, впрочем, не брошена на произвол судьбы — как сообщается в блоге Apache, теперь проектом будет заниматься именно эта компания.
На самом деле такой исход был вполне ожидаем. Популярность NetBeans медленно, но верно падала — битву за право называться универсальной IDE NetBeans проиграла, уступив место Eclipse.
Остается лишь надеяться, что Apache Foundation серьезно отнесется к попавшему в ее руки продукту и не позволит ему исчезнуть совсем.»
Однажды программисты погубят этот мир