Machine Learning World
Одна небольшая техническая статья однажды принесла моему маленькому аутсорсу клиента, который потенциально стоил намного больше, чем вся реклама, которую мы могли себе позволить. В то время я развивал небольшое направление по machine learning и искал клиентов.…
А потом сделал вещь, которую многие инженеры почему-то недооценивают - я подробно описал этот опыт в небольшой статье на Medium. Без "мы лучшая AI-компания". Без "10 лет экспертизы". Без рекламных обещаний. Просто технический кейс: вот устройство, вот проблема, вот что пришлось реверсить, вот как получали данные, вот что получилось.
Примерно за полтора месяца после публикации к нам пришли пять потенциальных клиентов. Причем им вообще не была нужна моя конкретная фитнес-идея. У каждого были свои продукты и свои задачи. Но всем требовался software, который мог глубоко работать с похожими wearable devices.
Они уже искали подрядчиков. Уже разговаривали с компаниями. Уже получали стандартные презентации про "сильную команду" и "индивидуальный подход". А потом находили статью человека, который уже руками сделал почти то, что им было нужно.
С одним из этих клиентов мы в итоге начали полноценную работу.
Именно тогда я окончательно понял, почему хороший technical content иногда продает лучше отдела sales. Клиент покупает не ваш красивый сайт. Он покупает снижение риска. Когда он видит реальный кейс, код, архитектурные решения, ограничения, ошибки и результат, ему уже не нужно верить вашим словам о компетентности. Он ее наблюдает.
Холодный sales говорит: "Мы умеем решить вашу проблему". Сильная инженерная статья говорит: "Вот похожая проблема. Вот как я ее уже решал". Между этими двумя фразами огромная разница.
Поэтому я считаю technical writing не маркетингом вокруг инженерии, а частью самой инженерной репутации. Одна правильная статья может не собрать миллионы просмотров. Но если ее прочитает один человек с проблемой на миллион долларов, этого вполне достаточно.
#заметкиархитектора
Примерно за полтора месяца после публикации к нам пришли пять потенциальных клиентов. Причем им вообще не была нужна моя конкретная фитнес-идея. У каждого были свои продукты и свои задачи. Но всем требовался software, который мог глубоко работать с похожими wearable devices.
Они уже искали подрядчиков. Уже разговаривали с компаниями. Уже получали стандартные презентации про "сильную команду" и "индивидуальный подход". А потом находили статью человека, который уже руками сделал почти то, что им было нужно.
С одним из этих клиентов мы в итоге начали полноценную работу.
Именно тогда я окончательно понял, почему хороший technical content иногда продает лучше отдела sales. Клиент покупает не ваш красивый сайт. Он покупает снижение риска. Когда он видит реальный кейс, код, архитектурные решения, ограничения, ошибки и результат, ему уже не нужно верить вашим словам о компетентности. Он ее наблюдает.
Холодный sales говорит: "Мы умеем решить вашу проблему". Сильная инженерная статья говорит: "Вот похожая проблема. Вот как я ее уже решал". Между этими двумя фразами огромная разница.
Поэтому я считаю technical writing не маркетингом вокруг инженерии, а частью самой инженерной репутации. Одна правильная статья может не собрать миллионы просмотров. Но если ее прочитает один человек с проблемой на миллион долларов, этого вполне достаточно.
#заметкиархитектора
👍3❤1
CRDT хорошо понимать не как "магическую eventual consistency", а как способ заранее определить такую структуру данных, которую разные узлы смогут менять независимо, а потом слить без конфликтов.
Возьмем OR-Set - Observed-Remove Set. Он нужен там, где несколько replica могут одновременно добавлять и удалять одни и те же элементы: collaborative apps, distributed caches, replicated metadata, shopping carts, multi-region storage.
Проблема обычного Set очень простая. Пусть replica A и B одновременно работают с элементом "x". A делает add("x"), а B - remove("x"). Потом сеть восстанавливается. Что должно победить?
OR-Set решает это не timestamp-ом, а уникальными тегами операций.
Когда A добавляет "x", она хранит не просто:
x
а, например:
(x, a1)
Если B независимо тоже добавит "x":
(x, b1)
Теперь множество логически содержит:
x -> {a1, b1}
Удаление работает хитрее. remove("x") удаляет только те теги, которые replica уже видела.
Возьмем OR-Set - Observed-Remove Set. Он нужен там, где несколько replica могут одновременно добавлять и удалять одни и те же элементы: collaborative apps, distributed caches, replicated metadata, shopping carts, multi-region storage.
Проблема обычного Set очень простая. Пусть replica A и B одновременно работают с элементом "x". A делает add("x"), а B - remove("x"). Потом сеть восстанавливается. Что должно победить?
OR-Set решает это не timestamp-ом, а уникальными тегами операций.
Когда A добавляет "x", она хранит не просто:
x
а, например:
(x, a1)
Если B независимо тоже добавит "x":
(x, b1)
Теперь множество логически содержит:
x -> {a1, b1}
Удаление работает хитрее. remove("x") удаляет только те теги, которые replica уже видела.
Machine Learning World
CRDT хорошо понимать не как "магическую eventual consistency", а как способ заранее определить такую структуру данных, которую разные узлы смогут менять независимо, а потом слить без конфликтов. Возьмем OR-Set - Observed-Remove Set. Он нужен там, где несколько…
Допустим, A видит только a1 и делает remove("x"). Она удаляет a1, но b1, созданный параллельно на B, остается.
После merge:
x -> {b1}
То есть concurrent add побеждает remove.
Это не случайность, а выбранная семантика.
Для merge нам снова нужны свойства:
merge(A, B) = merge(B, A)
merge(merge(A, B), C) = merge(A, merge(B, C))
merge(A, A) = A
Именно commutativity, associativity и idempotency позволяют доставлять обновления в любом порядке, повторять их и переживать network partition без coordinator.
Интересная часть начинается с масштаба. Если один логический элемент добавляли N раз, у него потенциально может накопиться O(N) уникальных tag-ов. Значит, CRDT не отменяет стоимость согласования - он переносит ее из runtime coordination в metadata.
И вот это важный архитектурный trade-off.
Мы можем платить latency на каждой операции через lock, leader или consensus. А можем разрешить локальные изменения мгновенно, но платить памятью, metadata и сложностью garbage collection позже.
CRDT полезны не потому, что "работают без конфликтов". Они полезны потому, что превращают конфликт из runtime-события в заранее определенную алгебру данных.
#заметкиархитектора #история
После merge:
x -> {b1}
То есть concurrent add побеждает remove.
Это не случайность, а выбранная семантика.
Для merge нам снова нужны свойства:
merge(A, B) = merge(B, A)
merge(merge(A, B), C) = merge(A, merge(B, C))
merge(A, A) = A
Именно commutativity, associativity и idempotency позволяют доставлять обновления в любом порядке, повторять их и переживать network partition без coordinator.
Интересная часть начинается с масштаба. Если один логический элемент добавляли N раз, у него потенциально может накопиться O(N) уникальных tag-ов. Значит, CRDT не отменяет стоимость согласования - он переносит ее из runtime coordination в metadata.
И вот это важный архитектурный trade-off.
Мы можем платить latency на каждой операции через lock, leader или consensus. А можем разрешить локальные изменения мгновенно, но платить памятью, metadata и сложностью garbage collection позже.
CRDT полезны не потому, что "работают без конфликтов". Они полезны потому, что превращают конфликт из runtime-события в заранее определенную алгебру данных.
#заметкиархитектора #история
👍3
This media is not supported in your browser
VIEW IN TELEGRAM
Делаю в свободное время разные тулзы для себя которые экономят время.
Сверху оригинал, снизу видео уже после обработки в Davinci Resolve.
Всю обработку делает AI через кастомный MCP через мост в Davinci Resolve.
Из плюшок которые есть уже сегодня:
- Обработка цвета через генерацию LUT'ов
- Нарезка (по звуку, по смене кадров, по тексту, по линии глаз)
- Работа с камерой (создание разноплановых сцен, зум, движение)
- Генерация текста с аудио и генерация субтитров
- Работа со звуком (выравнивание, контроль громкости, удаление долгих пауз, улучшение качества голоса у убирание шумов)
- Оптимизация через AI локальный для уменьшение сьедания токенов.
- Работа с простыми эффектами Fusion
В идеале хочу сделать комбайн который может делать качественные видео уровня крутого видеоредактора автоматом. Я конечно и сам это люблю, как и сьемку видео.. но увы времени нет вообще, а делать нужно много чего.
А как вы используете ИИ для упрощения своей жизни?
Сверху оригинал, снизу видео уже после обработки в Davinci Resolve.
Всю обработку делает AI через кастомный MCP через мост в Davinci Resolve.
Из плюшок которые есть уже сегодня:
- Обработка цвета через генерацию LUT'ов
- Нарезка (по звуку, по смене кадров, по тексту, по линии глаз)
- Работа с камерой (создание разноплановых сцен, зум, движение)
- Генерация текста с аудио и генерация субтитров
- Работа со звуком (выравнивание, контроль громкости, удаление долгих пауз, улучшение качества голоса у убирание шумов)
- Оптимизация через AI локальный для уменьшение сьедания токенов.
- Работа с простыми эффектами Fusion
В идеале хочу сделать комбайн который может делать качественные видео уровня крутого видеоредактора автоматом. Я конечно и сам это люблю, как и сьемку видео.. но увы времени нет вообще, а делать нужно много чего.
А как вы используете ИИ для упрощения своей жизни?
👍3
Есть алгоритмы, которые особенно хорошо показывают разницу между "посчитать точно" и "решить задачу правильно". MinHash - как раз такой случай.
Представим блокчейн-систему, где у нас есть миллионы адресов, транзакций или наборов взаимодействий. Например, мы хотим быстро находить кошельки, которые работают с похожим набором контрактов, токенов или контрагентов.
Самый прямой способ - взять два множества и посчитать Jaccard similarity:
intersection / union.
Если кошелек A взаимодействовал с 10 000 адресов, B - с 12 000, мы можем сравнить их множества напрямую. Для одной пары это не проблема. Для сотен миллионов пар начинается совершенно другая математика по CPU, памяти и времени.
Вот здесь появляется MinHash.
Идея почти смешно простая. Мы берем элементы множества, пропускаем их через несколько разных hash-функций и для каждой функции сохраняем только минимальное получившееся значение.
Вместо огромного множества у нас остается маленькая подпись - signature.
Представим блокчейн-систему, где у нас есть миллионы адресов, транзакций или наборов взаимодействий. Например, мы хотим быстро находить кошельки, которые работают с похожим набором контрактов, токенов или контрагентов.
Самый прямой способ - взять два множества и посчитать Jaccard similarity:
intersection / union.
Если кошелек A взаимодействовал с 10 000 адресов, B - с 12 000, мы можем сравнить их множества напрямую. Для одной пары это не проблема. Для сотен миллионов пар начинается совершенно другая математика по CPU, памяти и времени.
Вот здесь появляется MinHash.
Идея почти смешно простая. Мы берем элементы множества, пропускаем их через несколько разных hash-функций и для каждой функции сохраняем только минимальное получившееся значение.
Вместо огромного множества у нас остается маленькая подпись - signature.
Machine Learning World
Есть алгоритмы, которые особенно хорошо показывают разницу между "посчитать точно" и "решить задачу правильно". MinHash - как раз такой случай. Представим блокчейн-систему, где у нас есть миллионы адресов, транзакций или наборов взаимодействий. Например,…
Например, исходный кошелек может иметь 50 000 взаимодействий, а его MinHash signature - всего 128 чисел.
Самое красивое начинается дальше.
Если две MinHash signature совпали в 100 позициях из 128, то Jaccard similarity исходных множеств будет примерно 100 / 128 = 0.78.
То есть мы не сравнивали десятки тысяч элементов. Мы сравнили 128 чисел и получили хорошую оценку того, насколько похожи два множества.
Почему это работает? Для одной случайной hash-функции вероятность того, что минимальный hash двух множеств окажется одинаковым, равна их Jaccard similarity. Повторяя эксперимент много раз, мы получаем статистическую оценку.
В blockchain это можно использовать для clustering адресов, поиска похожего поведения, анализа transaction patterns, группировки контрактов по множествам пользователей, обнаружения почти одинаковых datasets и предварительного отбора кандидатов для более дорогого анализа.
Важно понимать: MinHash не отвечает на вопрос "одинаковые ли эти кошельки". Он дешево отвечает на другой вопрос: "какие пары вообще стоит сравнивать подробнее?"
И это гораздо более полезная архитектурная роль.
За пределами blockchain MinHash встречается практически везде, где объект можно представить множеством. Поиск дубликатов документов через наборы shingles. Similarity web pages. Recommendation systems. Поиск похожих пользователей. Deduplication больших data lakes. Анализ логов. Сравнение наборов features. Поиск почти одинаковых файлов или записей.
А вместе с Locality Sensitive Hashing можно уйти еще дальше и не сравнивать каждую signature с каждой, а быстро находить только вероятно похожие объекты.
Мне вообще нравится этот класс алгоритмов за одну важную инженерную идею.
На больших данных правильный вопрос часто звучит не "как посчитать абсолютно точно?"
А "какую минимальную информацию нужно сохранить, чтобы с высокой вероятностью принять правильное решение?"
#заметкиархитектора
Самое красивое начинается дальше.
Если две MinHash signature совпали в 100 позициях из 128, то Jaccard similarity исходных множеств будет примерно 100 / 128 = 0.78.
То есть мы не сравнивали десятки тысяч элементов. Мы сравнили 128 чисел и получили хорошую оценку того, насколько похожи два множества.
Почему это работает? Для одной случайной hash-функции вероятность того, что минимальный hash двух множеств окажется одинаковым, равна их Jaccard similarity. Повторяя эксперимент много раз, мы получаем статистическую оценку.
В blockchain это можно использовать для clustering адресов, поиска похожего поведения, анализа transaction patterns, группировки контрактов по множествам пользователей, обнаружения почти одинаковых datasets и предварительного отбора кандидатов для более дорогого анализа.
Важно понимать: MinHash не отвечает на вопрос "одинаковые ли эти кошельки". Он дешево отвечает на другой вопрос: "какие пары вообще стоит сравнивать подробнее?"
И это гораздо более полезная архитектурная роль.
За пределами blockchain MinHash встречается практически везде, где объект можно представить множеством. Поиск дубликатов документов через наборы shingles. Similarity web pages. Recommendation systems. Поиск похожих пользователей. Deduplication больших data lakes. Анализ логов. Сравнение наборов features. Поиск почти одинаковых файлов или записей.
А вместе с Locality Sensitive Hashing можно уйти еще дальше и не сравнивать каждую signature с каждой, а быстро находить только вероятно похожие объекты.
Мне вообще нравится этот класс алгоритмов за одну важную инженерную идею.
На больших данных правильный вопрос часто звучит не "как посчитать абсолютно точно?"
А "какую минимальную информацию нужно сохранить, чтобы с высокой вероятностью принять правильное решение?"
#заметкиархитектора
👍1
Друзі, нам до кінця дня треба зібрати 12500грн на закупівлю ліків від ФІП. На рахунках нулі.
Зібрано 700грн
Від цих ліків залежить чи будуть котики завтра живі чи ні. Благаю вашої допомоги
https://send.monobank.ua/jar/9tbJNeWg6U
Зібрано 700грн
Від цих ліків залежить чи будуть котики завтра живі чи ні. Благаю вашої допомоги
https://send.monobank.ua/jar/9tbJNeWg6U
send.monobank.ua
Безпечний переказ коштів
Надсилайте безкоштовно та безпечно кошти
Продакт: "Це маленька фіча". Я: фотографія Оппенгеймера. Підпис: "Я бачив такі “маленькі фічі”."
#жартипроандрія
#жартипроандрія
😁3
Forwarded from Andrey Nikishaev
Друзі, терміново треба ще 32тис грн інакше тварин викинуть з клініки на смерть. В нас немає чим оплатити рахунки
Благаю вас
https://send.monobank.ua/jar/9tbJNeWg6U
Благаю вас
https://send.monobank.ua/jar/9tbJNeWg6U
Я будую відмовостійкі системи. Коти тестують мене на відмову щодня.
Підписуйтесь на мої канали:
https://www.youtube.com/@MiiDosvid
https://xn--r1a.website/devs_world
https://xn--r1a.website/fe8courses
#жартипроандрія
Підписуйтесь на мої канали:
https://www.youtube.com/@MiiDosvid
https://xn--r1a.website/devs_world
https://xn--r1a.website/fe8courses
#жартипроандрія
🔥1😁1
Сон важливий. Навіть коти вже зрозуміли, що я зламався.
Підписуйтесь на мої канали:
https://www.youtube.com/@MiiDosvid
https://xn--r1a.website/devs_world
https://xn--r1a.website/fe8courses
#жартипроандрія
Підписуйтесь на мої канали:
https://www.youtube.com/@MiiDosvid
https://xn--r1a.website/devs_world
https://xn--r1a.website/fe8courses
#жартипроандрія
😁2❤1👍1
В житті головне мати правильні пріоритети
Підписуйтесь на мої канали:
https://www.youtube.com/@MiiDosvid
https://xn--r1a.website/devs_world
https://xn--r1a.website/fe8courses
#жартипроандрія
Підписуйтесь на мої канали:
https://www.youtube.com/@MiiDosvid
https://xn--r1a.website/devs_world
https://xn--r1a.website/fe8courses
#жартипроандрія
👍1🔥1
Winter Is Coming... Потрібно утеплюватися. Добре, що в мене 14 котів.
Підписуйтесь на мої канали:
https://www.youtube.com/@MiiDosvid
https://xn--r1a.website/devs_world
https://xn--r1a.website/fe8courses
#жартипроандрія
Підписуйтесь на мої канали:
https://www.youtube.com/@MiiDosvid
https://xn--r1a.website/devs_world
https://xn--r1a.website/fe8courses
#жартипроандрія
❤1👍1🔥1😁1
Ніколи не робіть подібну аналітику якщо хочете знайти роботу дата саєнтистом. Кому цікаво чому(якщо не зрозуміло) - задавайте питання в коментах
https://lnkd.in/p/dm_FjZ6q
https://lnkd.in/p/dm_FjZ6q
LinkedIn
"Інформація – це нафта ХХІ століття" – ніколи не здогадаєтесь, чий це був слоган, відповідь в кінці. Проаналізував з АІ приблизно…
"Інформація – це нафта ХХІ століття" – ніколи не здогадаєтесь, чий це був слоган, відповідь в кінці. Проаналізував з АІ приблизно 1 220 294 відео з українського ютуб в 25 категоріях і реакції глядачів на них. Щоб що? Щоб зрозуміти, на що взагалі можна розраховувати…
😁2👍1🔥1
Forwarded from Devs World
Оплачувати їх лікування нічим. 8 важких тварин в клініці, через 2 дні потрібно оплатити рахунок. А платити нічим, ліки купити теж немає за що.
Волонтерство просто вмирає, бачу це по іншим. Більшість просто не витримує і уходить. Тому що тягнути витрати в 1М грн щомісяця, і збирати третину безкінченно не вийде, рано чи піздно приїдуть люди у бобіку з автоматами і заберуть усе що мав. Бо гроші не беруться з повітря, а лікарні та аптеки безкоштовно не працюють, як і всі окрім волонтерів (бо ми їбаньки).
Поки Єрмаки, Притули, Стерненки будували своє краще життя за чужий рахунок, я за всі 11 років волонтерства не взяв собі ні копійки, лише докладав свої.
Якщо порахувати то ці роки волонтерства це декілька квартир в Києві, красивий порше чи інеос, дача за містом, можливо ще щось. Але все що маю наразі це однокімнатна з 14ма котами, і то може статися так що заберуть і її.
І я не прошу вас полегшити моє життя, я прошу вас полегшити їх, бо окрім нас з вами в них більше нікого немає, і ніхто їм не допоможе.
Волонтерство просто вмирає, бачу це по іншим. Більшість просто не витримує і уходить. Тому що тягнути витрати в 1М грн щомісяця, і збирати третину безкінченно не вийде, рано чи піздно приїдуть люди у бобіку з автоматами і заберуть усе що мав. Бо гроші не беруться з повітря, а лікарні та аптеки безкоштовно не працюють, як і всі окрім волонтерів (бо ми їбаньки).
Поки Єрмаки, Притули, Стерненки будували своє краще життя за чужий рахунок, я за всі 11 років волонтерства не взяв собі ні копійки, лише докладав свої.
Якщо порахувати то ці роки волонтерства це декілька квартир в Києві, красивий порше чи інеос, дача за містом, можливо ще щось. Але все що маю наразі це однокімнатна з 14ма котами, і то може статися так що заберуть і її.
І я не прошу вас полегшити моє життя, я прошу вас полегшити їх, бо окрім нас з вами в них більше нікого немає, і ніхто їм не допоможе.
❤1
Forwarded from Devs World
Я не прошу багато хто скільки може + лайк + комент + репост. Це не так багато, для того щоб зберегти чиєсь життя.
https://uah.fund/donate
https://uah.fund/donate
❤2
Forwarded from Devs World
Как и обещал шерю код скрин шеринга для мака https://github.com/creotiv/mac-screen-share
GitHub
GitHub - creotiv/mac-screen-share: Sharing screen from Mac to any device
Sharing screen from Mac to any device. Contribute to creotiv/mac-screen-share development by creating an account on GitHub.
😁1