?

Log in

No account? Create an account

Previous Entry

Теперь уже в этой теме прошу писать всех, кто хотел бы что-то обсудить – статьи на сайте или же просто какие-то интересные/актуальные вопросы. По результатам сбора пожеланий опять-таки будут созданы темы для обсуждения. Или же статьи, что тоже реально.

Я был бы рад, если бы анонимные комментарии и вопросы были подписаны – проще отвечать.

Comments

( 118 comments — Leave a comment )
Page 2 of 4
<<[1] [2] [3] [4] >>
(Anonymous)
Oct. 7th, 2010 03:26 pm (UTC)
Здравствуйте, Евгений!

Вы могли бы подсказать, какие технологии лучше использовать для реализации такого проекта:
Реляционная база данных из 4-х таблиц (организации; их сотрудники; выданные документы; полученные документы).
Клиент желает иметь доступ к этой информации через Интернет (редактирование и просмотр отчета).
Сотрудники клиента тоже должны иметь доступ к отчету о самих себе.
Т.е. доступ по логину и паролю.

Скажите, пожалуйста, какие технологии лучше использовать для хранения базы данных?
Для защиты базы от нелегального доступа?
А само приложение лучше писать, пользуясь JSP?

В целом, приложение, кажется, не сложное, однако опыта программирования для серверов вообще нет. Буду очень благодарен, если сориентируете!
Спасибо!

Алексей
skipy_ru
Oct. 12th, 2010 01:01 pm (UTC)
Добрый день!

Судя по всему, база достаточно простая и ненагруженная. Соответственно, подойдет любая СУБД - от MySQL, Apache Derby и PostgreSQL до Oracle и MSSQL.

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

Возможно, стоит использовать ORM типа Hibernate, на таких объемах накладные расходы будут несущественными, а удобство это даст.

Пользователи хранятся в базе, вместе с хешами паролей. Таким образом, проверить введенный пароль можно, а узнать - нет. Подобрать - сложно, если использовать, например, SHA (MD5 подбирается).

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

Технологии, на которых строится web-интерфейс, могут быть самыми разными. С простым JSP будет много возни, лучше взять какой-нибудь фреймворк, в котором JSP будут играть роль представления, как им и положено. Например, Spring Framework, у него есть web MVC. Брать объектные фреймворки типа JSF, Wicket и иже с ними я бы не стал - имхо, тут чем проще, тем лучше, интерфейс намечается тривиальный. Мы вообще когда-то такой делали на Velocity вместо JSP.

Приложение действительно несложное. В общем, если бы я набирал сам технологии под него, я бы взял PostgreSQL(либо MySQL), Hibernate, Apache Tomcat как сервер, Spring Framework и JSP как представление. Вроде ничего не забыл.
(no subject) - (Anonymous) - Oct. 19th, 2010 02:11 pm (UTC) - Expand
(Anonymous)
Oct. 13th, 2010 10:19 am (UTC)
Дизайн для таймеров?
Здравствуйте, Евгений.
Для начала спасибо за ваш сайт(я помню его ещё зелёным:) и полезные статьи.
И раз уж вы принимаете вопросы, то они есть у меня, и практически все связаны с архитектурой и дизайном приложений.

Вот один из таких, который стал часто возникать последнее время.
Есть обычное серверное приложение - база данных и т.д.
Часто есть необходимость в задачах по расписанию, например снимать статистику каждый день в 22:00 по одним данным или в 0 минут каждого часа по другим. Или просто по периодам, типа каждый час, каждые 10 минут проверять то и это.

С технической стороны все очевидно или поток, проверяющий каждую секунду "а не настало ли время чё-то сделать", или использование реализаций ScheduledExecutorService (Timer и TimerTask нынче устарели). Сейчас используются оба подхода.
Проблема в том, когда возникает новое периодическое задание, то каждый раз приходится думать куда её приткнуть - или в "таймерный" поток, или добавить к существующему ScheduledExecutor-у (а может создать новый?) и задачу Runnable к нему. В общем нет какого-то единого подхода, и нет хороших идей как сделать правильно.

