Facebook настолько не устраивал Git, что в итоге компания создала ему сразу три замены.
Начиналось всё как у многих: один огромный monorepo, в котором лежал код всех команд.
По мере роста кодовой базы Git начал сдавать. Обычный
Facebook обратился к мейнтейнерам Git с вопросом, как масштабировать такую систему.
Ответ был простой: разбить репозиторий на несколько поменьше.
Для Facebook это не подходило. Весь смысл был именно в monorepo.
Тогда инженеры обратили внимание на менее популярный Mercurial. Его было проще расширять, а сообщество охотнее принимало изменения. Facebook перенёс туда всю кодовую базу и помог превратить Mercurial в один из лучших вариантов для огромных monorepo.
Но со временем и Mercurial упёрся в ограничения.
Тогда Facebook написал собственную систему контроля версий с нуля — Sapling.
А когда кодовая база выросла настолько, что один инженер уже физически не мог скачать её целиком на ноутбук, появился EdenFS — виртуальная файловая система, которая подгружает файл только в тот момент, когда разработчик реально его открывает.
Три замены. Одна компания. И всё потому, что кодовая база росла быстрее, чем успевали масштабироваться существующие системы контроля версий.
Большинство компаний подстраивают рабочие процессы под доступные инструменты.
Facebook просто создаёт новые инструменты, когда старые перестают справляться.
👉 @PythonPortal
Начиналось всё как у многих: один огромный monorepo, в котором лежал код всех команд.
По мере роста кодовой базы Git начал сдавать. Обычный
git fetch мог занимать до 30 минут. Инженеры тратили больше времени на ожидание Git, чем на написание кода.Facebook обратился к мейнтейнерам Git с вопросом, как масштабировать такую систему.
Ответ был простой: разбить репозиторий на несколько поменьше.
Для Facebook это не подходило. Весь смысл был именно в monorepo.
Тогда инженеры обратили внимание на менее популярный Mercurial. Его было проще расширять, а сообщество охотнее принимало изменения. Facebook перенёс туда всю кодовую базу и помог превратить Mercurial в один из лучших вариантов для огромных monorepo.
Но со временем и Mercurial упёрся в ограничения.
Тогда Facebook написал собственную систему контроля версий с нуля — Sapling.
А когда кодовая база выросла настолько, что один инженер уже физически не мог скачать её целиком на ноутбук, появился EdenFS — виртуальная файловая система, которая подгружает файл только в тот момент, когда разработчик реально его открывает.
Три замены. Одна компания. И всё потому, что кодовая база росла быстрее, чем успевали масштабироваться существующие системы контроля версий.
Большинство компаний подстраивают рабочие процессы под доступные инструменты.
Facebook просто создаёт новые инструменты, когда старые перестают справляться.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤16👍6😁2
В Python обычный 🐍
Например:
Если нужно сохранить все элементы, есть
Недостающие значения он по умолчанию заполняет
Небольшая штука, но полезно помнить, когда объединяете данные из источников разной длины.
👉 @PythonPortal
zip() может незаметно «съесть» часть данных, если списки разной длины. Например:
x = [1, 2, 3, 4, 5]
y = ['a', 'b', 'c']
list(zip(x, y))
# [(1, 'a'), (2, 'b'), (3, 'c')]
zip() останавливается, как только заканчивается самый короткий список — поэтому 4 и 5 просто не попадут в результат.Если нужно сохранить все элементы, есть
itertools.zip_longest():import itertools
list(itertools.zip_longest(x, y))
# [(1, 'a'), (2, 'b'), (3, 'c'), (4, None), (5, None)]
Недостающие значения он по умолчанию заполняет
None.Небольшая штука, но полезно помнить, когда объединяете данные из источников разной длины.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10❤4
This media is not supported in your browser
VIEW IN TELEGRAM
Wan2GP — бесплатная опенсорсная альтернатива облачным сервисам для генерации AI-видео вроде Higgsfield.
Всё запускается локально и, по заявлению разработчиков, работает даже с 6 ГБ VRAM, старыми RTX 10-й серии и ноутбуками с 8 ГБ памяти.
Внутри:
— генерация видео из текста и изображений
— Wan 2.2, LTX-2, Hunyuan Video и Flux
— браузерный интерфейс с очередью генераций
— поддержка LoRA
— редактор масок
— улучшение промптов
Пятисекундный ролик на среднем игровом ПК можно сгенерировать за несколько минут.
Без подписки, облака, лимитов и водяных знаков. Всё бесплатно.
https://github.com/deepbeepmeep/Wan2GP
Ну, если считать видеокарту и электричество бесплатными.🥲
👉 @PythonPortal
Всё запускается локально и, по заявлению разработчиков, работает даже с 6 ГБ VRAM, старыми RTX 10-й серии и ноутбуками с 8 ГБ памяти.
Внутри:
— генерация видео из текста и изображений
— Wan 2.2, LTX-2, Hunyuan Video и Flux
— браузерный интерфейс с очередью генераций
— поддержка LoRA
— редактор масок
— улучшение промптов
Пятисекундный ролик на среднем игровом ПК можно сгенерировать за несколько минут.
Без подписки, облака, лимитов и водяных знаков. Всё бесплатно.
https://github.com/deepbeepmeep/Wan2GP
Ну, если считать видеокарту и электричество бесплатными.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤6
Сохрани этот ресурс, если работаешь с SQL.
Это playground без установки, где можно:
- создавать таблицы, выполнять запросы и делиться результатами;
- работать с MySQL, PostgreSQL и SQL Server.
Бесплатно и без установки:
→ http://runsql.com/r
👉 @PythonPortal
Это playground без установки, где можно:
- создавать таблицы, выполнять запросы и делиться результатами;
- работать с MySQL, PostgreSQL и SQL Server.
Бесплатно и без установки:
→ http://runsql.com/r
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤5
Лучшие инженеры не изучают распределённые системы по поверхностным пересказам. Они сразу обращаются к фундаментальным научным статьям. Чтение таких работ помогает понять, почему системы спроектированы именно так, а не просто научиться ими пользоваться.
Вот пять классических статей всех времён, которые должен прочитать каждый разработчик.
1. The Google File System (2003)
Почему стоит прочитать: статья изменила подход всей индустрии, предложив считать отказ компонентов нормой, а не исключением. В ней описано, как построить масштабную отказоустойчивую распределённую систему хранения данных на базе недорогого массового оборудования, оптимизировав её под интенсивную последовательную дозапись вместо произвольной записи.
Ссылка: https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf
2. Dynamo: Amazon’s Highly Available Key-Value Store (2007)
Почему стоит прочитать: исчерпывающий разбор того, как пожертвовать согласованностью ради высокой доступности — AP в теореме CAP. В статье изложены ключевые паттерны, лежащие в основе масштабируемых NoSQL-хранилищ: консистентное хеширование, векторные часы, gossip-протоколы и настраиваемый кворум для операций чтения и записи.
Ссылка: https://allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
3. In Search of an Understandable Consensus Algorithm (Raft) (2014)
Почему стоит прочитать: Paxos печально известен тем, насколько сложно его понять и корректно реализовать, тогда как Raft делает концепцию реплицируемых конечных автоматов более доступной. Алгоритм разбивает задачу консенсуса на отдельные подзадачи, которые легко анализировать: выбор лидера, репликацию журнала и обеспечение безопасности.
Ссылка: https://raft.github.io/raft.pdf
4. Spanner: Google’s Globally-Distributed Database (2012)
Почему стоит прочитать: статья показывает, как добиться строгой сериализуемости и внешней согласованности между дата-центрами по всему миру. Секрет — API Google TrueTime, ограничивающий неопределённость времени с помощью синхронизированных GPS-приёмников и атомных часов.
Ссылка: https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf
5. Time, Clocks, and the Ordering of Events in a Distributed System
Почему стоит прочитать: на физическое время нельзя полагаться при работе с независимыми узлами. Лэмпорт вводит логические часы и фундаментальное отношение «произошло до» (happened-before), лежащее в основе упорядочивания событий в современных распределённых сетях.
Ссылка: https://amturing.acm.org/p558-lamport.pdf
👉 @PythonPortal
Вот пять классических статей всех времён, которые должен прочитать каждый разработчик.
1. The Google File System (2003)
Почему стоит прочитать: статья изменила подход всей индустрии, предложив считать отказ компонентов нормой, а не исключением. В ней описано, как построить масштабную отказоустойчивую распределённую систему хранения данных на базе недорогого массового оборудования, оптимизировав её под интенсивную последовательную дозапись вместо произвольной записи.
Ссылка: https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf
2. Dynamo: Amazon’s Highly Available Key-Value Store (2007)
Почему стоит прочитать: исчерпывающий разбор того, как пожертвовать согласованностью ради высокой доступности — AP в теореме CAP. В статье изложены ключевые паттерны, лежащие в основе масштабируемых NoSQL-хранилищ: консистентное хеширование, векторные часы, gossip-протоколы и настраиваемый кворум для операций чтения и записи.
Ссылка: https://allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
3. In Search of an Understandable Consensus Algorithm (Raft) (2014)
Почему стоит прочитать: Paxos печально известен тем, насколько сложно его понять и корректно реализовать, тогда как Raft делает концепцию реплицируемых конечных автоматов более доступной. Алгоритм разбивает задачу консенсуса на отдельные подзадачи, которые легко анализировать: выбор лидера, репликацию журнала и обеспечение безопасности.
Ссылка: https://raft.github.io/raft.pdf
4. Spanner: Google’s Globally-Distributed Database (2012)
Почему стоит прочитать: статья показывает, как добиться строгой сериализуемости и внешней согласованности между дата-центрами по всему миру. Секрет — API Google TrueTime, ограничивающий неопределённость времени с помощью синхронизированных GPS-приёмников и атомных часов.
Ссылка: https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf
5. Time, Clocks, and the Ordering of Events in a Distributed System
Почему стоит прочитать: на физическое время нельзя полагаться при работе с независимыми узлами. Лэмпорт вводит логические часы и фундаментальное отношение «произошло до» (happened-before), лежащее в основе упорядочивания событий в современных распределённых сетях.
Ссылка: https://amturing.acm.org/p558-lamport.pdf
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8❤2👍1
collections.ChainMap — встроенный класс Python, который объединяет несколько словарей или других отображений в единое обновляемое представление.Вместо слияния словарей и создания новых структур данных в памяти он связывает их по ссылке, позволяя выполнять поиск и управлять ими как единым целым.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍2
Media is too big
VIEW IN TELEGRAM
Opus 5 пересобрал Pokémon в виде полностью играбельной 3D-игры.
промпт и репо: https://github.com/PauliusOS/pallet-town-3d
👉 @PythonPortal
промпт и репо: https://github.com/PauliusOS/pallet-town-3d
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🏆2🤝1
This media is not supported in your browser
VIEW IN TELEGRAM
Мы постоянно обсуждаем LLM и их непрерывное развитие, но следующая революция уже совсем близко.
Робототехника изменит всё не меньше. А возможно, даже сильнее.
👉 @PythonPortal
Робототехника изменит всё не меньше. А возможно, даже сильнее.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍6
Добро пожаловать в мир разработки
Проект «TERMINAL» стал крупнейшей библиотекой бесплатного образования. В одном канале собраны курсы, книги, полезные инструменты и практические тренажёры для всех разработчиков
🎓 Практические курсы и задания
🪽 Книги и статьи известных авторов
😮💨 Полезные инструменты и ресурсы
🌟 IT-новости и инсайды
Обучение по всем направлениям: SQL, Python, ML, Frontend, PHP, C++, Go, GIT, Linux, QA, Java, Vibe-coding, Infosec и др.
Ценишь знания, подпишись: Terminal_tg
Проект «TERMINAL» стал крупнейшей библиотекой бесплатного образования. В одном канале собраны курсы, книги, полезные инструменты и практические тренажёры для всех разработчиков
Обучение по всем направлениям: SQL, Python, ML, Frontend, PHP, C++, Go, GIT, Linux, QA, Java, Vibe-coding, Infosec и др.
Ценишь знания, подпишись: Terminal_tg
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1🤣1
Oracle, возможно, устроила одно из самых громких убийств open-source проекта в истории.
Речь о Solaris. Эта ОС получила возможности, похожие на контейнеры, за много лет до появления Docker.
Разработанная Sun Microsystems, Solaris в 1990-х и 2000-х работала в дата-центрах, университетах и банках по всему миру.
Технология Solaris Zones позволяла запускать изолированные окружения задолго до того, как Docker сделал контейнеры массовыми. ZFS принесла снапшоты, самовосстанавливающееся хранилище и проверки целостности данных ещё тогда, когда аналогов практически не существовало. Solaris не догоняла индустрию — индустрия догоняла Solaris.
В 2010 году Oracle купила Sun Microsystems за 7,4 млрд долларов.
Спустя несколько месяцев компания закрыла открытую модель разработки, благодаря которой инженеры со всего мира могли участвовать в развитии проекта. Уже в августе 2010 года Oracle полностью прекратила публикацию исходного кода.
Разработчики, которые годами отправляли патчи, не стали ждать. Многие ушли в Linux, где разработка оставалась открытой и развивалась быстрее.
Бывшие инженеры Sun решили не дать проекту исчезнуть. Через несколько часов после закрытия открытой разработки они запустили illumos — продолжение Solaris на базе последней открытой версии исходного кода Sun.
Oracle продолжила продавать Solaris корпоративным клиентам, но в 2017 году уволила большую часть команд Solaris и SPARC. К 2019 году система перешла в режим sustaining support.
Если перевести с корпоративного языка, это означает: «Мы ответим на ваши обращения, но ничего нового больше не ждите».
Solaris проиграла не из-за плохой инженерии. Она проиграла компании, для которой контракты на поддержку оказались важнее будущего продукта.
illumos существует до сих пор. Проект остаётся открытым и поддерживается инженерами, которых Oracle так и не смогла удержать.
👉 @PythonPortal
Речь о Solaris. Эта ОС получила возможности, похожие на контейнеры, за много лет до появления Docker.
Разработанная Sun Microsystems, Solaris в 1990-х и 2000-х работала в дата-центрах, университетах и банках по всему миру.
Технология Solaris Zones позволяла запускать изолированные окружения задолго до того, как Docker сделал контейнеры массовыми. ZFS принесла снапшоты, самовосстанавливающееся хранилище и проверки целостности данных ещё тогда, когда аналогов практически не существовало. Solaris не догоняла индустрию — индустрия догоняла Solaris.
В 2010 году Oracle купила Sun Microsystems за 7,4 млрд долларов.
Спустя несколько месяцев компания закрыла открытую модель разработки, благодаря которой инженеры со всего мира могли участвовать в развитии проекта. Уже в августе 2010 года Oracle полностью прекратила публикацию исходного кода.
Разработчики, которые годами отправляли патчи, не стали ждать. Многие ушли в Linux, где разработка оставалась открытой и развивалась быстрее.
Бывшие инженеры Sun решили не дать проекту исчезнуть. Через несколько часов после закрытия открытой разработки они запустили illumos — продолжение Solaris на базе последней открытой версии исходного кода Sun.
Oracle продолжила продавать Solaris корпоративным клиентам, но в 2017 году уволила большую часть команд Solaris и SPARC. К 2019 году система перешла в режим sustaining support.
Если перевести с корпоративного языка, это означает: «Мы ответим на ваши обращения, но ничего нового больше не ждите».
Solaris проиграла не из-за плохой инженерии. Она проиграла компании, для которой контракты на поддержку оказались важнее будущего продукта.
illumos существует до сих пор. Проект остаётся открытым и поддерживается инженерами, которых Oracle так и не смогла удержать.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9😢3