Почему нет отечественных программ для бизнеса?

[skmdeveloper]

Я имею ввиду метод разработки ПО. Синдром Windows - это настойчивое изобретение велосипедов. Есть разработанные и проверенные технологии. Именно их и нужно использовать. Например Qt + PostgreSQL + привязка к развитому скриптовому ЯП хватит практически для всего.

[watashiwa_daredeska]

Например Qt + PostgreSQL + привязка к развитому скриптовому ЯП хватит практически для всего.

Это никоим образом не избавляет от

атавизмы типа монолитных программ, бизнес-логику в СУБД и пр.

А по поводу Философии Юникс вот:

Unix — нифига не дружелюбная система.
Представьте себе человека, который большую часть времени молчит, а говорит предельно четко, кратко и только по делу. В глазах окружающих такой человек будет выглядеть хмурым занудой. А вот если он чешет языком, как помелом, улыбается, каждые 5 минут перезванивает и интересуется: «Кагдила? Тыгде?» — вот это крайне дружелюбный человек.
Так вот, программы Unix следуют правилу: «Rule of Silence: When a program has nothing surprising to say, it should say nothing» (http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878450), а людям нравятся весёлые, общительные и, желательно, чтобы не грузили всякой заумью.

[trdm]

Я имею ввиду метод разработки ПО. Синдром Windows - это настойчивое изобретение велосипедов. Есть разработанные и проверенные технологии. Именно их и нужно использовать.

софистика.
Дело не в технологиях, а в авторе программы. Его личность всегда накладывает на программу свой особенный неповторимый оттенок. Люди не роботы.

[skmdeveloper]

А по поводу Философии Юникс вот:

Согласились бы вы работать с бухгалтерской программой в которая бы радостно подмигивала пользователю? Мы уже видели приплясывающего жизнерадостного идиотика в одной из версий MS Office...

Дело не в технологиях, а в авторе программы. Его личность всегда накладывает на программу свой особенный неповторимый оттенок. Люди не роботы.

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

[trdm]

Дело не в технологиях, а в авторе программы. Его личность всегда накладывает на программу свой особенный неповторимый оттенок.

Это и есть изобретение велосипеда.

я тебе не понимаю. И наверное мне этого уже не хочется.

[watashiwa_daredeska]

Согласились бы вы работать с бухгалтерской программой в которая бы радостно подмигивала пользователю?

Я бы ни с какой не согласился — не мой профиль :) Поэтому бухгалтерские программы пишут не для меня и спрашивать надо не у меня.

[Voral]

Я имею ввиду метод разработки ПО. Синдром Windows - это настойчивое изобретение велосипедов. Есть разработанные и проверенные технологии. Именно их и нужно использовать. Например Qt + PostgreSQL + привязка к развитому скриптовому ЯП хватит практически для всего.

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

Впрочем. Можете более конкретно идею сформулировать? На общих понятиях то понятно все легко "опустить".

[skmdeveloper]

В общих чертах.

Программа обязательно должна быть модульной.

Снизу вверх.

1. Самая нижнеуровневая часть - Самые базовые классы и уровень взаимодействия с БД.
2. Реализация метаданных и объектов. Только через п.1.
3. Слой взаимодействия с GUI. Он уже не обязателен. Если планируется ПО с веб-интерфейсом тут привязка к какому либо скриптовому языку.
4. Подсистема генерации отчетов.

Этих пунктов достаточно для написания приложений на С++.

5. Привязки к скриптовым ЯП. Я пробовал Ruby, но вариантов может быть несколько.

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

[trdm]

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

[skmdeveloper]

Это высокоуровневые части иногда можно писать "как придется". На нижнем уровне глюки всей системы вплоть до и неработоспособности гарантированы.

[BIgAndy]

1. Самая нижнеуровневая часть - Самые базовые классы и уровень взаимодействия с БД.
2. Реализация метаданных и объектов. Только через п.1.
3. Слой взаимодействия с GUI. Он уже не обязателен. Если планируется ПО с веб-интерфейсом тут привязка к какому либо скриптовому языку.
4. Подсистема генерации отчетов.

5. Привязки к скриптовым ЯП. Я пробовал Ruby, но вариантов может быть несколько.

вЫ ОПИСЫВАЛИ oPENoFFICE ? Таки тагда Ахха! причем именно с несколькими скриптовыми языками, java и сипипи.

[skmdeveloper]

