Back to The tech awesomeness
Table of contents
Java chapters

The article for today.

Decoupling: Business logic is located in FRONT END-Java server pages for other purposes than representational ones

Influenced Components: [ BACK END ] [ FRONT END ]

Move corresponding logic from FRONT END into single-responsibility BACK END Manager-layer:
-> Investigate such places in code base [ bottleneck process ]

-> Create precise refactoring JIRAs [ ongoing parallel process ]

-> Implement each refactoring JIRA [ ongoing parallel process ]

-> Control the quality during installed review-process for each JIRA [ ongoing parallel process ]

Resources required: depends on CURRENT 'SW-CLEANUP' JIRA estimations + FOUND JIRA estimations during investigation + other practices and routines.

Consequences if handled:
1. Most product developers are happier.
2. There is a possibility for truly FRONT END development and BACK END development. 3. No more mixed development for majority of new features.

Consequences if not handled:
1. At some point product becomes as much agile as stone is.
2. No chance to understand for new developers in timely manner.
3. Code complexity grows at the extent, where only the few ones can understand it.
4. More bugs can be expected because of this mixture and increasing complexity through time.

Business logic is spread over BACK END-layer-classes

Influenced Components: [ BACK END ]

Unite into single-responsibility Manager-layer from other BACK END layers, such as DAO's,
-> Investigate such places in code base [ bottleneck process ]

-> Create precise refactoring JIRAs [ ongoing parallel process ]

-> Implement each refactoring JIRA [ ongoing parallel process ]

-> Control the quality during installed review-process for each JIRA [ ongoing parallel process ]

Resources required: depends on CURRENTLY exitsing 'SW-CLEANUP' JIRA estimations + FOUND JIRA estimations during investigation + other practices and routines.

Consequences if handled:
1. Most product developers are happier.
2. Possibility is created to decouple and increase speed and visibility of product (business) development from technical routines.

Consequences if not handled:
1. At some point product becomes as much agile as stone is.
2. Complexity is growing and because of this mixture it is hard to answer to requests with certain assurance after long analysis.
3. Spent time for bug fixes and features continues to grow for newly and long-ago joined developers.
4. More bugs can be expected.

Feature flag CLEAN-UP

Influenced Components: [ BACK END ] [ FRONT END ] [ DATABASE ]

Check the confluence Portal Configuration Flags cleanup :
-> Investigate such places in code base [ bottleneck process ]

-> Create precise refactoring JIRAs [ ongoing parallel process ]

-> Implement each refactoring JIRA [ ongoing parallel process ]

-> Control the quality during installed review-process for each JIRA [ ongoing parallel process ]

Resources required: depends on CURRENTLY exitsing 'SW-CLEANUP' JIRA estimations + FOUND JIRA estimations during investigation + other practices and routines.

Consequences if handled:
1. Most product developers are happier.
2. Features will stop to group on one another in invisible manner.

Consequences if not handled:
1. Feature list is as big and un-searchable as one's imagination can imagine.
2. Spent time for bug fixes and features continues to grow for newly and long-ago joined developers.
3. More bugs can be expected with a very high probability because of nesting feature on top of existing features and absence of transparency there.

Duplicated logic-related issues

Influenced Components: [ BACK END ]

Merge common methods from DAO/Manager layers into sub-project
Add dependency of sub-project
Use DAO-methods from sub-project
(Optional) Later on DAO/manager layers can be extracted into own jars, which can allow implementation of onion architecture https://www.infoq.com/news/2014/10/ddd-onion-architecture

-> Investigate such places in code base [ bottleneck process ]

-> Create precise refactoring JIRAs [ ongoing parallel process ]

-> Implement each refactoring JIRA [ ongoing parallel process ]

-> Control the quality during installed review-process for each JIRA [ ongoing parallel process ]

Resources required: depends on CURRENTLY exitsing 'SW-CLEANUP' JIRA estimations + FOUND JIRA estimations during investigation + other practices and routines.

Consequences if handled:
1. Most product developers are happier.
2. Project is back to maintainable state.

Consequences if not handled:
1. At some point product is still a stone.
2. No major improvements or features can still be done to product.
3. Spent time for minor bug fixes and features continues to grow for newly and long-ago joined developers.
4. More bugs can be expected.

Method names are imprecise and are not reviewed

Influenced Components: [ BACK END ]

Create method naming strategy
Rename the non-understandable methods from code base
-> Investigate such places in code base [ bottleneck process ]

-> Create precise refactoring JIRAs [ ongoing parallel process ]

-> Implement each refactoring JIRA [ ongoing parallel process ]

-> Control the quality during installed review-process for each JIRA [ ongoing parallel process ]

Resources required: depends on CURRENTLY exitsing 'SW-CLEANUP' JIRA estimations + FOUND JIRA estimations during investigation + other practices and routines.

Consequences if handled:
1. Most product developers are happier.
2. Understand-ability is higher, thus search time for developer is higher.
3. Easier to re-use the code for new feature, thus new features are more transparent.

Consequences if not handled:
1. At some point product becomes as much agile as stone is.
2. Spent time for bug fixes and features continues to grow for newly and long-ago joined developers.
3. Duplicated double-work which is already done can be expected.

Data source switching has costs-related issues

Influenced Components: [ BACK END ] [ DATABASE ]

Consult with platform team: how can it be handled instead of current approaches: application at server 1+ application at server 2 usage-design >> application at server 1+ application at server 2 integration-design >> application at server 1+application at server 2 technical>>design?

"Magic numbers"-related issues with unfamiliar meaning

Influenced Components: [ BACK END ] [ FRONT END ] [ DATABASE ]

Use constants with readable names instead of "magic numbers"
-> Investigate such places in code base [ bottleneck process ]

-> Create precise refactoring JIRAs [ ongoing parallel process ]

-> Implement each refactoring JIRA [ ongoing parallel process ]

-> Control the quality during installed review-process for each JIRA [ ongoing parallel process ]

Resources required: depends on CURRENTLY exitsing 'SW-CLEANUP' JIRA estimations + FOUND JIRA estimations during investigation + other practices and routines.

Consequences if handled:
1. Most product developers are happier.
2. No more guessing, what 1 can mean in office for availability or what 1 can mean for other properties, thus it is faster to implement or refactor.

Consequences if not handled:
1. At some point product becomes as much agile as stone is.
2. Spent time for bug fixes and features continues to grow for newly and long-ago joined developers.
3. More can be introduced.

String concatenation issues

Influenced Components: [ BACK END ]

Fix occurrences
-> Investigate such places in code base [ bottleneck process ]

-> Create precise refactoring JIRAs [ ongoing parallel process ]

-> Implement each refactoring JIRA [ ongoing parallel process ]

-> Control the quality during installed review-process for each JIRA [ ongoing parallel process ]

Resources required: depends on CURRENTLY exitsing 'SW-CLEANUP' JIRA estimations + FOUND JIRA estimations during investigation + other practices and routines.

Consequences if handled:
1. Most product developers are happier.
2. Performance boosts in few percentage here and there, so that the customer satisfaction might grow, for those, who are time-limited and time-critical.

Consequences if not handled:
1. At some point product becomes as much agile as stone is.
2. Spent time for bug fixes and features continues to grow for newly and long-ago joined developers.
3. Slowness is higher for end-customers or thier users.

Data types consistency issues

Influenced Components: [ BACK END ]

Fix occurrences
-> Investigate such places in code base [ bottleneck process ]

-> Create precise refactoring JIRAs [ ongoing parallel process ]

-> Implement each refactoring JIRA [ ongoing parallel process ]

-> Control the quality during installed review-process for each JIRA [ ongoing parallel process ]

Resources required: depends on CURRENTLY exitsing 'SW-CLEANUP' JIRA estimations + FOUND JIRA estimations during investigation + other practices and routines.

Consequences if handled:
1. Most product developers are happier.
2. Understand-ability is higher and less assumptions are done, thus the overall maintainability is higher, which leads to faster and less-bugs delivery.

Consequences if not handled:
1. At some point product becomes as much agile as stone is.
2. Spent time for bug fixes and features continues to grow for newly and long-ago joined developers.
3. Zoo of different data types which leads to slower delivery.

Positional parameter-related issues

Influenced Components: [ BACK END ]

Fix occurrences
-> Investigate such places in code base [ bottleneck process ]

-> Create precise refactoring JIRAs [ ongoing parallel process ]

-> Implement each refactoring JIRA [ ongoing parallel process ]

-> Control the quality during installed review-process for each JIRA [ ongoing parallel process ]

Resources required: depends on CURRENTLY exitsing 'SW-CLEANUP' JIRA estimations + FOUND JIRA estimations during investigation + other practices and routines.

Consequences if handled:
1. Most product developers are happier.
2. More bugs can be introduced during refactoring, thus time to stabilize is higher and higher.

Consequences if not handled:
1. At some point product becomes as much agile as stone is.
2. Spent time for bug fixes and features continues to grow for newly and long-ago joined developers.
3. "select ("?,?,?,?,?,?,?,?,?,?,?") from..." turns to become normal practice and syntax whatever these question marks mean for every newly- or long-ago joined developer.
4. Complexity grows, delivery time drops.
5. More bugs can be expected.

Transaction-related issues

Influenced Components: [ BACK END ]

Hibernate transactional specialist can solve handling of this problem because I have requested competence upgrade request for hibernate: Training 2017

Duplicated SQLs-and-methods-related issues

Influenced Components: [ BACK END ]

Clean DAO-layer duplicated logic
Clean Manager-layer duplicated logic
-> Investigate such places in code base [ bottleneck process ]

-> Create precise refactoring JIRAs [ ongoing parallel process ]

-> Implement each refactoring JIRA [ ongoing parallel process ]

-> Control the quality during installed review-process for each JIRA [ ongoing parallel process ]

Resources required: depends on CURRENTLY exitsing 'SW-CLEANUP' JIRA estimations + FOUND JIRA estimations during investigation + other practices and routines.

Consequences if handled:
1. Most product developers are happier.
2. Maintability grows, delivery time grows a bit.
3. Transperancy grows, more bugs can be catched earlier and avoided.

Consequences if not handled:
1. At some point product becomes as much agile as stone is.
2. Spent time for bug fixes and features continues to grow for newly and long-ago joined developers.
3. More bugs can be expected.

Null Pointer Exception-related issues

Influenced Component: [ BACK END ]

Limit usages of null-value in newly-created logic-classes at max extent possible, which was introduced in Copy Pasting Code v.11 on 29 Sep 2015 14:11
-> Investigate such places in code base [ bottleneck process ]

-> Create precise refactoring JIRAs [ ongoing parallel process ]

-> Implement each refactoring JIRA [ ongoing parallel process ]

-> Control the quality during installed review-process for each JIRA [ ongoing parallel process ]

Resources required: depends on CURRENTLY exitsing 'SW-CLEANUP' JIRA estimations + FOUND JIRA estimations during investigation + other practices and routines.

Consequences if handled:
1. Most product developers are happier.
2. Less bugs will be experienced.

Consequences if not handled:
1. At some point product becomes as much agile as stone is.
2. Spent time for bug fixes and features continues to grow for newly and long-ago joined developers.
3. More bugs can to be expected.

Exception handling issues

Influenced Components: [ BACK END ]

Create exception handling strategy
Create exception handling hierarchy eventually based on that exception handling strategy
-> Investigate such places in code base [ bottleneck process ]

-> Create precise refactoring JIRAs [ ongoing parallel process ]

-> Implement each refactoring JIRA [ ongoing parallel process ]

-> Control the quality during installed review-process for each JIRA [ ongoing parallel process ]

Resources required: depends on CURRENTLY exitsing 'SW-CLEANUP' JIRA estimations + FOUND JIRA estimations during investigation + other practices and routines.

Consequences if handled:
1. Most product developers are happier.
2. Easier development of business policies.
3. More insights for business holders can be expected.

Consequences if not handled:
1. At some point product becomes as much agile as stone is.
2. Spent time for bug fixes and features continues to grow for newly and long-ago joined developers.
3. More bugs can be expected.
4. Longer to tackle complicated business rules.

Performance issues

Influenced Components: [ BACK END ] [ DATABASE ]

It has direct connection with approach XYZ-scalability http://microservices.io/articles/scalecube.html

No need to handle because the functionality is implemented and up-and-running and unless the technical debt is at least 80% handled, because otherwise before doing handling the technical debt, while making the system faster, such effort or attempt will simply eat the time resources drastically because of the overhead of current not implemented technical debt in vast batch expenses and increase at least my frustration levels to highest value.
Return to handling this topic eventually after technical debt is at least 80% handled.
Consequences if not handled:
1. At some point product becomes as much agile as stone is.
2. Customers can complain about slowness but it will be slow to change code base because of other technical debt nature and its affected influence.

Recommended Actions:

Limit at the maximum possible extent introducing the new logic/features/change-requests based on the old logic which is full of technical debt currently until 60% of technical debt will be handled.

Install mildly strict [ 3 out of 1 - to - 4 scale ] review-process and create definition for what 3-scale-magic number means on that scale: 1) what to review 2) how long 3) are following documents still actual: GENERAL-290 - Code review: Extended MEPS (Closed. Tested on production) and https://jira.local/jira/secure/attachment/19288/code%20review.txt and can be used?

Introduce modern checklist for review based on current state and knowledge about code base.

Notes:

FRONT END technical debt is not taken into account except of "Decoupling: Business logic is located in FRONT END-Java server pages" issue. FRONT END technical debt would be better analyzed as well in another effort.
FRONT END side mostly was not taken into account during analysis and creation of these proposals and it might have more influences on BACK END / DATABASE components if to taken into account FRONT END-old technical debt issues.
There are lots of personal "opinionated"-solutions in these proposals.
Please criticize at max taking into account the strategy of agree-to-disagree.
Please feel free to rethink the proposal in different ways.
Risk analysis was not involved, please find specialist on that topic.
Resource analysis is purely dependent on the results of investigation and analysis of each of such technical debt handling JIRA tickets.

Additional information:

Review is one of the fastest processes for identifying issues fast on their early stages right after the changes were done to the code base.

https://en.wikipedia.org/wiki/Software_review

Results

Catching most errors before test

• Review plus test is much cheaper than just test

Jonathan Aldrich 15 November 2015 https://www.cs.cmu.edu/~aldrich/courses/413/slides/33-code-reviews.pdf

What does each part of technical debt mean to each developer of the company working on the same product?
https://trellis.co/blog/consequences-accumulating-technical-debt/
https://en.wikipedia.org/wiki/Technical_debt#Consequences

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

Martin Fowler 1 October 2003 https://martinfowler.com/bliki/TechnicalDebt.html

The update as of 2020-09-04.


    class LongComputationException extends RuntimeException {
        /*message with computing about: connection to remote resource; formula; mechanism of iterating; method; cycle; custom algorithm.*/
        //http://thetechawesomeness.ideasmatter.info/summation.html;2022-05-11
    }

