@Transactional(Transactional.TxType.MANDATORY) не нужен в интерфейсе, ибо они неявно и так создаются(транзакции) имплементацией jpa репозиториев.
P.S. интереснее было бы прочитать именно про применение full-text search'a по разным критериям которых мало в документации — поиск по дистанции, поиск для русских слов и т.п.
Глупый вопрос, но нельзя ли для ACL воткнуть кэширование? По идее это такие вещи, которые не так часто меняются и отлично подпадают под возможность кэширования(я про ACL). Механизмов хватает — Redis/Memcache/(да даже тупое кэширование файловое) должно улучшить на порядки производительность. Конечно, это приведет к модификации исходного кода Joomla(что не хорошо в плане последующих апгрейдов)… Но даже не знаю стоит ли из бетонных блоков пытаться слепить детский песочный домик или слегка допилить напильником то, что уже есть…
Поправьте меня если я не прав, но насколько это хорошее решение делать толстого клиента?
Может быть было бы резоннее сделать слой который ходит в базу данных не частью JavaFX приложения, а частью веб сервиса который предоставлял бы эту функциональность? А для JavaFX приложения использовать нечто более легковесное, чем Spring? Например, Google Guice или что-то другое для Dependency Injection?
Просто я пытался использовать Spring для десктопных приложений и пришел к выводу, что он довольно-таки тяжелый(именно стадия инициализации занимает много времени да и куча библиотек за ним тянется из-за чего конечный разме jar файла получается довольно-таки большим, да и памяти отъедается прилично на ПК пользователя) и для десктопа именно я его бы не использовал, хотя на стороне сервера это решение себя хорошо зарекомендовало.
Все вышесказанное — мое ИМХО — было бы интересно услышать мнение других сторон.
Это иллюзия о том, что уйти нет возможности. Я тоже ей жил, пока в один момент не принял для себя решение. И самое интересное — компания где я работал спустя 2 года до сих пор жива-здорова.
В какой-то степени я тоже был тем самы Риком. Разница только в том, что оценив всю ситуацию — я встал и ушел. Потому что менеджмент не волновали те проблемы, которые я озвучивал. За 3 года моей работы в комании ничего не изменилось. А работы не уменьшалось.
Мой код слишком сложен — слышал я (пишу на Java). Слишком сложно — это использовать Stream api для трансформации/фильтрации. Другой «сениор» это не осилил. Переписал на итератор. Слишком сложно пишу видимо(или просто квалификация разработчиков остается на каком-то уровне выше которого им подниматься лень).
Из статьи еше стало понятно, что Рик задал вектор движения. А что смогли сделать остальные девелоперы за оставшийся промежуток времени — это выкинуть бОльшую часть фичей и навставлять костылей(поныв менеджменту что ничего непонятно, мы не успеем и т.п. — те в свою очередь задрейфили и пошли на уступки).
Да и руководство тоже молодцы. Сделали все для того что бы Рик выгорел. А потом нашли крайнего вместо того, что бы разобраться в ситуации на самом деле. Не снимаю вину с Рика, но менеджер должен уметь менеджить(простите меня за тавтологию). И уволить нужно было еще парочку менеджеров вместе с Риком(хотя может быть Рика нужно было просто отправить в принудительный отпуск/кинуть на другой проект).
Моя основная позиция против бизнес логики в базе потому что:
1. Сложнее дебажить
2. Логика размазана
3. Если база начнет захлебываться, то это будет на порядки сложнее скалировать, нежели если бы это было логикой со стороны кода.
Как с точки зрения последующего мейнтенанса, так и с точки зрения скалирования это плохо. Да, возможно вы сможете написать быстрее что-то там, но потом поддерживать вам это будет стоить 10x по сравнению если бы у вас логика была просто на стороне приложения. Я это говорю основываясь на своем опыте работы как над кровавыми оракловскими энтерпрпайзами, где 70% всей логики в базе — кстати очень здорово расхлебывать им теперь перформанс проблемы так как бОльшая часть всей логики на стороне БД ;) Так и имея опыт разработки где база — просто хранилище данных, в котором проблемы как сопровождения так и перформанса решаются на порядки проще и дешевле.
Вопрос — зачем вы все еще пишите логику на стороне базы?
Какое-то время назад смотрели возможность настроить Master-Slave репликацию, что бы с каких-то Slave'ов можно было в realtime производить чтения и тем самым разгрузить master'a. После чтения документации остановились на потоковой репликации
( www.postgresql.org/docs/9.1/static/warm-standby.html#STREAMING-REPLICATION )
Может быть выбор не самый лучший и можете посоветовать что-либо более подходящее для read-only slave'ов в PostgreSQL?
Мне интересно, на сколько сложно затем в последствии поддерживать системы такого типа? То есть звучит для бизнеса это заманчиво — ничего не нужно разрабатывать, дальше администратор сможет тупо сам делать то, что ему нужно при помощи яваскрипта. Вопрос в том, на сколько сложно потом будет поддерживать такого рода систему? Как потом отлавливать ошибки и в каком виде все это тестироваться будет?
Я не согласен с автором статьи — нужно имплементировать security правильно, а не лепить костыли.
Выбор идентификаторов должен быть диктован ограничениями системы/ее архитектурой, а не попыткой что-то там заобфусцировать/захачить/прикрутить еще один клевый хак-о-костыль.
Если Security заимплементирована криво, то это проблема дизайна приложения/архитектуры/квалификации программистов.
Взгляд допустим на тот же Spring Security дает понимание того, как оно могло бы по правильному работать. И даже если вы не работаете с Java, больше чем уверен, что есть множество решений под разные языки/платформы готовые, удовлетворяющие нуждам.
Ну или хотя бы на их основании можно в правильном направлении начать двигаться, а не лепить что-то по типа «А давайте добавим еще один ID и слепим их вместе, а потом будем разбивать их пополоам, никто ведь не догадается».
Общий шаблон у нас вынесен и используется sitemesh. Остальные странички выглядят довольно просто. Сейчас в admin panel'e что-то около 15-20 страниц. Используется twitter bootstrap, что делает страницу относительно симпатичной, jQuery библиотека, underscore js и еще несколько по мелочи. Объем кода на страничках варьируется. В среднем что-то около 50-100, если нигде js не понаписан дополнительный.
Я, и в фирме где я работаю, существует внегласное правило — под одним контейнером бежит одно приложение. Поэтому, у нас деплоймент выглядит следующим образом:
1). Останавливается контейнер(в нашем случае — Tomcat).
2). Стирается все из webapps директории
3). Стирается все из work директории
4). Заливается новый war
5). Контейнер(Tomcat) запускается
Таким образом мы избегаем главной проблемы, связанной с redeployment'ом — OOM.
Это работает в случае с приложениями, где down-time возможен и не мешает.
В случае, где downtime недопустим — у нас бежит несколько инстансов томката за лоадбалансером, и каждый инстанс редеплоится именно таким образом, что исключает downtime при backward-compatible изменениях базы данных.
У нас Web(фронт-энд для нашего rest-service'a) и Admin Panel крутится сейчас именно на Spring, Spring MVC и JSP используется в качестве View. Насчет фич 8-ой java и дергания логики из View — на мой взгляд не очень хорошая идея. У нас на/c JSP передаются DTO объекты, которые в свою очередь трансформируются в DTO объекты сервисного уровня, которые уже в свою очередь преобразуются из/в объекты модельного уровня. С одной стороны, это может показаться избыточным(для простых приложений), с другой стороны это лучше позволяет разделить слои приложений и переиспользовать код.
Насчет SSP — я его обкатываю на своих личных проектах в первую очередь, прежде чем предложить использовать его в Production(с большой буквы), но пока что в целях — есть желание внедрить эту технологию отображения для начала, хотя бы для Admin Panel нашего сервиса.
Насчет JSF — личного опыта работы с ним я не имею, но от своих коллег, которые работали с данной технологией, я слышал не лестные отзывы. К ним относится — тормозит, если написаны какие-то кастомные компоненты, то при апгрейде на новую версию JSF их нужно зачастую сильно переделывать, что бы они заработали, кастомизировать под свои нужды внешний вид — тоже то еще занятие.
Насчет GWT — я немного пощупал эту технологию, и мне в принципе даже понравилось, но из минусов — довольно сложно изменять внешний вид, то есть я бы стал использовать только в том случае, если нужно набросать по-быстрому какой-то административный UI, где внешний вид не важен, так как кастомизировать отображение выходит сложнее, чем если это написать все с использованием более простых технологий.
P.S. интереснее было бы прочитать именно про применение full-text search'a по разным критериям которых мало в документации — поиск по дистанции, поиск для русских слов и т.п.
Может быть было бы резоннее сделать слой который ходит в базу данных не частью JavaFX приложения, а частью веб сервиса который предоставлял бы эту функциональность? А для JavaFX приложения использовать нечто более легковесное, чем Spring? Например, Google Guice или что-то другое для Dependency Injection?
Просто я пытался использовать Spring для десктопных приложений и пришел к выводу, что он довольно-таки тяжелый(именно стадия инициализации занимает много времени да и куча библиотек за ним тянется из-за чего конечный разме jar файла получается довольно-таки большим, да и памяти отъедается прилично на ПК пользователя) и для десктопа именно я его бы не использовал, хотя на стороне сервера это решение себя хорошо зарекомендовало.
Все вышесказанное — мое ИМХО — было бы интересно услышать мнение других сторон.
Мой код слишком сложен — слышал я (пишу на Java). Слишком сложно — это использовать Stream api для трансформации/фильтрации. Другой «сениор» это не осилил. Переписал на итератор. Слишком сложно пишу видимо(или просто квалификация разработчиков остается на каком-то уровне выше которого им подниматься лень).
Из статьи еше стало понятно, что Рик задал вектор движения. А что смогли сделать остальные девелоперы за оставшийся промежуток времени — это выкинуть бОльшую часть фичей и навставлять костылей(поныв менеджменту что ничего непонятно, мы не успеем и т.п. — те в свою очередь задрейфили и пошли на уступки).
Да и руководство тоже молодцы. Сделали все для того что бы Рик выгорел. А потом нашли крайнего вместо того, что бы разобраться в ситуации на самом деле. Не снимаю вину с Рика, но менеджер должен уметь менеджить(простите меня за тавтологию). И уволить нужно было еще парочку менеджеров вместе с Риком(хотя может быть Рика нужно было просто отправить в принудительный отпуск/кинуть на другой проект).
1. Сложнее дебажить
2. Логика размазана
3. Если база начнет захлебываться, то это будет на порядки сложнее скалировать, нежели если бы это было логикой со стороны кода.
Как с точки зрения последующего мейнтенанса, так и с точки зрения скалирования это плохо. Да, возможно вы сможете написать быстрее что-то там, но потом поддерживать вам это будет стоить 10x по сравнению если бы у вас логика была просто на стороне приложения. Я это говорю основываясь на своем опыте работы как над кровавыми оракловскими энтерпрпайзами, где 70% всей логики в базе — кстати очень здорово расхлебывать им теперь перформанс проблемы так как бОльшая часть всей логики на стороне БД ;) Так и имея опыт разработки где база — просто хранилище данных, в котором проблемы как сопровождения так и перформанса решаются на порядки проще и дешевле.
Вопрос — зачем вы все еще пишите логику на стороне базы?
Какое-то время назад смотрели возможность настроить Master-Slave репликацию, что бы с каких-то Slave'ов можно было в realtime производить чтения и тем самым разгрузить master'a. После чтения документации остановились на потоковой репликации
( www.postgresql.org/docs/9.1/static/warm-standby.html#STREAMING-REPLICATION )
Может быть выбор не самый лучший и можете посоветовать что-либо более подходящее для read-only slave'ов в PostgreSQL?
Выбор идентификаторов должен быть диктован ограничениями системы/ее архитектурой, а не попыткой что-то там заобфусцировать/захачить/прикрутить еще один клевый хак-о-костыль.
Если Security заимплементирована криво, то это проблема дизайна приложения/архитектуры/квалификации программистов.
Взгляд допустим на тот же Spring Security дает понимание того, как оно могло бы по правильному работать. И даже если вы не работаете с Java, больше чем уверен, что есть множество решений под разные языки/платформы готовые, удовлетворяющие нуждам.
Ну или хотя бы на их основании можно в правильном направлении начать двигаться, а не лепить что-то по типа «А давайте добавим еще один ID и слепим их вместе, а потом будем разбивать их пополоам, никто ведь не догадается».
1). Останавливается контейнер(в нашем случае — Tomcat).
2). Стирается все из webapps директории
3). Стирается все из work директории
4). Заливается новый war
5). Контейнер(Tomcat) запускается
Таким образом мы избегаем главной проблемы, связанной с redeployment'ом — OOM.
Это работает в случае с приложениями, где down-time возможен и не мешает.
В случае, где downtime недопустим — у нас бежит несколько инстансов томката за лоадбалансером, и каждый инстанс редеплоится именно таким образом, что исключает downtime при backward-compatible изменениях базы данных.
Насчет SSP — я его обкатываю на своих личных проектах в первую очередь, прежде чем предложить использовать его в Production(с большой буквы), но пока что в целях — есть желание внедрить эту технологию отображения для начала, хотя бы для Admin Panel нашего сервиса.
Насчет JSF — личного опыта работы с ним я не имею, но от своих коллег, которые работали с данной технологией, я слышал не лестные отзывы. К ним относится — тормозит, если написаны какие-то кастомные компоненты, то при апгрейде на новую версию JSF их нужно зачастую сильно переделывать, что бы они заработали, кастомизировать под свои нужды внешний вид — тоже то еще занятие.
Насчет GWT — я немного пощупал эту технологию, и мне в принципе даже понравилось, но из минусов — довольно сложно изменять внешний вид, то есть я бы стал использовать только в том случае, если нужно набросать по-быстрому какой-то административный UI, где внешний вид не важен, так как кастомизировать отображение выходит сложнее, чем если это написать все с использованием более простых технологий.