Евгений Матюшкин (skipy_ru) wrote,
Евгений Матюшкин
skipy_ru

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

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

Я был бы рад, если бы анонимные комментарии и вопросы были подписаны – проще отвечать.
Tags: пожелания
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 118 comments
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →

Anonymous

October 7 2010, 15:26:07 UTC 9 years ago

Здравствуйте, Евгений!

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

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

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

Алексей
Добрый день!

Судя по всему, база достаточно простая и ненагруженная. Соответственно, подойдет любая СУБД - от 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 как представление. Вроде ничего не забыл.

Anonymous

9 years ago

Здравствуйте, Евгений.
Для начала спасибо за ваш сайт(я помню его ещё зелёным:) и полезные статьи.
И раз уж вы принимаете вопросы, то они есть у меня, и практически все связаны с архитектурой и дизайном приложений.

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

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

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

Спасибо за внимание.
---
And
Добрый день!

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

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

This

Anonymous

October 19 2010, 05:07:33 UTC 9 years ago

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

ru.skipy

Anonymous

October 22 2010, 13:33:06 UTC 9 years ago

Здравствуйте, Евгений!

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

Спасибо!
Алексей
Добрый день!

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

Anonymous

November 4 2010, 09:30:15 UTC 9 years ago

Здравствуйте, Евгений!

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

Спасибо!
Тестирование приложений вообще, с помощью unit-тестов - возможно и опишу когда-нибудь. В последнее время несколько раз всплывал этот вопрос.

Насчет конкретно JUnit4 - не знаю. Мне кажется, что он чрезвычайно прост в освоении, почитать API в течение пары часов - и можно использовать. Если были знакомы с прошлой версией - проблем не вызовет.

Anonymous

9 years ago

JUnit

Anonymous

November 4 2010, 13:33:37 UTC 9 years ago

Добрый день!

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

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

Suspended comment

Ой-ёй-ёй! Спасибо, что предупредили. Перегенерировал индекс раздела. :)

P.S. Статья в список попала случайно - я ее только начал. Возможно, именно она будет следующей.

Suspended comment

Здравствуйте Евгений большое спасибо за ваши статьи я хотел бы поинтересоваться какую литературу вы бы посоветовали из области веб разработки на java
Добрый день!

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

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

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

Re: Литература о java

Anonymous

8 years ago

Re: Литература о java

Anonymous

8 years ago

Здравствуйте Евгений большое спасибо за ваши статьи. Я студент и собираюсь писать диплом но не могу определиться с темой, как вариант расматриваю CMS на Java как вы считаете есть ли у данного направления перспективы или нет.
Добрый день!

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

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

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

Так что я Вам предлагаю смотреть на дело именно с такой позиции. CMS - в принципе, направление востребовано. Хотя существует уже много CMS, в том числе и написаных на Java, это даст Вам возможность изучить web-программирование на достаточно приличном уровне. И пусть Ваша собственная CMS останется дипломной работой (хотя кто знает?!) - знания Вам по любому пригодянся, ибо вот как раз web-программирование сейчас действительно востребовано.
Здравстуйте,Евгений.
Интересно ваше мнение как программиста и архитектора о будущем Джавы: а именно будет ли Джава занимать и дальше лидирущие позиции на рынке ентерпрайз технологий, мобильных технологий.
В интернете очень много дисскусий по этому поводу. Многие считают что у платформы джава нету будущего поскольку:
- она очень громоздкая и не слишком быстрая
- сам синтаксис очень уступает по удобсову и скорости разработки многим новым языкам(Python,Groovy,тот же C#).
- приходит эра динамический языков и ,возможно,функционального программирования.
- Наконец Оракл может существенно влиять на платформу в том числе и негативную сторну.
Спасибо.
Наверно мой вопрос останеться без ответа). Хотя это логично - профессионалы предпочитают делать дело, а не философствовать о будущем и актуальности той или иной платформы :)
Евгений, а почему бы не добавить к статьям на сайте кнопки "Мне нравится!"?
Хотя бы, при помощи яндекса: http://api.yandex.ru/share/
Желаю вам много хороших статей и обзоров.
Спасибо! Буду стараться!
Добрый вечер, Евгений! Большое Вам человеческое спасибо за обзоры и статьи, которые Вы публикуете на этом сайте. Многие вещи очень полезны! Хотелось бы уточнить каким образом публикуются статьи, проходят ли они предварительную корректировку? Это не попытка указать на ошибки, это просто пожелание, чтобы Ваши статьи читались и воспринимались легче.. Пишу это пожелание, поскольку мне нравится Ваша инициатива и просто хочется иметь и советовать коллегам Ваш сайт для прочтения. С уважением, Роллан.
Добрый день!

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

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

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

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

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

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

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

С уважением,
Евгений aka Skipy
Евгений здравствуйте еще раз спасибо за ваши статьи меня зовут Константин у меня к вам просьба написать статью об обопщенных классах их особеностях, что это такое и с чем его едят заранее спасибо.
Добрый день, Константин.

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

Re: Обопщенные классы

Anonymous

8 years ago

Очень-очень хотелось бы статью про обработку xml.
Непонятно даже, за что хвататься. Всяких средств для работы с xml в java целая куча, как встроенных, так и сторонних. А вот как выбрать нужный?
Да и вообще, xml для меня загадка. Вроде и книжек по нему куча, и возможностей всяких и технологий очень много. Но как-то уж очень всего много... общего понимания его возможностей и области применения у меня нет.
Вот к примеру, моя прога пишет лог в xml. Логи объемные и подробные, ковыряться в них тяжело. Хочется написать компанент (к примеру для Swing), для удобного просмотра лога, с возможностью фильтрации по дате, времени, уровню, и самому телу сообщения. С какой библиотекой нужно познакомиться, что бы это реализовать?

Re: пожелание

skipy_ru

March 16 2011, 20:30:58 UTC 8 years ago Edited:  November 12 2012, 20:29:53 UTC

Добрый день!

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