|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
Спасибо всем за отзывы. Отвечу на некоторые комментарии: авторЛАБ может коннектится к любой СУБД, поддерживающей ОДБЦ использование ОДБЦ категорически нежелательно авторНаконец, для полноты картины можно упомянуть Delphi/Kylix. Но не думаю, что это хорошее решение для данного случая; Kylix - штука мертворожденная и неподдерживаемая, ничего серьезного на нем не писали. В этом вы абсолютно правы. При всей моей любви к Delphi, Kylix в качестве возможного решения не рассматривается именно по этим причинам авторА кто будет разрабатывать Ваше "корпоративное приложение"? Внутренние специалисты? Внутренние специалисты. Сейчас они (и я в т.ч.) занимаемся поддержкой и доработкой корпоративного приложения, написанного внешним вендором много лет назад на VB и частично на Delphi. Существенными знаниями в java/PHP/C никто, увы, не обладает. Соотв. курсы будут фирмой обеспечены. авторНу а бизнес-логика живущая в базе - это, ИМХО, крайне неграмотное архитектурное решение... ну а это ВЫ, по-моему, зря. Грамотные ХП и хорошо розданные права доступа, имхо, во многих отношениях лучше, чем громоздкий клиент ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2006, 15:07 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
pavelvpДля DB2, например, ODBC является компонентом прямого доступа. Ничуть не возражаю. Как не возражаю против ADO-доступа к MSSQL. Но читайте фразу, на которую я отвечаю: м. ЛАБ может коннектится к любой СУБД, поддерживающей ОДБЦ. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2006, 16:35 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
paul310 Ну а бизнес-логика живущая в базе - это, ИМХО, крайне неграмотное архитектурное решение... А у меня есть положительный опыт реализации бизнес логики в базе. Правда это было организовано определенным образом: логические объекты с методами и свойствами (вплоть до отчетов). Унаследованные свойства от других объектов. Все это реализовывалось в хранимых процедурах. Клиент с базой работал через один системный класс(таблица в памяти с встроенными методами вызова хранимых процедур). Работа по клиенту заключалась в рисовании интерфейса. Для получения данных содается объект, которому задавалось назнание логического объекта и нужные свойства. И т.д. Очень удобно в разработке. Проетировщик проектирует логическтй объект, программист БД пишет интерфейс в виде ХП. Физическую реализацию может менять по своему усмотрению и при необходимости. Программист клиентской части быстро рисует интерфейс. У нас человек клинета делал вообще не зная SQL :) Детали интерфейса отработаны так, что процентов 80 изменений в проекте не затрагивали клиента. Даже добавление свойств в логический объект автоматически отрабатывалось в интерфейсе. Внутри объектов встроенные системы разграничения полномочий (навернутая), журнализация и т.д. Работает весьма эффективно, так как обработка всех данных производится внутри субд. А уж сопровождать (вносить изменения) вообще песня - перегенерил процедуру прямо при работающих пользователях... А наличие описания логических объектов (которые естественно регестрировались в системе) обеспечивает хорошую документированность системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2006, 20:16 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
А в DB2, однако в качестве языка хранимых процедур можно использовать Java ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2007, 06:42 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
Akni авторНаконец, для полноты картины можно упомянуть Delphi/Kylix. Но не думаю, что это хорошее решение для данного случая; Kylix - штука мертворожденная и неподдерживаемая, ничего серьезного на нем не писали. В этом вы абсолютно правы. При всей моей любви к Delphi, Kylix в качестве возможного решения не рассматривается именно по этим причинам Насчет Kylix - это печальный, но факт. Но что либо более адекватное, чем Delphi (и база, и наборы инструментария третьих сторон) - в настоящее время - не существует (кроме номинальных возможностей в .NET). Рассматривать Java инфраструктуру в "доступном массам" виде - тем более бессмысленно. Реально используемые практиками (как правило, очень большими компаниями) инструменты - мало имеют отношения к тому, что активно популяризуется в прессе и в "общественном мнении". Профессиональный же уровень (WebLogic и WebSphere), требует огромных финансовых вливаний (в лицензии, в обучение, в поддержку) с весьма непредсказуемым результатом. Akni авторНу а бизнес-логика живущая в базе - это, ИМХО, крайне неграмотное архитектурное решение... ну а это ВЫ, по-моему, зря. Грамотные ХП и хорошо розданные права доступа, имхо, во многих отношениях лучше, чем громоздкий клиент Все зависит от используемой СУБД и степени развитости этих языков в ней. Тем не менее, серьёзно рассматривать что либо, отличное от PL/SQL - я бы в принципе не стал (судя даже по документации от DB2, MS SQL, Interbase). Серверные слои на J2EE или .NET (встроенные) или в виде middleware (внешние) - это огоромный выстрел мимо по любым ТТХ (кроме случая - интеграции крайне зоопарковых/гетерогенных комплексов) Да, PL/SQL - это дорого, но в данном случае - это как раз лучший случай из категории: "скупой платит дважды, скупой дурак - трижды" ---- Тем не менее, наиболее разумным вариантом развития событий я бы назвал примерно следующее: Специфику (основную деятельность) бизнеса - лучше автоматизировать самим. Как правило, сюда попадают блоки: - продаж (+ CRM) - производства (впрочем, зависит от вида оного, к примеру - в случае дискретного производства - есть смысл взять готовый блок технической подготовки и нормирования) - логистика (как ни странно, но ее лучше - реализовать самому) В остальных же контурах (носящий регламентный общепринятый характер или не связанные с повседневной деятельностью предприятия), к примеру: - бухалтерский учет (вернее налоговый и консолидированный) - учет ЗП (именно расчет) - финансовое планирование и бюджетирование - документооборот Лучше применять тиражируемые и хорошо зарекомендовавшие себя решения с разумной ценой. К примеру (соотвественно) -1c, - 1с или Коминтех, - ??? (не знаю, не имел дела) - система Дело (ЕОС) И о зле "лоскутности" я бы говорить в данном случае - и вовсе не стал бы. Как правило, и в озвученных мной выше продуктах вопросы интеграции - давно решены, и в Oracle и MS SQL гетерогенные сервисы - давно уже отработанная и довольно адекватная тема ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2007, 09:18 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
Выскажу свое мнение. Все же Ява наиболее предпочтительный язык для вас, но... Для разработки своей системы берите готовый open source фреймуорк с активным сообществом. Если совсем с нуля то jboss. Но я бы посоветовал вам обратить внимание на http://adempiere.red1.org Это открытая ERP система в которой уже 80% есть того, что вам надо. Остальные 20% дописать гораздо проще. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2007, 10:48 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
Hi! grexhide Все зависит от используемой СУБД и степени развитости этих языков в ней. Тем не менее, серьёзно рассматривать что либо, отличное от PL/SQL - я бы в принципе не стал (судя даже по документации от DB2, MS SQL, Interbase). Серверные слои на J2EE или .NET (встроенные) или в виде middleware (внешние) - это огоромный выстрел мимо по любым ТТХ (кроме случая - интеграции крайне зоопарковых/гетерогенных комплексов) А вот тут поподробнее. С чего такой вывод? PL/SQL - далеко не самое удобное решение для построения серверов приложений с высокой производительностью. Да и удобство разработки - не очень. Существуют Cache и другие М-*, которые изначально созданы, как платформы для построения распределенных серверов приложений, в отличие от Oracle, DB2 и т.д. Господин MX - ALEX тут уже неоднократно высказывался. У меня есть свой подход к построению серверов приложений на Cache. Пока "огоромный выстрел мимо по любым ТТХ" не замечал. Системы работают быстро, с большими базами (около 200 Гб, 400 конкурентных соединений), на дешевых серверах, совершенно не требуют администрирования, обслуживание/обновление - дистанционное. ____________________________ С уважением, Лисеев Дмитрий. http://private.peterlink.ru/dimik/ PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73 Posted via ActualForum NNTP Server 1.3 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2007, 12:23 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
Dmitry V. LiseevА вот тут поподробнее. С чего такой вывод? Нет, нельзя. Идите в раздел - Сравнение СУБД и рассказывайте про свою cache. - Право, даже не смешно ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2007, 12:53 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
anjeyА в DB2, однако в качестве языка хранимых процедур можно использовать Java ;) Не только в DB2. В Informix тоже и еще C ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2007, 14:16 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
Hi! [quit grexhide]Нет, нельзя.[/quit] Забавный Вы человек: "На яве программировать не умею, про каше вообще не знаю, потому самая крутая система - Delphi, т.к. только ее я хорошо знаю". [quit grexhide]Идите в раздел - Сравнение СУБД[/quit] Причем тут СУБД? Речь шла о серверной бизнес логике. Или Tomcat Вы тоже к СУБД относите, потому что он на сервере стоит? Или потому, что Вы не знаете, что такое Tomcat? [quit grexhide]Право, даже не смешно[/quit] Дык, о том и речь. ____________________________ С уважением, Лисеев Дмитрий. http://private.peterlink.ru/dimik/ PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73 Posted via ActualForum NNTP Server 1.3 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2007, 05:04 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
grexhide Dmitry V. LiseevА вот тут поподробнее. С чего такой вывод? Нет, нельзя. Идите в раздел - Сравнение СУБД и рассказывайте про свою cache. - Право, даже не смешно +1 IMHO в топике не говорится о создании промежуточного сервера приложений. IMHO ООБД изврат (на данном историческом этапе) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2007, 13:39 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
Hi! Petro123 IMHO в топике не говорится о создании промежуточного сервера приложений. В топике говорилось о том, где и на чем писать бизнес-логику. Вариантов не так много. Можно делать всю бизнес-логику в клиенте на том, на чем написан клиент. Можно делать всю бизнес-логику в СУБД на том, на чем она позволяет (триггеры и хранимки на PL/SQL, T/SQL и т.д.). Можно делать ее на промежуточном уровне на PHP, Perl, ASP, JSP, Java и т.д. Petro123 IMHO ООБД изврат (на данном историческом этапе) "Не читал, но осуждаю" :) Cache не имеет отношения к ООБД. Это просто платформа для разработки распределенных приложений. Она может как хранить данные (быть в качестве СУБД, и даже изображать подобие РСУБД), так и сервером приложений. Как на разных физических серверах, так и "в одном флаконе". Можно в качестве СУБД использовать ORACLE, а бизнес-логику писать на Cache, можно наоборот, хранить данные в Cache, а бизнес-логику делать отдельно на PHP, Java или еще чем-нибудь (или на клиенте). Можно делать все в Cache, что существенно удобнее в разработке и сильно быстрее работает. Единственное, что нельзя делать на Cache, так это клиента. Тут уже говорилось о варианте, когда в качестве клиента используется Excel, а все остальное сделано на сервере Cache, есть масса вариантов, когда в качестве клиента используют браузер (DHTML, JavaScript или JavaApplet), а все остальное на Cache, есть варианты когда клиентов пишут на Delphi, C++ и т.д. На Cache делают программы, которые получают и сохраняют данные с разных девайсов или с модема через COM, работают с файлами, парсят и генерят XML, выполняют сложную обработку данных, включая сложные индексы и поиск (есть примеры построения полнотекстовых индексов) работают в качестве серверов или клиентов по TCP/IP (например SMTP, NNTP, FTP и т.д.). Ничего такого на СУБД сделать просто нельзя, потому бессмысленно сравнивать Cache и СУБД. В частности, для разработки этого форума не нужно ничего, кроме Cache (разве что WEB сервер еще желателен, типа IIS или Apache). Она может хранить сообщения и файлы, выполнять полнотекстовое индексирование и поиск, давать доступ как через HTTP, так и через NNTP. Просто там язык программирования специально заточен на обработку данных, в отличие от Pascal, C++, Java и т.д. Но при этом имеет больше возможностей, чем PL/SQL, соответственно не приходится разводить зоопарк из разных языков и технологий на сервере. Собственно, я своих архитектурных решений никому не навязываю. Просто потом не надо удивляться, почему у одних зарплата считается три часа на сервере стоимостью 20 килобаксов и требует админа с зарплатой 3 килобакса, а у других считается 15 секунд на трех серверах по колибаксу и никакого обслуживания вообще не требует. Единственное, чего делать не нужно, так это писать новый ответственный проект на Cache, если Вы о нем раньше не слышали. Собственно, это относится и к любой другой технологии (Java, C#, .Net и т.д.). Писать нужно только на том, на чем умеешь и знаешь. А самообразованием заниматься в отдельное время. ____________________________ С уважением, Лисеев Дмитрий. http://private.peterlink.ru/dimik/ PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73 Posted via ActualForum NNTP Server 1.3 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2007, 07:58 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
grexhideТем не менее, наиболее разумным вариантом развития событий я бы назвал примерно следующее: Специфику (основную деятельность) бизнеса - лучше автоматизировать самим. ... В остальных же контурах (носящий регламентный общепринятый характер или не связанные с повседневной деятельностью предприятия)... Лучше применять тиражируемые и хорошо зарекомендовавшие себя решения с разумной ценой Приблизительно так все и будет выглядеть. Бухгалтерия и зарплата имеют свой купленный софт, его трогать никто не собирается. Автоматизироваться будет следующее: -учет клиентов -обработка заказов (включая их жизн. цикл на предприятии, этапы техн. обработки и т.п.) -логистика -выставление счетов Бизнес-логика предполагается в базе в виде ХП, триггеров и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2007, 11:23 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
Akni grexhideТем не менее, наиболее разумным вариантом развития событий я бы назвал примерно следующее: Специфику (основную деятельность) бизнеса - лучше автоматизировать самим. ... В остальных же контурах (носящий регламентный общепринятый характер или не связанные с повседневной деятельностью предприятия)... Лучше применять тиражируемые и хорошо зарекомендовавшие себя решения с разумной ценой Приблизительно так все и будет выглядеть. Бухгалтерия и зарплата имеют свой купленный софт, его трогать никто не собирается. Автоматизироваться будет следующее: -учет клиентов -обработка заказов (включая их жизн. цикл на предприятии, этапы техн. обработки и т.п.) -логистика -выставление счетов Бизнес-логика предполагается в базе в виде ХП, триггеров и т.п. +1 конечно, т.к. - лезть в финансы дорого и на счётчик могут поставить . А остальные области автоматизации (перечисленные выше) слишком сильно завитсят от вИдения начальством бизнес-правил этих систем. Правда у всех решений есть недостатки (лоскутная автоматизация). Но применять ли ERP-решения, как более высокий уровень, зависит от масштабов IT-системы. IMHO ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2007, 11:51 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
Petro123Но применять ли ERP-решения, как более высокий уровень, зависит от масштабов IT-системы. IMHO а) реально работающая ERP система - это большая редкость б) то что работает, зачастую - с таким же успехом попадает под определение лоскутности (рассматривая внутреннюю структуру монстров) в) есть конечно, варианты "попроще", вроде 1с или Axapta, но им до ERP - как... пешком на юг. Забавно, конечно, но не стоит оно того (надежд). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2007, 12:24 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
grexhideВсе зависит от используемой СУБД и степени развитости этих языков в ней. Тем не менее, серьёзно рассматривать что либо, отличное от PL/SQL - я бы в принципе не стал (судя даже по документации от DB2, MS SQL, Interbase). Не хотелось бы впадать в разворачивающийся флейм, но это несколько запальчивое заявление. Вы знаете, серверную логику не только на Ораклах пишут... Nobody faults but mine... (LZ) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2007, 18:04 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
С появлением .NET FW 3.0, по мере ознакомления с "новыми придумками мокрософтов", меня одолевает(неутихая) фантазия создания КС-системы "терминального" типа: с одной стороны, в mssql 2005 заметно улучшилась работа с XML, с другой - в FW 3.0 (WPF & WF) есть XAML (специализированный для описания UI XML), т.е., сервер вполне может "отплевывать" клиенту XAML'ы, содержащие в себе и данные и описание UI-элементов и код (обработчиков событий и т.п.). Клиент превращает XAML собственно в "часть своего тела" (XamlReader), т.о. клиент получается чрезвычайно "тонким", соотв. вся система - чрезвычайно гибкой... Мда, фантазия еще не умерла...:) А, ну да, по теме ж главное - основной язык программирования - XML/XAML :)) (разумеется, немножко и t-sql + с# придется использовать ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2007, 20:55 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
LRА, ну да, по теме ж главное - основной язык программирования - XML/XAML :)) Я видел и такие примеры "кунсткамер" локального масштаба. Генерируемый на/из сервера БД XML (через PL/SQL) и "браузер", на .NET писанный, рендерящий вот это все удовольствие. Но по массе именно технических причин - я не стал работать с данной компанией и их технологией. Все это - было красиво в теории. А на практике - нулевая поддержка со стороны... IDE (основное IDE у них было - multiedit). Короче, в газенваген. --- При том, что XAML - это штука довольно интересная, и, возможно - будет и актуальная (через несколько лет). По одной простой причине - традиционные среды и языки разработки (если не брать WEB) не предусматривают банального (или делают это очень плохо) - масштабирования UI от текущего разрешения экрана. Об этом даже Тема Лебедев говорил. - Но опять же, XAML и иже - это далеко не панацея и не единственное возможное решение. К примеру - у меня уже запланирана серьезная перетряска подхода от жестко-пиксельного кодирования UI дизайна в delphi. Собираются материалы, прорабатываются вопросы автоматического layoutingа (по принципу web-а и его действительно весьма разумного <TABLE> и иже). И не так уж много труда придется приложить. Другой вопрос же - куда индустрию в целом понесет (те же самые SWT или WinForms-ы....) --- А проблема то в чем - человек в >40 летнем возрасте - перестает нормально (без напряжения зрения) воспринимать 8-пунктовый Tahoma (MS Sans Serif) шрифт на 17" TFT мониторе (1280x1024).... ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2007, 21:10 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
LRС появлением .NET FW 3.0, по мере ознакомления с "новыми придумками мокрософтов", меня одолевает(неутихая) фантазия создания КС-системы "терминального" типа: с одной стороны, в mssql 2005 заметно улучшилась работа с XML, с другой - в FW 3.0 (WPF & WF) есть XAML (специализированный для описания UI XML), т.е., сервер вполне может "отплевывать" клиенту XAML'ы, содержащие в себе и данные и описание UI-элементов и код (обработчиков событий и т.п.). Клиент превращает XAML собственно в "часть своего тела" (XamlReader), т.о. клиент получается чрезвычайно "тонким", соотв. вся система - чрезвычайно гибкой... Мда, фантазия еще не умерла...:) А, ну да, по теме ж главное - основной язык программирования - XML/XAML :)) (разумеется, немножко и t-sql + с# придется использовать ;) Какие к черту "новыми придумками мокрософтов" - Вы только что описали давно существующую технологию AJAX.... А из "новыми придумками мокрософтов" я могу назвать только ODBC ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2007, 05:06 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
grexhideЯ видел и такие примеры "кунсткамер" локального масштаба. Генерируемый на/из сервера БД XML (через PL/SQL) и "браузер", на .NET писанный, рендерящий вот это все удовольствие. Но по массе именно технических причин - я не стал работать с данной компанией и их технологией. О! Это про нас. Постараюсь отстоять честь конторы. grexhideВсе это - было красиво в теории. А на практике - нулевая поддержка со стороны... IDE (основное IDE у них было - multiedit). Короче, в газенваген. Сейчас уже добавился некий новый редактор XMLников клиентской части. Хотя я по привычке пользуюсь multiedit и мне лично это удобнее. grexhideПри том, что XAML - это штука довольно интересная, и, возможно - будет и актуальная (через несколько лет). По одной простой причине - традиционные среды и языки разработки (если не брать WEB) не предусматривают банального (или делают это очень плохо) - масштабирования UI от текущего разрешения экрана. А наш "браузер", на .NET писанный, это предусматривает. grexhideОб этом даже Тема Лебедев говорил. По-моему, по ссылке немного о другом. grexhideНо опять же, XAML и иже - это далеко не панацея и не единственное возможное решение. К примеру - у меня уже запланирана серьезная перетряска подхода от жестко-пиксельного кодирования UI дизайна в delphi. Собираются материалы, прорабатываются вопросы автоматического layoutingа (по принципу web-а и его действительно весьма разумного <TABLE> и иже). И не так уж много труда придется приложить. Другой вопрос же - куда индустрию в целом понесет (те же самые SWT или WinForms-ы....) Труда уйдёт не так уж и мало. А наша кунсткамера это всё уже умеет. Не торопитесь отправлять ближнего своего в газенваген :) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2007, 18:59 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
Так_забежал_просто Труда уйдёт не так уж и мало. А наша кунсткамера это всё уже умеет. Не торопитесь отправлять ближнего своего в газенваген :) Да нет, спасибо. Но в принципе - я был вполне благодарен этой организации (Китай-город ?) за то, что понял, насколько мне важна такая стандартная для IDE вещь, как Code complete. Это, конечно, может выглядеть немного странным, но с годами - у тебя вырабатывается масса рефлекторных привычек. А вот сидеть и рисовать в multiedit-е PL/SQL -ный код - это довольно мрачно. По банальной и простой причине - я никогда не задавался целью помнить, как точно называется вот тот самый 2435-й по счету реализованный метод, поле или имя процедуры. - А вот аргументация одного вашего сотрудника, о том, что пакеты лучше писать через SGML (или, не помню, какой то сильно древний язык форматирования), только ради того, чтобы не "делать работу дважды", реализуя пакет и его тело отдельно...... да право, действительно, это весьма осознанный ход, чтобы отказаться от PL/SQL Developer ;)))) При том, что нужно отдать должное - культура производства была очень даже впечатляющая, в целом. Но увы - то, что для одного может быть удобным, для другого - запросто заблокировать способность к продуктивной мыследеятельности ;)) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2007, 20:35 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
grexhideА проблема то в чем - человек в >40 летнем возрасте - перестает нормально (без напряжения зрения) воспринимать 8-пунктовый Tahoma (MS Sans Serif) шрифт на 17" TFT мониторе (1280x1024).... Хм. А много ли Вы видели "простых пользователей", работающих в 1280x1024, да еще и без Large Fonts? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2007, 13:10 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
softwarerХм. А много ли Вы видели "простых пользователей", работающих в 1280x1024, да еще и без Large Fonts? Скажем так - не видел ни одного ;)) С Large Fonts были замечены трудности, местами, даже у Microsoft продуктов ;( ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2007, 22:08 |
|
Выбор языка программирования
|
|||
---|---|---|---|
#18+
а просто интересно, что в результате выбрали? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2007, 20:09 |
|
|
start [/forum/search_topic.php?author=sr_arhimed&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
get settings: |
10ms |
get forum list: |
12ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
50ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 5214ms |
total: | 5400ms |
0 / 0 |