Хорошо… Раз сейчас происходит абсолютно то же самое наследование багов (с добавлением щепотки своих) и наплевательство на стандарты, то чем тогда плох переход на единую платформу? — В этом случае хотя бы новые баги не будут появляться, при попытке скопировать баги чужие…
Сохранение багов ради обратной совместимости? — Это да, это перспектива плачевная. Но тем не менее, выше в комментариях уже писали на примере того же Хрома и Сафари, когда какой-то баг есть только у одного из них.
Взглянем на потенциальную проблему с другой стороны (допустим, переход на WebKit состоялся, кроме старого доброго IE — чтобы перешёл он нужно, наверное, второе пришествие): есть куча браузеров, которые реализуют, например, 95% рекомендаций HTML6 и CSS4, а напротив них есть семейство IE, которое только-только осилило HTML5 и CSS3… Что останется делать MS? — Правильно, догонять и перегонять.
На мой взгляд, конкуренция сохранится до тех пор, пока существуют хотя бы 2 базы для браузеров. И конкуренция эта будет тем ожесточенней, чем более крупные игроки будут выступать с обеих сторон.
А конкуренция эта будет в любом случае, потому что это деньги. Даже если все вообще браузеры перейдут на базу WebKit — конкуренция останется, только перейдёт на другой уровень и развитие пойдёт уже в рамках надстроек/модулей/фишек в реализациях браузеров от конкретных вендоров.
Если я правильно понял статью (поправьте, если нет), то суть её сводится следующему: отсутствие конкуренции и наследование багов ради обратной совместимости, тотальная слежка за всеми и пресечение инноваций. Вот этого, на мой взгляд, точно не будет, потому что крупные игроки никогда на пойдут на то, чтобы быть равными — для выживания в бизнесе необходимо развитие, а без конкуренции в развитии нет смысла.
Разве моё преувеличение сильнее, чем преувеличение и теория заговора в статье?
Почему-то на ум пришла аналогия, как когда-то, во времена готичного черного доса, в коде было необходимо поддерживать тонну разнообразного железа, чтобы всё работало адекватно на разнородных системах. Потом пришли DirectX и OpenGL+OpenAL. Развитие технологий не остановилось.
Когда-то, во времена, когда компьютеры были большими, каждый процессор имел свой набор инструкций. Потом пришёл 8086 и началась эпоха x86. Развитие технологий не остановилось.
Когда-то, давным давно не было IBM-совместимых компьютеров…
С оглядкой на эти истории у меня возникает резонный вопрос: почему же переход на WebKit сулит нам стагнацию в развитии веб-технологий и пахнет катастрофой?
Не очередной ли это виток закономерного развития, когда куча разрозненных и обособленных разработок, а так же компаний, которые эти самые разработки поддерживают, объединяются и общими усилиями начинают двигаться в ОДНОМ направлении вместе?
Как мне кажется, преувеличение в этой статье, вкупе с теорией заговоров, гораздо более спекулятивное, чем мой пример с перегнутой палкой в CSS (зато ярко).
В конце-концов, WebKit — проект открытый.
Не нравятся варианты, которые предлагают вендоры? — Возьми, да собери свой. И собери его не с нуля, а с использованием тонны кода высококвалифицированных разработчиков от крупных вендоров, которые этот проект поддерживают.
Нравятся варианты, которые предлагают вендоры, но чего-то нехватает? — Собери свой с нужным функционалом. В качестве примера могу привести проект Роджера Вонга, который взял WebKit и привинтил к нему Node.js: github.com/rogerwang/node-webkit
Если же обнаруживается какой-то баг в WebKit с отступлением от стандартов до какой-то определенной версии — задаём условие в init.js:
function getWebKitVersion(){
var version = 0;
var regexp = /Safari\/([\d.]+)/;
var result = regexp.exec(navigator.userAgent);
if(result) {
version = parseFloat(result[1]);
}
return version;
}
$( document ).ready(function(){
if ( getWebKitVersion() < 537.17 ){
var ss = document.createElement( "link" );
ss.type = "text/css";
ss.rel = "stylesheet";
ss.href = "537_17_hack.css";
document.getElementsByTagName( "head" )[0].appendChild( ss );
}
});
Всё. Проблемы нет. Код проще. Код понятнее. Поправили багу в вебките? — Хак не подгрузился и всё.
Если я не прав — пинайте ногами, но… Переход на WebKit — это благо для цивилизации. К тому же, то, что WebKit будет использоваться в качестве базы, совершенно не отменяет того, что в каждом конкретном браузере будут собственные уникальные фичи. Пример с Сафари и Хромом — в хроме по-дефолту WebGL включен, в Сафари — нет. Оба на базе WebKit.
Мне, например, гораздо проще и удобнее учиться именно по справочнику по принципу «есть задача — сломай голову, но найди решение». Изучая что-то по справочнику, волей не волей, в процессе поиска нужной информации, захватываешь попутно ещё целую гору материала, прямо не относящегося к конкретной функции или методу, которые помогут решить текущую задачу, но так или иначе откладывающегося в закромах памяти.
Раз за разом бегая таким образом по справочнику, рано или поздно, но автоматически изучишь возможности нужной библиотеки/фреймворка/класса. Конечно, если только не требуется обширная теоретическая база (как для веб-программера, который всю жизнь использовал только jQuery и только для анимации UI, а тут ему вдруг взбрендило написать демку на WebGL и чистом JS :)
Книги, в отличие от справочников, как правило, несут с собой приличный объем воды. Алгоритмы? — Алгоритмы везде одинаковые: либо ты умеешь их составлять, либо нет и книги тут, как мне кажется, играют слабую роль.
Жаль только, что принцип изучения по справочнику не подходит для освоения новых ЯП: тут, как ни крути, необходимо знать особенности изучаемых языков — справочник не поможет и книги тут действительно необходимы. Но Node.js, как мне кажется, всё же не из этой оперы.
По теме топика: node-webkit великая вещь! В несколько кликов портировал свою демку:
Three.js + Node-Webkit + batch to exe converter
Сейчас вынашиваю коварные планы по написанию простенького гейм-движка на базе Three.js, tQuery, Physijs и Node-Webkit. Надеюсь, что-нибудь из этого получится. :)
Никогда особо не вчитывался в различные рекомендации по оформлению кода, но для себя вывел примерно следующую схему:
THIS_IS_CONST
thisIsVar
ThisIsFucntion (или f_ThisIsFucntion — если много функционального кода)
CThisIsClass (или c_ThisIsClass)
Работаю как раз в основном именно с этими двумя движками (MODx и Битрикс) и сталкивался в работе только с переездом MODx -> Bitrix.
В силу этого обстоятельства сейчас возник профессиональный интерес: чем клиент мотивировал переезд Bitrix -> MODx? Если это не коммерческая тайна, конечно же.
Как по мне, так оно может «взлететь» (в смысле «выстрелить», в смысле «сработать»), если некоторые элементы изменить/заменить:
1) Вместо водорода — гелий; — не взрывоопасно, но нужен больший объём.
2) Толстые тросы из кевлара; — для удержания конструкции вокруг заданной точки на земле;
3) Минимум два дирижабля; — для поддержания сети-конденсатора в расправленном состоянии (максимальная площадь), чтобы та не провисала под собственным весом и весом конденсата;
4) Компактные и долговечные двигательные установки дирижаблей; — для удержания их на заданном расстоянии друг от друга, для поддержания сети-конденсатора в расправленном состоянии;
5) Система электроснабжения двигательных установок дирижаблей; — хорошо экранированные прочные кабели от наземной турбины-генератора;
6) Компьютеризированная система точного позиционирования и управления дирижаблями; — для поддержания сети-конденсатора в развернутом состоянии под нужным углом атаки ветра;
7) Прочное синтетическое износоустойчивое волокно для самой сети-конденсатора; — износ, как мне кажется, будет существенной проблемой при учёте постоянного механического воздействия;
8) Прочная (возможно, опять же, кевларовая) внешняя оболочка дирижаблей и упругая износоустойчивая внутренняя оболочка; — защита от природных (град, молнии) и биологических (птицы) угроз;
9) Инфраструктура технического обслуживания; — дозаправка дирижаблей гелием, т.к. при необходимых объёмах утечки и, как следствие, потеря подъемной силы, будут неизбежны, и т.п.;
Как следствие того, что я перечислил — базовые затраты на разворачивание подобной системы вырастают значительно. К тому же таки необходимы будут затраты на инфраструктуру, которая будет обслуживать такую АэроГЭС (как минимум один хороший механик и один инженер, плюс ресурсы). Ну и так далее…
Это так, навскидку, что в голову пришло. Я не физик и не инженер, так что это идеи и соображения дилетанта, но думаю, что на Хабре обязательно найдутся соответствующие специалисты и всё подробно прокомментируют.
Так вот: как на мой взгляд, так эта статейка банальный «вброс гаумна» в адрес НАСА со стороны обиженных и обделённых из-за собственного раздолбайства и тотальной безответственности русских Иванов, обосравших такую перспективную миссию (единственную за много лет). А зная любовь наших «пилить» выделенные бюджеты, я даже догадываюсь почему эту самую миссию и облажали.
По принципу: «У нас не получилось полететь на Марс, а у вас получилось — вы над нами ржоте. Ну и что, зато у вас негр в белом доме и Марс вообще не настоящий! Вот так!». Язык типа показали…
Но факт от этого остаётся фактом — они туда успешно летали, летят сейчас и будут летать в будущем, а мы будем строить дачи и покупать мерседесы на халяву.
P.S.
Не минусить — всё вышесказанное банальный сарказм и сатира на действительно плачевное положение дел в передовых областях отечественной науки и техники.
Как по мне, так подобные средства для ведения конкурентной борьбы уже давным давно вовсю используются. Я уверен в этом на 100%, потому как ко мне самому несколько раз обращались с вопросами типа «Вы знаете, вот у таких-то сервис есть на сайте такой-то, почти как у нас, можно ли что-нибудь сделать, чтобы у них пользователей поменьше стало?».
Просто, видимо, одно дело нанять группу хакеров (допустим, человек 5 отличных спецов), а другое дело поднять на уши половину Интернета так, что каждый кулхацкер теперь считает своим долгом за бутылочкой пивка посидеть вечером с друзьями и поискать дыры в защите соневских систем. Вряд ли команда специалистов (пусть даже и очень хороших) сравнится с целым «зергом» анонимусов.
Как вариант — провокационные акции, направленные на поднятие общественности против кого-то или чего-то…
Думается мне, что последствия в глобальном масштабе могут быть очень «радужные» для всего интернет-сообщества.
И так давят со всех сторон копирасты; гмейл пытались запретить, потому что ФСБ не может с него переписку читать; все предпосылки к введению тотальной цензуры всего и вся в интернете; и т.д., и т.п. — список можно продолжать очень и очень долго. А вот доблестные товарищи из LulzSec, фактически, подлили масла в огонь и дали очередной повод для охоты на ведьм.
Вспомнилась цитата с баша, диалог между юзером и админом провайдера:
Ю: -Сделайте так, чтоб у меня ночами интернета не было!
А: -Спать хочется?
Ю: -Угу…
А на счёт «отдать пароль от программы другу»: пусть разработчики тогда уж сразу добавят в эту софтину автоматическую блокировку всех мыслимых и немыслимых анонимайзеров (типа каларупы или hidemyass) и злобный антиотладчик, который бросает винду в синий экран, чуть только почуяв нависший дебагер… а то ведь, когда очередной дозы хабра захочется, ещё и не в такие извращения подашься.
А вообще, да… Сколько раз думал и жалел, что не стоит за спиной какой-нибудь злобный Терминатор с лопатой в руках и не палит, какую по счёту цитату с баша я читаю, вместо того, чтоб кодить очередной модуль под двиг проекта, который нужно было сдать «НИДЕЛЮ НАЗАААД!!! БЫЫЫЫСТРААА!!!»…
Разделяю мнение, сам любитель хоткеев и сам же обматерился, пока тестировал всё это. Но тут использовано всё в комплексе — от блокировки Ctrl, до отсутствия где-либо в коде прямой ссылки на искомую картинку.
Для рядового пользователя, который не преследует цель «во что бы то ни стало, достать картинку!» — этого вполне достаточно, чтоб он остыл. Для остальных же, кому действительно нужно (или дело принципа) — это от 30 секунд до n минут мороки.
Мне этого как раз и не нужно было и сам я пытался объяснить заказчику то же самое.
Суть можно свести к тому, что заказчик хотел опросить n-ое число пользователей, через интернет, по нескольким картинкам (что-то типа тестирования рекламных концепций), но не хотел, чтоб они их сохраняли (т.к. их можно было использовать «в корыстных/личных» (с) целях).
Убедить его, что сохранить от копирования контент, выложенный в интернете (тем более УЖЕ попавший к конечному пользователю в кэш), невозможно — не получилось.
Я предложил описанный вариант и он заказчика устроил. Сюда же я выложил наработку для тех, кому она может пригодится, если кто-то окажется в подобной ситуации.
Вы бы хоть почитали повнимательней, что я пишу и почему это делаю.
if (keyCode == '155'){ // не работает, т.к. PrintScreen является функцией заложенной в ОС, а не в браузер - до неё мы достучаться не сможем
Повторюсь — у меня стояла задача и я её решил тем способом, который описал (см. UPD 2), пусть и не самым лучшим. А здесь я решил поделиться своим решением с теми, кто, возможно, когда-нибудь столкнётся с подобной задачей.
Сохранение багов ради обратной совместимости? — Это да, это перспектива плачевная. Но тем не менее, выше в комментариях уже писали на примере того же Хрома и Сафари, когда какой-то баг есть только у одного из них.
Взглянем на потенциальную проблему с другой стороны (допустим, переход на WebKit состоялся, кроме старого доброго IE — чтобы перешёл он нужно, наверное, второе пришествие): есть куча браузеров, которые реализуют, например, 95% рекомендаций HTML6 и CSS4, а напротив них есть семейство IE, которое только-только осилило HTML5 и CSS3… Что останется делать MS? — Правильно, догонять и перегонять.
На мой взгляд, конкуренция сохранится до тех пор, пока существуют хотя бы 2 базы для браузеров. И конкуренция эта будет тем ожесточенней, чем более крупные игроки будут выступать с обеих сторон.
А конкуренция эта будет в любом случае, потому что это деньги. Даже если все вообще браузеры перейдут на базу WebKit — конкуренция останется, только перейдёт на другой уровень и развитие пойдёт уже в рамках надстроек/модулей/фишек в реализациях браузеров от конкретных вендоров.
Если я правильно понял статью (поправьте, если нет), то суть её сводится следующему: отсутствие конкуренции и наследование багов ради обратной совместимости, тотальная слежка за всеми и пресечение инноваций. Вот этого, на мой взгляд, точно не будет, потому что крупные игроки никогда на пойдут на то, чтобы быть равными — для выживания в бизнесе необходимо развитие, а без конкуренции в развитии нет смысла.
Почему-то на ум пришла аналогия, как когда-то, во времена готичного черного доса, в коде было необходимо поддерживать тонну разнообразного железа, чтобы всё работало адекватно на разнородных системах. Потом пришли DirectX и OpenGL+OpenAL. Развитие технологий не остановилось.
Когда-то, во времена, когда компьютеры были большими, каждый процессор имел свой набор инструкций. Потом пришёл 8086 и началась эпоха x86. Развитие технологий не остановилось.
Когда-то, давным давно не было IBM-совместимых компьютеров…
С оглядкой на эти истории у меня возникает резонный вопрос: почему же переход на WebKit сулит нам стагнацию в развитии веб-технологий и пахнет катастрофой?
Не очередной ли это виток закономерного развития, когда куча разрозненных и обособленных разработок, а так же компаний, которые эти самые разработки поддерживают, объединяются и общими усилиями начинают двигаться в ОДНОМ направлении вместе?
Как мне кажется, преувеличение в этой статье, вкупе с теорией заговоров, гораздо более спекулятивное, чем мой пример с перегнутой палкой в CSS (зато ярко).
В конце-концов, WebKit — проект открытый.
Не нравятся варианты, которые предлагают вендоры? — Возьми, да собери свой. И собери его не с нуля, а с использованием тонны кода высококвалифицированных разработчиков от крупных вендоров, которые этот проект поддерживают.
Нравятся варианты, которые предлагают вендоры, но чего-то нехватает? — Собери свой с нужным функционалом. В качестве примера могу привести проект Роджера Вонга, который взял WebKit и привинтил к нему Node.js: github.com/rogerwang/node-webkit
Не вижу совершенно никакой проблемы.
Почему? — Потому…
Что имеем сейчас:
В HTML:
… несколькими строками ниже:
Теперь CSS:
… несколькими строками ниже:
Про различия в JS говорить не буду, т.к. к WebKit'у они отношения не имеют.
Что же мы будем иметь в исходниках при условии наличия WebKit в качестве стандартной базы для рендера html в браузере?
Пример с теми же исходниками, что привёл выше.
В HTML:
В CSS:
Если же обнаруживается какой-то баг в WebKit с отступлением от стандартов до какой-то определенной версии — задаём условие в init.js:
Всё. Проблемы нет. Код проще. Код понятнее. Поправили багу в вебките? — Хак не подгрузился и всё.
Если я не прав — пинайте ногами, но… Переход на WebKit — это благо для цивилизации. К тому же, то, что WebKit будет использоваться в качестве базы, совершенно не отменяет того, что в каждом конкретном браузере будут собственные уникальные фичи. Пример с Сафари и Хромом — в хроме по-дефолту WebGL включен, в Сафари — нет. Оба на базе WebKit.
Делаем выводы. :)
Мне, например, гораздо проще и удобнее учиться именно по справочнику по принципу «есть задача — сломай голову, но найди решение». Изучая что-то по справочнику, волей не волей, в процессе поиска нужной информации, захватываешь попутно ещё целую гору материала, прямо не относящегося к конкретной функции или методу, которые помогут решить текущую задачу, но так или иначе откладывающегося в закромах памяти.
Раз за разом бегая таким образом по справочнику, рано или поздно, но автоматически изучишь возможности нужной библиотеки/фреймворка/класса. Конечно, если только не требуется обширная теоретическая база (как для веб-программера, который всю жизнь использовал только jQuery и только для анимации UI, а тут ему вдруг взбрендило написать демку на WebGL и чистом JS :)
Книги, в отличие от справочников, как правило, несут с собой приличный объем воды. Алгоритмы? — Алгоритмы везде одинаковые: либо ты умеешь их составлять, либо нет и книги тут, как мне кажется, играют слабую роль.
Жаль только, что принцип изучения по справочнику не подходит для освоения новых ЯП: тут, как ни крути, необходимо знать особенности изучаемых языков — справочник не поможет и книги тут действительно необходимы. Но Node.js, как мне кажется, всё же не из этой оперы.
По теме топика: node-webkit великая вещь! В несколько кликов портировал свою демку:
Three.js + Node-Webkit + batch to exe converter
Сейчас вынашиваю коварные планы по написанию простенького гейм-движка на базе Three.js, tQuery, Physijs и Node-Webkit. Надеюсь, что-нибудь из этого получится. :)
THIS_IS_CONST
thisIsVar
ThisIsFucntion (или f_ThisIsFucntion — если много функционального кода)
CThisIsClass (или c_ThisIsClass)
В силу этого обстоятельства сейчас возник профессиональный интерес: чем клиент мотивировал переезд Bitrix -> MODx? Если это не коммерческая тайна, конечно же.
1) Вместо водорода — гелий; — не взрывоопасно, но нужен больший объём.
2) Толстые тросы из кевлара; — для удержания конструкции вокруг заданной точки на земле;
3) Минимум два дирижабля; — для поддержания сети-конденсатора в расправленном состоянии (максимальная площадь), чтобы та не провисала под собственным весом и весом конденсата;
4) Компактные и долговечные двигательные установки дирижаблей; — для удержания их на заданном расстоянии друг от друга, для поддержания сети-конденсатора в расправленном состоянии;
5) Система электроснабжения двигательных установок дирижаблей; — хорошо экранированные прочные кабели от наземной турбины-генератора;
6) Компьютеризированная система точного позиционирования и управления дирижаблями; — для поддержания сети-конденсатора в развернутом состоянии под нужным углом атаки ветра;
7) Прочное синтетическое износоустойчивое волокно для самой сети-конденсатора; — износ, как мне кажется, будет существенной проблемой при учёте постоянного механического воздействия;
8) Прочная (возможно, опять же, кевларовая) внешняя оболочка дирижаблей и упругая износоустойчивая внутренняя оболочка; — защита от природных (град, молнии) и биологических (птицы) угроз;
9) Инфраструктура технического обслуживания; — дозаправка дирижаблей гелием, т.к. при необходимых объёмах утечки и, как следствие, потеря подъемной силы, будут неизбежны, и т.п.;
Как следствие того, что я перечислил — базовые затраты на разворачивание подобной системы вырастают значительно. К тому же таки необходимы будут затраты на инфраструктуру, которая будет обслуживать такую АэроГЭС (как минимум один хороший механик и один инженер, плюс ресурсы). Ну и так далее…
Это так, навскидку, что в голову пришло. Я не физик и не инженер, так что это идеи и соображения дилетанта, но думаю, что на Хабре обязательно найдутся соответствующие специалисты и всё подробно прокомментируют.
Так вот: как на мой взгляд, так эта статейка банальный «вброс гаумна» в адрес НАСА со стороны обиженных и обделённых из-за собственного раздолбайства и тотальной безответственности русских Иванов, обосравших такую перспективную миссию (единственную за много лет). А зная любовь наших «пилить» выделенные бюджеты, я даже догадываюсь почему эту самую миссию и облажали.
По принципу: «У нас не получилось полететь на Марс, а у вас получилось — вы над нами ржоте. Ну и что, зато у вас негр в белом доме и Марс вообще не настоящий! Вот так!». Язык типа показали…
Но факт от этого остаётся фактом — они туда успешно летали, летят сейчас и будут летать в будущем, а мы будем строить дачи и покупать мерседесы на халяву.
P.S.
Не минусить — всё вышесказанное банальный сарказм и сатира на действительно плачевное положение дел в передовых областях отечественной науки и техники.
Просто, видимо, одно дело нанять группу хакеров (допустим, человек 5 отличных спецов), а другое дело поднять на уши половину Интернета так, что каждый кулхацкер теперь считает своим долгом за бутылочкой пивка посидеть вечером с друзьями и поискать дыры в защите соневских систем. Вряд ли команда специалистов (пусть даже и очень хороших) сравнится с целым «зергом» анонимусов.
Как вариант — провокационные акции, направленные на поднятие общественности против кого-то или чего-то…
И так давят со всех сторон копирасты; гмейл пытались запретить, потому что ФСБ не может с него переписку читать; все предпосылки к введению тотальной цензуры всего и вся в интернете; и т.д., и т.п. — список можно продолжать очень и очень долго. А вот доблестные товарищи из LulzSec, фактически, подлили масла в огонь и дали очередной повод для охоты на ведьм.
Ю: -Сделайте так, чтоб у меня ночами интернета не было!
А: -Спать хочется?
Ю: -Угу…
А на счёт «отдать пароль от программы другу»: пусть разработчики тогда уж сразу добавят в эту софтину автоматическую блокировку всех мыслимых и немыслимых анонимайзеров (типа каларупы или hidemyass) и злобный антиотладчик, который бросает винду в синий экран, чуть только почуяв нависший дебагер… а то ведь, когда очередной дозы хабра захочется, ещё и не в такие извращения подашься.
А вообще, да… Сколько раз думал и жалел, что не стоит за спиной какой-нибудь злобный Терминатор с лопатой в руках и не палит, какую по счёту цитату с баша я читаю, вместо того, чтоб кодить очередной модуль под двиг проекта, который нужно было сдать «НИДЕЛЮ НАЗАААД!!! БЫЫЫЫСТРААА!!!»…
Может быть, за это и минусуют (раз работает)…
Для рядового пользователя, который не преследует цель «во что бы то ни стало, достать картинку!» — этого вполне достаточно, чтоб он остыл. Для остальных же, кому действительно нужно (или дело принципа) — это от 30 секунд до n минут мороки.
Суть можно свести к тому, что заказчик хотел опросить n-ое число пользователей, через интернет, по нескольким картинкам (что-то типа тестирования рекламных концепций), но не хотел, чтоб они их сохраняли (т.к. их можно было использовать «в корыстных/личных» (с) целях).
Убедить его, что сохранить от копирования контент, выложенный в интернете (тем более УЖЕ попавший к конечному пользователю в кэш), невозможно — не получилось.
Я предложил описанный вариант и он заказчика устроил. Сюда же я выложил наработку для тех, кому она может пригодится, если кто-то окажется в подобной ситуации.
if (keyCode == '155'){ // не работает, т.к. PrintScreen является функцией заложенной в ОС, а не в браузер - до неё мы достучаться не сможемПовторюсь — у меня стояла задача и я её решил тем способом, который описал (см. UPD 2), пусть и не самым лучшим. А здесь я решил поделиться своим решением с теми, кто, возможно, когда-нибудь столкнётся с подобной задачей.