Личный Журнал

Определения важны и неважны

2025-09-23T08:01:09.094Z

Напишите пост с эссе по поводу традиции избегания определений в текстах

7 минут

Избегание определений в текстах происходит у каких авторов?

В целом, избегание определений характерно для авторов, которые считают, что:

язык живёт в практике, а не в словарях (Витгенштейн);
смысл неустойчив и множественен (Деррида, Делёз);
определение — это форма власти (Фуко);
универсальные рамки мешают видеть разнообразие опыта (Лиотар, постмодернисты).

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

http://lesswrong.com/lw/kg/expecting_short_inferential_distances

1) Напишите пост, где дайте три примера ваших попыток преодолеть далёкое понятийное расстояние (не забудьте перед написанием поста освежить в памяти https://lesswrong.ru/w/Ожидая_короткие_понятийные_расстояния, эта работа была упомянута в предыдущем подразделе).

Три моих примера, когда я пытался преодолеть далекое понятийное расстояние

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

Вспомните десяток ваших последних дискуссий. Какие из них были «спорами о терминах» и поэтому заведомо бесплодны? Напишите об этом пост.

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

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

Где на текущий момент замечаю и стараюсь устранять споры о терминах:

Обсуждение со второй половинкой/партнером касательно ситуаций, мыслей: какое поведение что означало, какие то идеи.

- "экспертные продажи" (рабочий проект)

- заведомо бесплодны по следующим причинам

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

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

- "обучение персонала" (рабочий проект)

создавали "курсы", которые уже не работают
давали исполнителям делать курс, которые не имели предметного представления содержательной части
не было понимания зачем: какой итоговый результат. Говорили больше про систему трансформатор/создателя, чем про целевую, или нашу.
обучение ради обучения - малополезное мероприятие без понимания зачем, к чему, и чему надо обучать.

Заметки - Stanislau Niadbailau. Reasoning в проектах и подсчет

2025-04-27T21:43:40.713Z

https://www.youtube.com/watch?v=QN_NFSEa9hM

Все что более конкретное, сразу же побеждает

Боль компании - все просто балаболят и презентации делают, которые только обещания делают, через 2 года что-то будет

Все что более конкретное, сразу же побеждает

или же короче сроки, с объяснениями
или разложение даже процентов, может быть неверно, но мы продвинулись

Люди тригерятся на это, т.к. реально становится - деньги

Трюк в том, чтоб:

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

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

Сразу делаем

попробуй по системной мантре пройти

Моя команда может быть не нужна: если можешь доказать, что даже если гипотетически мы сделаем что хотим, и ничего не изменится или минимальные результат будет. Если не делать, то что будет.

Цифра дает совершенно другой разговор: кейс про разинцу между предложением сделать еще один сайт и сэкономить секунду для сотрудников коллцентра имеет разный результат, хотя разговор идет об одном и том же.

Предметная область, для подсчета

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

описание рабочих процессов

как это работает
как они там этим пользуются
user research - как они там этим пользуются вообще, взять интервью

деньги:

вообще узнать ,как эти деньги ... "формируются?"
секунда, пример 200.000$ как это считается
что они считают? (по ф-аптекам тоже)
как они вообще измеряют? (по ф-аптекам тоже)

Что такое «Штанга Талеба»?

2025-03-12T08:09:01.347Z

«Штанга Талеба» — это концепция, предложенная Нассимом Николасом Талебом, американским экономистом, математиком и автором книг «Чёрный лебедь» и «Антихрупкость». Она представляет собой стратегию управления рисками, которая помогает справляться с неопределённостью и делает системы или людей «антихрупкими» — то есть способными не только выдерживать хаос, но и извлекать из него выгоду. Давай разберём, что это такое, как работает и где применяется.

Что такое «Штанга Талеба»?

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

Одна крайность: Максимальная безопасность, минимальный риск.
Другая крайность: Высокий риск, но с потенциалом большой прибыли.
Избегание середины: Отказ от «среднего» подхода, который часто уязвим к неожиданным событиям («чёрным лебедям»).

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

Как работает «Штанга Талеба»?

Основная идея — разделить ресурсы (например, капитал, время, усилия) между двумя противоположными подходами:

Безопасная часть (90–95%): Инвестируйте большую часть ресурсов в надёжные, предсказуемые и низкорисковые активы или действия. Это защищает от катастрофических потерь.
Рискованная часть (5–10%): Небольшую долю направьте на высокорисковые, но потенциально высокодоходные действия. Здесь вы можете потерять всё, но это не нанесёт серьёзного ущерба, а в случае успеха вы получите большую выгоду.

Пример из финансов (Талеб — бывший трейдер, поэтому часто приводит примеры из этой области):

90% капитала (например, 900 000 рублей из 1 миллиона) вложите в надёжные государственные облигации (ОФЗ) с минимальным риском.
10% (100 000 рублей) инвестируйте в высокорисковые активы, такие как опционы или стартапы, где есть шанс на огромную прибыль.
Если рискованные активы не сработают, вы потеряете только 10%, но сохраните основную часть капитала. Если же они «выстрелят», вы получите значительный выигрыш.

Почему это работает?

Талеб считает, что мир полон неопределённости, и традиционные методы управления рисками (например, прогнозирование или усреднение) неэффективны, потому что не учитывают редкие, но разрушительные события («чёрные лебеди»). Стратегия штанги помогает:

Ограничить потери: Большая часть ресурсов защищена от «негативных чёрных лебедей» (неожиданных кризисов).
Извлечь выгоду: Небольшая рискованная часть позволяет поймать «позитивные чёрные лебеди» (редкие события с огромной выгодой).

Талеб приводит пример своей компании: во время финансового кризиса 2008 года, используя стратегию штанги, они заработали полмиллиарда долларов для инвесторов, потому что были защищены от потерь, но смогли воспользоваться хаосом на рынках.

Применение «Штанги Талеба» в разных сферах

Эта стратегия применима не только в финансах, но и в других областях, где есть неопределённость. Вот несколько примеров:

Бизнес и стартапы

90% времени и ресурсов компании направьте на стабильные, проверенные процессы (например, обслуживание текущих клиентов).
10% — на эксперименты с новыми идеями, продуктами или рынками. Если эксперимент провалится, бизнес не рухнет, но в случае успеха вы получите новый источник роста.

Личное развитие

90% времени занимайтесь рутинной работой, которая обеспечивает стабильность (например, основная работа).
10% времени экспериментируйте с новыми навыками, хобби или проектами. Это может привести к неожиданным возможностям (например, Талеб сам совмещал трейдинг с писательством, что сделало его известным).

Личная жизнь

Талеб приводит пример моногамных птиц: они «изменяют» с «рок-звездой» среди сородичей, чтобы улучшить генетику потомства, сохраняя стабильность пары. Это метафора: сохраняйте стабильность в жизни, но иногда позволяйте себе небольшие риски, которые могут принести новые впечатления.

Преимущества «Штанги Талеба»

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

Недостатки и критика

Не всегда применимо: В некоторых сферах сложно выделить «безопасную» часть. Например, если весь ваш бизнес зависит от одного продукта, разделение на 90/10 может быть нереалистичным.
Риск недооценки потерь: Если рискованная часть (10%) окажется связана с основной (90%), потери могут быть больше, чем ожидалось.
Сложность реализации: Например, в России, как упоминалось в одном из источников, маржируемые опционы (в отличие от премиальных в США) требуют дополнительных затрат (гарантийное обеспечение), что может усложнить стратегию.
Критика Талеба: Некоторые считают, что Талеб переоценивает универсальность своей идеи. Например, Андрей Подшибякин отмечает, что Талеб признаёт: сильно пострадавшим от кризисов помочь нельзя, и штанга лишь учит извлекать уроки из чужих ошибок.

Итог

«Штанга Талеба» — это стратегия, которая помогает справляться с неопределённостью, избегая среднего уровня риска и разделяя усилия между максимальной безопасностью и небольшим, но потенциально выгодным риском. Она делает системы, людей или компании антихрупкими, позволяя не только выживать в хаосе, но и извлекать из него выгоду. Если вы хотите применить её в своей работе (например, в абонентском отделе), можно, скажем, 90% времени сосредоточиться на стабильных процессах (обработка текущих запросов), а 10% — на эксперименты (автоматизация или новые подходы к клиентам). Хотите пример для вашей ситуации? Расскажите больше!

Теперь изучаем менеджмент, так как с ним проблемы

2025-02-05T20:54:31.301Z

https://blog.commant.com/smart-collaborative-process-describing-with-the-process-model-canvas-incl-free-template

https://kanbanzone.com/2019/drum-buffer-rope-kanban-boards-dbr/

https://tameflow.com/blog/2020-05-29/steve-tendon-on-agility-chefs-live-show/

БД мы проектировали, а вот трансформацию не совсем. Поэтому начнем.

2024-12-26T21:52:28.087Z

ETL

Пообщался с Grok.

изучаю ссылки.

Data Silos (GROK)

"Data silos" refer to isolated collections of data within an organization that are not integrated or easily accessible by other parts of the organization. Here's a breakdown of what this term means:
Key Characteristics:

Isolation: Data is kept in separate systems or departments without sharing or integration. This can occur in different departments like marketing, sales, HR, etc., where each might have its own database or software solution.
Inaccessibility: Other parts of the organization cannot easily access or use this data without special permissions, requests, or sometimes even manual data transfer.
Lack of Integration: There's often no or limited data flow between these silos, meaning that the information held in one silo does not directly benefit or inform operations in another.

Implications:

Inefficiency: Work duplication might occur because one department isn't aware of what another is doing or has already done.
Poor Decision Making: Without a holistic view of data, decisions might be based on incomplete information, leading to suboptimal outcomes.
Reduced Innovation: Opportunities for cross-departmental insights or innovations are missed because the data needed isn't readily available or combined.
Customer Experience: For companies, this can translate into a disjointed customer experience where different parts of the customer's interaction with the company (sales, support, marketing) do not reflect knowledge from other interactions.

Causes:

Legacy Systems: Older technology that isn't designed to integrate with modern systems or other departments' databases.
Departmental Autonomy: Each department might choose its own tools or systems, leading to fragmentation.
Organizational Culture: A culture that doesn't prioritize data sharing or where there's a protective stance over data.
Regulatory or Security Concerns: Sometimes, data is siloed due to compliance with privacy laws or security policies.

Mitigation:

Data Integration Tools: Implementing technologies that can connect disparate data sources.
Centralized Data Management: Creating a central data warehouse or using data lakes where all data can be stored and accessed.
Cultural Shift: Encouraging a culture of data sharing and transparency across departments.
Standardization: Using common data formats or platforms across the organization.

Understanding and addressing data silos is crucial for organizations aiming for efficiency, better data-driven decisions, and an enhanced ability to innovate. Management strategies often involve both technological solutions and changes in organizational behavior or culture.

Скорее всего да, проблема всем известна, стандартна: data silos

нам нужна будет табличка источников, откуда берем данные
какие основные данные берем
добрать ssd

https://www.castordoc.com/data-strategy/how-do-large-organizations-avoid-data-silos

https://www.castordoc.com/blog/data-catalog-best-practices

https://www.techtarget.com/searchdatamanagement/definition/data-silo

Решение отменили: сможем пока обойтись без dwh, зациклим данные на crm. Выгрузка с УТ пойдет в crm, оттуда обратно в УТ, и далее это сделаем обмен в Бэкэнде. А бэкэндовские данные, напрямую создадим в crm, либо в УТ

заметки: ускорение инженерных работ

2024-11-03T21:34:03.594Z

Первый шаг ускорения: сомневаться в запросах(requirements/требованиях/необходимостях/потребностях), и вообще, что нужно делать, а что нет.

первое, что можно сделать, поставить напротив каждого требования/запроса, имя того, кто это запросил. Чтоб запрос был не "вообщешный": от "отдел"а, или "попросили", а кто-то конкретный. Чтоб можно было пойти к этому человеку, уточнить что он имел в виду. Используем принцип почтальона.
далее уже можно ставить под сомнение то, что вообще это нужно делать. Несмотря на ум человека, и возможно, даже мнение об уме человека может оказаться самым опасным, т.к. из-за этого мнения, запросы этого человека не будут проходить проверку.
Далее эти запросы можно уточнять, либо делать менее идиотскими, тупыми, более адекватными.

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

удалять любую часть процесса, элемента, которую можем. https://www.corporate-rebels.com/blog/the-art-of-subtraction

удаляем ненужные нам части

Musk: "You may have to add [parts or processes] back later. In fact, if you do not end up adding back at least 10% of them, then you didn't delete enough."

То есть, Маск за то, чтоб удалять чем больше людей, тем больше - добавить всегда сможем.

если в итоге, мы не добавили как минимум 10% из этого, значит можно еще удалять, и удалили недостаточно.

Третий шаг: Упростить, оптимизировать.

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

Четвертый шаг: Ускорение времени цикла

Ускорение процессов. Думать, как ускорять эти процессы. Но только те, процессы, которые прошли первые 3 шага. Потому что можно ускорить совсем то, что не должно было вообще существовать.

Пятый шаг: Автоматизировать

После всей проделанной работы:

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

Иначе мы будем думать про автоматизацию того(что будет требовать ресурсов), что вообще не должно было быть в целом сделано, а после и автоматизировано.

Можно пойти дальше

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

Пример с ШСМ может быть: «Упрощаем способы стать умнее». Процесс может быть усложнен, но результаты получаются качественнее и быстрее. Хотя, можно много что убирать, удалять, упрощать, ускорять тоже.

Нужно попробовать такое в курсе.

Кроме этого: T-Shape профессионалы.

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

Возражением может быть: «нельзя все выучить, узнать.»

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

мышление на базе постов:

https://www.corporate-rebels.com/blog/musks-algorithm-to-cut-bureaucracy

https://www.linkedin.com/pulse/applying-elon-musks-algorithm-software-engineering-marko-marinovic-laudf/

...нужно проверить гипотезы выше.

заметки Битрикс24 | Малик Валиходжаев

2024-10-29T01:29:21.211Z

Товары:

раздел crm. Можно создавать.
сумма товара указана
to-do:

закрыть доступ на открытие товара со сделки
сделать удобный быстрый поиск: удобно категоризировать
обеспечить, чтоб создавалась РТУ со стороны Б24? Как сделать, чтоб оформлено было автоматом?

Проектирование БД

2024-10-06T17:21:41.084Z

Немного моделировал в 2019-20 схему реляционных БД, при прохождении https://productuniversity.ru/marketing-i

https://www.youtube.com/watch?v=B5r8CcTUs5Y&list=PL4etfiszkYJydvQ3wqa7BcPXkX69TyUSo

Но теперь, нужно реально составить для задач, иначе сложно двигатсья дальше.

Далее, мета-описания, записываю мысли по прохождению.

Мои основные задачи:

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

Список вещей которые я незнаю:

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

"Database Keys Made Easy - Primary, Foreign, Candidate, Surrogate, & Many More"

Что такое keys

как лучше всего начать моделировать БД

один из примеров: https://www.ibm.com/docs/ru/tivoli-netcoolimpact/7.1?topic=wdm-setting-up-data-model

Хороший план(на мой взгляд)

Описать источники данных, где хранится все
Описать типы данных: сущности
Описать элементы данных: поля сущностей, и их содержание
Описать связи данных
Описать источники событий, события для изменения данных (можно через Dataflow Diagram, связав "действия/сценарий с агентами - тут основное внимание на сценарии получения данных/информации - кто что запрашивает, заносит куда и что получает https://prnt.sc/9HZS-AUtLbxO)

Возможно категоризировать по отделам
Возможно прикреплять ссылки на сценарии событий

Ключи это мета-мета-мета объекты описания.

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

Table - статическая табличка (плоская таблица)

Tables - реляционная табличка, со связями

Иерархическая таблица(сгруппированная, либо с ссылками - догадка моя)

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

Мы получим несколько уровней таблиц, минимум следующую:

Таблица всех зареганных документов
Таблица типов документов

Документы, как таблицы (то есть "сущность", и является таблицей так же)

и связи между ними мы просто мы строим ме жду этими таблицами.

А хранятся формы таблиц, и само содержание табличек(ящичков с данными) и таблиц мы храним уже в базах данных

Зачем делается реляционная база:

для экономии места - одна база, делится на части, по сущностям, после связываются между собой каким-то знаком, по типу - ID клиента и тп.

Primary key - это такое значение, которое помогает нам определять, о какой записи мы говорим, где они находятся - то есть, оно уникальное, по которому нам легко пойти в другую базу, табличку и идентифицировать связанные записи

задача: значит нужно у полей определять их назначение, тип "ключей" справа. Чтоб по ним понять, по "чему" мы определяем что.

ЕЕЕ, разобарсял что такое foregn key:

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

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

К примеру, для таблички заказов id клиента будет не определяющим это мета-описание, оно будет указывать и ссылаться на другой ящичек, то это foregn key.

А то, что будет указывать, ссылаться, определять, размечать именно этот ящичек и будет для этой таблички заказов как primary. Так же и с табличкой клиентов. Отчасти, primary key, предполагаю, являются определяющей "шапкой" для тиблички "ящичка". Если это сущность клиента, то это Сущность и ее номер по порядке, т.к

А связи, взаимосвязи: "1 к 1", "1 к множеству" и "множество к множеству"

1 to 1
1 to many
many to many

Это поможет выстроить связи и структуру между ними.

Как понять, какая связь между таблицами по множествам?

логикой

если одна сущность, может создать больше сущностей чем одну, то это 1 к множеству (взаимоисключающе, то есть в обратную сторону такого не происходит)
если одна сущность может создать только 1 сущность, то это 1 к 1
Если множество сущностей, может создать множество (тут предполагаю, что на одно поле может влиять несколько полей, и оно, поле, тоже может вариироваться - наверно более редкий случай, который нужно смотреть на примере). Это мостовые таблицы(называют как bridge tables) как понял.

Пример тут:

клиент может создать несколько заказов
А несколько заказов не могут создать несколько клиентов, это будут разные клиенты
а разные клиенты, не могут создать 1 заказ(хотя, если это б2б, или общий заказ, то это возможно), или даже несколько заказов.

Тут показан пример PK

Как раз, нашел и пример, вроде правильно догадывался - множества к множеству

https://prnt.sc/9HZS-AUtLbxO

https://www.youtube.com/watch?v=B5r8CcTUs5Y

Диаграмму движения потока данных можно делать по одному процессу за раз

https://youtu.be/QkKTxsMBdZs?t=714

Список пот. исполнителей:

https://kwork.ru/personal-assistant/35329531/sozdanie-bazy-dannykh-dlya-internet-magazina
https://kwork.ru/script-programming/29307520/razrabotayu-bazu-dannykh
Отправил им https://www.websailors.pro/ru/healthcare-mobile-application
Отправил им https://studiovsemoe.com/services9.html
https://freelancehunt.com/showcase/work/dizayn-razrabotka-bd-yii2-migratsii/647153.html - вот это мужик может мб помочь
https://kwork.ru/software/1065486/dorabotka-bazy-na-ms-access
https://kwork.ru/software/10986214/dorabotka-ili-sozdanie-bazy-dannykh-na-ms-access
https://kwork.ru/script-programming/29324415/telegram-razrabotka-bota-pod-klyuch

Еще источники:

Database Schema (ERD). Entity Relationship Diagram

Tables → Fields

Student table

Class table

Relation, relation key

Nature of relationship: 1 to 1, 1 to many, many to many

Как понять, как назвать табличку - по ее Primary Key - по столбцу. которая ее определяет, уникальность.

оптимизация табличек, "ящичков", делать их компактнее, как раз такими разбиениями

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

то же самое можно с продуктами, или с "набором" продуктов иметь дело. "Пакет услуг" нужен для того, чтобы объеденить таблички - по сути, мы имеем "Корзину услуг". И по идее, можем платить за "корзину". https://prnt.sc/Ta5QVD7ZUjip

в итоге, у нас будет ID пакета, и возможно id продукта/договора, за который проводится платеж, чтобы "распознать" платеж при оплате

интересно, насколько мы можем сделать личный кабинет для платежа? и стоит ли?

то есть нужно подумать, куда дальше двигаться по отпимизации - как идентифицировать договора и оплаты, за какой primary key держаться

Каждую оптимизацию можно делать таким образом, шаг за шагом.

В итоге, получает такую мета-модель, чисто с ссылками(1 primary и foregn key), чтоб все то, что не используется, вынести в бок, оставить место только для того, что используется.

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

+ даже так можно сгруппировать еще, в итоге:

То есть в итоге, шапка состоит из мета-мета-мета-данных/описаний - ссылок, по которым можно детали узнать для себя уже найдя/перейдя по ссылке. Но эффективность базы, ее организация растет.

можно посмотреть примеры требований: тут явно про то, чем мы тоже занимаемся - https://prnt.sc/rtoAbTwqL4vw

Про ETL процессы:

https://blog.skillfactory.ru/glossary/etl/#:~:text=ETL%20%E2%80%94%20%D1%8D%D1%82%D0%BE%20%D0%BE%D0%B1%D1%89%D0%B8%D0%B9%20%D1%82%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%20%D0%B4%D0%BB%D1%8F,%D1%81%20%D1%84%D0%B0%D0%B9%D0%BB%D0%B0%D0%BC%D0%B8%20%D0%B2%20%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%B5%20%D0%BF%D0%B5%D1%80%D0%B5%D0%BD%D0%BE%D1%81%D0%B0.

Когда мы размечаем что-то как Primary - мы сразу обозначаем это как мета-объект, "шапку", данных

Как Foregn key мы размечаем ссылки на другие таблицы, обозначем "мета-объект" как ссылку, чтоб по ней было понятно, что это шапка, которая ссылает меня на другую табличку/ящичек данных.

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

https://t.me/malik_valikhodjaev1/105

Основные задачи, внутри данных, которые будут производится в рамках практик:
1. поправка критической вещи: правильного порядка взаимосвязей данных меж собой. Понимание взаимосвязей объектов - критично. (https://youtu.be/aWP2MLAYQfk?t=879)

И важно помнить, что взаимоотношения, строим не между табличками, ящичками, а между аттрибутами/полями/данными. Условно это между табличками, но тут кейс в том, что связей может быть множество, поэтому связи строим между полями все-таки - не с "ящичком", а с данным и мета-данным.

Композитные ключи - Composite Key

https://youtu.be/hktyW5Lp0Vo?t=541
это когда соединяют значения, для создания уникального комбо значения - типо - что-то с документами, когда из твоей даты рождения и пр данных + id паспорта создают уник номер, который по сути является Composite Key

Bridge Table

соединительные "ящички"

Как ручками сделать в lucid с типовым кодом базу:

int (integers) - интеграл - целые числа - нечто целое = 1,2,3 и тд.
words - string - строка, текстовый формат данных - вики - кобминация(нить) любых символов(знаков) и чисел, без разницы
floats = числа, с дроблением = 1.02, 38.287 и тд.
date - датовое значение, для временных форматов
Char (___) - в SQL - Char и (кол-во символов в этой строке) - занимает 1 кол-во строк, в зависимости от указанного кол-во символов - если указали 7, то будет 7 знаков всегда занимать.
Varchar - varying - изменяемое - varchar(__) - в скобках можно указать максимальное значение строки.
boolean - Истина/Ложь(для программистов)- да/нет(для пользователей), True/False. Тип данных, тип переменных. В знаках указывается как - ложь=0, истина=1.
в char - могут быть и негативные значения, в uchar - только положительные.
money - фин значение
https://vertabelo.com/blog/er-diagram/
enum - enumiration - списковое значение, которое задают, чтоб потом можно было это значение выбрать. Но, это только в случае, если значения не меняются. Если меняются, то лучше составить отдельную таблицу и сделать через ссылкочную строку - foreign key, с этими значениями, даже с тем, что они будут пополнятся, и генерить ID этих новых значений, потом связав через foreign key - https://prnt.sc/pgV3E-bf1OJE

https://docs.mql4.com/ru/basis/types/integer/integertypes#char

https://vertabelo.com/blog/er-diagram/

https://vertabelo.com/blog/logical-physical-data-model/

https://docs.mql4.com/ru/basis/types/integer

Part 2

Придется ручками учится моделировать, уже к этому припер.

Тут прям, выше, гайд как делать. Буду записывать, брать в работу, еще и возвращаться пересматривать.

Inputs - перечислить все операции с данными(близко к юзкейсам) - что круто. Их активность, периодичность запросов, workload смотреть.

пересчитать кол-во запросов, их нагрузку. От этого начинается (можно в табличке сценариев, сделать эту модель.

Примеры:

Запрос(query): какие данные запрашивают

Задача: Берем самые важные query вперед!

Операция: что делают с данными, или какое действие происходит со стороны приложения/базы данных
Description: по сути краткое описание сценария, сути того, что смотрят, какие данные

Задача 2: разложить все сущности на модели изначально

Пока самый гибкий инструмент - draw.io

будем продолжать там - https://docs.google.com/spreadsheets/d/1NjOS3_sI71FCoJ9fm2mtI402LwuG9KT9EzKA09cNXSo/edit?gid=1345648953#gid=1345648953

апдейт: лучше этот - https://app.quickdatabasediagrams.com/#/d/xjTWti

апдейт: еще лучше https://dbdiagram.io/e/6713aea297a66db9a38c6ae7/6715aafc97a66db9a3a44f78 гуд!

Практика DFD - Data Flow Diagram

Нотация проста

https://app.diagrams.net/#G1u2KO8cbXyKB-WvFu3MDCjzcsH1QCsMpC#%7B%22pageId%22%3A%22dgrNQc7oY4N92YgCMkvI%22%7D

возможно получится несколько уровней модели даталфоу https://youtu.be/ab1DZ6o7QBs?t=938
https://www.youtube.com/watch?v=p72mCYQBM8o

Контекстная диаграмма
Диаграма 1 уровня

Обсуждение проблемы «игровая зависимость»

2023-10-09T01:28:07.923Z

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

Это для меня является проблемой. В целом, это у меня включается ассоциативное внимание, автоматическое на объекты. Далее я уже себя не контролирую, а действую рефлекторно.

Корень проблемы именно в ассоциативном наведении внимания.

Чтобы такого не происходило, нужно научиться себя выдергивать из этого состояния распознавания знакомых эффектов. Так сложилось, что играть «в доту» мне привычно и понятно, комфортно. Нужно понимать, что именно это является ловушкой для меня — именно этот комфорт наведения ассоциативного внимания.

Поэтому, чтобы не вредить своему здоровью, а так же успеху в деятельности, мне придется сделать выбор в сторону:

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

менее комфортного выбора, но в итоге более полезного понятийного внимания.

Мышление письмом 24/08/23

2023-08-23T22:35:20.981Z

Ситуация

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

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

Чтобы теперь зарабатывать, нужно создавать системы/рабочие продукты. Какие, ещё в процессе принятия решения я.

системы создаваемые для заработка в компании:

Devsym.io. в Дев.ио это команда и её сроки

Проект разработки

Henry Bonnar (on going). в хенри бонар это целевые показатели по продажам цветов (под вопросом)
Dinara DNA - PR and Publishing (on going). это 2 проекта: pr для EU представителей и тендер по внутреннему и внешнему ПР на заводе в кашкадарье + процессы обработки заявок менеджерами (под вопросом)

ШСМ

Инструкторство. 1 час
Обучение. 1 час.
Развитие амбассадоров. 1-2 часа в неделю.
Выступления.

Сбор базы данных(уже какая-то есть).
Составление аутрич сообщения.
Аутрич базы данных, обработка ответов.
Организация.
Выступление.

Создание прибыльной организации

продюсирование художника

договор доступа, публикаций на нужных сайтах: арт ниша.

Сайт института, академии, культура.уз, арт-блог, арт верниссаж,

подготовка контента: текст для публикации.
публикация. Привязанная к «искусствоведческому анализу» и библиотеке для искусствоведов.

Расширение линейки продуктов галереи:

печатная продукция
сбыт печатной продукции, наладка сбыта на постоянную основу. Выбор поставщиков печатной продукции
продукция готовых принтов

Какие риски, проблемы я могу ожидать?

нехватка 5млн. в месяц
зашоренность.
непонятность позиции
недостаточное понимание предметной области(тут моделирование нужно делать)
неуспевание по срокам, не исправление/понимание в чем выражаются результаты ролей, и что ждут от исполнителя роли
непонимание задач, ведет к снижение мотивации, непонятно что зачем делать. К примеру страницу википедии я понимаю зачем делать, другое пока не понятно зачем.
нехватка времени на инструктаж.
попадание не в ту сферу, которой я буду недоволен.
недостаток роста - роста чего? скорее всего изменения, изменения состояния своих практик и трансдисциплин с одного состояния на другое, или даже недостаток скорости изменений.

разрыв между всем и вся, и поэтому падение продуктивности. Поэтому надо как-то адаптироваться. Что я могу сделать?
-— оффер с другой компании, я потеряю время вложенное в сотрудничество с другой компанией. Ничего, за то успею сделать полезное дело.
-— не хватит времени, интереса на курс практики развития. Схитрить — час тратить на курс, а час на кур онтологики, а после и на программу системного менеджмента, мышления и тд. Ежедневно, надо уже начинать, иначе никогда не вырасту так + интересно будет. Как раз возьму проект рабочий в виде той деятельности, которой занимаюсь.

Идеи по орг.изменениям в Дев.ио

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

Решение, план:

Что я могу сделать, чтобы снизить риски и проблемы в будущем:

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

Какие основные системы мы создаём и по каким этапам(жц):

работающий сайт. Рабочий документ. Что должны смочь с помощью этого рабочего документа/инструмента сделать пользователи?
контент на поисковиках и серверах арт тематики

на страницах сайтов

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

измененный я

с состояния новичка до реформатора, директора по развитию

орг.развитие — организация

школа
веб-студия (пока что)
галерея
цветочный магазин (вероятно)
PR and Publishing organization (вероятно)

студенты

студенты курса саморазвития
студенты прокрастинации

рабочие документы для бренда (эффект кредитности, доверия, авторитета в сфере):

база данных о местах
налаженные связи: люди, которые

описания с выполненных мастер-классов
фото-описания с событий для кредитности