Roinet-LJournal

После внедрения одной компоненты процессинговой системы, упоминаемой в предыдущей заметке, настало время её использования – надо набивать её мясом, писать скрипты, которые собственно и будут выполнять всю работу. Сказано сделано – к моменту внедрения был написан скрипт для общения с одной внешней системой, через неделю – ещё один. В результате за две недели было проведено около четверти миллиона бизнес-транзакций и около миллиона запросов во внешний мир.

Все было хорошо, пока не потребовалось реализовать скрипт с использованием SOAP протокола. Вариант с кодогенерацией, как в случае использования утилиты wsdl.exe, не подошел, так как данная компонента должна быть постоянно в работе (останов недопустим), так же она должна иметь возможность работать со многими дополнительными частями (модулями), изменяющимися на ходу. Поэтому было принято решение об использовании DLR.

Для решения поставленной задачи были подняты более-менее поддерживаемые python-библиотеки:

• SOAPpy
• soaplib
• ZSI

Однако ни одны из этого списка работать под IronPython не захотела. Только SOAPpy удалось заставить только пропарсить WSDL и сгенерировать клиентов – посылать запросы не получилось.

Запись опубликована Roinet.Net.Вы можете оставить комментарии здесь или тут

Последние 3 месяца были потрачены на одну из частей распределенной системы, выполняющей некоторые бизнес-задачи. В связи с тем, что проект начат недавно, было принято решение об использовании DLR+IronPython в полный рост. Эта компонента не стала исключением. Итого 1 месяц потрачено на реализацию, 2 месяца – на функциональное, интеграционное, нагрузочное тестирование и доводку. Рабочая среда представляет собой сервер с двумя процессорами Opteron. И вот тут начались проблемы – посыпались ошибки типа

IronPython.Runtime.Exceptions.ImportException: Cannot import name Struct
   в IronPython.Runtime.Importer.ImportFrom(CodeContext context, Object from, String name)
   в Microsoft.Scripting.Utils.InvokeHelper`4.Invoke(Object arg0, Object arg1, Object arg2)
   в Microsoft.Scripting.Interpreter.CallInstruction.Run(InterpretedFrame frame)
   в Microsoft.Scripting.Interpreter.Interpreter.RunInstructions(InterpretedFrame frame)
   в Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame)
   в Microsoft.Scripting.Interpreter.LightLambda.Run2[T0,T1,TRet](T0 arg0, T1 arg1)
   в IronPython.Compiler.PythonScriptCode.Run(Scope scope)
   в IronPython.Compiler.RuntimeScriptCode.InvokeTarget(LambdaExpression code, Scope scope)
   в Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope)
   .....

System.Exception: Can't pickle IronPython.Runtime.Types.BuiltinFunction: it's not the same object as copy_reg._reconstructor
   в Microsoft.Scripting.Actions.Calls.MethodCandidate.Caller.Call(Object[] args, Boolean& shouldOptimize)
   в IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`2.Call1(CallSite site, CodeContext context, TFuncType func, T0 arg0)
   в Microsoft.Scripting.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2)
   в serialize$67(Closure , PythonFunction , Object )
   в IronPython.Compiler.PythonCallTargets.OriginalCallTarget1(PythonFunction function, Object arg0)
   в CallSite.Target(Closure , CallSite , Object , Object )
   в Microsoft.Scripting.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite site, T0 arg0, T1 arg1)
   в _Scripting_(Object[] , Object )
   .....

Стек исключения явно указывает на то, что ошибки где-то в самом ядре DLR или IronPython и они явно происходят из-за многопроцессорности системы. В результате был написан минимальный код, на котором воспроизводятся подобные ошибки на многопроцессорных конфигурациях и Core2 Quad.

Запись опубликована Roinet.Net.Вы можете оставить комментарии здесь или тут