The update as of 2020-10-28.


    class Method{/**/}
    class Part extends Method{
        checkCompatibility() {/**/}
        Part getPartById(Id partId) {/**/}
    }
    class Factory extends Part{/**/}
    class RedCircleFactory extends Factory{/**/}
    class GreenCircleFactory extends Factory{/**/}
    public enum FactoryType
    {
        RedCircle,
        GreenCircle
    }
    class FactorialFactory extends Part {/* factory ship */
        public Factory getFactory(FactoryType type) {
        switch (type) {
            case FactoryType.RedCircle:
                return new RedCircleFactory();
            case FactoryType.GreenCircle:
                return new GreenCircleFactory();
            default:
                throw new NotSupportedException();
        }
    }
    class FactorialFactoryEditor extends Part {
        void edit(Id partId) {/**/}
    }
    class FactorialFactoryRemover extends Part {
        Part remove(Id partId) {
            /**/
            return getPartById(partId);
        }
    }
    class FactorialFactoryRecycler extends Part {
        Part[] recycle(Id partId) {
            Part[] parts = new Parts[]();
            /**/
            return parts;
        }
    }/*for objects with a cost of garbage cleaning and search by unique identifiers among multiplicity of unique identifiers and customiszation. in the name of factory method pattern.*/

The update as of 2020-10-29.

BitBar application provides a possibility to launch java files and java archives via sh shell enveronment in macOS menu bar as plugins.


    bitbar://openPlugin?title=title&src=file:///location
    bitbar://openPlugin?title=title&src=http://location

The update as of 2021-02-10.

I have found a comment about description of devices and also there has benn a technology which provides an connect between devices maybe 15 years age. The web site with a copy of approach of such technology if has the web address of another web site, by some endpoint can fetch the token, register and log in and get the sitemap or some tree like structure. Even 2 ones.

But it seems such endpoint or other negotiation in protocol should be still predistributable for that.

Some one in the style of https://en.wikipedia.org/wiki/Plug_and_play for those web sites or https://en.wikipedia.org/wiki/Autoconfigure for those web sites.

The update as of 2021-03-24.


    analysis --> compulysis
       /\            |
        |____________|
       back propagation

Видалення технічного боргу

Стаття сьогодні.

Оновлення від 2020-09-04.


    клас ДовгеОбчислюючеВиключення розширює ВиключенняСередовищаВиконання {
        /*повідомлення про обчислення про: з'єднання з віддаленим ресурсом; формулу; мезанізм перевертання; метод; цикол; традиційний алгорітм; інші.*/
    }

Оновлення від 2020-10-28.


    клас Спосіб{/**/}
    клас Частина розширює Спосіб{
        перевіритиСпівпадіння() {/**/}
        Частина отриматиЧатинуПоВизначнику(Визначник визначникЧастини) {/**/}
    }
    клас Завод розширює Частину{/**/}
    клас ЧервонийКоловийЗавод розширює Завод{/**/}
    клас ЗеленийКоловийЗавод розширює Завод{/**/}
    відкрито перечислення ЗаводнийТип
    {
        ЧервонеКоло,
        ЗеленеКоло
    }
    клас ЗаводнийЗавод розширює Частину {/* заводний човен */
        відкрито Завод отриматиЗавод(ЗаводнийТип тип) {
        перемикати (тип) {
            уВипадку ЗаводнийТип.ЧервонеКоло:
                повернути наново ЧервонийКоловийЗавод();
            уВипадку ЗаводнийТип.ЗеленеКоло:
                повернути наново ЗеленийКоловийЗавод();
            вІншомуРазі:
                кинути наново НеПідтримуванеВиключення();
        }
    }
    клас ЗаводноЗаводнийЗмінювач розгирює Частину {
        вакантно змінити(Визначник визначникЧастини) {/**/}
    }
    клас ЗаводноЗаводнийВидаляч розширює Частину {
        Частина видалити(Визначник визначникЧастини) {
            /**/
            повернути отриматиЧатинуПоВизначнику(визначникЧастини);
        }
    }
    клас ЗаводноЗаводнийПереробник розширює Частину {
        Частина[] переробити(Визначник визначникЧастини) {
            Частина[] частини = наново Частини[]();
            /**/
            повернути частини;
        }
    }/*для об'єктів з коштом прибирання сміття і пошуку за унікальними визначниками серед багатьох визначників і налаштовуваності. за мотивами factory method pattern'у.*/

The update as of 2020-10-29.

Оновлення від 2020-10-29.

BitBar застосунок чи додаток надає можливість запускати файли джава java і архіви джава java за допомогою середовища ш sh у macOS меню просторі як додатки.


    bitbar://openPlugin?title=title&src=file:///місцевість
    bitbar://openPlugin?title=title&src=http://місцевість

The update as of 2021-01-15.

Оновлення від 2021-01-15.

Можливо помітити візуально реп'яшки(такі як закрили так і відкрили), але не почути їх в мережевих програмах перегляду сторінок в інтернеті. Вони можуть слідкувати(існує такий тип реп'яшків) переміщаючися між сторінками в цей час щодо 'віувіувіу' і інших. І тоукєни теж. Більше того, реп'яшки можуть накопичуватися в таких програмах. А ще тоукєни можуть бути вcередині реп'яшка. А навпаки ні. Тож висновок: таким чином реп'яшок може бути колекційною моделлю для тоукєна. Але якщо тоукєн > ~ 4093 байтів, то він не поміститься у реп'яшок.

The update as of 2021-01-16.

Оновлення від 2021-01-16.

At least it is partially overcomeable with a help of addition and substraction of their parts. When one inside another one.

Проте щонайменш це є хоча б частково прохідно за допомогою базових додавання і віднімання (рядків) їх частин. Коли один з них в іншому. В залежності де вони знаходимуться, бо там існують інші обмеження, одне з них непрохідне(станом на сьогодні) наприклад в ~65500 байтів(приблизно).

Доте це призвело до іншої: service proposition as a service(пропозиція послуг(и) як послуга).

When I consider repeatable emails or digests and so on from this narrow point of view(service proposition as a service): spam type and non spam type, the differentiator there for them is the absence of subscription and unsubscription services in one of those types, particularly in spam type of email. In some types of paper mail the same one applies is as well.

Коли я розглядаю повторювані електронні листи з інформаційними наборами і інші з цієї вузької точки зору(пропозиція послуг(и) як послуга): спамні і неспамні, відрізняльником тут для них є відсутніть послуг підписки і відписки в одному з цих типів, точніше у спамному типі електронної пошти. В деяких видах паперової пошти так само.

Саму послугу відрізняння електронних листів спама від електронних листів неспама надає звичайно не електронний лист а постачальник електронної пошти(як послуги разом з іншими постачальниками). Як імовірно і паперової, але це неточно. Тож таке відрізняння електронних листів спама від електронних листів неспама як послуга як мінімум ділиться на три типа: 1) не відрізняння(нібито спама немає, лол); not marking as spam, 2) неавтоматичне помічання як спам(і від цього як кажуть там всередені щось електронне вчиться з цього процесу помічання); non automatical marking as spam і 3) помічання автоматичне(як кажуть те, що там всередині навчилося електронне, може робити це помічання теж); automatical marking as spam. Для паперової пошти умовно так само(необов'язково електронне звичайно).

А далі, як втретє, зазвичай, вже зі спаму ця електронна листова купа може бути видалена(автоматично) через скікі-то проміжку часу. І це теж послуга з видалення електронного листу зі спаму у постачальника електронної пошти. І вона теж ділиться на ввімкнену і вимкнену. Але тут в цих двух послугах процес можливий лише такий:


    1 -> 2.

Тобто неможливо видалити електронний лист, після чого помітити його як спамний, це нонсенс, абсурд. Можливо. Якщо є кошик для видаленних електронних листів і тому подібне:


    2 -> 1(але з кошиком для подібних).

Це два різних процеси.

Так послуги фільтрації і переадресації дуже розвинені у електронних поштових постачальниках і у системах. Проте я досі декілька років шукаю постачальника електронної пошти і/або подібний стандарт де існує присутня інтерграція з чимось накшталт drools, іншої зайнятості бізнес правил керівної системи business rule management system (BRMS) яка додає можливість створювати подібні процеси(помічання як спам і видалення як спам і можливих інших компоненталів) для наявної електронної пошти.

Але продовжуючи на цьому потужному компоненталі: ось фантантастично, Ілантославе Мохначевече, але це можливо витратить твій коштовний час на дд;нч tl;dr, або tl;dl, проте там є і про інших відомих людей минулого, і безпосередньо про Томаса Бейза, 1702 — 1761, чий винахід є залученим в деякі алгоритми маркування як спама деяких електронних листів.

Тож визначення компоненталя тут відсутнє, тож послуга як компоненталь. І водночас компоненталь це щось чітко визначене. Але компоненталь для щонайменш цих двох послуг(позначання як спам і видалення спаму) може дозволити копіювати послуги, як функцією контроль це control c, контроль ве control v.

І тоді після тієї ознайомлення з цим, стане більш вочевид, що можливо копіювати окрім:


    1. операндів(значень). ну і операторів звісно.
    2. формул.
    3. даних для формул.
    4. додатково отут саме ці компоненталі.

Бо на створення нестандартизованих гачків хуків hooks, я і витрачав найбільший проміжок часу. І у нестандартизованій формі саме це займало найбільше і створювало найбільше запитань і проблем. Ну це мої, як зазначили і критикують інші, суб'єктивна думка і твоє суб'єктивне спостереження.😉

У тому випадку, якщо сервіс послуга як компоненталь.

Розповім ще одну таємничку, тобто таке спостереження котре я помітив в електронних сервісах і електронних послугах: захучені послуги сервіси(електронні) рідко змінюються. Чи ознака це того, що це складно, або що це крихко(fragile) чи інша я не знаю.

Щоб знайти цьому підтвердження: я достатньо помічав подібні компоненталі, хуки, інтеграції, та їх історію змін в різних електронних перемикачевих системах. В кращих випадках і практиках сусідньо швидко створювалися, інші, або нові подібні. Теж нестандартизовані.

Досі їх неможливо копіювати. І досі в тому я витрачу найбільший проміжок часу.

Але з іншого боку цьому є ціна: достатньо запитати когось залученого до створення того алгоритму, особливо пришвидшено: ну як ти. І помітно що кожен день створюються нові перемикачеві системи з нестандартизованими хуками без компоненталів.😉

Компоненталь, ну як ти.◼️

Умовно:


                                                      |
                                                      |
компоненталь зі стандартом для кнтрл це,ве            |--
компоненталь без стандарту                            |-
                                                      |
                                                      |________________________
                                                       менший проміжок часу; більше ефікасі; х
                                                      |
                                                      |
componental with Standart{/*Standard*/} for ctrl c,v  |--
componental with no Standart{/*Standard*/}            |-
                                                      |
                                                      |________________________
                                                       less period of time; more efficacy; x

Іншими словами: достатньо уявити що ви можете якось скопіювати цілий сервіс цілу послугу в інший сервіс іншу послугу. Електронно. Приблизно способом як копіюються інші з наприклад натисканням кнтрл це,ве. Ті послуги, які це дозволяють, тобто ті послуги, які надають таку можливість.

Тобто отут індуктивний логічний висновок: такі подібні електронні послуги формують свій тип мережі, тому що мають межі для цієї можливості легкого копіювання. Інші називають її ще електронною екосистемою.

Звичайно без цього вейстін тайм та й годі.

Звичайно мені подобаються замовники і замовниці, котрі замовляють перемикачеві системи без компоненталів, бо подібного стандарту ж немає вже декілька років. Ось ці електронні системи і функціонали і копіюються, дублюються , без перевикористання і відрито кодово і закрито кодово. І за подібну діяльність це ще й сплачують від 62500 грн (UAH) і від 82500 грн (UAH) у мінімальних випадках десь. ◼️ Дуже помітно, що за подібне іноді і в еквівалентах рівнозначеннях, якщо компанія немісцева, заморська, заокеанська. Оминаючі навіть про неелектронні варіанти, паралелі подібного. ◼️

Влаштування електронним хукером. Проте ж існує і інший, неелектронний хукінг. Ням. Ще ж існує і ⛏. І не один. Вейстін тайм та й годі бо це є цілком за даних умов. ◼️

Отам десь були шкали, так, ідеальні. Somewhere there were some scales.

Тепер для цього випадку є інша шкала, у цей раз неідеальна:

There is for this case another scale at this time, not ideal one:


      less period of time; more efficacy; менший проміжок часу; більше ефікасі <-------------------> вейстін тайм, wasting time

І такє вже щонаймеш триває як мінімум декілька років. По селящянські для вас. Але це не трівіа. Гра така.

це кодовий протекціонізм. 😉

Maybe it is a case, a phenomenon of a code protectionism. 😉

тоді це оновлення про кодовий антипротекціонізм.

Maybe this update is about a case, a phenomenon of a code antiprotectionism.

Хтось розцінив це як критику. Так, можливо. Але це ні, не критика, заперечу: це спостереження, факти, аналізи і фантастично.

А от за робусту і арабіку, дякс, тим людям що піклувалися про них і зібрали, якщо власноруч, і за обробку, і за доставку і всім у цій ціпці окрім можливо подібного типу посередників як вищезгадував і тут ще десь. Або додатково тим людям за автоматичних працівників чи за автоматичних працівниць, що аугументували їх(ті процеси). Коли майже засинаєш, як ото ота снігова королева, ні ні, як спляча гарнюка, робуста і арабіка спішать до допомоги як кажуть. Але ще як кажуть, це не корисно для напруги.

The update as of 2021-01-17.

Оновлення від 2021-01-17.

Для подібного конпоненталя для копіювання електронної послуги я згадав одразу лєго Lego, ХЕйТОАС HATEOAS. Проте сервіси послуги не схожі на блок лєго Lego.

Ще це нагадало історію про перевантаження пост ярмаркових площ з товарами речей продуктів. Там є мабуть дві системи: вантажівкова і пост ярмарково площинна. І умовно третя для переміщення цих товарів речей продуктів.

І ту історію де всередині пост ярмаркових площах автоматичні працівники чи автоматичні працівниці переміщають ці товари продукти речі.

Так само і електронний сервіс і електронна послуга має дані і методи і спілкування.

Якщо ХЕйТОАС HATEOAS більше для спілкування і навігації між становищами послуги сервіса, то для копіювання електронної послуги треба копіювати не лише дані і наступні методи.

Тож це копіювання дерево подібної структури, ієрархічної структури, як файли(документи) і папки, і які наприклаж теж підтримуються форматами ДжейСОН JSON, ІксЕмЕль XML.

Але в ньому змінні параметри аргументи мають бути якось позначеними, на відміну від назв файлів і папок.

Тож в експортній частині для копіювання сервіса послуги яка генерує подібну структуру це нагадує файл з купою пов'язаних зразків файлів зразків ХЕйТОАС HATEOAS зі своїми деякими особливостями.


{service_name_sample_28473876584: {
        move: {
            from: "variablestartvariableend",
            to: "variablestartvariableend",
            result: {
                message: {"variablestartvariableend"},
                error: {"variablestartvariableend"},
                next_actions: "unmove, remove, measure_available_power, recharge_power",
                next_actions_as_a_collection: ["unmove", "remove", "measure_available_power", "recharge_power"],
                next_actions_as_another_collection: {
                    "unmove":{}, 
                    "remove":{},
                    "measure_available_power":{},
                    "recharge_power"{}
                }
            }
        },
        unmove: {
            from: "variablestartvariableend",
            to: "variablestartvariableend",
            result: {
                message: {"variablestartvariableend"},
                error: {"variablestartvariableend"},
                next_actions: "move, remove, measure_available_power, recharge_power",
                next_actions_as_a_collection: ["move", "remove", "measure_available_power", "recharge_power"],
                next_actions_as_another_collection: {
                    "move":{},
                    "remove":{},
                    "measure_available_power":{},
                    "recharge_power":{}
                }
            }
        },
        remove: {
            from: "variablestartvariableend",
            to: "variablestartvariableend",
            result: {
                message: {"variablestartvariableend"},
                error: {"variablestartvariableend"},
                next_actions: "unmove, move, measure_available_power, recharge_power",
                next_actions_as_a_collection: ["unmove", "move", "measure_available_power", "recharge_power"],
                next_actions_as_another_collection: {
                    "unmove":{},
                    "move":{},
                    "measure_available_power":{},
                    "recharge_power":{}
                }
            }
        },
        measure_available_power: {
            result: {
                message: {"variablestartvariableend"},
                error: {"variablestartvariableend"},
                next_actions: "unmove, move, remove, recharge_power",
                next_actions_as_a_collection: ["unmove", "move", "remove", "recharge_power"],
                next_actions_as_another_collection: {
                    "unmove":{},
                    "move":{},
                    "remove":{},
                    "recharge_power":{}
                }
            }
        },
        recharge_power: {
            to: "variablestartvariableend",
            result: {
                message: {"variablestartvariableend"},
                error: {"variablestartvariableend"},
                next_actions: "unmove, move, remove, measure_available_power",
                next_actions_as_a_collection: ["unmove", "move", "remove", "measure_available_power"],
                next_actions_as_another_collection: {
                    "unmove":{},
                    "move":{},
                    "remove":{},
                    "measure_available_power":{}
                }
            }
        },
        locate: {
            to: "variablestartvariableend",
            result: {
                at: {"variablestartvariableend"},
                at_x: {"variablestartvariableend"},
                at_y: {"variablestartvariableend"},
                message: {"variablestartvariableend"},
                error: {"variablestartvariableend"},
                next_actions: "measure_available_power, recharge_power",
                next_actions_as_a_collection: ["measure_available_power", "recharge_power"],
                next_actions_as_another_collection: {
                    "measure_available_power":{},
                    "recharge_power":{}
                }
            }
        }
    }
}

Оновлення від 2021-01-17.

Тож для якогось ресурса в інтернет мережі, де реп'яшок необхідний, як реп'яшкувати запит, який позначив, що він не реп'яшкуємий: відхилити його, чи повторно запитати, що можливо він сам себе якось позначить реп'яшком(ще раз повторним запитом) чи інакше(але ресурс можливо не підтримує цей інший нереп'яшковий позначник). Мабуть і mdN+Ndm без реп'яшкування можливий для цього для самого запита, але ж запит може бути надісланий з точки n+1, а підписаний як з n+2, тоді 2 два запита з однаковим вмістом з n+1 і з n+2 підписаного як з n+1 отримають той самий результат для mdN+Ndm. Але якщо таких запитів багато, тоді мабуть перед цим можливий якийсь обмін підтримуваними позначниками за допомогою якогось позначникового інтерфейса обміна.

The update as of 2021-02-09.

Оновлення від 2021-02-09.

Unsubscription from spam calls and messages as a service.

Відписка від спам викликів і повідомлень як веб сервіс чи як веб послуга.

The start of update as of 2021-12-05.

Початок оновлення від 2021-12-05.

Деякі послуги нагадують про себе у кампаніях повідомленнями, з огляду на попереднє про Відписка від спам викликів і повідомлень як сервіс послуга це краще ніж відсутність такої взагалі. Для послуги це не лише мабуть взаємодія а ще й утримання користувача чи користувачки. Але якщо я не користувався послугою і не слідкував за переліком послуг також ймовірно що така послуга більше не цікава. Де-не-де а також у деяких групах послуг існують повідомлення накшталт Ви не користувалися послугою НН діб, ви хотіли б видалити чи, як варіація, Ви не користувалися послугою НН діб, ви будете видалені через НН діб. Але що у кожному окремому випадку для послуги краще покращити послугу чи утримати клієнта чи клієнтку: я не знаю. Більш досвідчені точно на цю тему про це мої деякі попередні колеги й мої деякі попередні колежанки. Я їх не рекламуватиму тут, хоча це теж мабуть є зразком деякого типа реклами, як на зразок weak reference у деяких мовах програмування, тоді я їх тут не рекламуватиму у якийсь не weak reference спосіб.

Кінець оновлення від 2021-12-05.

The start of update as of 2021-12-05.

Оновлення від 2021-02-10.

Знайшов коментар про опис пристроїв і також була технологія яка надає підключення між пристроями десь біля 15 років тому. Веб місце з копією такого способа якщо має веб адресу іншого такого місця якоюсь кінцевою точкою може отримати тоукєн чи реп'яшок чи щось подібне, зареєструватись і додати запис і отримати мапу того веб місця чи подібну іншу деревоподібну структуру. Навіть дві.

Але здається подібна кінцева точка чи інший обмін у протоколі досі має бути зазделегідь розподіленими для цього.

Щось у схожому стилі https://uk.wikipedia.org/wiki/Plug_and_play для тих веб місць або https://en.wikipedia.org/wiki/Autoconfigure для тих веб місць.

The update as of 2021-02-22.

Оновлення від 2021-02-22.

Customizable limit per incoming messages per time period with a possibility to show or not as a service.

Налаштовуємий ліміт;обмеження для вхідних повідомлень протягом проміжку часу з можливістю показати чи ні як сервіс;послуга.

The update as of 2021-02-26.

Оновлення від 2021-02-26.


    class Result{/**/}
    class FormulaResult extends Result{/**/}
    class FormulaEmptyResult extends FormulaResult{/**/}
    class FormulaTimeoutResult extends FormulaResult{/**/}
    class ResultFactory<FormulaResult> extends Factory{/**/}
    class FormulaResultConsumer<FormulaResult> {/**/}//java.util.function.Function.//andThen.java.util.function.Function.//andThen.

The update as of 2021-03-09.

Оновлення від 2021-03-09.

I did not find a ping tool in some email client through some service the subscriptions on a link and accounts on a link and their details after corresponding allowance or otherwise, so that the other option is to track them manually.

I did not find a ping tool in some service the bank cards on a link after corresponding allowance or otherwise, so that the other option is to track them manually.

It seems to be a case for manual tracing for those data.

Я не знайшов інструмента запита у якомусь поштовому клієнті за допомогою якогось сервісу послуги підписок на прив'язці і рахунків на прив'язці і їх деталів після відповідного дозволу чи чогось, так що іншою можливістю є слідкувати за ними вручну.

Я не знайшов інструмента запита у якомусь сервісі послузі банківських карт на прив'язці і їх деталів після відповідного дозволу чи чогось, так що іншою можливістю є слідкувати за ними вручну.

Здається це є випадком ручного відстеження для тих даних.

Оновлення від 2021-03-24.


    аналіз -->   компуліз,обробуліз числами,обчислюліз
       /\            |
        |____________|
       зворотнє розповсюдження

Оновлення від 2021-05-20.

The update as of 2021-05-20.

As Pravin Tarte typed "Why not control the implementation during code-review?" "Well technically you can, but in that case, the reviewer becomes the bottleneck in the whole SDLC process." So he actually later introduced ArchUnit and some examples for automation of some review practices. I personally never ever appeared in any review bottleneck in the whole SDLC process or in any review suspension in the whole SDLC process.

In order to update the following text from somewhere above at this web page:

• Review plus test is much cheaper than just test

into

• Review plus test with ArchUnit is much cheaper than just review plus test

with a stuck in the dark ages, or not.

Як Правін Тарте Pravin Tarte надрукував "Why not control the implementation during code-review?" "Well technically you can, but in that case, the reviewer becomes the bottleneck in the whole SDLC process." Так що він представив пізніше ArchUnit і деякі приклади для автоматизації деяких перегляду практик. Я особисто ніколи ніколи опинявся у будь-якій переглядовій зупинці в цілому ЕсДіЕлСі SDLC процесі чи у будь-якому переглядовому призупиненні в цілому ЕсДіЕлСі SDLC процесі.

Для того щоб оновити наступний текст звідкіля вище цією сторінкою у веб:

• Перегляд та тест є набагато дешевше ніж лише тест

до

• Перегляд та тест з АрхЮніт ArchUnit є набагато дешевше ніж лише перегляд та тест

з застряганням в темних часах чи ні.

Оновлення від 2021-05-29.

The update as of 2021-05-29.

Another one for ArchUnit.

I have brought the same code into 2 audits, got 2 different results. Probably according to the review guidelines there.

Automating and distributing those review rules into the tools similar to ArchUnit would probably keep a pineapple a day.

No wondering whether the similar approach could be applicable to the recently gaining popularity security code reviews or audits.

Ще одне про АрхЮніт ArchUnit.

Я заніс той самий код до двох аудитів, отримав 2 різних результата. Ймовірно згідно рядків перегляду й не лише кода там.

Аутоматизуючи і розповсюджуючи ті правила перегляду й не лише кода в інструменти схожі з АрхЮніт ArchUnit зберігло би можливо ананасу добу.

Не блукаючи міг би схожий спосіб бути застосованим до нещодавно набираючим моду перегляду й не лише коду щодо безпеки чи аудитів.

What is more. Probably there is a well-known story about NPE somewhere. I tried to avoid it according to different manifesto, however when some IDE has a mode, in which its null core is in avoidance, probably keeps not only a pineapple a day. Or plugin.

Ба більше. Ймовірно існує відома історія десь про НВВ NPE. Я намагався уникати його згідно різних маніфестів, однак коли якась іДеЄ IDE має режим, у якому глибинне в НВВ NPE є в униканні, ймовірно це зберігає не лише ананасу добу. Або плагін.

Що вже й казати про ситуації вилізання за межі мовою програмування. Або бібліотекою кода.

However the flexibility of programming language is untouchable without using those ones. And null core is still there as well whatever some pineaple might say, if it could, taking into whether it is a dark skin pineapple or a skinless one.

Однак гнучкість мови програмування є недоторканна без використання тих. І глибинне в НВВ NPE є теж досі там щоби ананас і казав, якби міг, зважаючи навіть щодо того чи це темношкірковий ананас чи безшкірковий.

Оновлення від 2021-05-30.

The update as of 2021-05-30.

I have found another article today in RSS about ArchUnit where there is a mention of an ArchUnit as an alternative one and it also has a lot of instructions about how to apply regress to success strategy in not so obvious and evident cases in several projects.

Знайшов сьогодні ще одну статтю у RSS стрічці про АрхЮніт ArchUnit де є згадка про альтернативу АрхЮніта ArchUnit і вона також має багато інструкцій про те як застосовувати план повернення до успіху у не так виразно наявних і не лише випадках у декількох проектах.

Оновлення від 2021-06-04.

The update as of 2021-06-04.

Another method of finding about how java-dependent the code is, is to take the burden and to extend each class from AnotherObject which is extending Object клас and implementing the Object interface.

Іншим засобом визначення наскільки джава java-залежним є код, є прийняти тягар і розширити кожен клас від ІншогоОб'єкта, який розширює клас Об'єкт і виконує виразно інтерфес Об'єкта.

In java independent code except its syntax both classes are not necessary. But when using framework, there will be classes in which it is not possible to do that because of design as an advantage in this approach. That one is the clear marker that such classes are not only java dependent but also framework dependent.

В java джава незалежному коді за виключенням його синтаксу обидва класи є непотрібними. Але коли використовуючи фреймворковий програмний каркас, там будуть класи в яких неможливо зробити те з за дизайну у цьому способі як перевага. Те є чистою позначкою що такі класи є не лише джава залежними але і фреймворково програмно каркасово залежними.

The more such classes the less portable is the code even with the syntax dependency.

Чим більше подібних класів тим менш портабельним переміщаємим в інший є код навіть з синтаксом як залежністю.

I guess it can apply to other programming language with inheritance unless the specific implementation peculiarities.

Гадаю це застосовуємо і до інших мов програмування з класовою належністю якщо не специфічні реалізаційні особливості.

Ah, and another such class AnotherInterface for interface layer.

Ох, і інший же ще подібний такий клас для шара інтерфейсу.

The existence of such extraction of layer of interface with java independent code, still in java even with exception of syntax, inside a code framework may cause to creation of so called code "framework standard" or code framework interface, which links the existing code frameworks on a code level. Taking into account that accidental finding in some previous story in these pages here with security versions of functionality for code frameworks. Otherwise code framework vendor lock is pretty hard overcomeable after adopting of some code framework the more time it pass after choice at design stage. And that one probably leads to that of what with API situation currently recently found also accidentally in some description in some of these web pages. But at the code level some framework already have modules and other elements, where some of them even contain the security. It is pretty arguable that the framework does not have a framework functional interface. Maybe even a pretty big one in its scope. Because for example previously there were no tech.clouds and there were no such module there in some code frameworks. Because I do not want to migrate to another framework, just to stuck in vendor lock there later with no approach to migrate back, similar like already I do not want to just migrate to another JPA implementation to stuck there BUT AND I want an easy migration, which is an inherent advantage of JPA as used in many projects. While that, still they are having a place and famous implementations for implentations specifics. While I am familiar only with one as that garçon uncovered only one occurence among such ones. And it is clear that probably there are more with the appropriate reasons for them. But still migration is pretty easy among JPA implementations even the more time it pass after choice at design stage unlike the code framework migrations.

JFrA, JFA or alike.

Існування подібного видобутку шару інтерфейсів з джава java незалежним кодом, й у джава навіть з виключенням щодо синтаксу, всередині кодового фреймворкового програмного каркасу може викликати створення так званого кодового "фреймворкового стандарту" чи кодового фреймворкового інтерфейсу, який з'єднує існує кодові фреймворкові програмні каркаси кодовим рівнем. Беручи до рахунку ту випадкову знахідку в деякій попередньому оновленні в цих сторінках тут з безпековими версіями функціоналу для кодових фреймворкових програмних каркасів. В іншому випадку кодово фреймворково програмно каркасне замкнення виробника є достатньо складно обхідним після устаткування деякого кодового фреймворкового програмного каркасу чим більший проміжок часу минає після цього вибору на етапі дизайну. І те мабуть призводить до того що з ППІ ситуацією поточно нещодавно знайдено також випадково у якомусь описі у якійсь з цих сторінок в інтернет. Але кодовим рівнем якийсь фреймворковий програмний каркас вже має модулі і інші елементи, де якісь з них навіть налічують безпекові. Це є достатньо суперечливим що кодовий програмний фреймворковий каркас не має кодово фреймворково програмно функціонального інтерфейсу. Можливо навіть достатньо великого у своїх межах. Тому що наприклад попередньо не було тех.хмар і не було подібного модуля в деяких кодових фреймворкових прогамних каркасах. Тому що я не буду мігрувати до іншого фреймворкового програмного каркаса в поточний якісний але непрозорий імплементаційно детальний а не кодовий засіб між наприклад двома існуючими фреймворковими програмними каркасами, просто щоб застрягнути у замкненні виробника там без прозорого засоба мігрувати назад, схожого як з вже я не буду просто мігрувати до іншого ДжПіЕй JPA імплементації щоб застрягнути там АЛЕ І я буду легко мігрувати, що є притаманною перевагою самого ДжПіЕй JPA який використовується в багатьох проектах. Поки це, досі вони а саме ці імплементації тобто виконання мають відоме місце і мають відомі імплементації тобто виконання для імплементаційних виконань специфік уточнень. Поки мені відома лише одна як той гарсон розповів лише про один випадок серед подібних. І це є прозоро що імовірно існує більше з доречними причинами для них. Але досі однак ці міграції переходи є достатньо легкими серед ДжПіЕй JPA імплементацій виконань навіть чим більший проміжок часу минає після цього вибору на етапі дизайну що не є схожим зараз з для міграцій переходів між кодовими фреймворковими програмними каркасами.

ДжФрА JFrA, ДжФА JFA чи щось.

З для це помилка. Мені це відомо. Дякую.

Whether there is no sharable common framework annotations or sharable common code element, code artifact, code library or elsewise but it is not easy now to mirgrate after their adoption among security implementations of for example spring security and apache shiro security in java scope.

Або чи не існує поділяємих спільних фреймворково програмно каркасових анотацій чи не існує поділяємих спільних колдового елементу, кодового артефакту, кодової бібліотекі проте це не є легко зараз мігрувати після їх устаткування серед безпекових імплементацій виконань наприклад спрінг spring секьюріті security та апаче apache широ shiro секьюріті security у межах джава java.

For example for similar auth, login, logout, their handlers and so on.

Наприклад для схожих аусов, входов, їх обробників і тому подібних.

I did not compare how easy those code migration are for for example quarkus, for MicroProfile framework items and for other profile items.

Я не перевіряв порівнянням наскільки легкими ті кодові міграції переміщення є чи не є для наприклад кваркуса quarkus, для мікропрофльних MicroProfile фреймворково програмно каркасових одиниць і інших профільних одиниць.

Оновлення від 2021-06-05.

The update as of 2021-06-05.


    groupid:filenameid -> groupid:projectid:filenameid

//for example

    ideasmatter.techawesomeness.data:file1.txt->ideasmatter.techawesomeness:data:file1.txt
    ideasmatter.techawesomeness.security:file2.txt->ideasmatter.techawesomeness:security:file2.txt

//for example

    ..
    ├─ ideasmatter.techawesomeness.data:file1.txt
    |  └─ ideasmatter.techawesomeness.security:file2.txt
    ..
-> --projectful --groupful --filenameful
    ..
    ├─ ideasmatter.techawesomeness
    |  └─ideasmatter.techawesomeness:data:file1.txt
    |    └─ ideasmatter.techawesomeness:security:file2.txt
    ..

Оновлення від 2021-06-27.

The update as of 2021-06-27.

Відсутність оціночного фреймворкового програмного каркаса веде до нема очп в ідеальному варіанті.

Якщо я роблю очп випадково, тоді я виконую роль оціночного фреймворкового програмного каркаса. Чим більше я потребую робити це все, тим більшим оціночним фреймворковим програмним каркасом я є.

The absence of EstimationFramework leads to EstimationNullPointerException in an ideal case.

If I am doing the estimation randomly, then I am performing the role of an estimation framework. The more I need to do it all, the bigger the estimation framework I am.

Оновлення від 2021-07-13.

The update as of 2021-07-13.

">mdnplusndm

Оновлення від 2022-01-15.

The update as of 2022-01-15.

">mdnplusndm version 2

">mdnplusndm version 3 with representations of informational bubble and informational virus

">mdnplusndm version 4 with representations of informational web

Кінець оновлення від 2022-01-15.

The update as of 2022-01-15.

Оновлення від 2022-01-17.

The update as of 2022-01-17.

Якщо застосувати ту четверту версію того виображення замінивши mdN+Ndm версіями якогось одного компіляційного складача для розповсюдження то це ще раз покаже деяку різноманітність у системі координат зворотня сумісність <--------> одночасні оновлення одного постачальника такого компіляційного складача у використанні різними продуктами кінцево. Те співпадіння випадкове. Що більше так це те що той об'єкт перед виображеннями інших не лише зачиняємий і відчиняємий якщо один чи не один так і рухомий або навпаки.

If to apply that fourth version of that representation by substituting mdN+Ndm into versions of some one compiler for distribution then it once more will show some diversity in those axes of backward compatibility <--------> simultaneous updates of one provider of such compiler in use by different products as a result. Where somewhere there is a version of 2007-07-18 in use in one product while in parallel there is a version of 2021-07-28 in use in another product in scope of the same compiler provider. That coincidence is random. What is more is that that object before representations of products is not only openable and closable if there is such one if there are more such ones but it is also moveable or otherwise round.

Кінець оновлення від 2022-01-17.

The update as of 2022-01-17.

Оновлення від 2021-07-19.

The update as of 2021-07-19.

У об'єктному факторійному методі як в одному з моделів проектування, він не банить, блокує чи забороняє ново як ключове слово у деякому відношенні схожого з строго як ключовим словом для одного з режимів в джаваскріпт javascript, він капсулює і ховає його всередині і надає додатковий методо підписовий зразок. Аєчігіраут.

In factory method as in one of design patterns, it does not ban, block or prohibit new as the keyword in some extent similar to strict as keyword in javascript as a mode it encapsulates and hides that one inside and provides additional method signature sample.

Оновлення від 2021-07-25.

The update as of 2021-07-25.


    кластерна назва чи проектна назва по тег позначковій назві чи по описовій тоукєновій одиничній назві
        кодова сховищна назва; ✅12; ⛔️11; по випуску версії З.З.З.
        інша кодова сховищна назва; ✅1; по випуску версії З.З.З.
        ...

    cluster name or project name by tag name or by description token name
        code repository name; ✅12; ⛔️11; per release version Z.Z.Z.
        another code repository name; ✅1; per release version Z.Z.Z.
        ...

Оновлення від 2021-07-27.

The update as of 2021-07-27.


                                                        перевірка доступності                       взаємозамінність;         longevity;тривалість                                                            чи зразок видаляємий чи змінюємий користувацьки; додано 2021-08-20      автоматичне продовження після закінчення попередньої активної тривалості за преференцією користувацьки; додано 2021-10-15      specific to; специфічно до;додано 2021-11-22
                                                        availability check                          interchangeability
                                                        Оновлення від 2021-08-03.
                                                        The update as of 2021-08-03.
type;тип

реп'яшок;cookie                                         mostly browser;переважно браузер            так *                     налаштувуєме;configurable                                                       так; додано 2021-08-20                                                      є можливість; додано 2021-10-15                                                                                                    browser feature and data; особливості ППіНТВСуІ і даних;додано 2021-11-22
тоукєн;token                                            налаштувуєме;configurable                   так *                     налаштувуєме;configurable                                                       так; додано 2021-08-20                                                      є можливість; додано 2021-10-15                                                                                                    data and implementation feature; даних і особливості виконання;додано 2021-11-22
    обфускуючі і двійково обфускуючі
     як наприклад за допомогою
      залежності Google ProtoBuf
      в цій табличці у межах тоукєнів як такі,
      якими можливо створити дуже великі тоукєни,
      однак їх і застосовують
      до типово невеликих тоукєнів
             * API Keys; PATs; ППІ тоукєни;
             додано 2022-02-22
    адже усі ці зразки
    реп'яшків, тоукєнів, самопідписаних БРШ підписок,
    БРШ підписок
    можливо є
    визначниками; але на початку створення 
    цієї таблички припускалося що усі вони
    переважно централізовані але 
    з доданням 
    децентралізованої моделі для SSI як то
    https://commons.wikimedia.org/wiki/File:(20201118)(Piloting_with_EBSI_Webinar_2_Roadmap_Your_Pilot)(v1.01)-23.png
    то 
     децентралізовані тоукєни
      DID
       тому що вони можуть бути перевірені
       за допомогою blockchain як Dapp способом
       але ймовірно не лише ним
       тому що якщо застосувати до 
       попередньої моделі 
       як до формули то принаймні
       можливі як дві змінні до самої моделі 
       принаймні у джава
       java стилі підтипи DID та постачальник
       їх перевіряння.
       додано 2022-04-22
self signed SSL certificate;самопідписана               mostly browser;переважно браузер            так *                     налаштувуєме;configurable                                                       ні; додано 2021-08-20                                                       є 1 полуавтоматичне рішення у 1 постачальника; додано 2021-10-15                                                                  лише протоколу неперемикаємого;non triggerable protocol;додано 2021-11-22
БРШ підписка
CA  SSL certificate; СА                                 mostly from browser;переважно з браузера    так *                     30 діб чи 90 діб чи ~365 діб переважно;mostly 30 days or 90 days or ~365 days   ні; додано 2021-08-20                                                       невідомо; не знаходив; знаходив лише за потребою або як в on demand без автоматичного продовження; додано 2021-10-15              лише протоколу неперемикаємого;non triggerable protocol;додано 2021-11-22
БРШ підписка

Початок оновлення від 2021-11-05.

The start of update as of 2021-11-05.

* лише як рівня виконання;as only implementation specific. often once selected and on. одного разу обране й подальші зміни вимагають достатньо змінної й іноді немалої кількості наступних змін але залежно від багатьох факторів. але в деяких системах є в наявності якісь імпорти та експорти для них. in few systems there are imports and exports for those ones.

Probably that is mostly because of they are not similar to API for such other type of interchangeability. Ймовірно це з за того що вони не ППІ подібні для такого іншого типу взаємозамінності.

Кінець оновлення від 2021-11-05.

The end of update as of 2021-11-05.

Початок оновлення від 2021-11-22.

The start of update as of 2021-11-22.

Як кажуть в рефактòринзі, відтепер можливо екстрагувáти наступний клас в якому буде тип.


    клас зЯкоюсьНевідомоюНазвоюНаприклад89458954894589458945 {
        Рядок тип;
        Рядок перевіркаДоступності;
        Рядок взаємозамінність;
        Рядок тривалість;
        Рядок чиЗразокВидаляємийЧиЗмінюємийКористувацьки;
        Рядок автоматичнеПродовженняПісляЗакінченняПопередньоїАктивноїТривалостіЗаПреференцієюКористувацьки;
        Рядок специфічноДо;
    }

    class withSomeUnknownNameForExample89458954894589458945 {
        String type;
        String availabilityCheck;
        String interchangeability;
        String longevity;
        String чиЗразокВидаляємийЧиЗмінюємийКористувацькиЩоНеперекладено;
        String автоматичнеПродовженняПісляЗакінченняПопередньоїАктивноїТривалостіЗаПреференцієюКористувацькиЩоНеперекладено;
        String especificTo;
    }

Кінець оновлення від 2021-11-22.

The end of update as of 2021-11-22.

Оновлення від 2021-10-25.

The update as of 2021-10-25.

Адже сумісність між ПЗ може бути не лише оголошена, потім потрібна до вивчення й потім виконана, а ще й може бути перевірена, існує щонайменш 2 типа ПЗ, один з них як описаний, а інший як перевіряємий, тобто якісь особливості оголошуються і потім перевіряються, навіть у клієнтах і навіть у серверах оброблячах з клієнтами як клієнтах.

As long as compatibility can be not only announced, then need to know, then implemented, and also it can be verified, there is at least 2 types of software, one of which as described, and another one as verifiable, therefore some features are announced and then verified, even in clients, and even in servers with clients as clients.

Можливо найбільшим наслідком від цього і для цього є більшістю ППіНТВСуІ.

Така можливість можливо реалізується рівнем ПЗ, чи то додатки й застосунки чи то розширення й плагіни, але ППіНТВСуІ не мають ППІ чи іншої особливості яке б полегшувало це їх розробникам і розробницям, а значить така можливість можливо буде повторюватися і перевиконуватися в такому способі в кожному сервері оброблячі або в кожному клієнті по різному раз за разом що є щонайменш неефективним.

Чи вони так звано тонкі чи жирні.

Така особливість відсутня і в ОСІ OSI моделі але там є принаймні обмін контентом чи обмін вміста. Тож обмін підтримуваними особливостями може бути як назва для цього ділення.

Maybe the biggest consequtive effect from this are having the most web browsers.

Such feature can be implemented at the software level, whether it is web sites and applications or extenstions and plugins, but the most web browsers do not have API or other feature which easens it for such developers, therefore such feature probably will be repeated and reimplemented in such a way in each server or in each client differently time after time which is at least ineffective.

Whether they are so called thin or fat ones.

Such feature is absent and in OSI model but there is at least content negotiation there. So the feature negotiation can be as a name for such division.

Оновлення від 2021-10-29.

The update as of 2021-10-29.

Адже якщо деяке ПЗ може змінюватися особливо одного з типів без запиту користувача чи користувачки чи без іншого попереднього налаштування і особливо таке як неперевіряєме ПЗ, то таке ПЗ має бути позначено як чи Ɵ чи їх варіаціями чи іншими або й додатково чи навпаки мати в наявності якийсь дуже короткий текстовий опис про це для користувачів і користувачок перед його використанням з різних причин.

As long as if some software can be changed especially of one of the types without the user request or without other preconfiguration and especially such as not verifiable one, then such software must have a mark within by or Ɵ or their variations or by other ones or and additionally or vice versa must have some very short textual notification about it for users before its usage because of several reasons.

Оновлення ПЗ з такої перспективи є залежністю самого ПЗ але не повсякчас і водночас є міжз'єднання для обох типів і для різних версій як відкрито кодових так і інших але не в усіх процесах розробки.

Software update from such perspertive is a dependency of software itself but not always and at the same time is an interlink for both types and for different versions such as open source and others but not in all development processes.

Це пов'язано з сумісністю, від якої і яку не кожен ПЗ продукт залежить від чи включає, але загалом вирогідно виділилися її типи й там. Існує часткова та повна.

Прикладів багато для часткової останнім часом, але переважно це коли версія продукта або версія послуги підтримує частку версій у своїх подальших продуктах або послугах.

It is cohesive with compatibility, which not every product depends on or includes, but overall seems there are types there. There are partial and full ones.

There are many examples for partial one recently, but mainly it is when a version of a software product and or version of service supports a partiality of versions in their further products and or services.

Оновлення від 2021-12-22.

The update as of 2021-12-22.

Якщо перемикачева система має можливість перемістити підпис метода до так званого чорного переліку як інший тип застарівання, не внутрішній, а зовнішній у цьому випадку, який майже не розповсюджений як внутрішній, наприклад для того, щоб отримати можливість перевірити як додаток чи застосунок з використанням такого метода буде виконуватися з подібним методом у так званому чорному переліці наприклад щоби унукнути оновлення щодо release notes і подібних а замість цього мати можливість одразу це перевірити, або для видалення дії якогось інформаційного віруса. Але у наступній версії такий додаток чи застосунок чи інформаційний вірус можливо змінить цей підпис після якогось впливу бо він має таку властивість, тож у такому випадку це нагадає якусь іншу версію ПерегонногоУмовногоСімулятора.

Оновлення від 2021-12-25.

The update as of 2021-12-25.

Так що ви вже можливо знаєте про що ці сторінки у веб й вони вже нудні. Так само і з ППіНТВСуІ. У деяких ППіНТВСуІ панель веб адреси чи рядок веб адреси тобто УРР приховуємі чи інший подібний елемент а у деяких ні. Це тому що існують інтернет веб адрес і інтернет посилань. Тому що можливо користуватися такою ППіНТВСуІ і без подібного такого елементу тоді однак потрібно якась вхідна точка для входу чи сайт для входу чи щось подібне. Однак у джава програми завжди є точка для входу однак вона не обов'язково має веб адресу. Адже кожна наступна джава програма може бути створена як минуломережева за деяких обставин і може бути як міжмережева і минуло міжмережева і позаміжмережева це дає можливість кожній такій програмі отримати для цього відповідні значки.

Оновлення від 2022-02-18.

The update as of 2022-02-18.

Якщо використовувати способом як у цих публікаціях https://stackoverflow.com/questions/28065158/java-bigdecimal-and-double-nan то це як раз до цієї веб сторінки. Тому що якщо використовувати "спеціальні" значення то це призведе до дублікатів розширення як у прикладі з MyNumber у різних подібних проектах і до чогось як про деякі рядки тут. Навіть якщо не розширювати без тих трьох статичних сталих які присутні у https://docs.oracle.com/javase/8/docs/api/java/lang/Double.html це виконати за допомогою одного null неможливо а при повторенні не лише до несхожих але все ж таки до дублікатів у різних кодах проектів що схоже з як у оновленні від 2022-02-16. Згідно інших трьох відповідей NaN не число і згідно документації теж але щодо Double це як виключення або не стосується що не вказано але присутньо там і зручно у використанні тобто convenient згідно розповсюдженого використання у інших проектах. Тож тоді це як раз до цієї. Тож вцілому відсутність оновлення тих класів тому рівнем з якого це могло б використовуватися іншими кодами інших проектів як раз і до таких публікацій як у https://stackoverflow.com/questions/28065158/java-bigdecimal-and-double-nan. Це нагадує спосіб DIY який можливо ще й WET у таких випадках що і до як раз таких як ця веб сторінка. Тобто якщо би було переміщення трьох статичних сталих до рівня вище до Number то це би оновлення і ті відповіді і те питання були би вичерпані але при застосуванні такої версії тоді би компіляційно не склалися багато попередніх кодів проектів що не є крізьплатформенно. Але якщо не переміщенням а копіювати трьох статичних сталих до рівня вище до Number то це би оновлення і ті відповіді і те питання були би теж вичерпані але при застосуванні такої версії тоді би компіляційно не склалися стільки ж чи більше чи менше попередніх кодів проектів що не є крізьплатформенно. І теж якщо платформою вважати якусь специфічну окрему її версію. Динамічна типізація часу виконання і рефлексія як особливості зводять на нівець такі припущення. Більше того це створило би дублікат у самому такому проекті, але який там легко заміщується @Deprecated з позначкою до подальшого вилучення що є як POLA крізь кілька версій платформи чи через декілька платформ якщо платформою вважати якусь специфічну окрему її версію. Тобто хоча він а саме такий дізрапшн тобто disruption і викликає гаряче незадоволення але вони влучно запобігають стагнації у таких випадках при невідомій кількості застосувань динамічної типізації часу виконання і рефлексії особливо у закритокодових проектах. Особливо якщо платформою вважати якусь специфічну окрему її версію а файли збірок з вказаними попередніми версіями платформи такий дізрапшн не чіпає. Як і було протягом наприклад додання --add-opens. Але це також має і стосунок з наприклад двома моделями сховища для сховищ кодів проектів тобто репозиторіїв тобто котрі є для подальших залежностей у тих проектах. Одною є як наприклад у Central Maven Repository, майже незмінний тобто almost immutable, але майже тому що присутній фактор переконання тобто convincing factor принаймні протягом фіксів чи владнань тих даних. А іншою є як наприклад у JCenter тобто змінна тобто mutable. Подібна змінна модель такого сховища для сховищ кодів є присутньою принаймні і у npm та node.js екосистемі. Перевагою майже незмінної є те що попередні збірки проектів дуже ймовірно компіляційно складуться. Але адже це віддалене сховище такі попередні збірки проектів також і складуться якщо ті сховища кодів проектів тобто репозиторіїв а можливо і дістріб'ютіексчейнджі тобто котрі є для подальших залежностей у тих проектах були копійовані до локального сховища. Тобто це можливо навіть забезпечено таким способом двічі у моделі майже незмінних таких сховищ.

Оновлення від 2022-02-20.

The update as of 2022-02-20.

Eventhough this update is a piece of text, but with software it is much complex. For example in some previous versions of software, no matter awesome it is, there are possible other software dependencies, which if are not in an update cycle as well, then leaving vulnerabilities where such ones were published. The complex part in them is because some software are not in rolling updates cycle or alike to it for example it is inside waterfall model, but so it has an EOL and similar ones inside them if had such announcements //because in alternativeto.net there is an approach to announce //about EOL and alike; at least so found for some open source software //including with some previous data of update for such some software //but it is unknown whether it is announced or there is for that approach //it is via code or via other approach thus leaving an option to continue use such software with found vulnerabilities after it exprired or that such expiration date passed or to update it if available. This update is rephrasable by following a situation in these several links: https://mvnrepository.com/artifact/org.apache.shiro/shiro-core, https://mvnrepository.com/artifact/org.apache.shiro/shiro-core/1.1.0, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23305, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23302, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104 . Till now I did not find an approach to mitigate but there is a widespread suggestion to get rid of such dependencies in such software in multiple web resources, which is WET and not DRY particularly for open source software. That is while there is an already known existence of code in files along with others which is already open source there is no need to rewrite it from scratch instead of other approaches during other absence of other arguments towards that one. But this one is also overlapping with their software licenses and feature prepearing for next following software with them where such dependencies are used but that one is probably as another item to that table in changes of dependencies for such following software. In such a situation it is pretty difficultly acceleratable in some existing as contrary to for some other software from scratch with no dependencies yet because of such intertwining of those mentioned items even taken that such existing software is not unknown. Because the speed of sequences of updates for such situation is hardly applicable because similar vulnerabilities appeared in unknown moment of time after which necesarily there is a cycle of update of such software which for each software is its own one from waterfall to scrum and others. And only after which already there is application of such software after updates for other software or as a distributeeexchangee till as applications for end users. But this update is particularly what is for this situation during application of such software after updates for other software in that period of time.

Хоча і це оновлення є текстовим, але з ПЗ це складніше. Наприклад у деяких попередніх версіях ПЗ, незважаючи щодо того наскільки воно неймовірне, існують ймовірні інщі ПЗ залежності, які якщо не у циклі оновлення також, тоді залишають уразливості де подібні були опубліковані. Складна частина у них є такою тому що деяке ПЗ є не у циклі з катячиїмися оновленнями чи подібному до нього наприклад воно всередині водоспадної моделі, та й так таке ПЗ має КЖЦ та подібні всередені них якщо оголошені //тому що у alternativeto.net існує спосіб повідомлень //про КЖЦ і подібні принаймні так знайдено для деякого відкритокодового ПЗ //включаючи з останньою датою оновлення для деякого ПЗ //але невідомо це оголошено чи там для того способу //кодово чи інакше таким чином залишаючи можливість продовжити застосовувати подібне ПЗ зі знайденими уразливостями після того як таке ПЗ вийшло з терміну придатності чи така подібна дата придатності минула чи оновити його якщо доступне. Це оновлення також перефразовуєме при слідуванні за ситуацією у цих декількох посиланнях: https://mvnrepository.com/artifact/org.apache.shiro/shiro-core, https://mvnrepository.com/artifact/org.apache.shiro/shiro-core/1.1.0, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23305, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23302, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104 . До тепер я не знайшов спосіб уникнути цього але існує загальнорозповсюджений погляд позбавити таких залежностей у такому ПЗ у багатьох веб ресурсах, який є WET але не DRY й з уточненням для відкритокодового ПЗ. Тобто за вже відомою наявною присутністю коду у файлах з іншими який є вже відкритокодовим немає потреби його переписувати з нуля замість інших способів за відсутністю інших аргументів щодо цього. Але ця ситуація з пов'язаними оновленнями щодо залежностей з ймовірно опублікованими уразливості у них також й перекривається з їх ПЗ ліцензіями та підготовування особливостей для наступного ПЗ з такими чи іншими залежностями де подібні залежності у використанні але ця ситуацтя є можливо як інший елемент до тієї таблички про зміни у залежностях для такого наступного ПЗ з такими чи іншими залежностями. У подібній ситуації є достатньо складно пришвидшуємим у деякому існуючому на противагу до для деякого іншого ПЗ яке досі без залежностей з за такого пов'язування тих згаданих елементів навіть беручи до опису цієї ситуації те що таке існуюче ПЗ є не невідомим. Тому що швидкість послідовності оновлень для таких ситуацій ледве застосовна тому що подібні уразливості публікуються у невизначений момент часу за чим обов'язково цикл оновлення такого ПЗ який для кожного свій власний від водоспадпадной до скрам і інших. І лише після чого вже їх застосування до іншого ПЗ чи як дістріб'ютіексчейнджі до кінцевих користувачів і кінцевих користувачок. Але це оновлення переважно щодо цієї ситуації протягом застосування їх до іншого ПЗ у тому проміжку часу.

Оновлення від 2022-02-22.

The update as of 2022-02-22.

Про * API Keys; PATs; Personal Access Tokens; ППІ тоукєни. Вперше я помітив їх яка API keys до hooks, тобто до web hooks тобто до веб гачків у Atlassian Jira plugins десь років 8 тому. Але їх додаткова версію і назву помітив і нещодавно у github.com. Використовуються вони як інший тип паролів. Їх відмінністю є те що їх хоча і можливо ввести але найчастіше їх копіюють. І також вони можуть мати у наявності додаткову у собі кодовану інформацію. Тобто одного зразка такого API Key; PAT; ППІ тоукєна може бути достатньо якимось виконанням щоби визначити що до нього пов'язано. Приклад використання наприклад такий. Я не надам веб клієнтам пароль від своєї електронної пошти тому що невідомо що з ним станеться особливо у закритокодових. Але якось треба дізнатися про наявність такої пошти. Тут є сумісним отакий API Key; PAT; ППІ тоукєн. Але і ППІ має надавати пошту без вмісту тобто бути спеціальним ППІ а якщо такого немає то доведеться якщо не пересилати пошту з однієї адреси на іншу для приватності то при отриманні пошти все ж таки надсилати наприклад порожнього електроного листа до іншої електронної поштової адреси при отриманні а таким електронним поштовим клієнтам надавати доступ до тієї електронної поштової адреси куди такі порожні електронні листи надіслані за відсутності таких ППІ і з API Keys; PATs; ППІ тоукєнів поки чекатиму. Схоже з SQL count запитами як щодо ППІ після виконання яких відсутній зміст даних а присутнє лише загалом число. Або щоби не створювати такого електронного поштового спама не робитиму так і користуватимусь існуючими веб електронними поштовими клієнтами поки чекатимему таку особливість хоча і невідомо чи вона з'явиться для такої привватності від невідомих веб поштових клієнтів. Такий невеликий приклад поштового налаштування а не програмування тому що там немає змінних але які є наприклад у деяких оболонках. А у PostScript як у зразка PDL однак мені і невідомо чи він є чи немає але там присутні методи а саме такі методи як то moveto, show, showpage. А у такому електронно веб поштовому налатштуванні і цей метод і складається у надсиланні пошти із використанням або застосування існуючих можливостей якщо через існуючі веб електронно поштові клієнти. Але оцей останньо описаний достатньо потужний тому що з за свого притаманного процесу налаштування .. -> фільтр -> налаштування -> надіслати -> .. спроможний через інший клієнт навіть надіслати до якогось принтера чи друкарника якщо той використовує PDL, такий як PostScript, якийсь вміст щотак за наявності посередницького клієнтського ПЗ яке виконується. Наприклад як альтернатива цьому клієнту. Звичайно якщо такий принтер чи друкарник має у наявності свій зразок веб адреси чи свій зразок електронної поштової адреси для цього приклада. Інакше це досі можливо через інщі способи.

...

It seems in Ops world it is the similar situation as with migrations in software, particularly the one often referred to in these web pages. GitOps proved to be narrow, because whether you can easily switch it to other one, to for example SVN, HG, or others then you are out of it, if you cannot it is the same situation but for other domain that is for software component for Ops in this case. So, these possible necessities of migration and such inability for such easy migrations makes it, GitOps as an approach a technology dependent one as well as and thus a narrow one which is as is embedded in it even in its name. Not polymorphous, though. In that such approach. Because once again as it was in that described situation in these web pages as well as a implementation dependent one. Eventhough there are some implementations for it. And it seems some people already partially have solved it by providing some products for DIY types of Ops linking to other products. Which is at least more diverse than prevailing git in such situation now. Even though how comfortable it is. In such situation in software domain for Dev, it is for me is due to the absence of JFrA, JFA or alike, which is abundantly described in these web pages, but which recently found partially solved when applying smart contracts but in dApps domain. What is missing in Ops domain I have not found yet for at least partially similar situation.

...

With so many APIs now providing data in JSON or XML formats it is becoming popular to duplicate it in some approach or another. For example. If it is via a design pattern, then it is for one or more DTO class for formats. Which is not DRY but WET. But if it is a query like structure, without an explicit class for such data in JSON or XML formats then it is no compile time friendly thus not statically typed from those programming languaged where it supports so as a feature. If it is autogenerated, then it can not join with other types in JSON and XML formats coming. But I did not find an approach in between with static types but with avoiding of its creation with each and every API when it is not supplied by API provider as a dependency. For provider it is too complex to provide such dependency in each and every programming language and there was a period of time when such approach was pretty popular, for client it is too boring to create such classes for each and every API in use because it is repeatable, thus some kind of a converter which does or can do that both in precompile AND in runtime conversions is of that such a dependency.

...

It is called some abstraction leak. https://en.wikipedia.org/wiki/Year_2000_problem. But this interface had already solved it. https://github.com/apache/poi/blob/trunk/poi/src/main/java/org/apache/poi/ss/usermodel/Date1904Support.java or in https://github.com/apache/poi/blob/trunk/poi/src/main/java/org/apache/poi/ss/usermodel/DateUtil.java at getExcelDate(LocalDate date, boolean use1904windowing) method. However in https://en.wikipedia.org/wiki/Unix_time there are two more similar samples for that one: 1 January 1972 and 1 January 1970 so that boolean is more of an array though with all those at least 4 values. It is called some abstraction leak.

Початок оновлення від 2022-02-23.

The update as of 2022-02-23.

Так що існує два джерела чи два типа для подібного windowing.

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/chrono/MinguoDate.html.

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/chrono/ThaiBuddhistDate.html.

Одне з них з деяких операційнийних систем як з типа перемикачевих. Інше з деяких calendar, chronology, тобто з календарів і хронологій.

Кінець оновлення від 2022-02-23.

The end of update as of 2022-02-23.

So to be more precise for DTO.

...

Luckily there JSON an XML codes are not mixed in java code mostly. But that is not so for SQL code in some projects.

And here where there is such a


    hiber  \
            ->
                nate
            ->
    jIncar / 

Because here http://www.hammurapi.biz/hammurapi-biz/ef/xmenu/hammurapi-group/products/sqlc/index.html it is about so many advantages. 1. It also obviates SQL text and table or column names mixed into Java code. Because when typically to use spring as a framework with JPA, OpenJPA, then it is where a plain java class is being wrapped eventually into public /*abstract*/ class Record implements Serializable { private static final long serialVersionUID = 42L; @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "id", nullable = !true, updatable = !true) private short id; @Column(name = "comment") ... String q = "SELECT record FROM Record record " + " WHERE " + " record.id = :" + RECORD_ID; try { Object record = em.createQuery(q)//to parametrize //to statically type...

But that is one approach with over annotations as there.

2. jIncarnate is also a means for better collaboration and separation of concerns between data modelers and Java developers.

Because without that one it will be a mix or that developer then should do it all in such approach.

3. ...eliminating ... runtime errors caused by typos in SQL statements and names of database objects. That is so for typical approach where a small typos is only showing at a runtime or of course it can be via JPQL but with a much more code which is not then 4. it shortens development cycle. however 5. and makes application more robust// and via JPQL too. 6. jIncarnate includes a rules-based code generation framework. And that is where it is so alike with the JSON and XML generation for APIs in DTOs. But there is a strong argument also from a person from Spain, that SQL should not leak into templates, such as in example into Velocity ones, JSP ones. For me it is so, because the idea initially was to move it to Java code at least. But from the other side it is A CODE generation framework. And moreover it is so much similar with spring framework in that it also support or at least supported template frameworks for example such as Velocity and Thymeleaf. 7. The rules-based code generation framework is wired into the SQL Compiler generation process. So it is process dependent but also have an compiler and 8. ...can also be used independently.

But where that was one approach with over annotations as there, this is another one with templates, where in spring framework it can be so similar with templating as another approach, where in templates can be stored SQL and as well as client side such as HTML pieces. But that means also XML and JSON pieces for such approach or..

But there is a third approach here or an acme approach at http://www.sormula.org/zero-config and http://www.sormula.org/example1.

No annotations in code, and no SQL in java code though 1. Can be mixed with JDBC and 2. Executes as fast as plain JDBC and faster if caching enabled at least in those examples.

Which is by the way is also an ORM feature as in Hibernate, what is not defined in case of jIncarnate.

3. Change database by simply changing JDBC jar and url. Though I need to clarify of a pool of connections feature.

And there are its distibuteeexchangees in some package managers and it is also process dependent in http://www.sormula.org/howto.

Though it supports annotations as in http://www.sormula.org/identity and has a separation of concerns at least at a user level of it as a library as for Model, Logic, DDL.

A guess is that it is nice to try to mix those three ones to reach or to achieve if possible 1. ddlAuto = "update"; as in Hibernate to create and to update tables after ORM feature by other element of framework into database but to preserve a separation of concerns for between data model and data developing. As well as by Google FlyWay at least for more complex data transformations later. 2. easy and consice and short Logic over Models as in sormula. 3. templating with SQL generation also with separation of concerns between not only application layers but between SQL activities after a split into templates and in easy process steps for complex SQLs as in jIncarnate.

For that one each build, test, download, distribute cycle is slower.

Оновлення від 2022-02-26.

The update as of 2022-02-26.

So I still use fail-fast mvn package managing non automatedly. But if to use script PingerAndMover from 2022-02-18 and to substitute similar several lines of code with some as


    //...
        Process ptoMonitorSomeWebServiceByIPWithSuchSupportsAsByPingProcess =
             Runtime.getRuntime().exec(new String[]{
            //  "zsh","-c","cat /Users/cat/bioshock.txt" //..
            //  "zsh","-c","sudo crontab -l" //..
            
             "zsh",//or to random for zsh or for others
             "-c",
             //"ping -c 1 000.000.000.000"//no response when no count //to extract
             "cd /Users/cat/bioshock;mvn install -q"
        });
    //...

that would end up as a primitive class for CI until it is runnable during RunTime automatedly because it is iteratable over time per your preference for iteration period in that class if available.

Примітивний зразок класа для тривалої інтеграції кода щодо його компіляціного складання допоки він виконується протягом часу виконання тобто допоки запущений з основою зразка класа PingerAndMover від 2022-02-18 у java джава з Apache maven.

But as long as there are returnCode and bufferedReaderNumero1, such code


    if (readLine.contains("[ERROR]")) {//у межах Apache maven
        System.out.println("Cat discourages " + line);//not validated
        //...
    }

finds some of output, so then email with if possible, or some web service usage or some other method for that if available.///// Тож адже доступні returnCode and bufferedReaderNumero1 у тому зразку деякі вихідні доступні для західки і після цього надсилання електронного поштового листа чи застосування якоїсь веб послуги чи інший метод якщо доступні. Для більш складних випадків обробки вихідних даних можливе застосування класа з виконанням java.lang.Throwable у межах java джава.

Це щодо розробки у тому випадку, після того як код готовий і при переході до тесту чи до його компіляційного складання щодо іншого у розробці з режимом не за тестами спочатку а радше у розробці з режимом за доменною моделлю спочатку. Але можливо і для застосування для інших випадків тобто наприклад для розміщення як частини операцій у тому налаштуванні.

It is for development in that case mostly, after code is done and during such transitions to tests or to compilations for others in a non TDD or other development mode but rather in DDD mode. But it is possible also to apply it for other cases that is for example for deployment as a part of Ops in that setting.

Це у межах DDD у якій модель спрямована з задньої частини ПЗ тобто невидима більшістю для користувача чи користуачки. Але вона можлива і спрямована і з передньої частини. У O2O який є неподільно жорстко пов'язаний або tightly coupled до деякого значення з деякими частинами Міжмережевої і минуло міжмережевої і позаміжмережевої првсутні подібні приклади. А між ними тобто при такій розробці можливо присутні DTO і подібні як модель тобто як патерн дизайну чи відсутні. Адже існують і інщі способи щодо цього то це нагадує про додаткові інтеграційні операції цих частин тобто щонайменш задньої і передньої якщо вони присутні з якого б напрямку вони не були здійснені принаймні протягом процесу розробки у межах цих моделей.

Оновлення від 2022-02-26.

The update as of 2022-02-26.

So I still use fail-fast mvn package managing non automatedly. But if to use script PingerAndMover from 2022-02-18 and to substitute similar several lines of code with some as


    //...
        Process ptoMonitorSomeWebServiceByIPWithSuchSupportsAsByPingProcess =
             Runtime.getRuntime().exec(new String[]{
            //  "zsh","-c","cat /Users/cat/bioshock.txt" //..
            //  "zsh","-c","sudo crontab -l" //..
            
             "zsh",//or to random for zsh or for others
             "-c",
             //"ping -c 1 000.000.000.000"//no response when no count //to extract
             "cd /Users/cat/bioshock;mvn install -q"
        });
    //...

Оновлення від 2022-02-28.

The update as of 2022-02-28.

Але якщо знову використати код замінивши декілька рядків.. But if to use script PingerAndMover from 2022-02-18 and to substitute similar several lines of code with some as


    //...
        Process ptoMonitorSomeWebServiceByIPWithSuchSupportsAsByPingProcess =
            try {
                //stackoverflow.com/a/67962071/1851286
                SpringApplication.run(Application.class, args);//implies dependency
            } catch     (org.springframework.boot.web.server.PortInUseException e) {
                Process ptoMonitorSomeWebServiceByIPWithSuchSupportsAsByPingProcess =
                    Runtime.getRuntime().exec(new String[]{
                    //  "zsh","-c","cat /Users/cat/bioshock.txt" //..
                    //  "zsh","-c","sudo crontab -l" //..
                    
                    "zsh",//or to random for zsh or for others
                    "-c",
                    //"ping -c 1 000.000.000.000"//no response when no count //to extract
                    "pkill processName"
                });
                
                //...

                if (readLine.startsWith("")) {//to add check for null.
                    //or
                    SpringApplication.run(Application.class, otherargs);
                    //SpringApplication.run(Application.class, new String[]{"--server.port=8444"});
                    //when invoked recursively it is a port rebalancer for port usage among port pool with server as from client for startup stage via application restarts within many busy ports which are used before or without querying.
                } else {/*NOP.*/}
            }
             "cd /Users/cat/bioshock;mvn install -q"
        });
    //...

