Pull to refresh
-2
0
Дмитрий Черняк@dmiche

IT-архитектор, владелец компании, философ

Send message

Ну да, всё как на Хабре: на смену статьям-мозгоклюйкам пришли статьи-хавтушечки. Лет через 15 ждём статьи-уставчики, о том, как здорово и мотивированно делать всё единообразно-унифицированно.

Не раскрыта тема удержания указанных в начале психотипов игроков. Т.е., соотнести типы и последующие советы можно, но чёткости не будет и, если не понимать основ стратегии выделенных психотипов, то, в любом случае, довольно сложно.

Т.е., к примеру, что будет важно для коллекционера, а что не важно?

Потому что, во-первых, иногда игра и не должна удовлетворять все психотипы, а имеет фокус на свою аудиторию. А, во-вторых, даже если это игра для всех, то каждый тип будет иметь в ней свои "коридоры" привлекательных фич и нужно, по идее, заботиться о консистентности коридоров, а не набрасывать плюшки лоскутно.

ДНК как-то так должна работать :)

К сожалению, тезис этот, сам по себе, довольно банальный. Реальные методы геймификации, реальные метрики, реальные правила, реальные методы мониторинга для соотнесения жизни с ачивками были бы интересны.

Увели весь хайтек. Оставили старое стагнируещее барахло, которое тут из инфраструктуры не вынуть, а там нафиг никому не нужно. С другой стороны, вгипотезно, торг и шёл за то, чтобы оно у нас не накрылось медным тазом.

Т.е., Вы говорите о том, что существует матрица слов и матрица смыслов. Это - разные предметы, живущие по разным законам. Предлагается делать отображение слов на смыслы используя "цифровой толковый словарь" одного языка, а затем распаковывать обратно, используя словарь другого.

В настоящее время эта технология уже реализована - так работает нейросетевой переводчик: он отображает текст на внутреннее пространство т.н. "эмбеддингов" при помощи сетки-"энкодера", а затем из него достаёт при помощи сетки-"декодера". Обе сетки тренируются синхронно на одном фразовом материале, но на разных языках, что и обеспечивает общность промежуточного слоя эмбеддингов.

Пространство эмбеддингов - это псевдолинейная матрица, в том плане, что конструктивно все ячейки в ней линейно пронумерованы, а фактически она полносвязная и с выходным слоем энкодера и со входным слоем декодера. В смысле, каждый выход энкодера соединён матрицей весов с каждым элементом эмбеддинг-матрицы. Т.е., там по факту NxM размерность в каждую сторону.

С пространством эмбеддингов, получаемым таким способом, есть проблема: можно создать алгоритм, который будет обеспечивать сходимость пространства эмбеддинов при тренировке, но невозможно определить, какой эмбеддинг за что отвечает в точности.

На самом деле, есть спекулятивное предположение, что это нерешимая задача в рамках современной парадигмы, потому что это похоже на взаимную неопределённость эрмитовых операторов. Т.е., там нет и не может быть взаимно-однозначного соответствия (за счёт чего, собственно, и получается что-то внятно перевести).

Примечательно то, что Вы переосмысливаете эту задачу на языке, который ближе к метафизике, а не к математике. Т.е., который использует термины, скорее, в пространстве смыслов, чем в пространстве свойств. Из за этого математики сердятся: кожаная нейросетка в их голове перетренирована на понятийное мышление и, из за этого, они про смысловые конструкции очень вяло понимают. Между тем, для описания нейросетей Ваш подход более органичен. Он позволит, в конечном итоге, назвать происходящие в них процессы простыми и точными именами смысла их действия, а не восстанавливать этот смысл каждый раз в голове через дешифровку формулы их работы.

Такое везде возможно, но банк в этом плане довольно интересная структура: это полностью цифровое производство. Т.е. компания, которая не занимается непосредственно ИТ-деятельностью, не реализует какую-то уникальную услугу, но у которой всё в цифре. Отправная точка, даже для маленького банка - примерно 20 серверов, соответственно, там даже при малом масштабе деятельности достаточно большой и разносторонний ИТ штат и он "убыточен", т.е., он не производит ничего, просто занимается текущими задачами. И сколько в него не вкладывай, денег он не принесёт.

Поэтому средств на "выстраивание системы" просто физически не дают. Ну, грубо говоря, если у бизнес-руковдства есть выбор, иметь 5-10 ИТ-шников и "как есть", или 12-20 соответственно и "выстроенную систему", при том, что для бизнеса не изменится вообще ничего (риски точно не упадут), то выбор, обычно, в пользу экономии.

