Bloomberg пишет что Microsoft может приобрести Github, крупнейший проект репозиториев исходного кода, за 5 миллиардов USD [1], однако пока не подтверждает это какими-либо ссылками на официальные источники. А в Techcrunch пишут что компания пока никак не комментирует эти слухи [2].

О переговорах между компаниями писали ещё несколько дней назад в Business Insider [3], однако Bloomberg теперь пишет всё в гораздо более уверенных тонах.

5 миллиардов USD - это значительно меньше чем, например, 26 миллиардов USD за которые Microsoft купили LinkedIn. А покупка Github'а даст Microsoft существенное преимущество при интеграции Github и облака Azure, например.

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

Ссылки:
[1] https://www.bloomberg.com/news/articles/2018-06-03/microsoft-is-said-to-have-agreed-to-acquire-coding-site-github
[2] https://techcrunch.com/2018/06/03/microsoft-is-reportedly-acquiring-github/
[3] http://www.businessinsider.fr/us/2-billion-startup-github-could-be-for-sale-microsoft-2018-5

#opensource #github #microsoft

Microsoft официально купили Github за 7.5 миллиарда USD [1] с оплатой акциями, в их пресс релизе упоминается 28 миллионов разработчиков итого получается по 267 USD за одного разработчика, не так уж много если подумать.

А тем временем с начала анонса начался массовый импорт проектов в GitLab [2], о чём активно обсуждают на YCombinator [3] и Reddit [4]

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

Ссылки:
[1] https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/
[2] https://www.bleepingcomputer.com/news/technology/gitlab-sees-huge-traffic-spike-after-news-of-microsoft-buying-github/
[3] https://news.ycombinator.com/item?id=17223116
[4] https://www.reddit.com/r/Ubuntu/comments/8odwlb/gitlab_sees_huge_spike_in_project_imports_seems/

#opensource #microsoft #github

Правильная работа с негативом - это общаться с аудиторией и объяснять, объяснять и ещё раз объяснять. Nat Friedman, будущий CEO Github'а подробно ответил на вопросы разработчиков на Reddit'е в жанре AMA (Ask Me Anything) [1]. За год это самая популярная тема на Reddit по числу комментариев, их там более 1400+ и второй по популярности по просмотрам.

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

Ссылки:
[1] https://www.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman_future_ceo_of_github_ama/

#github

Для тех кто ищет наборы данных побольше, команда Clickhouse обработала данных из Github'а собранные в проекте GHArchive и превратила в большую базу для Clickhouse [1].

Её также можно скачать в виде цельной базы данных для Clickhouse, 71ГБ в сжатом виде [2]

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

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

Ссылки:
[1] https://gh.clickhouse.tech/explorer/
[2] https://gh.clickhouse.tech/explorer/#download-the-dataset

#opendata #bigdata #github #clickhouse

Свежий проект от команды Github'а - FlatData [1] как набор инструментов для сбора и обработки данных в git репозиториях. Это подход который когда-то продвигал Simon Wilson [2], автор многих инструментов и проектов на данных. Действительно Github с его набором действий очень подходит для автоматизации сбора данных. У него же есть пример автоматизации сбора данных о пожарах в Калифорнии [3].

Не менее интересный инструмент Flat Viewer для просмотра простых (плоских) файлов [4].

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

Я могу сказать что про эти инструменты что про десятки других что я видел за последние годы, у них примерно одна и та же проблема - работа с плоскими данными. Данные с которыми я и моя команда работаем, к примеру, почти всегда не_плоские. Это сложные JSON или XML объекты декомпозиция которых назад в плоские таблицы - это большая работа, трудоёмкая и ресурсозатратная. Часто проще с самого начала сохранять сложность первичных данных, преобразуя их только тогда когда есть в этом необходимость. Для такого не подходят CSV и плоский JSON, а скорее файлы построчного JSON lines и BSON (используется в MongoDB)

Я сам выложил в открытый код как минимум 2 инструмента с таким подходом:
- undatum [5] - утилита для обработки данных, с акцентом как раз на JSON lines и BSON.
- apibackuper [6] - утилита для автоматизации выгрузки наборов данных из API с экспортом данных в JSON lines.

С другой стороны я знаю немало инициатив как раз по отказу от платформ вроде Github'а для хранения данных и использованию альтернатив. Например, Giftless [7] от Datopian даёт возможность эмулировать Git LFS поверх локального хранилища и хранилищ Google, Amazon и Azure, тем самым мигрируя с хранилища Github.

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

Ссылки:
[1] https://octo.github.com/projects/flat-data
[2] https://simonwillison.net/2020/Oct/9/git-scraping/
[3] https://github.com/simonw/ca-fires-history
[4] https://flatgithub.com/the-pudding/data
[5] https://github.com/datacoon/undatum/
[6] https://github.com/ruarxive/apibackuper
[7] https://github.com/datopian/giftless

#opendata #datatools #opensource #git #github