1. Самая нижнеуровневая часть - Самые базовые классы и уровень взаимодействия с БД.
2. Реализация метаданных и объектов. Только через п.1.
3. Слой взаимодействия с GUI. Он уже не обязателен. Если планируется ПО с веб-интерфейсом тут привязка к какому либо скриптовому языку.
4. Подсистема генерации отчетов.

5. Привязки к скриптовым ЯП. Я пробовал Ruby, но вариантов может быть несколько.

вЫ ОПИСЫВАЛИ oPENoFFICE ? Таки тагда Ахха! причем именно с несколькими скриптовыми языками, java и сипипи.

Не понял насчет OpenOffice. Это самый неприемлемый из всех вариантов. Если уж на MS Office за всю историю не написано ни одного вменяемого приложения, то на ОО можно даже не пытаться. Все таки офисный пакет не средство разработки.

[BIgAndy]

Не понял насчет OpenOffice. Это самый неприемлемый из всех вариантов. Если уж на MS Office за всю историю не написано ни одного вменяемого приложения, то на ОО можно даже не пытаться. Все таки офисный пакет не средство разработки.

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

[Voral]

В общих чертах.

Хм. Ну так вроде как в этом "направлении" тут и пошла мысль (по крайней мере у меня).....

[skmdeveloper]

Но вы действительно описали модель опенофиса. Один в один.

OO уже не монолитное приложение и его можно поставить на сервер без иксов или организовать на нем сервер приложений? Или прикрутить его к PHP, Ruby, Python, Perl и т.д. одновременно? А потом писать программы, в том числе и веб-интерфейсом?
Мой вариант подразумевает возможность этого.

[skmdeveloper]

Хм. Ну так вроде как в этом "направлении" тут и пошла мысль (по крайней мере у меня).....

А нормальных вариантов придумать уже невозможно. Все прочее к сожалению, еще не до конца забытое старое.
Отсутствие модульности и расширяемости могут позволить себе только монополисты монстры типа 1С. Что они и делают, чтобы подсадить пользователей на иглу.

[BIgAndy]

OO уже не монолитное приложение

ъ
Ну, монолитным он был во времена stardivision. Как раз наоборот. Идеология UNO и базирующихся на них расширений показывает скорее обратное.

и его можно поставить на сервер без иксов

Конечно можно. Более того у нас он иногда применяется как конвертер doc/docx в ODF. На почтовом сервере.

или организовать на нем сервер приложений?

В принципе, не исключаю, но уж очень тяжеловесным решением это будет.
Хотя, если сравнивать современными приложениями, то приблизительно такое же
А зачем на сравнительно простую задачу crm/erp/товароучетку/бухгалтерию(ой) городить целый сервер приложений? Все можно реализовать внутри самой RDBMS.

Или прикрутить его к PHP, Ruby, Python, Perl и т.д. одновременно?

PHP, в принципе, можно, Вроде даже кто-то этим занимается на developer.openoffice.org Все остальное уже прикручено. Причем одновременно. Причем к этому можно присоединить java и с++

А потом писать программы, в том числе и веб-интерфейсом?

OOoXmlForms

Мой вариант подразумевает возможность этого.

Мой -нет, но, как говорят мушкетеры, пуркуа па?
Мой предусматривает двух-трех звенную архитектуру модульного приложения. Ибо большая часть бизнес-логики у нас прикручена на RDBMS. А от реализации на RDBMS два шага до web-based приложения.

Хотя мое мнение: на настоящий момент приложения с вебинтерфесом без использования, скажем ajaks,получаются очень тяжеловесными и генерящимим массу паразитного трафика.

Кроме того ООо решает проблемму кроссплатформенности практически автоматически.

PS
К сожалению у нас в стране за редким счастливым исключением, во многом, благодаря всяким клиперам и фоксам, принято использовать RDBMS как помойку с данными. А не как самостоятельное бизнес-приложение.
Например многие формы и отчеты у нас реализованы в голом CLI на bash|perl. Как в старые добрые времена. На черном экране зеленые пукоффки.
Успех такого подхода можно подглядеть (и я подглядывал) , например, у РЖД, Coca-Cola, ЧМК, и некоторых труЪ компаний, которым не все равно с чем работать. Которым все равно, огребают адынэс по самые гланды.
В той части применения вычислительной техники мне более близка идеология IBM.

[watashiwa_daredeska]