Если сильно короче: банк средней руки с широким спектром услуг, имеющий штат до нескольких сотен душ представляет собой бессистемно автоматизированное ИТ-предприятие со средним уровнем документированности и высоким объёмом местного колхоза. Более того, если там как-то по другому, то ИТ-сектор явно занимается выкачиванием денег из бизнеса и где-то их на стороне осваивает.

Что не мешает его ИТ-подразделению постоянно бороться за упорядочение (иначе там вообще всё порастёт и покроется).

На выходе из ИТ дира получается хороший менеджер ИТ-проекта или техлид (если он действительно от сохи рос), способный к необычным решениям и реальной экономии (которая нынче снова вошла в моду).

Ну или просто манагер, если его ИТ задолбало, а люди ещё нет (не это, вроде не про Вас).

В наше время - можно присмотреться к госам, где внедряются отечественные продукты - эти продукты представляют сейчас, как раз ИТ-колхоз уровня нулевых, который необходимо достаточно оперативно поднимать до корпоративного. И это могло бы быть одним из каналов служебного роста.

Например, нужно вкачать фио/адрес, адрес увязать с КЛАДРом. Ну и ещё ворох таких же источников и хотелок. Казалось бы, что может пойти не так, если первичку вводили живые люди?

И вот прошаренный разработчик сразу прикинет, что заказчик захочет поиск по несовпавшим адресам и ещё какуюньть непрогнозируемую дичь. Поэтому будет планировать гибкую архитектуру, которую можно будет понятно как костылить. Ну и она закономерно обрастает этими костылями по заранее намеченной траектории.

Потом приходит юный отличник, смотрит на вот это и начинает сердиться: "кто так строит? всё должно на всё ссылаться, нужно всё переделывать!". А поскольку это такие вещи, что если надо объяснять, то не надо объяснять, то ему один раз ответят, а дальше ждут, что он будет что-то полезное делать и живого опыта набираться.

Конечно, бывают такие проекты, что там не спроектированный бардак, а просто бардак. Но разраб без опыта отличить не сможет.

Вы, возможно, удивитесь, узнав, что далеко не все люди в жизни пользуются логикой. Собственно, вот обученная нейронка - она же не использует логику, она, вульгарно выражаясь, использует кейсы. Много кейсов.

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

В нашей жизни техника безопасности, правила дорожного движения и устав караульной службы - это продукты отнюдь не логики, а именно набора кейсов. Логика при их составлении была только лишь слабой отправной точкой. И именно эти кейсы спасают жизни. Но, при этом, требуют от пользователя дологического подхода - не нужно думать, нужно исполнять.

Что касается "мистики" в коде, то, вот, в Питоне есть, например, такие фокусы:

>>> Decimal(0.1)

Decimal('0.1000000000000000055511151231257827021181583404541015625')

И если вы не знаете, в чём дело, то воркараунд будет выглядеть как магия.

В приснопамятном Борланд паскале разлива девяностых иногда добавление строчки комментария в код исправляло компиляцию. Сколько таких хвостов в NUMA-кластере, у которого пользовательская база весьма ограничена, даже подумать сложно.

Опять же, очень часто, способный новичок, особенно, ортогональноголовый, недооценивая деталей задачи и не обладая необходимым жизненным опытом, чтобы эти детали предвидеть, полагает, что всё можно запрограммировать непротиворечиво. Смущает своими речами коллег, берётся переделывать и... стабильно увязает через 2 месяца, когда всё логичное уже сделано и мы подходим к самому интересному, обнаруживаем, например, что некорректные входные данные нельзя терять, а способов, которыми они некорректны слишком много. Если такому тимлид своевременно не настучит по голове, то это будут выкинутые трудодни.

В общем, свежий продвинутый взгляд на код всегда полезен, но далеко не всегда бывает верен :) А с другой стороны, чистых мистиков в программировании тоже хватает. Тут, скорее, по результату нужно смотреть. Если продукт есть, если он приносит прибыль, значит модель и команда выбраны верно, что бы нам не говорило чувство перфекционизма. Когда бизнес занеможет - кто то это перепишет и сделает новый бизнес.

P.S. А за книжечку спасибо. Хорошего Нового Года!

А, ну так стало понятно, да, спасибо.

