На чому писати проект?

[miwa]

У світлі останніх гілок виникла ось задумка...
Маю кілька замовлень на автоматизацію складу, каси та виробництва у нашому містечку. По ряду причин потрібно саме писати програми з нуля, а не використовувати існуючі. Первинно хотів (інерція мислення ;о) ) писати на звичних для мене дельфі+інтербейз, але подумав ось, що є чудова нагода перевести хоча б одне маленьке містечко на лінукс  

Власне задача - відносто прості програми для дрібних магазинів, пекарень і т.п.: порахувати, скільки товару по якій ціні придбано, та по якій продано і скільки ми на цьому заробили/втратили (спрощую, звісно - порожня база даних наразі налічує кілька по десятків таблиць, збережених процедур, доменів і т.п.; джерельні коди пре-альфи чорновика на дельфі - півмегабайта).

Основний момент - інтенсивне використання штрих-кодів, котрий на com-порт вішається, тому робити щось кросплатформенне з інтерфейсом у броузері не вийде.

Власне - хто що може сказати "з приводу"?

З.І. Ось, до речі, хороший метод переводити дрібні підприємства на лінукс: практично ніде (по крайній мірі у нас) 1С їм не підходить - надто громіздка, неповоротка, важко перенаналаштовується під забаганки конкретного ПП і чинного законодавства (у всякому разі, НМВ, добре сконфігурувати 1С не набагато легше, аніж написати щось своє "з нуля").

[235]

^{Як образливо, коли набрав до дідька й якусь фігню робиш, що все попадає}

Трохи наболівша для мене тема - декілька років тому підтримував складську бухгалтерію, що написана на Delphi+MySQL. Код Delphi формо-орієнований, тому розібратися в ньому було страшно - форматування немає, осмислених назв компонентів теж, а річ велика. MySQL показала відверто свої недоліки, те що з-за різних глюків M$ середовища все падає іноді й б'єть база, це одне. Наспавді проблема в тому, що сам MySQL ще не доріс до стандартів баз данних й є неповноціннию в цьому плані. Відсутність foreign key й відносно нерідкі втрати крос-записів самим додатком, що мусить утримувати всю логіку, призводило до потреби вручну відловлювати осиротілі запили, що суттєво підглюкували роботу системи. Доречі, касовий апарат теж любить глючити, як виявилося нарікання на цю модель датексу були не лише у мене. Набув серйозний скептис можливості розробки серйозних додатків у форм-орієнтованих середовищах (читай Delphi, май на увазі Lasarus) й базах данних на зразок того ж MySQL, що насправді не давали нічого більше зберігання й простих виборок таблиць.

Далі розробляли цікаву спеціалізовану облікуву систему на базі PostgreSQL, що містила в базі також всю логіку за допомогою влаштованих процедур/тригерів/зв'язків, аутентифікація на основі бази, власні логи вела, доступ клієнтського додатку чере вже відформатовані під користувача в'юви. Сам клієнтський додаток - простий й легкий, лише потрібно відмітити гарно був зконструюваний щодо юзабіліті й в ідеалі мав би бути доведений до автогенерування форм.
Postgres з 8ї версії вже має добре працювати у M$, потрібний лише тюнінг швидкості роботи, тоді відлагоджували через cygwin.

Мали займатися розробкою більш повноцінної системи складського обліку, але далі розгорнутих аналізів й проектування не пішло. Особливо не жалкую. Можу порекомендувати брати за базу хорошу СУБД й розробляти на ній логіку на зразок Postgres (не MySQL). Клієнт простий й має забезпечувати автогенерування форм  правки/вставки/виборки/роботи + система генереції заданих звітів.

Все-таки раджу звернути увану на наступні проекти (трохи застарівші лінки мо):
iceB http://www.iceb.vc.ukrtel.net/ - Вінницькі, працюють непогано, не знаю сучасного стану, але раніше були текст-орієнтовані, графічний робили як простий дубляж тексту трішки краще відформатованого
ananas http://ananas.linux.ru.net/ - розвивають
tinyERP http://tinyerp.com/ - нова система, цікава, думаю дивитися детальніше.

інше/так собі:
SQL-Leder - http://www.sql-ledger.com/ - веб-орієнтована
BananaPos - http://bananapos.com/pos/features/screen.html
http://eas.linux.ru.net/ - ой не пам'ятаю, але щось звідти
.....

можливо ще з часом зможу поділитися якимись надумками, як знайду в пошті своїй

[balu]

Uran, власне написав приблизно те, що сказав и би і я. Єдине, що я можу підкинути - мою чернетку, де є автогенерація форм, відповідно запитів і таке інше. Це написано на Pithon+Tkinter, орієнтовано на firebird. Рішення працює під Лінукс і форточки.
Зараз я б робив все по-іншому. Якщо там буде Лінукс і ніколи не буде Винди я робив-би на Python+PyQT - делфі відпочиває.
Щодо друку всяких звітів, то вибір обмежений http://reportman.sourceforge.net/ або ручками в пдф.
До речі, Уран не тикнув носом на http://gnuenterprise.org/ - під віндою він у мене не стартонув, на відміну від Дебіана (в якому він є). До речі система звітності там є. Є також аналог access-у http://www.koffice.org/kexi/ Здається і віндовий варіант там присутній. Але з ним я не ковирявся.
Удачі.

[Володимир Лісівка]

^{Як образливо, коли набрав до дідька й якусь фігню робиш, що все попадає}