тоді місцева програма повторно запускаєма ним. Then a local process is restartable by it. As long that code is addable for checking before stopping before restart, then it is also monitorable automatically. Адже той код можливий до додання для перевірки щодо присутності перед зупинкою перед повторним запуском то тоді він теж і можливий бути моніторюваний автоматично.

Є у нього і два недоліка. Адже я скопіював його двічі як способом то він має бути видобутий у метод згідно рефакторингу. То є WET and not DRY. І другий це те що при зміні перемикачевої системи він можливо не функціональний тобто не кросплатформений.

It contains two disadvantages. Because I have copied it twice as an approach then it should be extrcted according to refactoring. That is WET and not DRY. And the second one is that after a change of triggeral system it is possibly non functional that is not crossplatform.

Другий тому що у ньому застосований не лише джава Java код а і ППІ самої перемикачевої системи. Тому це створює для підтримки кросплатформенності набір тверджень таких як наприклад if else та else if або switch.

The second one is because it is applying not only Java as a code but also and API of triggeral system itself. Therefore it creates for crossplatformeity support or for postcrossplatformeity a set of statements such as if else and else if or switch.

Але якщо застосувати код з самого PingerAndMover щодо його Pinger частини і застосуввання цього коду для повторного запуска замінивши його викликом знову ж таки наприклад перемикачевою системою віддаленого скрипта чи віддаленого коду то тоді можливо повторно запускати не лише місцеві а і віддалені процеси чи віддалені веб послуги в залежності від того скрипта чи коду. Але водначас це створює і залежність від наявності і доступності того віддаленого скрипта чи віддаленого коду.

But if to apply the code from PingerAndMover itself for its Pinger part and application of this code for restart replacing it into a call for example again by triggeral system of a remote script or of a remote code then it is possible then to restart not only local processes and also remote processes or remote web services depending on that script or on that code. But simultaneously it creates a dependency on availability and accessibility of that remote script or of that remote code.

У http://www.sormula.org/home присутня така особливість цитата "Change database by simply changing JDBC jar and url" тобто змінювати базу даних змінюючи файл застосунка для з'єднання з базою даних і посилання для з'єднання з базою даних. Це зазначено про портативність тобто про рухомість. Але подібної такої особливості я не знайшов для фреймворкових програмних каркасів лише у цьому випадку для зміни файл застосунка фреймворкового програмного каркаса. А значить що я не знайшов подібного застосунка як sormula для фреймворкових програмних каркасів. Тому що при застосуванні такої особливості і усі особливості рівня розробника чи розробниці для баз даних і для фреймворкових програмних каркасів принаймні у джава java особливо якщо їх меншість можуть бути наприклад виключеннями при їх несумісності з іншим фреймворковим програмним каркасом при наявності замкнення виробника АЛЕ коли такий додаток чи застосунок компіляційно складеться чи інакше після такої подібної зміни бази даних і того посилання чи файл фреймворкового програмного каркаса. Тобто така особливість як у sormula і є основою для JFrA, JFA or alike. При дозволених провалах після такої міграції і переміщення і включенні ситуації з замкненнями виробника. Якщо це обробляється виключеннями тоді такі виключення потім обробляються чи ні, тобто можливе застосування fail-fast і інших ПІСЛЯ успішного компіляційного чи іншого складання. У цьому оновленні припущено що фреймворкові програмні каркаси підтримують їх змінність. Тобто такий процес не односпрямований.

