Полностью с вами согласен, особенно если, как я писал выше, все будут знать, что этот робот может тут же «слить» информацию про нарушение ПДД в дорожную полицию. И еще, развивая тему, было бы неплохо, чтобы информация пусть даже не про нарушения, а просто про агрессивное вождение и прочие нерегламентируемые правилами лихачества «сливалась» также страховщикам и другим заинтересованным организациям. Чтобы например стоимость мед страховки, страховки авто или кредита на машину для лихачей была выше.
С 2 февраля 2009 года максимальный штраф за демонстративное нарушение дистанции (drängeln) составляет 400 евро (ранее — 250 евро). Контроль за соблюдением дистанции на автобанах осуществляется с помощью специальных патрульных автомобилей, ничем в общем потоке не отличающихся, но оборудованных видеокамерами и специальными измерительными приборами. Оспорить эти доказательства практически невозможно.
Хотел бы я посмотреть как вы будете объяснять немецкому дорожному полисмену в такой ситуации, что не можете выучить какую-то там «трёхмерную таблицу».
Я считаю, что в ПДД должны быть прописаны более конкретные формулировки, пусть не на все случаи жизни, но хотя бы про минимальные дистанции, интервалы и т.д. и т.п. И чтобы подобные видео можно было бы отправлять в полицию не только автоматически с робомобилей, но и простым гражданам с обычных видеорегистраторов, со всеми вытекающими для нарушителей последствиями! Потому что есть ситуации скажем так дискуссионные, а есть наглые нарушения ПДД, за которые надо отвечать.
Т.к. робомобили уже снабжены кучей камер — надо в их ПО встроить систему автоматичекой фиксации нарушений ПДД с последующей передачей этих фото и видео данных в соотв. отдел дорожной полиции для выписки штрафов. Сами машины снабдить соотв. маркировкой с предупреждением о том, что ведется автофиксация ПДД и тогда любой деятель, который захочет перестроится с несоблюдением дистанции или как-то еще нарушить ПДД — хорошенько подумает о возможном штрафе. И ситуаций когда робомобилям надо будет «понимать» лихачей или слоупоков — резко поубавится!
в первой строке функции, чтобы уж совсем красиво было, вместо Null-коалесцентного оператора лучше сделать приведение типа входного $params к объекту, а то вдруг там массив или еще что вместо stdClass:
function showWarning($params = null) {
$params = (object) $params; // если отсутствуют входные параметры
$width = $params->width ?? 200; // если не указана width, то width = 200
$height = $params->height ?? 100; // если нет height, то height = 100
$title = $params->title ?? "Предупреждение";
$contents = $params->contents ?? "Ничего серьезного.";
//...
}
function showWarning(opts) {
var opts = opts || {}; // если отсутствуют входные параметры
var width = opts.width || 200; // если не указана width, то width = 200
var height = opts.height || 100; // если нет height, то height = 100
var title = opts.title || "Предупреждение";
var contents = opts.contents|| "Ничего серьезного.";
//...
}
В PHP приходится платить разработкой структуры входных/выходных аргументов в отдельных классах. В основном получается муторно, но иногда — весело.
Судя по примеру на JS — вас не волнует, что там реально предается в opts, тогда вместо ваших «отдельных классов» просто используйте в PHP для тех же целей stdClass что-то типа такого:
$params = new \stdClass;
$params->width = $x;
$params->height = $y;
function showWarning($params = null) {
$params = $params ?? new \stdClass; // если отсутствуют входные параметры
$width = $params->width ?? 200; // если не указана width, то width = 200
$height = $params->height ?? 100; // если нет height, то height = 100
$title = $params->title ?? "Предупреждение";
$contents = $params->contents ?? "Ничего серьезного.";
//...
}
Как я понимаю — этот пост является рерайтом вот этой статьи: https://vc.ru/p/yamaha-story.
Кстати всем желающим узнать, что было дальше и не ждать «to be continued…» от автора поста — рекомендую прочитать вышеуказанную статью на ЦП.
ошибся, вместо:
каждый конкретный замок Может быть только на одной конкретной Двери
следует читать:
каждый конкретный Замок может быть только на одной конкретной Двери
Как по мне, то было бы здорово чтобы все выглядело примерно так:
Есть Некто, кто хочет получить Доступ в Помещение открыв Дверь Ключом.
По логике Дверь не может вести в несколько Помещений, т.е. если Некто откроет одну конкретную Дверь он попадет в одно конкретное Помещение, значит про Помещение вообще не стоит упоминать в этом действии. Далее на Двери может быть несколько Замков в разных состояниях открытости, но каждый конкретный замок Может быть только на одной конкретной Двери. Т.o. если Некто откроет один конкретный Замок одним конкретным Ключом, то при условии, что все остальные Замки на этой двери открыты — он откроет эту Дверь и попадет в Помещение.
Т.е. все, что нужно этому объекту Некто — это отправить сообщение Открыть объекту Ключу с параметром Замок для получения объекта Доступ. Назвать этот метод можно например получить_доступ_в_помещение. Объект Доступ будет знать про какое Помещение и через какую Дверь на основании данных из Замка.
Так никто и не упрекает за экономию. Просто надо называть вещи своими именами:
дискриминация «стариков» по возрасту = экономия на зарплате «умных молодых»
а точнее «развод» «молодых» за счет их неопытности, наивности, раздутого ЧСВ и т.д. т.п.
При этом «молодые» имеют квалификацию не хуже чем у «стариков» и особо не косячат, просто они пока не знают своей реальной цены, а когда по прошествии лет наконец начинают понимать эту цену — сами становятся невыгодными «стариками» :)
Так было, так есть и так будет — главное понимать это и делать соотв. выводы как «молодым» так и «старикам». «Старик» из статьи сделал, т.к. несколько раз соглашался на новом месте на зарплату меньше предыдущей, хоть и пытается это прикрыть пафосным бредом вроде:
Спокойно идите на снижение зарплаты ради получения новых возможностей.
…
Я оставлял рабочее место, потому что не видел для себя возможности профессионального роста на занимаемой должности. Я также отказывался от мест с высокой зарплатой, когда чувствовал, что они помешали бы моему профессиональному развитию.
самое грустное, что ни слова о главном — о том, что с «умными молодыми» из-за их наивности за их вполне себе стоящие идеи, предложения и существенный вклад в развитие бизнеса всяким «цукербергам» гораздо проще рассчитываться с ними подобной лабудой (картинку можно открыть крупнее):
эти т.н. «умные молодые» гораздо легче ведутся на всякий там «корпоративный дух» и прочую чушь, в то время как более опытные «старички» предпочитают за то же самое получать что-то более материальное!
разработчикам нужно больше концентрировать внимание на реализации новых фич для пользователей, нежели на постоянном исправлении ошибок
Ну тогда бизнесу следует определиться — что ему надо на начальном этапе разработки: бажный, но «дешевый» по всем параметрам MVP, слепленный на скорую руку для тестирования бизнес-идей, или тщательно спроектированный продукт с продуманной архитектурой?
Вот не было в моем опыте такого, когда бизнес положительно протестировав идеи на MVP, выкинул его в мусор и предложил разработчикам сделать на основе этого удачного MVP качественный продукт с нуля. Всегда просят добавлять новые фичи именно в первоначальный глючный MVP.
А если совсем просто, то laravel использует компонент Symfony Process, который основан на proc_open. Этой PHP командой для каждого зарегистрированного задания (в терминах laravel — команды) запускается отдельный процесс PHP, в котором опять-таки отрабатывает код laravel, который наконец-то выполняет собственно код команды.
Я рефакторил легаси код с кучей eval и знаком с проблемой не понаслышке!
Даже если в коде будет всего один eval, использующийся для выполнения различных кусков кода из БД и прочих источников данных, недоступных для анализатора IDE — это уже «ад» для того, кто будет с этим кодом работать после автора.
Все ваши проблемы можно решить с помощью уже давно реализованных в PHP замыканий! Но при этом разобраться с кодом стороннему разработчику в своей IDE будет в разы проще, и исчезнут проблемы с которых началась эта ветка.
Хотел бы я посмотреть как вы будете объяснять немецкому дорожному полисмену в такой ситуации, что не можете выучить какую-то там «трёхмерную таблицу».
Кстати всем желающим узнать, что было дальше и не ждать «to be continued…» от автора поста — рекомендую прочитать вышеуказанную статью на ЦП.
каждый конкретный замок Может быть только на одной конкретной Двери
следует читать:
каждый конкретный Замок может быть только на одной конкретной Двери
Есть Некто, кто хочет получить Доступ в Помещение открыв Дверь Ключом.
По логике Дверь не может вести в несколько Помещений, т.е. если Некто откроет одну конкретную Дверь он попадет в одно конкретное Помещение, значит про Помещение вообще не стоит упоминать в этом действии. Далее на Двери может быть несколько Замков в разных состояниях открытости, но каждый конкретный замок Может быть только на одной конкретной Двери. Т.o. если Некто откроет один конкретный Замок одним конкретным Ключом, то при условии, что все остальные Замки на этой двери открыты — он откроет эту Дверь и попадет в Помещение.
Т.е. все, что нужно этому объекту Некто — это отправить сообщение Открыть объекту Ключу с параметром Замок для получения объекта Доступ. Назвать этот метод можно например получить_доступ_в_помещение. Объект Доступ будет знать про какое Помещение и через какую Дверь на основании данных из Замка.
Некто.получить_доступ_в_помещение(Ключ, Открыть, Замок)
Вопрос, что я делаю не так?
- дискриминация «стариков» по возрасту = экономия на зарплате «умных молодых»
а точнее «развод» «молодых» за счет их неопытности, наивности, раздутого ЧСВ и т.д. т.п.При этом «молодые» имеют квалификацию не хуже чем у «стариков» и особо не косячат, просто они пока не знают своей реальной цены, а когда по прошествии лет наконец начинают понимать эту цену — сами становятся невыгодными «стариками» :)
Так было, так есть и так будет — главное понимать это и делать соотв. выводы как «молодым» так и «старикам». «Старик» из статьи сделал, т.к. несколько раз соглашался на новом месте на зарплату меньше предыдущей, хоть и пытается это прикрыть пафосным бредом вроде:
эти т.н. «умные молодые» гораздо легче ведутся на всякий там «корпоративный дух» и прочую чушь, в то время как более опытные «старички» предпочитают за то же самое получать что-то более материальное!
Вот не было в моем опыте такого, когда бизнес положительно протестировав идеи на MVP, выкинул его в мусор и предложил разработчикам сделать на основе этого удачного MVP качественный продукт с нуля. Всегда просят добавлять новые фичи именно в первоначальный глючный MVP.
то дальше объяснять вам недостатки eval — бессмысленно!
Даже если в коде будет всего один eval, использующийся для выполнения различных кусков кода из БД и прочих источников данных, недоступных для анализатора IDE — это уже «ад» для того, кто будет с этим кодом работать после автора.
Все ваши проблемы можно решить с помощью уже давно реализованных в PHP замыканий! Но при этом разобраться с кодом стороннему разработчику в своей IDE будет в разы проще, и исчезнут проблемы с которых началась эта ветка.