Ну, монолитным он никогда не был. Как раз наоборот. Идеология UNO и базирующихся на них расширений показывает, скорее, обратное.

Расширения, модули и прочая дребедень ни разу не означают «немонолитности». Особенно, в том смысле, который имеется в виду в упомянутой Философии Unix.

[skmdeveloper]

Я за то чтобы ПО работало из коробки. Программа обязана сама создавать таблицы в БД. В случае необходимости реорганизовывать базу данных. Если нужно добавить поддержку другой БД, то достаточно изменить несколько классов, и все ОК.
Если же мы превращаем ПО свалку из SQL-кода (не совсем совместимого у разных БД), то судьба множества "новационных" покойничков, которых сжила со света не идеальная , но простая в установке, обновлении и использовании 1С, гарантирована. Программа должна устанавливаться и обновляться исключительно "одним движением руки" из репозиториев или собираться из исходников с минимальным количеством широко распространенных зависимостей. Иначе это никому не нужно.

[BIgAndy]

Я за то чтобы ПО работало из коробки. Программа обязана сама создавать таблицы в БД. В случае необходимости реорганизовывать базу данных. Если нужно добавить поддержку другой БД, то достаточно изменить несколько классов, и все ОК.

Из коробки - это хорошо. только у всех свои предпочтения при настройке бизнес-процессов. Здесь все спотыкается о "простоту"

Если же мы превращаем ПО свалку из SQL-кода (не совсем совместимого у разных БД), то судьба множества "новационных" покойничков, которых сжила со света не идеальная , но простая в установке, обновлении и использовании 1С, гарантирована.

Ну, на данном этапе нет мегазадчи затмить адынэс своим блеском.
Кроме того кто мешаетвыбрать ииспользовать одну RDBMS? Кому нужно, перенесут процедуры в свои БД.

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

Что же может быть проще? tar{gz|bz] еще никто не отменял

[skmdeveloper]

ПО обязано обязательно работать из коробки. Как и в случае с 1С для внедрения должна быть достаточна доработка специфичных для конкретного бизнеса частей. Их если отбросить высосанные из пальца "идеи" аудиторов, не так уж и много.
Очередной "конструктор" никому не нужен.

[skmdeveloper]

Одно мне не понятно. Зачем использовать в разработке нового ПО идеи 15-летней давности? Все это мы уже проходили. Зачем изобретать фактически аналог VB или Delphi? Никаких плюсов у такого ПО перед этими уродцами не будет.

[BIgAndy]

Одно мне не понятно. Зачем использовать в разработке нового ПО идеи 15-летней давности? Все это мы уже проходили. Зачем изобретать фактически аналог VB или Delphi? Никаких плюсов у такого ПО перед этими уродцами не будет.

O_o Это вы про что????
Какие такие идеи 15-и летней давности? Ничего, что многие из идей даже большей давности используется в современнейших OLAP и OLTP системах? например,в SAP/R3. например, в WebSphare? Какие такие возможности этих технологий вас не устраивают?
Ничего, что Unix-time составляет >30 лет?
Или PHP/PERL/Pyton - мейнстрим технологического прогресса? Бизнес сообщество весьма консервативно в выборе средств... В прочем, кто мешает использовать новомодные "мейнстримовые" достижения? Лишь бы пупка зватило!
Ктож вам чем-то сможет помешать?

[watashiwa_daredeska]

Кроме того кто мешаетвыбрать ииспользовать одну RDBMS? Кому нужно, перенесут процедуры в свои БД.

Если я правильно понимаю, простота 1С в том, что она может работать без полноценной БД. Как только появляется полноценная DBMS, начинается геморрой с установкой и поддержкой этой DBMS. А большинству пользователей, скорее всего, и SQLite достаточно будет.

[skmdeveloper]

Одно мне не понятно. Зачем использовать в разработке нового ПО идеи 15-летней давности? Все это мы уже проходили. Зачем изобретать фактически аналог VB или Delphi? Никаких плюсов у такого ПО перед этими уродцами не будет.

O_o Это вы про что????
Какие такие идеи 15-и летней давности?
Ничего, что Unix-time составляет >30 лет?

Дело не во времени. Принципы UNIX намного опередили свое время и для многих становятся очевидными только сейчас. Ваши идеи с ПО написанном на офисном пакете + SQL - это махровый MS-Way эпохи Windows 95.
Хотя уже в это время 1С (для DOS) в отличие от конкурентов можно было дорабатывать без напильника и погружения в искусство SQL. Именно поэтому конкуренты или скончались или влачат жалкое существование.

