Слухи о невозможности опротестовать транзакцию подтвержденную pin'ом слышу очень часто. А не засветить pin в наших магазинах — это практически нереальная задача.
Оспорить-то можно, вопрос в том, удовлетворят ли.
Вот сперли у вас карточку, купили что-то и расписались левой подписью. Вы транзакцию оспариваете. По идее нужно проводить анализ подписи. А он, по слухам, очень часто выдает что-то в стиле «подлинность подписи определить нельзя».
Или я не прав и оспаривание в такой ситуации происходит по какой-то другой процедуре?
Ну если разработчик одновременно хороший и адекватный, и если речь идет о городе с большим выбором работодателей, то он прекрасно понимает, что может покинуть компанию, как только она перестанет выполнять договоренности. Так что, в худшем случае, он рискует 90% от одной зп. При этом если зп получается значительно больше чем в других местах работы, то это вполне компенсирует риски.
Да, при таком подходе наверное покатит. Правда, насколько я понимаю, чтобы незнание пароля считалось нарушением трудовой дисциплины нужно, чтобы требование знание пароля наизусть было зафиксировано в трудовых обязанностях работника. Что вроде реализуемо.
С другой стороны все это — тонна бюрократии, отчетности и времени непонятно для чего. Проще уж реально внедрить какие-нибудь rsa токены.
Мало кто желает в совокупности рассмотреть проблему безопасности.
Истинно так.
Все эти регулярные смены паролей и абсурдные требования подчас напоминают крепостные ворота в деревянном заборчике в метр высотой. Эдакая непоколебимая уверенность в том, что злоумышленник будет ломиться исключительно в самую защищенную точку системы.
По закону нельзя просто так взять и уменьшить/не выплатить премию. Впрочем увеличить/выплатить просто так тоже нельзя. Согласно 129 ст. ТК РФ премия — это часть заработной платы.
Выплата премий регламентируется либо трудовым договором, либо положением о премировании. И вот в таком документе должно быть отражено за какие заслуги премия платится и в каких количествах. Соответственно, чтобы порезать человеку премию на том основании, что он не помнит свой пароль, нужно как-то фиксировать это требование. И вот как такое требование нормально закрепить в том же положении о премировании или трудовом договоре я хз. Т.е. зафиксировать-то просто, но вот зафиксировать так чтобы суд, в случае тяжбы, не признал такое требование ничтожным — это уже задачка сложнее.
С другой стороны работник, скорее всего, не будет париться и идти в суд (и ждать пару лет решения, ага) чтобы ему выплатили премию.
Мне как-то попалась система, которая требовала пароль с буквами в обоих регистрах, цифрами и спецсимволами длинной от 7 и до 10 символов. В тот раз подход, подобный вашему, впервые дал для меня сбой, так как пароля удовлетворяющего таким требованиям у меня не было.
Мне несколько раз попадались сайты, которые на попытку восстановить пароль ругались, что мой новый пароль отличается от старого всего одним символом. Вот такие вот сумрачные гении попадаются.
Про «великое чудо» — вы меня с кем-то путаете :), я такого не писал. Я лишь указал на статистическую незначимость вашего рассуждения про античных философов.
Насчет лопарей, у вас уже значимый аргумент, тут правда еще можно сыграть на не репрезентативности выборки. Впрочем, в том же источнике чуть ниже дано еще более сильное утверждение — среди всего РСФСР умершие в возрасте 70 лет и старше составили 8% от всех умерших в 1925 году. Вот это уже перекрыть сложно.
Если бы шестидесятилетний старик считался (цитирую) «великим чудом», девяностолетних помнили бы в том числе, если не в первую очередь, за долголетие.
Люди прожившие больше 110 лет даже сейчас невероятная редкость, но они есть. Много вы таких людей поименно знаете? Без гугла пожалуйста.
Поэтому статистически значимых величин вам в этой дискуссии приведут вряд ли
Ну раз значимых данных за данный период у нас нет, то зачем же к нему апеллировать? Если вы хотите кому-то что-то доказать, то обращайтесь к фактам, их, в отличие от домыслов, сложно опровергнуть.
А можно подробнее? А то я что-то такое уже не в первый раз слышу, но реальных примеров за 6 лет не наблюдал. Да и быстрое гугление не выдает чего-то вразумительного.
Практически любой документ со сложной структурой, который есть необходимость править руками. Например конфиги или дескрипторы развертывания. За счет наличия XSD схемы XML легко проверить на валидность. За счет той же XSD во многих IDE работает автодополнение. По XSD можно даже автоматом сгенерить объектную модель.
Если требуется обработка больших объемов XML, то на помощь приходит XSLT и XQuery.
А еще в json нет неймспейсов.
Если же работать с документом как с DOM деревом или мапить его на объекты, то разницы между форматами по сути и нет — все равно всё спрятано за библиотеками.
А насчет HTML:
А вы взгляните на reactjs — там есть virtual dom, который как раз представляет html в виде json. Просто сравните:
<p class="lead">
<span>A JavaScript library for building user interfaces </span>
<a href="http://facebook.github.io/react/">React</a>
</p>
и
{
tag: 'p',
attrs: {className: {'lead': true}},
children: [
{
tag: 'span',
children: 'A JavaScript library for building user interfaces '
},
{
tag: 'a',
attrs: {href: 'http://facebook.github.io/react/'},
children: 'React'
}
]
}
Да, в Java обратную совместимость не нарушали никогда (если конечно не завязывать на недокументированный функционал, типа способа работы String.intern или Unsafe). Поэтому мажорная версия там единичка.
Хорошо это или плохо — спорный вопрос. С одной стороны круто, что код написанный в бородатые времена на Java 1.0 будет работать до сих пор.
А с другой стороны стороны в Java из-за этого висит куча классов с невменяемым API. Например я для всех своих проектов тяну сторонние библиотеки для логирования и парсинга XML, хотя формально все это есть в стандартной библиотеке.
И опять таки, все это относится исключительно к JavaSE. В JavaEE обратную совместимость нарушается, но что-то я не видел чтобы кто-то жаловался что EJB 2.0 не поддерживаются в Java EE 7.
Что-то я вас не пойму.
Весь профит генной модификации как раз в том, что можно выбрать какие характеристики привить. И вот тут можно привить исключительно бесплодие, а можно привить всё кроме неё, создав нечто вроде лошака, но уже способного к размножению. Тут уже всё на совести «производителя».
Слухи о невозможности опротестовать транзакцию подтвержденную pin'ом слышу очень часто. А не засветить pin в наших магазинах — это практически нереальная задача.
Вот сперли у вас карточку, купили что-то и расписались левой подписью. Вы транзакцию оспариваете. По идее нужно проводить анализ подписи. А он, по слухам, очень часто выдает что-то в стиле «подлинность подписи определить нельзя».
Или я не прав и оспаривание в такой ситуации происходит по какой-то другой процедуре?
С другой стороны все это — тонна бюрократии, отчетности и времени непонятно для чего. Проще уж реально внедрить какие-нибудь rsa токены.
Все эти регулярные смены паролей и абсурдные требования подчас напоминают крепостные ворота в деревянном заборчике в метр высотой. Эдакая непоколебимая уверенность в том, что злоумышленник будет ломиться исключительно в самую защищенную точку системы.
Выплата премий регламентируется либо трудовым договором, либо положением о премировании. И вот в таком документе должно быть отражено за какие заслуги премия платится и в каких количествах. Соответственно, чтобы порезать человеку премию на том основании, что он не помнит свой пароль, нужно как-то фиксировать это требование. И вот как такое требование нормально закрепить в том же положении о премировании или трудовом договоре я хз. Т.е. зафиксировать-то просто, но вот зафиксировать так чтобы суд, в случае тяжбы, не признал такое требование ничтожным — это уже задачка сложнее.
С другой стороны работник, скорее всего, не будет париться и идти в суд (и ждать пару лет решения, ага) чтобы ему выплатили премию.
А почему работника должны волновать риски работодателя?
Насчет лопарей, у вас уже значимый аргумент, тут правда еще можно сыграть на не репрезентативности выборки. Впрочем, в том же источнике чуть ниже дано еще более сильное утверждение — среди всего РСФСР умершие в возрасте 70 лет и старше составили 8% от всех умерших в 1925 году. Вот это уже перекрыть сложно.
Люди прожившие больше 110 лет даже сейчас невероятная редкость, но они есть. Много вы таких людей поименно знаете? Без гугла пожалуйста.
Ну раз значимых данных за данный период у нас нет, то зачем же к нему апеллировать? Если вы хотите кому-то что-то доказать, то обращайтесь к фактам, их, в отличие от домыслов, сложно опровергнуть.
Я могу так же привести 3 примера людей, которые жили 116 лет, но из этого не следует, что это что-то обычное.
Если требуется обработка больших объемов XML, то на помощь приходит XSLT и XQuery.
А еще в json нет неймспейсов.
Если же работать с документом как с DOM деревом или мапить его на объекты, то разницы между форматами по сути и нет — все равно всё спрятано за библиотеками.
А насчет HTML:
А вы взгляните на reactjs — там есть virtual dom, который как раз представляет html в виде json. Просто сравните:
и
Хорошо это или плохо — спорный вопрос. С одной стороны круто, что код написанный в бородатые времена на Java 1.0 будет работать до сих пор.
А с другой стороны стороны в Java из-за этого висит куча классов с невменяемым API. Например я для всех своих проектов тяну сторонние библиотеки для логирования и парсинга XML, хотя формально все это есть в стандартной библиотеке.
И опять таки, все это относится исключительно к JavaSE. В JavaEE обратную совместимость нарушается, но что-то я не видел чтобы кто-то жаловался что EJB 2.0 не поддерживаются в Java EE 7.
Весь профит генной модификации как раз в том, что можно выбрать какие характеристики привить. И вот тут можно привить исключительно бесплодие, а можно привить всё кроме неё, создав нечто вроде лошака, но уже способного к размножению. Тут уже всё на совести «производителя».
Вообще многие гибриды не способны к размножению.