Back to The tech awesomeness
Table of contents
Java chapters
import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;
public class MultiplicationOfZeroIntegersShouldReturnZeroTest {
@Test
public void multiplicationOfZeroIntegersShouldReturnZero() {
MultiplicationOfZeroIntegersShouldReturnZero tester = new MultiplicationOfZeroIntegersShouldReturnZero(); // MultiplicationOfZeroIntegersShouldReturnZero class for testing
// assert statements
assertEquals(0, tester.multiply(10, 0), "10 x 0 must be 0");
assertEquals(0, tester.multiply(0, 10), "0 x 10 must be 0");
assertEquals(0, tester.multiply(0, 0), "0 x 0 must be 0");
}
}
public class MultiplicationOfZeroIntegersShouldReturnZeroTestTest {
@Test
public void multiplicationOfZeroIntegersShouldReturnZeroTest() {
MultiplicationOfZeroIntegersShouldReturnZeroTest tester = new MultiplicationOfZeroIntegersShouldReturnZeroTest(); // MultiplicationOfZeroIntegersShouldReturnZeroTest for testing
tester.multiplicationOfZeroIntegersShouldReturnZero();
//assertEquals//...
}
}
public class MultiplicationOfZeroIntegersShouldReturnZeroTestTestTest {
@Test
public void multiplicationOfZeroIntegersShouldReturnZeroTestTest() {
MultiplicationOfZeroIntegersShouldReturnZeroTestTest tester = new MultiplicationOfZeroIntegersShouldReturnZeroTestTest(); // MultiplicationOfZeroIntegersShouldReturnZeroTestTest for testing
tester.multiplicationOfZeroIntegersShouldReturnZeroTest();
//assertEquals//...
}
}
public class MultiplicationOfZeroIntegersShouldReturnZeroTestPower5 {
@Test
public void multiplicationOfZeroIntegersShouldReturnZeroTestPower4() {
MultiplicationOfZeroIntegersShouldReturnZeroTestPower4 tester = new MultiplicationOfZeroIntegersShouldReturnZeroTestPower4(); // MultiplicationOfZeroIntegersShouldReturnZeroTestPower4 for testing
tester.multiplicationOfZeroIntegersShouldReturnZeroTestPower3();
//assertEquals//...
}
}
public class MultiplicationOfZeroIntegersShouldReturnZeroTestPowerN {
@Test
public void multiplicationOfZeroIntegersShouldReturnZeroTestPowerNMinus1() {
MultiplicationOfZeroIntegersShouldReturnZeroTestPowerNMinus1 tester = new MultiplicationOfZeroIntegersShouldReturnZeroTestPowerNMinus1(); // MultiplicationOfZeroIntegersShouldReturnZeroTestPowerNMinus1 for testing
tester.multiplicationOfZeroIntegersShouldReturnZeroTestPowerNMinus2();
//assertEquals//...
}
}
Оновлення від 2021-11-08.
The update as of 2021-11-08.
//..
if (notInteractiveMode && failFastMode && nonAutomatedMode) {
for(App app: apps) {
if (!whiteListOfAppVersions.contains( app.getVersion() )) {
output(whiteListOfAppVersions.getMessageWithConsequencesIfAvailableFor(app));
output(whiteListOfAppVersions.getMessageWithNonAutomatableWorkaroundStepsIfAvailableFor(app));//for example to hide a variable with value from storage of such tuples
} else {/*continue;*/}
}
} else {/*NOP.*/}
//..
//..
якщо (неІнтерактивнийРежим && швидкоЗупиннийРежим && неАвтоматизованийРежим) {
для(Додатка додатка: вДодатках) {
якщо (!білийПерелікДодатковихВерсій.включає( додатка.отриматиВерсію() )) {
видати(білийПерелікДодатковихВерсій.отриматиПовідомленняЗНаслідкамиЯкщоІснуєДля(додатка));
видати(білийПерелікДодатковихВерсій.отриматиПовідомленняЗНеавтоматизуємимОбходовимиКрокамиЯкщоІснуєДля(додатка));//наприклад сховати змінну зі значенням зі сховища з подібними парами
} інакше {/*продовжити;*/}
}
} інакше {/*ноп.*/}
//..
Оновлення від 2021-12-07.
The update as of 2021-12-07.
Про часто повторювані.
git clone ..
mvn install
git pull ..
..
git pull ..
..
//if ..
// for..
І це в такий спосіб пропонується більшістю проектів лише у ручному режимі, без альтернативно і без опціонально і без варіантів, залишаючи це наступним розробникам і розробницям, не надаючи при цьому якоїсь автоматизації такому рутинному повторюванню особливо для компіляційно повторно складаємих проектів й не лише для інтерпретованих. Тож з crontab чи інщим, але це залишається для розробників і розробниць, знову ж таки як вже було зазначено на цих сторінках наприклад від 2021-11-06 створюючи різноманітні версії скриптових автоматизацій для тієї самої автоматизації для кожного окремого проекта з невідомої причини у незакритокодових проектах. Така виключенність призводить до збільшенного рутинного повторюваного введення того самого з відсутністю додаткового функціонального навантаження.
Оновлення від 2022-01-22.
The update as of 2022-01-22.
Обидва перегляд і не лише кода і тестування є зусиллями серед інших з впровадження, покращення та підтримування сталості високоякісного кода. Особливо для відкритого коду і більше адже він не має невидимості як закритий код.
Both code reviews and testing are efforts among others of establishing, improving and maintaining code staticity of high quality code. Particualrly for open source and above as long as they does not have invisibility as closed source code.
Тому і зручно використовувати переглянуті і тестовані фреймворкові програмні каркаси для проектів хоча це і створює залежність тому що багато коду не лише вже існує а й після тесту й після перегляда кода які значно зменшують кількість помилок і надають більше особливостей. Щоби повторити однак наразі досі присутня подібна ситуація.
|App1|.|Gap2|.|AppN| |App1|.|Gap2|.|AppN|
. .
____________ ___________ _______________
Framework1 . Gap1 . FrameworkN
____________ ___________ _______________
. .
... ...
That gap1 is merely an absence of JFrA, JFA or alike which causes also code staticity along with vendor locks which is solvable by code migrations if any and if likeable though still rare. Also by code porting as already mentioned in these pages. Also possibly by applying ArchUnit, PMD and alike but no occurences found at that scope if feasible at all because one of the approaches is a snapshot like due to code changeability at that level. Preferentially it is still solvable by for example extraction of pretty nifty module structure of spring framework which is already existing under certain circumstances for next frameworks if not for others in that scope. Basically it is for the same traits of frameworks still leaving empty implementations for absent modules in some ones and leaving implementation specific ones id absent in spring framework otherwise. At least as well also Quarkus framework has a publication for unidirectional migration from spring framework into it. Such similar one is already present for easy substituion and for easy replacement for example of some application servers again in spring framework and again under certain circumstances. Thus stalling and decelerating architectural and design changes there but creating vendor lock or by creating vendor lock unlike spring fraamework under those certain circumstances.
Інша про gap2 це повторюваність коду у додатках і застосунках використувуючих такі фреймворкові програмні каркаси і як наслідок повторюваність такого коду для таких особливостей.
The reduction of such code repetitiveness of such code one by one sequentially without JFrA, JFA or alike would be mundane if not routine and repetitive.
Оновлення від 2022-01-24.
The update as of 2022-01-24.
Але якщо ви не за жодний spring framework чи Quarkus для того, наприклад з за імовірності їх можливого застарівання або не за жодний подібний з існуючих особливо у випадку для наступного фреймворкового каркасу або для JFrA, JFA чи подібного то інакше преференційно також можливо зібрати усі pom.xml, gradle.build і подібні доступні у деякій місцевості і звичайно у віртуальній такій і зробити вибірку тих залежностей наявних у них якимось преференційним запитом щоб отримати іншу подібно тієї структуру згідно них і того преференційного запиту. Наприклад за допомогою JPA Criterion API. Повторюючи це з деякою періодичністю не виключено що така структура змінюватиметься якщо змінюватимуться ті зібрані усі pom.xml, gradle.build і подібні доступні у деякій місцевості і звичайно у віртуальній такій.
Але якщо такі зібрані дані не включають дані про відкритість коду і про покриття тестуванням та переглядами і не лише коду то такий спосіб для такого наступного фреймворкового програмного каркасу чи JFrA, JFA чи подібного може бути щонайбільш полуавтоматичним тому що ті дані доведеться збирати власноруч для кожної такої залежності тобто рутинно що повільніше ніж інакше. Тобто дані про такі властивості про такі особливості залежностей у таких зібраних даних є щонайменш бажаними для прискорення їх обробки для подібного випадку.
Оновлення від 2022-02-13.
The update as of 2022-02-13.
Переносячи від 2022-02-12 про decentralized application;dApp;dapp;DApp;Dapp;децентралізований застосунок до попередньої схемки.
|dApp| . |smart contract| . |dApp|
. .
|App1|.|Gap2|.|AppN| |App1|.|Gap2|.|AppN|
. .
____________ ___________ _______________
Framework1 . Gap1 . FrameworkN
____________ ___________ _______________
. .
... ...
Тож з такої перспективи ті smart contract нагадують як раз виконання того що відсутньо рівнем фреймворкових програмних каркасів чи є у використанні такі фреймворкові програмні каркаси децентралізованими застосунками чи ні. Тобто нагадує як аналог того рівня для обміну даних.
Оновлення від 2022-05-12.
The update as of 2022-05-12.
Java provides an opportunity for a specific type of testing. It is for searching of runtime issues. Which are not visible during compilations unless not syntactic ones. There are a lot about NPE and runtime unchecked exception on those ones available in the web. But there are more in this class or for such type. Some parameter was not set for a query, an SQL one, by .setParameter( and it is also findable in runtime but not before it by compilation. While it was expected by execution flow then. It is also a developer issue, which is sharable with Java, so there are features and so on, which provide such opportunity and such ones which are not. Also a bit in a line with that more complex one which is inside the edges of three domains as of in http://thetechawesomeness.ideasmatter.info/summation.html as of 2022-04-17 about empty and other ones.
Maybe there are solutions for that one via OSGI or antlr or alike in runtime, or via static code analysis tool as pre runtime solution by a plugin or by an extension, but this type for testing is about a type of cohesiveness of such features and so on, which is visible only in runtime or possibly by those approaches.
Оновлення від 2022-05-19.
The update as of 2022-05-19.
There are so many reports on available bypassability and arbitrary code executions in one of the trigerral systems recently. Will it be another additional test for bypassability or another set of patch fixes ?
So each message has a direction upon its sending. At least one. But.. if you try not to track or to anonymize, it is merely a hidden technical detail. That one is for gameability as of yesterday . There are more sometimes. Some of them are testable at least in two different plaaces for this direction which is in a link with double confirmation also in: http://thetechawesomeness.ideasmatter.info/cases-for-rather-immutable-distributable-storage.html and http://thetechawesomeness.ideasmatter.info/mobile-food.html.
And here http://www.sormula.org/example-schema it shows
import org.sormula.annotation.Column;
and here https://stackoverflow.com/questions/41733010/hibernate-column-annotation-not-work it shows
import javax.persistence.Column;
even though the latter one already uses JPA, so a converter for them between them in this case is inevitable, because they are already there by design.
In a situation with MACOSX_RPATH a resolver is required .
команда
повторення
запуск середовища програмування мови програмування R
інший такий псевдонім чи інша така функція
Until its application it is a set of variables, after it is resolved it is a one of a set of variables.
A situation with MACOSX_RPATH with an available resolver in turn is an instance of a type of resolvee.
And after series of iterations of repetitions as long as there is some correlation with http://thetechawesomeness.ideasmatter.info/internet-and-exinternet-and-internetless.html;2022-04-26 this situation is nothing more than a questionable one.
Also this approach and foremostly its tool or/and another one such tool increased partiality of a vendor lock as a dependency for that part of applications in that ecosystem .
Оновлення від 2022-05-22.
The update as of 2022-05-22.
Though in digiture for those questionable ones after requesting and receiving there are several options mostly other than to avoid if not with some type of identifiers :
resolve
режим імперсонації
resolve anonymously
non communicado mode
As long as it is impossible to resolve anonymously such one with a link or URL which contains a personal identifier, there is a natural dichotomy there.
Which is sometimes resolvable with http://thetechawesomeness.ideasmatter.info/consent-with-time-restriction.html. If applicable to http://thetechawesomeness.ideasmatter.info/ductible-wireless.html. But that update is also about joinability of those ones with and without for example such limitation .
The update as of 2022-05-26.
Оновлення від 2022-05-26.
In Apache maven in some situations there is message similar to Unknown host ... : nodename nor servname provided, or not known which happens also when there is no available internet connection which is one of these ones which is similar to not known one from that message. There are 6 options here in this situation. In this situation after resolution, it does not respond in a by default mode with some HTTP code .
The update as of 2022-06-15.
Оновлення від 2022-06-15.
На відміну від інтерпретованих мов програмування хоча ймовірно у них і швидше і гнучкіше ніж у у компіляційно складаємих у компіляційно складаємих за наявності тестування не потрібно повторенно перевіряти і тестувати ті дані які вони складають, принаймні якщо такі дані самі не усередині або як у від 2021-03-03 або якщо нема після перетину тих даних до інших не компіляційно складаємих частин як достатньо розповсюджено за конфігурації чи дизайну між наприклад задніми і передніми частинами додатків і застосунків тобто щодо клієнт серверних. Тобто якщо відсутня зміна середовища для тих даних і якщо вони не самодостатні тобто не усередині такого додатка чи застосунка. А також якщо застосовані версії таких складачів є перевірено надійними. При цьому мені невідомі альтернативи такій перевірці таких складачів без перегляду і не лише їх коду окрім їх переліків зі збереженням. При цьому після появи TypeScript і подібних, вони мають для такого перевагу над деякими іншими. Або ж інщі мають таку недостатність лише у такому випадку. Тобто у такій розробці з таким тестуванням це створює постійну потребу наявності тестування з переглядом і не лише їх кода або ж розробки з переглядом і не лише їх кода що у свою чергу не сприяє http://thetechawesomeness.ideasmatter.info/accelerator-of-code-progress.html.
But if some of A-1 is also not only more secure than some of A1 for example of JavaScript which is provided in browsers and is mostly hidden from users, but also a minimal one. Але тоді це повертає до товстих і тонких клієнтів, >один з яких. А окрім того що їх принаймні два, то і якщо і можливі до налаштування то налаштовуються вони як і фреймворкові програмні каркаси по-різному. Тобто можлива найвність у них класа як то:
клас ОсобливістьЯкРежим {/*...*/}
який теж якимось з тих налаштувань виставлений як то exposed чи ні.
Наприклад деякі класи і методи включають компіляційно складаєму валідацію або assertion перевірки, тому перевіряти такє зайвий раз було би повторенно якщо не інакше як у цій веб сторінці. Тому деяким фреймворковим каркасам для тестування невідомо про такє і деякі з них як одним способом включають можливість виключення таких принаймні класів у своїх налаштуваннях принаймні у деяких версіях щоби уминути такого повторення при кожному компіляційному складанню після цього.
У оновленні від 2022-01-17 спільною точкою є як код між версіями так і у копіях є підв'язка. Тож це натякає щодо опціональності але також і щодо опціональної наявності у продуктах підв'язування при подібній розробці як і поряд з тестуванням при наявності принаймні однієї з цих двох у них особливостей як то зворотня сумісність чи одночасні оновлення.
Поки ті між А-1 і А2 не об'єднані, однією з переваг є гнучкість для кожної з них, а для додатків і застосунків недоліком є деяке повторення кода. Наприклад якщо присутні декілька таких клієнтів у одному такому додатку чи у одному такому застосунку з за їх різних особливостей. Також при цьому ймовірне повторення кода як для самих А-1 і А2 так і для кінцевих додатків і застосунків. Тобто замість наприклад додаткових унікальних особливостей або їх більшого різноманіття у таких додатках і застосунках це буде замість того щодо такого повторення кода або іншого повторення неунікального для збереження попередньо означених деяких з переваг такого способа у такому випадку. І як додатковою перевагою при такій необ'єднанності лише для наступних досі неіснуючих додатків і застосунків є обрання з початку його розробки саме такого між А-1 і А2 з незайвою кількістю особливостей які сумісні саме для нього. Існуючі додатки і застосунки при цьому не мають такої переваги і при цьому тоді наприклад можливі бути сприяні пристосуванням інщих між А-1 і А2 за цих таких обставин для додання тих інших особливостей. При цьому такий спосіб можливо зменшує кількість самих додатків і застосунків і інших які можливі повторені не щодо особливості чи особливостей а достатньо вцілому як у випадку з 2021-03-03 але без використання наприклад переліків тобто є третім чи черговим для такого і при такому застосуванні. А тобто і дещо децентралізованим на відміну від перелікового способа але теж з використанням дещо більшої кількості залежностей на відміну від 2021-03-03 способу. http://thetechawesomeness.ideasmatter.info/single-extensibility-principle-and-cyclic-inheritance.html.
Що можливо дещо слабо пов'язано при деякому застосуванні з деякою ситуацією як з ШРкодами.