[skmdeveloper]

Кроме того кто мешаетвыбрать ииспользовать одну RDBMS? Кому нужно, перенесут процедуры в свои БД.

Если я правильно понимаю, простота 1С в том, что она может работать без полноценной БД. Как только появляется полноценная DBMS, начинается геморрой с установкой и поддержкой этой DBMS. А большинству пользователей, скорее всего, и SQLite достаточно будет.

Хотим мы этого или не хотим все идет к тому. Сейчас каждый как раньше не пишет корявый сайт, а использует готовый движок и дорабатывает его. Притом эти движки поддерживают несколько разных БД. У десктопного ПО та же судьба.
Я понимаю когда речь идет о высоконагруженых системах, тут без тюнинга не обойтись. И то оптимизировать нужно точечно самые узкие места. А писать бизнес-логику на SQL это все равно что программировать на Ассемблере. Конечно круто. Но оправдано ли? И как это аукнется в сопровождении и тем более развитии проекта?

[BIgAndy]

Я понимаю когда речь идет о высоконагруженых системах, тут без тюнинга не обойтись. И то оптимизировать нужно точечно самые узкие места.

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

А писать бизнес-логику на SQL это все равно что программировать на Ассемблере. Конечно круто.

А что тут крутого? Это скорее как на бейсике писать, а не на ассемблере ;D

Но оправдано ли?

Как показывает наша практика - боле чем!

И как это аукнется в сопровождении и тем более развитии проекта?

А что там болжно аукаться?
Вот живой пример: денси:касса. У них там есть три таблички на Postgres: ware, ware_group, ware_barcode, в котрые вносятся соответсвтенно товары, группы товаров(автореккурентная табличка), штрих коды (их может быть более одного на товар),

Мы их заменили где запросами, где хранимыми процедурами, которые предоставляют такую же структуру данных, но теперь на торговых точках не надо отдельно формировать пакеты ля выгрузки и згрузки. Товар принимается в торговую зону одной формой. И иерархия товаров и налогов стала единой на всех кассах одним движением руки. Притом руками править ничего не пришлось. Slony все растащил по местам самостоятельно.

На все-про все ушло не более часа у одного человека. Включая создание соответсвующей формы на ООBase и сопровождающего правила в PL/PGSQL.
Бейсик-то все знают!

Я понимаю когда речь идет о высоконагруженых системах, тут без тюнинга не обойтись. И то оптимизировать нужно точечно самые узкие места.

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

А писать бизнес-логику на SQL это все равно что программировать на Ассемблере. Конечно круто.

А что тут крутого? Это скорее как на бейсике писать, а не на ассемблере ;D

Но оправдано ли?

Как показывает наша практика - боле чем!

И как это аукнется в сопровождении и тем более развитии проекта?

А что там болжно аукаться?
Вот живой пример: денси:касса. У них там есть три таблички на Postgres: ware, ware_group, ware_barcode, в котрые вносятся соответсвтенно товары, группы товаров(автореккурентная табличка), штрих коды (их может быть более одного на товар),

Мы их заменили где запросами, где хранимыми процедурами, которые предоставляют такую же структуру данных, но теперь на торговых точках не надо отдельно формировать пакеты ля выгрузки и згрузки. Товар принимается в торговую зону одной формой. И иерархия товаров и налогов стала единой на всех кассах одним движением руки. Притом руками править ничего не пришлось. Slony все растащил по местам самостоятельно.

На все-про все ушло не более часа у одного человека. Включая создание соответсвующей формы на ООBase и сопровождающего правила в PL/PGSQL.
Бейсик-то все знают!

[skmdeveloper]

Бейсик к счастью знают далеко не все. Я тоже уже не помню. Писал в последний раз лет 20 назад. Сейчас в школе давно изучают Паскаль.
Вы исходите из принципа "сделай сам". Я исхожу из принципа "готово к употреблению". Вы пилите ПО под себя. Мне по жизни приходится разгребать то что понаписали программисты - я занимаюсь сопровождением, обучением и консультациями. Вам ближе интересы программиста. Мне рядового пользователя.

[BIgAndy]

Сейчас в школе давно изучают Паскаль.

О! Тем более скриптовыйе языки будет просто освоить.

[skmdeveloper]

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