Ivan Begtin
8.07K subscribers
1.5K photos
3 videos
100 files
4.26K links
I write about Open Data, Data Engineering, Government, Privacy and Data Preservation and other gov and tech stuff
Telegram @ibegtin
Facebook - https://facebook.com/ibegtin
Secure contacts ivan@begtin.tech

Contact @NMBabina for ads proposals
Download Telegram
Мне тут регулярно пишут что я своими предсказаниями будущего подкидываю идей регуляторам и нормотворцам о том как сделать цифровую жизнь россиянам похуже, пожиже, потяжелее.

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

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

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

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

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

#ideas
Для тех кто пользуется телеграмом регулярно, поделюсь несколькими идеями продуктов которыми мне самому заняться всегда не хватало времени/мотивации/занятости. Да и специализация моя data engineering, что немного в другой области.

Первая идея весьма очевидная.

Аналог Slack/Element на базе Telegram

У телеграм'а есть сильное ограничение в числе каналов и чатов которые возможно поддерживать в одиночку. Больше чем на 20 каналов подписываться самоубийственное занятие, а чаты идут вперемешку рабочие и нерабочие и всякие. В этом смысле Slack или Element (Matrix) организованные по комнатам и сгруппированные по компаниям удобнее для корпоративного использования. В десктопном телеграме есть возможность группировать каналы и чаты, но, скажем так, довольно ограниченная.

Так вот востребованная штука - это сделать аналог Slack'а поверх телеграма. Почему так? Аналог Slack - это:
1. Способ организации рабочего пространства. В нем должны быть собраны все чаты команд, каналы команды и тд.
2. Автоматизированная архивация всей корпоративной переписки в чатах.
3. Корпоративный поиск по чатам (нужен поиск только по чатам в рамках определенной группы).
4. Иные возможности как у Slack'а

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


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

#ideas #tech #telegram
Иногда полезно перечитывать отложенные ещё в прошлом году материалы и там есть интересные идеи.

Например, возможно, мало кто слышал про подход к разработке информационный систем Documentation-first или Docs First.

Это идея когда всё делается наоборот, а не как в привычном цикле. Вначале пишут документацию, потом по ней проектируют спецификации (API) и только потом пишут код.

То есть цикл не: код -> спецификация -> документация, а документация -> спецификация -> код

Об этом выступал Rahul Dighe на конференции ASC 2021 [1] с аргументами что разработчики - это тоже пользователи и заботится о них нужно ещё начиная со стадии проектирования.

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

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

Ссылки:
[1] https://events.linuxfoundation.org/archive/2021/openapi-asc/program/schedule/

#API #ideas #documentation #docsfirst
Instrumentorum minorum linguarum inopia magna sunt

Как активный пользователь разного рода онлайн и не онлайн курсов/занятий/инструментов изучения разговорных языков могу сказать что есть большая нехватка удобных инструментов изучения для языков малых и не хайповых.

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

В лучшем случае если ты уже знаешь английский то можешь учить через него какие-то другие языки через Duolingo или аналогичные онлайн сервисы (ling-app и ещё с десяток).

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

Такое ощущение что здесь есть какая-то бизнес модель упускаемая на этом рынке. Аналоги Duolingo on premise, когда не свой контент, чужой перепродаешь или даёшь платформу в аренду. Может быть курсера для языков.

Или, возможно, более структурированный и адаптированный "усилитель работы репетиторов" которыми сейчас де-факто являются карточки в Memrise к примеру.

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

#startups #ideas #thoughts
дарю идею совершенно безвозмездно (с)

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

Зато сделать туда несколько важных фич։
1. Дайджестирование подписок. Иначе говоря, настраивать сгруппировывание постов от некоторых каналов сразу по n штук. Помогает читать чрезмерно частящие каналы
2. Спам фильтры. В некоторых телеграм каналах реклама уже за... раздражает. Нужны механизмы фильтрации по тегам или по ключевым словам и встроенные спам фильтры. На этом же можно монетизироваться. Спам фильтры можно [и нужно] вести централизованно.
3. Бьютификация контента. Удаление смайликов и тд.

Минус - экосистема телеграма вне контроля, поменяются правила и API и всё на... закончится.
Плюс - рынок точно есть, монетизация не конфликтует пока с монетизацией телеграма.

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

Тем не менее тема эта интересная и, на мой взгляд, будет развиваться, хотя и не все идеи кажутся реалистичными. Я собрал пока следующие идеи:
- запросы к базам данных на естественном языке
- запросы на автоматическое построение визуализации на естественном языке
- автоматизация написания SQL запросов или запросов на других языках (text2sql)
- автоматическое проектирование баз данных из ТЗ написанного на естественном языке (вместе с извлечение бизнес логики и тд.)
- автоматическое обнаружение неработающих дашбордов, отсутствующих данных, сбоев в конвейерах данных (Monte Carlo data)
* обогащение данных и метаданных
* генерация идей для аналитики на основе данных
* поиск аномалий, автоматизированный контроль качества данных

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

#dataengineering #ai #ideas #thoughts
Отвлекаясь от темы данных, немного о самоорганизации. Много лет, больше 15 у меня жизнь была организована по принципу zero inbox это когда каждое письмо во входящих было задачей, а далее день начинался с разбора почты. Правило нарушилось после ковида и, с перерывами на небольшие попытки чистить почту, к июню накопилось 1200+ писем.

Сегодня, наконец-то, удалось всё привести в порядок. Ура! Осталось 4 письма, все из которых являются именно задачами.

И, в который раз, я никак не могу упустить вниманием тот факт что до сих пор нигде не видел удобных автоматизированных email assistant'ов. Там даже ИИ необязательно для его эффективности. Но подход должен быть совершенно нестандартным.
1. Все письма которые информационные/рассылки легко идентифицируются их можно и нужно автоматически складывать в отдельную группу и создавать по ним ежесуточный/еженедельный дайджест.
2. Письмам можно автоматически присваивать теги и давать возможность отфильтровывать и группировать по этим тегам.
3. Куча дополнительных метаданных можно автоматически извлекать из писем и присваивать тегами или группировать. Например,
- письма от адресатов которые ранее Вам не писали
- письма от коллег
- наименования компаний из которых пишут отправители
- письма от контрагентов (по списку компаний/доменов)
4. Для гиков должен быть SQL интерфейс для фильтрации почты. Об этом я как-то уже писал

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

#selforg #email #thoughts #ideas