MySQL показала відверто свої недоліки, те що з-за різних глюків M$ середовища все падає іноді й б'єть база, це одне. Наспавді проблема в тому, що сам MySQL ще не доріс до стандартів баз данних й є неповноціннию в цьому плані. Відсутність foreign key й відносно нерідкі втрати крос-записів самим додатком, що мусить утримувати всю логіку, призводило до потреби вручну відловлювати осиротілі запили, що суттєво підглюкували роботу системи.

Використовуйте InnoDB як тип бази та MySQL 4.1, 5.x - там є і FK і транзакції. Плюс не забудьте підтюнити MySQL під свої потреби - подивіться в "SHOW STATS;" де які ліміти недостатні й збільшіть їх. Я зараз цілком задоволений надійністю MySQL з InnoDB (база - 2x900M, кількість запитів зараз: 80-100 тсч. на день).

Я користувався цими статтями коли тюнив MySQL:

http://www.databasejournal.com/features/mysql/article.php/10897_1402311_3

http://www.databasejournal.com/features/mysql/article.php/3367871

Хоча якщо не потрібна висока швидкодія на простих селектах і кластеризація, то краще користуватися чимось іншим, більш розвинутим, напр. PostgreSQL.

[235]

Використовуйте InnoDB як тип бази та MySQL 4.1, 5.x - там є і FK і транзакції. Плюс не забудьте підтюнити MySQL під свої потреби - подивіться в "SHOW STATS;" де які ліміти недостатні й збільшіть їх. Я зараз цілком задоволений надійністю MySQL з InnoDB (база - 2x900M, кількість запитів зараз: 80-100 тсч. на день).

в той час найкращим була MySQL 3.23 й мови про FK й не було, повертатися на стару роботу робити реінжениринг й переносити - пуття всеодно з того додатку вже не буде. А в сучасних поняттях InnoDB має поки сильно обмежений SQL синтаксис, наскільки пам'ятаю немає мови поки про вкладені запити та інше (можливо не в курсі останніх подій) та якісь в новинах пробігали проблеми щодо подальшого залучення InnoDB в MySQL й останній грозився все переписати. Далі - основна логіка таки залишатиметься в зовнішньому додатку, тому всі його глюки таки проявлятимуться на даних доки не буде тригерів/процедур/в'ювів. MySQL в цьому плані залишається базою для простих та за рахунок цього швидких вибірок на базах без логіки.

Я користувався цими статтями коли тюнив MySQL:

дякую, подилюся також. З досвіду маю сказати що найбільший тюнінг - в правильній побудові бази, правильних вибірках та правильній індексації. Просто прозріваю яку фігню роблять горе PHP-"програмісти" й на скільки порядків! вдається покращити роботу просто слідуючи елементарним знанням роботи з СУБД.

[k0l0b0k]

Особисто я б радив Вам використовувати Mono та PostgreSQL для такого класу задач. З Mono найменше проблем при розробцi ПЗ, помилки в якому можуть коштувати дуже дорого, до того ж iнфраструктура Mono/.net на сьогоднiшнiй день досить сильно розвинута. Ну а Postgre - IДВВ (це по типу ИМХО  ), надiйна i швидка СУБД.

[Praporshic]

Особисто я б радив Вам використовувати Mono та PostgreSQL для такого класу задач. З Mono найменше проблем при розробцi ПЗ, помилки в якому можуть коштувати дуже дорого, до того ж iнфраструктура Mono/.net на сьогоднiшнiй день досить сильно розвинута. Ну а Postgre - IДВВ (це по типу ИМХО  ), надiйна i швидка СУБД.

Стосовно надійності постгресу - питань немає. Нащадок Ingres від якого пішов найвідоміший Oracle - це звісно річ. А от про моно такого сказати не можу. НМД - краще подібні речі не чіпати. Краще вже Java. Свого часу (десь півроку тому) виникла потреба у GUI для приймання-відсилання факсів. Одни з варінатів був на Mono. Від єдиний окрім помилок середовища нічого не видав.

[rangel]

Тут звучали слова про Python.
Ми використовували зв'язку Python+wxPython+PostgreSQL виходило досить не погано. Код працював і в Вінді і в Лінуксі. Досить багаті можливості, в тому числі і при друці звітності.

[Soft]

У світлі останніх гілок виникла ось задумка...
Маю кілька замовлень на автоматизацію складу, каси та виробництва у нашому містечку. По ряду причин потрібно саме писати програми з нуля, а не використовувати існуючі. Первинно хотів (інерція мислення ;о) ) писати на звичних для мене дельфі+інтербейз, але подумав ось, що є чудова нагода перевести хоча б одне маленьке містечко на лінукс  

Netbeans(java)+Jdbc+Fb 1.5 Stable а для Java є пкети під Win та Lin котрі працюють з LPT та COM портами.

[intracer]

Може спробувати mono + boo (python like language for .net)

[Rainbow]

Щодо СУБД, то найкращий варіант, як на мене PostgreSQL.
Щодо ГКІ, то Qt.
В свій час писав кросплатвормові речі на цій звязці. Працює все просто супер. Перевірено досвідом.

[administr]

Цікава тема написання плагіна до броузера з доступом до ком порта, або
чи можливо це зробити на javascript.

[Володимир Лісівка]

Цікава тема написання плагіна до броузера з доступом до ком порта, або
чи можливо це зробити на javascript.

Ну якщо JS має доступ до файлової системи, то var comport=new File("/dev/ttyS0");  

[235]

Ну якщо JS має доступ до файлової системи, то var comport=new File("/dev/ttyS0");  

звісно має, але тільки по переповненню стека