В Тинькофф можно удаленно открыть счет, и создавать несколько виртуальных карт (но привязанных к счету физической), и устанавливать разные лимиты. Физической картой можно вообще не пользоваться — установить лимиты в 0, запретить операции в интернете.
При этом изменения лимитов применяются мгновенно, в отличие от некоторых других банков. Т.е. можно по умолчанию устанавливать на карте лимит 0, а непосредственно перед оплатой в интернете ставить нужную сумму.
Определение зон с текстом на изображении — практически та же задача распознавания. Библиотек для предобработки изображений множество. Наиболее известные — OpenCV и ImageMagick. Вот тут еще варианты перечислены: tesseract-ocr.github.io/tessdoc/ImproveQuality#tools--libraries
А вот в случае, когда PDF документ содержит неправильный текст, определить блоки с текстом проще. Ведь информация о расположении текста доступна, просто маппинги в Unicode неправильные. Определить позиции существующего текста в PDF документе можно так.
Не удивлюсь, т.к. про это написано по ссылке со StackOverflow, которую я привел в своем сообщении (https://stackoverflow.com/a/16719474/136138)
На практике на моем i7-4200HQ разница существенна для RyuJIT x64. Я взял benchmark gist.github.com/aensidhe/0d412e142eb29fd21eea01b5f6462d41 и сравнил For() и ForReverse(). В первом случае RyuJIT убирает bounds check, во втором — оставляет. И у меня на машине получаются такие результаты:
Возможно, это ограничение LegacyJIT x86. Либо код запускался без оптимизаций. RyuJIT x64 должен быть умнее (https://stackoverflow.com/a/17138483/136138).
Подскажите, пожалуйста, потребуется ли использовать онлайн-кассы для случаев вывода денег с Upwork или AppStore?
В законе есть пункт «9. Контрольно-кассовая техника не применяется при осуществлении расчетов с использованием электронного средства платежа без его предъявления между организациями и (или) индивидуальными предпринимателями.», можно ли его применять в данном случае?
Стоит изначально добавить поддержку .NET Standard Library — это позволит использовать ваш фреймворк из ASP.NET Core приложений. На ранней стадии это сделать проще.
Не спорю, создавать документы и тем более писать Javascript для PDF, конечно же, значительно удобней в Adobe LiveCycle Designer (как и, например, создавать docx документы в Word, а не программно)
Подход описанный в статье более низкоуровневый и может представлять дополнительный интерес для разработчиков приложений, которым требуется создавать или модифицировать PDF документы. Это может быть программная генерация разного рода форм или отчетов. Или, например, сжатие существующих документов — одним из приемов тут может быть удаление всех Javascript action'ов из документа.
Mercurial на порядок дружественней для Windows пользователей. TortoiseGit все-таки еще достаточно сыроват.
Другим важным преимуществом для нас стало то, что Mercurial — основная VCS в FogBugz, это трекер, на который мы решили переехать.
Изучали, но не стали пробовать. По нескольким причинам:
1) У нас было несколько собственных SVN репозиториев, связанных через externals (например, в репозиторий проекта A подгружаются файлы из репозитория проекта Common), и все их нужно было перенести на Меркуриал. Как в этом случае корректно перенести всю историю с внешними зависимостями я с трудом представляю
2) subrepo это все-таки не совсем svn:externals. Задача стояла сохранить историю всех репозиториев полностью работоспособной и идентичной оригиналу, и не было гарантии, что через suprepo это получится вообще. Способ описанный в статье достаточно простой и гарантированно дает нужный результат, поэтому не стали тратить время на эксперименты.
3) После некоторого времени активного использования svn:externals пришли к выводу, что внешние зависимости на уровне репозиториев не так уж и хороши, и тащить их в Меркуриал попросту не хотелось.
Согласен, теги — отличная альтернатива конкретным ревизиям, если, конечно, они правильно используются и используются вообще во внешнем репозитории. Не вспомнил об этом при написании статьи.
— Если хранить все в одном репозитории, то получаются неудобства с нумерацией версий конкретных проектов (если завязывать нумерацию версий на номер ревизии). Например:
Работаем только над «проект1», сделали 300 коммитов, выпустили версию «проект1» 1.0.300
Затем переключаемся на «проект2», после 400 коммитов выпускаем версию «проект2» 1.0.600 (уже не совсем верно)
Возвращаемся к «проект1», делаем 1 коммит (небольшой фикс) и выпускаем версию — получается номер 1.0.601 (совсем некорректно)
— На начальном этапе это не заметно, но со временем размер репозитория сильно увеличивается. В истории накапливается куча ненужного. Например, представим ситуацию, когда какой-то проект больше ну совершенно не нужен — можно его удалить. Простое удаление из репозитория не уменьшит общий размер, ибо вся история останется.
Размер репозитория до поры-до времени будет не критичен, однако когда он вырастает до нескольких Гб — готовьтесь, что как только потребуется осуществлять какие-то действия с самим репозиторием — перенос на новый сервер, какую-то обработку дампа, миграцию в другую VCS — столкнетесь с проблемами.
— Декомпозиция дает большую гибкость в управлении репозиториями
Частичное повторение предыдущего пункта. Если захотите что-то сделать с репозиторием — выкинуть какую-то ненужную часть истории, сделать бэкап только одного проекта, перейти на Git — с декомпозированными репозиториями будет проще.
К слову, при декомпозиции никто не мешает также использовать копирование вместо externals, так что Ваше второе преимущество не совсем преимущество.
/////
Вообще, как показывает практика, и в других областях декомпозиция в большинстве случаев лучше. Ибо, обычно, делает вещи проще, например:
— Вся эволюция императивных языков программирования направлена на упрощение разработки и, соответственно, кода. И декомпозиция — главный инструмент для этого. Сейчас мы пришли к тому, что грамотно спроектированный проект:
1) Разделен на модули/компоненты, каждый из которых решает конкретную задачу;
2) Каждый компонент разделен на классы, каждый из которых в соответствии с хорошими практиками ООП решает 1 задачу;
3) Каждый класс разделен на методы, каждый из которых в идеале решает 1 задачу;
4) В каждом методе используются переменные и, в идеале, каждая переменная должна использоваться только для одной цели.
— Управление требованиями к проекту. Как проще — когда все требования по проекту в куче в одном документе или же аккуратно разнесены по разным задачам в трекере? Практика показывает, что второе.
Путь через «svnadmin setrevprop» также возможен, но, на мой вгляд, требует больше усилий и занимает больше времени. При таком подходе все равно нужно:
-найти в дампе все проблемные ревизии, где встречаются ссылки на внешний репозиторий
-каждое свойство, которое нужно поменять, скопировать в файл
-поправить ссылку в файле
-применить «svnadmin setrevprop» для каждого свойства
При предложенном мной подходе все изменения делаются по ходу просмотра файла дампа. Количество байт не нужно считать глазами, текстовый редактор с этим отлично справляется либо можно просто отнять/прибавить разницу в длине между старым и новым адресом.
При этом изменения лимитов применяются мгновенно, в отличие от некоторых других банков. Т.е. можно по умолчанию устанавливать на карте лимит 0, а непосредственно перед оплатой в интернете ставить нужную сумму.
А вот в случае, когда PDF документ содержит неправильный текст, определить блоки с текстом проще. Ведь информация о расположении текста доступна, просто маппинги в Unicode неправильные. Определить позиции существующего текста в PDF документе можно так.
На практике на моем i7-4200HQ разница существенна для RyuJIT x64. Я взял benchmark gist.github.com/aensidhe/0d412e142eb29fd21eea01b5f6462d41 и сравнил For() и ForReverse(). В первом случае RyuJIT убирает bounds check, во втором — оставляет. И у меня на машине получаются такие результаты:
blogs.msdn.microsoft.com/clrcodegeneration/2009/08/13/array-bounds-check-elimination-in-the-clr
stackoverflow.com/questions/16713076/array-bounds-check-efficiency-in-net-4-and-above
В ваших примерах bounds check присутствуют:
cmp esi, eaxjae 056e2d31
Возможно, это ограничение LegacyJIT x86. Либо код запускался без оптимизаций. RyuJIT x64 должен быть умнее (https://stackoverflow.com/a/17138483/136138).
stackoverflow.com/a/26214865/136138
В законе есть пункт «9. Контрольно-кассовая техника не применяется при осуществлении расчетов с использованием электронного средства платежа без его предъявления между организациями и (или) индивидуальными предпринимателями.», можно ли его применять в данном случае?
Подход описанный в статье более низкоуровневый и может представлять дополнительный интерес для разработчиков приложений, которым требуется создавать или модифицировать PDF документы. Это может быть программная генерация разного рода форм или отчетов. Или, например, сжатие существующих документов — одним из приемов тут может быть удаление всех Javascript action'ов из документа.
Другим важным преимуществом для нас стало то, что Mercurial — основная VCS в FogBugz, это трекер, на который мы решили переехать.
1) У нас было несколько собственных SVN репозиториев, связанных через externals (например, в репозиторий проекта A подгружаются файлы из репозитория проекта Common), и все их нужно было перенести на Меркуриал. Как в этом случае корректно перенести всю историю с внешними зависимостями я с трудом представляю
2) subrepo это все-таки не совсем svn:externals. Задача стояла сохранить историю всех репозиториев полностью работоспособной и идентичной оригиналу, и не было гарантии, что через suprepo это получится вообще. Способ описанный в статье достаточно простой и гарантированно дает нужный результат, поэтому не стали тратить время на эксперименты.
3) После некоторого времени активного использования svn:externals пришли к выводу, что внешние зависимости на уровне репозиториев не так уж и хороши, и тащить их в Меркуриал попросту не хотелось.
Можете попробовать Babel .NET, мы им пользуемся для обфускации, довольны.
— Если хранить все в одном репозитории, то получаются неудобства с нумерацией версий конкретных проектов (если завязывать нумерацию версий на номер ревизии). Например:
Работаем только над «проект1», сделали 300 коммитов, выпустили версию «проект1» 1.0.300
Затем переключаемся на «проект2», после 400 коммитов выпускаем версию «проект2» 1.0.600 (уже не совсем верно)
Возвращаемся к «проект1», делаем 1 коммит (небольшой фикс) и выпускаем версию — получается номер 1.0.601 (совсем некорректно)
— На начальном этапе это не заметно, но со временем размер репозитория сильно увеличивается. В истории накапливается куча ненужного. Например, представим ситуацию, когда какой-то проект больше ну совершенно не нужен — можно его удалить. Простое удаление из репозитория не уменьшит общий размер, ибо вся история останется.
Размер репозитория до поры-до времени будет не критичен, однако когда он вырастает до нескольких Гб — готовьтесь, что как только потребуется осуществлять какие-то действия с самим репозиторием — перенос на новый сервер, какую-то обработку дампа, миграцию в другую VCS — столкнетесь с проблемами.
— Декомпозиция дает большую гибкость в управлении репозиториями
Частичное повторение предыдущего пункта. Если захотите что-то сделать с репозиторием — выкинуть какую-то ненужную часть истории, сделать бэкап только одного проекта, перейти на Git — с декомпозированными репозиториями будет проще.
К слову, при декомпозиции никто не мешает также использовать копирование вместо externals, так что Ваше второе преимущество не совсем преимущество.
/////
Вообще, как показывает практика, и в других областях декомпозиция в большинстве случаев лучше. Ибо, обычно, делает вещи проще, например:
— Вся эволюция императивных языков программирования направлена на упрощение разработки и, соответственно, кода. И декомпозиция — главный инструмент для этого. Сейчас мы пришли к тому, что грамотно спроектированный проект:
1) Разделен на модули/компоненты, каждый из которых решает конкретную задачу;
2) Каждый компонент разделен на классы, каждый из которых в соответствии с хорошими практиками ООП решает 1 задачу;
3) Каждый класс разделен на методы, каждый из которых в идеале решает 1 задачу;
4) В каждом методе используются переменные и, в идеале, каждая переменная должна использоваться только для одной цели.
— Управление требованиями к проекту. Как проще — когда все требования по проекту в куче в одном документе или же аккуратно разнесены по разным задачам в трекере? Практика показывает, что второе.
Путь через «svnadmin setrevprop» также возможен, но, на мой вгляд, требует больше усилий и занимает больше времени. При таком подходе все равно нужно:
-найти в дампе все проблемные ревизии, где встречаются ссылки на внешний репозиторий
-каждое свойство, которое нужно поменять, скопировать в файл
-поправить ссылку в файле
-применить «svnadmin setrevprop» для каждого свойства
При предложенном мной подходе все изменения делаются по ходу просмотра файла дампа. Количество байт не нужно считать глазами, текстовый редактор с этим отлично справляется либо можно просто отнять/прибавить разницу в длине между старым и новым адресом.
markhansen.co.nz/git-repo-inside-git/#submodules
Есть и альтернатива в виде Subtree merges. Подробнее про последний путь тут:
www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html