1. Система СRUD-ом как раз занимается. Обычная работа с реляционной БД.
2. Релизаций пулов много. Просто тот, который используем мы — хоть и самопальный, но нас устраивает. Зачем его менять на тот же c3p0? какой выигрыш от этого?
3. Вот это мне совсем непонятно. Вы серьезно предлагаете ВСЕ SQL-запросы обернуть в процедуры под эгидой «уборки мешанины»?
У нас есть задачи, которые связаны с тем, чтобы, например, получить данные в форму. Это обычный селект, и живет он в коде. А есть задачи обработки больших количеств данных внутри БД. Это мы пишем хранимой процедурой, т.к. иначе это будет очень медленно.
5. Нюанс есть, но я очень долго в него вникал. И вообще не очень понятно из документации, где надо писать префикс неймспейса, где не надо и почему. Там приведен только формат функции xpath.
6. Мы ни за что не боремся, просто удобно вести разработку в одной среде и SQL-запросов тоже. А выходит — нельзя.
Да, мы специально рассматривали базы данных, ориентированные на XML. Но у нас XML — это небольшая часть от всего объема, который нужно хранить в БД. И БД точно не для key-value mapping, а это проектная структура, данные в которую попадают с графических схем и затем их нужно обрабатывать.
Вообще у нас autocommit отключен в JDBC. Мы контролируем транзакции сами, например — если нужно сохранить графическую схему в БД, то она сохраняется только полностью, т.е. если все insert-ы прошли успешно, то мы делаем commit отдельно. Так вот — это делалось у нас всегда, и без addBatch.
И всеравно с addBatch быстрее.
По-моему, дело не только в транзакциях, но и в подготовке самого запроса. т.е. в механизме PREPARE в различных СУБД.
Spring я смотрел, но мне на тот момент показалось, что это довольно тяжеловесный фреймворк, который не стоит использовать только для задач подключения. Если использовать Spring — то через него нужно организовывать всю работу с БД. Хотя, наверное, это правильнее, мы еще попробуем оптимизировать эту часть.
XML-маппинг у нас сделан следующим образом: есть библиотеки графических объектов, которые при запуске системы загружаются в память. На этапе загрузки идет считывание файла XML-логики для каждого библиотечного элемента, на основе которой к графике объекта добавляются свойства. Для каждого свойства в XML прописаны тип, таблица и колонка БД.
Когда идет формирование SQL-запросов, то данные берутся из самих свойств, т.е. не с XML работаем уже, а с объектами-свойствами. И в коде ничего не хранится.
У нас тоже было практически единоличное мнение начальства против. За наше с коллегой «новый САПР» на презентации нас ругали на чем свет стоит.
У вас пожалуй посовременнее система, раз там есть прослойка к БД на C#.
А у нас разработка 80х кодов — С, Фортран, Shell, гора файлов, скриптов и бинарников. И куча ошибок.
так что просто не было другого выхода.
Занимаюсь разработкой «с нуля» новой версии САПР на основе старой немецкой. Причин было много — основные — крайне устаревшая модель системы 30летней давности, проблемы с пересборкой и и необходимость внедрения нового функционала.
Никаких графиков не чертил, а сначала изучал старую систему в течение 2х лет, занимаясь ее допиливанием и поддержкой. Когда стало ясно, что перспектива не лучшая, убедил начальство, что надо разработать систему заново на современных платформах (Java), и не старый код курочить, а писать понимая суть дела.
Затем написал ТЗ, рисовал кучу архитектурных картинок — просто, в Visio, без наворотов.
Потом были проектирование БД, споры с коллегами как лучше сделать, презентации новой системы.
Что-то рисовали конечно, но старый код и реализации вообще не копировали и не рефакторили. Брали за основу только принципы.
Сейчас прошло 2 года, над системой работали несколько человек, и на носу 2хтысячная SVN-ревизия. Новая система уже запущена.
Из собственного опыта:
У меня программист — начальница, и программист — молодая коллега (это не все, но самые близкие на работе).
Люди диаметрально противоположные по характеру, разные по возрасту и опыту. Начальница — 10 лет вела маленький кусок большой системы и писала всю документацию. Очень грамотный человек
молодая коллега — потрясающе за 2 года выучила язык Java, любую задачу на этом языке решает в рекордно короткий срок. Тоже быстро становится грамотным специалистом.
Есть одно не очень хорошее свойство, которое их объединяет: крайняя неактивность в освоении новых технологий и вообще попытках «объять необъятное». Мне кажется, что это свойство объединяет большинство женщин-программистов. Не хотят они узнавать ничего нового. Им нравится «статус кво» и больше ничего не нужно.
Но нас учили — что главное в нашей профессии — это постоянно «быть на плаву», ориентироваться в технологиях, понимать, КАК надо решать задачи. Иначе ты быстро станешь не нужен.
Пока я не встречал женщин-программистов с таким подходом.
Я в своей команде играю роль менеджера среднего звена. Работаем в НИИ, пишем САПР. Проект большой, несколько человек, 2 года уже проекту.
Вот как по-вашему, по позитивному:
При завершении каждой локальной разработки коллеги зовут меня и говорят — смотри.
Смотрю. Нахожу ошибки. Показываю. Иногда вообще бросается в глаза то, что сделано нелогично на мой взгляд.
Но на сообщения об этом все реагируют по разному.
И некоторые (не все!) даже обижаются, когда им говоришь что надо доработать.
Периодически начинают спорить. Часто спор на уровне — «кнопка должна быть слева» — «нет кнопка должна быть справа».
Как грамотный менеджер будет показывать людям на их ошибки, чтобы это никого не задевало?
Кстати, а действительно — было бы здорово. Сейчас у меня на работе — и джаббер, и почта, и документооборот, и система управления проектами+багтрекер, и система контроля версий.
А если все это окажется привязано к одной «корпоративной социальной сети»?
Бред? или новый виток корпоративного ПО?
Думаю, если выкинуть отсюда спам/рассылку, то получится раз в 20 меньше.
А вот что будет, если добавить все непосчитанные почтовые сервера интернета, не говоря уже о закрытых (т.е. работающих только в интранет)?
Эх, если бы это было так… Нет, есть еще .netbeans/var/cache/*. где частично лежат скомпилированные файлы классов, только с расширением .sig.
Очистку с построением делал раз 10 подряд. И удаление каталога build тоже не помогало. К сожалению, это мы проходили…
Надо признаться, я в данный момент (и не один, а с командой из 6 человек) переписываю старый проект.
Старый проект — САПР, разработан компанией Siemens в 70-80х гг под ОС HP-UX. Качественнейшая и современнейшая вещь для тех лет.
Получили лицензию, перенесли на платформу Linux из-за эмбарго США на поставки HP-машин.
Однако, последние 10 лет наблюдается страшная тенденция — система становится все хуже и хуже. Пересборка ряда модулей системы практически невозможна.
Под нее необходимо вести специальный дистрибутив ОС Linux. Обновление ядра Linux и glibc приводит к краху граф.редактора САПР.
+ постоянные жалобы пользователей и желание внедрить кучу новых возможностей.
Пару лет убеждал руководство прекратить танцы с бубном, и начать разработку своей такой же системы.
В конце концов убедил. С тех пор прошло еще 2 года, пишем на Java и чуть-чуть на C. Через 2 месяца — проверка на вшивость — первое внедрение.
Ну, вообще-то ничего не мешало. Так и делает до сих пор 2/3 команды. Но — с другой стороны — ведь обновляться все-равно придется рано или поздно. Скакать через 3-4 версии более рискованно, бывают несовместимости.
Еще сыграла популярность Eclipse и превеликое множество плагинов под нее.
А вообще думаю — новых членов команды сажать на Eclipse, а остальные пусть на свой страх и риск действуют.
Но тогда встает вопрос — как собирать проекты без привязки к среде. Видимо, придется еще изучать всякие штуки типа Maven…
он работает через JDBС, соответственно и слоны поддерживаются
2. Релизаций пулов много. Просто тот, который используем мы — хоть и самопальный, но нас устраивает. Зачем его менять на тот же c3p0? какой выигрыш от этого?
3. Вот это мне совсем непонятно. Вы серьезно предлагаете ВСЕ SQL-запросы обернуть в процедуры под эгидой «уборки мешанины»?
У нас есть задачи, которые связаны с тем, чтобы, например, получить данные в форму. Это обычный селект, и живет он в коде. А есть задачи обработки больших количеств данных внутри БД. Это мы пишем хранимой процедурой, т.к. иначе это будет очень медленно.
5. Нюанс есть, но я очень долго в него вникал. И вообще не очень понятно из документации, где надо писать префикс неймспейса, где не надо и почему. Там приведен только формат функции xpath.
6. Мы ни за что не боремся, просто удобно вести разработку в одной среде и SQL-запросов тоже. А выходит — нельзя.
И всеравно с addBatch быстрее.
По-моему, дело не только в транзакциях, но и в подготовке самого запроса. т.е. в механизме PREPARE в различных СУБД.
XML-маппинг у нас сделан следующим образом: есть библиотеки графических объектов, которые при запуске системы загружаются в память. На этапе загрузки идет считывание файла XML-логики для каждого библиотечного элемента, на основе которой к графике объекта добавляются свойства. Для каждого свойства в XML прописаны тип, таблица и колонка БД.
Когда идет формирование SQL-запросов, то данные берутся из самих свойств, т.е. не с XML работаем уже, а с объектами-свойствами. И в коде ничего не хранится.
У вас пожалуй посовременнее система, раз там есть прослойка к БД на C#.
А у нас разработка 80х кодов — С, Фортран, Shell, гора файлов, скриптов и бинарников. И куча ошибок.
так что просто не было другого выхода.
Никаких графиков не чертил, а сначала изучал старую систему в течение 2х лет, занимаясь ее допиливанием и поддержкой. Когда стало ясно, что перспектива не лучшая, убедил начальство, что надо разработать систему заново на современных платформах (Java), и не старый код курочить, а писать понимая суть дела.
Затем написал ТЗ, рисовал кучу архитектурных картинок — просто, в Visio, без наворотов.
Потом были проектирование БД, споры с коллегами как лучше сделать, презентации новой системы.
Что-то рисовали конечно, но старый код и реализации вообще не копировали и не рефакторили. Брали за основу только принципы.
Сейчас прошло 2 года, над системой работали несколько человек, и на носу 2хтысячная SVN-ревизия. Новая система уже запущена.
У меня программист — начальница, и программист — молодая коллега (это не все, но самые близкие на работе).
Люди диаметрально противоположные по характеру, разные по возрасту и опыту. Начальница — 10 лет вела маленький кусок большой системы и писала всю документацию. Очень грамотный человек
молодая коллега — потрясающе за 2 года выучила язык Java, любую задачу на этом языке решает в рекордно короткий срок. Тоже быстро становится грамотным специалистом.
Есть одно не очень хорошее свойство, которое их объединяет: крайняя неактивность в освоении новых технологий и вообще попытках «объять необъятное». Мне кажется, что это свойство объединяет большинство женщин-программистов. Не хотят они узнавать ничего нового. Им нравится «статус кво» и больше ничего не нужно.
Но нас учили — что главное в нашей профессии — это постоянно «быть на плаву», ориентироваться в технологиях, понимать, КАК надо решать задачи. Иначе ты быстро станешь не нужен.
Пока я не встречал женщин-программистов с таким подходом.
Вот как по-вашему, по позитивному:
При завершении каждой локальной разработки коллеги зовут меня и говорят — смотри.
Смотрю. Нахожу ошибки. Показываю. Иногда вообще бросается в глаза то, что сделано нелогично на мой взгляд.
Но на сообщения об этом все реагируют по разному.
И некоторые (не все!) даже обижаются, когда им говоришь что надо доработать.
Периодически начинают спорить. Часто спор на уровне — «кнопка должна быть слева» — «нет кнопка должна быть справа».
Как грамотный менеджер будет показывать людям на их ошибки, чтобы это никого не задевало?
Кстати, а действительно — было бы здорово. Сейчас у меня на работе — и джаббер, и почта, и документооборот, и система управления проектами+багтрекер, и система контроля версий.
А если все это окажется привязано к одной «корпоративной социальной сети»?
Бред? или новый виток корпоративного ПО?
А вот что будет, если добавить все непосчитанные почтовые сервера интернета, не говоря уже о закрытых (т.е. работающих только в интранет)?
Очистку с построением делал раз 10 подряд. И удаление каталога build тоже не помогало. К сожалению, это мы проходили…
Старый проект — САПР, разработан компанией Siemens в 70-80х гг под ОС HP-UX. Качественнейшая и современнейшая вещь для тех лет.
Получили лицензию, перенесли на платформу Linux из-за эмбарго США на поставки HP-машин.
Однако, последние 10 лет наблюдается страшная тенденция — система становится все хуже и хуже. Пересборка ряда модулей системы практически невозможна.
Под нее необходимо вести специальный дистрибутив ОС Linux. Обновление ядра Linux и glibc приводит к краху граф.редактора САПР.
+ постоянные жалобы пользователей и желание внедрить кучу новых возможностей.
Пару лет убеждал руководство прекратить танцы с бубном, и начать разработку своей такой же системы.
В конце концов убедил. С тех пор прошло еще 2 года, пишем на Java и чуть-чуть на C. Через 2 месяца — проверка на вшивость — первое внедрение.
Еще сыграла популярность Eclipse и превеликое множество плагинов под нее.
А вообще думаю — новых членов команды сажать на Eclipse, а остальные пусть на свой страх и риск действуют.
Но тогда встает вопрос — как собирать проекты без привязки к среде. Видимо, придется еще изучать всякие штуки типа Maven…