Bankir.Ru
9 декабря, пятница 18:35

Объявление

Свернуть
Пока нет объявлений.

"Объектность" против "открытости"

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • "Объектность" против "открытости"

    Недавно при обсуждении "Путей развития АБС" у меня с Alanf'ом возник спор об используемых средствах доработки АБС. Аналогичный вопрос возник и при обсуждении темы Хранилища.

    И так. Что лучше (для банка, а не для разработчика системы):
    а) наличие объектного API (вместе с языком програмирования) со спрятаной за ним физической структурой данных.
    б) открытая структура данных с возможностью использования любых средств разработки и доступа к данным.

    Понятно, что в первом случае ниже вероятность ошибок, проще с поддержкой и переходом на новые версии.
    Но во втором случае возможности по доработкам силами банка значительно выше, да с производительностью проблем меньше.

    Я например, сторонник открытого варианта. Но изучая имеющиеся на рынке системы заметил, что большинство из них тяготеют к закрытому варианту. Может быть это я один такой? Или не понимаю чего-то важного?
    Многоуважаемые коллеги, выскажите свое мнение.

  • #2
    Посторонний
    Как мне кажется, для банка всё равно лучше первый вариант!
    - внутренние доработки банком, на мой субъективный взгляд, надо присекать в корне... аргументов - масса... главный из которых управление изменениями.
    - безопасность Ваших данных... с этим, наверное тоже ясно...
    однако то, что это проще поддерживать и обновлять - сомневаюсь
    Лёха

    Комментарий


    • #3
      2shmyga : Как мне кажется, для банка всё равно лучше первый вариант

      Несогласные мы. Если банк динамично развивается, а не "окостенел" в смысле спектра производимых операций - ни один разработчик АБС (ни совковый, ни западный) не "угонится" за потребностями бизнес-подразделений в автоматизации. А чтобы написать на хотя бы 90% универсальное, безглючное и малоограниченное API, нужен не один год и даже не несколько.
      У меня имеется опыт общения с подобными надстройками - от МИМ-технологий (МИМ-дизайнер) и от Кворума (Атлантис). Общее впечатление (подтвердившееся после начала работы с открытой системой на Oracle) - ну не стОит овчинка выделки...
      WBR, Александр Турчин

      Комментарий


      • #4
        2Александр_Турчин
        не думаю, что даже у динамично развивающегося банка есть возможность максимально тестировать свои разработки. Более того, именно у динамично развивающегося банка софт такой, что тестировать его нужно "в хвост и в гриву". Если учесть, что разработчик АБС может "покатать" ее (АБС) в энном количестве реализаций, а Банк - только у себя, то напрашивается 1-й вариант

        Комментарий


        • #5
          Соглашусь с Александр_Турчин.

          Если бы можно было не думать о написании собственных приблуд вообще, то тогда и без разницы можно и без открытости и API. И это было бы хорошо и здорово.

          Но если есть хоть какая малая необходимость в своих приблудах, то открытый код гораздо лучше. И хоть продвинутый банк, хоть не продвинутый, но на сегодня найдется кто не пишет себе с боку бантики?

          А еще документация. Может и мой грех, плохо читаю, но тем системам где я работал, легче разобраться как задумывалось и что происходит когда видишь потроха, чем понять по документации.
          [/B]

          Комментарий


          • #6
            2 SKol & Александр_Турчин
            Мне кажется вы говорите не о нормальных системах... точнее не от хорошей жизни.
            давайте посмотрим насколько часто кто-то чего-то дописывает в "авторитетах" - например R/3 ? вот и я думаю - ничего там пользователи (в смысле организации) не пишут !!!
            теперь по поводу "динамичности" :
            а почему Вы думаете, что нельзя разрабатывать системы "на вырост" - один раз сделал (реализовал механизм настроек), описал это всё в мануале... - а дальше пусть пользователь сам настраивает чё хочет... а вот ежли он в коде уже пусть даже 2% поменял... это уже, извините, не система...
            давайте ближе к жизни : вы видели что б хозяин мерса или какой-либо японской авто... переделывал САМ СЕБЕ некие механизмы ? попроще ? да - наш автопром далёк от совершенства... так давайте, дорогие, не будем уподобляться ему...
            по-моему каждый должен заниматься своим делом.
            есть ещё довод, и он уже больше к оценке рисков - банк (либо другая контора) попадает в зависисмость от такого "писателя"...
            и ещё : любая НОРМАЛЬНАЯ фирма пойдёт Вам навстречу, если Вы со своим бурно развивающимся банком будете требовать от них реализации инноваций или на худой конец механизмов настройки...
            Лёха

            Комментарий


            • #7
              expertl
              не думаю, что даже у динамично развивающегося банка есть возможность максимально тестировать свои разработки

              Ничего себе... Я аж растерялся, прочитамши...

              По-моему, как раз ТОЛЬКО У БАНКА и есть возможность максимально тестировать. Сразу тыща юзеров сидит и тестирует на живых документах с утра и до ночи. У отдела сопровождения в банке телефон горячий от звонков из бухгалтерии о "результатах тестирования". И сколько раз такое было, что "покатанная" разработчиком (АБС) в энном количестве реализаций при первом же запуске у тебя такое выдает... Никогда у разработчика не будет такой богатой базы для отладки, как в банке. Очень часто разработчики просят банк прислать файлы, на которых их суперобкатанные в хвост и в гриву программы рушатся. А сами тестируют кое-как, даже лидеры рынка. Когда у моего клиента при ста платежках за день клиент-банк умирал, BSS меня спрашивал - "А где вы таких клиентов берете?". В Африке, млин... Мне, кстати, по барабану, в скольких там банках разработчик это катал, мне важно, чтобы у меня работало.
              Последний раз редактировалось Pif; 30.04.2003, 17:33.

              Комментарий


              • #8
                Pif
                ой! по моему на 1000 - головом банке тестировать - это уже издевательство...
                а потом - представьте менеджмент захочет "упаковать" и продать этот банк другому владельцу... )) "писателям" грозит быть упакованными...

                ЗЫ
                хотя Когда то давно в 1998 году один мой приятель - сетевик в достаточно уважаемой конторе избежал сокращения... потому как "его нужно было оставлять со СКС" - только он знал от_и_до инфраструктуру здания...
                ныне эта компания целиком на "аутсорсинге"...
                Лёха

                Комментарий


                • #9
                  по моему на 1000 - головом банке тестировать - это уже издевательство

                  На любом банке тестировать - издевательство. Но таких разработчиков, которые не на банках свое бла-бла-бла тестируют, а у себя - видимо, нет. Если таких знаете - примеры в студию

                  Комментарий


                  • #10
                    Мое мнение - второй вариант (т.е. открытая структура). Тогда банк сам может спроектировать, разработать и внедрить необходимые ему модули и изменения к существующим. Риск, конечно, есть, но "жизнь хороша, хороша вдвойне, коль ей рисковать умеешь". Только надо программеров держать нормальных и методолога, который бы фишки сек в программировании и банковских технологиях.
                    А от закрытых API я, например, уже наплакался. Сам ничего не можешь исправить, а от разработчика пока дождешься, так либо он гад денежку требует, либо к тому времени ЦБ что-нибудь нароет и отымеет по самое не могу (извините, но уж больно неприятно вспоминать)

                    Комментарий


                    • #11
                      2shmyga : давайте посмотрим насколько часто кто-то чего-то дописывает в "авторитетах" - например R/3 ?

                      Приведите pls, чтобы не быть голословным, примеры внедрений банковских систем на основе R\3 в России. А то как-то неавторитетно выходит .

                      а почему Вы думаете, что нельзя разрабатывать системы "на вырост" - один раз сделал (реализовал механизм настроек), описал это всё в мануале... - а дальше пусть пользователь сам настраивает чё хочет... а вот ежли он в коде уже пусть даже 2% поменял... это уже, извините, не система...

                      Не сочтите за обиду, но, прочитав это Ваше высказывание, можно подумать, что г. Красногорск находится не на планете Земля . Приведу простой пример - во многих ли российских и западных системах есть полноценная (с онлайн- и оффлайн клиентскими интерфейсами, модулями для филиалов и допофисов и функционалом, соответствующим российским реалиям) факторинговая система ? И какими, извините, настройками Вы её реализуете в случае отсутствия соответствующего модуля ?
                      WBR, Александр Турчин

                      Комментарий


                      • #12
                        Pif
                        может мы о разных вещах ?
                        разумеется если банк сам - сознательно и осознанно - тестирует всё на себе... и человек, отвечающий "за базар" в курсе тестирования и принимает такое решение... это одно... я же о другом - о "рояле в кустах"...

                        с другой стороны ВСЁ_ВСЁ_ВСЁ протестировать действительно сложно...
                        а примеры ? мы же здесь обсуждаем концепции, подходы... реальные примеры готов привести, но лучше по бимэйлу... дабы не сочли за рекламу
                        Лёха

                        Комментарий


                        • #13
                          Александр_Турчин
                          Ну Красногорск далеко, согласен, (однако турция ещё дальше)

                          Вы хотите чтобы, извиняюсь, буржуи разрабатывали под наши, извините беспорядочные требования, системы ? Может Вы ещё приведёте примеры Российских банков с, не только формализоваными, но и исполняемыми и реализоваными стратегиями и задачами ? мне кажется наоборот - всегда "хотим как лучше, а получается, как всегда..." (с)
                          Итак вернувшись в начало темы - для банка всегда лучше сотрудничество с фирмой-разработчиком, т.е. банк - финансовый институт, а разработчик - производственный...
                          так кто чем должен заниматься ?..
                          Лёха

                          Комментарий


                          • #14
                            shmyga Вы хотите чтобы, извиняюсь, буржуи разрабатывали под наши, извините беспорядочные требования, системы ?

                            Что - то я Вас не пойму. То Вы говорите, что "крутая" система должна уметь ВСЁ посредством установки соответствующих настроек, то утверждаете, что буржуйские системы это сделать не сумеют. Определитесь уж...
                            WBR, Александр Турчин

                            Комментарий


                            • #15
                              Я вот за открытость, более того, за документированную и желательно объектную (с описанным АПИ) открытость. Каждый сообразно своему уровню знаний и умений пусть пишет. На то и программисты (там где они есть), что бы писать. И если банк своими силами способен решать свои проблемы и не платить за это просто неприличные деньги разработчикам АБС, то честь ему и хвала. А то, что при этом банк попадает в зависимость от разработчиков, так это утопия. Если разработка ведется на какой-нибудь более менее стандартной базе данных, по которой можно найти специалистов, если клиент пишется на более менее распространенной системе типа Delphi, то заменить исполнителей программистов не проблема. Заменить всю команду - проблема, но тоже решаемо. Вот заменить технолога - это проблема. Главное не допускать, что бы один человек совместил в себе три таких ипостаси. Но и это не проблема - при наличии неприличных денег, для оплаты замены технологии. Т.е. в конечном итоге все решается так или иначе деньгами.
                              Поэтому я только за открытость. Даже желательно с открытым кодом. Если тяму хватит у программистов, да пусть развиваются. И, опять же, здоровая конкуренция разработчикам АБС, что б шевелились быстрее.

                              Комментарий


                              • #16
                                Раз уж мы перешли на деньги.
                                То давайте подумаем насколько программная реализация банковской бухгалтерии сложнее реализации производственной, и почему 1С стоит до 20000 рублей, а любой банковский софт от 30000 долларов.

                                Комментарий


                                • #17
                                  Реализация бухгалтерии банковской значительно легче реализации бухгалтерии производственной. Поскольку меньше перечень учитываемых документов и операций. Насчет 1с - это именно бухгалтерия, а никак не система уровня современной АБС. Если из АБС выкинуть все, кроме бухгалтерии, так и стоить будет то самое, что и 1с. Оно так и стоило, пример - киевский опердень. А нормальная система комплексной автоматизации деятельности предприятия класса MRP стоит от 1млн. баксов. Тут у нас комбайновый завод внедряет как раз такую.

                                  Комментарий


                                  • #18
                                    Да нечего из АБС выкидывать!
                                    И в банках и на производстве поголовно - учет и отчетность.
                                    Если кому-то хочется чего-то большего, то и платят уже ДЕНЬГИ.
                                    Может попросить 1совцев АБС написать "объектную" и "открытую"

                                    Комментарий


                                    • #19
                                      Прошу прощения что вмешиваюсь, вроде бы автор темы просил высказаться только банкиров. Что ж, тогда вспомню про свой банковский опыт и попробую отрешиться от опыта "разработчика"...
                                      2 AlexCH:
                                      И если банк своими силами способен решать свои проблемы и не платить за это просто неприличные деньги разработчикам АБС, то честь ему и хвала.
                                      Вот тут хотелось бы уточнить: а "свои силы" требуют "приличных" денег, Вы совершенно в этом уверены?
                                      А то, что при этом банк попадает в зависимость от разработчиков, так это утопия.
                                      У меня есть три конкретных примера банков, находившихся в зависимости от разработчика. И только в одном из этих примеров разработчик согласился сотрудничать в проекте перехода на "промышленную" АБС. А остальные 2 примера-банка пострадали весьма сильно.
                                      Если разработка ведется на какой-нибудь более менее стандартной базе данных, по которой можно найти специалистов, если клиент пишется на более менее распространенной системе типа Delphi, то заменить исполнителей программистов не проблема. Заменить всю команду - проблема, но тоже решаемо.
                                      Вспоминается классика: "Тот, кто придумал фразу - Легко, как отнять леденец у ребенка, никогда не пробовал отнять леденец у ребенка". Разобраться в 2-3Мб исходных текстов на С++... Хм, воистину "гвозди бы делать из этих людей...". И, кстати, не совсем понял при чем тут СУБД разработки? База данных как раз дело десятое...
                                      Вот заменить технолога - это проблема. Главное не допускать, что бы один человек совместил в себе три таких ипостаси. Но и это не проблема - при наличии неприличных денег, для оплаты замены технологии. Т.е. в конечном итоге все решается так или иначе деньгами.
                                      Вернемся к началу и спросим: Так может проще заплатить "неприличные" деньги разработчику, а не менять технологию время от времени?

                                      Комментарий


                                      • #20
                                        2Cost
                                        Нельзя никому платить "неприличные" деньги, если один раз заплатишь, то потом из тебя будут веревки вить. Постоянно напрягать со сроками, надувать щеки, что проблема должна быть решена "комплексно", а оказывается все можно сделать за день на коленке. Ну не могут программы стоить так дорого.
                                        Сразу скажу, что никто меня не убедит в обратном.
                                        Аналитический, прогнозирующий софт - с некоторыми допущениями может стоить "неприличных" денег. Но там хоть будет видна работа мозга разработчика.

                                        Комментарий


                                        • #21
                                          Cost
                                          Вот тут хотелось бы уточнить: а "свои силы" требуют "приличных" денег, Вы совершенно в этом уверены?
                                          Нет не уверен. У меня только пара случаев подобной статистики. И один обратный случай.

                                          У меня есть три конкретных примера банков, находившихся в зависимости от разработчика. И только в одном из этих примеров разработчик согласился сотрудничать в проекте перехода на "промышленную" АБС. А остальные 2 примера-банка пострадали весьма сильно.
                                          Я как раз в таком пострадавшем банке работаю и рядом наблюдаю несколько таких. Я пожалуй более скажу, ВСЕ банки находятся в зависимости от разработчика. Важно отношение разработчика в банку.

                                          Разобраться в 2-3Мб исходных текстов на С++...
                                          Так хоть возможность есть. Многим достаточно возможности, а уж есть ли желание ее реализовать...

                                          И, кстати, не совсем понял при чем тут СУБД разработки? База данных как раз дело десятое...
                                          Наверно это уже из области технологий. Но у меня вся логика реализована внутри базы данных на сторед-процедурах. Сделано это было по острой необходимости: 1. мне надо было писать и запускать в работу различных клиентов (на Delphi и на PHP) и 2. систему защиты данных достаточно гибкую делать. Поэтому абсолютно все действия с данными происходят посредством специально написанного АПИ. Насколько я могу судить по косвенным данным, диасофт 5нт организован аналогично. Оно и правильно - методы обработки данных находятся вместе с данными, чем не объектный подход. А всякое баловство типа select'ов для клиентов вообще запрещено. Только через разработанный АПИ.

                                          Так может проще заплатить "неприличные" деньги разработчику, а не менять
                                          технологию время от времени?

                                          Вот тут я с вами полностью согласен. Только баланс надо бы соблюдать. Т.е. сравнить - что дешевле, и что быстрее окупится. Если замена технологии позволит вам развивать новое направление бизнеса, которое окупит за пару месяцев эту самую замену, ну неужто вы откажетесь?

                                          Комментарий


                                          • #22
                                            AlexCH
                                            Так хоть возможность есть. Многим достаточно возможности, а уж есть ли желание ее реализовать...
                                            Я пока только реплику брошу по ходу дела
                                            Если меня позовут и скажут: Василий, а нарисуйте нам вот то-то и то-то с нуля, пожалуйста, - я подумаю и возьму N кг. денег
                                            Если меня позовут и скажут: Василий, а перепишите (допишите) нам вот то-то и то-то, тут до Вас делали, вот сорцы , пожалуйста, - я подумаю, и возьму 2*N кг. денег

                                            Почему - думаю нет необходимости объяснять
                                            Вот и смотрите, что дешеле

                                            Комментарий


                                            • #23
                                              Посторонний Но изучая имеющиеся на рынке системы заметил, что большинство из них тяготеют к закрытому варианту. Может быть это я один такой? Или не понимаю чего-то важного? Как видно из ответов - Вы не одиноки. Но мировая практика показывает, что API - магистральный путь, а полная открытость - только временное решение...

                                              shmyga Мне кажется вы говорите не о нормальных системах... точнее не от хорошей жизни. С Вами, уважаемая shmyga, полностью согласен (и уже не в первый раз ).
                                              shmyga есть ещё довод, и он уже больше к оценке рисков - банк (либо другая контора) попадает в зависисмость от такого "писателя"... ... при том, что уровень его ответственности - не выше его месячной зарплаты

                                              Pif Мне, кстати, по барабану, в скольких там банках разработчик это катал, мне важно, чтобы у меня работало. Тоже верно. Вот только это Вы узнаете только после покупки и установки системы. А часто нужно знать "ДО"...

                                              fplab Риск, конечно, есть, но "жизнь хороша, хороша вдвойне, коль ей рисковать умеешь".
                                              Насчёт ТАКОГО риска ... это Вы владельцу Банка когда-нибудь объясняли???

                                              AlexCH Если из АБС выкинуть все, кроме бухгалтерии, так и стоить будет то самое, что и 1с. Оно так и стоило, пример - киевский опердень ... по моему, после достопамятного распределения Киевского ОДБ в качестве ПО для бывщих жилсоцбанковских контор, исходники свободно ходили по всей Руси и бывшему Союзу.

                                              AlexCH ВСЕ банки находятся в зависимости от разработчика. Важно отношение разработчика в банку. И ещё лучше с этим "отношением" определиться ещё ДО выбора "бизнес-партнёра в технологическом развитии Банка" (самоцитата ).
                                              Да пребудет с Тобою Великая Сила! ©

                                              Комментарий


                                              • #24
                                                К_Маркелов
                                                А как раз в ТАКОМ банке и работаю. И довольно давно и довольно успешно. Многое зависит от, как Вы говорите, самого владельца. Если он что-то соображает в автоматизации (а это, увы, редкость), то он способен понять и доводы в пользу открытых систем, проанализировать и сравнить плюсы и минусы от обоих подходов.
                                                Я, собственно, к чему веду. Ядро (т.е. та часть, что взаимодействует с БД) пусть будет закрытой (проприетарной, частнособственнической, патентованой - как угодно называйте) и поставщик этого ядра должен быть серьезной фирмой. Это, своего рода, низкоуровневый слой. А все остальное - я должен иметь возможность делать сам (другое дело есть ли у банка желание и, главное, кадры для этого).

                                                Комментарий


                                                • #25
                                                  fplab А как раз в ТАКОМ банке и работаю Извините, дружище Плейшнер, я не удержался... Посмотрел Вам в профиль профессора... А там так и написано: Ваш банк (компания) Банчок ... То есть, с чувством юмора у Вас - полный порядок... ...
                                                  Без обид, ладно? Владельцу - большой и искренний привет
                                                  Уважаемый ALL и персонально fplab !!! Мои извинения за этот офф-топ...
                                                  Да пребудет с Тобою Великая Сила! ©

                                                  Комментарий


                                                  • #26
                                                    Какие обиды ! Все нормально. Привет передам всенепременнейше !!!
                                                    В свою очередь прошу пардону за офф-топ. Надеюсь, модератор снисходительно отнесется к этому топику

                                                    Комментарий


                                                    • #27
                                                      Посторонний и All

                                                      Несколько некорректна постановка темы. Объектность и открытость - это не есть взаимоисключающие понятия. Я не ратую за закрытость, я говорил за открытость, но открытость высокоуровневую. API это и есть "открытость" системы, дающая возможность ее (системы) доработки. Я непротив открытости СУБД, но против свободного, открытого доступа в нее (в рамках АБС, разумеется).
                                                      Для иллюстрации возьмем ООП. Зачем при разработке классов используют области видимости (Visibility). Всякие там public, protected, private?
                                                      Пож-та, используйте объекты - экземпляры этого класса или его наследников, но только не надо менять такие-то members или дергать закрытые методы. Они определяют логику объекта, его поведение.
                                                      Я же не говорил, что нельзя давать доступ к СУБД (а именно вокруг этого был спор). Мое мнение, что этот доступ должен быть "завернуть" в соответствующие объекты и методы, которые должны составлять некую прослойку между физикой и прикладным кодом. Что это дает? Это дает еще большую независимость от разработчика в плане использования СУБД. Сегодня у вас одна, а завтра производительность ее не устраивает, вы хотите перейти на промышленную. При таком подходе, этот переход будет с наименьшими потерями, при условии неизменности структуры БД. Не надо говорить о стандартах языков ANSI. Мы все прекрасно знаем, что у каждой реализации любого языка есть свои отступления от стандарта и SQL - не исключение.
                                                      Жить надо так, чтоб тебя помнили сволочи!

                                                      Комментарий


                                                      • #28
                                                        alanf
                                                        Я непротив открытости СУБД, но против свободного, открытого доступа в нее (в рамках АБС, разумеется).
                                                        Для иллюстрации возьмем ООП.
                                                        У меня вот проблема возникла. Из допофиса множество всяких бумажек присылают. Мне вменили в обязанность ставить на каждую штампирку "получено электронно", время и подпись. Спросил - а можно печатать все это, сказали можно. Купил FastReport, у которого анонсирована возможность внесения изменений в готовый отчет. Начал разбираться, а там тот самый метод, который собственно и сохраняет внесенные изменения, в private области находится.
                                                        Резюме. Без исходных текстов я и не разобрался бы и, естественно, использовать не смог бы.
                                                        Я думаю все коллеги по банковскому бизнесу попадали в подобные ситуации. Зачастую не с поставленной задачей приходится разбираться, а с логикой ее конкретной реализации. Что бы понять логику, лучше иметь все!!! И АПИ, и исходные тексты, и описание, и советы коллег, и варианты решений подобных проблем. И, как сказал vsv - тут до Вас делали, вот сорцы , пожалуйста, - я подумаю, и возьму 2*N кг. денег.

                                                        Комментарий


                                                        • #29
                                                          AlexCH
                                                          Т.е. вы согласны платить за сорцы? А это не как Вася сказал 2*N, это N в квадрате, да и ни кто Вам их не продаст - это собственность. Если только АБС не будет Freeware Не надо сравнивать FR и подобное с АБС.

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

                                                          Без исходных текстов я и не разобрался бы Отсутствие документации - вот проблема. Эту задачу можно было решить и без исходников. Во-первых, любой компилятор ругается на access к закрытым методам/свойствам. А для определения структуры объекта есть Header-ы или Object explorer-ы, опять же при отсутсвии доки. Изменение Visibility в описании declaration без изменения самого кода (impl) будь он в obj, dcu, lib проблему решает.

                                                          А vsv хотел сказать (посмею предложить свою "интертрепацию"), что копаться в чужих исходниках - дело неблагодарное. Когда код носит прикладной характер (т.е. его не так много), это еще можно себе позволить, а когда это системообразующий код (движок, логика) - это перебор. И опасно, очень.
                                                          Жить надо так, чтоб тебя помнили сволочи!

                                                          Комментарий


                                                          • #30
                                                            что копаться в чужих исходниках - дело неблагодарное.
                                                            Именно

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X