Я был бы рад, если бы анонимные комментарии и вопросы были подписаны – проще отвечать.
◎ Продолжаю собирать пожелания
Я был бы рад, если бы анонимные комментарии и вопросы были подписаны – проще отвечать.
-
О сборке мусора и нетривиальных конструкциях
Наткнулся на такой вопрос. Какая принципиальная разница между следующими фрагментами кода? MyObject o; o = new MyObject(); o = new MyObject();…
-
Повторная запись объектов в поток
Очень часто встречается в последнее время проблема: пишут объект в поток, меняют, пишут снова – а на выходе при чтении получают два одинаковых…
-
Обсуждение статьи «Внутреннее устройство GUI»
Очередная статья родилась. Времени на нее я потратил чуть не четыре месяца – было много работы, да и статья обширная, иллюстративных примеров…
-
О сборке мусора и нетривиальных конструкциях
Наткнулся на такой вопрос. Какая принципиальная разница между следующими фрагментами кода? MyObject o; o = new MyObject(); o = new MyObject();…
-
Повторная запись объектов в поток
Очень часто встречается в последнее время проблема: пишут объект в поток, меняют, пишут снова – а на выходе при чтении получают два одинаковых…
-
Обсуждение статьи «Внутреннее устройство GUI»
Очередная статья родилась. Времени на нее я потратил чуть не четыре месяца – было много работы, да и статья обширная, иллюстративных примеров…
← Ctrl ← Alt
Ctrl → Alt →
Anonymous
October 7 2010, 15:26:07 UTC 10 years ago
Вы могли бы подсказать, какие технологии лучше использовать для реализации такого проекта:
Реляционная база данных из 4-х таблиц (организации; их сотрудники; выданные документы; полученные документы).
Клиент желает иметь доступ к этой информации через Интернет (редактирование и просмотр отчета).
Сотрудники клиента тоже должны иметь доступ к отчету о самих себе.
Т.е. доступ по логину и паролю.
Скажите, пожалуйста, какие технологии лучше использовать для хранения базы данных?
Для защиты базы от нелегального доступа?
А само приложение лучше писать, пользуясь JSP?
В целом, приложение, кажется, не сложное, однако опыта программирования для серверов вообще нет. Буду очень благодарен, если сориентируете!
Спасибо!
Алексей
October 12 2010, 13:01:40 UTC 10 years ago
Судя по всему, база достаточно простая и ненагруженная. Соответственно, подойдет любая СУБД - от 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
10 years ago
Дизайн для таймеров?
Anonymous
October 13 2010, 10:19:12 UTC 10 years ago
Для начала спасибо за ваш сайт(я помню его ещё зелёным:) и полезные статьи.
И раз уж вы принимаете вопросы, то они есть у меня, и практически все связаны с архитектурой и дизайном приложений.
Вот один из таких, который стал часто возникать последнее время.
Есть обычное серверное приложение - база данных и т.д.
Часто есть необходимость в задачах по расписанию, например снимать статистику каждый день в 22:00 по одним данным или в 0 минут каждого часа по другим. Или просто по периодам, типа каждый час, каждые 10 минут проверять то и это.
С технической стороны все очевидно или поток, проверяющий каждую секунду "а не настало ли время чё-то сделать", или использование реализаций ScheduledExecutorService (Timer и TimerTask нынче устарели). Сейчас используются оба подхода.
Проблема в том, когда возникает новое периодическое задание, то каждый раз приходится думать куда её приткнуть - или в "таймерный" поток, или добавить к существующему ScheduledExecutor-у (а может создать новый?) и задачу Runnable к нему. В общем нет какого-то единого подхода, и нет хороших идей как сделать правильно.
Связанный вопрос, но помельче (возможно отпадёт после ответа на предыдущий):
допустим есть некие заявки пользователей (хранятся в базе), и у которых есть срок после которого они недействительны. Как и когда лучше фиксировать их недействительность? Запуском очередного таска по расписанию, или проверки на месте, например, при обращении к заявке. Конечно 1-й вариант более правильный, но из-за описанного выше иногда побеждает второй..
Спасибо за внимание.
---
And
Re: Дизайн для таймеров?
October 19 2010, 08:58:16 UTC 10 years ago
Ну, если бы выбирал я - я бы выбрал ScheduledExecutor-ы. Или вообще что-то стороннее типа Quartz - http://www.quartz-scheduler.org/. Мы его испоьзовали еще лет пять назад, и именно как замену стандартным средствам.
Что касается заявок - зависит от. Чем плох запуск по расписанию в этом случае - он происходит редко. Т.е. всегда существует определенный период, когда заявка уже недействительна, но еще не помечена. И если Вы своим запросом попадете в этот период - будет совсем не здорово. Так что тут смотреть надо по месту - если заявки портятся в полночь, а у вас гарантированный период бездействия с 11 вечера до 7 утра - в 0:30 можно запускать проверку. Если же у вас есть вероятность попасть в ненужный интервал - спасет только проверка по месту. Кстати, ничего особо плохого я в этом не вижу. По бизнес-логике проверка заявки должна присутствовать, а необходимость в отдельном запуске проверки отпадает.
Re: Дизайн для таймеров?
Anonymous
10 years ago
This
Anonymous
October 19 2010, 05:07:33 UTC 10 years ago
Re: This
October 19 2010, 07:05:44 UTC 10 years ago
this
является ссылкой на текущий объект. И это всё. Вы лучше задайте вопрос конкретный, что Вам непонятно. Постараюсь ответить.ru.skipy
Anonymous
October 22 2010, 13:33:06 UTC 10 years ago
Заметил, что все java-файлы, которые Вы приводите в своих статьях, размещены в пакеты (напр., ru.skipy.tests.ui).
Расскажите, пожалуйста, для чего так сделано. Просто удобно? Или "корень" пакета добавлен в CLASSPATH и можно легко обращаться к файлам *.class? Или есть другие "reason'ы"?
Спасибо!
Алексей
Re: ru.skipy
November 17 2010, 10:43:26 UTC 10 years ago
Вообще-то я достаточно подробно писал, зачем нужны пакеты, вот тут: http://www.skipy.ru/technics/likbez.html. И о CLASSPATH писал, там же.
Anonymous
November 4 2010, 09:30:15 UTC 10 years ago
А как насчет статьи о JUnit 4? Интересует Ваше мнение о подходе к тестированию приложений вообще и к использованию junit как библиотеки для тестирования.
Мне кажется, что в интернете (и в книжных магазинах) дефицит литературы по JUnit (по 4-ой версии)...
Спасибо!
November 17 2010, 10:37:35 UTC 10 years ago
Насчет конкретно JUnit4 - не знаю. Мне кажется, что он чрезвычайно прост в освоении, почитать API в течение пары часов - и можно использовать. Если были знакомы с прошлой версией - проблем не вызовет.
Anonymous
10 years ago
JUnit
Anonymous
November 4 2010, 13:33:37 UTC 10 years ago
Евгений, возник конкретный вопрос по JUnit.
Как из тестового класса проконтролировать private поля в контролируемом классе?
Re: JUnit
November 17 2010, 10:35:37 UTC 10 years ago
Вообще, имхо, у Вас не совсем правильный подход. Вы тестируете public API. "Щелкни кобылу по носу - и она махнет хвостом". Все, что в середине - черный ящик. В тестах Вы не должны знать о private-переменных.
Suspended comment
November 17 2010, 10:33:04 UTC 10 years ago
P.S. Статья в список попала случайно - я ее только начал. Возможно, именно она будет следующей.
Suspended comment
Литература о java
Anonymous
November 21 2010, 14:47:51 UTC 10 years ago
Re: Литература о java
December 14 2010, 06:39:25 UTC 10 years ago
Насчет web-разработки мне, честно сказать, сложно что-то советовать. Это слишком многогранная тема, она включает в себя знания из множества областей. Ну, строго обязательно знание технологии Servlet/JSP, включая фильтры. Знание протокола http, причем именно на уровне протокола - заголовки, управление различными аспектами и т.п. Знание спецификации HTML тоже крайне желательно, даже есть Вы не будете заниматься разработкой интерфейса.
А вообще требования, выдвигаемые web-разработкой, я озвучивал тут: http://www.skipy.ru/philosophy/professionalism.html. Из упомянутых фреймворков сейчас имеет смысл сконцентрироваться на Spring Framework, он, на мой взгляд, более перспективен. Хотя принципы, как ни странно, лучше изучать по Struts.
Кроме того, важно понимать области применимости тех или иных технологий. Например, все ORM в случае массовых выборок (например, построение отчетов и т.п.) не только не дадут преимущества, но могут и серьезно навредить.
Re: Литература о java
Anonymous
10 years ago
Re: Литература о java
10 years ago
Re: Литература о java
Anonymous
10 years ago
Re: Литература о java
10 years ago
CMS на Java
Anonymous
November 24 2010, 03:20:22 UTC 10 years ago
Re: CMS на Java
December 14 2010, 06:52:53 UTC 10 years ago
Видите ли в чем дело... Дипломную работу можно (и нужно, на мой взгляд!) рассматривать прежде всего как изучение набора технологий. То, что Вы напишете - оно вторично. Ничего личного, это объективная реальность. Дело в том, что любая сложная система, во-первых, требует определенных специфичных знаний (которых у Вас с большой вероятностью нет), во-вторых, хорошего владения технологиями (которого у Вас тоже пока нет).
Поясню на собственном опыте. Когда я писал диплом, я на него убил полтора года. Сейчас я понимаю, насколько он неоптимально был написан, насколько безумные решения я принимал, какие ляпы я допускал из-за незнания технологий. В общем, сейчас бы я его написал за месяц в худшем случае, и код был бы существенно более высокого качества.
И тем не менее - Java я изучил во время написания диплома. Множество принципов построения приложения - тоже. Получил навыки работы с *NIX. Получил навыки работы с HTML и CGI.
Так что я Вам предлагаю смотреть на дело именно с такой позиции. CMS - в принципе, направление востребовано. Хотя существует уже много CMS, в том числе и написаных на Java, это даст Вам возможность изучить web-программирование на достаточно приличном уровне. И пусть Ваша собственная CMS останется дипломной работой (хотя кто знает?!) - знания Вам по любому пригодянся, ибо вот как раз web-программирование сейчас действительно востребовано.
Общий вопрос
December 16 2010, 13:56:30 UTC 10 years ago
Интересно ваше мнение как программиста и архитектора о будущем Джавы: а именно будет ли Джава занимать и дальше лидирущие позиции на рынке ентерпрайз технологий, мобильных технологий.
В интернете очень много дисскусий по этому поводу. Многие считают что у платформы джава нету будущего поскольку:
- она очень громоздкая и не слишком быстрая
- сам синтаксис очень уступает по удобсову и скорости разработки многим новым языкам(Python,Groovy,тот же C#).
- приходит эра динамический языков и ,возможно,функционального программирования.
- Наконец Оракл может существенно влиять на платформу в том числе и негативную сторну.
Спасибо.
Re: Общий вопрос
December 27 2010, 09:33:45 UTC 10 years ago
Re: Общий вопрос
10 years ago
Re: Общий вопрос
10 years ago
December 29 2010, 12:06:44 UTC 10 years ago
Хотя бы, при помощи яндекса: http://api.yandex.ru/share/
Успехов всем!
Anonymous
January 6 2011, 06:54:56 UTC 10 years ago
Re: Успехов всем!
January 6 2011, 20:53:36 UTC 10 years ago
По поводу содержания статей..
Anonymous
January 6 2011, 12:52:02 UTC 10 years ago
Re: По поводу содержания статей..
January 6 2011, 21:10:33 UTC 10 years ago
Вы, честно сказать, поставили меня в тупик словом "корректировка". Я не совсем понимаю, что именно надо корректировать, и зачем. А как пишутся статьи - расскажу, это не секрет.
Итак. Для начала выбирается тема. Статья - это не абы что, она должна быть о чем-то, причем о том, что интересно и полезно. Сейчас у меня в списке порядка 20 различных тем, по которым, я считаю, стоит что-то написать.
Далее. Определяется круг вопросов, которые я затрону. Чаще всего темы, на которые я пишу, существенно более обширны, чем вместится в одну статью. Кроме того, существует порог восприятия информации, и если ее больше - нужно разделять материал на несколько статей.
Ну и дальше - я начинаю писать. Читать. Исправлять. Переписывать. Писать иллюстративные примеры. В процессе обнаруживается что-то, чего я не знал, но что стоит непременно включить в статью. Иногда через неделю, а то и месяц работы начинаешь понимать, что пишешь всё не то. Выбрасываешь и начинаешь сначала. Этот процесс самый долгий.
Когда статья уже практически написана - начинается работа над формулировками. Я печатаю ее целиком и читаю не с экрана, а с бумаги, причем желательно даже не сидя. Наилучший вариант - на ходу, по дороге с работы. Это позволяет выйти из контекста, в котором я эту статью пишу. И часто оказывается, что вот тут коряво, вот тут - непонятно, что я имел в виду, вот тут - нет явной связи с предыдущим текстом. Скажем, статью о практике XP (Экстремальное программирование – практика, психология и ошибки) я печатал для вычитки 18 раз. Учитывая, что вычитывал я ее не каждый день - только на окончательную правку ушло больше месяца. А вообще я ее писал почти два года, и несколько первых вариантов похоронил.
И вот только после этого я выкладываю статью на боевой сервер.
Так что, как видите, корректировку статья проходят. И такую работу я проделываю именно потому, что хочу, чтобы статьи читались и воспринимались максимально просто. Если Вы считаете, что где-то я пишу все-таки сложно - это вопрос для обсуждения. Я допускаю, что первые статьи были несколько скомканными, по крайней мере, не настолько развернутыми, как сейчас. Все-таки почти за семь лет я уже набил руку.
С уважением,
Евгений aka Skipy
Обопщенные классы
Anonymous
February 3 2011, 02:26:37 UTC 9 years ago
Re: Обопщенные классы
February 14 2011, 13:44:24 UTC 9 years ago
В планах есть, и давно. Но вот когда руки дойдут... У нас code freeze date - 28 февраля, после 9 месяцев работы, так что мне сейчас не до статей.
Re: Обопщенные классы
Anonymous
9 years ago
пожелание
Anonymous
March 10 2011, 14:24:46 UTC 9 years ago
Непонятно даже, за что хвататься. Всяких средств для работы с xml в java целая куча, как встроенных, так и сторонних. А вот как выбрать нужный?
Да и вообще, xml для меня загадка. Вроде и книжек по нему куча, и возможностей всяких и технологий очень много. Но как-то уж очень всего много... общего понимания его возможностей и области применения у меня нет.
Вот к примеру, моя прога пишет лог в xml. Логи объемные и подробные, ковыряться в них тяжело. Хочется написать компанент (к примеру для Swing), для удобного просмотра лога, с возможностью фильтрации по дате, времени, уровню, и самому телу сообщения. С какой библиотекой нужно познакомиться, что бы это реализовать?
Re: пожелание
March 16 2011, 20:30:58 UTC 9 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. А по хорошему - это чистая задача для использования базы данных. Загнать в базу, сделать индексы по всем полям - и выборки можно эффективные организовать, постраничные, и фильтрацию, и поиск.
← Ctrl ← Alt
Ctrl → Alt →