In http://www.sormula.org/home there is such a feature as a quote "Change database by simply changing JDBC jar and url" for connection with database. It is in portable class of features. But such a feature I have not found yet for frameworks but in this case it is only a file of framework itself. That is I have not found such application as sormula for frameworks. Because while applying such feature as in sormula all features dependent on frawework at the level of application developer for databases and for frameworks at least in java especially if there is a miunority of them can be as exceptions while their incompatibility with other framework on presence of vendor lock BUT when such application is complilationally or otherwise consistent AFTER such change of a database and that URL or of framework. That is such feature as in sormula and is a basis for JFrA, JFA or alike. Under allowed fails after such migrations and inclusion of a situation with vendor locks. If it is processed in a manner of exceptions whether such exception then are processed or not, that is possible to apply fail-fast and others AFTER successful compilation or its other types. In this updaate it is assumed that such frameworks support their changeability. That is such process is not unidirectional.

Then not for all by at least for some ones. Тоді не для всіх а принаймні для деяких.


                          посилання   клієнтський       обслуговуючий
                          для         додаток           додаток
                          мережевого  для розробки      для розробки
                          з'єднання   з ним чи з нею;   з ним чи з нею;
                          щоби бути   client            server
                          мережевою   application for   application for
                          чи          development       development
                          мережевим;  with it           with it
                          URL for
                          networking
                          to be
                          online

    база даних;           так         так               так
    database

    framework;            ні          так               ?
    фреймворковий
    програмний каркас

    веб сервер;           так         так               так
    веб обслуговувач;
    web server

    веб місце;            так
    веб сайт;
    web site

    додаток;
    застосунок

    DApp;Dapp;
    децентралізований
    застосунок

    щоби ділитися
    контентом
    але не без'імяційно
    content sharing       так         так               так
    but not anonymously

        наприклад
        for example
        puffin like

        наприклад
        друкарником;
        for example
        by printer

    щоби ділитися         так         так               так
    мережевим з'єднанням
    без'імяційно
    connectivity sharing
    anonymously
         наприклад 
         TOR like

    щоби ділитися         ?;
    мережевим з'єднанням  за запитом;
    але не без'імяційно   by request
    connectivity sharing
    but not anonymously