Выходит, что там упругого колебания вообще нет, там всё летит только вперёд. Неожиданно.

PS. Для минусаторов: господа, минус за вопрос - это как? Типа, "ответить не могу, но осуждаю?" :)))

Это значит, что мы должны быть способны ответить на вопрос, где прибавилось, когда тут уменьшилось. И, если говорим о понимании процессов, то ещё на вопрос за счёт чего.

Если мы на графике берём развёртку по времени, а мы именно её и берём, то они никуда не движутся. Потому что для движения необходимо течение времени, график же его в каждой своей точке исключает.

Как при этом действует закон сохранения энергии. Если её там нету, то где она?

Т.е. на самом деле, там примерно как с орбитой электрона: там в реальности суперпозиция, но мы считаем, что как бы есть орбита. Так и тут - вроде колебания есть, но вроде как это вообще не колебания?

Да, интересно. Получается, что фильтр, по сути (как Вы и пишете в самом начале) преобразует поляризацию. Т.е., пропущенная им энергия формирует уже волну новой поляризации, а не ослабленную волну старой.

А можно глупый вопрос не по теме? Вот эта картинка, в которой лепестки Э/М и Э/С поля синфазны, она же, насколько я понимаю, графически корректна, они именно синфазны. Но тогда куда девается энергия в узловых точках? Как здесь работает закон сохранения энергии?

Опенсорс вообще не про монетизацию. Его всегда двигали люди, которые не голодали. Опенсорс - это про то, что инженер, способный сам сделать узел, который ему предлагают купить, не хочет использовать этот платный энтерпрайз-фекалий. И не потому, что он платный, а потому, что он неудобный, перегруженный тем, что в 90% задач не нужно, устаревший, очень часто - слабопрофессиональный и всегда - с закрытым кодом, чтобы этого никто не увидел. Security by obscurity и всё вот это вот.

Когда таких инженеров становится много (а интернет этому способствует), и находится пара-тройка гениев, типа Столлмана и Линуса, способных написать действительно сложный базовый продукт (компилятор, затем - ядро, ну и обвязка до кучи) появляется своя экосистема. Энтерпрайз её переплёвывает только в приложениях, которые в одно лицо создать не просто сложно, а невозможно. Но, как показала практика, значимость этого порога сильно преувеличена - очень много чего, что сейчас в ходу, было сделано одиночками.

Затем энтерпрайз таки прочухал халяву и то, что он просто проиграл по технологии (SCO, AIX, Novell и прочие), ему было некуда деваться, он принял опенсорс, влил в него толпу своих тупых кодеров, которым было вообще пофиг, чего писать и мы сегодня имеем то, что имеем. Сегодня многие опенсорс-проекты по степени развитости - уже не проекты одиночек - это и хорошо и ностальгически плохо одновременно, поскольку нарушает принцип KISS. Впрочем, это было неизбежно.

Занятно при этом, что попытка эффективных манагеров вывести тот или иной проект из опенсорса (тот же MySQL, Bacula) мгновенно роняет ту клиентуру, которая имеет шанс вырасти и потом прийти за консалтингом и энтерпрайз-надстройками.

Что будет дальше?

Лет через несколько CoPilot-ы дадут возможность уже сложные проекты в одно жало модифицировать (нейронка будет просто вкуривать структуру всего кода проекта и радикально облегчит точечные доработки) и опенсорс одиночек вторгнется обратно в сложные продукты.

Сам по себе опенсорс-подход, уже как обязательный инструмент, использовался в блокчейне, а прямо сейчас он, в своём первозданном виде живёт в разработке нейросетей.

Но тех денег, про который Вы говорите, в нём по прежнему не будет.

Зато значимость социальных ачивок, которые он даёт, вырастет многократно.

Более того, я не исключаю того, что корпоратам вменят контрибуцию в опенсурс, примерно как вменили ESG. Под ровно тем же предлогом - чтобы сократить выбросы парниковых газов из макушек программистов на создание того, что можно взять у товарища. Такая вот экономика сейчас. А совсем не про деньги :)

Это если хостинга пользователи предоставляют ококонечный сервис неограниченному кругу лиц. А если нет, а это всего лишь GPU бэкенд, или 1С-ка, например - это вообще внутрикорпоративный сервис и там РКН не интересно.

Сейчас, конечно, 2023 уже, но статьи хорошие. Для не математиков в самый раз.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity