Комментарии 199
НЛО прилетело и опубликовало эту надпись здесь
просто спросил бы, при чём тут QuickTime :-)
Это явление закономерно, когда сапожник печет пироги, а сапоги шьет пирожник, эдакая война миров. Надо полагать, будущее программистов будет неизбежно упираться не в языковый скрипт выражающий клиентский поведенческий алгоритм, а в создание платформы нового поколения с инструментальной средой генерирования исходников в интерфейсе под конечного пользователя и пусть он там играется со своими алгоритмами до одури, симулирует свои процессы, в финале отправляет в печать готовую PCB.
НЛО прилетело и опубликовало эту надпись здесь
Таки это мелочи. Какая разница, как это было названо, если все поняли, о чём идёт речь?
НЛО прилетело и опубликовало эту надпись здесь
Нет, это, как раз-таки, мелочь. Многие даже не знают, что «Qt» — это не аббревиатура. Удивляет, как на это постоянно обращают внимание, а на то, что в четверти, а то и в трети, всех хабратопиков неправильно употребляется деепричастный оборот, закрывают глаза. Например, прямо сейчас на главной странице висит: «Пережив некоторые трудности, сегодня это — достаточно зрелый продукт». Не говоря уже о всяких «Нажав на кнопку, начинает звучать мелодия» и подобное. Вот где, действительно, не мелочь, но никто словно не замечает. Или правда не замечает? Видимо, куда проще показать свою «грамотность», заучив какой-нибудь шаблон, что «Qt, а не QT», что «Андроид, а не Андройд».
НЛО прилетело и опубликовало эту надпись здесь
В том, что это избитая и заезженная тема. Вы не научите каждого говорить так, как считаете нужным, а если очень сильно хочется, то это можно сделать и в привате. Как я уже сказал, на Хабре полно куда более грубых ошибок, и то, что вы их не видите в приведённых мной примерах, лишь иллюстрирует плачевность ситуации. Но при этом Хабр пестрит обвинениями в одних и тех же ошибках. Это уже все видели, просто кто хотел, уже давно взял это на вооружение, остальным это бесполезно объяснять.
По поводу деепричастных оборотов читайте здесь. Есть ещё очень распространённая ошибка с мягким знаком (или его отсутствием) в глаголах, оканчивающихся на «ться» и «тся». И про это тоже есть сайт, правда, я далеко не первый, кто на него ссылается. Эту ошибку, всё-таки, хотя бы иногда замечают и исправляют.
По поводу деепричастных оборотов читайте здесь. Есть ещё очень распространённая ошибка с мягким знаком (или его отсутствием) в глаголах, оканчивающихся на «ться» и «тся». И про это тоже есть сайт, правда, я далеко не первый, кто на него ссылается. Эту ошибку, всё-таки, хотя бы иногда замечают и исправляют.
Про расшифровку аббревиатур улыбнуло: «Парни со стволами» с 0:51:11 — 0:52:30
Да, пиши так дальше. Я не против
Тоже считаю, что не мелочи. Один бывший сотрудник — программист не выключал в туалете свет. Ну как можно — включить и не выключить!
И это программист. Страшно предстаить, что там в коде :)
И это программист. Страшно предстаить, что там в коде :)
Вы не поверите, но многие общественные туалеты (на работе — это тоже не «личный», а рассчитанный на группу сотрудников) делаются из расчета, что свет в них не выключается. Например, включение вытяжки делают на том же выключателе, на котором свет работает.
Это я к тому, что Вы уверены в своей правоте, хотя, вполне возможно, ошибаетесь, не обладая достаточной информацией.
Это я к тому, что Вы уверены в своей правоте, хотя, вполне возможно, ошибаетесь, не обладая достаточной информацией.
Это не мелочи. Это «нечего сказать — доедокопайся до орфографии».
Все поняли о чём речь, но если столкнутся с тем, что на самом деле называется QT, то будет путаница.
Я на работе уже всех выдрессировал называть I2C «ай-ту-си» или «и-два-цэ», а не «и-два-эс». Потому что есть I2S.
Я на работе уже всех выдрессировал называть I2C «ай-ту-си» или «и-два-цэ», а не «и-два-эс». Потому что есть I2S.
> пусть он там играется со своими алгоритмами до одури
Никогда конечный юзер не будет играть с алгоритмами. Во первых он в этом не разбирается, во вторых ему это не интересно.
Никогда конечный юзер не будет играть с алгоритмами. Во первых он в этом не разбирается, во вторых ему это не интересно.
Псих?
Ладно программисты, эти ещё хоть что-то понимают. Представляете как обидно простым пользователям? Они ни ассемблера, ни фреймворка, ни устройства ОС не знают и шансов не имеют узнать, не положив на это полжизни. И как-то пользуются компьютерами, доверяют чужим компетенциям.
Их успешно защищает Эффект Даннинга-Крюгера. Люди, не представляющие устройства программного обеспечения либо явно (если глупы), либо подсознательно считают его чем-то простым и понятным.
Труднее всего приходится так называемым «продвинутым пользователям», то есть людям, склонным относиться к технике ответственно и изучать инструкции по эксплуатации перед тем, как пользоваться техникой. Мне всегда очень больно наблюдать страдания моего пожилого отца, который не умеет совершать простые манипуляции с собственным Андроид-смартфоном, потому что не знает, как, но который достаточно квалифицирован, чтобы жать «куда попало» (то есть использовать интуицию), на что эти интерфейсы и рассчиланы.
Труднее всего приходится так называемым «продвинутым пользователям», то есть людям, склонным относиться к технике ответственно и изучать инструкции по эксплуатации перед тем, как пользоваться техникой. Мне всегда очень больно наблюдать страдания моего пожилого отца, который не умеет совершать простые манипуляции с собственным Андроид-смартфоном, потому что не знает, как, но который достаточно квалифицирован, чтобы жать «куда попало» (то есть использовать интуицию), на что эти интерфейсы и рассчиланы.
А ещё было время, когда водители авто сами их собирали и в точности знали каждый болтик и винтик, ибо были эти самые авто штучным изделием…
А ещё было время, когда великие врачи, чьи имена вписаны в историю человечества, сами своими руками изготавливали целебные настои и точно знали как они действуют на организм человека, доверяя своему опыту, а не бездушным инструкциям-вкладышам…
Уж не знаю, к сожалению ли или к радости, но сейчас наступила эпоха готовых решений. Мне это тоже не по душе. Я помню как сам писал и обучал нейронные сети, реализовывал генетические алгоритмы, точно знал все нюансы своих программ. Но современный рынок требует умения пользоваться готовыми решениями. И я пользуюсь стандартными библиотеками.
Это наша реальность и приходится с ней мириться. Хотя, знание основ — это огромный плюс, так как это возможность создать новое готовое решение для новой проблемы, которое будем использоваться многими, кто даже не задумается, как там всё устроено.
А ещё было время, когда великие врачи, чьи имена вписаны в историю человечества, сами своими руками изготавливали целебные настои и точно знали как они действуют на организм человека, доверяя своему опыту, а не бездушным инструкциям-вкладышам…
Уж не знаю, к сожалению ли или к радости, но сейчас наступила эпоха готовых решений. Мне это тоже не по душе. Я помню как сам писал и обучал нейронные сети, реализовывал генетические алгоритмы, точно знал все нюансы своих программ. Но современный рынок требует умения пользоваться готовыми решениями. И я пользуюсь стандартными библиотеками.
Это наша реальность и приходится с ней мириться. Хотя, знание основ — это огромный плюс, так как это возможность создать новое готовое решение для новой проблемы, которое будем использоваться многими, кто даже не задумается, как там всё устроено.
Ваши примеры нерелевантны.
— Технически-подкованный водитель и сейчас знает об устройстве своего автомобиля ровно столько, сколько нужно, чтобы на этом автомобиле успешно передвигаться. И даже поменять колесо в экстренной ситуации.
Они доверяют ремонт авто работникам сервисов не потому, что не знают, как что работает, а потому, что справдливо полагают, что работники сервиса чинят лучше.
— Я никому не пожелаю иметь дело с врачом, не понимающим биохимические и фармакинетический свойства выписываемых им препаратов. Опять же, фармакомпания делает, а понимать должны все, кто выписывает (и, кстати, неплохо бы, чтобы хоть немного понимали даже те, кто принимает).
Не обязательно знать каждый ньюанс в том, что ты используешь. Но основоположные вещи нужно знать обязательно. Иначе случится катастрофа. За примером далеко ходить не надо. И он, к слову, произошел еще до «айтишной революции».
— Технически-подкованный водитель и сейчас знает об устройстве своего автомобиля ровно столько, сколько нужно, чтобы на этом автомобиле успешно передвигаться. И даже поменять колесо в экстренной ситуации.
Они доверяют ремонт авто работникам сервисов не потому, что не знают, как что работает, а потому, что справдливо полагают, что работники сервиса чинят лучше.
— Я никому не пожелаю иметь дело с врачом, не понимающим биохимические и фармакинетический свойства выписываемых им препаратов. Опять же, фармакомпания делает, а понимать должны все, кто выписывает (и, кстати, неплохо бы, чтобы хоть немного понимали даже те, кто принимает).
Не обязательно знать каждый ньюанс в том, что ты используешь. Но основоположные вещи нужно знать обязательно. Иначе случится катастрофа. За примером далеко ходить не надо. И он, к слову, произошел еще до «айтишной революции».
А я и не утверждаю, что водитель не должен понимать как работает автомобиль и уметь провести простейшее обслуживание, а врач не понимать как действует препарат…
Но, если абсолютно всё делать самому от и до, то можно очень сильно отстать от современности. Приходится находить компромисс между своим опытом и доверием другим специалистам, предлагающим нам готовые решения.
И разработчик обязан знать как ДОЛЖЕН работать используемый им продукт. А вот работает ли он так на самом деле? В этом, приходится доверяться разработчику продукта. Ибо воссоздать все технологии одному человеку — непосильная и абсурдная задача. Вот тут-то и появляются «магические строчки»… Как механизм приспособления к окружающей нас действительности.
Но, если абсолютно всё делать самому от и до, то можно очень сильно отстать от современности. Приходится находить компромисс между своим опытом и доверием другим специалистам, предлагающим нам готовые решения.
И разработчик обязан знать как ДОЛЖЕН работать используемый им продукт. А вот работает ли он так на самом деле? В этом, приходится доверяться разработчику продукта. Ибо воссоздать все технологии одному человеку — непосильная и абсурдная задача. Вот тут-то и появляются «магические строчки»… Как механизм приспособления к окружающей нас действительности.
> разработчик обязан знать как ДОЛЖЕН работать используемый им продукт
Автор статьи посетовал на то, что существуют «боги из машины», которые «магически» делают ваш код лучше (не слишком понятно, какую цену приходится за это заплатить) и что большинство людей в индустрии не понимают, как они работают.
Так что, строго говоря, никто из этих людей определенному вами долженствованию не удовлетворяет. Не могут они знать, как их продукт должен работать. Если только вы под «должен» не подразумевали техзадание — тут даже менеджер знает, как что «должно работать».
Автор статьи посетовал на то, что существуют «боги из машины», которые «магически» делают ваш код лучше (не слишком понятно, какую цену приходится за это заплатить) и что большинство людей в индустрии не понимают, как они работают.
Так что, строго говоря, никто из этих людей определенному вами долженствованию не удовлетворяет. Не могут они знать, как их продукт должен работать. Если только вы под «должен» не подразумевали техзадание — тут даже менеджер знает, как что «должно работать».
Тоже нет. Менеджер хочет, чтобы продукт вёл себя ожидаемым для него образом. Про «должно работать» тут и речи нет
Менеджер: Когда нибудь придёт время, когда программисты станут не нужны. Я напишу полную и точную спецификацию программы и она сама заработает.
Программист: знаешь как называется самая полная и точная спецификация программы? «Код», это называется «код».
Менеджер: Когда нибудь придёт время, когда программисты станут не нужны. Я напишу полную и точную спецификацию программы и она сама заработает.
Программист: знаешь как называется самая полная и точная спецификация программы? «Код», это называется «код».
Примеры как раз релевантны и вот почему:
Мой отец может разобрать и собрать машину отечественного производства и иностранного до 90х годов. Любую, где не используется компьютер. Заменить ГРМ, перебрать клапана, починить карбюратор из подручных средств — для него не проблема, и экстренно починить заглохший двигатель с помощью гвоздя и резинки тоже (сам видел). При этом скажет сколько она проедет до следующей такой же проблемы. И он, отец, не механик, а простой советский инженер. При этом при обращении с современными машинами, он вынужден обращаться в сервис, и вынужден доверять тем специалистам которые обслужат машину, и их квалификацию, как и результат может проверить только очень поверхностно, как работают эти контроллеры и компьютеры он не знает, при этом постоянно проверяя за сервисными работниками то, что он знает. При этом мой знакомый который работает в мастерской и настраивает электронику в машинах — говорит что все делает по документации и не лезет внутрь.
Так вот, к чему я это написал. В современном мире мы все дальше уходим от понимания принципов работы системы даже среднестатистическим инженером, не говоря уже о конкретном пользователе, и дальше будет хуже.
Мы будем использовать продукты в рамках инструкций не разбираясь в запасах прочности и допусках и вариантах замены в экстренных ситуациях. Мы не сможем экстренно починить заглохший двигатель с помощью гвоздя и резинки.
Мой отец может разобрать и собрать машину отечественного производства и иностранного до 90х годов. Любую, где не используется компьютер. Заменить ГРМ, перебрать клапана, починить карбюратор из подручных средств — для него не проблема, и экстренно починить заглохший двигатель с помощью гвоздя и резинки тоже (сам видел). При этом скажет сколько она проедет до следующей такой же проблемы. И он, отец, не механик, а простой советский инженер. При этом при обращении с современными машинами, он вынужден обращаться в сервис, и вынужден доверять тем специалистам которые обслужат машину, и их квалификацию, как и результат может проверить только очень поверхностно, как работают эти контроллеры и компьютеры он не знает, при этом постоянно проверяя за сервисными работниками то, что он знает. При этом мой знакомый который работает в мастерской и настраивает электронику в машинах — говорит что все делает по документации и не лезет внутрь.
Так вот, к чему я это написал. В современном мире мы все дальше уходим от понимания принципов работы системы даже среднестатистическим инженером, не говоря уже о конкретном пользователе, и дальше будет хуже.
Мы будем использовать продукты в рамках инструкций не разбираясь в запасах прочности и допусках и вариантах замены в экстренных ситуациях. Мы не сможем экстренно починить заглохший двигатель с помощью гвоздя и резинки.
Системы усложняются и сейчас мы кажется уже приблизились в некоторых областях к той точке когда один человек не может полностью уместить всю систему в голове. Пример с автомобилями показателен, но если взглянуть скажем на ракетоноситель, то там уже давно такая ситуация.
Это не хорошо и не плохо, просто особенность любой сложной системы, переход на новый уровень абстракции. Примерно также как инженер, разрабатывающий электронную схему на базе микросхем вряд ли вникает во внутреннее устройство каждой. Аналогично с машинами — на работает блок, на замену. И да починить заглохший двигатель с помощью гвоздя и резинки теперь не получится, но это цена прогресса. Зато мы получаем на много больше плюшек )
Это не хорошо и не плохо, просто особенность любой сложной системы, переход на новый уровень абстракции. Примерно также как инженер, разрабатывающий электронную схему на базе микросхем вряд ли вникает во внутреннее устройство каждой. Аналогично с машинами — на работает блок, на замену. И да починить заглохший двигатель с помощью гвоздя и резинки теперь не получится, но это цена прогресса. Зато мы получаем на много больше плюшек )
Извините, но это называется "ракета-носитель" :). Она ракета, и при этом носитель полезной нагрузки.
А по сути — вы совершенно правы. Это в самом деле цена прогресса. Преимущество гвоздя перед атомным реактором в том, что в гвозде выходить из строя совершенно нечему. Но энергию он, гад такой, не производит.
А по сути — вы совершенно правы. Это в самом деле цена прогресса. Преимущество гвоздя перед атомным реактором в том, что в гвозде выходить из строя совершенно нечему. Но энергию он, гад такой, не производит.
Это всё — как посмотреть. С одной точки зрения, точка «неосознания всей системы» уже давно пройдена, потому что количество идей, вложенных даже в автомобиль 50-х годов уже запредельно для осознания одним человеком (он, конечно, может разобрать/собрать «21» Волгу, но вот изготовить в ней деталь руками и заменить (как это делал на своей работе мой прадед-часовщик) — уже вряд ли. Разве что гвоздем и резинкой…
А с другой стороны, у меня есть друг, который может как ваш отец — натурально всё собрать, разобрать, — он даже модификации в конструкции своей машины сделал — теперь гаишники прикапываются. А еще для него совершенно не проблема программировать микроконтроллеры. И он чудесным образом может починить багу в системе «умного» впрыска топлива, например. Просто, он другого поколения, чем ваш отец.
В плане возможности поддержки и ремонта техники ситуация, когда один человек неспособен разобраться во всем устройстве, преодалена только в одном типе устройств — в компьютерах. Вот там сложность такова, что никто уже толком не понимает, как что работает (кроме пары гениев, которые стояли у истоков, всю жизнь разрабатывали процессоры и чипсеты и еще не ушли на пенсию). И, откровенно говоря, текущее состояние платформы PC немного удручает. Куча глюков, в том числе, — аппаратных, проблемы с софтом, тормоза… В общем, плохо, когда никто не может понять всю систему целиком и хорошенько ее «отрефакторить».
А с другой стороны, у меня есть друг, который может как ваш отец — натурально всё собрать, разобрать, — он даже модификации в конструкции своей машины сделал — теперь гаишники прикапываются. А еще для него совершенно не проблема программировать микроконтроллеры. И он чудесным образом может починить багу в системе «умного» впрыска топлива, например. Просто, он другого поколения, чем ваш отец.
В плане возможности поддержки и ремонта техники ситуация, когда один человек неспособен разобраться во всем устройстве, преодалена только в одном типе устройств — в компьютерах. Вот там сложность такова, что никто уже толком не понимает, как что работает (кроме пары гениев, которые стояли у истоков, всю жизнь разрабатывали процессоры и чипсеты и еще не ушли на пенсию). И, откровенно говоря, текущее состояние платформы PC немного удручает. Куча глюков, в том числе, — аппаратных, проблемы с софтом, тормоза… В общем, плохо, когда никто не может понять всю систему целиком и хорошенько ее «отрефакторить».
Про машины…
Вот мой отец например. Он привык в советское время постоянно быть в гараже, перебирать двигатель, коробку передач, все эти лебёдки, ключи, масло… И вот появилась у него японская машина 20-летней давности. И не знает, что с ней делать в гараже. Ведь по привычке надо в ней копаться, а не «докопаешься». Вот и протирает он её тряпочкой и она всегда чистенькая и блестящая. Трудно ему, непривычно.
Есть ещё такие австралопитеки, которые на полном серьёзе считают, что машину с механической коробкой передач обязан уметь управлять каждый водитель.
Вот мой отец например. Он привык в советское время постоянно быть в гараже, перебирать двигатель, коробку передач, все эти лебёдки, ключи, масло… И вот появилась у него японская машина 20-летней давности. И не знает, что с ней делать в гараже. Ведь по привычке надо в ней копаться, а не «докопаешься». Вот и протирает он её тряпочкой и она всегда чистенькая и блестящая. Трудно ему, непривычно.
Есть ещё такие австралопитеки, которые на полном серьёзе считают, что машину с механической коробкой передач обязан уметь управлять каждый водитель.
20-15-летняя япошка прекрасно перебирается в гараже чуть менее, чем полностью (за исключением, разве что, коробочки с «мозгами») даже человеком не имевшим опыта десятилетий сборки-разборки автотазиков. Не гоните гусей :)
НЛО прилетело и опубликовало эту надпись здесь
Это значит вы и такие же как вы 'австралопитеки' отчасти ездите на машине ради езды а не ради перемещения из точки А в точку Б. Полагаю, это пройдет с возрастом, как и аналогичное отношения к играм (искренне надеюсь что у меня к играм отношение не изменится как можно дольше).
Странно полагать, что человек умеющий ездить на механике не просто перемещается, а получает от перемещения еще и какое-то удовольствие. Посмотрите так называемые «машины для водителя», в их множестве не так уж и много экземпляров на механике. Значит не все так уж и взаимосвязано. Уметь ездить на ней или не уметь дело Ваше. Ваша точка зрения будет правильной только в том случае, когда автоматы и роботы будут на процентах 70 машин и механику можно будет окончательно записать в артефакты для почитателей ретро. А пока все обстоит несколько иначе, умение ездить на механике должно быть если не обязательным, то крайне рекомендуемым.
Мне механика нравится… Какое-то чувство контроля за машиной… На автомате оно меньше, хотя удобство больше ))
«А пока все обстоит несколько иначе, умение ездить на механике должно быть если не обязательным, то крайне рекомендуемым. „
Все обстоит не иначе, а зависит от страны проживания.
В США более 90% машины — автомат. Причем подавляющее большинство водителей вообще не имеют представление как работает механика, и им нафиг это сдалось. Причем для многих моделей, вариант с механикой отсутствует в принципе.
В Японии процент автомата еще больше.
Все обстоит не иначе, а зависит от страны проживания.
В США более 90% машины — автомат. Причем подавляющее большинство водителей вообще не имеют представление как работает механика, и им нафиг это сдалось. Причем для многих моделей, вариант с механикой отсутствует в принципе.
В Японии процент автомата еще больше.
Просто, некоторым людям нравится ездить и хорошо управлять машиной, другие это терпят как вынужденное зло ради удобного перемещения и не более. Так же как кто-то в консоли предпочитает работать, другой воспринимает только графику с парой простых кнопок.
Умение водить механику нужно не столько для самого умения водить. А просто потому что пока еще встречаются ситуации, когда в доступности есть только механика. Частая история в прокатах, например. Когда механики в использовании не останется, никакой нужны уметь ей управлять и не будет. Ну и не нужно это тем, кто использует машину только передвижения с дома на работу и даже не задумывается о том, чтобы взять другую машину и где-то на ней ездить.
Умение водить механику нужно не столько для самого умения водить. А просто потому что пока еще встречаются ситуации, когда в доступности есть только механика. Частая история в прокатах, например. Когда механики в использовании не останется, никакой нужны уметь ей управлять и не будет. Ну и не нужно это тем, кто использует машину только передвижения с дома на работу и даже не задумывается о том, чтобы взять другую машину и где-то на ней ездить.
НЛО прилетело и опубликовало эту надпись здесь
Вылезать раскачкой совершенно не проблема даже на моём древнем автомате. Возможно, не так эффективно, как на механике, но вполне осуществимо.
Вообще говоря седельные тягачи уже как много лет с АКПП. А нагрузки там много больше 10т.
Роботы позволяют раскачивать машину. Умные роботы (типа powershift для Мерседесовски грузовиков) даже стаят одно сцепление на переднюю, второе на заднюю передачу, что дает полноценную раскачку, недоступную на механике. А тянуть на буксире автомат без проблем позволяет, лишь бы усилие было не слишком большое.
Контроль на механике обычно заключается в том, что передача в ненужный момент не сменится. На автомате это тоже достижимо (если там есть толковый ручной режим), но мало кто этим пользуется.
В любом случае, механические коробки уже даже с мотоциклов будут уходить. Лет через 5 в большинстве автошкол цивилизованных стран вряд ли будут обучать вождению на механике в рамках общей программы.
Контроль на механике обычно заключается в том, что передача в ненужный момент не сменится. На автомате это тоже достижимо (если там есть толковый ручной режим), но мало кто этим пользуется.
В любом случае, механические коробки уже даже с мотоциклов будут уходить. Лет через 5 в большинстве автошкол цивилизованных стран вряд ли будут обучать вождению на механике в рамках общей программы.
НЛО прилетело и опубликовало эту надпись здесь
Вариатор на мощные мотоциклы не ставят по одной причине — он не позволяет делать резкие ускорения. Ремень проскальзывает, моментально перегревается и рвется. Это знакомо владельцам квадроциклов и УТВ (в последних, кстати, мощность уже ушла за 150 лошадей).
Однако, вы немного отстали от жизни;) У Хонды есть коробка DCT, ее уже пару лет ставят на NC700 и VFR1200X. Это робот с двумя сцеплениями, который показал себя надежным и сейчас вот ставят на новую литровую Африку. Железно работает она прекрасно (переключения моментальные, без рывков, запутать робот, переключая передачи туда-сюда у меня не вышло). Есть проблема с алгоритмом работы при активной езде на дороге, но его со временем решат. Не Хонда, так БМВ (которая, в отличие от Хонды, в машинах автомат настраивает очень неплохо).
Хонда тут новатор, остальные ставят на мотоциклы квикшифреты — дополнение к механике, позволяющее переключать передачи без сцепления и не меняя газ. По сути, упрощающее и ускоряющее переключение по технике квикшифтинга, когда кратковременно сбрасывают газ при переключении вверх. Но это временное решение, работает оно хуже, чем робот.
Учитывая, что Хонда начала ставить робот на многие новые модели, остальные производители не будут долго с этим тянуть. Тем более, что многие имеют возможность позаимствовать решения у автомобилей и наверняка давно ведут разработки. Хонда просто умудрилась первой выпустить толковую и компактную коробку.
Однако, вы немного отстали от жизни;) У Хонды есть коробка DCT, ее уже пару лет ставят на NC700 и VFR1200X. Это робот с двумя сцеплениями, который показал себя надежным и сейчас вот ставят на новую литровую Африку. Железно работает она прекрасно (переключения моментальные, без рывков, запутать робот, переключая передачи туда-сюда у меня не вышло). Есть проблема с алгоритмом работы при активной езде на дороге, но его со временем решат. Не Хонда, так БМВ (которая, в отличие от Хонды, в машинах автомат настраивает очень неплохо).
Хонда тут новатор, остальные ставят на мотоциклы квикшифреты — дополнение к механике, позволяющее переключать передачи без сцепления и не меняя газ. По сути, упрощающее и ускоряющее переключение по технике квикшифтинга, когда кратковременно сбрасывают газ при переключении вверх. Но это временное решение, работает оно хуже, чем робот.
Учитывая, что Хонда начала ставить робот на многие новые модели, остальные производители не будут долго с этим тянуть. Тем более, что многие имеют возможность позаимствовать решения у автомобилей и наверняка давно ведут разработки. Хонда просто умудрилась первой выпустить толковую и компактную коробку.
Суть в том, что 99% случаев, вам не нужно выползать откуда-то раскачкой (за бугром дороги нормальные), или тянуть кого-то на буксире (за бугром это задача эвакуаторов).
А большинство машин производится именно за бугром, и механика понемного уходит.
Лично я буду ездить на механике, пока это будет возможно, но я понимаю почему существует тенденция в сторону автомата, и вполне предполагаю, что в будущем автоматов будет гораздо больше, если не полностью.
А большинство машин производится именно за бугром, и механика понемного уходит.
Лично я буду ездить на механике, пока это будет возможно, но я понимаю почему существует тенденция в сторону автомата, и вполне предполагаю, что в будущем автоматов будет гораздо больше, если не полностью.
Вам знакомо понятие «чувствовать двигатель»?
Когда между вашей ногой, жмущей на «газ» и колесами присутствует только двигатель и зубчатая передача, передаточным числом которой вы управляете сами, чувство контроля (притом, совершенно обоснованное) гораздо выше, чем когда вас с колесами разделяет сложная, «интеллектуальная» система, которая, к тому же, имеет «наглость» адаптироваться к вашему стилю вождения (то есть менять свое поведение «на ходу»).
Когда между вашей ногой, жмущей на «газ» и колесами присутствует только двигатель и зубчатая передача, передаточным числом которой вы управляете сами, чувство контроля (притом, совершенно обоснованное) гораздо выше, чем когда вас с колесами разделяет сложная, «интеллектуальная» система, которая, к тому же, имеет «наглость» адаптироваться к вашему стилю вождения (то есть менять свое поведение «на ходу»).
Увы, но на современных машинах с механикой все равно стоит электронная педаль газа, которая может вносить свои коррективы и обычно таки вносит.
Добро пожаловать в XXI век, встречайте самобеглые! коляски с автопилотами™, ту же Теслу, например. Чувство контроля, говорите — а оно вам надо? Поспите лучше, пока коляска самобегло перемещает уставшую организьму из бара домой )))
вот тут соглашусь. купил механику, потому что а) умел б) надёжно — не доверяю автоматам.
прошло 5 лет — следующая машина будет с автоматом, потому как нафига делать самому то, что робот может делать в разы лучше?
прошло 5 лет — следующая машина будет с автоматом, потому как нафига делать самому то, что робот может делать в разы лучше?
Управлять машиной с механической коробкой передач должен уметь каждый водитель, чтобы вдруг не возникло ситуации, что вроде как машина есть, но ехать не ней не можешь, т.к. в правах галочка стоит на автомат. Как только мануальный коробки исчезнут, проблемы само собой не станет.
С уважением, ваш Австралопитек.
С уважением, ваш Австралопитек.
Машиной с МКПП обязан уметь управлять любой водитель.
Привет от австралопитека. Я не считаю, что каждый должен. Но себе лично купил (и снова куплю, если будет возможность) именно «механику». Потому что она интуитивнее — лучше чувствуется динамика.
И вообще, чем проще устройство — тем приятнее с ним иметь дело. Сложность — неизбежное зло, на которое приходится идти с целью безопасности и комфорта.
А вот брат мой — гонщик класса ралли, — покупая себе новую машину, снял с нее АБС. Потому что привык тормозить импульсами сам. И этот самый АБС ему бы мешал, а не помогал.
И вообще, чем проще устройство — тем приятнее с ним иметь дело. Сложность — неизбежное зло, на которое приходится идти с целью безопасности и комфорта.
А вот брат мой — гонщик класса ралли, — покупая себе новую машину, снял с нее АБС. Потому что привык тормозить импульсами сам. И этот самый АБС ему бы мешал, а не помогал.
Это называется проф. деформация;) На асфальте АБС не может мешать. Если сработала, значит водитель уже перетормозил. Отключать имеет смысл на грунте или в снегу, но отключать. Зачем снимать?
Видимо потому, что «асфальт» в России зимой нужно еще поискать.
А отключать надо потому, что если человек до спинного мозга привык к импульсному торможению ногой (чему вообще-то должен был учиться любой водитель до-АБС-ной эпохи, не только профессионал), то наложение на его «долбящую ногу» алгоритма импульсов АБС-а приведет уже не к сокращению, а к увеличению тормозного пути.
А отключать надо потому, что если человек до спинного мозга привык к импульсному торможению ногой (чему вообще-то должен был учиться любой водитель до-АБС-ной эпохи, не только профессионал), то наложение на его «долбящую ногу» алгоритма импульсов АБС-а приведет уже не к сокращению, а к увеличению тормозного пути.
то наложение на его «долбящую ногу» алгоритма импульсов АБС-а приведет уже не к сокращению, а к увеличению тормозного пути.
Или вы не знаете физику процесса работы АБС или я не знаю. Берем твердое покрытие (асфальт — сухой, мокрый или мерзлый, неважно. Где-то уж найдем его) и симулируем торможение по нему. Любая блокировка колеса тормозной путь увеличит (почему — в Вики написано в статье про АБС). Если блокировки нет, АБС не срабатывает — датчики у него достаточно точные для этого.
Как прерывистое торможение может быть ухудшено АБСом?
Повторюсь, у вашего брата проф. деформация. Раллийщики ездят по сыпучему и мягкому покрытию, там АБС может сделать хуже и тормозить лучше прерывисто. Как и в снегу. Но на асфальте и другом твердом покрытии ситуация иная.
АБС создает преимущество при торможении за счет задействования Штрибек-эффекта. Суть его в том, что при зацеплении с поверхностью сила трения чуть выше, чем при проскальзывании (очевидно, здесь принимают участие межмолекулярные связи, хотя физика эффекта очень сложна; трение — вообще очень непростая вещь).
Основная идея в том, чтобы всё время держать колесо в состоянии, когда скорость движения его поверхности относительно земли была близка к нулю. То есть колесо должно немного прокручиваться. При этом, как ни странно, оно будет терять энергию движения машины быстрее, чем при проскальзывании «юзом».
1. Как этого эффекта достигает человек?
Человек нажимает на тормоз, чувствует, что машина потеряла часть скорости, машина входит в проскальзывание, человек отпускает педаль, проскальзывание прекращается, человек снова нажимает педаль…
Та самая «долбёжка по тормозу». Ее тренируют при прохождении начального курса экстремального вождения.
2. Как этого эффекта достигает система АБС?
Примерно так же. Она блокирует колесо, фиксирует напряжение на оси, когда напряжение падает, ослабляет «хватку» колодок, затем снова усиливает. Та же самая «долбежка», только без педали (возможно, более плавная/высокочастотная, но сути это не меняет).
3. А теперь вместе.
АБС включится при нажатии на «тормоз» и выключится при отпускании. Водитель, инстинктивно «долбящий» педаль не даст АБС-у найти оптимальное напряжение оси. Автоматика просто не успеет понять, насколько сильно надо тормозить. В результате тормозить толком не будет никто.
Тормозной путь станет не короче, чем при проскальзовании, а длиннее.
Теперь по последнему пункту. Опять.
Вы, насколько следует из профиля, живете не в России. Напомню, что в нашей стране зимой любая, даже самая хорошая дорога содержит на себе либо слякоть (в лучшем случае), либо полсантиметра снега. Снег бывает раскатанный и скользкий, а бывает плохопримятый. В любом случае, российские водители рассматривают вождение на сухом асфальте как роскошь. Лично мне вообще никаких улучшений моего транспортного средства в условиях сухой летней дороги и хорошей видимости не нужно. Тормозной путь в 15-20 метров при скорости в 90 км/ч — просто роскошь.
У нас все водители с ралли!
Иллюстрация:
P.S. Летом в плохую погоду эта же дорога может быть покрыта примерно таким же слоем скользкой грязи.
Основная идея в том, чтобы всё время держать колесо в состоянии, когда скорость движения его поверхности относительно земли была близка к нулю. То есть колесо должно немного прокручиваться. При этом, как ни странно, оно будет терять энергию движения машины быстрее, чем при проскальзывании «юзом».
1. Как этого эффекта достигает человек?
Человек нажимает на тормоз, чувствует, что машина потеряла часть скорости, машина входит в проскальзывание, человек отпускает педаль, проскальзывание прекращается, человек снова нажимает педаль…
Та самая «долбёжка по тормозу». Ее тренируют при прохождении начального курса экстремального вождения.
2. Как этого эффекта достигает система АБС?
Примерно так же. Она блокирует колесо, фиксирует напряжение на оси, когда напряжение падает, ослабляет «хватку» колодок, затем снова усиливает. Та же самая «долбежка», только без педали (возможно, более плавная/высокочастотная, но сути это не меняет).
3. А теперь вместе.
АБС включится при нажатии на «тормоз» и выключится при отпускании. Водитель, инстинктивно «долбящий» педаль не даст АБС-у найти оптимальное напряжение оси. Автоматика просто не успеет понять, насколько сильно надо тормозить. В результате тормозить толком не будет никто.
Тормозной путь станет не короче, чем при проскальзовании, а длиннее.
Теперь по последнему пункту. Опять.
Вы, насколько следует из профиля, живете не в России. Напомню, что в нашей стране зимой любая, даже самая хорошая дорога содержит на себе либо слякоть (в лучшем случае), либо полсантиметра снега. Снег бывает раскатанный и скользкий, а бывает плохопримятый. В любом случае, российские водители рассматривают вождение на сухом асфальте как роскошь. Лично мне вообще никаких улучшений моего транспортного средства в условиях сухой летней дороги и хорошей видимости не нужно. Тормозной путь в 15-20 метров при скорости в 90 км/ч — просто роскошь.
У нас все водители с ралли!
Иллюстрация:
P.S. Летом в плохую погоду эта же дорога может быть покрыта примерно таким же слоем скользкой грязи.
Печаль, люди настолько трудно принимают новые технологии, что готовы найти любые оправдания, чтобы только ездить на архаичной повозке.
АБС основана на том обстоятельстве, что трение покоя гораздо больше, чем трение скольжения. Пока колеса катятся по асфальту без юза, на них действует именно сила трения покоя. Это как шкаф двигать, гораздо легче идет если сорвать.
Дальше, АБС срабатывает очень быстро и так же быстро выключается. Т.е. он минимизирует время, которое колесо находится в состоянии трения скольжения и при этом не дает сильно ослабить тормозное усилие, пока оно не приводит к срыву колеса. Это приводит к тому, что колесо проводит в трении скольжения минимально возможное время. Гораздо меньше, чем если тормозить прерывисто самому. И тормозной путь будет меньше, чем у любого ралийщика, как бы он не тормозил (в идеале, тормозной путь будет примерно равен и это лучшее, чего сможет добиться человек).
Когда человек тормозит прерывисто с АБС он конечно мешает работать АБС, но в моменты, когда колесо блокируется, АБС все равно экономит тормозной путь, пусть и меньше, чем если бы водитель ему не мешал.
Теперь о ралли. На мягком и сыпучей поверхности, сцепление с дорогой гораздо хуже и что трение покоя что качения достаточно слабое и не позволяют нормально затормозить. Но, колеса в юзе могут нагребать перед собой небольшую горку из песка, снега или того, по чему катится колесо. Вот за счет этой горки и обеспечивается немалая часть замедления. Потому, в ралли и другом оффроаде нужно допускать небольшой юз колеса и торможение крупными рывками будет эффективнее, чем если использовать АБС. Только на покрытии, которое позволяет набрать эту горку перед колесом. Не на асфальте!
А то, что в России нет дорог конечно повторять любят. И мне возможно было бы приятно так думать. Но к несчастью для себя я знаю, что дороги там все же есть, кроме некоторых регионов. Но в тех регионах на легковой технике и не ездят, как правило. А для тех сравнительно редких ситуаций, когда вы таки решите понаваливать по рыхлому снегу, часто есть кнопка отключения этого самого АБС. Но ей обычно пользоваться не стоит т.к. она отключает еще и систему стабилизации (если такая есть в машине), а без нее наваливание по рыхлому снегу на гражданской машине может закончиться плохо даже для раллийщика (если мы говорим о скоростях 80 км/ч и выше).
АБС основана на том обстоятельстве, что трение покоя гораздо больше, чем трение скольжения. Пока колеса катятся по асфальту без юза, на них действует именно сила трения покоя. Это как шкаф двигать, гораздо легче идет если сорвать.
Дальше, АБС срабатывает очень быстро и так же быстро выключается. Т.е. он минимизирует время, которое колесо находится в состоянии трения скольжения и при этом не дает сильно ослабить тормозное усилие, пока оно не приводит к срыву колеса. Это приводит к тому, что колесо проводит в трении скольжения минимально возможное время. Гораздо меньше, чем если тормозить прерывисто самому. И тормозной путь будет меньше, чем у любого ралийщика, как бы он не тормозил (в идеале, тормозной путь будет примерно равен и это лучшее, чего сможет добиться человек).
Когда человек тормозит прерывисто с АБС он конечно мешает работать АБС, но в моменты, когда колесо блокируется, АБС все равно экономит тормозной путь, пусть и меньше, чем если бы водитель ему не мешал.
Теперь о ралли. На мягком и сыпучей поверхности, сцепление с дорогой гораздо хуже и что трение покоя что качения достаточно слабое и не позволяют нормально затормозить. Но, колеса в юзе могут нагребать перед собой небольшую горку из песка, снега или того, по чему катится колесо. Вот за счет этой горки и обеспечивается немалая часть замедления. Потому, в ралли и другом оффроаде нужно допускать небольшой юз колеса и торможение крупными рывками будет эффективнее, чем если использовать АБС. Только на покрытии, которое позволяет набрать эту горку перед колесом. Не на асфальте!
А то, что в России нет дорог конечно повторять любят. И мне возможно было бы приятно так думать. Но к несчастью для себя я знаю, что дороги там все же есть, кроме некоторых регионов. Но в тех регионах на легковой технике и не ездят, как правило. А для тех сравнительно редких ситуаций, когда вы таки решите понаваливать по рыхлому снегу, часто есть кнопка отключения этого самого АБС. Но ей обычно пользоваться не стоит т.к. она отключает еще и систему стабилизации (если такая есть в машине), а без нее наваливание по рыхлому снегу на гражданской машине может закончиться плохо даже для раллийщика (если мы говорим о скоростях 80 км/ч и выше).
Господа, мне приятно, что мой пример про автомобили породил целую ветку комментариев чисто про автомобили :) Но мы тут изначально про IT собрались…
> Когда человек тормозит прерывисто с АБС он конечно мешает работать АБС, но в моменты, когда колесо блокируется, АБС все равно экономит тормозной путь, пусть и меньше, чем если бы водитель ему не мешал.
Пойду, сообщу брату-гонщику, что его личные эксперименты и опыт товарищей — ерунда, потому что некий эксперт из интернета так решил. Интересно, что он ответит.
>А то, что в России нет дорог конечно повторять любят.
Я не говорил, что в России нет дорог. (Кстати, речь идет о городе Москве, где дорожное покрытие вполне годное почти везде.) Я имел в виду, что зимой в России дорожные службы не справляются с их расчисткой. Дороги завалены снегом, сцепления почти нет.
В довершение процитирую мнение одного очень старого водителя, который когда-то учил меня так: «Смотри, выпал снег и лег. Пришла зима. Если не хочешь беды, про тормоза до весны ты должен забыть». Очень релевантное мнение, кстати.
Пойду, сообщу брату-гонщику, что его личные эксперименты и опыт товарищей — ерунда, потому что некий эксперт из интернета так решил. Интересно, что он ответит.
>А то, что в России нет дорог конечно повторять любят.
Я не говорил, что в России нет дорог. (Кстати, речь идет о городе Москве, где дорожное покрытие вполне годное почти везде.) Я имел в виду, что зимой в России дорожные службы не справляются с их расчисткой. Дороги завалены снегом, сцепления почти нет.
В довершение процитирую мнение одного очень старого водителя, который когда-то учил меня так: «Смотри, выпал снег и лег. Пришла зима. Если не хочешь беды, про тормоза до весны ты должен забыть». Очень релевантное мнение, кстати.
Вы, главное, не забывайте, что вы и ваш брат (если он существует) это тоже «некие эксперты из интернета».
И еще, успехи в ралли не делают человека автоматически экспертом на асфальте.
И еще, успехи в ралли не делают человека автоматически экспертом на асфальте.
За что ж вы так моего брата-то… Вы главную мысль мою упорно игнорируете. Не понимаю, почему.
В средней полосе России абсолютно не имеет значения, насколько хорошо ваша машина тормозит летом в сухую погоду. Потому что на то, как вы управляете машиной, влияют следующие навыки:
1. В городах и на крупных трассах — аквапланирование летом и езда по мокрой снежной каше зимой.
2. За городом — умение на глаз отличить глубокую грязь от мелкой летом, езда по глубокому снегу зимой.
Я про езду по бездорожью выше даже не упоминал. Говорил исключительно про случай, когда под снегом/водой/грязью есть хороший асфальт без выбоин и колеи.
Да и машина за городом нужна иная. С высоким подъемом и полноприводная.
В средней полосе России абсолютно не имеет значения, насколько хорошо ваша машина тормозит летом в сухую погоду. Потому что на то, как вы управляете машиной, влияют следующие навыки:
1. В городах и на крупных трассах — аквапланирование летом и езда по мокрой снежной каше зимой.
2. За городом — умение на глаз отличить глубокую грязь от мелкой летом, езда по глубокому снегу зимой.
Я про езду по бездорожью выше даже не упоминал. Говорил исключительно про случай, когда под снегом/водой/грязью есть хороший асфальт без выбоин и колеи.
Да и машина за городом нужна иная. С высоким подъемом и полноприводная.
Любая блокировка колеса тормозной путь увеличит
Вы пишите ерунду. Вот вам картинка из авторевю, там тесты проводили, а не википедию читали, смотрите туда, где про лед. Сама статья убрана из свободного доступа, к сожалению.
АБС не уменьшает тормозной путь. АБС делает торможение управляемым. Как и прерывистое торможение. Хватит уже мифологию разводить.
Ну, наконец то истина видна.
Это правда, знаю по личному опыту: доводилось «лавировать» на трассе (изначальная скорость порядка 100км/ч) между участниками «кучи малой» с педалью тормоза вжатой в пол. Не знаю какой там получился тормозной путь, но многоканальный АБС позволил мне вполне нормально управлять машиной. Это оказалось важнее, чем сокращение пути, всё-равно бы присоединился к тусовке, слишком малая была дистанция на момент начала торможения…
Позвольте, утверждение, конечно, неверное, но ваше тоже ошибочно.
При прирывистой блокировке энергия, всё же, теряется…
При прирывистой блокировке энергия, всё же, теряется…
Про врачей ошибочно. До XIX века знания об организме человека были столь приблизительны, что точное знание о действии лекарства на человека было попросту невозможно.
Из «Фауста» Гёте, монолог Фауста:
Из «Фауста» Гёте, монолог Фауста:
Отец мой, темный труженик, в тиши
Над тайнами природы тщетно бился;
В ее круги святые он стремился
Проникнуть всеми силами души —
По-своему, но честно. Меж адептов
Сидел он в чёрной кухне взаперти
И силился бальзам целительный найти,
Мешая разных множество рецептов.
Являлся красный лев — и был он женихом,
И в теплой жидкости они его венчали
С прекрасной лилией, и грели их огнем,
И из сосуда их в сосуд перемещали.
И вслед — блиставшую лучами всех цветов
Царицу юную в стекле мы получали:
Целительный напиток был готов.
И стали мы лечить. Удвоились мученья:
Больные гибли все без исключенья,
А выздоравливал ли кто,
Спросить не думали про то.
Вот наши подвиги леченья!
Средь этих гор губили мы
Страшней губительной чумы!
Я сам дал тысячам отраву:
Их нет — а я живу… И вот —
В моём лице воздал народ
Своим убийцам честь и славу!
я думаю, что данная проблема тесно коррелирует с проблемой качества получаемого образования. Холивар про образование отставим…
вопросы подняты, конечно, интересные, жизненные, но боюсь ответы на них скорее философские нежели практические.
Про софт. Довелось поддерживать продукт 15-ти летний. Видел в нем как раз то, что новые функции открывают новые баги, и т.п. Дык вот, коли такое происходит, я считаю жизненный цикл ПО подошел к концу. Не потому он не нужен, просто нужно пересмотреть архитектуру, и да, переписать версию 2.0 с учетом хотелок и ошибок. Что-то выбросить, что-то добавить — это нормально я считаю.
И вообще — нет ничего идеального…
вопросы подняты, конечно, интересные, жизненные, но боюсь ответы на них скорее философские нежели практические.
Про софт. Довелось поддерживать продукт 15-ти летний. Видел в нем как раз то, что новые функции открывают новые баги, и т.п. Дык вот, коли такое происходит, я считаю жизненный цикл ПО подошел к концу. Не потому он не нужен, просто нужно пересмотреть архитектуру, и да, переписать версию 2.0 с учетом хотелок и ошибок. Что-то выбросить, что-то добавить — это нормально я считаю.
И вообще — нет ничего идеального…
>Возможно, не будь я программистом, мне не было бы так страшно
Тот, кто работает в сосисочном цехе, никогда не ест сосиски.
Врачи вот тоже могут много «забавного» рассказать, но только в своём кругу.
Не надо бояться технологий и программистов. Весь этот процесс абсолютно нормален.
Так что присаживайтесь по удобнее, едем дальше.
Тот, кто работает в сосисочном цехе, никогда не ест сосиски.
Врачи вот тоже могут много «забавного» рассказать, но только в своём кругу.
Не надо бояться технологий и программистов. Весь этот процесс абсолютно нормален.
Так что присаживайтесь по удобнее, едем дальше.
У врачей все хорошо) Все умрем)
Работал на мясокомбинате, сосиски ем. Просто знаю в отличие от посторонних какие продукты можно есть, а какие стоит избегать.
Мне стало страшнее жить, когда я начал узнавать как это все работает на уровне аппаратуры. До какого-то момента в чем, а в этом уровне был уверен и, так сказать, не лез туда. Оказалось там не все так строго, как я представлял. Потом уже я узнал, что процессор может в какой-то момент выкинуть исключение Macine Check и сказать «гудбай». Кэш память, прогнозирование переходов, спекулятивное исполнение — все это, казалось бы, обходные пути, однако это все работает на большинстве процессоров.
Еще забавен тот факт, что сложение двух чисел на C++ в некоторых случаях undifined behaviour (чисто теоретически может отформатировать жесткий диск):D
Еще забавен тот факт, что сложение двух чисел на C++ в некоторых случаях undifined behaviour (чисто теоретически может отформатировать жесткий диск):D
Прогресс идет по пути разделения труда и специализации. Везде, в том числе, в сфере разработки ПО.
Точка.
Точка.
Никто и не против вашей «точки». Только вот разделение труда не означает, что правая рука не знает, что делает левая нога.
Именно что означает. Она специализируется в своей, праворукой деятельности, и достигает в ней совершенства. А как работает левая нога — не ее дело. Сломается — будет ее чинить мастер по левым ногам. Вот и вся недолга. Чем сложнее система, тем меньше возможности у отдельного человека ее всю охватить.
Пример: В США, в некоторых штатах водителям большегрузов запрещено самим менять пробитые колеса, независимо от того, может человек, или нет. Этим занимается специальная служба, шофер — ведет машину.
Пример: В США, в некоторых штатах водителям большегрузов запрещено самим менять пробитые колеса, независимо от того, может человек, или нет. Этим занимается специальная служба, шофер — ведет машину.
Но это не означает, что они НЕ ПОНИМАЮТ, как сменить колесо.
Еще раз, вдумайтесь. Если врачи, которые лечат ваши уши, не будут знать физиологию всего тела (а зачем?) или, скажем учитель математики вашего ребенка не будет уметь грамотно писать (или учитель литературы не будет уметь считать) — вы полагаете, это и есть то «светлое будущее» с разделением труда?
В таком случае нам с вами определенно не по пути. Потому что мир, в котором люди не понимают (хотя бы приблизительно) проблемы и задачи друг друга, похож на Вавилонскую Башню.
Вам же автор статьи привел пример проекта, который накрылся медью из-за того, что инженеры-«жестянщики» в упор не понимали, чем занимаются программисты. Или этот пример не иллюстрирует проблему?
Еще раз, вдумайтесь. Если врачи, которые лечат ваши уши, не будут знать физиологию всего тела (а зачем?) или, скажем учитель математики вашего ребенка не будет уметь грамотно писать (или учитель литературы не будет уметь считать) — вы полагаете, это и есть то «светлое будущее» с разделением труда?
В таком случае нам с вами определенно не по пути. Потому что мир, в котором люди не понимают (хотя бы приблизительно) проблемы и задачи друг друга, похож на Вавилонскую Башню.
Вам же автор статьи привел пример проекта, который накрылся медью из-за того, что инженеры-«жестянщики» в упор не понимали, чем занимаются программисты. Или этот пример не иллюстрирует проблему?
Но это не означает, что они НЕ ПОНИМАЮТ, как сменить колесо.
Вовсе необязательно. Могут и не понимать. Разделение труда приводит к специализации. Это повышает эффективность обучения и производительность труда.
Еще раз, вдумайтесь. Если врачи, которые лечат ваши уши, не будут знать физиологию всего тела (а зачем?)
При этом они не знают другие части тела так же хорошо, как и «свои». «Знать физиологию» — это игра словами, основанная на неоднозначности слова «знать» в этом контексте.
скажем учитель математики вашего ребенка не будет уметь грамотно писать (или учитель литературы не будет уметь считать)
Это некорректный примерю Навыки письма и счета — базовые для всех людей. Мы же говорим о профессиональной деятельности, и тут — о ужас — да, учитель математики не умеет учить детей литературе.
В таком случае нам с вами определенно не по пути. Потому что мир, в котором люди не понимают (хотя бы приблизительно) проблемы и задачи друг друга, похож на Вавилонскую Башню.
Путь в обратную сторону — дорога в средневековье. Вы просто пытаетесь определить набор навыков, иметь которые по-вашему «нормально» (вида «нормальый мужик умеет починить кран и прибить полку», только в применении к другим сферам), я же говорю о профессиональной деятельности, производстве продукта/услуг.
Вам же автор статьи привел пример проекта, который накрылся медью из-за того, что инженеры-«жестянщики» в упор не понимали, чем занимаются программисты. Или этот пример не иллюстрирует проблему?
Этот пример демонстрирует проблему отсутствия человека, координирующего действия тех двоих. Потому что инженеру (не в сфере ПО) также знаком итеративный процесс решения проблемы, поиск альтернатив; это означает, что между ними нет неразрешимых противоречий, это обычная communication проблема.
> Навыки письма и счета — базовые для всех людей.
А навыки оперирования с алгебраическими выражениями общие для всех, кто занимается точными науками.
А знание анатомии обязательно для всех, кто имеет дело с телом человека. Даже если он всю жизнь смотрит исключительно в рот.
А элементарные слесарные навыки обязательны для всякого водителя (во всяком случае если он хочет быть уверенным, что выберется из по-настоящему нештатной ситуации).
>Вы просто пытаетесь определить набор навыков, иметь которые по-вашему «нормально» (вида «нормальый мужик умеет починить кран и прибить полку», только в применении к другим сферам)
Я пытаюсь определить набор навыков, который определяет околопрофессиональный кругозор человека, занимающегося деятельностью, близкой к моей.
А вы бросаетесь в крайности.
И, кстати, поделитесь мыслью, каким таким волшебным способом этот третий человек, координирующий двоих, справится со своей задачей, не имея хотя бы базовой экспертизы в областях, которыми занимаются они оба. Я за время своей работы сменил около десятка руководителей, но такого чуда чудесного не встречал. Все они более-менее разбирались в том, чем управляли. И слава богу.
А навыки оперирования с алгебраическими выражениями общие для всех, кто занимается точными науками.
А знание анатомии обязательно для всех, кто имеет дело с телом человека. Даже если он всю жизнь смотрит исключительно в рот.
А элементарные слесарные навыки обязательны для всякого водителя (во всяком случае если он хочет быть уверенным, что выберется из по-настоящему нештатной ситуации).
>Вы просто пытаетесь определить набор навыков, иметь которые по-вашему «нормально» (вида «нормальый мужик умеет починить кран и прибить полку», только в применении к другим сферам)
Я пытаюсь определить набор навыков, который определяет околопрофессиональный кругозор человека, занимающегося деятельностью, близкой к моей.
А вы бросаетесь в крайности.
И, кстати, поделитесь мыслью, каким таким волшебным способом этот третий человек, координирующий двоих, справится со своей задачей, не имея хотя бы базовой экспертизы в областях, которыми занимаются они оба. Я за время своей работы сменил около десятка руководителей, но такого чуда чудесного не встречал. Все они более-менее разбирались в том, чем управляли. И слава богу.
А знание анатомии обязательно для всех, кто имеет дело с телом человека. Даже если он всю жизнь смотрит исключительно в рот.
Проблема в том, что вы определяете «элементарные навыки» волюнтаристский. Я уже обозначил это, указав на использование вами слова «знание», но вы этого не поняли.
Я пытаюсь определить набор навыков, который определяет околопрофессиональный кругозор человека, занимающегося деятельностью, близкой к моей.
Так я не против, непонятно, на что вы возражаете здесь.
А вы бросаетесь в крайности.
Отнюдь, это делаете вы. Я как раз не против расширения области, захватывающей что-либо, что позволит людям разных специализаций состыковаться.
А вот ваши примеры-контраргументы — как раз полярные, крайность.
>А знание анатомии
Что такое «знание анатомии», что такое «элементарные слесарные навыки»? Вы бросаетесь абсолютно неопределёнными фразами — это крайне непрофессионально, если на то пошло.
Знание анатомии — что это? Профессиональный гинеколог должен знать какие участки головного мозга за что отвечают? Нейрофизиолог должен знать то, как работает человеческий иммунитет так, чтобы иметь например возможность рассказать без недельной подготовки по этой теме лекцию?
Элементарные слесарные навыки — что это? Нестандартная ситуация — какая это? В машине произошла поломка инжектора/коробки передач/бортового компьютера/электродвигатель отказал — это ещё настолько нестандартные ситуации, чтобы с ними необходимо было уметь справиться профессиональному водителю или ещё нет? И не в копейке, выпущенной лет 20 назад, а в современной среднестатистической иномарке, в которой иногда и подобраться к нужным деталям без спецоборудования не так то просто.
>третий человек, координирующий двоих >базовой экспертизы
Опять неопределённость, уточните должность и что такое «базовая экспертиза»?
Хотя это можно вообще-то долго продолжать. Я думаю, уже давно понятно, что без умения пользоваться предоставленными другими людьми абстракциями никто в современном мире не сможет успешно продолжать свою деятельность. А то, абстракциями насколько высокого уровня должен уметь оперировать человек на определённой должности, точно решит уже скорее всего только рынок.
Что такое «знание анатомии», что такое «элементарные слесарные навыки»? Вы бросаетесь абсолютно неопределёнными фразами — это крайне непрофессионально, если на то пошло.
Знание анатомии — что это? Профессиональный гинеколог должен знать какие участки головного мозга за что отвечают? Нейрофизиолог должен знать то, как работает человеческий иммунитет так, чтобы иметь например возможность рассказать без недельной подготовки по этой теме лекцию?
Элементарные слесарные навыки — что это? Нестандартная ситуация — какая это? В машине произошла поломка инжектора/коробки передач/бортового компьютера/электродвигатель отказал — это ещё настолько нестандартные ситуации, чтобы с ними необходимо было уметь справиться профессиональному водителю или ещё нет? И не в копейке, выпущенной лет 20 назад, а в современной среднестатистической иномарке, в которой иногда и подобраться к нужным деталям без спецоборудования не так то просто.
>третий человек, координирующий двоих >базовой экспертизы
Опять неопределённость, уточните должность и что такое «базовая экспертиза»?
Хотя это можно вообще-то долго продолжать. Я думаю, уже давно понятно, что без умения пользоваться предоставленными другими людьми абстракциями никто в современном мире не сможет успешно продолжать свою деятельность. А то, абстракциями насколько высокого уровня должен уметь оперировать человек на определённой должности, точно решит уже скорее всего только рынок.
Я солидарен с bigfatbrowncat.
Ну и по теме статьи: эту проблему можно проецировать практически на любую область, будь то производство или проектирование. Но конкретно в сфере ПО думаю что технологии производства микропроцессоров в будущем «упрутся» в невозможность производства более производительных систем. И вот тогда наступит время кодеров которые будут по-настоящему оптимизировать код. До этого времени объем кода будет только увеличиваться.
Вовсе необязательно. Могут и не понимать. Разделение труда приводит к специализации. Это повышает эффективность обучения и производительность труда.Если впадать в крайности то у нас на каждый чих, по такой логике, будет специалист.
Путь в обратную сторону — дорога в средневековье. Вы просто пытаетесь определить набор навыков, иметь которые по-вашему «нормально» (вида «нормальый мужик умеет починить кран и прибить полку», только в применении к другим сферам), я же говорю о профессиональной деятельности, производстве продукта/услуг.а что собственно плохого в «нормальном мужике»? почему нельзя сочетать это качество и быть хорошим специалистом в своей области? В Японии, слышал, практикуется система «горизонтального» роста: каждые пять лет инженер меняет специализацию и начинает все с нуля. А самое главное Вы не должны забывать чем вызвано это производство продуктов/услуг. По-моему из-нас делают потребителей этих самых продуктов/услуг. Такое ощущение что миром начинает править маркетинг. Про путь в обратную сторону- не это имел ввиду bigfatbrowncat. Я думаю, что смысл в том что нужно оглядываться назад, двигаясь вперед. Наша нация (я не делаю здесь ударения), если помните, всегда отличалась смекалкой. Вспомните великие битвы и войны за нашу родину. Сколько раз мы выживали благодаря нашему менталитету (собственно, порою оказываемся в *опе из-за него же). Я не понимаю как можно, например, дать замерзнуть своему ребенку на трассе, зимой просто из-за того, что ты не умеешь заменить колесо (если уж речь зашла о замене колес).
Этот пример демонстрирует проблему отсутствия человека, координирующего действия тех двоих. Потому что инженеру (не в сфере ПО) также знаком итеративный процесс решения проблемы, поиск альтернатив; это означает, что между ними нет неразрешимых противоречий, это обычная communication проблема.Нужен не просто координатор, а человек развитый во многих областях, который понимает проблемы того или иного направления/специализации. Талантливый и действительно сведущий ГИП, project manager, руководитель проекта (называйте как хотите) большая редкость нынче.
Ну и по теме статьи: эту проблему можно проецировать практически на любую область, будь то производство или проектирование. Но конкретно в сфере ПО думаю что технологии производства микропроцессоров в будущем «упрутся» в невозможность производства более производительных систем. И вот тогда наступит время кодеров которые будут по-настоящему оптимизировать код. До этого времени объем кода будет только увеличиваться.
Специализация хороша, когда развивается эволюционным путем.
А «водителям большегрузов запрещено самим менять пробитые колеса» — это уже навязывание кем-то.
Водитель может сам решить насколько выгодно ему ждать спец. службу или же поменять колесо самостоятельно. Или же его работодатель решит, если водитель недостачно компетентен.
А «водителям большегрузов запрещено самим менять пробитые колеса» — это уже навязывание кем-то.
Водитель может сам решить насколько выгодно ему ждать спец. службу или же поменять колесо самостоятельно. Или же его работодатель решит, если водитель недостачно компетентен.
Боюсь, не все так просто. В США очень развита страховая и законодательная система. Отчасти это хорошо, но есть и свои минусы. Если водитель поменяет колесо сам, а после этого автомобиль попадет в аварию — водителя засудят на большую сумму денег. У него не было соответствующей документально подтвержденной квалификации для этой работы, пусть даже он гуру по замене колес. Такой вот перекос.
Спрошу почти в тему. Мне кажется что я постоянно забываю все, чем хоть некоторое время не пользуюсь.
Банальный и самый яркий для меня пример — умножение матриц.
Пока проходили первый раз в техникуме, сдал почти на отлично. Через год писал практическую — пришлось лезть в конспекты, потому что забыл. Еще через год писал программу строящую графики поверхностей — читал заново. Через год писал демки на OpenGL — заново. Проходили и в институте — ничего не помнил. Позже попал в геймдев контору, писали свой 2д движок — читал википедию. Через пол года писал бенчмарк для luajit с перемножением матриц — заново. С год назад писал биндинги к glfw — вспоминал заново. И если спросить меня о об умножении матриц сейчас, я все равно не смогу сказать сходу, полезу в вики.
И похожие провалы почти во всем — стоит не трогать css с пол года, и я едва помню что-либо кроме основных селекторов и свойств. Пытаюсь бороться с этим, записывая краткие конспекты в простенький outliner, всплывающий на ctrl+shift+z (Flashnote).
Это у меня реально проблема, или я просто себя накручиваю?
Банальный и самый яркий для меня пример — умножение матриц.
Пока проходили первый раз в техникуме, сдал почти на отлично. Через год писал практическую — пришлось лезть в конспекты, потому что забыл. Еще через год писал программу строящую графики поверхностей — читал заново. Через год писал демки на OpenGL — заново. Проходили и в институте — ничего не помнил. Позже попал в геймдев контору, писали свой 2д движок — читал википедию. Через пол года писал бенчмарк для luajit с перемножением матриц — заново. С год назад писал биндинги к glfw — вспоминал заново. И если спросить меня о об умножении матриц сейчас, я все равно не смогу сказать сходу, полезу в вики.
И похожие провалы почти во всем — стоит не трогать css с пол года, и я едва помню что-либо кроме основных селекторов и свойств. Пытаюсь бороться с этим, записывая краткие конспекты в простенький outliner, всплывающий на ctrl+shift+z (Flashnote).
Это у меня реально проблема, или я просто себя накручиваю?
Никакой у вас проблемы нет.
Проблема у тех, кто считает, что для умножения матриц требуется немного пыли пикси и щепотка тертого философского камня. Или у тех, у кого слово «матрица» ассоциируется только с творчеством братьев Вачовски.
Общая эрудиция, достаточная для нахождения необходимого решения поставленной задачи — это именно то, что достаточно специалисту. Остальное вам даст справочная литература.
А эпоха «Сайрусов Смитов» давно закончилась, да. Подготовка современного инженера не подразумевает способности восстановить технологический уровень современного обества на необитаемом острове.
Проблема у тех, кто считает, что для умножения матриц требуется немного пыли пикси и щепотка тертого философского камня. Или у тех, у кого слово «матрица» ассоциируется только с творчеством братьев Вачовски.
Общая эрудиция, достаточная для нахождения необходимого решения поставленной задачи — это именно то, что достаточно специалисту. Остальное вам даст справочная литература.
А эпоха «Сайрусов Смитов» давно закончилась, да. Подготовка современного инженера не подразумевает способности восстановить технологический уровень современного обества на необитаемом острове.
Общая эрудиция, достаточная для нахождения необходимого решения поставленной задачи — это именно то, что достаточно специалисту. Остальное вам даст справочная литература.
Серьезно? Вам
определеннонепо пути
с человеком, который не знает, как перемножаются матрицы?
irony, отсылка к разговору выше, если что.
Ну и что? Вы меня там, выше, не поняли — может хоть здесь поймете.
Я помню формулу перемножения матриц. Но при необходимости всё равно уточню в справочнике — моя память со мной уже не раз играла дурную шутку. Но я точно помню, из чего эта формула состоит — там были линейные комбинации членов строк одной и столбцов другой… как-то так ведь, правда? То есть, я точно знаю, что не нужно, скажем, возводить элименты в квадрат. Или брать экспоненту. И этого вполне достаточно.
Я могу выдавать вполне квалифицированное мнение о задаче, связанной с перемножением матриц, даже если не помню деталей.
К нашему разговору выше — я не требую от преподавателя математики знания названий правил русского языка из учебника. Всего лишь писать грамотно. И врач, который лечит меня антибиотиком, не обязательно должен в деталях знать, как этот антибиотик изготовлен. Но он должен понимать, каков принцип действия, а не просто, как многие современные врачи, увы, делают, назначать по принципу «это — от головы, а это — от живота».
Вы мне говорите о разделении труда, я не возражаю (было бы глупо), но пытаюсь вам доказать, что разделение труда — не самоцель, а суровая необходимость. Если бы возможности мозга были бы безграничны, все были бы Сайрусами Смитами. Вернее, все, кто стремится достичь вершин в своей профессии, изучали бы ее, начиная от атомов.
Я всегда старался максимально расширять свой кругозор. Со школы. Программирование — супер. Физика — интересно. Графический дизайн — почему бы нет. Звук, музыка, видео… И так далее. Я осознавал, что пяти профессий быть не может. Но вот, в чем штука — уже неоднократно оказывалось так, что на работе кто-то куда более квалифицированный, чем я, сталкивается с проблемой, которую не может разрешить в силу своей узкой специализации. А я подсказываю человеку идею, как можно обойти препятствие. Не потому, что я чем-то «круче», а просто потому, что немножко шире изучал вопрос.
Скажем, мои познания в дизайне неоднократно помогали мне убеждать в своей правоте UX команду в тот момент, когда напарники, понимая, что господа-дизайнеры придумали ересь (потому что, в свою очередь, не понимали предметную область), не имели весомых аргументов. Просто не знали, как сформулировать проблему.
Вот такое вот разделение.
Я помню формулу перемножения матриц. Но при необходимости всё равно уточню в справочнике — моя память со мной уже не раз играла дурную шутку. Но я точно помню, из чего эта формула состоит — там были линейные комбинации членов строк одной и столбцов другой… как-то так ведь, правда? То есть, я точно знаю, что не нужно, скажем, возводить элименты в квадрат. Или брать экспоненту. И этого вполне достаточно.
Я могу выдавать вполне квалифицированное мнение о задаче, связанной с перемножением матриц, даже если не помню деталей.
К нашему разговору выше — я не требую от преподавателя математики знания названий правил русского языка из учебника. Всего лишь писать грамотно. И врач, который лечит меня антибиотиком, не обязательно должен в деталях знать, как этот антибиотик изготовлен. Но он должен понимать, каков принцип действия, а не просто, как многие современные врачи, увы, делают, назначать по принципу «это — от головы, а это — от живота».
Вы мне говорите о разделении труда, я не возражаю (было бы глупо), но пытаюсь вам доказать, что разделение труда — не самоцель, а суровая необходимость. Если бы возможности мозга были бы безграничны, все были бы Сайрусами Смитами. Вернее, все, кто стремится достичь вершин в своей профессии, изучали бы ее, начиная от атомов.
Я всегда старался максимально расширять свой кругозор. Со школы. Программирование — супер. Физика — интересно. Графический дизайн — почему бы нет. Звук, музыка, видео… И так далее. Я осознавал, что пяти профессий быть не может. Но вот, в чем штука — уже неоднократно оказывалось так, что на работе кто-то куда более квалифицированный, чем я, сталкивается с проблемой, которую не может разрешить в силу своей узкой специализации. А я подсказываю человеку идею, как можно обойти препятствие. Не потому, что я чем-то «круче», а просто потому, что немножко шире изучал вопрос.
Скажем, мои познания в дизайне неоднократно помогали мне убеждать в своей правоте UX команду в тот момент, когда напарники, понимая, что господа-дизайнеры придумали ересь (потому что, в свою очередь, не понимали предметную область), не имели весомых аргументов. Просто не знали, как сформулировать проблему.
Вот такое вот разделение.
Вы меня там, выше, не поняли — может хоть здесь поймете
Почему же? Я отлично понял вашу позицию; вы не поняли моего возражения.
То есть, я точно знаю, что не нужно, скажем, возводить элименты в квадрат. Или брать экспоненту. И этого вполне достаточно.
Я же написал — irony. Ваш набор необходимого субъективен — в одном случае вы говорите «это можно посмотреть в справочнике», в другом «я расширяю кругозор, потому что это нужно».
К нашему разговору выше — я не требую от преподавателя математики знания названий правил русского языка из учебника. Всего лишь писать грамотно.
Вы непоследовательны. Речь шла о разделении труда и о том, что умение писать — это не специфичный для профессии учителя навык, это навык, специфичный для всех современных людей. Он вне профессии. А вот навык преподавания математики или русского языка — специфичен, и здесь есть разделение труда, специализация. Это не я перехожу в крайности, это вы представляете мой аргумент таковым, вероятно, по ошибке.
не обязательно должен в деталях знать, как этот антибиотик изготовлен. Но он должен понимать
Принцип изготовления антибиотика не является специфичным для его профессии, применение — является. Поэтому он должен иметь это знание, а не просто «потому что» или «для кругозора».
но пытаюсь вам доказать, что разделение труда — не самоцель, а суровая необходимость.
Это очевидно, вы тратите свое и мое время. Это необходимость, вызванная ограниченными возможносятми человека.
Если бы возможности мозга были бы безграничны,
Если бы… это невозможно. Знаете байку про экзамен в физтех с шуткой о кошке?
Я всегда старался максимально расширять свой кругозор
И это замечательно. Что не отменяет того, что вы специализируетесь в какой-то области. И чем сложнее будут вещи, с которыми мы работаем, тем более глубокая специализация потребуется.
Разумеется, мой выбор субъективен. В том и фишка. Специалист сам выбирает спектр знаний, который ему необходим для решения задачи. Его невозможно и вредно определять извне. Вот эта вся чушь с «должностной инструкцией» смехотворна, как только речь заходит о мало-мальски творческой профессии.
Возможно, я зря ломлюсь в открытую дверь в случае спора с вами, но обычно следом за утверждением об «обязательном разделении труда» идет утверждение о том, что специалист «должен заниматься только своим делом», то есть умывать руки всякий раз, когда задача выходит на миллиметр за пределы его формальной компетенции.
А это называется «итальянская забастовка».
Возможно, я зря ломлюсь в открытую дверь в случае спора с вами, но обычно следом за утверждением об «обязательном разделении труда» идет утверждение о том, что специалист «должен заниматься только своим делом», то есть умывать руки всякий раз, когда задача выходит на миллиметр за пределы его формальной компетенции.
А это называется «итальянская забастовка».
Да нет проблемы, я вот ещё со школы для себя понял, что всё в голове держать не возможно и не нужно, важно понимать и помнить суть, и знать, где искать подробности. В результате так и получается — в школе ничего не зубрил, и сейчас те же матрицы в своих записях смотрю как перемножать и в каком порядке. Если постоянно с чем-то работаешь, то этот «рабочий набор» в голове держится, при переключении теряется. Я даже пришёл к выводу, что это достаточно полезный навык — уметь быстро выкидывать из головы всё лишнее, что не требуется для текущих задач, так сказать, поддерживает ясность мыслей, что важно в наше время переполняющих мозг информационных потоков.
Ура! Я не один такой
Я стараюсь работать с меньшим количеством кода.
Для этого стараюсь не использовать сторонний код без необходимости.
Особенно это касается фреймворков PHP.
Для этого стараюсь не использовать сторонний код без необходимости.
Особенно это касается фреймворков PHP.
Автор попал в один из классических распильно-откатных проектов, где главное было сделать видимость работы и подписать акты — и, видимо, так и не понял этого. Инженер со стороны заказчика был студентом, проходящим практику, тесты «за один день» — фикцией, а на рельное железо ничего никогда не встало, как и планировалось изначально. Главный инженер смотрел на чип как на «выточенную железку с размерами и допусками» именно потому, что знал, что на неё никогда даже не будет подан ток.
Так что вся эта тревога о качестве в данном случае была совершенно ни к чему. Качества несуществующего продукта измерить нельзя.
Так что вся эта тревога о качестве в данном случае была совершенно ни к чему. Качества несуществующего продукта измерить нельзя.
Вы забыли написать, — «мы все умрём» и надеть шапочку из фольги.
Про распильные традиции ещё Александр Житинский хорошо написал в рассказе «Глагол „Инженер“».
Скрытый текст
Мы подъехали к институту. Это было очень высокое и узкое здание. Мой пропуск уже дожидался в проходной. Меглишвили повел меня по лестнице, мы куда-то повернули и очутились в приемной Зураба Ираклиевича. Приемная была размером с баскетбольную площадку. В одном ее углу находился небольшой бассейн с золотыми рыбками. Пол был устлан коврами. Гия что-то сказал секретарше, и та исчезла за дверью, к которой была привинчена табличка: «Директор Зураб Ираклиевич Харакадзе». Табличка была из бронзы. Секретарша появилась через пять секунд и жестом пригласила нас в кабинет.
Зураб Ираклиевич сидел за столом. В руке у него была курительная трубка. Он мне напомнил одного своего соотечественника, очень популярного в свое время. В кабинете было все, что нужно для жизни. Цветной телевизор, бар, кресла, диваны, журнальный столик, книжный шкаф, натюрморты на стенах и тому подобное.
Мы тепло поздоровались, и я вынул из портфеля три экземпляра отчета.
– Вот, – скромно сказал я. – Нам удалось кое-что сделать.
Зураб Ираклиевич взял отчет и взвесил его в руке. Потом он перелистал его, выражая удивленное внимание. Меглишвили делал в это время то же самое, пользуясь вторым экземпляром отчета. Зураб Ираклиевич нажал кнопку и сказал в микрофон:
– Чхилая ко мне.
В кабинете возник Чхилая. Он почтительно взял отчет и стал рассматривать кривые, цокая языком.
– Как ви оцениваете? – спросил Зураб Ираклиевич.
– Именно то, что нам нужно, – быстро сказал Чхилая.
– Ми тоже так думаем, – сказал Зураб Ираклиевич.
Он взял все три экземпляра, подошел к книжному шкафу, открыл его ключом, поставил отчеты на полку и снова закрыл шкаф. По тому, как он это делал, я понял, что отчеты никогда больше не покинут этого шкафа.
– Ви свободны, – сказал он Чхилая. Тот провалился.
Зураб Ираклиевич взял меня за локоть и повел по направлению к бару, расспрашивая о Юрии Тимофеевиче, о его здоровье и прочем. Я стал рассказывать о свадьбе Милы. Это всех заинтересовало. Щелкнули автоматические дверцы бара, засияли зеркальные стенки, заискрились вина и коньяки.
– Что будете пить? – спросил Зураб Ираклиевич.
– Замороженный дайкири, – сказал я, вспомнив один из романов Хемингуэя.
Зураб Ираклиевич слегка склонил голову, оценив во мне знатока. Мой заказ не застал его врасплох. Двигаясь на редкость элегантно, он приготовил три дайкири, и мы уселись за столик, потягивая коктейли из соломки. На столике лежали сигареты «Филип Морис» в коричневой пачке. Разговор шел о погоде, тбилисском «Динамо» и грузинских марках коньяка. Некоторые мы тут же дегустировали. Никто не заикнулся о моей работе. Будто ее и не было.
– Да, чуть было не забыл! – сказал я. – Нужно оформить акты.
Я достал бланки. Зураб Ираклиевич изучил их и положил к себе на стол.
– Завтра вам передадут, – сказал он. – Ну что же… Вам надо познакомиться с Тбилиси. Гия, чтобы все было… понимаешь?
Гия понимающе зажмурил глаза.
…
Я пришел в нашу комнату и показал Чемогурову акты.
– Они даже отчет как следует не посмотрели, – сказал я.
– Ты наивный человек, – сказал Чемогуров. – У них оставались лишние двадцать тысяч рублей. Приближался конец года. Вот они их и потратили. Все довольны – и они, и мы.
– Я недоволен, – сказал я.
Зураб Ираклиевич сидел за столом. В руке у него была курительная трубка. Он мне напомнил одного своего соотечественника, очень популярного в свое время. В кабинете было все, что нужно для жизни. Цветной телевизор, бар, кресла, диваны, журнальный столик, книжный шкаф, натюрморты на стенах и тому подобное.
Мы тепло поздоровались, и я вынул из портфеля три экземпляра отчета.
– Вот, – скромно сказал я. – Нам удалось кое-что сделать.
Зураб Ираклиевич взял отчет и взвесил его в руке. Потом он перелистал его, выражая удивленное внимание. Меглишвили делал в это время то же самое, пользуясь вторым экземпляром отчета. Зураб Ираклиевич нажал кнопку и сказал в микрофон:
– Чхилая ко мне.
В кабинете возник Чхилая. Он почтительно взял отчет и стал рассматривать кривые, цокая языком.
– Как ви оцениваете? – спросил Зураб Ираклиевич.
– Именно то, что нам нужно, – быстро сказал Чхилая.
– Ми тоже так думаем, – сказал Зураб Ираклиевич.
Он взял все три экземпляра, подошел к книжному шкафу, открыл его ключом, поставил отчеты на полку и снова закрыл шкаф. По тому, как он это делал, я понял, что отчеты никогда больше не покинут этого шкафа.
– Ви свободны, – сказал он Чхилая. Тот провалился.
Зураб Ираклиевич взял меня за локоть и повел по направлению к бару, расспрашивая о Юрии Тимофеевиче, о его здоровье и прочем. Я стал рассказывать о свадьбе Милы. Это всех заинтересовало. Щелкнули автоматические дверцы бара, засияли зеркальные стенки, заискрились вина и коньяки.
– Что будете пить? – спросил Зураб Ираклиевич.
– Замороженный дайкири, – сказал я, вспомнив один из романов Хемингуэя.
Зураб Ираклиевич слегка склонил голову, оценив во мне знатока. Мой заказ не застал его врасплох. Двигаясь на редкость элегантно, он приготовил три дайкири, и мы уселись за столик, потягивая коктейли из соломки. На столике лежали сигареты «Филип Морис» в коричневой пачке. Разговор шел о погоде, тбилисском «Динамо» и грузинских марках коньяка. Некоторые мы тут же дегустировали. Никто не заикнулся о моей работе. Будто ее и не было.
– Да, чуть было не забыл! – сказал я. – Нужно оформить акты.
Я достал бланки. Зураб Ираклиевич изучил их и положил к себе на стол.
– Завтра вам передадут, – сказал он. – Ну что же… Вам надо познакомиться с Тбилиси. Гия, чтобы все было… понимаешь?
Гия понимающе зажмурил глаза.
…
Я пришел в нашу комнату и показал Чемогурову акты.
– Они даже отчет как следует не посмотрели, – сказал я.
– Ты наивный человек, – сказал Чемогуров. – У них оставались лишние двадцать тысяч рублей. Приближался конец года. Вот они их и потратили. Все довольны – и они, и мы.
– Я недоволен, – сказал я.
IT просто становится одним из тех направлений, где порог входа не высокий, а очень высокий, и приходится пользоваться сторонними продуктами неизвестного качества.
Таже ядерная физика — можно вообще всю жизнь учиться, и не научиться проектировать ядерный реактор. А если научиться, то хрен соберешь команду, финансирование и вообще возможность построить полноценный проект.
Раньше все было как в точной науке. А теперь — бетон не такой привезли, арматура с примесями и ржавчиной, окна вроде бы те, но по размерам чуток не совпадают, и надо допиливать.
Таже ядерная физика — можно вообще всю жизнь учиться, и не научиться проектировать ядерный реактор. А если научиться, то хрен соберешь команду, финансирование и вообще возможность построить полноценный проект.
Раньше все было как в точной науке. А теперь — бетон не такой привезли, арматура с примесями и ржавчиной, окна вроде бы те, но по размерам чуток не совпадают, и надо допиливать.
Да совремнный мир айти это ад перфекциониста. Надо просто понять, что не бывает програм без багов, не бывает идеального алгоритма и не требовать от себя слишком много. Ваш опыт в распильном проекте прекрасный пример.
К примеру очень много правил ПДД написано на крови. Если бы авторы пдд пытались предусмотреть все возможные ньюансы изначально, возможно до сих пор ходили бы пешком. Грустно но правда
К примеру очень много правил ПДД написано на крови. Если бы авторы пдд пытались предусмотреть все возможные ньюансы изначально, возможно до сих пор ходили бы пешком. Грустно но правда
Мне кажется, автор затрагивает очень интересную тему, но немного драматизирует.
Личные воспоминания о серьёзных проектах от микроконтроллеров до Qt в очередной раз показывают, что наша индустрия всё ещё молода, ведь в самом деле, как уже отмечали, невозможно себе представить, чтобы сегодня хирург делал операцию на сердце, а завтра — на мозге.
Получается, что мы работаем несколько «по-ковбойски»: что-то делаем, оно как-то работает, никто не понимает как, и слава богу. Макконнелл считает, что всё будет двигаться в сторону более строгой бюрократической системе разделения работ на основе лицензируемости. Ну, мы уже видим это на примерах всяких сертификатов Oracle или IBM, но в целом, как мне кажется, он впадает в другую крайность.
Я думаю, что проблема будет решаться по кусочкам. Во-первых, есть вопрос денег. Если вы строите у себя амбар на участке, нет смысла нанимать архитектурное бюро и заставлять инженеров просчитывать сопромат. Упадёт — ну и ладно, новый поставим. Так и у нас, глядя на поделия, то есть, гм, инструментарий для внутренних нужд, можно потерять веру в человечество; но мы же понимаем разницу между амбаром на заднем дворе и продуктом на продажу. При этом и вопрос денег тоже решается по-разному. Скажем, китайцам, которые производят ширпотреб десятками или сотнями тысяч единиц, почему-то проще перевести инструкцию гугл-транслейтом, вместо того, чтобы нанять хорошего переводчика всего на один день (!) Видимо, не считают эти космические затраты целесообразными, что тут сказать. В IT ведь всё то же самое: ну хорошо, наймите отдельного специалиста, который разбирается досконально в Qt (и больше ни в чём), но сначала решите, стоит оно того или нет.
Во-вторых, есть вопрос интерфейсов, документированности и обязательств. Пример с «магической строкой» показывает, что не всё здесь ладно, потому что не хватает культуры производства, и это не только авторов Qt проблема, пока попросту нет всеми принятого подхода, и каждый крутится как умеет. Скажем, мне нравится (хотя бы на идейном уровне) подход к документации библиотеки C++ STL. Для каждого алгоритма указаны чёткие требования по входным данным, гарантии выходных данных и асимптотическая сложность алгоритма. При этом почти везде гарантируется, что самостоятельная реализация того же алгоритма вряд ли будет намного лучше, т.е. мысли «переписать STL» в большинстве случаев возникать не должно. То есть мы имеем чётко определённые «кирпичи» с заданными характеристиками, и лезть внутрь такого «кирпича» совершенно незачем. Сравните это с ситуацией в Python, где сам автор языка последовательно перебирает различные «волшебные» строки с целью ускорить алгоритм (не всегда представляя себе ожидаемый результат).
Иными словами, разделение ответственности и ликвидация «волшебных» строк в целом возможны. Но всё это требует больших усилий, денег и дисциплины. Кому-то удаётся лучше, кому-то — так себе. В общем, ужас, но не ужас-ужас-ужас.
Личные воспоминания о серьёзных проектах от микроконтроллеров до Qt в очередной раз показывают, что наша индустрия всё ещё молода, ведь в самом деле, как уже отмечали, невозможно себе представить, чтобы сегодня хирург делал операцию на сердце, а завтра — на мозге.
Получается, что мы работаем несколько «по-ковбойски»: что-то делаем, оно как-то работает, никто не понимает как, и слава богу. Макконнелл считает, что всё будет двигаться в сторону более строгой бюрократической системе разделения работ на основе лицензируемости. Ну, мы уже видим это на примерах всяких сертификатов Oracle или IBM, но в целом, как мне кажется, он впадает в другую крайность.
Я думаю, что проблема будет решаться по кусочкам. Во-первых, есть вопрос денег. Если вы строите у себя амбар на участке, нет смысла нанимать архитектурное бюро и заставлять инженеров просчитывать сопромат. Упадёт — ну и ладно, новый поставим. Так и у нас, глядя на поделия, то есть, гм, инструментарий для внутренних нужд, можно потерять веру в человечество; но мы же понимаем разницу между амбаром на заднем дворе и продуктом на продажу. При этом и вопрос денег тоже решается по-разному. Скажем, китайцам, которые производят ширпотреб десятками или сотнями тысяч единиц, почему-то проще перевести инструкцию гугл-транслейтом, вместо того, чтобы нанять хорошего переводчика всего на один день (!) Видимо, не считают эти космические затраты целесообразными, что тут сказать. В IT ведь всё то же самое: ну хорошо, наймите отдельного специалиста, который разбирается досконально в Qt (и больше ни в чём), но сначала решите, стоит оно того или нет.
Во-вторых, есть вопрос интерфейсов, документированности и обязательств. Пример с «магической строкой» показывает, что не всё здесь ладно, потому что не хватает культуры производства, и это не только авторов Qt проблема, пока попросту нет всеми принятого подхода, и каждый крутится как умеет. Скажем, мне нравится (хотя бы на идейном уровне) подход к документации библиотеки C++ STL. Для каждого алгоритма указаны чёткие требования по входным данным, гарантии выходных данных и асимптотическая сложность алгоритма. При этом почти везде гарантируется, что самостоятельная реализация того же алгоритма вряд ли будет намного лучше, т.е. мысли «переписать STL» в большинстве случаев возникать не должно. То есть мы имеем чётко определённые «кирпичи» с заданными характеристиками, и лезть внутрь такого «кирпича» совершенно незачем. Сравните это с ситуацией в Python, где сам автор языка последовательно перебирает различные «волшебные» строки с целью ускорить алгоритм (не всегда представляя себе ожидаемый результат).
Иными словами, разделение ответственности и ликвидация «волшебных» строк в целом возможны. Но всё это требует больших усилий, денег и дисциплины. Кому-то удаётся лучше, кому-то — так себе. В общем, ужас, но не ужас-ужас-ужас.
О, мой любимый пример — GPS! Вам вовсе не обязательно быть специалистом в радиосвязи, ракетостроении и конструкциях спутников, чтобы получать данные от GPS в своем приложении для смартфона. Но вся система, в целом, в таком случае, становится становится некой "магической" средой, где для достижения результата нужно знать определенные "заклинания". Мы живем в интересное время, когда технологии становятся не менее абстрактными, чем идеи, но лично меня это не пугает. Главное — дружить и говорить на одном языке с теми "демонами", с которыми вы имеете дело, а остальной мир пусть остается "волшебным", это же весело! Ну и то, что называется "технологической сингулярностью", ИМХО, давно уже наступило, в глобальном плане. Это было неизбежно, и главное не тормозить с адаптацией собственного мышления к новой среде.
С приходом осени столько нытья на хабре… Крепитесь, люди, скоро лето! :)
Не все возможно доживут, но уж точно мир не рухнет.
ЗЫ: эта статья отличается от прочих в лучшую сторону тем, что в ней хотя бы пара строк кода есть.
Не все возможно доживут, но уж точно мир не рухнет.
ЗЫ: эта статья отличается от прочих в лучшую сторону тем, что в ней хотя бы пара строк кода есть.
Напомнило доклад дяди Боба «The Future of Programming». Во всяком случае опасения у авторов одинаковы.
Коллегам-психам на заметку на счет чужих библиотек: когда уж сильно прижимает подозрительность и паранойя, я пишу для чужих либ тесты, бенчмарки и собственные реализации. Через день-другой сравнения прихожу к выводу, что для моей задачи библиотека работает так же или лучше, чем самописное решение и с чистой совестью использую ее. :)
Да, бывают и курьезы, например, собраный на коленке из чего-то там и палок RLE для несжатых текстур оказался выгоднее всех существующих. До сих пор не могу себя заставить от него избавиться.
Да, бывают и курьезы, например, собраный на коленке из чего-то там и палок RLE для несжатых текстур оказался выгоднее всех существующих. До сих пор не могу себя заставить от него избавиться.
я пишу для чужих либ тесты, бенчмарки и собственные реализации
Весьма интересный подход к насущному вопросу.
Но вот в чём другой вопрос: смысл чужих либ как раз таки в том, чтобы не писать свои самому — насколько окупается написание тестов и собственных реализаций? Всегда ли есть на это время? Если нет — то как поступаете?
Скажу точно, на это времени никогда нет и в общем зачете почти никогда не окупается! Даже когда получается добиться выше производительности/удобства, например, в собственном физическом движке, то затраченное время никак не соизмеримо с использованием чужого кода. Но зато это весьма наглядно избавляет от шизов вроде «я бы сделал это лучше» )) Если оценивать с точки зрения психического состояния разработчика как залога успеха — выходит вполне нормально. С точки зрения эффективности — ужас-ужас.
Возможно, не будь я программистом, мне не было бы так страшно…
А теперь представьте, как страшно жить химикам, особенно тем, кто связан с производством. В университетский курс входит изучение 3-7 различных направлений химии в семестр. Достаточно, чтоб разбираться в свойства всего, что нас окружает: строй материалы, отделочные, мебель, пищевая химия и экология, лекарственные средства, косметические средства и много другое.
Вы правы на все 100%. И от этого грустно. Потому что всем плевать: живут здесь и сейчас, а что будет завтра — не важно: перепишем, перекодируем, пере-, пере-, пере...
Я согласен с автором статьи в том, что для обычного программиста бурный рост технологий приводит к тому, что он не понимает что он пишет и для чего. Возможно это связано со старением и молодые джуниоры с горящими глазами и зудом в руках легко с этим всем справляются, но для программистов с опытом всё не так однозначно. Всё чаще и чаще относишься к новым технологиям с настороженностью и не тратишь время на их изучение, потому что не знаешь приживётся она или нет.
Стыдно сказать, что я даже AngularJS знаю очень и очень поверхностно просто потому что реальных проектов с ним не было, а вот-вот прийдёт 2ая версия и может сложиться так, что 1ая мне никогда и не понадобится.
Другая проблема — это компетенция самих разработчиков и команды в целом. Я работал в проектах, где были сильные программисты, середнячки и откровенно слабые. И если у части команды возникали вопросы о том, как будет работать система в целом, какие плюсы и минусы есть у данного решения и т.д, то у некоторых этих вопросов не возникало и они просто кодили или даже собирали пазл из раннее написанного кода и того, что нашли в интернете. Всё это приводило к скрытым и плавающим багам и даже к проблемам в архитектуре. И такого кода много в любой крупной системе.
Поэтому чем больше мы внедряем ПО в нашу жизнь, тем больше вероятность что какие-то из этих ошибок выстрелят и приведут к очень печальных последствиям. Конечно входить в высотные здания и летать на самолёте я пока ещё не очень боюсь, а вот пользоваться онлайн-банкингом побаиваюсь значительно сильнее. (Опять же примерно представляя качество продукта, которым приходится пользоваться).
Но тем не менее — не думаю, что всё вышеописанное — плохо. Это как с автомобилем — все знают что достаточно одного неверного решения или действия — и вы можете погибнуть, но тем не менее все продолжают ими пользоваться потому что удобство от использования перевешивает страх.
Стыдно сказать, что я даже AngularJS знаю очень и очень поверхностно просто потому что реальных проектов с ним не было, а вот-вот прийдёт 2ая версия и может сложиться так, что 1ая мне никогда и не понадобится.
Другая проблема — это компетенция самих разработчиков и команды в целом. Я работал в проектах, где были сильные программисты, середнячки и откровенно слабые. И если у части команды возникали вопросы о том, как будет работать система в целом, какие плюсы и минусы есть у данного решения и т.д, то у некоторых этих вопросов не возникало и они просто кодили или даже собирали пазл из раннее написанного кода и того, что нашли в интернете. Всё это приводило к скрытым и плавающим багам и даже к проблемам в архитектуре. И такого кода много в любой крупной системе.
Поэтому чем больше мы внедряем ПО в нашу жизнь, тем больше вероятность что какие-то из этих ошибок выстрелят и приведут к очень печальных последствиям. Конечно входить в высотные здания и летать на самолёте я пока ещё не очень боюсь, а вот пользоваться онлайн-банкингом побаиваюсь значительно сильнее. (Опять же примерно представляя качество продукта, которым приходится пользоваться).
Но тем не менее — не думаю, что всё вышеописанное — плохо. Это как с автомобилем — все знают что достаточно одного неверного решения или действия — и вы можете погибнуть, но тем не менее все продолжают ими пользоваться потому что удобство от использования перевешивает страх.
Какой-то «левый» (перемаркированный) STM32F407VGT6 на иллюстрации
должно быть вот так примерно
/>
должно быть вот так примерно
/>
НЛО прилетело и опубликовало эту надпись здесь
А так всегда, и не только в программировании-я тоже так, устроился в компанию, продумывал планы, что я буду делать и как, заполнял таблицы, отчеты, не спал до 3х ночи, ездил по делам фирмы во вне рабочее время-результат? (с армянским акцентом)-пиши заулявление, нам не нрауцца, как ти работаеш.
Это происходит от нежелания людей вникать в нюансы, от непрофессионализма, от жадности, от глупости…
Это происходит от нежелания людей вникать в нюансы, от непрофессионализма, от жадности, от глупости…
Хочу выразить несогласие с мнением автора. Оглянитесь вокруг — программное моделирование сложнейших процессов, спутники, автопилоты, суперкомпьютеры, роботехника в производстве, IoT, системы поддержки принятия решений, помощь в проектировании сложных систем, числодробилки, криптовалюты, 3D-принтинг, realtime-аналитика, фотореалистичная графика, свободное программное обеспечение.
Да, мы ограничены. Да, мы не всегда понимаем, что мы делаем. Да, сложность зашкаливает, и мы не можем её победить. Ну и что? Это мешает нам делать мир лучше? Каждый чертов день мы можем все больше и больше, и я счастлив принимать в этом участие.
Да, мы ограничены. Да, мы не всегда понимаем, что мы делаем. Да, сложность зашкаливает, и мы не можем её победить. Ну и что? Это мешает нам делать мир лучше? Каждый чертов день мы можем все больше и больше, и я счастлив принимать в этом участие.
Компьютер «Специалист»!!! Как же давно это было. Я его собрал в 1989, и как большое достижение написал что-то похожее на Sokoban, конечно на ассемблере.
А по теме — с ростом сложности происходит разделение по уровням. Пример — сетевая модель OSI. Каждый из её уровней сам по себе очень сложен, но как то они уживаются вместе. И конечно включается естественный отбор. Та же Qt — библиотека смогла выжить, она поддержана большим сообществом разработчиков и позволяет разрабатывать сложные проекты.
А по теме — с ростом сложности происходит разделение по уровням. Пример — сетевая модель 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/
считаю, что ПО от которого зависят жизни и здоровье людей (автопилоты самолётов, электронные помощники в авто, управление медтехникой и реакторами АЭС) должно быть либо открытым (чтобы любой заинтересованный мог проверить логику его работы), либо быть написаным специалистом, подписавшим договор о персональной административной/имущественной/уголовной ответственности за последствия работы его программы.
https://geektimes.ru/post/279548/
https://habrahabr.ru/company/pvs-studio/blog/307788/
считаю, что ПО от которого зависят жизни и здоровье людей (автопилоты самолётов, электронные помощники в авто, управление медтехникой и реакторами АЭС) должно быть либо открытым (чтобы любой заинтересованный мог проверить логику его работы), либо быть написаным специалистом, подписавшим договор о персональной административной/имущественной/уголовной ответственности за последствия работы его программы.
Автор ставит вопрос — «Можно ли верить медицинским приборам? „
Желаю автору не болеть всю жизнь.
Иначе без анализов (которые делаются медицинскими приборами) доктора его
“пошлют» — и останется только что то вроде «нетрадиционной медицины»
Желаю автору не болеть всю жизнь.
Иначе без анализов (которые делаются медицинскими приборами) доктора его
“пошлют» — и останется только что то вроде «нетрадиционной медицины»
Медицинским приборам в целом можно верить при условии соблюдения персоналом правил их эксплуатации.
Впрочем, проблемы бывают не только при невыполнении правил, но и при некоторых предположениях, закладываемых в логику работы приборов.
Впрочем, проблемы бывают не только при невыполнении правил, но и при некоторых предположениях, закладываемых в логику работы приборов.
И в самом деле, не болеть — лучше: https://geektimes.ru/post/268510/
Уже есть пример из жизни: сотовый телефон через который порой невозможно поговорить из-за глюков то ли сети, то ли самого телефона. (обрыв во время разговора, тебя не слышат/ты не слышишь, отбой во время дозвона, пропала сеть)
Начали хорошего примера.
Про цветок.
Да, Вы объяснили силой тяжести и его ростом причину его падения, но разве Вы знаете откуда взялась сила тяжести и/или почему он рос? Знание причин почему что-то работает никогда полным не будет.
Так почему это это должно быть проблемой именно в программировании?
Это не проблема, это реальность, и тут самое главное суметь ее принять.
«premature optimization root of evil» по большому счету оттуда же, от желания все сделать идеально правильно, но именно поэтому эта идея и проваливается.
Некоторое количество погрешностей будет всегда и без понимания этого нет самого важного — понимания что с этими погрешностями надо работать и как надо с ними работать.
Упрощая… допустим Вы не знаете почему этот цветок падает, но раз Вы можете предусмотреть такую возможность, просто привязываете горшок веревкой.
Про цветок.
Да, Вы объяснили силой тяжести и его ростом причину его падения, но разве Вы знаете откуда взялась сила тяжести и/или почему он рос? Знание причин почему что-то работает никогда полным не будет.
Так почему это это должно быть проблемой именно в программировании?
Это не проблема, это реальность, и тут самое главное суметь ее принять.
«premature optimization root of evil» по большому счету оттуда же, от желания все сделать идеально правильно, но именно поэтому эта идея и проваливается.
Некоторое количество погрешностей будет всегда и без понимания этого нет самого важного — понимания что с этими погрешностями надо работать и как надо с ними работать.
Упрощая… допустим Вы не знаете почему этот цветок падает, но раз Вы можете предусмотреть такую возможность, просто привязываете горшок веревкой.
Я суеверный человек. Знаете, как я к этому пришел? В один прекрасный момент я осознал всю сложность окружающих нас систем. До мурашек на коже осознал.
Подумайте только, что происходит, когда вы смотрите котиков на ютубе. Огромное число элементов взаимодействуют друг с другом: железо сервера от разных производителей (оператива, процессор, сетевая карта, хранилище, шины данных), firmware для этого железа, ОС с тысячами библиотек, написаных разными людьми, веб-сервер, каналы связи, маршрутизаторы со своим ПО, железо вашего компа со всем его firmware, ОС, браузер, кодеки. Все это передает данные друг другу по разным протоколам, использует разные технологии. На самом деле это только верхушка айсберга. Если разбирать каждый элемент этой системы — он сам по себе представляет сложную систему взаимодействующих частей.
Все, что происходит, я могу назвать только волшебством. Не потому, что я не понимаю, как это работает, а как раз наоборот — потому что я более-менее знаю, что происходит. Мне не дает покоя один вопрос: какого лешего это всё не ломается уже сейчас?
Сразу отвечу насчет стандартизации и тестирования — это не панацея. Все мы знаем, что идеального ПО не существует.
Представьте себе, что в алгоритме одной библиотеки есть ошибка: при определенной последовательности входных данных на выход вылетает мусор. Сможем мы протестировать эту последовательность, если она встречается довольно редко? Нет. Мы не может потестировать все пространство входных данных, иначе в этом алгоритме не было бы смысла: достаточно было бы взять матрицу вход/выход из тестов. Все ПО, которое использует библиотеку расчитывает на корректность ее работы. Что в итоге? UB работы всей системы.
Это простой случай. А теперь более сложый. Если эту последовательность не тестировали, потому что она никогда не должна была поступить на вход? Но случилось так, что элемент системы от которого пришли данные тоже имел небольшую ошибку. Эта область пересечения нескольких ошибок разных частей и вызвала крах всей системы. Такие вещи практически непредсказуемы.
А теперь представьте, что в современных гипер-сложных системах сотни (если не тысячи) таких точек возможного слома. Просто они спят и ждут своего часа. Еще не страшно? Сейчас-сейчас… А давайте мы добавим в систему более непредсказуемые элементы навроде нейронных сетей? Сдобрим это все генетическими алгоритмами? И заставим системы больше взаимодействовать с реальным миром и друг с другом, добавив тем самым сложности и случайности?
Завидую людям, которые не заглядывают на другие уровни абстракции. Как же им проще: они уверены, что когда что-то используют — все будет хорошо. Вы как хотите, а я пойду выбирать себе талисман на удачу :)
P.S. только что наткнулся на статью, которая сильно перекливается с моими мыслями
Подумайте только, что происходит, когда вы смотрите котиков на ютубе. Огромное число элементов взаимодействуют друг с другом: железо сервера от разных производителей (оператива, процессор, сетевая карта, хранилище, шины данных), firmware для этого железа, ОС с тысячами библиотек, написаных разными людьми, веб-сервер, каналы связи, маршрутизаторы со своим ПО, железо вашего компа со всем его firmware, ОС, браузер, кодеки. Все это передает данные друг другу по разным протоколам, использует разные технологии. На самом деле это только верхушка айсберга. Если разбирать каждый элемент этой системы — он сам по себе представляет сложную систему взаимодействующих частей.
Все, что происходит, я могу назвать только волшебством. Не потому, что я не понимаю, как это работает, а как раз наоборот — потому что я более-менее знаю, что происходит. Мне не дает покоя один вопрос: какого лешего это всё не ломается уже сейчас?
Сразу отвечу насчет стандартизации и тестирования — это не панацея. Все мы знаем, что идеального ПО не существует.
Представьте себе, что в алгоритме одной библиотеки есть ошибка: при определенной последовательности входных данных на выход вылетает мусор. Сможем мы протестировать эту последовательность, если она встречается довольно редко? Нет. Мы не может потестировать все пространство входных данных, иначе в этом алгоритме не было бы смысла: достаточно было бы взять матрицу вход/выход из тестов. Все ПО, которое использует библиотеку расчитывает на корректность ее работы. Что в итоге? UB работы всей системы.
Это простой случай. А теперь более сложый. Если эту последовательность не тестировали, потому что она никогда не должна была поступить на вход? Но случилось так, что элемент системы от которого пришли данные тоже имел небольшую ошибку. Эта область пересечения нескольких ошибок разных частей и вызвала крах всей системы. Такие вещи практически непредсказуемы.
А теперь представьте, что в современных гипер-сложных системах сотни (если не тысячи) таких точек возможного слома. Просто они спят и ждут своего часа. Еще не страшно? Сейчас-сейчас… А давайте мы добавим в систему более непредсказуемые элементы навроде нейронных сетей? Сдобрим это все генетическими алгоритмами? И заставим системы больше взаимодействовать с реальным миром и друг с другом, добавив тем самым сложности и случайности?
Завидую людям, которые не заглядывают на другие уровни абстракции. Как же им проще: они уверены, что когда что-то используют — все будет хорошо. Вы как хотите, а я пойду выбирать себе талисман на удачу :)
P.S. только что наткнулся на статью, которая сильно перекливается с моими мыслями
Ваши рассуждения напоминают анекдот о вероятности падения метеорита 50% — может упасть, а может и нет.
Если вы думаете, что оно должно сломаться, а оно все никак не ломается — это не волшебство, это вы неправы.
Если вы думаете, что оно должно сломаться, а оно все никак не ломается — это не волшебство, это вы неправы.
А оно ломается. Просто пока это единичные случаи. Думаю, существует некая граница энтропии системы, при приближении к которой вероятность возникновения ошибки будет стремиться к единице. Вопрос лишь в том, как скоро мы приблизимся к этой границе.
Вообще теперь ничего делать не будем?
У каждой системы есть срок службы, в конце концов.
У каждой системы есть срок службы, в конце концов.
Я не имею в виду износ. Я говорю про то, что в определенный момент в созданной сложной системе вероятность возникновения ошибки будет велика. К этому просто нужно быть готовым. Мы уже давно пытаемся отсрочить этот момент, создавая новые языки, инструменты и подходы. Но, думаю, есть какой-то теоретический предел сложности, и рано или поздно мы к нему подберемся.
Хотите свежий пример? Есть смартфон от фирмы S с номером 7. Думаю, вы в курсе новостей. Тестировали ли аккумулятор во время разработки? Конечно да. Сам смартфон? Определенно. Контроллер зарядки? Да. Все вместе? Конечно!
Почему же он взрывается? Дело не в качестве отдельных частей, но в их объединение. Это объединение создало сложную систему не только с новыми свойствами, но и с новыми потенциальными ошибками.
Почему же эти ошибки не нашли во время тестирования? Отдельные части были протестированы и, думаю, работали хорошо. Насколько я помню, число бракованых смартфонов составляет 25 на миллион. Как вы думаете, какова была вероятность наткнуться на этот баг во время тестов всего смартфона? Очень мала. Смарт выпустили на рынок — и тут сработал закон больших чисел.
Хотите свежий пример? Есть смартфон от фирмы S с номером 7. Думаю, вы в курсе новостей. Тестировали ли аккумулятор во время разработки? Конечно да. Сам смартфон? Определенно. Контроллер зарядки? Да. Все вместе? Конечно!
Почему же он взрывается? Дело не в качестве отдельных частей, но в их объединение. Это объединение создало сложную систему не только с новыми свойствами, но и с новыми потенциальными ошибками.
Почему же эти ошибки не нашли во время тестирования? Отдельные части были протестированы и, думаю, работали хорошо. Насколько я помню, число бракованых смартфонов составляет 25 на миллион. Как вы думаете, какова была вероятность наткнуться на этот баг во время тестов всего смартфона? Очень мала. Смарт выпустили на рынок — и тут сработал закон больших чисел.
Почему же он взрывается?
Брак при производстве. Который выразился в сильном сжатие батареи (при её производстве), что и приводит к возгоранию.
Причина: При производстве не проводился достаточный(!) контроль на деформацию батареи.
Виновные наказаны (расстреляны?) — но осадочек и не слабый то, остался.
Если программисты и далее будут писать микроконтроллеры на Node.js, то да, всё плохо. Выбор языка программирования не решает всех бед, но позволяет существенно повлиять на доверие к поведеню программ. Скажем, сильная типизация Rust позволяет избежать множества ошибок ещё до тестирования, а также гарантирует определённое поведение при исключительных ситуациях (паника).
Отставив проблемы человеческих отношений в сторону (это отдельная тема), я вижу большой потенциал в развитии парадигм программирования и инструментов, их реализующих. Скажем, если вы в функциональном языке вызываете чистую функцию с определёнными параметрами, то во-первых можете быть уверены, что результат при тех же аргументах не изменится; а во вторых, что она не станет ломать пентагон и нажимать на красную кнопку.
Функциональное и чистое программирование стало популярным сейчас не просто так. Современные системы становятся все более и более сложными. Это попытка снизить эту сложность, отсрочить на время ад комплексных систем.
Будут, конечно, писать на node.js (openwrt там, все дела). То, что в нодах можно в одну уже тысячу раз написанную строку реализовать, вообще не задумываясь, в этих ваших ассемблерах придется отлаживать до пенсии.
Почему-то автор статьи и многие комментаторы искренне, как мне показалось, считают, что данная «проблема» касается только программирования и программного обеспечения.
Вот, например, автор боится идти по мосту, потому что программисты, которые писали программы проектирования мостов, не знали до конца, что именно они делают, а заказчик программы (по сути — конечный её пользователь) вообще не разбирается в программировании.
Но при этом автор забывает, что мост проектировала не только программа, но и люди. И не поверите — 99% проектировщиков мостов и других сооружений и зданий не являются специалистами в теории упругости. Да многие (очень многие) не вспоминают даже простого сопромата при проектировании строительных конструкций. А еще очень мало кто из них является специалистом в материаловедении и не представляет себе ни состава используемой стали, ни процесса прокатки двутавровых балок. Конечно, проектировщик, который знает всю подноготную строительства от добычи ископаемых до покраски фасадов ценится выше. Но таких, честно скажу, не много.
Да, у нас, у проектировщиков, все то же самое — разделение труда и совершенно слепое использование чужих наработок. Один институт разрабатывает состав бетона, второй разрабатывает технологию его укладки, третий — сталь для арматуры, четвертый — профиль арматуры, пятый — формирует серию на изготовление железобетонных плит, шестой — просто применяет их в проекте. Всё то же, что и в программировании — есть низкоуровневая разработка, есть высокоуровневая, есть библиотеки готовыхфункций инженерных решений, есть конечные программы проекты, использующие их.
А заказчики у нас техзадание вообще писать не умеют. Совершенно. Абсолютно. Приходят и просят проектную организацию саму себе задание написать и ставят под ним подпись.
И это в любых областях нашей жизни так — терапевт в районной поликлинике — не микробиолог и может не представлять себе, как именно лекарство будет воздействовать на ваши клетки. А вы, как заказчик работы терапевта — тем более.
Так что еще можно поспорить, кто быстрее погубит мир))
Вот, например, автор боится идти по мосту, потому что программисты, которые писали программы проектирования мостов, не знали до конца, что именно они делают, а заказчик программы (по сути — конечный её пользователь) вообще не разбирается в программировании.
Но при этом автор забывает, что мост проектировала не только программа, но и люди. И не поверите — 99% проектировщиков мостов и других сооружений и зданий не являются специалистами в теории упругости. Да многие (очень многие) не вспоминают даже простого сопромата при проектировании строительных конструкций. А еще очень мало кто из них является специалистом в материаловедении и не представляет себе ни состава используемой стали, ни процесса прокатки двутавровых балок. Конечно, проектировщик, который знает всю подноготную строительства от добычи ископаемых до покраски фасадов ценится выше. Но таких, честно скажу, не много.
Да, у нас, у проектировщиков, все то же самое — разделение труда и совершенно слепое использование чужих наработок. Один институт разрабатывает состав бетона, второй разрабатывает технологию его укладки, третий — сталь для арматуры, четвертый — профиль арматуры, пятый — формирует серию на изготовление железобетонных плит, шестой — просто применяет их в проекте. Всё то же, что и в программировании — есть низкоуровневая разработка, есть высокоуровневая, есть библиотеки готовых
А заказчики у нас техзадание вообще писать не умеют. Совершенно. Абсолютно. Приходят и просят проектную организацию саму себе задание написать и ставят под ним подпись.
И это в любых областях нашей жизни так — терапевт в районной поликлинике — не микробиолог и может не представлять себе, как именно лекарство будет воздействовать на ваши клетки. А вы, как заказчик работы терапевта — тем более.
Так что еще можно поспорить, кто быстрее погубит мир))
Статья навела уныние, но так устроен мир прогресса. Каждый должен уметь делать одно дело, но хорошо и уверенно.
Я осознал это в первый раз, когда мне ученный(доктор наук) физик ядерщик не смог во время одной из дискуссии ответить, как при помощи закона Гука рассчитать прикладываемую силу к пружине, при известной степени деформации.
Я осознал это в первый раз, когда мне ученный(доктор наук) физик ядерщик не смог во время одной из дискуссии ответить, как при помощи закона Гука рассчитать прикладываемую силу к пружине, при известной степени деформации.
Однако были и нюансы:
Эти нюансы по хорошему должен разрешать специальный человек, который называется «инженер-системотехник». Именно он и должен был обеспечить коммуникацию между вами и «железячниками», и разбираться с тем, что Вы назвали «Бедой N2».
Вообще, странно, что вы задались этим вопросом только сейчас, потому что на самом деле наш мир работает так уже достаточно давно. Если взять любую сложную систему, то мы вряд ли найдем человека досконально понимающего нюансы работы всех ее подсистем. Взять даже ассемблер, когда Вы пишите команду, думаете ли Вы о том, когда конкретно процессор ее вычитает, во что преобразует ее декодер инструкций, что произойдет с ней в конвейере, в каких физических регистрах окажется результат, и так далее? Думаю, что вряд ли, и процессор для Вас тоже своего рода «черный ящик», но ящик привычный, и потому не вызывающий вопросов и опасений «а вдруг там баг», а вот библиотека — ящик непривычный, отсюда и опасения.
На самом деле, если начать задумываться о том, сколько «деталей» и процессов должно быть задействовано, чтобы отправить или прочесть это сообщение, сколько тысяч людей понадобилось, чтобы все эти «детали» создать, сколько подводных камней им пришлось обойти, чтобы заставить это заработать, и сколько во всем этом мест, где что-то может сломаться, недолго заработать тяжелую форму паранойи.
Статья полна откровенной тупости, и автору почему-то смешно, а не стыдно, и винит он в этом кого угодно, только не себя.
>>Эй! Коллега программист! Это что еще за хрень?
Об этой «хрени» наверняка есть где-то целый раздел в документации (где, возможно, и строчечки те волшебные приведены), который эти две кодомакаки, по обыкновению, не читали. А потом им «что-то слишком сложно и непонятно все, я боюся чо-то». (Да, я знаю, что бывают баги в либах, но чаще всего виноваты все же не они, а сами макаки.)
А вообще, есть такая хорошая книжка Гради Буча, называется «Объектно-ориентированный анализ и проектирование». Он там наглядно (в смешных картинках с котиками), но очень толково объясняет, как программист может понимать, почему (не)работает система, не разбирая в деталях устройство ее компонентов, и почему пользователю сложная система может казаться простой и понятной (и это правильно). Так что снизу доверху знать, «как работает программа», не нужно.
>>Эй! Коллега программист! Это что еще за хрень?
Об этой «хрени» наверняка есть где-то целый раздел в документации (где, возможно, и строчечки те волшебные приведены), который эти две кодомакаки, по обыкновению, не читали. А потом им «что-то слишком сложно и непонятно все, я боюся чо-то». (Да, я знаю, что бывают баги в либах, но чаще всего виноваты все же не они, а сами макаки.)
А вообще, есть такая хорошая книжка Гради Буча, называется «Объектно-ориентированный анализ и проектирование». Он там наглядно (в смешных картинках с котиками), но очень толково объясняет, как программист может понимать, почему (не)работает система, не разбирая в деталях устройство ее компонентов, и почему пользователю сложная система может казаться простой и понятной (и это правильно). Так что снизу доверху знать, «как работает программа», не нужно.
Программист знает как работает его код. Если не знает — то он не программист. Как работают всякие подключаемые библиотеки — не знает и знать совершенно не обязан. Заказчик тоже совершенно не обязан понимать тонкости написания программ. Не понимаю в чём пафос статьи.
Не понимаю в чём пафос статьи.
Были времена, где программист мог объяснить поведение своей программы с точностью до ячейки памяти.
Те времена канули в лету.
Ой, ну в самом деле, зачем программисту, чтобы приложение работало стабильно и без багов? Ведь ему же деньги платят, чтобы его код работал, верно?
Никто вам не даст исходники чипов и плат, из которых собран ваш компьютер.
Следовательно, знать от и до, как работает программа, вообще невозможно.
Следовательно, знать от и до, как работает программа, вообще невозможно.
Я не говорю про полный контроль над всей системой. Тут товарищ даже не готов разбираться в библиотеках, которые он выбирает для своего проекта. Мне кажется, что это входит в обязанности хорошего разработчика.
Это не подразумевает ковыряния в этих библиотеках. Тем более, что много хороших фреймворков вообще закрытые.
Этот «товарищ» вам все сказал правильно, слово «инкапсуляция» вам о чем-то говорит?
Этот «товарищ» вам все сказал правильно, слово «инкапсуляция» вам о чем-то говорит?
Я не буду разбираться до мелочей, как работает та или иная библиотека (при условии, что я не разрабатываю ПО, которое, возможно, будет использоваться в критически важных системах).
Но я могу оценить подходы в разработке: качество кода, покрытие тестами, общую архитектуру, число тикетов на багтрекере, насколько их быстро закрывают, кто эту библиотеку разрабатывает в конце концов. И это срабатывает в большинстве случаев.
В случае закрытого ПО я не смогу этого сделать. Мне приходится верить. Что-что, а обещать в современном мире красивых презентаци и лендингов умеют все. Вот я даже не смогу исправить ошибку в библиотеке, если на нее наткнусь.
Еще один совет: когда вы собираетесь выложить свою библиотеку в открытый доступ — помните, что какой-то чудак может использовать ее на атомной станции :) Пишите хороший код.
Но я могу оценить подходы в разработке: качество кода, покрытие тестами, общую архитектуру, число тикетов на багтрекере, насколько их быстро закрывают, кто эту библиотеку разрабатывает в конце концов. И это срабатывает в большинстве случаев.
В случае закрытого ПО я не смогу этого сделать. Мне приходится верить. Что-что, а обещать в современном мире красивых презентаци и лендингов умеют все. Вот я даже не смогу исправить ошибку в библиотеке, если на нее наткнусь.
Еще один совет: когда вы собираетесь выложить свою библиотеку в открытый доступ — помните, что какой-то чудак может использовать ее на атомной станции :) Пишите хороший код.
Спасибо большое за совет! Буду писать игровой движок на джаваскрипте — обязательно подумаю о новой Фукусиме!
А если серьезно, вам уже миллион раз написали, что у всего есть свои сценарии использования (т.е. интерфейс) и сфера применения.
То, что библиотека ведет себя так, как описано в доках, и используется в тысячах проектов, у вас не срабатывает? Хотя вот, например, openssl… Ах да, она же открытая.
А если серьезно, вам уже миллион раз написали, что у всего есть свои сценарии использования (т.е. интерфейс) и сфера применения.
То, что библиотека ведет себя так, как описано в доках, и используется в тысячах проектов, у вас не срабатывает? Хотя вот, например, 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, в которой про воспроизведение из сети вообще ничего нет.
Я как раз таки осознаю свою некомпетентность. Я не понимаю как ее преодолеть. Преодолеть можно, но это время, которого на самом деле почти нет.
Смотрите, предположим меня просят участвовать в проекте с использованием Qt, который я ранее не использовал. Однако руководство считает, что мне нужно временно помочь коллегам с этим проектом. Естественно я как могу быстро пытаюсь понять, что такое Qt и как это работает.
По собственному опыту или по собственной не компетенции могу сказать, что некоторые компоненты Qt работают довольно загадочно. По крайней мере для меня.
Например: QMediaPlayer воспроизводит локальные видео файлы точно как описано в документации, можно делать паузу, воспроизведение и менять позицию воспроизведения. Однако, если вместо локального файла использовать QUrl указывающий на сетевой ресурс, то воспроизведение начинается, но сменить позицию воспроизведения setPosition() уже не получается. Почему? Почему QMediaPlayer не следует документации Qt? К слову в документации Qt фообще нет упоминания про воспроизведение из сетевых ресурсов. Может это вообще нельзя?
Это происходит в Windows c Qt мультимедиа бэкендом dsengine_plugin.
Если же ту же самую программу без изменений компилировать и запускать в Linux, с мультимедиа бэкэндом gstreamer, то все работает: и setPosition() так же замечательно работает. Что за такая кроссплатформенность в Qt, которая по разному себя ведет на разных платформах? И как я это должен чинить? Нам просто повезло, что оказывается Qt предлагает для виндовс на выбор второй мультимедиа бэкэнд wmfengine_plugin, который и в виндовс ведет себя достойно. Но почему он в Qt библиотеках по умолчанию не стоит? Для меня это сплошное недоумение.
Должен ли я не разобравшись до конца, почему один бэкэнд лучше другого просто плюнуть и использовать второй? Или нужно тратить время и разбираться где баг в библиотеке Qt?
Да, я согласен. Моя не компетенция. Но эта такая «не компетенция» которая занимает полторы недели безрезультатного поиска в гугле и чтения документации Qt, в которой про воспроизведение из сети вообще ничего нет.
А вот здесь появляется очень интересный вопрос об оплате того чем мы пользуемся. Например Qt имеет несколько версий, open-source и коммерческую. В общем случае, если есть какие то требования, то за них надо платить. Собственно в этом направлении и развивается мир.
Кстати в примере с компьютером «Специалист» есть фраза — «я знал о программе всё», но это наверняка это не так. Например, как выполняются команды внутри процессора? Так что принципиально ничего не изменилось. Мы создаём новые продукты на основе того, что кто-то сделал раньше.
Кстати в примере с компьютером «Специалист» есть фраза — «я знал о программе всё», но это наверняка это не так. Например, как выполняются команды внутри процессора? Так что принципиально ничего не изменилось. Мы создаём новые продукты на основе того, что кто-то сделал раньше.
Вы меня, разумеется, поняли превратно в силу своего стиля мышления, который я и критикую.
Некомпетентность ваша не в том, что вы не понимаете, как оно работает.
Она в том, что вы пытаетесь найти workaround вместо того, чтобы искать _надежное_ решение (да, найти другое стороннее решение, которое работает, как заявлено, или написать свое). Системы, построенные методом тыка, и работают, как попало — тут вы никакой Америки не открыли, капитан.
«Гы-гы хрень какайто нук тыкни суды чо будит» — типичный технарь-стайл говночистов по компьютерам (может быть, это в самом деле и не так, но я сужу по тому, что вы написали). И вы пишете так, как будто это нормально и неизбежно. Я тысячу раз видел, как люди ругали инструменты и пытались методом тыка что-нибудь «порезолвить» из-за собственных «кривых рук» и превратного восприятия.
QMediaPlayer::seekable() что возвращала? Если false, все ок, все по документации. Где написано, что любой media source можно прокручивать? Там еще seekableChanged() есть (заметили ее вообще?), что как бы намекает нам, что media source может совершенно внезапно стать/перестать быть seekable, и библиотека вас уведомит, когда это произойдет.
Некомпетентность ваша не в том, что вы не понимаете, как оно работает.
Она в том, что вы пытаетесь найти workaround вместо того, чтобы искать _надежное_ решение (да, найти другое стороннее решение, которое работает, как заявлено, или написать свое). Системы, построенные методом тыка, и работают, как попало — тут вы никакой Америки не открыли, капитан.
«Гы-гы хрень какайто нук тыкни суды чо будит» — типичный технарь-стайл говночистов по компьютерам (может быть, это в самом деле и не так, но я сужу по тому, что вы написали). И вы пишете так, как будто это нормально и неизбежно. Я тысячу раз видел, как люди ругали инструменты и пытались методом тыка что-нибудь «порезолвить» из-за собственных «кривых рук» и превратного восприятия.
QMediaPlayer::seekable() что возвращала? Если false, все ок, все по документации. Где написано, что любой media source можно прокручивать? Там еще seekableChanged() есть (заметили ее вообще?), что как бы намекает нам, что media source может совершенно внезапно стать/перестать быть seekable, и библиотека вас уведомит, когда это произойдет.
«OpenGL? Не, не слышал!»
Года три назад я себе представить не мог, что увижу такое на хабре.
Года три назад я себе представить не мог, что увижу такое на хабре.
Все не так уж плохо, все таки мы не работы и для нас не так важно работает ли тот или иной прибор или программа «прям так как задумано» или чуть иначе, понимание «на 100%» важно если например это управление лифтом\самолетом\медицинским оборудованием, а для прикладного софта или сайтов это не так уж и критично. К примеру у меня есть приложение, в котором ошибки возникают постоянно, это особенность архитектуры (так было задумано изначально), но это не мешает ей исполнять свое предназначение и более того, никто это даже не заметит, так что ИМХО даже в случае наступления сингулярности люди просто примут ее как должное и будут «привыкать» к тому что есть.
Один мой приятель, работавший когда-то администратором БД в центре авторизации банковских карточек, все держит наликом и всегда сразу снимает всю З/П со своей карточки.
Где живет приятель, говорите? Ваш приятель, раз так делает, оценил риски хранения нала дома и стоимости этой процедуры (по сравнению с рисками на счету в банке)? Если нет, то ваш приятель, простите, глупец обыкновенный (если не сказать грубее). А если да, было бы любопытно посмотреть на его соображения. Не попросите его поделиться?
мой приятель живет в Москве, соответственно, и речь о ней. Мы ему тоже говорили о «рисках», рассчитывали какие-то вероятности на пальцах и, что он, конечно, глупец (как минимум), что его домашняя «банковская» система хранения смехотворна, но это не оказывало ровным счетом никакого влияния, он упрямо продолжал месяц за месяцем снимать шанежки, и нам советовал поступать также, а скептикам говорил с ухмылкой «ну-ну». Что именно его так потрясло я не знаю, это не моя область. В итоге, он накопил и купил квартиру в МСК, без всякого кредита. Вот такие дела, молодой человек. Мир полон странными людьми, но за несколько лет совместной работы с бышим админом БД из центра авторизации, я сам теперь иногда задумываюсь о «ну-ну», стоя перед АТМкой. Удачей ;)
мой приятель живет в Москве
У вас что-то с чуством юмора случилось. Я спрашивал адрес квартиры, где деньги лежат.
В итоге, он накопил и купил квартиру в МСК, без всякого кредита.
Это тут вообще при чем? Если бы деньги лежали на депозитах, он бы накопил еще быстрее. При стоимости квартир в Москве, он бы в районе миллиона в год только процентов имел.
Но история больше на сказку похожа. Сдается мне, либо вы нам лапшу на уши вешаете, либо ваш приятель вам. С зарплатой админа копить на мало мальски приличную квартиру в Москве нужно лет 10, как минимум. За это время половину денег, лежащих под подушкой, просто сожрет инфляция. Именно для борьбы с этой самой инфляцией и берется ипотека или деньги вкладываются в инструменты с доходностью выше оной.
В общем, ваш приятель везучий глупец-сказочник. Почитайте сводки по квартирным кражам и задумайтесь про ошибку выжившего (погуглите, что это такое), стоя следующий раз перед АТМ-кой.
Почему-то вспомнился диалог, переданный мне моим бывшим непосредственным начальником (нет, начальник наверно никуда не делся — это я поменял работу)
посредственный начальник: — И чтоб через 3 месяца было готово!
непосредственный начальник: — Мы не сможем обрабатывать абсолютно все записи — и будем терять по миллиону в квартал на недовыставленных счетах
посредственный начальник: — Плевать, мы платим 3 миллиона в квартал за аренду софта, который выставляет все счета правильно
посредственный начальник: — И чтоб через 3 месяца было готово!
непосредственный начальник: — Мы не сможем обрабатывать абсолютно все записи — и будем терять по миллиону в квартал на недовыставленных счетах
посредственный начальник: — Плевать, мы платим 3 миллиона в квартал за аренду софта, который выставляет все счета правильно
Благодаря информационным технологиям, которые очень глубоко проникли в нашу жизнь, мир, конечно, не рухнет, и программисты его не погубят. Мир изменится.
Технологии, за которыми всё труднее угнаться и полностью постичь хотя бы одну из них, — это порождение коллективного разума, которое живёт своей жизнью, обладает своими механизмами саморегуляции.
Стремительная метаморфоза из постиндустриального в информационно-ориентированный уклад жизни действительно выглядит как крах фундаментальных устоев, но это далеко не первая «революция» которую переживает человеческое сознание.
И как предлагал Платон довериться «человеку-познающему», сейчас настало время довериться «технологии-развивающейся». Рынок и коллективный разум естественным образом будет поддерживать только правильные технологии, наиболее актуальные и развитые.
И хоть каждому отдельному специалисту и тяжело с пониманием технологии в целом (хотя это и не означает, что не надо профессионально развиваться), человеческое сообщество и наш уклад жизни сейчас действует как своеобразный инкубатор: питательная (для развития) и в меру агрессивная (для естественного отбора) среда, в которой происходит процесс эволюции информационных технологий.
Технологии, за которыми всё труднее угнаться и полностью постичь хотя бы одну из них, — это порождение коллективного разума, которое живёт своей жизнью, обладает своими механизмами саморегуляции.
Стремительная метаморфоза из постиндустриального в информационно-ориентированный уклад жизни действительно выглядит как крах фундаментальных устоев, но это далеко не первая «революция» которую переживает человеческое сознание.
И как предлагал Платон довериться «человеку-познающему», сейчас настало время довериться «технологии-развивающейся». Рынок и коллективный разум естественным образом будет поддерживать только правильные технологии, наиболее актуальные и развитые.
И хоть каждому отдельному специалисту и тяжело с пониманием технологии в целом (хотя это и не означает, что не надо профессионально развиваться), человеческое сообщество и наш уклад жизни сейчас действует как своеобразный инкубатор: питательная (для развития) и в меру агрессивная (для естественного отбора) среда, в которой происходит процесс эволюции информационных технологий.
Не все так просто. Когда дерево растет, развивается и прогрессирует оно неизбежно движется к смерти: ведь его ветви больше, тяжелее и у них больше парусность. Придет сильный ветер и завалит большое дерево. Прогресс — это движение к смерти. Когда человек смертельно болен говорят, что болезнь прогрессирует. Когда человеческий прогресс шагает по планете — он двигает нас к катастрофе.
Неразумное африканское племя не может нарушить биобаланс планеты, но разумные европецы и американцы — вполне могут, обладают технологиями сжигания топлива в непомерных количествах и всякими ЯО. Кто больше всего генерирует мусора? Думаю именно экономически развитые цивилизации и государства.
Все, что человек делает за свою жизнь — приближает крах.
Даже человек с профессией «учитель», развивая интерес к знаниям у учеников не безвреден. Вот выучится кто-то любознательный под влиянием хорошего учителя и изобретет какое нибудь «мюонное топливо», военные из него как водится сделают бомбу и испытают ее.
Программисты, находясь на передовой всяких научных исследований приближают конец прогресса.
Прогресс движется вверх не линейно, а в квадрате или в кубе от пройденного времени.
Остановить это к сожалению или к счастью нельзя, как нельзя сказать дереву «не расти».
Неразумное африканское племя не может нарушить биобаланс планеты, но разумные европецы и американцы — вполне могут, обладают технологиями сжигания топлива в непомерных количествах и всякими ЯО. Кто больше всего генерирует мусора? Думаю именно экономически развитые цивилизации и государства.
Все, что человек делает за свою жизнь — приближает крах.
Даже человек с профессией «учитель», развивая интерес к знаниям у учеников не безвреден. Вот выучится кто-то любознательный под влиянием хорошего учителя и изобретет какое нибудь «мюонное топливо», военные из него как водится сделают бомбу и испытают ее.
Программисты, находясь на передовой всяких научных исследований приближают конец прогресса.
Прогресс движется вверх не линейно, а в квадрате или в кубе от пройденного времени.
Остановить это к сожалению или к счастью нельзя, как нельзя сказать дереву «не расти».
«Сколько недо-продуктов будет нас окружать?»
Так уже.
Домашний компьютер, Windows 10: выдает тихий звук. Переустановка драйвера возвращает звук в норму. На следующий день опять тихо.
IDE Eclipse for Java Developers: раз в несколько дней зацикливается, приходится убивать процесс.
Лифт в здании, где я работаю: иногда отказывается везти на 4 этаж.
Накачал музыкальных обучающих программ — ни одна не работает как следует.
Так уже.
Домашний компьютер, Windows 10: выдает тихий звук. Переустановка драйвера возвращает звук в норму. На следующий день опять тихо.
IDE Eclipse for Java Developers: раз в несколько дней зацикливается, приходится убивать процесс.
Лифт в здании, где я работаю: иногда отказывается везти на 4 этаж.
Накачал музыкальных обучающих программ — ни одна не работает как следует.
>IDE Eclipse for Java Developers: раз в несколько дней зацикливается, приходится убивать процесс.
Он так себя уже лет 15 ведёт. ;-)
Он так себя уже лет 15 ведёт. ;-)
ИМХО, NetBeans лучше… Или просто мне привычнее…
> NetBeans лучше… Или просто мне привычнее…
«История этой IDE началась в далеком 1995 году. В 2000 году она перешла в руки Sun, а в 2009 году Oracle забрала ее вместе с Java в рамках сделки с Sun.
И вот теперь Oracle один за другим отказывается от проектов, перешедших ей от Sun: OpenSolaris, технологии виртуализации, OpenOffice. Выпуск новой версии самого главного продукта, Java, постоянно переносится. Настал черед и NetBeans. Среда разработки, впрочем, не брошена на произвол судьбы — как сообщается в блоге Apache, теперь проектом будет заниматься именно эта компания.
На самом деле такой исход был вполне ожидаем. Популярность NetBeans медленно, но верно падала — битву за право называться универсальной IDE NetBeans проиграла, уступив место Eclipse.
Остается лишь надеяться, что Apache Foundation серьезно отнесется к попавшему в ее руки продукту и не позволит ему исчезнуть совсем.»
«История этой IDE началась в далеком 1995 году. В 2000 году она перешла в руки Sun, а в 2009 году Oracle забрала ее вместе с Java в рамках сделки с Sun.
И вот теперь Oracle один за другим отказывается от проектов, перешедших ей от Sun: OpenSolaris, технологии виртуализации, OpenOffice. Выпуск новой версии самого главного продукта, Java, постоянно переносится. Настал черед и NetBeans. Среда разработки, впрочем, не брошена на произвол судьбы — как сообщается в блоге Apache, теперь проектом будет заниматься именно эта компания.
На самом деле такой исход был вполне ожидаем. Популярность NetBeans медленно, но верно падала — битву за право называться универсальной IDE NetBeans проиграла, уступив место Eclipse.
Остается лишь надеяться, что Apache Foundation серьезно отнесется к попавшему в ее руки продукту и не позволит ему исчезнуть совсем.»
Однажды лет в 10 я случайно срезал тонкий аккуратный лоскут картофельной кожуры. С тех пор картошку чистил только я :(
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Однажды программисты погубят этот мир