Смартфон эмулирует магнитную полосу не чипом NFC. Судя по сайту Самсунга (я не знаю других производителей с такой технологией) — там стоит специальный чип для эмуляции магнитной полосы. Впечатления от нее смешанные: пробовал два раза. Один раз сработало, один — нет.
Опять же, насколько мне известно, такую эмуляцию умеют только смартфоны S7-й серии (S7, S7 Edge).
В обоих случаях был терминал, не поддерживающий PayWave/PayPass.
Ссылка на Самсунг: http://www.samsung.com/ru/support/skp/faq/1116646
Если у вас нет проблем — тогда зачем вы тиражируете чьи-то заявления, причин которых не понимаете? В ситуации, когда внедренец честно говорит: у меня нет компетенций по Линуск/Мак/Звездам смерти, я имею компетенции по Виндоуз/Юникс/Телепортаторам, по этому и предлагаю вам то, что предлагаю, никакого криминала сходу не видно. Есть честное предупреждение о своих возможностях. Печально, если отсутствие своих компетенций прикрывается обвинениями продукта в невозможности сделать что-то.
Представители 1С иногда заявляют публично, что Линукс не интересует клиентов, процент внедрений на нем очень мал
И прямо есть ссылки на такие заявления представителей 1С?
Да потому и мал, что внедренцы отказываются ставить на него 1С.
Да вроде не отказываются. Судя по партнерскому форуму — Линукс используется достаточно часто.
Давайте не смешивать кислое и фиолетовое.
По приведенной ссылке имеется фактологическая ошибка.
Ваше утверждение о том, что 1С: Предприятие не поддерживает работу с PostgreSQL — это только ваше утверждение. Почему мифические внедренцы предлагают УПП и MS SQL — это отдельный вопрос. Радикально простой ответ на этот вопрос звучит так: эти внедренцы ничего другого не знают. Подозреваю, что мир не монохромен, и правильный ответ не так радикален.
Предлагается все-таки не разбрасываться абстрактными утверждениями (их много и у вас и у меня), а быть несколько более конструктивными. Если есть проблемы с PostgreSQL — пишите в поддержку: эти ошибки будут анализироваться и исправляться.
Билайновский ЛК безотносительно страдает отрицательной производительностью. У них даже мобильный кабинет для получения 6 цифр по тарифу тратит чуть не минуту. Боюсь, что верстка почти совсем не оказывает влияния на скорость.
Может для предоплаты ЛК и быстрый, но для постоплаты — это просто адский тормоз
Я не в белом, не на коне и не мушкетер, но ответить все-таки попытаюсь :)
Ваши фантазии по поводу того, что и почему мы делаем оставлю без комментариев, т.к. нет предмета для комментария.
Теперь про конкретную ситуацию.
Когда нас критикуют за медленный язык, мы пытаемся понять — что пытается реализовать разработчик такого, что встроенный язык начинает влиять на реактивность системы, насколько часто возникает описываемая ситуация и сколько людей используют этот механизм. Если будут выявлены реальные сценарии, когда скорость интерпретатора является реальным тормозом — значит будем анализировать такие случаи и думать, как решить проблему. В общем случае — мы не считаем, что скорость встроенного языка является существенной проблемой в данный момент. Что, однако, не исключает того, что мы готовы рассматривать конкретные проблемы и их решать. Но вначале проблему надо понять и оценить ее влияние на конфигурации. Если проблему поднимают 3 человека (да и даже если 103), а пользуются платформой несколько сотен тысяч, то надо хорошо представлять себе, насколько эта проблема реальна. Если вы считаете, что рассказать, нам о том, как мы не умеем программировать важнее, чем привести реальный сценарий — ок, позиция понятна :)
В примере с серверными вычислениями есть только один момент, который выглядит не очевидным: лично я совсем не уверен, что быстрый скрипт был-бы быстрее того же расчета на сервере, через временные таблицы. В данном случае мои сомнения и предположения коллеги (@svcoder) примерно равновероятны. Возможно, разработчики ERP дополнительно озадачивались данным вопросом и приняли текущее решение не просто так. Но, однако, пример как таковой кажется вполне логичным и понятным.
Теперь про JSON. Скажите, из какого вашего сообщений следует, что вы написали JSON-сериализацию тогда, когда ее не было в платформе? Я этого не увидел. Поэтому и уточнил — зачем ее писать самостоятельно? Вы меня стали подозревать в каких-то страшных грехах:) Также оставим за скобками то, что ваша реализация отлажена по умолчанию, а наша — глючна по умолчанию :)
Самое главное, что мы стараемся закрывать достаточно популярные и критичные моменты, причем для оценки популярности и критичности стараемся использовать не только свое мнение, но и мнение пользователей и партнеров. А для этого пытаемся узнавать — какую бизнес-задачу мешает реализовать та или иная возможность (или ее отсутствие) в платформе.
Проблемы производительности мы стараемся решать. Прилагаемые усилия видны и в списке изменений и на выступлениях на семинарах. Понятно, что это происходит в свежих версиях платформы.
ЗЫ: И все-таки предлагаю быть более конструктивным. Если стоит цель доказать нам, что мы не умеем писать экономический софт — наверное мы сразу согласимся :) Ну может быть попросим научить нас его писать качественно (даже вакансии открыты http://1c.ru/rus/firm1c/vacan/, особенно вот http://1c.ru/rus/firm1c/vacan/vacancy.jsp?id=201).
А какой клиент был в 8.2 для больших и ресурсоёмких задач? — x64.
С утерей толстого клиента Win x64 для 8.3.
Одной из причин повышения потребностей в памяти служит существенное усложнение прикладных решений. Я думаю, что если написать на 8.х аналог конфигурации 7.7 (полностью эквивалентный, без расширения возможностей!) — получится маленькое и быстрое решение. Это ИМХО, возможно безосновательное :)
С одной стороны она противоречит законодательству РФ
Можете привести ссылку на конкретный параграф закона?
, с другой стороны она противоречит вашей политике в отношении иностранных разработчиков:
Почему?
Для «местных» есть вот эта статья: Размещение данных 1С: Предприятия 8, есть метод получения структуры базы (во встроенном языке), есть описание того, что можно делать не нарушая лиц.соглашения (тут).
Смотреть можно, чинить базы можно, анализировать структуру данных и принимать адекватные решения по разработке — тоже можно. Нельзя делать продуктивные решения, построенные на прямом доступе к данным СУБД.
Опять же, насколько мне известно, такую эмуляцию умеют только смартфоны S7-й серии (S7, S7 Edge).
В обоих случаях был терминал, не поддерживающий PayWave/PayPass.
Ссылка на Самсунг: http://www.samsung.com/ru/support/skp/faq/1116646
И прямо есть ссылки на такие заявления представителей 1С?
Да вроде не отказываются. Судя по партнерскому форуму — Линукс используется достаточно часто.
По приведенной ссылке имеется фактологическая ошибка.
Ваше утверждение о том, что 1С: Предприятие не поддерживает работу с PostgreSQL — это только ваше утверждение. Почему мифические внедренцы предлагают УПП и MS SQL — это отдельный вопрос. Радикально простой ответ на этот вопрос звучит так: эти внедренцы ничего другого не знают. Подозреваю, что мир не монохромен, и правильный ответ не так радикален.
Предлагается все-таки не разбрасываться абстрактными утверждениями (их много и у вас и у меня), а быть несколько более конструктивными. Если есть проблемы с PostgreSQL — пишите в поддержку: эти ошибки будут анализироваться и исправляться.
По приведенной ссылке — баг, исправим.
Может для предоплаты ЛК и быстрый, но для постоплаты — это просто адский тормоз
http://its.1c.ru/db/v83doc#bookmark:adm:TI000000485
Спасибо!
Только вначале убедитесь, что версия платформы совпадает с версией документации.
В общем случае — можно без программиста. Есть такая штука — СКД называется. Вот она и позволяет такие вещи делать без программиста.
Ваши фантазии по поводу того, что и почему мы делаем оставлю без комментариев, т.к. нет предмета для комментария.
Теперь про конкретную ситуацию.
Когда нас критикуют за медленный язык, мы пытаемся понять — что пытается реализовать разработчик такого, что встроенный язык начинает влиять на реактивность системы, насколько часто возникает описываемая ситуация и сколько людей используют этот механизм. Если будут выявлены реальные сценарии, когда скорость интерпретатора является реальным тормозом — значит будем анализировать такие случаи и думать, как решить проблему. В общем случае — мы не считаем, что скорость встроенного языка является существенной проблемой в данный момент. Что, однако, не исключает того, что мы готовы рассматривать конкретные проблемы и их решать. Но вначале проблему надо понять и оценить ее влияние на конфигурации. Если проблему поднимают 3 человека (да и даже если 103), а пользуются платформой несколько сотен тысяч, то надо хорошо представлять себе, насколько эта проблема реальна. Если вы считаете, что рассказать, нам о том, как мы не умеем программировать важнее, чем привести реальный сценарий — ок, позиция понятна :)
В примере с серверными вычислениями есть только один момент, который выглядит не очевидным: лично я совсем не уверен, что быстрый скрипт был-бы быстрее того же расчета на сервере, через временные таблицы. В данном случае мои сомнения и предположения коллеги (@svcoder) примерно равновероятны. Возможно, разработчики ERP дополнительно озадачивались данным вопросом и приняли текущее решение не просто так. Но, однако, пример как таковой кажется вполне логичным и понятным.
Теперь про JSON. Скажите, из какого вашего сообщений следует, что вы написали JSON-сериализацию тогда, когда ее не было в платформе? Я этого не увидел. Поэтому и уточнил — зачем ее писать самостоятельно? Вы меня стали подозревать в каких-то страшных грехах:) Также оставим за скобками то, что ваша реализация отлажена по умолчанию, а наша — глючна по умолчанию :)
Самое главное, что мы стараемся закрывать достаточно популярные и критичные моменты, причем для оценки популярности и критичности стараемся использовать не только свое мнение, но и мнение пользователей и партнеров. А для этого пытаемся узнавать — какую бизнес-задачу мешает реализовать та или иная возможность (или ее отсутствие) в платформе.
Проблемы производительности мы стараемся решать. Прилагаемые усилия видны и в списке изменений и на выступлениях на семинарах. Понятно, что это происходит в свежих версиях платформы.
ЗЫ: И все-таки предлагаю быть более конструктивным. Если стоит цель доказать нам, что мы не умеем писать экономический софт — наверное мы сразу согласимся :) Ну может быть попросим научить нас его писать качественно (даже вакансии открыты http://1c.ru/rus/firm1c/vacan/, особенно вот http://1c.ru/rus/firm1c/vacan/vacancy.jsp?id=201).
Я отвечал на ремарку:
Одной из причин повышения потребностей в памяти служит существенное усложнение прикладных решений. Я думаю, что если написать на 8.х аналог конфигурации 7.7 (полностью эквивалентный, без расширения возможностей!) — получится маленькое и быстрое решение. Это ИМХО, возможно безосновательное :)
Можете привести ссылку на конкретный параграф закона?
Почему?
Для «местных» есть вот эта статья: Размещение данных 1С: Предприятия 8, есть метод получения структуры базы (во встроенном языке), есть описание того, что можно делать не нарушая лиц.соглашения (тут).
Смотреть можно, чинить базы можно, анализировать структуру данных и принимать адекватные решения по разработке — тоже можно. Нельзя делать продуктивные решения, построенные на прямом доступе к данным СУБД.