Игорь Артамонов

Допустим у нас стоит задача: нужно собирать неструктурированные html данные и извлекать из них структуру, или, точнее, информацию, т.е. система Text Mining/Information Extraction.

Вcе элементы этого процесса, конечно, должны где то хранится. И если конечную информацию можно структурировать, завести с десяток таблиц в БД, настроить связи и складывать туда, то входная информация по определению у нас не структурирована, ну или, как минимум, слабо структурированная. Если делать сложную структуру то из-за специфики нашей задачи нам будет очень сложно отследить целостность данных. К слову о сложности работы с такой структурированностью замечу что я попытался было нарисовать это подход, но не смог сделать чтобы это было внятно, без всего лишнего.

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

Как то так сложилось что при моем примерно 7-летнем опыте коммерческой разработки на Java я почти не имею опыта в EJB. Хотя это первое что спрашивают на собеседовании, я ведь проверял не так давно. Самое интересное, кстати, в том что многие собеседователи после кучи вопросов по опыту в EJB/WebSphere/JMS/пр., о том как это все им важно и пр., рассказывая о своих проектах, говорят что на практике все их проекты разрабатываются без какого либо EJB и прекрасно работают по Tomcat, а WebSphere получается лишь для веса. Возможно и потому что не серьезно сейчас предлагать решение без WebSphere/WebLogic + Oracle.

А мне всегда как то хватало связки Spring + Hibernate + Tomcat/JBoss, что в сущности дает тоже самое, но удобнее. Список можно продолжить добавив еще как минимум Acegi, AspectJ, и прочие решения умеющие хорошо и удобно решать свою отдельную задачу, многие легко взаимозаменяемы и дают очень неплохой синергетический эффект.
Читать далее »»

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

Чаще всего такие решения принимают когда поддержка текущей программы становится слишком дорогой, т.к. со временем изменения становятся все дороже и дороже. Ну и в итоге цена изменений становится совсем высокой и компания вынуждена выкинуть текущий продукт, и переписать все заново.
Читать далее »»

Бывает что при обновлении версии работающего приложения тратится иногда по нескольку часов на приведение структуры БД к новому виду. Ну т.е. добавление колонок, переименовывание, смена связей и пр. При этом DBA сидит и по diff двух инициализационных sql (для текущего приложения и для нового) пытается понять что менялось и как нужно прописать все эти ALTER TABLE ..., или того хуже UPDATE по хитрым условиям. Когда то, по неопытности, и мы так делали, при этом приложение клиента ждало (т.е. не работало) иногда по нескольку часов. Слава богу у них в это время была ночь и заказчик сладко спал, иначе бы много чего могли бы наслушаться.
Читать далее »»

Приведу небольшой список правил, на которые можно разумно ориентироваться при проектировании новой XML структуры. Это конечно не «истина в последней инстанции», и есть куча случаев когда некоторые из них совсем не подойдут, но в общем виде, как ориентир, ознакомится следует, чтобы не плодить xml документы с которыми невозможно работать.

1. Используйте атрибуты для одной группы

Выносите короткие значения из одной группы в атрибуты.
Лучше

<user name="John" sname="Smith"/>

чем

<user>
 <name>John</name>
 <sname>Smith</sname>
</user>

Читать далее »»