Очень интересная точка зрения основателя Tobiko (SQLMesh) — главного конкурента dbt.
Мы тут были в восторге от новой фичи dbt: он стал значительно быстрее, потому что его переписали на Rust. Логично, что переписывание старого движка дало мощный прирост в скорости, и выбор Rust очевидно удачный.
Но мы так привыкли к "бесплатному" и хорошо работающему dbt Core, что воспринимаем это как должное. А вот из-за такой "данности" компания dbt Labs теряет деньги. А им ведь ещё нужно отчитываться перед инвесторами.
Вот с Airflow и Airbyte всегда было проще, косяк на косяке=) (вот только не говорите мне, что "готовить не умею", я бы тогда просто-бы макросы VBA "приготовил бы"🧐 )
Вот и сам текст:
dbt Fusion — это полная переработка dbt Core на языке Rust. В отличие от dbt Core, который является полностью бесплатным и с открытым исходным кодом под лицензией Apache 2.0, dbt Fusion — это не open-source проект, так как распространяется по более ограничительной лицензии Elastic 2.0.
Хотя Fusion и можно использовать бесплатно, его лицензия запрещает использование в хостинговых или управляемых решениях третьими сторонами. Возможно, это кажется незначительным, но у этого ограничения есть серьёзные последствия.
Открытый исходный код хорош тем, что он стимулирует как отдельных разработчиков, так и компании инвестировать в развитие продукта без риска. Компания может полностью полагаться на open-source решение, потому что в любом случае его можно форкнуть и использовать в своих целях, независимо от решений основного разработчика. Лицензия с ограничениями, такая как Elastic, наоборот, демотивирует компании вкладываться в развитие продукта.
Не поймите неправильно: в решении dbt Labs нет ничего неэтичного. Более того, с финансовой точки зрения для них это может быть наиболее разумным шагом. Но важно понять, как мы к этому пришли и что это может значить для будущего dbt Core.
Мне кажется, стратегия dbt заключается в том, чтобы перевести dbt Core в режим поддержки (maintenance mode), сосредоточившись на Fusion и других коммерческих продуктах. Формулировки в анонсе были выбраны очень осторожно и расплывчато. В частности, говоря о поддержке dbt Core, они упомянули только исправление багов, обновления безопасности и поддержание совместимости.
Согласно их роадмапу, они отделили dbt-язык от runtime-движка. Также отдельно подчёркивается, что Fusion и Core со временем неизбежно разойдутся, поскольку Fusion обладает возможностями, которые невозможно добавить в Core. По моему мнению, dbt Labs используют эту возможность, чтобы сосредоточиться на более ограниченном и прибыльном софте, постепенно сворачивая то, что сделало их знаменитыми, но одновременно мешает их финансовому росту.
В конечном итоге ресурсы ограничены, и компании вынуждены расставлять приоритеты исходя из интересов бизнеса.
Учитывая фундаментальное значение dbt Core для современной аналитической инфраструктуры, аналитики и инженеры данных заслуживают свободную, открытую и постоянно развивающуюся платформу для трансформации данных. В противном случае ваша карьера окажется слишком зависимой от решений одной-единственной компании. Чтобы обеспечить непрерывные инновации в области data-трансформаций, возможно, пришло время начать дискуссию об открытом стандарте описания трансформаций данных.
Посмотрим как долго SQLMesh будет открытый (то есть как долго будет экономика сходится)🔪
Мы тут были в восторге от новой фичи dbt: он стал значительно быстрее, потому что его переписали на Rust. Логично, что переписывание старого движка дало мощный прирост в скорости, и выбор Rust очевидно удачный.
Но мы так привыкли к "бесплатному" и хорошо работающему dbt Core, что воспринимаем это как должное. А вот из-за такой "данности" компания dbt Labs теряет деньги. А им ведь ещё нужно отчитываться перед инвесторами.
Вот с Airflow и Airbyte всегда было проще, косяк на косяке=) (вот только не говорите мне, что "готовить не умею", я бы тогда просто-бы макросы VBA "приготовил бы"
Вот и сам текст:
dbt Fusion — это полная переработка dbt Core на языке Rust. В отличие от dbt Core, который является полностью бесплатным и с открытым исходным кодом под лицензией Apache 2.0, dbt Fusion — это не open-source проект, так как распространяется по более ограничительной лицензии Elastic 2.0.
Хотя Fusion и можно использовать бесплатно, его лицензия запрещает использование в хостинговых или управляемых решениях третьими сторонами. Возможно, это кажется незначительным, но у этого ограничения есть серьёзные последствия.
Открытый исходный код хорош тем, что он стимулирует как отдельных разработчиков, так и компании инвестировать в развитие продукта без риска. Компания может полностью полагаться на open-source решение, потому что в любом случае его можно форкнуть и использовать в своих целях, независимо от решений основного разработчика. Лицензия с ограничениями, такая как Elastic, наоборот, демотивирует компании вкладываться в развитие продукта.
Не поймите неправильно: в решении dbt Labs нет ничего неэтичного. Более того, с финансовой точки зрения для них это может быть наиболее разумным шагом. Но важно понять, как мы к этому пришли и что это может значить для будущего dbt Core.
Мне кажется, стратегия dbt заключается в том, чтобы перевести dbt Core в режим поддержки (maintenance mode), сосредоточившись на Fusion и других коммерческих продуктах. Формулировки в анонсе были выбраны очень осторожно и расплывчато. В частности, говоря о поддержке dbt Core, они упомянули только исправление багов, обновления безопасности и поддержание совместимости.
Согласно их роадмапу, они отделили dbt-язык от runtime-движка. Также отдельно подчёркивается, что Fusion и Core со временем неизбежно разойдутся, поскольку Fusion обладает возможностями, которые невозможно добавить в Core. По моему мнению, dbt Labs используют эту возможность, чтобы сосредоточиться на более ограниченном и прибыльном софте, постепенно сворачивая то, что сделало их знаменитыми, но одновременно мешает их финансовому росту.
В конечном итоге ресурсы ограничены, и компании вынуждены расставлять приоритеты исходя из интересов бизнеса.
Учитывая фундаментальное значение dbt Core для современной аналитической инфраструктуры, аналитики и инженеры данных заслуживают свободную, открытую и постоянно развивающуюся платформу для трансформации данных. В противном случае ваша карьера окажется слишком зависимой от решений одной-единственной компании. Чтобы обеспечить непрерывные инновации в области data-трансформаций, возможно, пришло время начать дискуссию об открытом стандарте описания трансформаций данных.
Посмотрим как долго SQLMesh будет открытый (то есть как долго будет экономика сходится)
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡19🐳6🌚3❤🔥1🤷♂1
Forwarded from Книжный куб (Alexander Polomodov)
AI-помощники при работе с кодом. Взгляд в будущее - Евгений Колесников - Platform Engineering Night (Рубрика #AI)
Крутое выступление Евгения из команды Yandex Infrastructure, в котором он делится глубокими мыслями про развитие AI copilot инструментами. Женя выступал с этим докладом на Platform Engineering Night в Т-Банке. Я уже рассказывал про выступления моих коллег оттуда: "AI и Platform Engineering" от Игоря Маслова и "Разработка собственного AI-ассистента для кода: спринт или марафон?" Дениса Артюшина. Ребята рассказывали про наши подходы к интеграции AI в SDLC) и интересно сравнить мысли из тех докладов с идеями Жени, что я постарался изложить ниже
1. Реальность разработки
По стате разработчики пишут код всего 40 минут - 120 минут в день, при этом комитят в среднем только 40 строк кода в день. Основная проблема не в скорости печати, а в сложности мыслительных процессов, что идут на трех уровнях
- Ментальная модель - что мы хотим сделать
- Семантическая модель - как мы это будем делать
- Синтаксическая модель - непосредственно сам код
ИИ сейчас помогает в основном на последнем этапе, что объясняет ограниченность эффекта.
2. Режимы работы разработчиков
Существуют два основных режима:
- Flow - сотояние потока, когда код "летит из-под пальцев". Интересно, что в DevEx фреймворке Flow - это одна из составлящих, кстати, я делал обзор whitepaper о нем
- Exploration - поиск информации в документации, интернете, общение с ИИ
Понимание этих режимов критично для эффективного использования ИИ-инструментов.
3. Чего хотят разработчики от ИИ
По мнению Евгения ожидания инженеров такие
- Переложить на AI рутинные операции, например, написание юнит-тестов
- Общаться на естественном языке с последующим уточнением через промпты
- Получить детерминированные результаты от недетерминированного genAI
Интересно, что у Google был whitepaper буквально с таким названием "What Do Developers Want From AI?" - я его разбирал раньше, а потом еще записал эпизод подкаста "Research Insights" вместе с моим коллегой, Колей Бушковым, где мы разбирали этот whitepaper
4. Бизнес-приоритеты
Бизнес хочет сокращения time to market, снижения издержек, а также предсказуемости. Но обычно все упирают на сокращение издержек, когда говорят, что "90% кода будет писаться ИИ". Но часто это не означает увольнение 90% программистов, а увеличение продуктивности существующих команд. Евгений привел пример Дарио Амодея с его тезисами из цитаты выше - а я разбирал это выступление раньше
5. Проблема измерения эффективности
Критически относитесь к цифрам вроде "повышение продуктивности на 55%". Продуктивность - неопределенный термин, зависящий от множества факторов. Пока нет единого способа точно измерить пользу от ИИ-инструментов. Интересно, что я уже пару раз выступал с темой навроде "Зачем заниматься темой developer productivity в большой компании"
6. LLM ≠ Продукт
Использование последней языковой модели не гарантирует успех продукта. UX/UI, правильный промптинг и интеграция в рабочий процесс часто важнее, чем выбор конкретной модели.
7. Правильные метрики
Стоит измерять NPS, CSAT в связке с retention (у SourceCraft от Yandex между 60-70%), cycle time, lead time и влияние на бизнес-метрики. Метрика счастья пользователя - интегральный показатель принятия/отклонения подсказок.
8. Снижение хайпа - это хорошо
За 2023-2024 год интерес к ИИ в некоторых областях упал и это хорошо - разработчики начинают реалистично оценивать возможности и ограничения ИИ-инструментов, что ведет к более эффективному использованию.
9. Будущее: от генерации к агентам
Развитие сейчас идет от генеративных моделей к агентским. Агенты проактивно решают задачи, но пока крайне ненадежны. Следующий этап развития - сделать агентов более надежными и предсказуемыми. Чем глубже интеграция ИИ в инфраструктуру компании, тем больше выигрыш.
Если подводить итоги, то Евгений считает, что AI-помощники однозначно полезны, но важно понимать их ограничения и правильно интегрировать в рабочий процесс, а не гнаться за хайпом.
#AI #Software #Engineering #Architecture #Agents
Крутое выступление Евгения из команды Yandex Infrastructure, в котором он делится глубокими мыслями про развитие AI copilot инструментами. Женя выступал с этим докладом на Platform Engineering Night в Т-Банке. Я уже рассказывал про выступления моих коллег оттуда: "AI и Platform Engineering" от Игоря Маслова и "Разработка собственного AI-ассистента для кода: спринт или марафон?" Дениса Артюшина. Ребята рассказывали про наши подходы к интеграции AI в SDLC) и интересно сравнить мысли из тех докладов с идеями Жени, что я постарался изложить ниже
1. Реальность разработки
По стате разработчики пишут код всего 40 минут - 120 минут в день, при этом комитят в среднем только 40 строк кода в день. Основная проблема не в скорости печати, а в сложности мыслительных процессов, что идут на трех уровнях
- Ментальная модель - что мы хотим сделать
- Семантическая модель - как мы это будем делать
- Синтаксическая модель - непосредственно сам код
ИИ сейчас помогает в основном на последнем этапе, что объясняет ограниченность эффекта.
2. Режимы работы разработчиков
Существуют два основных режима:
- Flow - сотояние потока, когда код "летит из-под пальцев". Интересно, что в DevEx фреймворке Flow - это одна из составлящих, кстати, я делал обзор whitepaper о нем
- Exploration - поиск информации в документации, интернете, общение с ИИ
Понимание этих режимов критично для эффективного использования ИИ-инструментов.
3. Чего хотят разработчики от ИИ
По мнению Евгения ожидания инженеров такие
- Переложить на AI рутинные операции, например, написание юнит-тестов
- Общаться на естественном языке с последующим уточнением через промпты
- Получить детерминированные результаты от недетерминированного genAI
Интересно, что у Google был whitepaper буквально с таким названием "What Do Developers Want From AI?" - я его разбирал раньше, а потом еще записал эпизод подкаста "Research Insights" вместе с моим коллегой, Колей Бушковым, где мы разбирали этот whitepaper
4. Бизнес-приоритеты
Бизнес хочет сокращения time to market, снижения издержек, а также предсказуемости. Но обычно все упирают на сокращение издержек, когда говорят, что "90% кода будет писаться ИИ". Но часто это не означает увольнение 90% программистов, а увеличение продуктивности существующих команд. Евгений привел пример Дарио Амодея с его тезисами из цитаты выше - а я разбирал это выступление раньше
5. Проблема измерения эффективности
Критически относитесь к цифрам вроде "повышение продуктивности на 55%". Продуктивность - неопределенный термин, зависящий от множества факторов. Пока нет единого способа точно измерить пользу от ИИ-инструментов. Интересно, что я уже пару раз выступал с темой навроде "Зачем заниматься темой developer productivity в большой компании"
6. LLM ≠ Продукт
Использование последней языковой модели не гарантирует успех продукта. UX/UI, правильный промптинг и интеграция в рабочий процесс часто важнее, чем выбор конкретной модели.
7. Правильные метрики
Стоит измерять NPS, CSAT в связке с retention (у SourceCraft от Yandex между 60-70%), cycle time, lead time и влияние на бизнес-метрики. Метрика счастья пользователя - интегральный показатель принятия/отклонения подсказок.
8. Снижение хайпа - это хорошо
За 2023-2024 год интерес к ИИ в некоторых областях упал и это хорошо - разработчики начинают реалистично оценивать возможности и ограничения ИИ-инструментов, что ведет к более эффективному использованию.
9. Будущее: от генерации к агентам
Развитие сейчас идет от генеративных моделей к агентским. Агенты проактивно решают задачи, но пока крайне ненадежны. Следующий этап развития - сделать агентов более надежными и предсказуемыми. Чем глубже интеграция ИИ в инфраструктуру компании, тем больше выигрыш.
Если подводить итоги, то Евгений считает, что AI-помощники однозначно полезны, но важно понимать их ограничения и правильно интегрировать в рабочий процесс, а не гнаться за хайпом.
#AI #Software #Engineering #Architecture #Agents
YouTube
Евгений Колесников — «AI-помощники при работе с кодом. Взгляд в будущее»
ИИ-помощников при работе с кодом становится все больше: могут встречаться yet another LLM-wrapper или отдельные IDE. В докладе рассмотрели, какие инструменты бывают, как измерять качество и определять, что идем в правильном направлении при создании инструментов…
⚡22❤🔥8🌚1
Изучая новости отчественных облаков обратил внимание на ключевые тезисы из дискуссии «Озера данных для конкурентоспобности бизнеса».
1. Компании инвестируют в озера данных сейчас, даже если не видят большого эффекта. Через несколько лет догонять лидеров в этой гонке будет сложно.
2. Мы идем к тому, что компании, которые не используют Data Lakehouse, будут считаться отстающими на Х лет.
3. Для многих компаний работа с большими данными — инвестиция вдолгую. Впереди — выработка методологии для правильной оценки эффекта, который принесут объемы вложенных ресурсов.
4. Перед бизнесом стоит организационный вызов: нужно научить отделы внутри компаний делиться данными и, возможно, идти в сторону отраслевых хранилищ с обезличенными данными.
5. Средний объем корпоративных хранилищ данных перешагнул порог 500 Тб.
6. Подобрать инфраструктуру для работы с большими данными сложно, поскольку ошибки при выборе провайдера могут сильно помешать масштабироваться на долгой дистанции.
К самим тезисам и облачным продуктам вопросов нет - уверен, озёра данных действительно рулят: они хранят большие объёмы информации, даже в формате Iceberg. Но тема-то заявлена - «конкурентоспособность бизнеса».
Подобные посты часто публикуют и Yandex Cloud, и Arenadata. Но такой контент не создаёт ценности - он ориентирован на нетехнических пользователей. Обычно таким читателям неважно, сколько там терабайт, и вряд ли они поймут разницу между lakehouse и data warehouse.
Складывается впечатление, что компании должны внедрять озёра данных просто потому, что «все внедряют». И если вы ещё не внедрили и не мигрировали - то вам, по сути, нечем будет «мериться». Сколько у кого терабайт? Сколько кластеров? Сколько табличек?
Кстати, западные вендоры уже ушли от такого подхода. Они либо делают упор на бизнес-результат и намеренно опускают технические детали, либо наоборот - таргетируют глубоко техническую аудиторию и погружаются в детали. То есть аудиторию чётко сегментируют.
Этот подход хорошо иллюстрирует пример с резюме. Вы можете описать свой опыт через output:
- количество таблиц
- количество пайплайнов
- количество дашбордов
- количество PR
- количество строк кода
- миграция из А в Б
- внедрение А, Б, В
Но в этом мало ценности. Ценность - в outcome, в пользе, которую вы принесли. Написать резюме, в котором будет баланс между технологиями и бизнес-ценностью, - непростая задача. Особенно если его нужно уместить в две страницы.
PS мне нравятся продукты yandex, vk, arenadata, проделана колоссальная работа и созданы отличные решения. Просто улыбнул факт подачи информации о ценности для бизнеса, напомнил мне собеседования и резюме. Всегда хочется рассказать про детали, но они не так важны.
1. Компании инвестируют в озера данных сейчас, даже если не видят большого эффекта. Через несколько лет догонять лидеров в этой гонке будет сложно.
2. Мы идем к тому, что компании, которые не используют Data Lakehouse, будут считаться отстающими на Х лет.
3. Для многих компаний работа с большими данными — инвестиция вдолгую. Впереди — выработка методологии для правильной оценки эффекта, который принесут объемы вложенных ресурсов.
4. Перед бизнесом стоит организационный вызов: нужно научить отделы внутри компаний делиться данными и, возможно, идти в сторону отраслевых хранилищ с обезличенными данными.
5. Средний объем корпоративных хранилищ данных перешагнул порог 500 Тб.
6. Подобрать инфраструктуру для работы с большими данными сложно, поскольку ошибки при выборе провайдера могут сильно помешать масштабироваться на долгой дистанции.
К самим тезисам и облачным продуктам вопросов нет - уверен, озёра данных действительно рулят: они хранят большие объёмы информации, даже в формате Iceberg. Но тема-то заявлена - «конкурентоспособность бизнеса».
Подобные посты часто публикуют и Yandex Cloud, и Arenadata. Но такой контент не создаёт ценности - он ориентирован на нетехнических пользователей. Обычно таким читателям неважно, сколько там терабайт, и вряд ли они поймут разницу между lakehouse и data warehouse.
Складывается впечатление, что компании должны внедрять озёра данных просто потому, что «все внедряют». И если вы ещё не внедрили и не мигрировали - то вам, по сути, нечем будет «мериться». Сколько у кого терабайт? Сколько кластеров? Сколько табличек?
Кстати, западные вендоры уже ушли от такого подхода. Они либо делают упор на бизнес-результат и намеренно опускают технические детали, либо наоборот - таргетируют глубоко техническую аудиторию и погружаются в детали. То есть аудиторию чётко сегментируют.
Этот подход хорошо иллюстрирует пример с резюме. Вы можете описать свой опыт через output:
- количество таблиц
- количество пайплайнов
- количество дашбордов
- количество PR
- количество строк кода
- миграция из А в Б
- внедрение А, Б, В
Но в этом мало ценности. Ценность - в outcome, в пользе, которую вы принесли. Написать резюме, в котором будет баланс между технологиями и бизнес-ценностью, - непростая задача. Особенно если его нужно уместить в две страницы.
PS мне нравятся продукты yandex, vk, arenadata, проделана колоссальная работа и созданы отличные решения. Просто улыбнул факт подачи информации о ценности для бизнеса, напомнил мне собеседования и резюме. Всегда хочется рассказать про детали, но они не так важны.
⚡11❤🔥6💯6🐳2
Все знакомы с понятием Ad-hoc запросов. Обычно мы воспринимаем их негативно, так как они отвлекают, время-то и так мало.
На самом деле, ad-hoc запросы могут бысть источником quick wins, и способом быстро показать impact и завоевать доверие (earn trust).
Ad-hoc — это не бардак. Это VIP-запросы, которые показывают: вам доверяют. Ваша задача - не утонуть, а превратить это в рычаг для влияния.
Вот пример фреймфорка:
1. Принять быстро
Ответ в течение пары минут (или автоответ, если в фокусе) показывает: у нас есть процесс, а не паника.
2. Быстрое фильтрование (2 минуты):
- Это повлияет на $Xk+ или стратегию?
- Нужно на этой неделе для принятия решений?
- Делается за полдня одним аналитиком?
- Если да → делаем. Если нет - в бэклог с пометкой по приоритету.
3. Минимум, но по делу
- Отправляем краткий инсайт, график или SQL - что реально помогает. Повторилось 3 раза? → автоматизация.
📌 Чтобы не сгореть:
- Назначаем on-call-аналитика/инженера (10% времени спринта)
- Не забываем про ротацию и отслеживание нагрузки
- Повторяемые запросы → обучающие материалы или дашборды
Эскалации - через менеджера, не через «договорился в курилке».
На самом деле, ad-hoc запросы могут бысть источником quick wins, и способом быстро показать impact и завоевать доверие (earn trust).
Ad-hoc — это не бардак. Это VIP-запросы, которые показывают: вам доверяют. Ваша задача - не утонуть, а превратить это в рычаг для влияния.
Вот пример фреймфорка:
1. Принять быстро
Ответ в течение пары минут (или автоответ, если в фокусе) показывает: у нас есть процесс, а не паника.
2. Быстрое фильтрование (2 минуты):
- Это повлияет на $Xk+ или стратегию?
- Нужно на этой неделе для принятия решений?
- Делается за полдня одним аналитиком?
- Если да → делаем. Если нет - в бэклог с пометкой по приоритету.
3. Минимум, но по делу
- Отправляем краткий инсайт, график или SQL - что реально помогает. Повторилось 3 раза? → автоматизация.
📌 Чтобы не сгореть:
- Назначаем on-call-аналитика/инженера (10% времени спринта)
- Не забываем про ротацию и отслеживание нагрузки
- Повторяемые запросы → обучающие материалы или дашборды
Эскалации - через менеджера, не через «договорился в курилке».
1💯55❤🔥22🗿4⚡1
Data-driven культура часто выглядит как BI инструмент(ы) с метриками и дашбордами + хранилище данных (хотя уже модно делать Data Lakeuse на 500ТБ 🤔 ).
В идеале культура, основанная на данных, должна включать три ключевых элемента — так называемый 3P framework:
- People - вовлечённые сотрудники и поддержка со стороны руководства.
- Platform - удобные и доступные инструменты (BI-системы, дашборды, ноутбуки, хранилища и т. п.).
- Process - процессы, которые помогают извлекать инсайты и превращать их в действия, с акцентом на качество данных, метрики и бизнес-приоритеты.
В такой культуре важно позволять людям экспериментировать с данными, поощрять стремление к обучению и развитию, задавать бизнес-вопросы, формулировать гипотезы и проверять их.
Способность находить закономерности в данных, предлагать улучшения и отслеживать их влияние на бизнес — одна из ключевых ценностей data-led подхода.
Несколько практик, которые помогают достичь такого уровня зрелости:
🎮 Проведение хакатонов и вовлечение бизнес-пользователей в работу с данными.
🙂 Отправка аналитиков и инженеров "в поля", чтобы на практике понять, как устроен бизнес, как генерируются данные и как аналитические решения влияют на процессы.
⚡️ Временная интеграция аналитиков и инженеров в бизнес-команды для более глубокого погружения в задачи и контекст.
Вообще парадокс, в маленькой компании или стартапе достаточно завести эксельку и вести учет нескольких показателей и вы уже data-driven. А вот в большой корпарации у вас может быть 10 хранилищ, 5 озер, 7 BI, и армия аналитиков и инженеров, и вы нифига не data-driven🤣
В идеале культура, основанная на данных, должна включать три ключевых элемента — так называемый 3P framework:
- People - вовлечённые сотрудники и поддержка со стороны руководства.
- Platform - удобные и доступные инструменты (BI-системы, дашборды, ноутбуки, хранилища и т. п.).
- Process - процессы, которые помогают извлекать инсайты и превращать их в действия, с акцентом на качество данных, метрики и бизнес-приоритеты.
В такой культуре важно позволять людям экспериментировать с данными, поощрять стремление к обучению и развитию, задавать бизнес-вопросы, формулировать гипотезы и проверять их.
Способность находить закономерности в данных, предлагать улучшения и отслеживать их влияние на бизнес — одна из ключевых ценностей data-led подхода.
Несколько практик, которые помогают достичь такого уровня зрелости:
Вообще парадокс, в маленькой компании или стартапе достаточно завести эксельку и вести учет нескольких показателей и вы уже data-driven. А вот в большой корпарации у вас может быть 10 хранилищ, 5 озер, 7 BI, и армия аналитиков и инженеров, и вы нифига не data-driven
Please open Telegram to view this post
VIEW IN TELEGRAM
💯42
Ищете работу на международном рынке?
Тогда канал Connectable Jobs будет полезен для вас. Ребята собирают вакансии в международных стартапах с русскоязычными фаундерами, делятся важной информацией про команды и инвестиции, а также прямыми контактами HR для удобного отклика.
Вот несколько актуальных вакансий таких компаниях:
— Head of Data в Manychat
— Data Engineer в Constructor
— Lead of Engineering в Appodeal
Еще у Connectable Jobs есть отдельный канал для разработчиков и инженеров, где публикуются вакансии только в этой области.
Подписывайтесь и развивайте карьеру в будущем единороге 🚀
Тогда канал Connectable Jobs будет полезен для вас. Ребята собирают вакансии в международных стартапах с русскоязычными фаундерами, делятся важной информацией про команды и инвестиции, а также прямыми контактами HR для удобного отклика.
Вот несколько актуальных вакансий таких компаниях:
— Head of Data в Manychat
— Data Engineer в Constructor
— Lead of Engineering в Appodeal
Еще у Connectable Jobs есть отдельный канал для разработчиков и инженеров, где публикуются вакансии только в этой области.
Подписывайтесь и развивайте карьеру в будущем единороге 🚀
Telegram
Connectable Jobs
Вакансии от 300+ зарубежных компаний с русскоговорящими фаундерами или командами. Наши читатели уже получили офферы в InDrive, Revolut, Wallet, JetBrains и др. 💙
Разместить вакансию: https://forms.gle/K5KiBsaqo6Tp2sje8
Q&A: @connectable_jobs_team
Разместить вакансию: https://forms.gle/K5KiBsaqo6Tp2sje8
Q&A: @connectable_jobs_team
❤🔥6
Всем хороших выходных! Для меня бутылочка сидра в компании жены лучшая награда за 6 рабочих дней:)
PS в пятницу записал для Surfalytics первый эпизод mock Data Engineering System Design interview, использовали Azure cloud.
PPS интересный факт, стаканы из IKEA, но made in Russia😊
PS в пятницу записал для Surfalytics первый эпизод mock Data Engineering System Design interview, использовали Azure cloud.
PPS интересный факт, стаканы из IKEA, но made in Russia😊
1⚡39❤🔥34💯7🐳6🫡1
Недавно увидел хорошие термины про тип работы - deep work vs shallow work.
Deep work - глубокое погружение в работу, которое позволяет сосредоточиться на проблеме, изучить необходимые технологии и процессы. Обычно такая работа требует как минимум несколько часов без отвлечений, и по окончании процесса вы получаете удовлетворение. От такой напряжённой работы вы не так устаете и не выгораете.
Shallow work, напротив, - это работа урывками, когда часто меняется контекст между задачами и проектами.
Даже хорошо спланированную работу в формате deep work можно легко превратить в shallow work. Достаточно начать реагировать на сообщения в мессенджере от коллег, менеджеров, друзей. Или участвовать в частых митингах.
Вот и получается: вроде день прошёл, а результата ноль.
Мне лично помогает несложное кольцо действий:
1. составить список 2–3 важных дел на день
2. не переключаться на новое дело, пока не закончу первое
3. блоки deep work в календаре, которые отменяют все встречи - они у меня стоят на год вперёд
Так же можно запланировать дела на неделю, добавив в них личные дела. Свой календарь я не разделяю на личный и рабочий.
Лично для вас будет эффективнее и приятнее выполнить от начала до конца одно важное дело, чем ответить всем подряд в мессенджерах, сходить на несколько митингов и при этом задержаться на работе на несколько часов - всё равно без результатов.
Deep work - глубокое погружение в работу, которое позволяет сосредоточиться на проблеме, изучить необходимые технологии и процессы. Обычно такая работа требует как минимум несколько часов без отвлечений, и по окончании процесса вы получаете удовлетворение. От такой напряжённой работы вы не так устаете и не выгораете.
Shallow work, напротив, - это работа урывками, когда часто меняется контекст между задачами и проектами.
Даже хорошо спланированную работу в формате deep work можно легко превратить в shallow work. Достаточно начать реагировать на сообщения в мессенджере от коллег, менеджеров, друзей. Или участвовать в частых митингах.
Вот и получается: вроде день прошёл, а результата ноль.
Мне лично помогает несложное кольцо действий:
1. составить список 2–3 важных дел на день
2. не переключаться на новое дело, пока не закончу первое
3. блоки deep work в календаре, которые отменяют все встречи - они у меня стоят на год вперёд
Так же можно запланировать дела на неделю, добавив в них личные дела. Свой календарь я не разделяю на личный и рабочий.
Лично для вас будет эффективнее и приятнее выполнить от начала до конца одно важное дело, чем ответить всем подряд в мессенджерах, сходить на несколько митингов и при этом задержаться на работе на несколько часов - всё равно без результатов.
2⚡62💯46❤🔥16👨💻4
Forwarded from CEO Readz
📖 SLOW PRODUCTIVITY: THE LOST ART OF ACCOMPLISHMENT WITHOUT BURNOUT (2024)
Cal Newport
#лучшее
#безперевода
✏️ О КНИГЕ
Кэл Ньюпорт написал очень актуальную и своевременную книгу с тремя принципами «медленной продуктивности». Это и интересное чтение с примерами и размышлениями о природе продуктивности и умственной работы в современном мире, и конкретные рекомендации по достижению результатов в ваших проектах (ведь, как известно, «быстро — это медленно без перерывов»).
Он предлагает фокусироваться на качестве, а не количестве, и ограничивать число проектов в работе. Число часов в сутках ограничено, и с ростом числа проектов накладные временные расходы будут съедать всё больше времени, которое пригодилось бы для основной работы. С увеличением нагрузки они могут вырасти до точки, когда обслуживание работы будет требовать столько времени, что вы не будете успевать закрывать задачи — новые будут появляться быстрее.
🔥ФИШКИ КНИГИ
— Простые правила медленной продуктивности из трёх пунктов
— В списке лучших книг 2024 года по версии редакторов Amazon
— Лучшая книга года по версии The Economist и Independent
👨💻 КТО АВТОР
Кэл Ньюпорт — преподаватель, писатель, 42 года:
— Профессор факультета информатики Джорджтаунского университета, специализируется на теории распределённых вычислительных систем и цифровой этике
— Один из лучших авторов издания New York Times
— Регулярно пишет для широкой аудитории статьи о том, как пересекаются технологии и культура, и выступает на Национальном общественном радио
— Сторонник цифрового минимализма, никогда не заводил соцсетей, но ведёт блог Study Hacks с 2007 года, который читают более 2 000 000 человек в год в стремлении жить и глубоко работать в мире, который всё больше отвлекается
— C 2022 года Кэл запустил новый портал TheDeepLife.com, на котором размещается весь контент: все прошлые эпизоды популярного подкаста и обширная библиотека оригинальных видеоматериалов, которые доступны в том числе на YouTube
📌 ЦИТАТЫ ИЗ КНИГИ
Медленная продуктивность базируется на трёх принципах:
1. Делайте меньше дел
2. Работайте в естественном темпе
3. Сосредоточьтесь на качестве
Длительные рабочие отрезки, которые не создают мгновенных результатов, могут вызывать тревожность — куда проще проверять почту или ходить со встречи на встречу, чем сесть и много часов думать над новой стратегией.
Псевдо-продуктивность — использование видимой деятельности для оценки действительно продуктивных полезных усилий. Появление электронной почты и корпоративных мессенджеров позволили создавать видимость дела с минимальными усилиями и привели к тому, что средний работник больше времени говорит о работе, чем работает.
Если вы решите делать четыре отчёта параллельно вместо одного, «накладные расходы» времени будут занимать половину рабочего дня, если не больше. В конечном итоге, делать меньше — это путь к тому, чтобы получать результаты быстрее.
Моя рекомендация проста: работайте над одним проектом каждый день. Я не имею в виду, что этот проект будет вашей единственной работой за день. У вас точно будут письма, встречи. Но если мы говорим о ключевых, важных задачах, сфокусируйтесь на движении к одной цели в рамках дня.
Люди не очень хороши в оценке времени, необходимого на выполнение умственных задач.
Простое правило: уменьшать список задач на день, который вы запланировали, на 25-50%. Мы очень оптимистичны в такого рода оценках.
(Автор этого обзора, кстати, примерно в два раза переоценил время, необходимое на его написание — хотя читал эту и многие другие книги по теме😊)
📖 ВЫХОДНЫЕ ДАННЫЕ
Slow Productivity: The Lost Art of Accomplishment Without Burnout
Portfolio, 5 марта 2024
256 стр.
Перевод названия:
Медленная продуктивность: утраченное искусство достижения целей без выгорания
Саммари на русском от Smart Reading
Автор: Ренат Шагабутдинов
📚 CEO Readz. Книги для первых лиц
Cal Newport
#лучшее
#безперевода
✏️ О КНИГЕ
Кэл Ньюпорт написал очень актуальную и своевременную книгу с тремя принципами «медленной продуктивности». Это и интересное чтение с примерами и размышлениями о природе продуктивности и умственной работы в современном мире, и конкретные рекомендации по достижению результатов в ваших проектах (ведь, как известно, «быстро — это медленно без перерывов»).
Он предлагает фокусироваться на качестве, а не количестве, и ограничивать число проектов в работе. Число часов в сутках ограничено, и с ростом числа проектов накладные временные расходы будут съедать всё больше времени, которое пригодилось бы для основной работы. С увеличением нагрузки они могут вырасти до точки, когда обслуживание работы будет требовать столько времени, что вы не будете успевать закрывать задачи — новые будут появляться быстрее.
🔥ФИШКИ КНИГИ
— Простые правила медленной продуктивности из трёх пунктов
— В списке лучших книг 2024 года по версии редакторов Amazon
— Лучшая книга года по версии The Economist и Independent
👨💻 КТО АВТОР
Кэл Ньюпорт — преподаватель, писатель, 42 года:
— Профессор факультета информатики Джорджтаунского университета, специализируется на теории распределённых вычислительных систем и цифровой этике
— Один из лучших авторов издания New York Times
— Регулярно пишет для широкой аудитории статьи о том, как пересекаются технологии и культура, и выступает на Национальном общественном радио
— Сторонник цифрового минимализма, никогда не заводил соцсетей, но ведёт блог Study Hacks с 2007 года, который читают более 2 000 000 человек в год в стремлении жить и глубоко работать в мире, который всё больше отвлекается
— C 2022 года Кэл запустил новый портал TheDeepLife.com, на котором размещается весь контент: все прошлые эпизоды популярного подкаста и обширная библиотека оригинальных видеоматериалов, которые доступны в том числе на YouTube
📌 ЦИТАТЫ ИЗ КНИГИ
Медленная продуктивность базируется на трёх принципах:
1. Делайте меньше дел
2. Работайте в естественном темпе
3. Сосредоточьтесь на качестве
Длительные рабочие отрезки, которые не создают мгновенных результатов, могут вызывать тревожность — куда проще проверять почту или ходить со встречи на встречу, чем сесть и много часов думать над новой стратегией.
Псевдо-продуктивность — использование видимой деятельности для оценки действительно продуктивных полезных усилий. Появление электронной почты и корпоративных мессенджеров позволили создавать видимость дела с минимальными усилиями и привели к тому, что средний работник больше времени говорит о работе, чем работает.
Если вы решите делать четыре отчёта параллельно вместо одного, «накладные расходы» времени будут занимать половину рабочего дня, если не больше. В конечном итоге, делать меньше — это путь к тому, чтобы получать результаты быстрее.
Моя рекомендация проста: работайте над одним проектом каждый день. Я не имею в виду, что этот проект будет вашей единственной работой за день. У вас точно будут письма, встречи. Но если мы говорим о ключевых, важных задачах, сфокусируйтесь на движении к одной цели в рамках дня.
Люди не очень хороши в оценке времени, необходимого на выполнение умственных задач.
Простое правило: уменьшать список задач на день, который вы запланировали, на 25-50%. Мы очень оптимистичны в такого рода оценках.
(Автор этого обзора, кстати, примерно в два раза переоценил время, необходимое на его написание — хотя читал эту и многие другие книги по теме😊)
📖 ВЫХОДНЫЕ ДАННЫЕ
Slow Productivity: The Lost Art of Accomplishment Without Burnout
Portfolio, 5 марта 2024
256 стр.
Перевод названия:
Медленная продуктивность: утраченное искусство достижения целей без выгорания
Саммари на русском от Smart Reading
Автор: Ренат Шагабутдинов
Please open Telegram to view this post
VIEW IN TELEGRAM
3💯30❤🔥17⚡6🙈1
В прошлом году мы сделали небольшой surf camp в Тофино, на бергу тихого океана.
В этом году мы тоже решили сделать небольшой camp: 30 июня по 3 июля.
Присоединяйтесь:)
В этом году мы тоже решили сделать небольшой camp: 30 июня по 3 июля.
Присоединяйтесь:)
Telegram
Инжиниринг Данных
Вот и прошел наш 6ти дневный Surfalytics meetup в красивом Тофино на острове Ванкувер на берегу открытого Тихого океана.
6 дней пролетело незаметно, было 10 семей и каждый нашел свое, все попробовали серф и влюбились в это место как мы 9 лет назад.
Мы…
6 дней пролетело незаметно, было 10 семей и каждый нашел свое, все попробовали серф и влюбились в это место как мы 9 лет назад.
Мы…
❤🔥25⚡15🐳5
Labubu и Vibe Coding
Недавно дочка загорелась монстриками Labubu. Это такие брелоки - стоят недорого, но достать их почти невозможно. Кто-то вешает их на дорогие сумки, кто-то кринжует по-другому.
Дочка захотела Labubu. Окей, подумал я, всего-то $30. Нашёл сайт, где их продают - https://www.popmart.com/ca, и понял, что там какие-то дропы: ограниченное количество игрушек.
Была надпись: старт продаж в 18:30. Я поставил будильник на 18:25. Зашёл на сайт и начал кликать. Сайт дико тормозил, и уже в 18:30 все игрушки были зарезервированы.
«Так значит?» - подумал я. У меня же есть Cursor. Сейчас как на вайбе закодю - мало не покажется.
Поставил себе задачу для плагина:
- Зайти на сайт
- Ровно в 18:30 нажать Shake the Box и добавить в корзину (ADD TO CART)
Решил начать с Google Chrome плагина. Я ведь уже купил один за $7 - не работает. Cursor быстро накатал мне плагин, который умел:
- запускаться по времени,
- добавлять в корзину,
- обновлять страницу,
- показывать логи.
Даже работал на простых товарах. Дети бегали в восторге и кричали: «Папа, хакер!»
Но с Labuba — это реальный high-load. Я решил масштабировать вкладки, и в итоге всё зависло. MacBook Pro с 32 GB оперативки пришлось перезагружать вручную — hard reset🪦
Спросил у ChatGPT, какие есть варианты на Python с headless-браузером.
Стал фигачить: сначала на Playwright, потом на Selenium. Нужно было логиниться, качать cookies. В итоге потратил часов восемь на всё это. Оно вроде как работало, но было сыровато и оставалось еще много недоделок.
Было очень интересно, настоящий deep work и поток. Но, увы, другие дела-то не делаются…
На следующий день, пока я собирался на новый заход, жена прислала фото с коробками Labubu. Нашла магазинчик, где они были в наличии. Так что… вы поняли, кто тут настоящий хакер.
Когда дочка принесла их в школу — был дикий ажиотаж. Ни у кого нет, а у неё аж три.
А у вас есть Labubu?
Недавно дочка загорелась монстриками Labubu. Это такие брелоки - стоят недорого, но достать их почти невозможно. Кто-то вешает их на дорогие сумки, кто-то кринжует по-другому.
Дочка захотела Labubu. Окей, подумал я, всего-то $30. Нашёл сайт, где их продают - https://www.popmart.com/ca, и понял, что там какие-то дропы: ограниченное количество игрушек.
Была надпись: старт продаж в 18:30. Я поставил будильник на 18:25. Зашёл на сайт и начал кликать. Сайт дико тормозил, и уже в 18:30 все игрушки были зарезервированы.
«Так значит?» - подумал я. У меня же есть Cursor. Сейчас как на вайбе закодю - мало не покажется.
Поставил себе задачу для плагина:
- Зайти на сайт
- Ровно в 18:30 нажать Shake the Box и добавить в корзину (ADD TO CART)
Решил начать с Google Chrome плагина. Я ведь уже купил один за $7 - не работает. Cursor быстро накатал мне плагин, который умел:
- запускаться по времени,
- добавлять в корзину,
- обновлять страницу,
- показывать логи.
Даже работал на простых товарах. Дети бегали в восторге и кричали: «Папа, хакер!»
Но с Labuba — это реальный high-load. Я решил масштабировать вкладки, и в итоге всё зависло. MacBook Pro с 32 GB оперативки пришлось перезагружать вручную — hard reset
Спросил у ChatGPT, какие есть варианты на Python с headless-браузером.
Стал фигачить: сначала на Playwright, потом на Selenium. Нужно было логиниться, качать cookies. В итоге потратил часов восемь на всё это. Оно вроде как работало, но было сыровато и оставалось еще много недоделок.
Было очень интересно, настоящий deep work и поток. Но, увы, другие дела-то не делаются…
На следующий день, пока я собирался на новый заход, жена прислала фото с коробками Labubu. Нашла магазинчик, где они были в наличии. Так что… вы поняли, кто тут настоящий хакер.
Когда дочка принесла их в школу — был дикий ажиотаж. Ни у кого нет, а у неё аж три.
А у вас есть Labubu?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥112
Игра симулятор про CDO, попробуйте, получилось прикольно https://www.whoisthebestcdo.com
Whoisthebestcdo
Who is the Best CDO?
Vote for the coolest cat in the office!
👨💻19
VC заинвестировали больше 73 лярдов в AI стартапы в 2025, и теперь кошечки прыгают в олимпийский бассейн как настоящие.
https://youtube.com/shorts/Z_hSnPzztpA
https://youtube.com/shorts/Z_hSnPzztpA
YouTube
Olympic Cat jump into swimming pool 🐈🐈.. #youtubeshorts #cats #ai #olympics #swimming
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
Forwarded from Trino и CedrusData
Всем привет! В следующий четверг 26 июня мы проведем очередной онлайн-митап по lakehouse технологиям. В программе два доклада:
Trino в Авито спустя два года: от движка к аналитической экосистеме, Дмитрий Рейман, Авито
Как Авито построил lakehouse-платформу на основе Trino, которая обрабатывает до 1 ПБ данных в день и обслуживает 300 пользователей
CedrusData Catalog — Современный каталог для lakehouse-платформ, Владимир Озеров, Кверифай Лабс
Архитектура и возможности CedrusData Catalog — бесплатного каталога Iceberg для российского рынка. Ролевая модель доступа, обслуживание таблиц Iceberg, time-travel, ускорение аналитических запросов.
Регистрация: https://cedrusdata.timepad.ru/event/3426242/
Trino в Авито спустя два года: от движка к аналитической экосистеме, Дмитрий Рейман, Авито
Как Авито построил lakehouse-платформу на основе Trino, которая обрабатывает до 1 ПБ данных в день и обслуживает 300 пользователей
CedrusData Catalog — Современный каталог для lakehouse-платформ, Владимир Озеров, Кверифай Лабс
Архитектура и возможности CedrusData Catalog — бесплатного каталога Iceberg для российского рынка. Ролевая модель доступа, обслуживание таблиц Iceberg, time-travel, ускорение аналитических запросов.
Регистрация: https://cedrusdata.timepad.ru/event/3426242/
cedrusdata.timepad.ru
Lakehouse Meetup #4: аналитическая экосистема на основе Trino в Avito, архитектура и возможности CedrusData Catalog / События на…
Обсудим, как за последние два года Avito выстроил аналитическую экосистему вокруг Trino, и рассмотрим внутреннее устройство и возможности CedrusData Catalog — современного бесплатного каталога для lakehouse-платформ.
Митап организован компанией Querify Labs…
Митап организован компанией Querify Labs…
❤🔥15
Оказывается есть еще очень много компаний, которые используют Microsoft Reporting Service (SSRS).
SSRS (SQL Server Reporting Services) был создан Microsoft и впервые представлен как часть SQL Server 2000 в 2004 году (в составе SQL Server 2000 Reporting Services add-on, релиз - январь 2004). Основная цель - дать пользователям SQL Server инструмент для создания отчётов, который интегрируется с экосистемой Microsoft и конкурирует с Crystal Reports (в то время популярным решением).
И вот, на конференции sqlBits в июне Microsoft объявил о завершении поддержки SSRS. В новом SQL Server будет уже Power BI Report Server (PBIRS), который будет работать с ключом лицензии SSRS.
Но обещана поддержка до 2033 года. В любом случае, если вы используете софт в РФ, поддержка вам и не нужна.
С legacy-софтом я вижу только одну проблему - это, прежде всего, проблема специалистов. Быть экспертом в устаревших системах сужает карьерные возможности. Несмотря на то, что SSRS и другие решения всё ещё отлично работают, вам, как высококлассному специалисту, делать там особо нечего. Зато для бизнеса это отличный вариант: надёжный софт, проверенный десятилетием, легко найти специалистов, и платить им много не нужно.
SSRS (SQL Server Reporting Services) был создан Microsoft и впервые представлен как часть SQL Server 2000 в 2004 году (в составе SQL Server 2000 Reporting Services add-on, релиз - январь 2004). Основная цель - дать пользователям SQL Server инструмент для создания отчётов, который интегрируется с экосистемой Microsoft и конкурирует с Crystal Reports (в то время популярным решением).
И вот, на конференции sqlBits в июне Microsoft объявил о завершении поддержки SSRS. В новом SQL Server будет уже Power BI Report Server (PBIRS), который будет работать с ключом лицензии SSRS.
Но обещана поддержка до 2033 года. В любом случае, если вы используете софт в РФ, поддержка вам и не нужна.
С legacy-софтом я вижу только одну проблему - это, прежде всего, проблема специалистов. Быть экспертом в устаревших системах сужает карьерные возможности. Несмотря на то, что SSRS и другие решения всё ещё отлично работают, вам, как высококлассному специалисту, делать там особо нечего. Зато для бизнеса это отличный вариант: надёжный софт, проверенный десятилетием, легко найти специалистов, и платить им много не нужно.
⚡8
Forwarded from Data Bar | О data-проектах (Alexander Varlamov)
Tableau Lego и невозможные визуализации.
В BI и датавиз пространстве большинство пользователей работают со стандартными визуализациями. Естественно, в любом инструменте визуализации данных есть свои ограничения - они и определяют сложность визуализаций. Эксперты могут посмотреть на любую работу и примерно рассказать как она сделана. В периметре Tableau существуют "невозможные визуализации" - такие, которые мало кто может повторить без мануала, и до их создания построение считалось невозможным. Обычно на скриншот с такой визуализацией говорят что "это сделано не в Табло".
Сегодня расскажу о своей визуализации Tableau Lego. Ей 5 лет, она стала классикой в своём сегменте, но не каждый Tableau эксперт понимает как она построена. Я консультировал несколько инженеров и сейлзов внутри компании Tableau по принципам её построения. То есть, инженеры, создающие продукт, хотели понять на что способен продукт, и что можно ещё создать. И внутри компании создают 3D проекты чтобы расширить понимание возможностей продукта.
Сама визуализация "Tableau Lego" - это эмулятор конструктора, где можно по шагам эмулировать сборку лего домика, а также смотреть на него под разными углами. Всё работает на чистой математике, без внешних модулей.
Когда-то для меня 3D в Tableau казалось космосом. Но надо было разобраться и добавить что-то своё. Месяца на 4 погружался в 3D, принципы, что было сделано и что можно сделать. Сверхсложного ничего нет - просто нужно время. Из своего - добавил работу с OBJ файлами - это сильно изменило картинку. До этого 3D модели описывались форматом стереолитографии, и полигоны делились на треугольники. С моим подходом можно работать с любым числом вершин в полигоне.
Самое сложное - создать датасет, остальное - дело техники. Визуализация - это набор полигонов с заданными координатами вершин и формулы проекции на плоскость плюс алгоритм сортировки полигонов. Максимально подробно всё описал в статье "3D модели в Tableau". Её до сих пор читают и делают 3D. Мы даже конкурс один раз проводили на индийском TUG с призами.
Мне нравится концепция Лего, когда из базовых кубиков создаёшь примитивные конструкции, а и из примитивных конструкций создаёшь сложные сооружения. Как в жизни.
После создания таких визуализаций мне посчасливилось сотрудничать с людьми из Pixar, они создавали ещё первую "Историю игрушек". Про это рассказывал в одном из постов.
Зачем всё это? В русскоязычном пространстве такой вопрос возникает часто, а в англоязычном - нет. В англоязычном комьюнити просят статьи, вебинары и объяснения. Мне просто интересно делать то, что считают невозможным. Это классно, когда ты ограничен инструментом (нет циклов, скриптов и т.п.), и приходится придумывать вычисления для реализации идеи.
В СНГ такие вещи никому не нужны, и это печально. А в англоязычном пространстве всегда ищут что-то необычное и тех кто это делает. В твиттере (благодаря таким работам) на мой профиль подписаны CEO Salesforce, CEO Tableau, CTO Twitter/Facebook (сейчас - Sierra AI) - это люди, определяющие куда пойдёт мировое IT. И им это надо.
В BI и датавиз пространстве большинство пользователей работают со стандартными визуализациями. Естественно, в любом инструменте визуализации данных есть свои ограничения - они и определяют сложность визуализаций. Эксперты могут посмотреть на любую работу и примерно рассказать как она сделана. В периметре Tableau существуют "невозможные визуализации" - такие, которые мало кто может повторить без мануала, и до их создания построение считалось невозможным. Обычно на скриншот с такой визуализацией говорят что "это сделано не в Табло".
Сегодня расскажу о своей визуализации Tableau Lego. Ей 5 лет, она стала классикой в своём сегменте, но не каждый Tableau эксперт понимает как она построена. Я консультировал несколько инженеров и сейлзов внутри компании Tableau по принципам её построения. То есть, инженеры, создающие продукт, хотели понять на что способен продукт, и что можно ещё создать. И внутри компании создают 3D проекты чтобы расширить понимание возможностей продукта.
Сама визуализация "Tableau Lego" - это эмулятор конструктора, где можно по шагам эмулировать сборку лего домика, а также смотреть на него под разными углами. Всё работает на чистой математике, без внешних модулей.
Когда-то для меня 3D в Tableau казалось космосом. Но надо было разобраться и добавить что-то своё. Месяца на 4 погружался в 3D, принципы, что было сделано и что можно сделать. Сверхсложного ничего нет - просто нужно время. Из своего - добавил работу с OBJ файлами - это сильно изменило картинку. До этого 3D модели описывались форматом стереолитографии, и полигоны делились на треугольники. С моим подходом можно работать с любым числом вершин в полигоне.
Самое сложное - создать датасет, остальное - дело техники. Визуализация - это набор полигонов с заданными координатами вершин и формулы проекции на плоскость плюс алгоритм сортировки полигонов. Максимально подробно всё описал в статье "3D модели в Tableau". Её до сих пор читают и делают 3D. Мы даже конкурс один раз проводили на индийском TUG с призами.
Мне нравится концепция Лего, когда из базовых кубиков создаёшь примитивные конструкции, а и из примитивных конструкций создаёшь сложные сооружения. Как в жизни.
После создания таких визуализаций мне посчасливилось сотрудничать с людьми из Pixar, они создавали ещё первую "Историю игрушек". Про это рассказывал в одном из постов.
Зачем всё это? В русскоязычном пространстве такой вопрос возникает часто, а в англоязычном - нет. В англоязычном комьюнити просят статьи, вебинары и объяснения. Мне просто интересно делать то, что считают невозможным. Это классно, когда ты ограничен инструментом (нет циклов, скриптов и т.п.), и приходится придумывать вычисления для реализации идеи.
В СНГ такие вещи никому не нужны, и это печально. А в англоязычном пространстве всегда ищут что-то необычное и тех кто это делает. В твиттере (благодаря таким работам) на мой профиль подписаны CEO Salesforce, CEO Tableau, CTO Twitter/Facebook (сейчас - Sierra AI) - это люди, определяющие куда пойдёт мировое IT. И им это надо.
❤🔥48⚡6💯3
Forwarded from Аналитика в действии
Фан факт: я поступил в 2 вуза из топ-3 в этом списке, но учиться пошел в другие места.
Физтех всегда был для меня первым из всех технических вузов, а вот Иннополис удивил
Физтех всегда был для меня первым из всех технических вузов, а вот Иннополис удивил
❤🔥17💯6⚡5🤷3
Наконец-то норм курсы по BI от MicroStrategy:
🇷🇺 Bitcoin 102: Corporate Adoption and the Bitcoin Standard
🇷🇺 Bitcoin 103: Financial Fluency for Bitcoin
🇷🇺 Bitcoin 104: Bitcoin in the Corporate Treasury and the Strategy Story
💰
Please open Telegram to view this post
VIEW IN TELEGRAM
🐳15❤🔥3😈3🫡2