Связанный вопрос, но помельче (возможно отпадёт после ответа на предыдущий):
допустим есть некие заявки пользователей (хранятся в базе), и у которых есть срок после которого они недействительны. Как и когда лучше фиксировать их недействительность? Запуском очередного таска по расписанию, или проверки на месте, например, при обращении к заявке. Конечно 1-й вариант более правильный, но из-за описанного выше иногда побеждает второй..

Спасибо за внимание.
---
And
skipy_ru
Oct. 19th, 2010 08:58 am (UTC)
Re: Дизайн для таймеров?
Добрый день!

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

Что касается заявок - зависит от. Чем плох запуск по расписанию в этом случае - он происходит редко. Т.е. всегда существует определенный период, когда заявка уже недействительна, но еще не помечена. И если Вы своим запросом попадете в этот период - будет совсем не здорово. Так что тут смотреть надо по месту - если заявки портятся в полночь, а у вас гарантированный период бездействия с 11 вечера до 7 утра - в 0:30 можно запускать проверку. Если же у вас есть вероятность попасть в ненужный интервал - спасет только проверка по месту. Кстати, ничего особо плохого я в этом не вижу. По бизнес-логике проверка заявки должна присутствовать, а необходимость в отдельном запуске проверки отпадает.
Re: Дизайн для таймеров? - (Anonymous) - Oct. 19th, 2010 02:40 pm (UTC) - Expand
(Anonymous)
Oct. 19th, 2010 05:07 am (UTC)
This
Было бы очень здорово ,если бы Вы Евгений ,разжевали тему с ключевым словом this,спасибо.
skipy_ru
Oct. 19th, 2010 07:05 am (UTC)
Re: This
Э-э-э... Вам удалось ввести меня в замешательство. Я, честно сказать, не вижу, что можно разжевывать. this является ссылкой на текущий объект. И это всё. Вы лучше задайте вопрос конкретный, что Вам непонятно. Постараюсь ответить.
(Anonymous)
Oct. 22nd, 2010 01:33 pm (UTC)
ru.skipy
Здравствуйте, Евгений!

Заметил, что все java-файлы, которые Вы приводите в своих статьях, размещены в пакеты (напр., ru.skipy.tests.ui).
Расскажите, пожалуйста, для чего так сделано. Просто удобно? Или "корень" пакета добавлен в CLASSPATH и можно легко обращаться к файлам *.class? Или есть другие "reason'ы"?

Спасибо!
Алексей
skipy_ru
Nov. 17th, 2010 10:43 am (UTC)
Re: ru.skipy
Добрый день!

Вообще-то я достаточно подробно писал, зачем нужны пакеты, вот тут: http://www.skipy.ru/technics/likbez.html. И о CLASSPATH писал, там же.
(Anonymous)
Nov. 4th, 2010 09:30 am (UTC)
Здравствуйте, Евгений!

А как насчет статьи о JUnit 4? Интересует Ваше мнение о подходе к тестированию приложений вообще и к использованию junit как библиотеки для тестирования.
Мне кажется, что в интернете (и в книжных магазинах) дефицит литературы по JUnit (по 4-ой версии)...

Спасибо!
skipy_ru
Nov. 17th, 2010 10:37 am (UTC)
Тестирование приложений вообще, с помощью unit-тестов - возможно и опишу когда-нибудь. В последнее время несколько раз всплывал этот вопрос.

Насчет конкретно JUnit4 - не знаю. Мне кажется, что он чрезвычайно прост в освоении, почитать API в течение пары часов - и можно использовать. Если были знакомы с прошлой версией - проблем не вызовет.
(no subject) - (Anonymous) - Nov. 18th, 2010 11:14 am (UTC) - Expand
(Anonymous)
Nov. 4th, 2010 01:33 pm (UTC)
JUnit
Добрый день!

