В том и дело, что во всех рекламах:
1) что-то липнет, предлагают решение — это же реклама чистящего средства, а не «против грязи». Грязь не обвиняют, грязь — проблема.
2) когда предлагают своё решение, никогда не поливают грязью других (кроме редких «идейных» противостояний типа пепси-кока, айфон-андроид). В 99% (раз вы любите это число) случаев против «правильного» товара противопоставлен «любой другой товар такого типа». То есть «конкурент» — обезличен. Это негласное правило рекламы, но в других сферах за такое могут и засудить.
Вы же вместо озвучивания проблемы говорите «1С делает это плохо, а Фузион — хорошо». При этом вы сравниваете совершенно различные функциональные элементы. Про это вам уже выше писали. Это как показывать калькулятор свой и чужой на примере «2+2=4». И говорить, что ваш калькулятор оптимизирован, а чужой нет, потому что на примере «2+2=4» он работает быстрее и код меньше.
Потому что мы рассматривали ДРУГУЮ ситуацию…
Все, меня уже не хватает. Либо вы тролли, либо действительно не понимаете о чем речь. Но в любом из этих случаев ваш фузион так и закончится на хабре
Так покажите, как реализовывается этот выбор. Вы же просто выдает перл за перлом вместо конкретного ответа.
И постоянные переходы на гиперболу… хорошее и логичное действие.
Дадада, всё у вас удалось. Ни у кого в мире не удавалось, но у вас конечно всё есть.
«В принципе можно реализовать, но по опыту проблема реально сильно надуманна» — а по моему опыту проблема очень даже не надуманная. Хотя, возможно, это результат ошибки выжившего. Вы создаете ПО в текущих реалиях, когда многие пользователи уже «научились» на других программах, что так делать нельзя, поэтому пользовательская грамотность слегка другая. 1С создавалась в других реалиях, когда компьютеры еще были в диковинку, поэтому пользователи намного чаще делали ошибки. Но это не значит, что сейчас надо надеяться на грамотность пользователя. Это ошибка в подходе, которая может больно аукнуться.
«Зачем мучать пользователей на всех процессах» — как вы будете определять, в какой ситуации нужна пессимистичная блокировка, а где оптимистичная?
И вообще, мне надоело, что вы вместо ответов на конкретный вопрос начинаете сами себе задавать вопросы и на них отвечать.
То есть вы решили проигнорировать половину сообщения, описывающую реальную проблему, а ответить в своём стиле…
Мы говорили про необходимость блокировок, когда пользователи «открыли» данные или одновременно их используют. И в примере про «печать» как раз рассматривали ситуацию, когда пользователь сидит в документе, он был изменен, после чего она его печатает (она его не меняла). В этот момент и срабатывает блокировка.
Обратную ситуацию, когда она сначала распечатала, потом кто-то поменял я просто упомянул, но эта ситуация — не та, ради которой устраивается блокировка. Ту ситуацию ни в одной системе нельзя обойти, только организационно.
Вы же вместо ответа на основное сообщение переводите фокус на «ситуацию-исключение», как будто это и было основным вопросом. И отвечаете в своём стиле «это никому не нужно».
Как ваша программа будет определять, когда нужно включать «защиту», а когда не надо?
Ваша аналогия некорректна. IT — достаточно уникальная среда, чтобы не сравнивать ее с простыми «житейскими» ситуациями.
Если пользователь может совершить ошибку — однажды он ее совершит. Задача разработчика ПО — как можно сильнее заблокировать пользователю возможности «совершить ошибку».
Вы же пытаетесь вечно выехать на аналогиях, вместо понимания проблемы, которую вы строите
То есть вы предлагаете заставлять делать пользователей 100 раз одну и ту же работу? Вместо того, чтобы разработчику 1 раз сделать так, чтобы это не приходилось делать?
Еще раз — ваш принцип «пусть сами разбираются» не должен быть основным при разработке массового ПО
Всё просто — это их маркетинговая основа.
Вместо того, чтобы говорить, что в фузион хорошо — они пишут, что в 1С плохо. Причем плохо именно по их «авторитетному» мнению, а почему — потому что «правило Парето» и «это не нужно в 99% случаев».
Потому что если будут пытаться показать достоинства своей программы без унижения других — рассказывать почти не о чем. Да и тяжелее будет переводить критику в полемику типа «а вот в 1С хуже»
Когда ваш эфемерный «1%» будет стоить вам миллионы — может задумаетесь о том, что при разработке ПО пользоваться правилом «Парето» (который обычно берут на вооружение продаваны для впаривания) — непозволительная роскошь.
Прекратите везде пихать «правило Парето», как универсальный аргумент. Вы не понимаете границ его использования, так еще и лихо меняете, то 97%, то 99%. По факту — это просто демагогический приём манипулирования. Так обычно действуют продаваны, когда хотят туфту пихнуть покупателю.
И да, если любите «правило Парето» — полюбите и «закон Мёрфи» — если что-то плохое может произойти — оно обязательно произойдет. Вот этот закон должен быть основой при разработке ПО, в котором крутятся миллионы.
Вы некорректно интерпретируете правило Парето.
Точнее так — вы используете его как универсальный ответ на вопрос «почему не реализовано это» — «а вот по правилу Парето это нужно будет в 1% случаев». К сожалению, при разработке ПО:
1) использовать его нельзя. ПО должно учитывать все возможные ситуации и минимизировать риски пользовательской ошибки при работе. Всегда нужна «защита от дурака»
2) когда люди, руководствуясь правилом Парето в виде «80% пользователей пользуются только 20% функционала» решают реализовать 20% функционала, чтобы получить 80% продаж, они натыкаются на проблему, что каждый пользователь использует РАЗНЫЕ 20% функционала.
Не будет так работать. В большинстве случаев если документ посчитается системой «измененным» — то он потребует перезаписи. А если изменен другим пользователем — то он потребует, чтобы его «перечитали». И тогда Маша увидит измененные данные и печатать будет правильный документ. Рассматривать ситуацию, что сначала Маша распечатала, а потом кто-то этот документ изменил не имеет смысла, потому что это уже не техническая ошибка, а организационная и решается на уровне пользователей, а не программы.
Вы кривите. Сравнение с ГуглДокс некорректно.
В ГуглДокс все видят, кто правит в данный момент какую ячейку. Постоянно. То есть есть информация о том, что кто-то работает в этом документе. В вашей же программе такого не будет.
Так что жду от вас «корректного» примера, где с данными работают без блокировок, как в вашей. Иначе — это «ноу хау» в стиле «пусть сами разгребают».
З.Ы. — безопасность всегда стоит выше эфемерного удобства. Если в системе могут работать десятки человек — без блокировок велик риск, что в один момент они подправят один-другой документ некорректно. И когда это определят и как будут исправлять — песня из матов, сначала в сторону пользователей, ну а как разберутся в чем причина — в вашу сторону.
То есть предлагаете это переложить на плечи пользователей? Интересное решение…
Как раз такую проблему и решает блокировка объекта. И ситуаций, когда она может пригодиться — не счесть. А если все моменты сбрасывать на пользователей — то зачем вообще программа, когда есть Excel?
А если оба пользователя вносят «идентичные» данные в разные строки?
Идея «работать без блокировок» — всегда опасна. Потому что ударить может в любой момент и неизвестно где. И как потом искать неправильные данные.
1) что-то липнет, предлагают решение — это же реклама чистящего средства, а не «против грязи». Грязь не обвиняют, грязь — проблема.
2) когда предлагают своё решение, никогда не поливают грязью других (кроме редких «идейных» противостояний типа пепси-кока, айфон-андроид). В 99% (раз вы любите это число) случаев против «правильного» товара противопоставлен «любой другой товар такого типа». То есть «конкурент» — обезличен. Это негласное правило рекламы, но в других сферах за такое могут и засудить.
Вы же вместо озвучивания проблемы говорите «1С делает это плохо, а Фузион — хорошо». При этом вы сравниваете совершенно различные функциональные элементы. Про это вам уже выше писали. Это как показывать калькулятор свой и чужой на примере «2+2=4». И говорить, что ваш калькулятор оптимизирован, а чужой нет, потому что на примере «2+2=4» он работает быстрее и код меньше.
Потому что мы рассматривали ДРУГУЮ ситуацию…
Все, меня уже не хватает. Либо вы тролли, либо действительно не понимаете о чем речь. Но в любом из этих случаев ваш фузион так и закончится на хабре
Так покажите, как реализовывается этот выбор. Вы же просто выдает перл за перлом вместо конкретного ответа.
И постоянные переходы на гиперболу… хорошее и логичное действие.
С учето полного отсутствия каких-то прудов при постоянном аппелировании к этим крупным клиентам — их наличие вообще под вопросом
И вместо ответа — гипербола и уход от ответа. Верной дорогой идете.
«В принципе можно реализовать, но по опыту проблема реально сильно надуманна» — а по моему опыту проблема очень даже не надуманная. Хотя, возможно, это результат ошибки выжившего. Вы создаете ПО в текущих реалиях, когда многие пользователи уже «научились» на других программах, что так делать нельзя, поэтому пользовательская грамотность слегка другая. 1С создавалась в других реалиях, когда компьютеры еще были в диковинку, поэтому пользователи намного чаще делали ошибки. Но это не значит, что сейчас надо надеяться на грамотность пользователя. Это ошибка в подходе, которая может больно аукнуться.
«Зачем мучать пользователей на всех процессах» — как вы будете определять, в какой ситуации нужна пессимистичная блокировка, а где оптимистичная?
И вообще, мне надоело, что вы вместо ответов на конкретный вопрос начинаете сами себе задавать вопросы и на них отвечать.
Мы говорили про необходимость блокировок, когда пользователи «открыли» данные или одновременно их используют. И в примере про «печать» как раз рассматривали ситуацию, когда пользователь сидит в документе, он был изменен, после чего она его печатает (она его не меняла). В этот момент и срабатывает блокировка.
Обратную ситуацию, когда она сначала распечатала, потом кто-то поменял я просто упомянул, но эта ситуация — не та, ради которой устраивается блокировка. Ту ситуацию ни в одной системе нельзя обойти, только организационно.
Вы же вместо ответа на основное сообщение переводите фокус на «ситуацию-исключение», как будто это и было основным вопросом. И отвечаете в своём стиле «это никому не нужно».
Ваша аналогия некорректна. IT — достаточно уникальная среда, чтобы не сравнивать ее с простыми «житейскими» ситуациями.
Если пользователь может совершить ошибку — однажды он ее совершит. Задача разработчика ПО — как можно сильнее заблокировать пользователю возможности «совершить ошибку».
Вы же пытаетесь вечно выехать на аналогиях, вместо понимания проблемы, которую вы строите
Еще раз — ваш принцип «пусть сами разбираются» не должен быть основным при разработке массового ПО
Вместо того, чтобы говорить, что в фузион хорошо — они пишут, что в 1С плохо. Причем плохо именно по их «авторитетному» мнению, а почему — потому что «правило Парето» и «это не нужно в 99% случаев».
Потому что если будут пытаться показать достоинства своей программы без унижения других — рассказывать почти не о чем. Да и тяжелее будет переводить критику в полемику типа «а вот в 1С хуже»
И да, если любите «правило Парето» — полюбите и «закон Мёрфи» — если что-то плохое может произойти — оно обязательно произойдет. Вот этот закон должен быть основой при разработке ПО, в котором крутятся миллионы.
Точнее так — вы используете его как универсальный ответ на вопрос «почему не реализовано это» — «а вот по правилу Парето это нужно будет в 1% случаев». К сожалению, при разработке ПО:
1) использовать его нельзя. ПО должно учитывать все возможные ситуации и минимизировать риски пользовательской ошибки при работе. Всегда нужна «защита от дурака»
2) когда люди, руководствуясь правилом Парето в виде «80% пользователей пользуются только 20% функционала» решают реализовать 20% функционала, чтобы получить 80% продаж, они натыкаются на проблему, что каждый пользователь использует РАЗНЫЕ 20% функционала.
В ГуглДокс все видят, кто правит в данный момент какую ячейку. Постоянно. То есть есть информация о том, что кто-то работает в этом документе. В вашей же программе такого не будет.
Так что жду от вас «корректного» примера, где с данными работают без блокировок, как в вашей. Иначе — это «ноу хау» в стиле «пусть сами разгребают».
З.Ы. — безопасность всегда стоит выше эфемерного удобства. Если в системе могут работать десятки человек — без блокировок велик риск, что в один момент они подправят один-другой документ некорректно. И когда это определят и как будут исправлять — песня из матов, сначала в сторону пользователей, ну а как разберутся в чем причина — в вашу сторону.
Как раз такую проблему и решает блокировка объекта. И ситуаций, когда она может пригодиться — не счесть. А если все моменты сбрасывать на пользователей — то зачем вообще программа, когда есть Excel?
Идея «работать без блокировок» — всегда опасна. Потому что ударить может в любой момент и неизвестно где. И как потом искать неправильные данные.