◎ Продолжаю собирать пожелания

Добрый день!

Ну, если бы выбирал я - я бы выбрал ScheduledExecutor-ы. Или вообще что-то стороннее типа Quartz - http://www.quartz-scheduler.org/. Мы его испоьзовали еще лет пять назад, и именно как замену стандартным средствам.

Что касается заявок - зависит от. Чем плох запуск по расписанию в этом случае - он происходит редко. Т.е. всегда существует определенный период, когда заявка уже недействительна, но еще не помечена. И если Вы своим запросом попадете в этот период - будет совсем не здорово. Так что тут смотреть надо по месту - если заявки портятся в полночь, а у вас гарантированный период бездействия с 11 вечера до 7 утра - в 0:30 можно запускать проверку. Если же у вас есть вероятность попасть в ненужный интервал - спасет только проверка по месту. Кстати, ничего особо плохого я в этом не вижу. По бизнес-логике проверка заявки должна присутствовать, а необходимость в отдельном запуске проверки отпадает.

Э-э-э... Вам удалось ввести меня в замешательство. Я, честно сказать, не вижу, что можно разжевывать. this является ссылкой на текущий объект. И это всё. Вы лучше задайте вопрос конкретный, что Вам непонятно. Постараюсь ответить.

Добрый день!

Вообще-то я достаточно подробно писал, зачем нужны пакеты, вот тут: http://www.skipy.ru/technics/likbez.html. И о CLASSPATH писал, там же.

Ну, разве что используя методы, которые возвращают их значения. А как можно иначе?

Вообще, имхо, у Вас не совсем правильный подход. Вы тестируете public API. "Щелкни кобылу по носу - и она махнет хвостом". Все, что в середине - черный ящик. В тестах Вы не должны знать о private-переменных.

Добрый день!

Насчет web-разработки мне, честно сказать, сложно что-то советовать. Это слишком многогранная тема, она включает в себя знания из множества областей. Ну, строго обязательно знание технологии Servlet/JSP, включая фильтры. Знание протокола http, причем именно на уровне протокола - заголовки, управление различными аспектами и т.п. Знание спецификации HTML тоже крайне желательно, даже есть Вы не будете заниматься разработкой интерфейса.

А вообще требования, выдвигаемые web-разработкой, я озвучивал тут: http://www.skipy.ru/philosophy/professionalism.html. Из упомянутых фреймворков сейчас имеет смысл сконцентрироваться на Spring Framework, он, на мой взгляд, более перспективен. Хотя принципы, как ни странно, лучше изучать по Struts.

Кроме того, важно понимать области применимости тех или иных технологий. Например, все ORM в случае массовых выборок (например, построение отчетов и т.п.) не только не дадут преимущества, но могут и серьезно навредить.

Добрый день!

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

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

И тем не менее - Java я изучил во время написания диплома. Множество принципов построения приложения - тоже. Получил навыки работы с *NIX. Получил навыки работы с HTML и CGI.

Так что я Вам предлагаю смотреть на дело именно с такой позиции. CMS - в принципе, направление востребовано. Хотя существует уже много CMS, в том числе и написаных на Java, это даст Вам возможность изучить web-программирование на достаточно приличном уровне. И пусть Ваша собственная CMS останется дипломной работой (хотя кто знает?!) - знания Вам по любому пригодянся, ибо вот как раз web-программирование сейчас действительно востребовано.

Спасибо! Буду стараться!

Добрый день!

Вы, честно сказать, поставили меня в тупик словом "корректировка". Я не совсем понимаю, что именно надо корректировать, и зачем. А как пишутся статьи - расскажу, это не секрет.

Итак. Для начала выбирается тема. Статья - это не абы что, она должна быть о чем-то, причем о том, что интересно и полезно. Сейчас у меня в списке порядка 20 различных тем, по которым, я считаю, стоит что-то написать.

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

Ну и дальше - я начинаю писать. Читать. Исправлять. Переписывать. Писать иллюстративные примеры. В процессе обнаруживается что-то, чего я не знал, но что стоит непременно включить в статью. Иногда через неделю, а то и месяц работы начинаешь понимать, что пишешь всё не то. Выбрасываешь и начинаешь сначала. Этот процесс самый долгий.

Когда статья уже практически написана - начинается работа над формулировками. Я печатаю ее целиком и читаю не с экрана, а с бумаги, причем желательно даже не сидя. Наилучший вариант - на ходу, по дороге с работы. Это позволяет выйти из контекста, в котором я эту статью пишу. И часто оказывается, что вот тут коряво, вот тут - непонятно, что я имел в виду, вот тут - нет явной связи с предыдущим текстом. Скажем, статью о практике XP (Экстремальное программирование – практика, психология и ошибки) я печатал для вычитки 18 раз. Учитывая, что вычитывал я ее не каждый день - только на окончательную правку ушло больше месяца. А вообще я ее писал почти два года, и несколько первых вариантов похоронил.

И вот только после этого я выкладываю статью на боевой сервер.

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

С уважением,
Евгений aka Skipy

Добрый день, Константин.

В планах есть, и давно. Но вот когда руки дойдут... У нас code freeze date - 28 февраля, после 9 месяцев работы, так что мне сейчас не до статей.

Добрый день!

Для начала - вот это: http://download.oracle.com/javaee/1.4/tutorial/doc/. С 4-й по 7-ю главы. Потом 18-я глава вот отсюда, это уже больше для ознакомления: http://download.oracle.com/javaee/5/tutorial/doc/. Потом можете почитать про Java API for XML Binding (JAXB, 17-я глава в tutorial по версии 5).

Если на пальцах - существует два подхода к обработке xml. Первый - SAX, Simple API for XML. Обработка последовательная. Фактически Вы решаете, какие теги Вам интересны, и ждете от обработчика событий - найден открытый тег, найдено тело тега, найден закрытый тег. Преимущества - требуется мало памяти. Недостаток - сложность реализации.

Второй способ - DOM, Document Object Model. В этом случае весь XML затаскивается в память, далее с ним можно работать как с деревом. Преимщество - простота работы, можно использовать XPATH, модифицировать узлы. Недостаток - нужно много памяти.

В Вашем случае, как это ни парадоксально, хорошо не подходит ни один вариант. Большой объем логов означает, что памяти под него потребуется много. Т.е. с DOM будут проблемы. Но на SAX не реализуется быстрая фильтрация. - придется каждый раз разбирать документ сначала. Не говоря о том, что это просто сложнее в реализации.

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

В принципе, если через JAXB этот XML в объекты парегнать да компараторов написать - сортировки да фильтрации будут эффективными. Но это опять память, от DOM недалеко ушло. Хотя работать будет проще, чем с XML в виде DOM.

P.S. А по хорошему - это чистая задача для использования базы данных. Загнать в базу, сделать индексы по всем полям - и выборки можно эффективные организовать, постраничные, и фильтрацию, и поиск.