Ну просто красота... C#, docker, redis, rabbit, mongo, minio... Сразу видно автор хорошо подумал о том что бы собрать в своём проекте поменьше зависимостей... Самодостаточное, самосодержащее решение...
Убрал, изначально поставил тк сама реализация включает в себя С (биндинги, и промежуточные файлы), но думаю и правда С сообществу вряд ли понадобится эта библиотека))
Там не совсем ффмпег. Исключительно декодеры (6 МБ против 40+МБ у всех функций). Так же собран AV1 декодер тк он в другой репе, там в основном ассемблер.
Го библиотека не требует внешних зависимостей тк часть ffmpeg «зашита» и статически слинкована(с использованием cgo), но внешний АПИ чисто гошный. Тесты 80+%, все указанные форматы были проверены.
Хорошая привычка - периодически искать плагины для автоматизации/упрощения процессов, быстрого взаимодейсвия с элементами инфраструктуры/API/контейнерами/git:
Плагин позволяет получать информацию почти из всех sql баз, смотреть таблицы, исполнять query, сохранять креды/пароли в зашифрованном виде. Всё это хорошо сочетается Command Palette, доступ ко многим командам есть через Ctrl+P
Инструмент для тестирования HTTP ендпоинтов, создания автотестов, коллекций тестов. Есть история запросов и переменные окружения, кодогенерация из запросов (с поддержкой большинства популярных языков)!
GUI обертка над некоторыми функциями из grpcurl от storydev. Позволяет визуально посмотреть gRPC апи, используемые типы в запросах, генерирует grpcurl команды.
Поддерживаю! Это лучший способ создать однобокий, скучный продукт. Что бы сделать продукт универсальным нужны разные люди, с разными способностями.
прохождения теста на уровне кандидатского минимума по финансам
Хороший способ подтверждения квалификации - это непосредственная работа над проектом (пул реквест/переводы/дизайн/issue/другое участие). Это подтвердит как заинтересованность в работе, так и возможность улучшить продукт.
1- Злоумышленник, зная IMSI абонента, может передать сообщение FailureReport на HLR, тем самым сделав абонента временно недоступным для передачи данных.
Еще одна альтернатива firebase - pocketbase. Проект с открытым исходным кодом на go, может работать с любым S3 совместимым хранилищем или локальной файловой системой. Можно развернуть в докере.
На разных стадиях разработки ОС «Альт» программисты буквально «препарируют» код.
Это замечательно. Я бы сделал какой-нибудь открытый сервис на блокчейне, в котором можно было бы посмотреть кто какие строки провалидировал.
Это было бы полезно, чтобы люди в разных местах не занимались перепроверкой одних и тех же строк кода, просто ради оптимизации. Плюс всем будет понятно, что работа в этом направлении реально ведется.
KISS важен :) Не совсем к теме статьи, но добавил бы что можно еще поисследовать репозитории людей которые очень давно пишут на go: пример1, пример2, пример3, пример4, пример5.
Там можно подтянуть конфиги линтеров, посмотреть как пишется документация к функциям, как проекты структурируются. Тоже может быть полезно.
gitea - это форк gogs с большим сообществом, дополнительными фишками и MIT лицензией. Всем кто хочет быстро развернуть gitea и почту на своём железе сюда - репа
А вы уверены что у вас хватит квалификации этот фундамент качественно укреплять?
Это должно решать сообщество. Мне не кажутся невозможным создание PR в открытые проекты, помощь в реализации уже существующих инструментов.
При этом даже направление квалификации не имеет значения, разные люди решают разные задачи.
И у вас есть на это время? Или вы готовы заниматься этим в свободное от работы время? Или у вас официально отводится сколько-то процентов времени на непроектные (технические) задачи?
Время есть.
Когда работал, занимался открытыми проектами в личное время (с чайком и музыкой по-вечерам).
Официально у меня не было возможности заниматься открытыми проектами, хотя на мой взгляд от 80% практически любой кодовой базы можно открывать (если функциональность хорошо разделена на компоненты).
В этом есть необходимость? Продолжать работать на своём уровне абстракций, постепенно расширяя границы фундамента свободных/открытых программ тоже хорошо.
Первой моей системой был windows, потом я попробовал macos. Потом ради интереса начал пробовать разные дистрибутивы. Сначала elementary, потом ubuntu, calculate, fedora. При чем это было сильно размазано по времени, но возвращался к windows/macos. Потом я попробовал manjaro и это было сильно удобнее для работы, потому что docker контейнеры быстрее собираются, чем на windows.
Главное не переставать пробовать, дистрибутивов очень много. 100% какой-нибудь подойдет, а если нет, то можно собрать свой из arch, gentoo или from scratch или еще как-нибудь.
Ну просто красота... C#, docker, redis, rabbit, mongo, minio... Сразу видно автор хорошо подумал о том что бы собрать в своём проекте поменьше зависимостей... Самодостаточное, самосодержащее решение...
Добавил mpegts демуксер. Теперь можно разбить плейлист на куски и скормить либе:
Если дадите url помогу протестировать.
Убрал, изначально поставил тк сама реализация включает в себя С (биндинги, и промежуточные файлы), но думаю и правда С сообществу вряд ли понадобится эта библиотека))
Надо добавить флаг при сборке: --enable-demuxer=hls,m3u8, тогда будет работать. Скрипт лежит в cmd/build/main.go. Завтра вечером добавлю в master.
Если для вас не критичен single-binary, то вот порт использующий зависимость: https://github.com/u2takey/ffmpeg-go
Там не совсем ффмпег. Исключительно декодеры (6 МБ против 40+МБ у всех функций). Так же собран AV1 декодер тк он в другой репе, там в основном ассемблер.
Го библиотека не требует внешних зависимостей тк часть ffmpeg «зашита» и статически слинкована(с использованием cgo), но внешний АПИ чисто гошный. Тесты 80+%, все указанные форматы были проверены.
Спасибо за статью!
Хорошая привычка - периодически искать плагины для автоматизации/упрощения процессов, быстрого взаимодейсвия с элементами инфраструктуры/API/контейнерами/git:
1) SQL базы: SQL-Tools
VSCode: https://marketplace.visualstudio.com/items?itemName=mtxr.sqltools
VSCodium: https://open-vsx.org/extension/mtxr/sqltools
Плагин позволяет получать информацию почти из всех sql баз, смотреть таблицы, исполнять query, сохранять креды/пароли в зашифрованном виде. Всё это хорошо сочетается Command Palette, доступ ко многим командам есть через Ctrl+P
2) HTTP клиент: Thunder Client (*проприетарный)
VSCode: https://marketplace.visualstudio.com/items?itemName=rangav.vscode-thunder-client
VSCodium: https://open-vsx.org/extension/rangav/vscode-thunder-client
Инструмент для тестирования HTTP ендпоинтов, создания автотестов, коллекций тестов. Есть история запросов и переменные окружения, кодогенерация из запросов (с поддержкой большинства популярных языков)!
3) gRPC клиент: gRPC Clicker
VSCode: https://marketplace.visualstudio.com/items?itemName=Dancheg97.grpc-clicker
VSCodium: https://open-vsx.org/extension/dancheg97/grpc-clicker
GUI обертка над некоторыми функциями из grpcurl от storydev. Позволяет визуально посмотреть gRPC апи, используемые типы в запросах, генерирует grpcurl команды.
4) Docker - Docker
VSCode: https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-docker
VSCodium: https://open-vsx.org/extension/ms-azuretools/vscode-docker
В общем то все функции докера, хотя некоторые всё же удобнее через терминал.
5) Mario: The Block Jumper Extension: быстрая навигация по коду
VSCode: https://marketplace.visualstudio.com/items?itemName=jeff-hykin.mario
VSCodium: https://open-vsx.org/extension/jeff-hykin/mario
Удобный плагин для быстрой навигации по блокам кода.
---
Есть еще пара не озвученных горячих клавиш:
1) Ctrl+Shift+A - фокусировка Activity Bar, для быстрого доступа к разным плагинам
2) Ctrl+Shift+F на выделении - поиск по рабочей директории, удобно для поиска дубликатов и рефакторинга.
Поддерживаю! Это лучший способ создать однобокий, скучный продукт. Что бы сделать продукт универсальным нужны разные люди, с разными способностями.
Хороший способ подтверждения квалификации - это непосредственная работа над проектом (пул реквест/переводы/дизайн/issue/другое участие). Это подтвердит как заинтересованность в работе, так и возможность улучшить продукт.
Не знал про существование данных проблем.
Еще одна альтернатива firebase - pocketbase. Проект с открытым исходным кодом на go, может работать с любым S3 совместимым хранилищем или локальной файловой системой. Можно развернуть в докере.
Это замечательно. Я бы сделал какой-нибудь открытый сервис на блокчейне, в котором можно было бы посмотреть кто какие строки провалидировал.
Это было бы полезно, чтобы люди в разных местах не занимались перепроверкой одних и тех же строк кода, просто ради оптимизации. Плюс всем будет понятно, что работа в этом направлении реально ведется.
Спасибо за статью!
KISS важен :) Не совсем к теме статьи, но добавил бы что можно еще поисследовать репозитории людей которые очень давно пишут на go: пример1, пример2, пример3, пример4, пример5.
Там можно подтянуть конфиги линтеров, посмотреть как пишется документация к функциям, как проекты структурируются. Тоже может быть полезно.
Присоединяюсь!
gitea - это форк gogs с большим сообществом, дополнительными фишками и MIT лицензией. Всем кто хочет быстро развернуть gitea и почту на своём железе сюда - репа
Было бы хорошо иметь генераторы на подобии https://github.com/kyleconroy/sqlc
Спасибо за статью!
Мне кажется, что базовое умение работать с командной строкой вряд ли кому-то повредит.
Это должно решать сообщество. Мне не кажутся невозможным создание PR в открытые проекты, помощь в реализации уже существующих инструментов.
При этом даже направление квалификации не имеет значения, разные люди решают разные задачи.
Время есть.
Когда работал, занимался открытыми проектами в личное время (с чайком и музыкой по-вечерам).
Официально у меня не было возможности заниматься открытыми проектами, хотя на мой взгляд от 80% практически любой кодовой базы можно открывать (если функциональность хорошо разделена на компоненты).
В этом есть необходимость? Продолжать работать на своём уровне абстракций, постепенно расширяя границы фундамента свободных/открытых программ тоже хорошо.
Ungoogled chromium собрал примерно за 3 часа на среднем ноутбуке.
Первой моей системой был windows, потом я попробовал macos. Потом ради интереса начал пробовать разные дистрибутивы. Сначала elementary, потом ubuntu, calculate, fedora. При чем это было сильно размазано по времени, но возвращался к windows/macos. Потом я попробовал manjaro и это было сильно удобнее для работы, потому что docker контейнеры быстрее собираются, чем на windows.
Главное не переставать пробовать, дистрибутивов очень много. 100% какой-нибудь подойдет, а если нет, то можно собрать свой из arch, gentoo или from scratch или еще как-нибудь.