Back to The tech awesomeness
Table of contents
Java chapters
Ozark a new MVC framework built on top of JAX-RS.
It can be integrated with CDI and BV.
MVC - is abbreviation for Model, View, Controller, also stands for architectural pattern, among MVVM, PAC, MVP, MVVM.
JAX-RS - is abbreviation for Java API for RESTful Web Services.
API - is abbreviation of Application programming interface, it also is a set of routines, protocols, and tools for building software and applications. (taken from wikipedia for today's version).
CDI - is abbreviation for Contexts and Dependency Injection (for the Java EE platform (CDI)).
BV - is again an abbreviation, which stands for bean validation.
Not so few abbreviations for a single framework.
What is inherently a framework?
As one could say: it is some system, that will frame the process inside, together with giving the evident outcome.
@Path("hello")
public class HelloController {
@Inject
private User user;
@GET
@Controller
public String hello(@QueryParam("name") String name) {
user.setName(name);
return "hello.jsp";
}
}
As a side look, one might say, it may drastically save time: by constantly creating the instances of models and putting them into controller(then other ones), with a later representing/manipulation of them in jsp's. Plus of course the knowledge about the state is also there. It will help to save a bunch of bug/debug time.
One dilemma comes later: the time was saved, and now it is time to tune performance, so how to decouple the jsp views from this architecture, for example to make them be served from a static server? Of course, it is possible to refactor by adding client controller and decoupling the views along with state as well, but how to guarantee the high quality plus timely manner for this move?
That's why maybe also to keep in mind, that ozark is stated as 'action-oriented' framework. What come to the specific project, where ozark might be used: the project actions(their amount and detalisation) might be changed. Thus, another root evaluative question or dilemma is: how often might the actions be changed in project in question?
The update from 2020-06-04.
Model(version)
/ \
/ \
/ \
/ \
SubModel(Interface) AnotherSubModel(Interface)
\ /
\ /
\ /
\ /
Model(interface)
/ \
/ \/updates \ /\manipulates
/ \
SubView(interface) / \ SubController(interface)
/ \ / \ / \
/ \ / \ / \
View(Version) View(Interface) Controller(interface) Controller(Version)
\ / \ / \ /
\ / \ / \ /
AnotherSubView(interface) \ / AnotherSubController(interface)
\ /
\ /
\ /
sees\/ \ / /\ uses
\ /
\ /
\ /
User
As of https://en.wikipedia.org/wiki/File:MVC-Process.svg at 2020-06-04.
Aside of that, there is https://uk.wikipedia.org/wiki/Ромбоедричний_графіт#/media/Файл:Бета-графит.jpg.
Aside of that, "Зміщення шарів у ромбоедричній формі" графіту "може досягати в природних графітах 30 %, у штучних вона практично не зустрічається.", as in https://uk.wikipedia.org/wiki/Графіт, which Google translation service translated as "The displacement of the layers in the rhombohedral form of graphite can reach 30% in natural graphites, in artificial it is almost non-existent.".
Also aside of that, there is Eliminating Technical debt.
As of 2020-06-04 in Java there is no allowance to create(to extend in this case) an interface from a class(interface from class cannot have inheritance), however, it takes some effort to displace, to offset the layer of the code both interfaces and classes.
The update from 2020-11-25.
For ozark as well as for Quarkus, Spring, ozark framework and possibly others.
The update from 2021-01-27.
When:
()before
()after
What:
()one file,stream of for example three types of S.data
After:
()download(net,not net)
()load(net,not net)
From:
()store, storage
()developible one with signature
()developible one with no signature
As:
()[start]
()[x]
()[options/\]
With:
()[notification]
()[no notification]
Via:
()[restart]
()[no restart]
Модель Вигляд Контролер МВК. Один з перших та розвинених шаблонів.
Оновлення від 2020-11-25.
Для озарк ozark так само як і для кваркус Quarkus, спрінг Spring, озарк ozark фреймворкових програмних каркасів і можливо інших.
Оновлення від 2021-01-27.
Коли:
()до
()після
Що:
()один документ файл,потік з наприклад трьох типів С.даних
Після:
()підвантаження(мережевого,не мережевого)
()завантаження(мережевого,не мережевого)
З:
()сховища, іншого сховища
()розробницького з підписом
()розробницького з не підписом
Як:
()[початок]
()[х]
()[вар'янти/\]
З:
()[оповіщенням]
()[не оповіщенням]
За допомогою:
()[перезавантаження]
()[не перезавантаження]
The update as of 2021-03-09.
Оновлення від 2021-03-09.
With your (not)smile or not,
if to insert into:
class SomeController implements java.util.function.Function {/**/}
class SomeService implements java.util.function.Function {/**/}
class SomeView implements java.util.function.Function {/**/}
class SomeModel implements java.util.function.Function {/**/}
then the following code chain is possible:
//...
controllerInstanse.apply(modelInstance);
//or even
controllerInstanse.andThen(modelInstance).andThen(viewInstance);
З вашою (не)радістю чи ні,
якщо додати до:
клас ДеякийКонтролер виконує джава.утіль.функція.Дія {/**/}
клас ДеякаПослуга виконує джава.утіль.функція.Дія {/**/}
клас ДеякийВид виконує джава.утіль.функція.Дія {/**/}
клас ДеякаМодель виконує джава.утіль.функція.Дія {/**/}
тоді наступна ціпка коду є можливою:
//...
контролерЗразок.застосувати(модельЗразок);
//чи навіть
контролерЗразок.іТоді(модельЗразок).іТоді(видЗразок);
I do not know whether it is a polymorphic pattern usage.
Я не знаю чи це є багатоформенним патерновим(модельним) використанням.
Мені невідома якась межа автоматизації таких ціпок кода які схожі на ціпки правил.
I hold no particular awareness on the border of automation of such code chains which are rather similar with the rule chains.
The update as of 2021-05-21.
Оновлення від 2021-05-21.
import org.eclipse.microprofile.graphql.Query;
//...
@Query
//...
@Path//jax-rs
//...
@GetMapping//spring framework
//...
There is a some similar part in these three annotations for a request.
Існує якась схожа частина в цих трьох анотаціях для запитів.
Still maybe this one is too obvious but as long as annotation processors process annotations as it is here: with this part of functionality without the compiler and runtime environment it is up to a developer as a need to know.
The processes are possible in this situation:
for annotations: to know the annotation processor AND/OR annotation documentation other than the annotation name and annotation parameters -> to read -> to use.
for method names and parameter names: to read -> to use.
So using and testing annotations require one more step.
Certainly there is some variability for closed and open source and for readability and availability of documentation in this case.
That is because in essense the processing requires the executing, running of the code in some form, and without compiler and runtime environment that additional piece of information as a need to know is executing itself via developer. Someone needs to run, to process that one in some form in this case though.
Оновлення від 2021-07-15.
The update as of 2021-07-15.
Якийсь тип замкнення даних прискорює деякі нещодавні переміщення з мвк до реактивних способів.
Some kind of data lock accelerates several recent migrations from mvc to reactive approaches.
Оновлення від 2021-12-10.
The update as of 2021-12-10.
In GitOps with actively cycling CI it is possible to allocate for example even some other resource if available in proper project by proper change in some file and its git commit.. and git merge.. But how about if there are more than 1 project. Then there is a navigation or routing between them. Whether or not it is included to another git commit.. and git merge.. cycle, it shows the point rotation in that such cycle. As an alternative one there is a navigation via API as well. But there are APIs which are closer to triggeral systems or ones which are closer to programming language and then as applications or alike or ones which are closer to browser than to others. What a nice to have is one that exports one API into others as a plugin or extension or external library to avoid reimplementing but with less customization. As it is findable from its name the point of rotation is the interface with its methods or functions in such approach. There is a difference in persistence of data between these two approaches, but the point was to show the point of similarity between them even though with rotation around different elements. This is a thanks message to colleagues and confrères.
У гітопс GitOps з активно циклюючим сіАй;CI можливо виділити наприклад навіть який інший ресурс якщо доступний у сумісному проекті сумісною зміною у якомусь файлі й його співмірним git commit.. й git merge.. Але як щодо якщо більше 1 проекту. Тоді існує переміщення між ними. Чи воно включно чи ні до іншого співмірного git commit.. йd git merge.. цикл, воно показує точку обертання у тому такому подібному циклі. Як іншим способом існує навігація за допомогою ППІ також. Але існують ППІ які ближче до перемикачевих систем чи ті які ближче до мови програмування і тоді як додатків чи застосунків чи подібних чи які ближче до ППіНТВСуІ ніж до інших. Що гарно мати так це один який експортує один ППІ у інщі як плагін чи розширення чи зовнішній файл щоби уникнути перевиконання але з меншим налаштуванням. Як можливо знайти з його назви точкою обертання є інтерфейс з його методами чи функціями у такому способі. Існує відмінність у збереженні даних між тими двома способами, але точкою було показати точку схожості між ними хоча і з обертанням навколо відмінних елементів. Це дякс колегам.
Оновлення від 2022-01-19.
The update as of 2022-01-19.
У spring фреймворковому програмному каркасі відсутній один з режимів і це допомагає розробникам і розробницям жорстко притримуватися з легкістю обраної стратегії протягом дизайну чи проектування чи архітектури додатка чи застосунка а також дозволяє використовувати можливість постійного їх перемішування тобто навіть змінювати таку стратегію з легкістю пізніше. Це також там і про відсутню особливість.
//..
@Autowired Strategy[] nextAutowiredStrategies;
@Встановлені Стратегії[] наступніВстановленіСтратегії;
//..
Оновлення від 2022-03-11.
The update as of 2022-03-11.
Якщо org.springframework.security.core.Authentication є ділимим з якомога більше інших фреймворкових програмних каркасів у будь який метод щоби продукт не був залежним від виконання як то саме від цього хоча це й інтерфейс тоді це рішення крізьфреймворково програмно каркасно. Це можливо схоже з деякими анотаціями у джіПіЕй JPA. Якщо такий фреймворковий програмний каркас вважається додатково й платформою як і інший фреймворковий програмний каркас за умови якщо для якого той будь метод теж буде сумісним то тоді таке рішення також й кросплатформне.
If org.springframework.security.core.Authentication is sharable with as many as possible other frameworks in any approach in order to for the product not to be implementation dependent particularly from this one eventhough it is already an interface then such solution is crossframework. It is somewhat similar with some annotations in JPA. If such framework is considered a platform as well as other framework with a condition of for that one framework that any approach is also suitable then such solution is crossplatform as well.
Оновлення від 2022-03-12.
The update as of 2022-03-12.
Тож декілька більш розгорнутих описів щодо оновлення ніж вчорашнє.
So there are more unwrapped descriptions of updates than a one of yesterday in this update.
Тож такий клас:
So such a class:
public class SessionProfile //in some triggerral system it has a peculiar fix in some situation.as of 2022-12-14. but several persons used such fix under critical comments more than a decade ago..that is under certain circumstance it would be a nice update for http://thetechawesomeness.ideasmatter.info/accelerator-of-code-progress.html
extends User //org.springframework.security.core.userdetails.User {/**/}
Він був переміщений вчора з моделів до DTO.
it was moved yesterday from a package of models to DTOs.
Він не був для збереження щодо його даних і не є.
It was not for persistence what is for its data and it is not.
Хоча цей клас від якого він розширений і має чудову функціональність username, password, enabled, accountNonExpired, credentialsNonExpired, accountNonLocked, сollectionOfGrantedAuthorities і ми з колегою колись його зберігали у цьому проекті зважаючи щодо багацької кількості посилань щодо цього до деяких цих сторінок у веб все ж таки вирішили його не зберігати. Як то кажуть to keep a long story short, тому що зберігаючи його у базі даних хоча це і чудова функціональність ми як би прив'язуємо проект саме до цього фреймворкового програмного каркасу що можливо нагадує чи то замкнення виробникаданих як то vendor lock, який ми самостійно застосовуємо у такому випадку чи то жорстке зв'язування тобто tight coupling. Хтось би міг сказати що варто було поділити моделі на ті що для збереження їх даних і на ті що для передачі шаблонів проектування для яких існує достатньо наприклад VO, POJO, і знову ж DTO але тут застосований інший спосіб щоби відділити код проекта від кода фреймоворкового програмного каркаса. Бо незважачи що ця функціональність і чудова org.springframework.security.core.userdetails.User без такого стандарта як JPA для збереження даних класів невідомо у цьому випадку чи інщі фреймворкові програмні каркаси поділяють думку про те що така функціональність чудова. А таке жорстке прив'язування чи таке замкнення виробника за відсутності такого стандарта не дозволяє однозначно сказати що щодо цього вважають розробники і розробниці у інших фреймворкових програмних каркасах і не дозволяє легке виокремлення коду проекта від коду фреймворкового програмного каркаса для такого виокремлення. Тож за таких умов це для мене це відкрито закрите питання тобто open ended question. Тому міграція тобто переміщення між фреймворковими програмними каркасами як це можливо між виконаннями JPA у проекті який його включає як особливість для уникнення подібних ситуацій з чи то замкненням виробника чи то з жорстким зв'язуванням є достатніми у такий спосіб за відсутності такого стандарту для фреймворкових програмних каркасів. Також тому що наприклад 1 фреймворковий програмний каркас для них усіх цікава ідея але їх різноманіття полягає у тому що фреймворкових програмних каркасів вже достатньо проміжок часу декілька тобто більше одного. А ситуація з відсутністю чогось подібного до JFrA, JFA чи подібних не нова і присутня достатньо тривалий проміжок часу і достатньо описано принаймні цими веб сторінками. А це така сама ситуація як і з базами даних і залежностями для них для коду але яка вже була подібно чи інакше вирішена з моменту появи перших версій JPA. 1. А якщо без чогось подібного до JFra, JFrA додавати по дві залежності двох фреймворкових програмних каркасів при міграціях то це збільшуватиме обсяг проекту щодо його вимог щодо простору. 2. А якщо без чогось подібного до JFra, JFrA не додавати по дві залежності двох фреймворкових програмних каркасів при міграціях то це призводитиме до ситуація як то https://stackoverflow.com/questions/12078404/org-springframework-security-core-userdetails-user-cannot-be-cast-to-myuser але лише тому що у подібних проектах відсутнє щось подібне до JFra,JFrA тобто це повільніше. Тобто при міграціях це цілком відомий наслідок ситуації подібного жорсткого зв'язування чи подібного замкнення виробника. Присутність чи наявність у проекті стандарту якогось подібного до JFra, JFrA сприяє уникненню обох таких двох описаних проблем окрім уникнення замкнення виробника якщо та функціональність є спільною у такому стандарті і уникненню пошуку чи це у самому фреймворковиму програмному каркасі лише за допомогою документації адже суто функціонально навіть якщо така чудова функціональність присутня у стандарті але відсутня у фреймворковому програмному каркасі то фреймворковий програмний каркас з будь якої причини наприклад кидає виключення про непідтримуваний метод як то throws UnsupportedMethod що і допомагає розробникам і розробницям уникає пошуку щодо цього ЛИШЕ у документації тому це можливо відтак і за допомогає API з підказками ІСР IDE або звичайно й при компіляційних складаннях і сприяє пришвидшенню міграцій між фреймворковими програмними каркасами з уникненням повторення такої ситуації у різноманітті проектів які використовую подібні фреймворкові програмні каркаси. Це був найкоротший опис такої ситуації у такому оновленні.
Оновлення від 2022-03-14.
The update as of 2022-03-14.
У випадку необ'єднаного import org.hibernate.annotations.Type; який надає можливість визначати тип даних з javax.persistence тобто з більш специфічним і це призводить у модулі до додакових залежностей щодо для нього. Чи навпаки. Що є DRY але односпрямовано. Але це підтримує принаймні односпрямовану з'єднаність мід джава java кодом DML. Або ж як альтернатива при відсутності такої з'єднаності водночас у одному класі іншою альтернативою є використання наприклад Google FlyWay тож це більше схоже .до як розрізнення і як до розширення. Наприклад для як у sormula.
Оновлення від 2022-04-08.
The update as of 2022-04-08.
The absence of interface for conversions between types of JCF Java Collection Framework and others in search results shows many reiterated solutions for that mostly in cycles and also a need to know implementation details for such conversions or a need to search for them or to reimplement in a multitude of projects for and inside iterable processes with such objects or processes with iterables and other such ones. Which is WET and not DRY, and if more often or more popular than not then it is more stable and less effective, until Eliminating Technical debt if it appears for example afterwards.
Відсутність інтерфейса для перетворювань між типами JCF Java Collection Framework джава фреймворкового програмного каркаса для колекцій та інших у результатах пошуку показує повторювані рішення для того переважно циклами і також потребу знати деталі виконання для таких перетворень чи потребу шукати їх чи перевиконувати у багатьох проектах для і у середині ітерованих процесів з такими об'єктами чи процесами з ітерованими і іншими подібними. Що є WET а не DRY, та якщо частіше чи популярніше ніж інакше тоді це сталіше але менш ефектикнивніше до Eliminating Technical debt;видалення технічного боргу якщо воно з'являється наприклад опісля.
Що після цього є даними наприклад для виглядів. Хоча і у деяких кодах виглядів таке присутнє теж.
Якщо ж eSIM перетворення включено з під'єднанням і від'єднанням під'єднані до git гіт чи подібної системи то таке рішення повністю можливе бути відстежуємим. щодо таких перетворень навіть рівнем розробки. При достатньому наявному вільному просторі або зі стисканням даних з подальшим їх відновленням для цього. Таким чином кешеподібний простір як веб послуга чи як веб сервіс дещо зменшує межі такого обмеження.
Обидва для автоматизації і зменшення повторювання у коді також як і у PMD і подібних але у першому у одній з деталів виконань для такого інтерфейса він можливо визначає завдяки instanceof чи більш елегантно.
Так що така табличка:
міграція даних;переміщення даних
формат
з цифрового до цифрового
з паперового до цифрового
з цифрового до паперового
з паперового до паперового
...
After findings of such gaps of absence of standards such as the first former one of today's update or JFra or missing application of such available standards it is pretty easy to identify models with a propagation a vendor lock of some sort. Після знахідок подібних відсутностей стандартів таких як перший попередній з сьогоднішнього оновлення чи ДжФА чи відсутні застосування подібних доступних стандартів достатньо легко визначити моделі з просуванням і розповсюдженням замкнень виробника чи виробниці якогось типа.
І поки наприклад багато ТБ каналів мають додаток чи застосунок і навіть веб сайт чи веб місце то небагато вебсайтів і вебмісць або ж додатків і застосунків мають наприклад ТБ канал хоча й існують деякі приклади намагань формуючи деяку систему .
The update as of 2022-05-27.
Оновлення від 2022-05-27.
Previously if as with that eSIM if in java for example some eSIM identifier is placable in some collection which effectively means for example a mobile number in a collection eventhough there are more layers there and then if opensource there are more code to review. Such layers as in mvc or more.
Попередньо якщо як з тим eSIM якщо через джава наприклад якийсь eSIM визначник розташовуємий у якійсь колекції що позначає мобільний номер у колекції у якому можливо й більше ніж один елемент а їх обробка є швидшою у цьому випадку ніж у деяких інших хоча за тих умов там і більше шарів і якщо це відкритокодовий то й більше для перегляду й не лише кода. Таких шарів як у мвк або більше.
Тож це схоже з цим випадком:
As in such one:
😼 <-------------------> 🐌