Оновлення від 2022-03-05.

The update from 2022-03-05.

Що помітно з деякими тоукєнами і особливо з PAT, ППІ тоукєнів якогось розміру що це такий тип об'єктів який достатньо дуже часто пересуваємий з місця створення до місця пересування через буфер обміну чи через процес подібний до тягти і перенести якщо у межах одного середовища і хоча і можливий для вводу безпосередньо якщо у межах декількох.

Оновлення від 2022-03-10.

The update from 2022-03-10.

У Hikari продукті можливо до встановлення найбільшої кількості запитів через спільне сховище з'єднань до баз даних. Схожим чином деякі ППІ встановлюють обмеження щодо кількості ГТТП запитів до обслуговувача. Але це один з трьох способів запобіганню ВПос DOS і ВВПос DDOS як деяким зусиллям хакінгу. Інщі два це повторний запуск обслуговувача чи обслуговувачки після успішного ВПос DOS чи ВВПос DDOS. Вони припускає деякий моніторінг веб сервісу чи веб послуги щодо наявності його чи її обслуговування. Та третій це збільшення обслуговування. Тобто


                                                          запити

                                                                 до баз даних      через ГТТП    через інші протоколи
    динамічне середовище
        збільшення наявних обслуговувачів
        збільшення і зменшення наявних обслуговувачів
            наприклад архітектурно за допомогою 
            балансерів чи кеш обслуговувачів
    достатньо статичне середовище
        достатньо рідкі чи повільні міграції
        для збільшення доступних 
        ресурсів обслуговувачу чи обслуговувачам

Але і у динамічному середовищі навіть якщо у такому середовищі веб сервіс чи веб послуга підтримує збільшення і зменшення наявних обслуговувачів тобто scale up і scale down наприклад зберігання тих запитів з пам'яті як то RAM до файлу, ті ресурси однак скінченні. Тому що scale up та scale down теж скінченний тому що виокремленний він чи ні у описі до веб послуги чи веб сервіса які його постачають у динамічних середовищах, через ППІ чи інакше, чи надані дані про це чи ні, наявність доступних обслуговуваів для такого збільшення і зменшення наявних обслуговувачів однак скінченна. Тобто подібне рішення як у Hikari для запитів до баз даних але і до інших типів запитів наприклад веб запитів неминуче тому що зменшує повну відсутність обслуговування при обмеженних доступних ресурсах хоча і завдяки ігноруванню обслуговування деяких запитів. Навіть для динамічного середовища принаймні тимчасово за таких умов. У якомусь місці архітектурно чи навіть у середині обслуговувача чи веб сервіса чи веб послуги. Тому що такі запити так чи інакше можливі до повторення. Навіть якщо це не ідентичні запити а такі запити що відрізняються чимось ?1 чи ?2 і тому подібні. Адже запити мають також кінцеву швидкість щодо їх обробки, це рішення з обмеженнями достатньо посереднє тому що воно включає часткове вирішення проблеми а саме завдяки усуненню деякого обслуговування деяких запитів що можливо включатиме відхилення щодо обслуговування а саме усування деяких запитів що призводитиме до false positives, тобто необслуговуванню деяких запитів які мали би бути обслуговані що зменшить таке customer satisfaction тобто задоволення запитуючих. Але вони й рідкі. Але рішення Hikari щодо запитів до баз даних залежність або модульне. Тобто воно абстрактне від якогось специфічного постачальника баз даних Щодо запитів наприклад ГТТП запитів, ймовірно я знаходив деякі рішення в середині деяких веб обслуговувачів тобто application servers. Але якщо воно вбудоване у них то це є рішенням але воно не таке абстрактне і не таке модульне і не як додаткова залежність або не як опціональна залежність як у Hikari щодо запитів до баз даних. Щодо подібного щодо інших типів запитів наприклад RSS я не знаходив, тобто мені невідомо. Але якщо воно доступне до видобування або до екстрактування як за допомогою метода рефакторингу як один з типів рішень щодо різних типів запитів то це формує деякий клас рішення щодо обслуговування обмежень щодо деяких типів запитів а й но принаймні цих двох: для запитів до баз даних і для запитів ГТТП.

Оновлення від 2022-04-09.

The update from 2022-04-09.

Таким чином вчорашнє оновлення у частині пропускання параметра типа дигітури також стосується і формата, тому що формат є моделлю, а це пов'язано із тим наскільки рішення ПЗ жорстко зв'язано із такою моделлю як то формат даних. Яке можливо включає і такий як тип дигітури у застосуванні. Щодо його подальших змін а інакше це про замкнення виробника чи замкнення виробниці у частині формата тобто у частині моделі.

Оновлення від 2022-05-09.

The update from 2022-05-09.

So for example while migrating between framework, as only one feature among others, to add a CORS, which is a part of configuration, that one is in spring framework it is for example


    http
        .authorizeRequests()
            .antMatchers(HttpMethod.POST, "/someURLasEndpoint").permitAll()
                .and().cors(); 
    http
        .authorizeRequests()
            .antMatchers(someURLsAsEndpoints).hasAuthority("ADMIN")
                .anyRequest().fullyAuthenticated()
                    .and().cors()

While in quarkus framework that one is as in that example


    @Provider   
    public class CorsFilter implements ContainerResponseFilter {
      @Override
      public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) throws IOException {
        responseContext.getHeaders().add("Access-Control-Allow-Origin", "*");
        responseContext.getHeaders().add("Access-Control-Allow-Credentials", "true");
        responseContext.getHeaders().add("Access-Control-Allow-Headers", "*");
        responseContext.getHeaders().add("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS, HEAD");
        responseContext.getHeaders().add("Access-Control-Max-Age", "100000");
      }
    }

While in Micronaut for that one it is to change a file application.yml.

While in each framework it is flexible, and in each one it is also differently, while CORS is one feature among such ones, where spring also has an autoconfiguration feature among other frameworks.

Whether an application which applies that feature should be then restarted or not, at least that is one of the features which are automatable for such migrations, among those three frameworks among others.

For example by extracting all those common parameters among those three frameworks among others by such extension or plugin for example and by providing different implementations with sn options to customize them in a best case still to support that flexibility when provided by different framework value for such extension oor plugin during migrations. Which is somewhat similsr with that of providing a browser version in oother case previously in some JavaScript code when using some extensions or plugins.

Оновлення від 2022-05-14.

The update from 2022-05-14.

IDRU

What if it is for example per app that is per application, when it is a rolling updates model, it turns out a developer knows somehow that user distribution, while for others it is hidden which is after 3 years in that comment for some users it is also foundable that there is such a repetition in testing which is also present for some web application, at least previously with some browser versions, but what is more, if it isn't a case, then NOP, but if it is a case, then a developer puts the load of that burden back to a source of rolling updates, that is visible that such model is not very friendly to independent development model or to that 5% of users, that is probably its limitation in that combination, http://thetechawesomeness.ideasmatter.info/configuring-alternative-compilers-in-macos.html , http://thetechawesomeness.ideasmatter.info/another-specific-method-for-application-creation-for-operational-system.html , but that source of that rolling updates probably has its some own limitation which is unknown similar to that previously unknown user distribution as a feature or as other one for some other users unless as in that comment if so.