Евгений, возник конкретный вопрос по JUnit.
Как из тестового класса проконтролировать private поля в контролируемом классе?
skipy_ru
Nov. 17th, 2010 10:35 am (UTC)
Re: JUnit
Ну, разве что используя методы, которые возвращают их значения. А как можно иначе?

Вообще, имхо, у Вас не совсем правильный подход. Вы тестируете public API. "Щелкни кобылу по носу - и она махнет хвостом". Все, что в середине - черный ящик. В тестах Вы не должны знать о private-переменных.
(no subject) - pswrdf - Nov. 17th, 2010 10:05 am (UTC) - Expand
skipy_ru
Nov. 17th, 2010 10:33 am (UTC)
Ой-ёй-ёй! Спасибо, что предупредили. Перегенерировал индекс раздела. :)

P.S. Статья в список попала случайно - я ее только начал. Возможно, именно она будет следующей.
(no subject) - pswrdf - Nov. 17th, 2010 12:49 pm (UTC) - Expand
(Anonymous)
Nov. 21st, 2010 02:47 pm (UTC)
Литература о java
Здравствуйте Евгений большое спасибо за ваши статьи я хотел бы поинтересоваться какую литературу вы бы посоветовали из области веб разработки на java
skipy_ru
Dec. 14th, 2010 06:39 am (UTC)
Re: Литература о java
Добрый день!

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

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

Кроме того, важно понимать области применимости тех или иных технологий. Например, все ORM в случае массовых выборок (например, построение отчетов и т.п.) не только не дадут преимущества, но могут и серьезно навредить.
Re: Литература о java - (Anonymous) - Dec. 14th, 2010 08:50 am (UTC) - Expand
Re: Литература о java - skipy_ru - Dec. 14th, 2010 02:02 pm (UTC) - Expand
Re: Литература о java - (Anonymous) - Dec. 15th, 2010 01:32 pm (UTC) - Expand
Re: Литература о java - skipy_ru - Dec. 15th, 2010 02:50 pm (UTC) - Expand
(Anonymous)
Nov. 24th, 2010 03:20 am (UTC)
CMS на Java
Здравствуйте Евгений большое спасибо за ваши статьи. Я студент и собираюсь писать диплом но не могу определиться с темой, как вариант расматриваю CMS на Java как вы считаете есть ли у данного направления перспективы или нет.
skipy_ru
Dec. 14th, 2010 06:52 am (UTC)
Re: CMS на Java
Добрый день!

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

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

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

