Ну с одной стороны вроде как бы и согласен, а с другой стороны с засильем Андроида (iOS как закрытую, можно вообще не упоминать) тоже надо что-то делать. У китайцев, в отличие от всяких Sailfish, Taizen, WebOS и т.д и т.п. хотя бы есть большой внутренний рынок за счет которого они вполне могут раскрутиться и таки выйти в конкурентно-способные объемы.
Для нас тут преимущества очевидны прежде всего с точки зрения санкций. Хоть Андроид и вроде как-бы открытая система, но сейчас слишком много приложений хотят GMS, а HMS доступен опять-же только у того-же Хуавея...
Описаный вами сценарий хоть и реальный в теории, но слишком маловероятный на практике. Во-первых, можно как и с картами ограничивать верхнюю сумму платежа без пинкода. Во-вторых, можно навернуть чего-нибудь еще для безопасности.
Например:Сканирум QR-код с кассы и формируем "ответный" QR код для платежа. Смысла его угонять 0. И хотя это немного усложняет оплату, но гораздо лучше онлайна.
Можно придумать еще какаие-то меры.
Текущая имплементация на мой взгляд сложилась по 2-м причинам:
1) Во-первых так было проще разработчикам системы, и им было плеать по большому счету на пользователей.
2) Когда все это внедрялось им было важней быстро разработать работающую систему "для себя", чем общие стандарты "для всех", как это сделано с тем-же NFC.
Ну и было бы интересно, когда наоборот - когда уже сам покупатель QR на экране телефона формирует "вот мой платеж", а камера у магазина его считывает. Тогда бы постоянной связи на телефоне можно было не требовать.
Кстати да, отличная идея. Все существующие кассы уже умеют читать QR-коды. Остается только продумать security как следует и было-бы отличное решение, а не как сейчас, когда после сканирования кода человек бежит к выходу из полу-подвального помещения поймать интернет...
И ничего страшного! "Сдвигаем" этот "пароль" на следующие буквы и вуаля. Я так и делал (паттерн был конечно другой, но смысл тот-же...) в одной тупой компании где заставляли менять пароль каждый месяц с невозможностью использования n старых. Я честно говоря не представляю на каких киборгов рассчитаны такие политики. Одно дело придумать хороший, стойкий пароль раз в 3-6 месяцев, и другое дело каждый месяц...
Только недавно перестал пользоваться iPad, незнаю точно какой именно серии, покупали 10 лет назад. Основных причин почему перестал пользоваться было две:
1) Батарейка уже практически не держит заряд
2) Последние обновления системы "съели" львиную долю памяти (iPad был на 16Гб).
До того как батарейка померла практически окончательно планшет был по сути "консолью для одной игры", поскольку ни на что большее памяти просто не хватало.
Как говорится "это зависит". Тут недавно была статья про Rust в геймдеве, так автор очень сильно плакался о том, что т.к. Rust очень хочет выловить максимум возможных ошибок, то он требует делать слишком много телодвижений в случае некоторых изменений, когда программисту нужно "побыстрому запрототипировать".
Т.е. в тот момент когда "лучше возможно с ошибками, но быстренько попробовать", Rust говорит, типа "нет милок, ты захотел сделать вот так, тогда давай зарефактори мне половину кода, чтобы я был точно уверен что ты нигде не накосячил".
Именно. Встроенные функции хороши только когда надо что-то сделать со всем контейнером. Не спорю, это составляет львиную долю использований. Но! Что если надо искать не с 0-го элемента, а с 1-го или не до последнего, а до предпосленего. И т.д. и т.п. Так что делать тупую встроенную функцию в которую не надо передавать begin()/end() - это по сути шаг назад.
Вообще уже довольно давно существует std::string_view - являющйся по сути полным эквивалентом char *, но в то-же время являющийся классом. Но и с ним, есть проблеммы...
Проблема "За пол часа делается прекрасный десктопный GUI." заключается в том, что как только мы меняем системный фонт или DPI экрана или еще какие-нибудь параметры, которые влияют на рендеринг и различаются на компьютере пользователя и компьютере разработчика, то из "прекрасного" GUI превращается в "ужасный".
На старом Windows эта проблема была практически незаметна, тупо потому что у 99% пользователей стояли стандартные настройки и все было хорошо. А вот с тем-же web-ом так уже не получается.
Если не считать требование к фичи, которые как-бы по умолчанию должны быть раньше кода, то по моему опыту писать документ вместо кода в подавляющем большинстве случаев малопродуктивно.
Потому что документ, в отличии от кода, невозможно отладить, протестировать и т.д. и т.п. И когда заставлют писать, скажем дизайн перед кодом, то получается, что придумали какой-то более менее рабочий дизайн, написали документ, пошли писать код и столкнулись с какой-то проблемой. Код правится чтобы обойти эту проблему, на дизайн все уже забили, он же уже написан!. и в результате дизайн не отражает код и в таком виде практически не имеет никакой ценности.
Возможно, если вместо текста использвоать какие-то специальные инструменты (ну например, пример из головы, какой-нибудь анализатор SQL запросов), то это могло бы быть эффективней написание кода, но простой текст и/или диаграмки все-же не тянут.
На эту тему недавно здесь на хабре была статейка в которой предлагалась писать дизайн на некотором формализованном языке и "тестировать" ее относительно кода, вот в таком подходе возможно было-бы все лучше, но и то я думаю написать хороший дизайн перед написанием когда целиком никогда не получится, максимум итеративный подход, когда на первой итерации прикидываем какой-то подход, пробуем его закодировать, вылавливаем проблеммы, исправляем паралелльно дизайн и код. И чтобы документ реально исправлялся нужны автоматические инструменты, типа "тестов" соответсвия дизайна-кода, иначе нельзя быть уверенным, что дизайн актуален.
Мне кажется вы перепутали документацию "о программе" и требования "к программе". Хотя чисто формально требования и можно считать документацией, но на смом деле они практически ничего вам не скажут о программе. 10 программистов получив одни и те-же требоваия напишут 10 разных программ.
А вот когда идет речь про документацию "о программе": дизайн, описание интерфеса, user manual тот-же самый и т.п., то это уже реально "выдержка из комментариев", плюс в 99% случаях не соответсвует реальной программе, т.к. код првится часто (баги-то надо править), а документация только когда прижмет.
Для автопилотов низкого уровня вы безусловно правы. Я если честно вообще не понимаю зачем оно надо, ну кроме разьве что хоть как-то отбить инвестиции во всю эту историю... Со всех остальных точек зрения глупость сплошная.
А вот для полного автопилота уже все по-другому. Всяким агрегаторам такси, перевозчикам грузов и т.д. и т.п. гораздо выгодней потратиться один раз на автопилот, чем постоянно платить водителям зарплату.
Потому что в C/C++ все функции - это функции. Тавталогия да. Я это к чему: если назвать этот класс функций просто функциями, то как понять о каких функциях идет речь? А так выделили "функции реализующие стандартные алгоритмы обработки информации" в отдельный "модуль", назвали его "алгоритмы" и всем сразу понятно о чем речь.
Для меня это немного больная тема, т.к. у нас в одном легаси проекте какие-то умники сделали класс Function, от которого наследуются "функции", которые рализуют БЛ. И вот очень блин все время выбешивает когда надо эти классы как-то обозвать...
И здесь создается впечатление, что закон ориентируется в первую очередь на бум беспилотных авто в бизнесе, а не частном секторе.
И это логично. Как только все составляющие (техническая, юридическа, моральная и .т.д.) "сойдутся". То частных владельцев будут выдавливать со страшной силой, потому что они никому, кроме производителей автомобилей, нафиг не упали.
Техническая грамотность "специалистов" поражает. Не могу ничего сказать насчет Apple, разумееется, а вот на Android-е "механизм блокировки краденных устройств" действует с точностью до наоборот от описанного "специалистом", т.е. блокирует телефон именно после перепрошивки. А если речь идет о функции "Find my phone", которой в том числе можно блокировать телефон, так ее несложно выключить на телефоне в настройках и никакой блокировки...
На мой взгляд критика с одной стороны справедливая, потому что "по сути" все так и есть и все перечисленные недостатки присутсвуют.
Но с другой стороны, не совсем корректная, т.к. очевидно, что человек применил свой подход именно в той предметной области и к тем проектам с которыми он работает, и ввел ограничения удобные именно для его ситуации. Сразу строить систему которая бы охватывала все возможные случаи и подходила бы всем и каждуому было-бы невозможно чисто по временным и техническим (надо на чем-то это все тоже тестировать!) причинам.
Тут скорее тем кому не подходит это решение в лоб нужно творчески подойти к вопросу и если можно так выразиться провести "рефакторинг", чтобы расширить возможности применения этой идеи.
Ну с одной стороны вроде как бы и согласен, а с другой стороны с засильем Андроида (iOS как закрытую, можно вообще не упоминать) тоже надо что-то делать. У китайцев, в отличие от всяких Sailfish, Taizen, WebOS и т.д и т.п. хотя бы есть большой внутренний рынок за счет которого они вполне могут раскрутиться и таки выйти в конкурентно-способные объемы.
Для нас тут преимущества очевидны прежде всего с точки зрения санкций. Хоть Андроид и вроде как-бы открытая система, но сейчас слишком много приложений хотят GMS, а HMS доступен опять-же только у того-же Хуавея...
Некоторые фразы сломали мой мозг. Типа:
Какое отношение Bluetooth имеет к Huawei Pay? Нет, может и имеет, но далекому от Huawei человеку это не очевидно.
У нас операционки теперь в человеках считают? Прикалываюсь конечно, но какое-то слово тут пропущено, то-ли "разработчиков", то-ли "потребителей".
И пара замечаний:
Очень сомнительно, тогда они вряд-ли бы отказались и от Андрода.
Да, вот только это будут китайские программы. Так что какие перспективы с остальными рынками, и в частности с Россией, не совсем понятно...
Описаный вами сценарий хоть и реальный в теории, но слишком маловероятный на практике. Во-первых, можно как и с картами ограничивать верхнюю сумму платежа без пинкода. Во-вторых, можно навернуть чего-нибудь еще для безопасности.
Например:Сканирум QR-код с кассы и формируем "ответный" QR код для платежа. Смысла его угонять 0. И хотя это немного усложняет оплату, но гораздо лучше онлайна.
Можно придумать еще какаие-то меры.
Текущая имплементация на мой взгляд сложилась по 2-м причинам:
1) Во-первых так было проще разработчикам системы, и им было плеать по большому счету на пользователей.
2) Когда все это внедрялось им было важней быстро разработать работающую систему "для себя", чем общие стандарты "для всех", как это сделано с тем-же NFC.
Кстати да, отличная идея. Все существующие кассы уже умеют читать QR-коды. Остается только продумать security как следует и было-бы отличное решение, а не как сейчас, когда после сканирования кода человек бежит к выходу из полу-подвального помещения поймать интернет...
И ничего страшного! "Сдвигаем" этот "пароль" на следующие буквы и вуаля. Я так и делал (паттерн был конечно другой, но смысл тот-же...) в одной тупой компании где заставляли менять пароль каждый месяц с невозможностью использования n старых. Я честно говоря не представляю на каких киборгов рассчитаны такие политики. Одно дело придумать хороший, стойкий пароль раз в 3-6 месяцев, и другое дело каждый месяц...
Только недавно перестал пользоваться iPad, незнаю точно какой именно серии, покупали 10 лет назад. Основных причин почему перестал пользоваться было две:
1) Батарейка уже практически не держит заряд
2) Последние обновления системы "съели" львиную долю памяти (iPad был на 16Гб).
До того как батарейка померла практически окончательно планшет был по сути "консолью для одной игры", поскольку ни на что большее памяти просто не хватало.
And we all know what happened then: https://blog.gitguardian.com/yes-github-copilot-can-leak-secrets/
Just NO. Except for open source it doesn't have any sense to handover control of YOUR code to someone else.
Как говорится "это зависит". Тут недавно была статья про Rust в геймдеве, так автор очень сильно плакался о том, что т.к. Rust очень хочет выловить максимум возможных ошибок, то он требует делать слишком много телодвижений в случае некоторых изменений, когда программисту нужно "побыстрому запрототипировать".
Т.е. в тот момент когда "лучше возможно с ошибками, но быстренько попробовать", Rust говорит, типа "нет милок, ты захотел сделать вот так, тогда давай зарефактори мне половину кода, чтобы я был точно уверен что ты нигде не накосячил".
Именно. Встроенные функции хороши только когда надо что-то сделать со всем контейнером. Не спорю, это составляет львиную долю использований. Но! Что если надо искать не с 0-го элемента, а с 1-го или не до последнего, а до предпосленего. И т.д. и т.п. Так что делать тупую встроенную функцию в которую не надо передавать begin()/end() - это по сути шаг назад.
Вообще уже довольно давно существует
std::string_view- являющйся по сути полным эквивалентомchar *, но в то-же время являющийся классом. Но и с ним, есть проблеммы...Проблема "За пол часа делается прекрасный десктопный GUI." заключается в том, что как только мы меняем системный фонт или DPI экрана или еще какие-нибудь параметры, которые влияют на рендеринг и различаются на компьютере пользователя и компьютере разработчика, то из "прекрасного" GUI превращается в "ужасный".
На старом Windows эта проблема была практически незаметна, тупо потому что у 99% пользователей стояли стандартные настройки и все было хорошо. А вот с тем-же web-ом так уже не получается.
А в чем новость? Помоему винда уже больше года пытается при каждом обновлении "подсадить" на облачную учетку...
Если не считать требование к фичи, которые как-бы по умолчанию должны быть раньше кода, то по моему опыту писать документ вместо кода в подавляющем большинстве случаев малопродуктивно.
Потому что документ, в отличии от кода, невозможно отладить, протестировать и т.д. и т.п. И когда заставлют писать, скажем дизайн перед кодом, то получается, что придумали какой-то более менее рабочий дизайн, написали документ, пошли писать код и столкнулись с какой-то проблемой. Код правится чтобы обойти эту проблему, на дизайн все уже забили, он же уже написан!. и в результате дизайн не отражает код и в таком виде практически не имеет никакой ценности.
Возможно, если вместо текста использвоать какие-то специальные инструменты (ну например, пример из головы, какой-нибудь анализатор SQL запросов), то это могло бы быть эффективней написание кода, но простой текст и/или диаграмки все-же не тянут.
На эту тему недавно здесь на хабре была статейка в которой предлагалась писать дизайн на некотором формализованном языке и "тестировать" ее относительно кода, вот в таком подходе возможно было-бы все лучше, но и то я думаю написать хороший дизайн перед написанием когда целиком никогда не получится, максимум итеративный подход, когда на первой итерации прикидываем какой-то подход, пробуем его закодировать, вылавливаем проблеммы, исправляем паралелльно дизайн и код. И чтобы документ реально исправлялся нужны автоматические инструменты, типа "тестов" соответсвия дизайна-кода, иначе нельзя быть уверенным, что дизайн актуален.
Мне кажется вы перепутали документацию "о программе" и требования "к программе". Хотя чисто формально требования и можно считать документацией, но на смом деле они практически ничего вам не скажут о программе. 10 программистов получив одни и те-же требоваия напишут 10 разных программ.
А вот когда идет речь про документацию "о программе": дизайн, описание интерфеса, user manual тот-же самый и т.п., то это уже реально "выдержка из комментариев", плюс в 99% случаях не соответсвует реальной программе, т.к. код првится часто (баги-то надо править), а документация только когда прижмет.
Для автопилотов низкого уровня вы безусловно правы. Я если честно вообще не понимаю зачем оно надо, ну кроме разьве что хоть как-то отбить инвестиции во всю эту историю... Со всех остальных точек зрения глупость сплошная.
А вот для полного автопилота уже все по-другому. Всяким агрегаторам такси, перевозчикам грузов и т.д. и т.п. гораздо выгодней потратиться один раз на автопилот, чем постоянно платить водителям зарплату.
Потому что в C/C++ все функции - это функции. Тавталогия да. Я это к чему: если назвать этот класс функций просто функциями, то как понять о каких функциях идет речь? А так выделили "функции реализующие стандартные алгоритмы обработки информации" в отдельный "модуль", назвали его "алгоритмы" и всем сразу понятно о чем речь.
Для меня это немного больная тема, т.к. у нас в одном легаси проекте какие-то умники сделали класс Function, от которого наследуются "функции", которые рализуют БЛ. И вот очень блин все время выбешивает когда надо эти классы как-то обозвать...
И это логично. Как только все составляющие (техническая, юридическа, моральная и .т.д.) "сойдутся". То частных владельцев будут выдавливать со страшной силой, потому что они никому, кроме производителей автомобилей, нафиг не упали.
Техническая грамотность "специалистов" поражает. Не могу ничего сказать насчет Apple, разумееется, а вот на Android-е "механизм блокировки краденных устройств" действует с точностью до наоборот от описанного "специалистом", т.е. блокирует телефон именно после перепрошивки. А если речь идет о функции "Find my phone", которой в том числе можно блокировать телефон, так ее несложно выключить на телефоне в настройках и никакой блокировки...
На мой взгляд критика с одной стороны справедливая, потому что "по сути" все так и есть и все перечисленные недостатки присутсвуют.
Но с другой стороны, не совсем корректная, т.к. очевидно, что человек применил свой подход именно в той предметной области и к тем проектам с которыми он работает, и ввел ограничения удобные именно для его ситуации. Сразу строить систему которая бы охватывала все возможные случаи и подходила бы всем и каждуому было-бы невозможно чисто по временным и техническим (надо на чем-то это все тоже тестировать!) причинам.
Тут скорее тем кому не подходит это решение в лоб нужно творчески подойти к вопросу и если можно так выразиться провести "рефакторинг", чтобы расширить возможности применения этой идеи.