Многие разработчики возмущены появлением Github Copilot [1] и использованием их кода ИИ для написания нового кода. А, тем временем, Brendan Dolan-Gavitt из NYU Tandon School of Engineering создал его аналог с открытым кодом и который можно использовать локально. Встречаем FauxPilot [2] в основе которого модели Salesforce CodeGet [3] и NVIDIA Triton Inference Server [4].

Для работы требуется процессор NVIDIA с объёмом видеопамяти от 2ГБ и где-то до 32ГБ для самых больших языковых моделей, выбор из нескольких моделей предусмотрен.

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

Ссылки:
[1] https://t.me/begtin/4020
[2] https://github.com/moyix/fauxpilot
[3] https://github.com/salesforce/CodeGen
[4] https://developer.nvidia.com/nvidia-triton-inference-server

#opensource #github #copilot #datatools #programming #fauxpilot

Полезное чтение про данные, технологии и не только:
- 6 простых шагов для дата-стартапа [1] - если коротко то всё так: цели и ключевые результаты, потоки пользователей, модель заработка, инструменты и каталог событий, каталог метрик, отчеты. С одной стороны разумно, а с другой, достаточно ли? Вот что для Вас важнейший шаг для дата-стартапа?
- О том как работает diffstatic [2] - это такой умный инструмент сравнения знающий 20 языков программирования и делающий сравнение с учётом их синтаксиса. Автор рассказывает как он его разрабатывал.
- Github Copilot делает разработчиков пушистее и шелковистее продуктивнее и счастливее [3] как показывает исследование самого Github'а. Кто бы сомневался что результат будет таким если исследование не независимое. Технология всё ещё имеет свои юридические и этические изъяны.
- Ducks: Поисковик по объектам в Python [4] довольное неожиданная реализация аналога NoSQL а ля MongoDB через словари для Python'а. С похожим языком запросов, но всё только в памяти. Когда надо много чего обрабатывать в памяти, а возможности включать СУБД нет может быть полезно.
- FAIR vs Open Data [5] научная статья в MIT Press Direct со сравнением инициативы FAIR по открытости научных исследований и движений за открытые данные. Это не синонимы и не антиподы, две близкие и пересекающиеся темы.
- Alexa TM 20B [6] научная статья про крупнейшую языковую модель по архитектуре seq2seq [7]. Как минимум полезно тем кто разрабатывает языковые модели.

Ссылки:
[1] https://thedatastrategist.medium.com/6-easy-steps-to-a-data-driven-startup-on-day-1-4e4f900c2667
[2] https://www.wilfred.me.uk/blog/2022/09/06/difftastic-the-fantastic-diff/
[3] https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
[4] https://ducks.readthedocs.io/en/latest/index.html
[5] https://direct.mit.edu/dint/article/doi/10.1162/dint_a_00176/112737/FAIR-Versus-Open-Data-A-Comparison-of-Objectives
[6] https://www.amazon.science/publications/alexatm-20b-few-shot-learning-using-a-large-scale-multilingual-seq2seq-model
[7] https://en.wikipedia.org/wiki/Seq2seq

#opendata #data #github #ai #datatools #readings

Команда исследователей из Microsoft и Github'а разместили препринт статьи Open Data on GitHub: Unlocking the Potential of AI [1], о том что на Github'е хостится порядка 800 миллионов файлов открытых данных общим объёмом около 142 терабайт.

Статья интересная самим фактом рассмотрения Github'а в роли портала открытых данных, но с большими методическими ошибками из-за которых цифрам верить нельзя. Я также анализировал Github как источник наборов данных и главное что понял что как хостинг файлов он хорош, а в остальном, не особо.

Конкретно в этом случае у исследователей есть три фундаментальные ошибки:
1. Недостаточная фильтрация файлов с расширениями вроде .json которые не про данные, а разного рода конфиги из-за чего завышенное число файлов
2. Отсутствие учёта файлов в формате XML, что особенно поразительно, из-за чего, наоборот, занижение числа файлов
3. Отсутствие учёта файлов архивов XZ, GZip, BZ2 и ZIP, которые могут использоваться для хранения всякого, но можно было хотя бы учесть файлы с двойными расширениями .csv.xz, .xml.gz и так далее. Из-за этого очень сильное занижение объёмов хранимых данных.

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

Ссылки:
[1] https://arxiv.org/abs/2306.06191

#opendata #research #microsoft #github #readings

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

По сути и так огромное число датасетов публикуют через Git, особенно научные репозитории выкладывают на Github, а на размещённое там уже дают ссылки с какого нибудь Zenodo.

Причём сделать дата репозитории Microsoft может сделать очень дешёвым образом.
1. Добавить атрибут data к репозиториям с данными, чтобы их можно было бы выделить в поиске.
2. Добавить спецификацию в YAML с метаданными датасета/датасетов в этом репозитории. За основу можно взять DCAT.

К счастью или к сожалению, ничего такого они не делают и, как следствие, своего поиска по данным у Microsoft нет. Но если бы сделали то Github было бы проще индексировать с помощью Dateno.

#opendata #datasets #microsoft #github #thoughts