Back to The tech awesomeness
Table of contents
Endeavor chapters
For these notes, I did not receive any financial benefits, so they are my description of the experiences.
I am using in these notes few words, which I did not find in the sources, which I am usually trusting to, such as unecosystemification, application vendor locking, so I apologize in advance for doing that action, because I did not find the subjectively criterially better alternative ones as of 2020-02-12 17:00.
Even though I held the devices from two ecosystems, Apple Inc. and Google LLC and 80% of those are from Apple Inc. ecosystem, once I counted the numerical amount of devices in pockets, bags and wearable ones, which I actually held at that moment, I ended up with the number of 5 at last.
I placed not an easy key performance indicator(KPI) for myself with such a criterion: not to withdraw them with no return backwards and still leave myself with most of chosen devices from Apple Inc. ecosystem, but at least to minify the wearable and other devices, which I held, at least down till 80%, which will be ideally 5-4=5*(0.2)=5*(100%-80%)=1 wearable, mobile, other type of devices with me later.
Why is that? Because I did not manage to minify the amount of the notifications and other information, which I periodically receive from different devices by changing the settings in these devices and that is why I decided to perform physical device laying on the shelf for some period of time.
So among the devices, such as laptop(mobile device), smart telephones(mobile devices, handheld computers), smart wrist watch(with wearable computer inside), I chose to lay on the shelf for some period of time the smart telephone(mobile device, handheld computer), such as Apple's smart telephone and Apple's smart wrist watch.
The features which relate to sport and medical purposes I substituted partially by another smart telephone's functionality, except the features, which are in provision by using only the hardware sensors in the smart wrist watch itself, so those feature I decided to set aside it for a period of time as well.
I encountered some number of the relatively fun situations when trying to migrate the functionality from the applications by the moving their functional load into the laptop environment.
Then I encountered the relative application vendor lock, when I did not find the option to install the applications other than to operational systems of the Apple smart telephones and Google smart telephones, with no versions for the web browsers, such as Nordea Codes application(for authentication in the mobile bank) and monobank(for internet mobile banking). One of the solutions I found was to install firstly the simulator and then the Emulator(virtual device), in order to try to use those applications outside of only inside the corresponding hardware devices with those mobile devices' operational systems.
When installing the Apple Inc.'s tooling for simulating for iOS operational system to install those relative application vendor lock applications of my choice for performing ecosystem migration, I encountered another situation: there is no existing application in allowance in the application store inside the operational system of the smart telephone in the Simulator, such as there is in the allowance in hardware smart telephone's iOS operational system as of 2020-02-12. So I dropped this idea because of this reason.
The solution I applied next was the composition of Emulator(Android Virtual Device) by Google's ecosystem for launching the emulation of Android operational system and installing and using those application there and it is another option how to migrate from that relative application vendor lock. Why is that? Because the another hardware smart telephone is rather old, so it is not supporting the installation of those applications. There are virtual devices in Google's Android Virtual Device Manager that support Google's Play Store and those which do not support Google's Play Store functionality inside the Emulator(Android Virtual Device).
The biggest mistake I made was the preliminary purchase of the authenication application for laptop's operational system, which provides the functionality for 2FA(multi-factor(two factor) authentication) too much beforehand in advance for laptop's operational system, because later I found later that I had a possibility to launch such functionality also in one of such applications in the Google LLC's Android Emulator(Android Virtual Device) for laptop's operational system.
The connectivity I use are either Wi-Fi and mobile network operator data transfers. There is no various Bluetooth types of area networks and other wireless interface networks in the locality I could use for the usage by laptop solely. Still I did not find the software and the hardware modem (modulator-demodulator) for transfer via 2G, 3G, 4G, GSM/EDGE, UMTS/HSPA, GPRS and other technologies in my current version of the laptop other than in the smart telephones with no usage of external USB-type of devices for that for the laptop, so I did not finish this endeavor with only one device as a result and that is why I finalized this endeavour with two devices instead: mobile laptop for most of the functionality and the mobile smart telephone for my usage of its modem and mobile operator data transfer functionalities and optional usage of mobile phone calling and call receiving functionalities.
So I did not reach 80% value as key performance indicator(KPI) as a result for this endeavor and I ended with 60% value only, and that difference is rather high from the expectant one, so I am eventually putting this difference to the technical debt as an another result of this endeavor.
After this endeavor I also noticed and did not expect the advantage, that from that moment on I started to spend much less time and attention for required software updates and notifications among less amount of mobile devices as their client and as their end user relative to the previous situation.
I would also probably call such endeavor as some type of grooming in this case the grooming of the ecosystem of own electronic devices as the substitute for the partial internal unecosystemification and ecosystem migration.
The update as of 2020-08-07.
The mobile device which contains a free and open-source hosted hypervisor(VirtualBox, KVM, Hyper-V, Docker containers, QEMU, VMware, AWS, Xen, even Vagrant software for choosing between them not only for virtual software development environments and similar software to Vagrant software) for virtualization(x86, x64, RISC, some other architectures which ones are optionally startable in combinations), where there is a possibility to choose operational system(if there is such option to install it into the combination of that specific mobile device and that specific free and open-source hosted hypervisor for virtualization) or several operational systems and to configure the resources for it, such as CPU, telephone service, connectivity services, network virtualization, input output virtualization, interruption virtualization, graphics processing unit virtualization, memory virtualization, other hardware assistance virtualization and other services so that later to switch among or reinstall those operanational systems for mobile device I have not found.
It seems that at the moment for the most locally available mobile devices there is a vendor lock relative to its operational system and mobile device model at least for most local mobile smart telephones. So when I buy mobile device, for example mobile smart telephone, I also bind to the operational system such device contains. So there is no operational system selectivity for me as user for such mobile devives. With allowance in scope of its license. While most of such local devices, as mobile personal computers, mobile laptops, mobile notebooks have such option as operational system selectivity. Same absence of operational system selectivity applies locally for such mobile devices as smart wrist watches, smart spectacles, and smart television sets.
The update as of 2020-11-04.
Frameworkification, unframeworkification and framework migration.
While using @Inject annotation instead of custom annotation help in framework migration, @GetMapping, @Get and @Path and @PostMapping, @Post and @Path are not linearly replacable while there are hundreds of endpoints in API(application programming interface) at least in controllers in mvc in such a relative framework vendor lock and framework vendor unlock.
https://en.wikipedia.org/wiki/Google_Guice
https://en.wikipedia.org/wiki/Spring_Framework
https://en.wikipedia.org/wiki/Comparison_of_web_frameworks
https://en.wikipedia.org/wiki/Jakarta_RESTful_Web_Services
The update as of 2021-01-26.
The closed source is a possible generator of vendor locks. When there is no access to it an absence of for example an exporting of most of the data at once (of various types) (or other options) becomes an ordinary time consumer with no possibility to add it at code or at extensions and a producer of returning to scraping one by one of such data in cost of or benefit to possibly familiar to vendor. For that one the absence of API or similar ones does not improve this one.
At least two cases here: for the data with boundary and for the data with no boundary relatively, from some data stream for example.
So while HTTP has Content Length, with boundary, the amount of such HTTP with Content Length with boundary is unfamiliar for me, especially in some data streams, that is with no boundary.
But of course after I chose closed source for that one, maybe someone had chosen some rating for that to avoid vendor locking. Though there are some open source projects in closed source projects as well. For example this web site at least as of 2021-01-26.
Спроба у частковій внутрішній позаекосистеміфікації та екосистемному переміщенні
Оновлення від 2020-11-04.
Фреймворкова програмна каркасація, фреймворкова програмна позакаркасація та переміщення фреймворкового програмного каркасу.
В той час як використовування @Inject ін'єктивне відображення у формі анотації замість спеціальної анотації допомагає у переміщенні фреймворкового програмного каркасу, @GetMapping асоціація отримання, @Get отримати та @Path шлях як анотації та @PostMapping асоціація опублікування, @Post публікувати та @Path шлях як анотаіцї є не лінійно замінними коли існують сотні точок контакту з веб ресурсами в ППІ (прикладному програмному інтерфесі додатків і застосунків) щонайменш у контролерах у mvc мвк у подібних відносних фреймворковому програмному каркасовому видавницькому замкненні і фреймворковому програмному каркасовому видавницькому відімкненні.
https://uk.wikipedia.org/wiki/Google_Guice
https://uk.wikipedia.org/wiki/Spring_Framework
https://uk.wikipedia.org/wiki/Comparison_of_web_frameworks
https://uk.wikipedia.org/wiki/Jakarta_RESTful_Web_Services
Оновлення від 2021-01-26.
Зачинене джерело з кодом є можливим створювачем ситуацій замкнень виробника. Коли немає доступу до нього то відсутність наприклад діставання більшості даних водночас (різних типів) (чи інших варіантів) стає звичайним споживачем часу з відсутністю можливості додання її з боку кода чи з боку додатку і виробником повернень до збирання таких даних одне за одним коштом чи прибутком імовірно відомим постачальнику. Ах, так, для цього відсутність ППІ API чи інших подібних не покращує цю.
Щонайменш 2 два випадка тут: для даних з межею і для даних з відсутністю межі умовно, з якогось потоку даних наприклад.
Так що поки ГТТП HTTP має Довжину Змісту Content Length, з межею, кількість подібних ГТТП HTTP з Довжинами Змісту Content Length з межею є невідомою мені, особливо у деяких потоках даних, тобто не з межею.
Але звичайно після того як я обрав зачинене джерело з кодом для того, можливо хтось обрав якийсь рейтинг для того щоб уникнути ситуацій замкнень виробника. Хоча існують деякі відчинені джерела проектів у зачинених лдерелах проектів також. Наприклад це місце в інтернеті щонайменш від 2021-01-26. Тобто той рейтинг чи ті подібні рейтинги в тих проектах знаходиться чи знаходяться в закритих джерелах коду. Тобто це подібні ситуації замкнення виробником рейтинга(vendor lock for ratings).
Але можливо ви пригадуєте веб сервіс чи веб послугу у wordpress, де там є такі малюночки і вони з'являються дуже зручно в різних місцях, не лише в wordpress, тож подібна безпечна копія послуги сервісу такої технології але для рейтингів в цьому випадку вирішить цю проблему розділених рейтингів в різних місцях, котрі і невідомо як зібрати в одне місце або перенести, окрім мабуть ну копіювання сторінок чи якось(але ж ще й підписати шоб не змінювати), тобто ситуації замкнення виробником чи виробниками рейтинга. Gravatar. Disqus. Тобто такий що вставляємий(embeddable).
Оновлення від 2021-02-01.
Довгу історію коротенько: контакти і повідомлення теж в ситуації замкнення виробників(another specific type of vendor lock). ППІ чи версії для SAML Security Assertion Markup Language(мова розмітки декларації безпеки) то немає переважно. Або іншої полегшеної міграції переміщення в інший сервіс послугу. Ось вже як декілька років в багатьох сервісах послугах. Причина, можливо, фейхоа. Як гіпотеза. А ось нещодавно була реклама після відкритого початку запуску сервісу послуги: ми не блокуємо контакти; і рейтинг популярність сервісу послуги зросла і більше користувачів. Пізніше: контакти можуть бути блоковані. Причина, можливо, теж фейхоа. А контакти то блоковані і непереміщаємі для мене як користувача. І що там з рейтингом популярністю такого сервісу послуги. Але то оте замкнення тих контактів і повідомлень нікуди не зникло. Тож чи заново додавати ті контакти і ті повідомлення в новий, інший сервіс послугу чи ні мені як користувачу. Чи заново додавати їх в новий запис в новий акаунт запис того самого сервісу послуги чи ні мені як користувачу. Бо можливості умовно їх легкого переміщення в інший подібний сервіс послугу немає, воно відсутнє, чи це позначає що я буду витрачати свій час для їх переміщення. Невже маленьке фейхоа стримує таку можливість як умовно легке переміщення контактів чи повідомлень між сервісами послугами чи створення ППІ(чи версії для SAML Security Assertion Markup Language(мова розмітки декларації безпеки)) для легкого їх переміщення між сервісами послугами вже декілька років. І ще і витрачає час користувача на відновлення контактів і повідомлень в тому самому чи іншому сервісі у випадку блокування. Сумнівно.
Оновлення від 2021-08-14.
The update as of 2021-08-14.
🦖.🦕. Мені може стати справді олдс' кульно знайти, де саме зберігаються мої дані з переміщеннями мурашок, а також мої дані про серії з переміщеннями мурашок чи то в загадкових хмарах чи в таємничих "хмарах" даних на землі чи десь ще, якщо та можлива дистанція, можлива відстань, можлива віддаль зростатиме. І також послугах і інших на них.
Оновлення від 2021-10-12.
The update as of 2021-10-12.
Поки більші оголосили про платежі щоб покращити один з аспектів відкрито кодових з невідомої причини, для контрасту в джава java, котра точно відрізняється від продуктів більших, але теж достатньо вікрито кодова хоча б можливо її окремі частини, а де деякі були закрито кодовими і до яких на додачу додалися відкрито кодові, у відповідь для тих аргументів, котрі про те, що вона стара або для гіків, що якщо деякі неджава non java продукти навіть закрито кодові мають вбудовані скрипти або сценарії наприклад для автоматизації, то джава java теж. Однією з відмінностей є для цього й для них той процес у джава java і в тих продуктах.
Оновлення від 2021-11-15.
The update as of 2021-11-15.
В типі автоматизованого рахування кількості об'єктів існує 2 ситуації. В одній ця кількість незмінна. В інщій вона змінюється.
Тобто в них можливо присутнє якесь переміщення чи якийсь рух чи ні.
Якщо для обробки обох випадків використовується якийсь *мулятор то він має встигати замапіти об'єкти тобто з'єднати ці об'єкти з якимись своїми варіаціями як їх віртуальних копій для себе перед їх обробкою наприклад перед рахуванням тобто тоді в такому способі буде присутнє якесь відтермінування незважаючи щодо того чи присутня надалі зупинка у якомусь способі для їх порахування чи ні.
Так що це також і про кількість об'єктів у проміжку часу під час їх обробки а саме під час їх підрахунку, а саме про їх змінність або незміність у цей проміжок часу у самому випадку незважаючи щодо того який саме спосіб використовуватметься для цього.
Оновлення від 2021-12-15.
The update as of 2021-12-15.
Ця публікація від 2021-12-14 https://forum.palemoon.org/viewtopic.php?f=5&t=27682 окрім її точок також нагадала наскільки різноманітна екосистема розширень у ППіНТВСуІ і чому я не почав застосовувати чи використовувати розширення широко, тому що вони були не переміщаємі між принаймні б 2 такими ППіНТВСуІ тобто не крізьплатформенні, якщо вважати кожну одну таку ППіНТВСуІ а всі їх тобто як платформу. А значить вони ведуть при використанні якимись ППіНТВСуІ до замкнення постачальника. Можливо це змінювали, мені це невідомо. Але також вона нагадала що існує принаймні 2 типа ППіНТВСуІ, які слідкують і збирають дані про такий перегляд і не лише сторінок в інтернет і шлють їх кудись не дуже помітно і які ні. Щоб уминути утримання це як потребу знати про це є часткове легке рішення перейменуванням такої ППіНТВСуІ з доданням позначки про цю особливість. Часткове тому що хоча це й буде помітно перед кожним запуском такої ППіНТВСуІ, є шанси що через невідомий проміжок часу наступною цікавою веб сторінкою це забудеться як всередині це не дуже помітно і не має про це позначки. Але щодо цієї особливості у деяких інших перемикачевих системах теж є такі які слідкують і збирають дані про такий перегляд і не лише сторінок в інтернет і шлють їх кудись не дуже помітно і які ні. Там це часткове рішення не застосовуєме бо наприклад немає такого елемента для перейменування. Але можливо є чим намалювати таку позначку проте таке часткове рішення набагато повільніше щодо оновлень такої позначки наприклад перед повторним запуском для їх актуального утримання.
Але є й одна нетипова ситуація там. moonbat зазначив, що "One hosts to look them up, one DNS to find them and in the darkness BIND them." Тож як то кажуть це компіляційно складається принаймні на моїй машині, залишається невідомим чи це приказка чи це загадка чи щось інше. Я переклав це як хтось чи щось розміщає їх щоби шукати, один ДіЕнЕс DNS щоби знаходити їх і за відсутності світла з'єднати їх. Припустимо що це приховано про веб ресурси. Але веб ресурсів а саме їх типів стало набагато більше після появи ДіЕнЕс DNS, наприклад ті ж блокчейн веб ресурси, які доступні лише в спеціальних ППіНТВСуІ, або ті ШРкоди та подібні та інщі. Тож якщо пошукати у сховищах кода таких як github.com і подібних, можливо знайти цілий шар: а саме цілий шар проектів, які підтримують й у тому числі й умовне компіляційне складання тієї фрази принаймні на моїй машині. Тобто у тих сховищах є присутнім хоча й можливо відкрито кодових цілий шар проектів з прихованою назвою їх категорії які підтримують таку особливість для ДіЕнЕс DNS. Що з іншої точки перспективи є екосистемою для ДіЕнЕс DNS і є співмірною з екосистемою розширень для ППіНТВСуІ у деяких межах порівняння. Чому прихований. І чому шар. Тому що в них ні слова може й не бути про ДіЕнЕс DNS. Тому що їх багато. Тому що в них ні слова може й не бути про веб ресурси. А якщо не пошукати тоді не знайти тобто НОП.
Але адже цей приклад тих додаткових типів веб ресурсів є і фактом того що веб зріс після появи ДіЕнЕс DNS, і підтверженням того що він вміє зростати, тож не виключено що існує саме зараз чи саме щойно десь частина веб або точніше можлива частина веб у якій є й інщі подібні веб ресурси такої екосистеми. Бо такі додаткові типи веб ресурсів могли бути створені як у веб так і поза ним а потім пізніше доєднані. Наприклад простим прикладом WLAN не доєднаного до веб з такими додатковими типами веб ресурсів. Це також і про інтернет і про дигітуру. Хоча це і видається логічним, однак не виключено що такий WLAN з подібними додатковими типами веб ресурсів, тобто як мережа, а точніше їх множина будуть доєднуватися одна до одної і не будуть доєднуватися до існуючого інтернету мереж, тобто існуючи паралельно, що створить можливість існуючому інтернету мереж доєднаєтися до таких доєднаних WLAN. Чи інших доєднаних типів мереж.
Оновлення від 2022-02-10.
The update as of 2022-02-10.
Деякий веб клієнт наприклад клієнт 89345893489348 після запиту до обслуговувачки наприклад обслуговувачки 1, отримав що та приймає дані у форматі наприклад формат 1 та формат 47837843474378, клієнту 89345893489348 недоступний формат 47837843474378 як і формат 47837843474378 і обслуговувачка 1 закритокодові. Клієнт 89345893489348 після запиту до обслуговувача 2 отримував дані про те що обслуговувач 2 надавав дані у форматі 1 але зупинив підтримку деякої мережі наприклад мережі 1 з невідомої причини але почав натомість надавати дані у деякій іншій мережі з підтримкої у мережі 2 але у неприватному режимі і в цілому після запиту тимчасово не надав послугу даних навіть через ту мережу 2 з невідомої причини. Тож обслуговувач 2 у цій ситуації повністю не надав послугу не через мережу 1 не через мережу 2 з невідомої причини щодо обох мереж. З за цього клієнт 89345893489348 не отримав дані і йому недоступне звертання до мережі 3 теж закритокодової яка у до обслуговувача 3 теж закритокодового без застосування ПрНайбС особливості чи декількох. Хоча і обслуговувачка 1 і обслуговувач 2 можуть знаходитися на відстані чи на віддалі декількох сотень метрів що в цьому випадку нагадує про обраний пріорітет приватності чи іншого над обслуговуванням у даному випадку. Адже це невперше бо як помітно у імпрессумі ці сторінки переміщалися між обслуговувачами не двічі і адже подібне повторилося це вказує на якусь діру чи gap яку отримав клієнт 89345893489348 тому що з невідомих причин це призвело до неможливості обміну даних без застосування ПрНайбС особливості чи декількох а значить десь сталася помилка чи більше або щось інше що невідомо чи уминаєме але з невідомих причин щодо закритокодових обслуговувача чи обслуговувачки внаслідок таких вимог чи обмежень але до якої клієнт 89345893489348 не дістанеться без застосування ПрНайбС особливості чи декількох. Інакше клієнт 89345893489348 застосовуючи ПрНайбС особливість чи декілька ще раз буде розташований у більшій кількості мереж до чого призвели неминуча залежність обміну даними у клієнт обслуговуючих архітектурах та відмова або несподіване для клієнта зупинення надання підтримки однієї мережі і натомість надання підтримці інщій мережі що більше нагадує ПрНайбС а у такому випадку і також її ненадання з невідомих причин але що є тимчасовим наразі. Тобто такі вимоги чи обмеження закритокодових обслуговувачів і обслуговувачок також призводять до збільшення кількості обміну даними через додаткові мережі для такого веб клієнта чи веб клієнтки й не лише через клієнтсерверні архітектури щоб уникнути цих помилок чи більше або щось іншого що невідомо чи уминаємого але з невідомих причин якщо такі мережі доступні збільшуючи на них навантаження з за невідомих причин щоби уминути застосування їх ПрНайбС особливостей. Тож щоб такому клієнту 89345893489348 уникнути застосування таких ПрНайбС особливостей подібно ймовірно застосованому ПрНайбС у цьому випадку попередньо достатньо використати чи застосувати типову особливість обслуговувачів і обслуговувачок а саме почекати незважаючи щодо невідомих причин цьому випадку внаслідок їх закритокодовості.
Оновлення від 2022-09-11.
The update as of 2022-09-11.
http://thetechawesomeness.ideasmatter.info/dry-and-wet-and-null.html http://thetechawesomeness.ideasmatter.info/impex-between-atlassian-jira-and-apple-calendar.html http://thetechawesomeness.ideasmatter.info/eliminating-technical-debt.html http://thetechawesomeness.ideasmatter.info/part-recomposer.html http://thetechawesomeness.ideasmatter.info/gravitron.html;2022-09-06 http://thetechawesomeness.ideasmatter.info/table-chapters.html;2
An ecosystem of distributeeexchangees with user and/or distributeeexchangee's data fully or partially; екосистема дістріб'ютіексчейнджі з користувацькими чи/та власними тобто розробницькими дістріб'ютіексчейнджі даними у ньому частково чи повністю:
with vendor lock;з замкненням виробника чи виробниці
vendor lockless;без такого замкнення
з наявністю конвертера чи перетворювача для таких даних між такими екосистемами чи їх дістріб'ютіексчейнджі
;with data converters for such ecosystems or their distributeeexchangees
без таких;without such ones
http://thetechawesomeness.ideasmatter.info/table-chapters.html;30.
Оновлення від 2023-03-14.
The update as of 2023-03-14.
http://thetechawesomeness.ideasmatter.info/eliminating-technical-debt.html;2022-08-29.
http://thetechawesomeness.ideasmatter.info/mvc.html;2022-03-12.
Або у ІСР завдяки цьому способу http://thetechawesomeness.ideasmatter.info/summation.html;2022-04-28 або без нього а інакше такий DTO після виокремлення інтерфейса й стає схожою рисою у такому додатку чи застосунку.