Так что я Вам предлагаю смотреть на дело именно с такой позиции. CMS - в принципе, направление востребовано. Хотя существует уже много CMS, в том числе и написаных на Java, это даст Вам возможность изучить web-программирование на достаточно приличном уровне. И пусть Ваша собственная CMS останется дипломной работой (хотя кто знает?!) - знания Вам по любому пригодянся, ибо вот как раз web-программирование сейчас действительно востребовано.
my_e_blog
Dec. 16th, 2010 01:56 pm (UTC)
Общий вопрос
Здравстуйте,Евгений.
Интересно ваше мнение как программиста и архитектора о будущем Джавы: а именно будет ли Джава занимать и дальше лидирущие позиции на рынке ентерпрайз технологий, мобильных технологий.
В интернете очень много дисскусий по этому поводу. Многие считают что у платформы джава нету будущего поскольку:
- она очень громоздкая и не слишком быстрая
- сам синтаксис очень уступает по удобсову и скорости разработки многим новым языкам(Python,Groovy,тот же C#).
- приходит эра динамический языков и ,возможно,функционального программирования.
- Наконец Оракл может существенно влиять на платформу в том числе и негативную сторну.
Спасибо.
my_e_blog
Dec. 27th, 2010 09:33 am (UTC)
Re: Общий вопрос
Наверно мой вопрос останеться без ответа). Хотя это логично - профессионалы предпочитают делать дело, а не философствовать о будущем и актуальности той или иной платформы :)
Re: Общий вопрос - skipy_ru - Dec. 28th, 2010 07:46 pm (UTC) - Expand
Re: Общий вопрос - skipy_ru - Jan. 6th, 2011 10:10 pm (UTC) - Expand
Re: Общий вопрос - my_e_blog - Jan. 10th, 2011 07:45 am (UTC) - Expand
kefirfromperm
Dec. 29th, 2010 12:06 pm (UTC)
Евгений, а почему бы не добавить к статьям на сайте кнопки "Мне нравится!"?
Хотя бы, при помощи яндекса: http://api.yandex.ru/share/
(Anonymous)
Jan. 6th, 2011 06:54 am (UTC)
Успехов всем!
Желаю вам много хороших статей и обзоров.
skipy_ru
Jan. 6th, 2011 08:53 pm (UTC)
Re: Успехов всем!
Спасибо! Буду стараться!
(Anonymous)
Jan. 6th, 2011 12:52 pm (UTC)
По поводу содержания статей..
Добрый вечер, Евгений! Большое Вам человеческое спасибо за обзоры и статьи, которые Вы публикуете на этом сайте. Многие вещи очень полезны! Хотелось бы уточнить каким образом публикуются статьи, проходят ли они предварительную корректировку? Это не попытка указать на ошибки, это просто пожелание, чтобы Ваши статьи читались и воспринимались легче.. Пишу это пожелание, поскольку мне нравится Ваша инициатива и просто хочется иметь и советовать коллегам Ваш сайт для прочтения. С уважением, Роллан.
skipy_ru
Jan. 6th, 2011 09:10 pm (UTC)
Re: По поводу содержания статей..
Добрый день!

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

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

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

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

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

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

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

С уважением,
Евгений aka Skipy
(Anonymous)
Feb. 3rd, 2011 02:26 am (UTC)
Обопщенные классы
Евгений здравствуйте еще раз спасибо за ваши статьи меня зовут Константин у меня к вам просьба написать статью об обопщенных классах их особеностях, что это такое и с чем его едят заранее спасибо.
skipy_ru
Feb. 14th, 2011 01:44 pm (UTC)
Re: Обопщенные классы
Добрый день, Константин.

В планах есть, и давно. Но вот когда руки дойдут... У нас code freeze date - 28 февраля, после 9 месяцев работы, так что мне сейчас не до статей.
Re: Обопщенные классы - (Anonymous) - Feb. 16th, 2011 04:46 am (UTC) - Expand
(Anonymous)
Mar. 10th, 2011 02:24 pm (UTC)
пожелание
Очень-очень хотелось бы статью про обработку xml.
Непонятно даже, за что хвататься. Всяких средств для работы с xml в java целая куча, как встроенных, так и сторонних. А вот как выбрать нужный?
Да и вообще, xml для меня загадка. Вроде и книжек по нему куча, и возможностей всяких и технологий очень много. Но как-то уж очень всего много... общего понимания его возможностей и области применения у меня нет.
Вот к примеру, моя прога пишет лог в xml. Логи объемные и подробные, ковыряться в них тяжело. Хочется написать компанент (к примеру для Swing), для удобного просмотра лога, с возможностью фильтрации по дате, времени, уровню, и самому телу сообщения. С какой библиотекой нужно познакомиться, что бы это реализовать?
skipy_ru
Mar. 16th, 2011 08:30 pm (UTC)
Re: пожелание
Добрый день!

Для начала - вот это: 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. А по хорошему - это чистая задача для использования базы данных. Загнать в базу, сделать индексы по всем полям - и выборки можно эффективные организовать, постраничные, и фильтрацию, и поиск.

Edited at 2012-11-12 08:29 pm (UTC)
Page 2 of 4
<<[1] [2] [3] [4] >>
( 118 comments — Leave a comment )