Оновлення від 2022-08-29.

The update from 2022-08-29.

Це оновлення очікується достатньо розлогим тож скорочено про нього..

Змінити постачальника послуги чи ресурса це така ситуація яка варіабельна за кількістю використань у веб як особливість чи як альтернатива як то option.

Звичайно, якщо також не завжди рівнем користувача чи користувачки, якщо вона не після надання рівнем розробки.

Воно також безпосередньо пов'язано з ситуацією щодо JFra і подібними цими веб сторінками.

Тож. Декілька років тому, була хвиля чи краще як то advent принаймні у деяких веб крамницях додатків і застосунків які створили, а також веб послуг і веб сервісів принаймні тут у околицях як і одній інщій ситуації цими веб сторінками таких які надавали принаймні у той час особливості додання і пошуку таких ресурсів які приєднані до інтернет як то веб камери і Wi-Fi точки доступу.

У обох таких ресурсів є схожими і спільними як то convergent дві особливості. Обидва були щодо публічних чи спільних таких ресурсів, і у моделів даних таких ресурсів були спільними принаймні на той момент тип, назва, розташування, радіус тощо. У спрощеному як то simplistic режіми.

Але саме у цьому оновленні від 2022-06-07 що їх також об'єднує принаймні теж рівнем моделі даних.

Мені невідомо чи та група таких публічних веб сервісів і веб послуг і інших були з'єднані між собою як то централізовано наприклад за допомогою такої веб послуги як соціальної мережі чи децентралізовано чи приховано чи інакше.

Адже у той проміжок часу вже існували постачальники для відображення таких розташувань, у тому числі і один у Google який який пізніше надавав особливість додання у окремі шари таких даних щодо об'єктів але більшістю то були одно чи двовимірні об'єкти для розташувань і надавав також особливість експорту таких даних. Але у випадку тієї хвилі ті такі ресурси щодо даних щодо тих їх радіусів мають двох чи тривимірні такі дані як властивість. Чим це їх і об'єднує принаймні при застосуванні як у цьому оновленні від 2022-06-07.

Але повертаючись до початку цього оновлення щодо таких змін постачальника чи постачальниці у веб як неодноразово згадувалось цими веб сторінками узагальнено можливі 2 випадка. З посереднім елементом чи з посереднім елементами і без них.

За невідсутності такого посереднього елемента чи таких посередніх елементів це щонайменш як то і за допомогою стандарта, інтерфейса і конвертерний про який дещо розгорнутіше тут.

Але цей випадок при зміні постачальника у веб щодо відображення таких розташувань визначний тим, якщо такі двох чи тривимірні чи інакше дані про радіус також щодо таких об'єктів чи ресурсів навіть зважаючи тоді вони були стаціонарними є експортованими до деякого файлу у якомусь форматі то це створює такий спосіб як за допомогою такого файла як у DTO, data transfer object як інтерфейс. Дещо як і у 2022-02-22 і у 2022-03-12; http://thetechawesomeness.ideasmatter.info/mvc.html.

Але він також і створює додаткову вимогу для розробників і розробниць щодо сумісності щодо такого файла для інших подібних таких постачальників і постачальників у веб щодо такого файла у такому його форматі якщо вони самі не використовують чи не застосовують конвертерний метод.

Чим також схоже з даними і схемами даних як у XML і його підтипах та у JSON, якщо такий експорт даних не саме з такими форматами даних.

При застосуванні HATEOAS ХейтОАС альтернативно це також надає деякі можливості для навігації між такими веб сервісами чи між такими веб послугами щодо таких об'єктів.

Оновлення від 2022-09-20.

The update from 2022-09-20.

xbar of version 2 which is a ancestor of BitBar abouth which one as previously in this web page and http://thetechawesomeness.ideasmatter.info/hyperprotocol.html and http://thetechawesomeness.ideasmatter.info/messenger-types.html, has a feature to start code from a menu at in one of the triggeral systems mostly being for users.

While I found it several months ago, it is in JavaScript;http://thetechawesomeness.ideasmatter.info/javascript-chapters.html and then I did not found such application or approach for Java;http://thetechawesomeness.ideasmatter.info/java-chapters.html.

So starting a search from https://stackoverflow.com/a/67237918 which then to at https://stackoverflow.com/a/61522873 and then to at https://stackoverflow.com/a/68571742 had given https://github.com/dustinkredmond/FXTrayIcon with JavaFX which was also mentioned in http://thetechawesomeness.ideasmatter.info/contradiction-creating-operation.html;2022-02-05 as a dependency but other than that one as a maven dependency as well as com.dustinredmond.fxtrayicon: FXTrayIcon: <!--See Below -->, which includes https://github.com/dustinkredmond/FXTrayIcon/blob/main/src/test/java/com/dustinredmond/fxtrayicon/RunnableTest.java .

Which is enough, because it is combinable with such TimerTasks as for example in http://thetechawesomeness.ideasmatter.info/accelerator-of-code-progress.html and http://thetechawesomeness.ideasmatter.info/imasvaji.html and http://thetechawesomeness.ideasmatter.info/some-virus-control-methods.html and http://thetechawesomeness.ideasmatter.info/za-graty-freedom-bot-institution.html are providing the same mimicable behaviour in Java as in that application. Though that approach is polyglot by that one because such approach as by 2 programming languages then.

But more than that, there are two more feature by it.

If to put PingerAndMover classes as with a mention in http://thetechawesomeness.ideasmatter.info/accelerator-of-code-progress.html and http://thetechawesomeness.ideasmatter.info/configuring-alternative-compilers-in-macos.html and in this web page and http://thetechawesomeness.ideasmatter.info/issues.html and http://thetechawesomeness.ideasmatter.info/part-recomposer.html or some classes after PingerAndMover's amendments in those methods for that RunnableTest.java before compilations, others, not only in Java ones are runnable or startable as well, including xbar as an application.

As long as one of the PingerAndMover includes a browser, then a browser as well.

One of the differences is that it does not include that list of scripts to install and requires compilations, so such approach is more for developers than for users unless compilation part is automatable somehow, because the scripts for it are available elsewhere as well.

As of 2022-09-20 according to FXTrayIcon the crossplatformeity status is at least then partially supported by such approach along with xbar's one.

Eventhough it relies on some specific type of GUI as in FXTrayIcon as well as for browser, but as long as a browser for PingerAndMover does not require that specific type of GUI, such approach support also interaction with some triggeral systems with such type of GUI, which are for example web servers by extracting the part of FXTrayIcon code into a class, which substitutes that component which is available then in a system without such type of GUI by its own. But leaving the code in those methods or code for menu items the same. So by this bit this approach is more flexible than xbar's one.

Another feature of difference between them is that taken that some versions of Java includes Nashorn JavaScript engine as with a mention in http://thetechawesomeness.ideasmatter.info/configuring-alternative-compilers-in-macos.html and http://thetechawesomeness.ideasmatter.info/messenger-types.html, then probably some xbar scripts are simulatable тобто удаваємі but, again, including compilations with them in this approach but I did not test such compatibility of JavaScript items and Java items and Java FX items then by such feature.

Such application in Java in some of the triggeral systems with such type of GUI, unless started as a process but as an application, when with a specific code and with compilations, can show up as similarly as by icons in menu and elsewhere, which reminds, that it is also an advantage as a flexibility by this approach for development, not only because it can be started as a process multiple times without those items, but also compiled so in one application as well not relying on application for in user in that one. Thus for some triggeral systems with such types of GUIs and for those ones without such type of GUIs, which is probably some feature of crossplatformeity or another dimension of crossplatformeity.

Оновлення від 2022-12-06.

The update from 2022-12-06.


  ______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  | PAT or Code Value for Validation type as of 2021-07-27       | довжина;length   | тривалість;duration | PAT server;обслуговувач | клієнт;client                 | клієнт і особливість               | третій бік                                                                                             | підтвердження;confirmation |
  | ППІ тоукєнів або кодового значення для валідації тип         | і набір символів |                     | наприклад видавник      | той чи та хто його налаштовує | наприклад приймаючий бік як клієнт |________________________________________________________________________________________________________|____________________________|
  | від 2021-07-27                                               | and symbol set   |                     |                         |                               |                                    |shadowees;http://thetechawesomeness.ideasmatter.info/active-and-passive-computer-vision.html|..         |____________________________|
  |                                                              |                  |                     |                         |                               |                                    |____________________________________________________________________________________________|___________|____________________________|
  |                                                              |                  |                     |                         |                               |                                    | підглядання чи подібно;sneaking      |  вгадування чи подібно                              |           |                            |
  |                                                              |                  |                     |                         |                               |                                    | місцево;locally | remotely;віддалено | зовнішньо;externally | внутрішньо;internally        |           |                            |
  |______________________________________________________________|__________________|_____________________|_________________________|_______________________________|____________________________________|_________________|____________________|_____________________________________________________|___________|____________________________|
    друкований чи подібно;printed or other alike                                                                                                                           
                                                                                                                                                                      веб послуга і автоматичне
    статичний і змінюємий;static and changeable                                                                                                                       повторення у ній наприклад для
                                                                                                                                                                      платежів;web service and automatic
    dynamic;самозмінний                                                                                                                                               repeating it for example for
                                                                                                                                                                      for payments
    static and dynamic;постійний змінний і самозмінюєма частина;
    http://thetechawesomeness.ideasmatter.info/one-more-one-more-one-time-password-client-authenticator.html
        2fa 

Оновлення від 2023-01-28.

Update as of 2023-01-28.

У нещодавньому способі є перевага при застосуванні абстракції над даними виділяючи це в окремий компоненталь. Чим при http://thetechawesomeness.ideasmatter.info/table-chapters.html;32 закритокодовості повертає до тіньовиків і тіньовикинь для збільшення обсягу обробки даних. Що є виключеннням при використанні чи застосуванні mdnplusndm.

In a recent approach there is an advantage while abstracting over data in extracting it as a separate componental. Which while http://thetechawesomeness.ideasmatter.info/table-chapters.html;32 being from closed source ones returns to shadowees for increasing the data flow through it. Which is not prone as well for mdnplusndm. Інший до двох у http://thetechawesomeness.ideasmatter.info/ductible-wireless.html;2022-07-27.

Якщо вважати образи як то images контейнерами даних для них тобто сховища для даних то спочатку Docker як додаток був популярним при їх застосуванні чи використанні і ймовірно серед небагатьох які надавали таку особливість наприклад для Apache James але пізніше у веб сервісах і у веб послугах теж було додання подібної особливості для як то у scaleway.com крізь ППІ і нещодавно у onworks.net крізь одне з хмарних сховищ. І використовує чи застосовує підв'язку для цього. Відтак це починає нагадувати спільний спосіб схожий з ситуацією з JFRA.

..

Тип: блокуючий процес. Веб місце: загальнодоступне. Наприклад у А1у джаваскріпт щоб уникнути деяких зламів Userscriptом чи інакше перевіряти наявність оновлення для уминання цього. Тоді потрібні 2 перевірки а саме перед завантаженням джаваскрипт кода веб місця, потім саме завантаження кода веб місця, потім друга перевірка щодо наявності оновлень для джаваскрипт частини у ППіНТВСуІ. Це блокуючий процес тобто BIO. На відміну від випадка про який у http://thetechawesomeness.ideasmatter.info/single-extensibility-principle-and-cyclic-inheritance.html;2022-12-18. Тоді зусиилля хакінгу у будь яких частинах дигітури які можуть додавати такі коди до веб місць не можуть цього випадку досягнути. І не потрібна так звано пісочниця для таких випадків для виокремлення але потрібні 2 перевірки щодо таких оновлень у ППіНТВСуІ при кожному завантаженні джаваскрипт кода перед його запуском з сторонніх веб місць. Тобто окрім наявності цього блокування потрібно наявне інтернет з'єднання. Але це не для невідомих уразливостей у загальнодоступних веб місцях. Затримка як то лаг щодо джаваскрипт кода не пристосовна до цього випадка але так звано man-in-the-middle або лаг з постачанням оновлень з ППіНТВСуІ можливі. Окрім того це повільніше і вимагає додаткових запитів і даних між ППіНТВСуІ і постачальником оновлень для нього якщо це не сам ППіНТВСуІ тобто з його веб місця. При кожному запиті 1 джаваскрипта кода чи їх пакета перед запуском.

http://thetechawesomeness.ideasmatter.info/table-chapters.html;4. Принаймні деякі з серверів і оброблювачів і оброблювачок веб місць мали перетин з BIO і до таких які NIO на відміну від джаваскрипт.

..

Тож за наявності декількох дістріб'ютічейні і такої затримки як то лага при розповсюдженні дістріб'ютіексчейнджі створює принаймні перевагу про яке початком цього оновлення. Але у іншому випадку і недолік як про ту перевірку щодо уразливостей. Як і відсутність. Тож чи такі оновлення централізовані чи децентралізовані але це впливає залежно від розташування щодо такої затримки. Якщо вона як розширення подвійного обмеження; http://thetechawesomeness.ideasmatter.info/table-chapters.html;23 а саме обмежуючий інтервал чи обмежуючий проміжок у межах джава. http://thetechawesomeness.ideasmatter.info/automatically-changeable-passwords.html;2023-01-26. Наприклад щодо клієнта і сервера чи інших далі цим оновленням сьогодні. Водночас це має наслідки і для інших. Принаймні до випадків про які у http://thetechawesomeness.ideasmatter.info/market-concurrency-provider.html та http://thetechawesomeness.ideasmatter.info/freedom-security-privacy.html. Тому це можливо до запитів як у http://thetechawesomeness.ideasmatter.info/mvc.html;2021-05-21.

Оновлення від 2023-01-30.

Update as of 2023-01-30.

Крізьплатформенність як властивість у різних додатках наприклад у пакетних системах є аналогом як JPA тобто є аналогом ППІ між деякими перемикачевими системами. Тому що мають спільний інтерфейс для КРІ. Тому ці ддеякі перемикачеві системи надають декілька спільних інтерфейсів КРІ для тих самих особливостей іноді. Їнщі можливо виокремити і у різних перемикачевих системах за допомогою http://thetechawesomeness.ideasmatter.info/pispjjslk.html як то застосовуючи help теж у КРІ. Вийнятком є фреймворкові програмні каркаси які не мають таких ППІ. Тож міграція даних чи пересування даних чи переміщення даних якщо такий наявний саме інтерфейс для даних відрізняється для такого випадку.

Цим також це додає до посткрізьплатформенності. http://thetechawesomeness.ideasmatter.info/single-extensibility-principle-and-cyclic-inheritance.html;2021-02-08.

Цим ці повторення і додають до посткрізьплатформенності і і створюють ймовірно деяку їх шаровість у властивостях і демонструють спосіб у якому за допомогою способа http://thetechawesomeness.ideasmatter.info/pispjjslk.html про їх уникнення який є альтернативним до цього.

Тому що він про WET і він поммітний за допомогою схемок від 2021-01-16 та http://thetechawesomeness.ideasmatter.info/freedom-security-privacy.html;2021-01-16 та http://thetechawesomeness.ideasmatter.info/reminder-about-data-neutrality.html;2021-01-16.

Наприклад у spring як фреймворкового програмного каркаса була помітна одна зміна у межах ДТПі а саме після додання додаткового модуля та автоматичного створення файлів pom.xml попри відсутність інших для джава про яке вже було цими веб сторінками через змінився спосіб від налаштування або попереднього налаштування його з процедурного поодиничного до більш пакетного між деякими його версіями. Тобто це спростило його налаштування.

Схоже з ППІ щодо JFRA з початку оновлення сьогодні навіть за допомогою коммпоненталя про який у оновленні від 2023-01-28 також і історія повідомлень;http://thetechawesomeness.ideasmatter.info/messenger-types.html і історія ППіНТВСуІ;http://thetechawesomeness.ideasmatter.info/another-specific-method-for-application-creation-for-operational-system.html; http://thetechawesomeness.ideasmatter.info/table-chapters.html;28 якщо невиокремлюємі це теж нагадує;http://thetechawesomeness.ideasmatter.info/reminder-about-data-neutrality.html про схожість щодо складності міграції таких даних чи пересування таких даних чи переміщення таких даних.