IronPython – реализация python на платформе .Net обычно имеено тем, что это именно .Net реализация на основе DLR. Это дает возможность простого сочетания производительности и строгости статических языков .Net (c#, например) и гибкости python. В текущем проекте потребовалась как раз такая связка для обеспечения производительности и гибкости одного из компонентов сервисной архитектуры.

В решаемой задаче необходимо было в коде C# использовать объекты python, находящиеся в динамически подгружаемых скриптах. Для решения задачи использованы .Net 3.5 (C# 3.0), DLR 0.91, IronPython 2.6 RC1. На прямую работать с интерпретатором python и dlr классами не очень удобно, т.к. надо постоянно тащить за собой такие объекты как ScriptEngine, ScriptScope. Так как способы динамической типизации появятся только в версии C# 4.0, то на данный момент приходится пользоваться небольшими и простыми обертками.

Запись опубликована Roinet.Net.Вы можете оставить комментарии здесь или тут

При использовании чисто специфических модулей для Python модулей (например, inspect) в реализации IronPython возникают определенного рода проблемы – магическим образом пропадает функция _getframe в модуле sys. Однако когда нельзя, но очень хочется, то можно…

Запись опубликована Roinet.Net.Вы можете оставить комментарии здесь или тут

Недавно был закончен один проект и встала задача нагрузочного тестирования разработанной системы. В связи с этим была разработана простенькая программа, задача которой была обращаться к удаленной системе с некоторыми входными данными. Написанный код был запущен в 1000 потоках для имитации массового наплыва клиентов. Однако весьма скоро было замечена странное поведение - клиент использовал не более 2-х соединений, при этом на удаленной стороне IIS был настроен корректно, т.к. 2 таких клиента использовали уже 4 соединения. В следствие долгих поисков и отладки проекта было выяснено следующее: по умолчанию .net framework ограничивает кол-во соединений в количестве 2 штук к каждой конечной точке (домен+порт).
Лечится это достаточно просто в конфигурации:

<system.net>
    <connectionManagement>
      <add address="*" maxconnection="1000"/>
    </connectionManagement>
</system.net>

Подробнее о данной особенности можно узнать в MSDN: http://msdn.microsoft.com/en-us/library/fb6y0fyc.aspx

Запись опубликована Roinet.Net.Вы можете оставить комментарии здесь или тут

Постоянное усложнение требований к программным системам ведет к неизбежному усложнению этих систем и на разработку приходится тратить все больше времени. Для решения этих проблем выход, как правило, один - повышение уровня абстракции кода и максимальное уменьшение дублирования кода.

Выполнения этих условий добиваются различными способами, например, использование различных паттернов проектирования. Однако существует направление, которое весьма широко применяется в различных вариантах - метапрограммирование. Метапрограммирование, на даный момент, развивается в двух направлениях: генерация кода и самомодифицирующийся код. Оба направления применяются уже очень давно и каждый из них обладает рядом преимуществ и недостатков.

Недавно была поставлена цель сымитировать на платформе .Net (C#) декораторы в том виде, в котором они существуют в Python. В связи с отсутствием какой либо языковой поддержки метапрограммирования в C# реализация такой конструкции, естественно, должна представлять собой решение основанное на подходах АОП. Перед такой реализацией были поставлены следующие условия:

• Реализация в виде аттрибута, чтобы использование декоратора было максимально приближено к python-реализации.
• Простота реализации - в идеале для реализации аттрибута хотелось максимум наследования и переопределения одного метода, а минимум - передачи делегата в конструктор аттрибута.
• Реализация аттрибута на основном языке проекта, т.е. на C#.

Запись опубликована Roinet.Net.Вы можете оставить комментарии здесь или тут

В последнее время одной из самых больших претензий к динамическим языкам вроде Python, которые мне приходится слышать, - это отсутствие интерфейсов. Я все время пытаюсь доказать, что это мнение безосновательно.

Запись опубликована Roinet.Net.Вы можете оставить комментарии здесь или тут

При разработке более-менее крупных проектов всегда (а всегда ли?) стоит вопрос об использовании средств поддержки разработки, библиотек и фреймворков. Даже при реализации обычных задач использование стандартных библиотек и протоколов в последствии может вылезти боком. Недавно имела место такая ситуация.

Последние 4-5 месяцев я занимался реализацией ядра системы сервисов для внутренних нужд предприятия. Проект и все сопутствующие ему программы и сервисы реализовывались на платформе Python с использованием формата передачи данных JSON, потому возможности динамического языка использовались на полную катушку. Недавно пришлось реализовывать клиентскую библиотеку к нашей системе для проекта использующего .Net. Само по себе ничего сложного в этом не было - вся динамика python была сымитирована использованием NullableTypes (на тот случай если передаваемая структура является полиморфной и не все поля присутствуют при каждом ответе/запросе), проблемы начались когда пришлось entity классы этой библиотеки передавать через внутренние web-сервисы, которые в .net реализованы с использованием протокола SOAP. Выяснилось, что реализация протокола SOAP в .Net framework не поддерживает передачу полиморфных структур или NullableTypes. Для этого было сделано решение, на мой взгляд представляющее собой костыль - были написаны две обёртки (со стороны клиента и web-сервиса .net проекта), которые скрывали сериализацию entity классов в бинарный формат. Вот и получилось, что классы, которые успешно передавались от python-сервисов .net web-сервисам для передачи клиенту приходится сериализовывать два раза (класс -> бинарная сериализация -> soap-сериализация).

К чему бы все это? Это к вопросу о выборе библиотек и протоколов. Даже во время реализации небольших проектов могут возникать проблемы из-за использования стандартных решений. Как уже написано выше, для передачи данных к/от python-сервисам были использован формат сериализации данных JSON. Так как фреймворков для построения rpc-сервисов на основе JSON нет, пришлось реализовывать все с нуля на основе web-сервера CherryPy и наших внутренних разработок.

Это не призыв к отказу от фреймворков. Наоборот, лично мне очень нравится Django, их необходимо использовать, но там где это необходимо.

Запись опубликована Roinet.Net.Вы можете оставить комментарии здесь или тут

Обсуждений протокола SOAP в сети имеется огромное множество - в теории и в практике. В основном он используется в корпоративных проектах, как следствие, основные и хорошо отлаженные реализации имеются для таких платформ как Java, .Net, PHP. Однако иногда возникают экзотические требования. Например, для реализации клиента выбирается язык PHP, а для реализации сервера - Python. Недавно именно такая задача имела место быть.

Запись опубликована Roinet.Net.Вы можете оставить комментарии здесь или тут

Аннотация.

В данной работе рассматривается проблема коррекции грамматических ошибок в сканированных текстах естественного языка. В связи с этим в работе поставлены следующие задачи:

1. Исследовать существующие методики диагностики и коррекции одиночных грамматических ошибок в текстах русского языка.
2. Провести сравнительный анализ методов.
3. Улучшить метод диагностики и коррекции одиночных грамматических ошибок в текстах русского языка, основанный на морфологическом
   анализе, за счет уменьшения количества вариантов коррекции.

Реализован программный комплекс диагностики и коррекции орфографических ошибок в сканированных текстах русского языка. Уменьшено количество вариантов коррекции в методе, основанном на морфологическом анализе, за счет применения частотного словаря, что позволило повысить процент корректно исправленных слов в 4 раза.

Печатная версия (MS Word).
Полная версия (+слайды).

Запись опубликована Roinet.Net.Вы можете оставить комментарии здесь или тут