С этим у меня, кстати, всегда было плохо.
Если я ничего не делаю, довольно быстро появляется ощущение, что я теряю время. Даже отдых хочется превратить во что-то полезное: почитать, придумать идею, поковырять проект, хотя бы составить план.
А потом удивляешься, почему после выходных ты вроде бы не работал, но и не отдохнул.
Пожалуй, умение иногда абсолютно бесполезно потратить несколько часов - тоже навык. И, судя по всему, довольно важный.
Не всё время должно быть продуктивным. Иногда его достаточно просто прожить.
Если я ничего не делаю, довольно быстро появляется ощущение, что я теряю время. Даже отдых хочется превратить во что-то полезное: почитать, придумать идею, поковырять проект, хотя бы составить план.
А потом удивляешься, почему после выходных ты вроде бы не работал, но и не отдохнул.
Пожалуй, умение иногда абсолютно бесполезно потратить несколько часов - тоже навык. И, судя по всему, довольно важный.
Не всё время должно быть продуктивным. Иногда его достаточно просто прожить.
👍3
В выходной день - немного лёгкой технической пользы.
Когда база начинает тормозить, первое желание часто одно: «давайте просто добавим серверу ресурсов». Но причин может быть гораздо больше - от неудачных запросов и отсутствующих индексов до архитектуры хранения данных.
Собрал в одной картинке 9 базовых способов ускорить работу БД. Не чек-лист «сделай всё сразу», а скорее карта вариантов: куда смотреть, когда запросы внезапно начинают жить своей жизнью.
Сохраняйте, пригодится 🙂
Когда база начинает тормозить, первое желание часто одно: «давайте просто добавим серверу ресурсов». Но причин может быть гораздо больше - от неудачных запросов и отсутствующих индексов до архитектуры хранения данных.
Собрал в одной картинке 9 базовых способов ускорить работу БД. Не чек-лист «сделай всё сразу», а скорее карта вариантов: куда смотреть, когда запросы внезапно начинают жить своей жизнью.
Сохраняйте, пригодится 🙂
Говорят, верблюд - это лошадь, сделанная по ТЗ заказчика.
В своей работе я регулярно сталкиваюсь с двумя видами ТЗ: его либо нет вообще, либо оно существует на уровне «нужна кнопка - сделать всё».
И это, кстати, не всегда проблема.
Если с заказчиком вы на одной волне, можно поговорить, позадавать вопросы, поспорить и постепенно вытащить наружу реальную задачу. Иногда хорошее ТЗ именно так и рождается.
Хуже, когда не получается даже этого.
У любого проекта есть идея. Но идея - ещё не фундамент.
Фундамент - не формулы, не инструменты, не базы данных и даже не выбранная архитектура. Фундамент - способность заказчика и исполнителя понять друг друга.
И, пожалуй, это одна из самых недооценённых частей любого проекта.
Заказчик совершенно не обязан знать техническую часть. Не обязан понимать все детали реализации. И даже финальный образ решения в его голове может быть довольно размытым.
Но если в начале проекта запрос звучал как:
«Мне нужна штука с двумя отсеками для воды, чтобы передвигаться по пустыне».
А в конце выяснилось, что отсеки вообще не нужны, передвигаться никуда не надо, а пустыня была просто примером...
Ну сорри.
Мы сделали вам верблюда.😘
В своей работе я регулярно сталкиваюсь с двумя видами ТЗ: его либо нет вообще, либо оно существует на уровне «нужна кнопка - сделать всё».
И это, кстати, не всегда проблема.
Если с заказчиком вы на одной волне, можно поговорить, позадавать вопросы, поспорить и постепенно вытащить наружу реальную задачу. Иногда хорошее ТЗ именно так и рождается.
Хуже, когда не получается даже этого.
У любого проекта есть идея. Но идея - ещё не фундамент.
Фундамент - не формулы, не инструменты, не базы данных и даже не выбранная архитектура. Фундамент - способность заказчика и исполнителя понять друг друга.
И, пожалуй, это одна из самых недооценённых частей любого проекта.
Заказчик совершенно не обязан знать техническую часть. Не обязан понимать все детали реализации. И даже финальный образ решения в его голове может быть довольно размытым.
Но если в начале проекта запрос звучал как:
«Мне нужна штука с двумя отсеками для воды, чтобы передвигаться по пустыне».
А в конце выяснилось, что отсеки вообще не нужны, передвигаться никуда не надо, а пустыня была просто примером...
Ну сорри.
Мы сделали вам верблюда.
Please open Telegram to view this post
VIEW IN TELEGRAM
А что, если интерфейс отчёта будет собираться под ваш вопрос?
OpenAI начала внедрять GPT-6 с Intelligent UI в ChatGPT. Теперь ответ может содержать интерактивные графики, формы, кнопки и небольшие инструменты, которыми можно пользоваться прямо в чате.
Для аналитики здесь интересен сам подход.
Представьте: вы спрашиваете, почему упали продажи. Под этот вопрос появляется сравнение регионов. Затем уточняете про ассортимент - получаете детализацию по SKU. Хотите проверить сценарий со скидкой - появляется калькулятор.
Это возможное направление развития аналитических интерфейсов. Подключение корпоративных данных и корректность расчётов всё ещё требуют отдельной работы.
И вот здесь начинается самое интересное: интерфейс можно сгенерировать, а смысл показателя всё равно нужно определить.
Что считать продажами? Как учитывать возвраты? С каким периодом сравнивать? Какие данные пользователь имеет право видеть?
Для меня эта новость - ещё один аргумент в пользу общей семантической модели: согласованных показателей, правил расчёта и связей между данными.
Когда интерфейсы создаются всё быстрее, цена ошибки в фундаменте становится выше. Красивый график появится за секунды. Только вот правильную ли выручку он покажет?
Анонс OpenAI
OpenAI начала внедрять GPT-6 с Intelligent UI в ChatGPT. Теперь ответ может содержать интерактивные графики, формы, кнопки и небольшие инструменты, которыми можно пользоваться прямо в чате.
Для аналитики здесь интересен сам подход.
Представьте: вы спрашиваете, почему упали продажи. Под этот вопрос появляется сравнение регионов. Затем уточняете про ассортимент - получаете детализацию по SKU. Хотите проверить сценарий со скидкой - появляется калькулятор.
Это возможное направление развития аналитических интерфейсов. Подключение корпоративных данных и корректность расчётов всё ещё требуют отдельной работы.
И вот здесь начинается самое интересное: интерфейс можно сгенерировать, а смысл показателя всё равно нужно определить.
Что считать продажами? Как учитывать возвраты? С каким периодом сравнивать? Какие данные пользователь имеет право видеть?
Для меня эта новость - ещё один аргумент в пользу общей семантической модели: согласованных показателей, правил расчёта и связей между данными.
Когда интерфейсы создаются всё быстрее, цена ошибки в фундаменте становится выше. Красивый график появится за секунды. Только вот правильную ли выручку он покажет?
Анонс OpenAI
OpenAI
GPT-6 and Intelligent UI for everyone
GPT‑6 is rolling out globally in ChatGPT with Intelligent UI, delivering faster responses with visuals and interactive experiences you can explore and use directly.
👍2
Сложные задачи становятся простыми, а невозможные - сложными. Кажется, именно туда сейчас движется BI.
Две вчерашние новости хорошо складываются в эту картину.
dltHub представил агента для диагностики упавших пайплайнов. Он читает логи, разбирается в контексте запуска и присылает предполагаемую причину сбоя с доказательствами и рекомендацией. Пока это public preview, а исправление остаётся за инженером.
Glean вывел в GA коннектор Power BI. Ассистент может находить отчёты и семантические модели, а при необходимых настройках - запрашивать актуальные данные с правами конкретного пользователя.
По отдельности - обновления продуктов. Вместе - направление, которое мне очень интересно.
Агенты уже помогают писать код. Теперь они получают инструменты, чтобы разбирать ошибки, обращаться к данным и использовать бизнес-показатели из существующих моделей.
Для инженера это меняет масштаб доступных задач.
Разобрать незнакомый лог, собрать прототип интеграции, проверить гипотезу, пройти от вопроса бизнеса до первого расчёта - на всё это постепенно требуется меньше ручной работы. А идеи, которые раньше откладывали из-за объёма разработки, становится реально хотя бы попробовать.
Но вместе со скоростью растёт значение инженерного решения.
К каким данным дать доступ? Как проверить расчёт? Где достаточно рекомендации, а где можно разрешить действие? Что произойдёт, если агент ошибётся?
Я вижу здесь возможность для небольших команд делать больше и браться за задачи, до которых раньше просто не доходили руки.
Сложное становится проще. Невозможное переходит в категорию «надо подумать, как сделать».
И вот это уже очень интересная работа.
Источники: dltHub · Glean
Две вчерашние новости хорошо складываются в эту картину.
dltHub представил агента для диагностики упавших пайплайнов. Он читает логи, разбирается в контексте запуска и присылает предполагаемую причину сбоя с доказательствами и рекомендацией. Пока это public preview, а исправление остаётся за инженером.
Glean вывел в GA коннектор Power BI. Ассистент может находить отчёты и семантические модели, а при необходимых настройках - запрашивать актуальные данные с правами конкретного пользователя.
По отдельности - обновления продуктов. Вместе - направление, которое мне очень интересно.
Агенты уже помогают писать код. Теперь они получают инструменты, чтобы разбирать ошибки, обращаться к данным и использовать бизнес-показатели из существующих моделей.
Для инженера это меняет масштаб доступных задач.
Разобрать незнакомый лог, собрать прототип интеграции, проверить гипотезу, пройти от вопроса бизнеса до первого расчёта - на всё это постепенно требуется меньше ручной работы. А идеи, которые раньше откладывали из-за объёма разработки, становится реально хотя бы попробовать.
Но вместе со скоростью растёт значение инженерного решения.
К каким данным дать доступ? Как проверить расчёт? Где достаточно рекомендации, а где можно разрешить действие? Что произойдёт, если агент ошибётся?
Я вижу здесь возможность для небольших команд делать больше и браться за задачи, до которых раньше просто не доходили руки.
Сложное становится проще. Невозможное переходит в категорию «надо подумать, как сделать».
И вот это уже очень интересная работа.
Источники: dltHub · Glean
dltHub
Introducing job-inspector: dltHub's first verified agent for diagnosing failed pipelines
dltHub background agents are in public preview, starting with job-inspector: a verified agent that diagnoses failed pipeline jobs with read-only access and posts the cause, its confidence and the log evidence to Slack.
👍1
Forwarded from Programmer & IT Memes
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Когда дата-центр становится новостью, а для тебя - рабочей проблемой.
Сегодня ночью, 11 октября, появилась информация об атаке БПЛА на дата-центр Яндекса во Владимире. По сообщениям СМИ, инфраструктура получила повреждения, работа площадки остановлена.
Для кого-то это очередная новость в ленте. Для меня - проблема, с которой придётся разбираться непосредственно.
Данные, с которыми я работаю, хранятся именно там. И последствия этого инцидента напрямую влияют на мою работу.
Впереди поиск альтернативных площадок, оценка доступности резервных копий, восстановление инфраструктуры и сервисов. А главное - необходимость пересмотреть подходы к обеспечению отказоустойчивости.
Мы привыкли обсуждать надёжность инфраструктуры через привычные технические критерии:
• SLA и доступность сервисов;
• резервирование и отказоустойчивость;
• стоимость хранения и вычислений;
• производительность и масштабируемость.
Но реальность добавляет ещё один фактор.
Географическое расположение данных и резервных копий становится одним из критически важных критериев при выборе инфраструктуры.
И речь уже не просто о том, чтобы хранить бэкап отдельно от основного сервера. Важно понимать, насколько отдельно он находится, каким рискам подвержены обе площадки и сможем ли мы восстановить работу, если одна из них физически перестанет существовать.
То, что раньше для многих компаний было сценарием из раздела Disaster Recovery, сегодня превращается в вполне реальную операционную задачу.
Отказоустойчивость - это не когда у тебя есть бэкап. Это когда ты действительно можешь из него восстановиться.
И, судя по всему, мне в ближайшее время предстоит проверить это на практике.
Сегодня ночью, 11 октября, появилась информация об атаке БПЛА на дата-центр Яндекса во Владимире. По сообщениям СМИ, инфраструктура получила повреждения, работа площадки остановлена.
Для кого-то это очередная новость в ленте. Для меня - проблема, с которой придётся разбираться непосредственно.
Данные, с которыми я работаю, хранятся именно там. И последствия этого инцидента напрямую влияют на мою работу.
Впереди поиск альтернативных площадок, оценка доступности резервных копий, восстановление инфраструктуры и сервисов. А главное - необходимость пересмотреть подходы к обеспечению отказоустойчивости.
Мы привыкли обсуждать надёжность инфраструктуры через привычные технические критерии:
• SLA и доступность сервисов;
• резервирование и отказоустойчивость;
• стоимость хранения и вычислений;
• производительность и масштабируемость.
Но реальность добавляет ещё один фактор.
Географическое расположение данных и резервных копий становится одним из критически важных критериев при выборе инфраструктуры.
И речь уже не просто о том, чтобы хранить бэкап отдельно от основного сервера. Важно понимать, насколько отдельно он находится, каким рискам подвержены обе площадки и сможем ли мы восстановить работу, если одна из них физически перестанет существовать.
То, что раньше для многих компаний было сценарием из раздела Disaster Recovery, сегодня превращается в вполне реальную операционную задачу.
Отказоустойчивость - это не когда у тебя есть бэкап. Это когда ты действительно можешь из него восстановиться.
И, судя по всему, мне в ближайшее время предстоит проверить это на практике.
3-4 часа работы. Результат - один Excel.
Сегодня на встрече мне показали процесс расчёта премий дистрибьюторам.
Обычная задача. Есть данные из разных источников, нужно собрать их вместе, что-то сопоставить, посчитать и получить итоговый файл.
Только вот на одну небольшую торговую сеть у одного небольшого дистрибьютора уходит 3-4 часа ручной работы.
Открыть файл. Скопировать. Вставить. Найти нужную колонку. Сопоставить. Проверить. Открыть следующий файл. Повторить.
И ведь самое интересное - это не какой-то уникальный случай. Таких процессов в компаниях десятки, а иногда и сотни.
Мы обсуждаем искусственный интеллект, автономных агентов, предиктивную аналитику...
А где-то в это время человек третий час переносит данные из Excel в Excel. 😁
Иногда компании не нужен искусственный интеллект. Ей достаточно перестать использовать человеческий как инструмент для копирования ячеек.
Сегодня на встрече мне показали процесс расчёта премий дистрибьюторам.
Обычная задача. Есть данные из разных источников, нужно собрать их вместе, что-то сопоставить, посчитать и получить итоговый файл.
Только вот на одну небольшую торговую сеть у одного небольшого дистрибьютора уходит 3-4 часа ручной работы.
Открыть файл. Скопировать. Вставить. Найти нужную колонку. Сопоставить. Проверить. Открыть следующий файл. Повторить.
И ведь самое интересное - это не какой-то уникальный случай. Таких процессов в компаниях десятки, а иногда и сотни.
Мы обсуждаем искусственный интеллект, автономных агентов, предиктивную аналитику...
А где-то в это время человек третий час переносит данные из Excel в Excel. 😁
Иногда компании не нужен искусственный интеллект. Ей достаточно перестать использовать человеческий как инструмент для копирования ячеек.
👍1🔥1