Оновлення від 2023-02-02.

Update as of 2023-02-02.

Також щодо понадвідкритокодового http://thetechawesomeness.ideasmatter.info/table-chapters.html;32 має бути додано з за можливостей OSGI і подібних про необхідну наявність mdn+ndm або інших для як самого дістріб'ютіексчейнджі так і для його запущеного зразка якщо вони не вийняті перед запуском.

Оновлення від 2023-02-03.

Update as of 2023-02-03.

Адже ймовірно можливі різні варіанти після застосування для понадвідкритокодового mdn+ndm або інших для вихідних дістріб'ютіексчейнджі після компіляційного складання з однієї платформи для іншої якщо з різних платформ декілька разів то видимий запис цього складання і отримання mdn+ndm або інших цього уникає тому що для кодового дістріб'ютіексчейнджі це вийнято якщо у ньому відсутня суміш з конфігураціями, наприклад конфігураціями ІСР та конфігураціями кодового сховища, які часто можливо змінюються. Тому воно теж має тоді бути як дістріб'ютіексчейнджі доступне.

Це уминає зайвим повторним компіляційним складанням при цьому.

Це також можливо натякає чому використання даних чи застосування даних крізь особливості не понадвідкритокодових операційних систем не популярні серед посередницьких постачальників наприклад у веб сайтах і у веб місцях для кінцевих користувачів і для кінцевих користувачок які здаволось би додали би їх до веб сайтів і до веб місць замість повторення тієї самої особливості у переважній їх більшості.

http://thetechawesomeness.ideasmatter.info/PingerAndMover.java є агностічним сам по собі щодо безім'яційності чи персоналізованості. Щодо інших а саме компіляційного складача як додатка, віртуалізатора, операційної системи зазделегідь йому невідомо.

Тож для перевірки після отримання кодового дістріб'ютіексчейнджі якоїсь версії і його компіляційного складання чи іншого одного значення після застосування mdn+ndm або інших достатньо для співставлення з понадвідкритокодовою версією. Але за умови ідеї щодо усього у одному місці і таких користувацьких налаштувань можливо застосування і до кодового дістріб'ютіексчейнджі теж mdn+ndm або інших. Тоді якщо вони не відрізняються обидві пари або 2 дуплети співпадатимуть при перевірці крізьплатформенно тобто з різних платформ. Якщо наприклад користувацькі преференції змінюють вихідний дістріб'ютіексчейнджі то лише одна пара або один дуплет співпадатиме. Якщо жодні не співпадатимуть то були зміни і або у віддаленному кодовому сховищі або у місцевому щось повторно записане або ж сам видимий запис чи світлина у понадвідкритокодовому розташуванні несправжній чи несправжня. Якщо було повторно записане місцево то це можливо потребуватиме процеса щодо їх відділення а саме кода від налаштувань користувацьких і інших даних наприклад кодового сховища якщо воно записує до того самого розташування при наявності такої ідеї.

При наявності такої застосування такої ідеїі підтримки цього щодо дідення при перевірці до строгої і не строгої при підтримці різних ІСР, систем побудови та кодового сховища і можливо інших для користувацьких налаштувань.

Оновлення від 2023-02-06.

Update as of 2023-02-06.

Щодо 20% підвищення у http://thetechawesomeness.ideasmatter.info/internet-and-exinternet-and-internetless.html;2023-01-31 навіть якщо навпаки то це лише нагадає ситуацію у http://thetechawesomeness.ideasmatter.info/network-types.html;2023-02-04 про гібридність і про таке явище як технологічний зоопарк, чим також можливо і нагадає про 100% проміжок але дещо ширший. http://thetechawesomeness.ideasmatter.info/automatically-changeable-passwords.html;2023-01-26.

Тоді якщо у перспективі такого процеса і з http://thetechawesomeness.ideasmatter.info/table-chapters.html;18 для клієнта чи клієнтки то


..//клієнту невідомо
↓
А1//open source;відкритокодове
↓
А2//closed source;закритокодове
↓
А3//closed source;закритокодове
↓
..//клієнту невідомо

то якщо існують і інщі А1.1 навіть різних форматів але вони теж можливо або відкритокодові або ні то можлива міграція і клієнту це помітно. Але якщо вони відкритокодові або понадвідкритокодові як у 2023-02-02 і у 2023-02-03 то після міграції до А1.1 тому що вони а саме А1 і А1.1 майже однаково швидкі щодо змін і зчитування і після застосування mdn+ndm або інших з доданням до них ШРкода крізь закритокодове або як у http://thetechawesomeness.ideasmatter.info/codifizer-and-decodifizer.html клієнт чи клієнтка може ходити по таких закладках.

Оновлення від 2023-02-15.

Update as of 2023-02-15.

З за депрекації чи точніше з за так звано м'якої депрекації; http://thetechawesomeness.ideasmatter.info/tapi.html як типу у якому вимога перетворена на запит чи питання інакше не обов'язково що вона відтак вже не вимога. З за двозначності і більше як то у ситуації з MACOSX_RPATH але лише коли це процес. Тобто для когось це вимога і для когось ні. Наявним прикладом у джава є про temurin у якому це перетворено на запит http://thetechawesomeness.ideasmatter.info/another-approach-for-imports.html;2023-01-09. Але у способі DIY та у таких ситуаціях від 2022-05-14 це досі можливо як вимога IDRU. Тож звідти і така двозначність чи більше.

Але треба пам'ятати про ситуацію з 100% з попереднього оновлення від 2023-02-06 для того щоб залишатися у таких межах. Якщо ні то це точно про такий процес а тоді таких проміжків більше 1 з за цієї двозначності чи більше і нажаль паперово і електроннопоштово клієнтово; http://thetechawesomeness.ideasmatter.info/contradiction-creating-operation.html;2022-02-05; http://thetechawesomeness.ideasmatter.info/table-chapters.html;18 це достатньо повільно до виображення а відтак у динамічних засобів як то у таких додатків і у таких веб місць у цьому є наявна перевага. Тому це й також створює перспективи.

Оновлення від 2023-02-16.

Update as of 2023-02-16.

Чим менше обсяг кода тим менша ймовірність повторень у ньому. Адже і більшість додатків і застосунків і веб сайтів намагаються бути запущеними у якомога більшій кількості місць щодо такої особливості то про Pico Compiler - Java 9 IDE JDK by Marcin Olawski; http://thetechawesomeness.ideasmatter.info/configuring-alternative-compilers-in-macos.html;2022-12-23; http://thetechawesomeness.ideasmatter.info/issues.html;2022-08-31; http://thetechawesomeness.ideasmatter.info/another-approach-for-imports.html;2023-01-21 можливо не лише повторити що це інший тип компіляційного складача але й це й компіляційний складач який більше до DRY. І він цього досягає за допомогою виключення таких складних додатків;complex applications. Але вцілому це можливо і звести до способа функторів у веб тобто функції-як-послуги тобто FAAS. http://thetechawesomeness.ideasmatter.info/freedom-security-privacy.html;2021-10-19. Якщо такий код з нього звіряється з такими FAAS веб послуугами. А цей FAAS спосіб й не є суто WET способом тому що без модерації у них його повторення не виключені і між такими FAAS веб послугами теж. http://thetechawesomeness.ideasmatter.info/messenger-types.html;2023-02-14. Деякі розробники і розробниці називали такі додатки і застосунки і веб місця вірулентними щодо такої особливості щодо такої їх можливості запуска. http://thetechawesomeness.ideasmatter.info/some-virus-control-methods.html. Це схоже й так проте це й також щодо WORADA;ПРВУРУ для них якщо у джава. http://thetechawesomeness.ideasmatter.info/accelerator-of-code-progress.html;2021-05-30.

Тому такий веб сервіс чи така веб послуга як online.net не лише підтримує WORADA;ПРВУРУ а й розширює ці веб місця для запуска для таких застосунків чи додатків чи веб місць. Тобто додає додаткове розташування у веб.

І воно не лише підтримує якісь крізьплатформенні додатки і застосунки і веб сайти а й саме є крізьплатформенним у межах доступних для запуска платформ чи операційних систем.

Також і для черг http://thetechawesomeness.ideasmatter.info/configuring-alternative-compilers-in-macos.html;2021-01-25 навіть якщо їх вміст з самими функторами чи щодо http://thetechawesomeness.ideasmatter.info/messenger-types.html;2023-02-14 адже вони можливі і всередині і крізь зовнішнє ПЗ і крізь такі веб послуги.

Також щодо




проактивна пасивність <-----.------------.---------------------.---------------------------.-...------------->
                              безкоштовні  з                      з                           небезкоштовні
                                           обмеженням для реклами обмеженням щодо часу
     

Оновлення від 2023-02-27.

Update as of 2023-02-27.

Ця табличка про визначники також узагальнюється до одиниць http://thetechawesomeness.ideasmatter.info/table-chapters.html;1. У межах ППіНТВСуІ.

А сам тоукєн у ній вже присутній. Вони не лише один до одного а й один до багатьох. Тому якщо точніше про тоукєн. У лінгвістиці це протиставляється а у МП не протиставляється. Але для МП там відсутньо.

про тоукєни

І у ППіНТВСуІ вони налаштовуємі. Тобто одиниця як тоукєн. Однак усі з http://thetechawesomeness.ideasmatter.info/table-chapters.html;1 для передачі і збереження даних для звертання до них пізніше та тоді і частково ППіНТВСуІ щодо цього і для цього як компіляційний складач для тоукєнів. У межах тоукєнів.

Тобто у одніх межах це


token;тоукєн <-----------> type;тип

а у інших налашатовуєме. Для і щодо функторів у 2023-02-16. І у http://thetechawesomeness.ideasmatter.info/gravitron.html;2022-10-06. Загалом це 2 типа меж.

І це досі про пари чи про дуплети з них.

Достатньо приємною мені там же є сленгова лінкована тобто поєднана рима:

bìscuit and cóokie = bookie.

Й у перекладі цього можливі варіанти наприклад

грінка і печиво; грічиво.

крекер і печиво; кречиво.

а при таких

грейпфрут і печиво; гречиво.

грецький горіх і печиво; гречиво.

ці два нагадують про http://thetechawesomeness.ideasmatter.info/ml-ambiguity.html та про MACOSX_RPATH.

І одразу про достатньо пікантні їх підтипи:

вінігрет і печиво; вінігречиво.

вінейгрет і печиво; вінейгречиво.

Тож про сметанку можливо знайти там же про те що це є крем.

про тоукєни вдруге

А про крем про те який з найкращих. У цих межах. Проте у останнього його межі постачають набагато ширший обсяг у цих межах. Але це буквально чи літерально. Одже і там теж вказано про таку неформальність.

про тоукєни втретє

Оновлення від 2023-02-28.

Update as of 2023-02-28.

Дігітура. Останній гамет.

Та її частина як і у вчорашньому випадку чи прикладі з гречивом для DNS має стосунок як і до обслуговувачів чи обслуговувачок так і до систем. Згідно там же.

Тож ця її частина є клієнт серверною.

Тож тоді відтак ППіНТВСуІ є клієнтом.

Тож ця її частина огортає розподіленість у такий спосіб.

Це є таким дизайном чи архітектурою у ній.

Відтак наявність просунутіших клієнтів для DNS таких як yacy, який є відкритокодовим, та інших є водночас і наявністю інших стилів чи дизайнів у цьому такому дизайні чи у такій архітектурі.

Для тих хто щодо віддаленного віщання тобто telecast чогось як цих веб сторінок, це позначає не лише суто віщання чи його поглинання, а й водночас обидва.

Іронія при цьому полягає у тому що це особливо лише повертає до деяких повідомлювачів. http://thetechawesomeness.ideasmatter.info/messenger-types.html.

Проте їх проблема щодо низької формалізованності та відсутності деякої безконтактності досі не зникла щодо мене.

Тому видизайнезовується видизайнена така


МП <-----------> повідомлювачі

Дігітура у цій її частині якось має з цим допомогти але це лише гамет.

Це щодо такого щодо DNS до асоціативної частини дігітури.

Тож у цьому вона має в наявності цю асоціюючу особливість. http://thetechawesomeness.ideasmatter.info/feature-as-a-dependency.html.

Тому одна частина асоціює а інша складає.

Це щодо інтернет адрес. Звичайно можливо мати текстову назву веб сторінки в наявності.

Проте це з за нерозривності і по-друге якщо у джава то це було б щодо текстоваАдресаВебМісця розширює числоваАдресаВебМісця щодо типів і тобто числова-спочатку. Без числової у сторінки немає вмісту навіть з наявністю тектової.

Тобто це викликано підтипізацією щодо їх ділення і такою їх пов'язаністю дизайново чи архітектурно.

Застосування подібного випадка як з DNS за такого дизайна чи стиля до МП виключено і вже було описано цими веб сторінками.

Якщо згадується в той спосіб а не в інщий то yacy для 1 особливості об'єднує обидві як у цьому випадку щодо DNS.

yacy асоціативно мережево у цій частині дігітури ігнорує цю частину історичну частину інтернета навіть з еволюційними циклами щодо IP в осіай щодо цього випадка з DNS а відтак є і інтерфейсом для нього.

Попри його користувацьку особливість такий інтерфейс у yacy не нагадує про http://thetechawesomeness.ideasmatter.info/hyperprotocol.html тому що він не застосуємий до інших не DNS інтернета однак це нагадує схожістю про випадок з JFra.

Це для веб місць однак для додатків чи застосунків це теж ймовірно застосуємо за наявності там подібного. Однак він і сам є деяким додатком.

Цей випадок щодо DNS як то кажуть вельми показовий.

При його застосуванні до інших фреймворкових каркасів які переважно вже є додатками щоби наблизити їх до чогось накшталт DNS у межах цього випадку їм не вистачає такої асоційованості як у DNS.

Але spring цього як фреймворковий програмний каркас цього вже досяг але процесно і користувацькі. spring.start.io. Не особливістю. http://thetechawesomeness.ideasmatter.info/feature-as-a-dependency.html. Тому це нагадує але цим особливим способом. Тому що не як у дигітури у цій її частині. Залежністю від ППіНТВСуІ для таких користувачів і користувачок цього.

Випадок з DNS є подвійним визначенням а за умови еволюційних циклів і більше. Тобто неоднозначним. А відтак це щодо підтипізації.

Якщо такий інтерфейс jacy є спеціальним тобто особливим то якщо у межах джава йому не вистачає поліглотності якщо jacy код не є у межах джава щоб бути з JFra. Тому у будь якому випадку його приклад додав до JFra. Як і випадок з DNS до додатків а саме фреймворкових програмних каркасів.

Це є виокремлюємим у окрему групу щодо визначень щодо DNS тому що це схоже з випадком щодо http://thetechawesomeness.ideasmatter.info/table-chapters.html;10 з відмінністю про те що там це щодо формату а не системи. Тобто у протокол у якому і система і обслуговувач і обслуговувачка. Про що вже йшлося цими веб сторінками.

Оновлення від 2023-06-24.

Update as of 2023-06-24.

Повторюся про LTS. LTS як особливість при оновленнях як особливість з WET чи інщі такі форки у межах http://thetechawesomeness.ideasmatter.info/consent-with-time-restriction.html чи ні з подальшим слідкуванням за ними чи ні призводить не лише до полегшення для розробників і для розробниць а до створення зразків орфанів у користувачів і у користувачок. Наприклад при http://thetechawesomeness.ideasmatter.info/internet-and-exinternet-and-internetless.html. Це можливо також при помилках саммого ПЗ. Навіть за наявності спільної частини у кожному з форків, лишаються різні тому що це і є форк. Тобто і з за чого він тобто такий форк був створений. Навіть якщо причина і не лише одна з цих наведених двох.

Про них також у 2023-05-15. Тобто у них був якийсь УРР для оновлень а потім ні. Це схоже з частковим відносним УРР. Що також є частиною шляхів. Що також є і визначником. А тому і для цих сутностей теж у цьому випадку.