awesome-3d-printing
Это подборка лучших ресурсов, инструментов и программ для 3D-печати, собранных в одном репозитории.
Репозиторий содержит ссылки на программы для создания, редактирования и подготовки 3D-моделей, а также утилиты для управления принтерами.
Здесь собраны как средства моделирования, так и ПО для слайсинга, мониторинга и анализа данных о печати.
Cсылка на GitHub
➡️ GitHub Ready | #урок
Это подборка лучших ресурсов, инструментов и программ для 3D-печати, собранных в одном репозитории.
Репозиторий содержит ссылки на программы для создания, редактирования и подготовки 3D-моделей, а также утилиты для управления принтерами.
Здесь собраны как средства моделирования, так и ПО для слайсинга, мониторинга и анализа данных о печати.
Cсылка на GitHub
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1
🔍 Как найти коммит, который сломал сборку? (Git Bisect)
Бывает так: вчера проект работал идеально, а сегодня — всё падает. Ты не знаешь, в какой именно момент закралась ошибка, ведь за день было сделано 20 коммитов. Перебирать каждый вручную — долго и мучительно.
Задача:
— Быстро найти тот самый «плохой» коммит среди десятков других.
— Автоматизировать поиск бага, даже если ты не знаешь, где именно в коде проблема.
Решение:
Используем «бинарный поиск» через git bisect. Git делит историю пополам, спрашивает тебя «тут работает?», и так за считанные шаги находит виновника.
1. Запускаем процесс
git bisect start
2. Помечаем текущее состояние как “плохое” (тут баг есть)
git bisect bad
3. Указываем хэш коммита, когда всё точно работало (например, вчерашний)
git bisect good 7b2f3a1
Git переключит тебя на коммит ровно посередине.
Проверяешь код (запускаешь тесты или приложение).
4. Если баг остался:
git bisect bad
Если всё работает:
git bisect good
Повторяй, пока Git не выдаст хэш того самого коммита-преступника.
5. Завершаем поиск и возвращаемся в реальность:
git bisect reset
Почему это магия?
— Скорость: чтобы найти ошибку среди 1000 коммитов, тебе понадобится всего около 10 проверок.
— Автоматизация: если у тебя есть готовый скрипт проверки, можно запустить git bisect run ./test.sh, и Git сам найдет баг, пока ты пьешь кофе.
🔥 — если bisect — твой главный детектив
🤝 — если ищешь баги глазами до победного
➡️ GitHub Ready | #урок
Бывает так: вчера проект работал идеально, а сегодня — всё падает. Ты не знаешь, в какой именно момент закралась ошибка, ведь за день было сделано 20 коммитов. Перебирать каждый вручную — долго и мучительно.
Задача:
— Быстро найти тот самый «плохой» коммит среди десятков других.
— Автоматизировать поиск бага, даже если ты не знаешь, где именно в коде проблема.
Решение:
Используем «бинарный поиск» через git bisect. Git делит историю пополам, спрашивает тебя «тут работает?», и так за считанные шаги находит виновника.
1. Запускаем процесс
git bisect start
2. Помечаем текущее состояние как “плохое” (тут баг есть)
git bisect bad
3. Указываем хэш коммита, когда всё точно работало (например, вчерашний)
git bisect good 7b2f3a1
Git переключит тебя на коммит ровно посередине.
Проверяешь код (запускаешь тесты или приложение).
4. Если баг остался:
git bisect bad
Если всё работает:
git bisect good
Повторяй, пока Git не выдаст хэш того самого коммита-преступника.
5. Завершаем поиск и возвращаемся в реальность:
git bisect reset
Почему это магия?
— Скорость: чтобы найти ошибку среди 1000 коммитов, тебе понадобится всего около 10 проверок.
— Автоматизация: если у тебя есть готовый скрипт проверки, можно запустить git bisect run ./test.sh, и Git сам найдет баг, пока ты пьешь кофе.
🔥 — если bisect — твой главный детектив
🤝 — если ищешь баги глазами до победного
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1🔥1
🕵️ Кто это сделал? Находим автора каждой строки (Git Blame)
Бывает, открываешь файл и видишь странный кусок кода, который ломает тебе всю логику. Хочется спросить автора: «Зачем здесь это условие?». Чтобы не гадать и не пролистывать всю историю коммитов, в Git есть инструмент «расследования».
Задача:
— Узнать, кто последним редактировал конкретную строку.
— Найти коммит, в котором появилось это изменение.
— Понять контекст: когда и в рамках какой задачи был написан этот код.
Решение:
Используем команду blame. Она выводит содержимое файла, а слева от каждой строки подписывает хэш коммита, автора и дату.
Почему это полезно?
— Экономия времени: не нужно вручную искать, когда изменилась функция.
— Коммуникация: ты точно знаешь, к кому подойти за пояснениями по коду.
— Ретроспектива: часто видишь, что «костыль» был поставлен три года назад для бага, которого уже не существует.
Совет: В современных IDE (VS Code, WebStorm) есть плагины вроде GitLens. Они показывают информацию из blame прямо в редакторе серым текстом в конце текущей строки. Это позволяет проводить «расследование», даже не открывая терминал.
🔥 — если постоянно проверяешь, кто накодил этот шедевр
🤝 — если и так помнишь весь свой код (и чужой тоже)
➡️ GitHub Ready | #урок
Бывает, открываешь файл и видишь странный кусок кода, который ломает тебе всю логику. Хочется спросить автора: «Зачем здесь это условие?». Чтобы не гадать и не пролистывать всю историю коммитов, в Git есть инструмент «расследования».
Задача:
— Узнать, кто последним редактировал конкретную строку.
— Найти коммит, в котором появилось это изменение.
— Понять контекст: когда и в рамках какой задачи был написан этот код.
Решение:
Используем команду blame. Она выводит содержимое файла, а слева от каждой строки подписывает хэш коммита, автора и дату.
# Посмотреть авторов всех строк в файле
git blame path/to/file.js
# Если файл огромный, смотрим только нужный диапазон (например, с 10 по 20 строку)
git blame -L 10,20 path/to/file.js
# Показать e-mail автора вместо имени (удобно, если в команде два Ивана)
git blame -e path/to/file.jsПочему это полезно?
— Экономия времени: не нужно вручную искать, когда изменилась функция.
— Коммуникация: ты точно знаешь, к кому подойти за пояснениями по коду.
— Ретроспектива: часто видишь, что «костыль» был поставлен три года назад для бага, которого уже не существует.
Совет: В современных IDE (VS Code, WebStorm) есть плагины вроде GitLens. Они показывают информацию из blame прямо в редакторе серым текстом в конце текущей строки. Это позволяет проводить «расследование», даже не открывая терминал.
🔥 — если постоянно проверяешь, кто накодил этот шедевр
🤝 — если и так помнишь весь свой код (и чужой тоже)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Bubble Tea — это мощный и элегантный фреймворк для создания терминальных пользовательских интерфейсов (TUI) на языке Go. С его помощью можно легко разрабатывать интерактивные и динамичные консольные приложения.
Основные особенности Bubble Tea:
- Модельная архитектура: реализация на основе архитектуры Model-Update-View (MUV), напоминающей Elm.
- Гибкость: подходит как для простых CLI-приложений, так и для сложных интерфейсов с анимацией.
- Совместимость: легко интегрируется с другими библиотеками и инструментами на Go.
- Поддержка таймеров и анимации: для создания динамичных эффектов.
- Простота тестирования: чистый и читаемый код.
https://github.com/charmbracelet/bubbletea
➡️ GitHub Ready | #урок
Основные особенности Bubble Tea:
- Модельная архитектура: реализация на основе архитектуры Model-Update-View (MUV), напоминающей Elm.
- Гибкость: подходит как для простых CLI-приложений, так и для сложных интерфейсов с анимацией.
- Совместимость: легко интегрируется с другими библиотеками и инструментами на Go.
- Поддержка таймеров и анимации: для создания динамичных эффектов.
- Простота тестирования: чистый и читаемый код.
https://github.com/charmbracelet/bubbletea
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
🔍 Как искать по коду быстрее, чем в IDE? (Git Grep)
Когда проект разрастается до тысяч файлов, обычный поиск в VS Code или WebStorm может начать подтормаживать. У Git есть встроенный инструмент поиска, который работает напрямую с базой данных репозитория — это невероятно быстро.
Задача:
— Найти все упоминания функции или переменной во всем проекте.
— Найти строку кода не только в текущем состоянии, но и в других ветках или старых коммитах.
Решение:
Используем команду grep. Она оптимизирована для работы с текстовыми файлами внутри Git.
Почему это мощнее обычного поиска?
— Скорость: Git ищет по своим индексам, что почти всегда быстрее, чем перебор файлов файловой системой.
— Гибкость: ты можешь искать код в истории или в ветках, которых у тебя даже нет «развернутыми» в папке.
— Чистота: git grep автоматически игнорирует всё, что прописано в .gitignore (никакого мусора из node_modules или dist в результатах).
Совет: Если хочешь увидеть контекст (строки до и после найденной), добавь флаги -B (before) и -A (after). Например, git grep -C 2 “function” покажет саму строку и по 2 строки вокруг неё.
🔥 — если терминал для тебя быстрее любого GUI
🤝 — если по старинке жмешь Ctrl + Shift + F
➡️ GitHub Ready | #урок
Когда проект разрастается до тысяч файлов, обычный поиск в VS Code или WebStorm может начать подтормаживать. У Git есть встроенный инструмент поиска, который работает напрямую с базой данных репозитория — это невероятно быстро.
Задача:
— Найти все упоминания функции или переменной во всем проекте.
— Найти строку кода не только в текущем состоянии, но и в других ветках или старых коммитах.
Решение:
Используем команду grep. Она оптимизирована для работы с текстовыми файлами внутри Git.
# Найти строку "authService" во всех файлах проекта
git grep "authService"
# Показать номера строк, где найдено совпадение
git grep -n "api_key"
# Ограничить поиск только определенным типом файлов (например, JS)
git grep "useEffect" -- '*.js'
# Самое крутое: поиск в другой ветке (не переключаясь на неё!)
git grep "new_feature" feature-branch
# Найти, сколько раз встречается слово (подсчет)
git grep -c "TODO"Почему это мощнее обычного поиска?
— Скорость: Git ищет по своим индексам, что почти всегда быстрее, чем перебор файлов файловой системой.
— Гибкость: ты можешь искать код в истории или в ветках, которых у тебя даже нет «развернутыми» в папке.
— Чистота: git grep автоматически игнорирует всё, что прописано в .gitignore (никакого мусора из node_modules или dist в результатах).
Совет: Если хочешь увидеть контекст (строки до и после найденной), добавь флаги -B (before) и -A (after). Например, git grep -C 2 “function” покажет саму строку и по 2 строки вокруг неё.
🔥 — если терминал для тебя быстрее любого GUI
🤝 — если по старинке жмешь Ctrl + Shift + F
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝3
🏗 Rebase vs Merge: как не превратить историю в «спагетти»?
Когда приходит время вливать свою ветку в main, перед тобой встает выбор: нажать кнопку Merge или использовать Rebase. Оба способа объединяют код, но делают это совершенно по-разному.
Задача:
— Объединить наработки из разных веток.
— Решить, важна ли тебе хронология событий или «чистая» прямая линия коммитов.
Решение:
1. Git Merge (Консервативный путь)
Создает специальный «мерж-коммит», который связывает две ветки.
— Плюсы: сохраняется история того, когда ветка была создана и влита. Это безопасно для общих веток.
— Минусы: если веток много, история превращается в запутанный клубок линий.
2. Git Rebase (Путь перфекциониста)
Берет твои коммиты и «переклеивает» их поверх последних коммитов из main.
— Плюсы: история выглядит как одна прямая линия, её легко читать.
— Минусы: переписывается история (хэши коммитов меняются). Никогда не делай ребейз в ветках, с которыми работают другие люди!
Почему это важно?
— Для работы в команде: обычно договариваются об одном стиле. Например: «все фичи вливаем через rebase, а релизы через merge».
— Для поиска багов: по прямой линии (после ребейза) гораздо проще искать ошибки через bisect.
— Для эстетики: чистый git log — это просто приятно.
Совет: Если ты запутался в процессе ребейза, всегда можно всё отменить командой git rebase –abort.
🔥 — если за идеальную линию в rebase
🤝 — если доверяешь только классическому merge
Когда приходит время вливать свою ветку в main, перед тобой встает выбор: нажать кнопку Merge или использовать Rebase. Оба способа объединяют код, но делают это совершенно по-разному.
Задача:
— Объединить наработки из разных веток.
— Решить, важна ли тебе хронология событий или «чистая» прямая линия коммитов.
Решение:
1. Git Merge (Консервативный путь)
Создает специальный «мерж-коммит», который связывает две ветки.
git checkout main
git merge feature-branch— Плюсы: сохраняется история того, когда ветка была создана и влита. Это безопасно для общих веток.
— Минусы: если веток много, история превращается в запутанный клубок линий.
2. Git Rebase (Путь перфекциониста)
Берет твои коммиты и «переклеивает» их поверх последних коммитов из main.
git checkout feature-branch
git rebase main— Плюсы: история выглядит как одна прямая линия, её легко читать.
— Минусы: переписывается история (хэши коммитов меняются). Никогда не делай ребейз в ветках, с которыми работают другие люди!
Почему это важно?
— Для работы в команде: обычно договариваются об одном стиле. Например: «все фичи вливаем через rebase, а релизы через merge».
— Для поиска багов: по прямой линии (после ребейза) гораздо проще искать ошибки через bisect.
— Для эстетики: чистый git log — это просто приятно.
Совет: Если ты запутался в процессе ребейза, всегда можно всё отменить командой git rebase –abort.
🔥 — если за идеальную линию в rebase
🤝 — если доверяешь только классическому merge
🤝3
🏷 Conventional Commits: как писать сообщения, которые поймут все?
Когда ты заглядываешь в git log через месяц, сообщения типа «fix», «updated» или «добавил кнопку» не говорят ни о чем. Чтобы история проекта была читаемой, разработчики придумали стандарт Conventional Commits. Это делает твой репозиторий профессиональным и позволяет автоматически генерировать Changelog.
Задача:
— Сделать историю коммитов понятной с первого взгляда.
— Разделить исправления багов, новые фичи и изменения в документации.
Решение:
Структура сообщения выглядит так: тип(область): описание.
Основные типы:
— feat — новая функциональность (например, feat(auth): add google login).
— fix — исправление ошибки (fix(api): resolve timeout on large requests).
— docs — изменения в документации (docs(readme): add installation steps).
— style — правки оформления (пробелы, форматирование), которые не влияют на логику.
— refactor — правка кода, которая не добавляет фичу и не фиксит баг.
— chore — обновление зависимостей или настроек сборки.
— test — добавление или исправление тестов.
Почему это круто?
— Скорость — ты сразу видишь, что именно произошло в коде, не открывая сам коммит.
— Автоматизация — инструменты вроде Semantic Release могут сами поднимать версию проекта (v1.0.1 -> v1.1.0), опираясь на твои feat и fix.
— Порядок — это дисциплинирует не пихать в один коммит и новую фичу, и правку старого бага.
Совет: Если изменение «ломает» обратную совместимость (Breaking Change), в конце типа ставят восклицательный знак, например: feat(api)!: change response format.
🔥 — если уже пишешь коммиты по стандарту
🤝 — если «fix» — твое второе имя
➡️ GitHub Ready | #урок
Когда ты заглядываешь в git log через месяц, сообщения типа «fix», «updated» или «добавил кнопку» не говорят ни о чем. Чтобы история проекта была читаемой, разработчики придумали стандарт Conventional Commits. Это делает твой репозиторий профессиональным и позволяет автоматически генерировать Changelog.
Задача:
— Сделать историю коммитов понятной с первого взгляда.
— Разделить исправления багов, новые фичи и изменения в документации.
Решение:
Структура сообщения выглядит так: тип(область): описание.
Основные типы:
— feat — новая функциональность (например, feat(auth): add google login).
— fix — исправление ошибки (fix(api): resolve timeout on large requests).
— docs — изменения в документации (docs(readme): add installation steps).
— style — правки оформления (пробелы, форматирование), которые не влияют на логику.
— refactor — правка кода, которая не добавляет фичу и не фиксит баг.
— chore — обновление зависимостей или настроек сборки.
— test — добавление или исправление тестов.
Почему это круто?
— Скорость — ты сразу видишь, что именно произошло в коде, не открывая сам коммит.
— Автоматизация — инструменты вроде Semantic Release могут сами поднимать версию проекта (v1.0.1 -> v1.1.0), опираясь на твои feat и fix.
— Порядок — это дисциплинирует не пихать в один коммит и новую фичу, и правку старого бага.
Совет: Если изменение «ломает» обратную совместимость (Breaking Change), в конце типа ставят восклицательный знак, например: feat(api)!: change response format.
🔥 — если уже пишешь коммиты по стандарту
🤝 — если «fix» — твое второе имя
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝6🔥3
В репозитории Python-Robotics лежит большой набор различных алгоритмов для робототехники, написанных на языке Python.👉 Основное внимание уделяется автономной навигации, а цель — помочь новичкам в робототехнике понять основные идеи, лежащие в основе каждого алгоритма.
Клик
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🪝 Git Hooks: как заставить проект проверять самого себя?
Представь: ты в спешке сделал коммит, забыл прогнать тесты или оставил в коде console.log. Всё это улетает в репозиторий, ломает сборку у коллег или просто засоряет проект. Git Hooks (хуки) — это скрипты, которые автоматически запускаются при определенных действиях (коммит, пуш, мерж) и могут отменить операцию, если что-то не так.
Задача:
— Автоматически проверять код на ошибки (ESLint, Prettier) перед каждым коммитом.
— Запускать тесты только для измененных файлов.
— Запрещать пушить в ветку main напрямую.
Решение:
Хуки живут в папке .git/hooks, но их неудобно синхронизировать с командой. Поэтому в JS-мире чаще всего используют инструмент Husky.
Почему это спасает нервы?
— Чистый код — проект всегда отформатирован по единому стандарту, и никто не «забывает» запустить линтер.
— Стабильность — если тесты упали, коммит просто не создастся. Тебе придется сначала всё починить.
— Экономия времени на ревью — коллегам не нужно указывать тебе на лишние пробелы или пропущенные точки с запятой — хуки всё исправят за тебя.
Совет: Если тебе очень нужно сделать коммит прямо сейчас (например, ты сохраняешь черновик и точно знаешь, что тесты упадут), можно обойти хуки флагом –no-verify: git commit -m “wip” –no-verify. Но используй это только в крайних случаях!
🔥 — если в твоих проектах всегда стоят хуки
🤝 — если узнал о них только что, но уже хочешь внедрить
➡️ GitHub Ready | #урок
Представь: ты в спешке сделал коммит, забыл прогнать тесты или оставил в коде console.log. Всё это улетает в репозиторий, ломает сборку у коллег или просто засоряет проект. Git Hooks (хуки) — это скрипты, которые автоматически запускаются при определенных действиях (коммит, пуш, мерж) и могут отменить операцию, если что-то не так.
Задача:
— Автоматически проверять код на ошибки (ESLint, Prettier) перед каждым коммитом.
— Запускать тесты только для измененных файлов.
— Запрещать пушить в ветку main напрямую.
Решение:
Хуки живут в папке .git/hooks, но их неудобно синхронизировать с командой. Поэтому в JS-мире чаще всего используют инструмент Husky.
# 1. Устанавливаем Husky
npx husky-init && npm install
# 2. Создаем хук пре-коммита (pre-commit)
# Теперь перед каждым 'git commit' будет запускаться проверка
npx husky add .husky/pre-commit "npm test"
# 3. Для продвинутых: используем lint-staged,
# чтобы проверять только те файлы, которые ты изменил, а не весь проект.Почему это спасает нервы?
— Чистый код — проект всегда отформатирован по единому стандарту, и никто не «забывает» запустить линтер.
— Стабильность — если тесты упали, коммит просто не создастся. Тебе придется сначала всё починить.
— Экономия времени на ревью — коллегам не нужно указывать тебе на лишние пробелы или пропущенные точки с запятой — хуки всё исправят за тебя.
Совет: Если тебе очень нужно сделать коммит прямо сейчас (например, ты сохраняешь черновик и точно знаешь, что тесты упадут), можно обойти хуки флагом –no-verify: git commit -m “wip” –no-verify. Но используй это только в крайних случаях!
🔥 — если в твоих проектах всегда стоят хуки
🤝 — если узнал о них только что, но уже хочешь внедрить
Please open Telegram to view this post
VIEW IN TELEGRAM
😁2🤝1
Настроил чат-бота за пару часов → заработал 9 000₽.
Просто представь, кто-то стоит в очереди на маршрутку в 8 утра чтобы успеть на “любимую” работу.
А кто-то за 3-4 часа делает чат-бота со своего ноута без привязки ко времени.
Разница в зарплате: 200 тысяч.
И нет — не надо ничего программировать.
Зачем грузить мозги кодом, если можно собрать чат-бота для бизнеса на конструкторе.
Без опыта. За 3-4 часа.
💡 Суть проста:
Берёшь клиента → Собираешь бота по шаблону → Наставник всё проверяет → Сдаёшь работу и получаешь деньги.
В первый месяц обычно выходят на доход 50–80 тыс ₽/мес, а с опытом от 180 тыс ₽ и выше. Легко совмещается с работой, учёбой, рыбалкой, семейными хлопотами… график устанавливаешь самостоятельно.
Всё, что нужно для старта — запустить бота
👉 @other_digital_bot
Там пошаговый план как стартануть и гайд по клиентам.
До 6 апреля вход бесплатный.
Просто представь, кто-то стоит в очереди на маршрутку в 8 утра чтобы успеть на “любимую” работу.
А кто-то за 3-4 часа делает чат-бота со своего ноута без привязки ко времени.
Разница в зарплате: 200 тысяч.
И нет — не надо ничего программировать.
Зачем грузить мозги кодом, если можно собрать чат-бота для бизнеса на конструкторе.
Без опыта. За 3-4 часа.
💡 Суть проста:
Берёшь клиента → Собираешь бота по шаблону → Наставник всё проверяет → Сдаёшь работу и получаешь деньги.
В первый месяц обычно выходят на доход 50–80 тыс ₽/мес, а с опытом от 180 тыс ₽ и выше. Легко совмещается с работой, учёбой, рыбалкой, семейными хлопотами… график устанавливаешь самостоятельно.
Всё, что нужно для старта — запустить бота
👉 @other_digital_bot
Там пошаговый план как стартануть и гайд по клиентам.
До 6 апреля вход бесплатный.
🔥1
goose
С AI в разработке на более сложных задачах часто приходится несколько раз гонять диалог туда-сюда: править код, дебажить, деплоить. И на каждом шаге нужно следить за процессом. Когда есть время, норм, а когда завал, это становится довольно геморно.
Недавно наткнулся на Goose, open source AI-проект, который уже набрал 31000+ звезд и может полностью автоматически закрывать сложные инженерные задачи.
Ключевая фишка здесь в автономности: достаточно дать инструкцию, и Goose сам проходит весь пайплайн от отладки кода и разработки фич до финального деплоя.
При этом Goose может целиком работать локально, поддерживает подключение любого LLM и протокол MCP, что дает приватность данных и высокую расширяемость.
Есть готовые установочные пакеты: скачиваешь с сайта или со страницы Releases, настраиваешь API Key провайдера модели и можно пользоваться.
Уже немало инженеров применяют его в реальных проектах. Если хочется разгрузиться от рутины и повторяющихся задач, это AI-инструмент, который стоит попробовать.
Cсылка на GitHub
➡️ GitHub Ready | #урок
С AI в разработке на более сложных задачах часто приходится несколько раз гонять диалог туда-сюда: править код, дебажить, деплоить. И на каждом шаге нужно следить за процессом. Когда есть время, норм, а когда завал, это становится довольно геморно.
Недавно наткнулся на Goose, open source AI-проект, который уже набрал 31000+ звезд и может полностью автоматически закрывать сложные инженерные задачи.
Ключевая фишка здесь в автономности: достаточно дать инструкцию, и Goose сам проходит весь пайплайн от отладки кода и разработки фич до финального деплоя.
При этом Goose может целиком работать локально, поддерживает подключение любого LLM и протокол MCP, что дает приватность данных и высокую расширяемость.
Есть готовые установочные пакеты: скачиваешь с сайта или со страницы Releases, настраиваешь API Key провайдера модели и можно пользоваться.
Уже немало инженеров применяют его в реальных проектах. Если хочется разгрузиться от рутины и повторяющихся задач, это AI-инструмент, который стоит попробовать.
Cсылка на GitHub
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
Этот инструмент фиксирует:⚫️ время работы над проектом;⚫️ времязатратность на определённые задачи;⚫️ какими ЯП чаще пользуетесь.👉 Совместим с популярными редакторами кода, удобен в использовании, собирает понятные графики и диаграммы.
Клик
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
Платить за дорогие курсы уже не обязательно
Пока одни отдают сотни тысяч за курсы, другие ту же информацию получают почти даром
В канале Slivbox собраны 60.000+ слитых курсов по всем направлениям:
— Программирование и IT
— Дизайн, монтаж, 3D-графика
— SMM, маркетинг, копирайтинг
— Иностранные языки
— Бизнес, инвестиции, трейдинг
— Подготовка к ЕГЭ и экзаменам
— Саморазвитие, психология
Доступ без ограничений — один раз оформляете и можете изучать любые материалы из каталога без лимитов по времени, просмотрам и загрузкам.
Забирай скорей, доступ будет открыт на 2 часа 👇
https://t.me/+t2Wwq-YOUS9jMmZi
Пока одни отдают сотни тысяч за курсы, другие ту же информацию получают почти даром
В канале Slivbox собраны 60.000+ слитых курсов по всем направлениям:
— Программирование и IT
— Дизайн, монтаж, 3D-графика
— SMM, маркетинг, копирайтинг
— Иностранные языки
— Бизнес, инвестиции, трейдинг
— Подготовка к ЕГЭ и экзаменам
— Саморазвитие, психология
Доступ без ограничений — один раз оформляете и можете изучать любые материалы из каталога без лимитов по времени, просмотрам и загрузкам.
Забирай скорей, доступ будет открыт на 2 часа 👇
https://t.me/+t2Wwq-YOUS9jMmZi
👎2
transcribee
Когда натыкаюсь на полезные видео на YouTube или TikTok и хочу разобрать контент в текстовые заметки, чтобы потом гонять это через AI, вручную конспектировать слишком выматывает. А существующие инструменты обычно требуют по одному экспортировать и раскладывать все руками, что жутко неудобно.
Можно попробовать вот это: transcribee, open-source тулза, которая одной командой превращает видео или аудио в текст и автоматически раскладывает все по базе знаний.
Поддерживает ссылки на YouTube, Instagram и TikTok, а также умеет обрабатывать локальные аудио- и видеофайлы. После транскриба она автоматически определяет разных спикеров и использует Claude, чтобы проанализировать темы и разнести материалы по соответствующим папкам.
Например, если прогнать пачку видео про AI-исследования, интервью со стартапами и health-образование, инструмент сам создаст под Documents категории вроде AI-Research, Startups и Health, а для каждого видео сделает отдельную директорию, где будут храниться текст транскриба и метаданные.
Сгенерированный текст уже размечен по спикерам, так что его можно сразу копипастить в ChatGPT или Claude и задавать вопросы.
Если ты часто смотришь обучающие видео или собираешь материалы и хочешь превращать это в поисковую базу знаний с Q&A, эту тулзу точно стоит попробовать.
Cсылка на GitHub
➡️ GitHub Ready | #урок
Когда натыкаюсь на полезные видео на YouTube или TikTok и хочу разобрать контент в текстовые заметки, чтобы потом гонять это через AI, вручную конспектировать слишком выматывает. А существующие инструменты обычно требуют по одному экспортировать и раскладывать все руками, что жутко неудобно.
Можно попробовать вот это: transcribee, open-source тулза, которая одной командой превращает видео или аудио в текст и автоматически раскладывает все по базе знаний.
Поддерживает ссылки на YouTube, Instagram и TikTok, а также умеет обрабатывать локальные аудио- и видеофайлы. После транскриба она автоматически определяет разных спикеров и использует Claude, чтобы проанализировать темы и разнести материалы по соответствующим папкам.
Например, если прогнать пачку видео про AI-исследования, интервью со стартапами и health-образование, инструмент сам создаст под Documents категории вроде AI-Research, Startups и Health, а для каждого видео сделает отдельную директорию, где будут храниться текст транскриба и метаданные.
Сгенерированный текст уже размечен по спикерам, так что его можно сразу копипастить в ChatGPT или Claude и задавать вопросы.
Если ты часто смотришь обучающие видео или собираешь материалы и хочешь превращать это в поисковую базу знаний с Q&A, эту тулзу точно стоит попробовать.
Cсылка на GitHub
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
claude-usage-bar
Это инструмент для отображения текущего использования лимитов Claude в строке состояния.
Он показывает количество использованных токенов, оставшийся бюджет, скорость расхода и время до истощения ресурсов в реальном времени.
Интегрируется с tmux и zsh, позволяя отображать информацию непосредственно в статусной строке или командной строке.
Обновления происходят автоматически, обеспечивая актуальность данных без необходимости ручного вмешательства.
Cсылка на GitHub
➡️ GitHub Ready | #урок
Это инструмент для отображения текущего использования лимитов Claude в строке состояния.
Он показывает количество использованных токенов, оставшийся бюджет, скорость расхода и время до истощения ресурсов в реальном времени.
Интегрируется с tmux и zsh, позволяя отображать информацию непосредственно в статусной строке или командной строке.
Обновления происходят автоматически, обеспечивая актуальность данных без необходимости ручного вмешательства.
Cсылка на GitHub
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Process Compose — простой, но гибкий планировщик и оркестратор для управления неконтейнерными приложениями.👉 Его цель — упростить оркестрацию процессов без сложностей, связанных с контейнерами. Например, не нужно иметь дело с Docker-файлами, определениями томов, сетями и Docker-реестрами.
Клик
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🔥2
CPA-Dashboard
Руки чешутся: накупил кучу аккаунтов Gemini, Claude или Antigravity, повесил их на CLIProxyAPI и гоняю сервис.
Самое больное: непонятно, какой аккаунт уже отвалился, и сколько у кого осталось квоты. Каждый раз лезть в логи и выискивать это вручную, дико неэффективно.
Случайно наткнулся на проект CPA-Dashboard. Это визуальная панель управления, заточенная специально под CLIProxyAPI: вместо холодного CLI получаешь понятный веб-интерфейс.
Что умеет:
- В вебе прямо включать/выключать сервисы
- В реальном времени смотреть runtime-логи
- Самое полезное: пачкой обновлять квоты аккаунтов, автоматически детектить и помечать протухшие аккаунты, которым нужен повторный логин
- Есть интеграция OAuth-флоу: чтобы добавить новый аккаунт, не надо в терминале набивать сложные команды, пару кликов и готово
Есть one-click скрипты запуска для Windows, macOS и Linux: они сами поднимут Python-окружение, поставят зависимости и подхватят существующий конфиг, так что можно сразу стартовать.
Если ты на CLIProxyAPI строишь свой AI API-сервис, эта панель реально экономит кучу времени на поддержке, стоит задеплоить.
Cсылка на GitHub
➡️ GitHub Ready | #урок
Руки чешутся: накупил кучу аккаунтов Gemini, Claude или Antigravity, повесил их на CLIProxyAPI и гоняю сервис.
Самое больное: непонятно, какой аккаунт уже отвалился, и сколько у кого осталось квоты. Каждый раз лезть в логи и выискивать это вручную, дико неэффективно.
Случайно наткнулся на проект CPA-Dashboard. Это визуальная панель управления, заточенная специально под CLIProxyAPI: вместо холодного CLI получаешь понятный веб-интерфейс.
Что умеет:
- В вебе прямо включать/выключать сервисы
- В реальном времени смотреть runtime-логи
- Самое полезное: пачкой обновлять квоты аккаунтов, автоматически детектить и помечать протухшие аккаунты, которым нужен повторный логин
- Есть интеграция OAuth-флоу: чтобы добавить новый аккаунт, не надо в терминале набивать сложные команды, пару кликов и готово
Есть one-click скрипты запуска для Windows, macOS и Linux: они сами поднимут Python-окружение, поставят зависимости и подхватят существующий конфиг, так что можно сразу стартовать.
Если ты на CLIProxyAPI строишь свой AI API-сервис, эта панель реально экономит кучу времени на поддержке, стоит задеплоить.
Cсылка на GitHub
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Media is too big
VIEW IN TELEGRAM
Порт Doom (1993), который запускается внутри PDF-файла.
DoomPDF — это библиотека Python, которая позволяет конвертировать HTML-документы в PDF с помощью Chromium. Она проста в использовании, поддерживает стили CSS и отлично справляется с задачей создания профессиональных PDF.
Вы можете предположить, что файлы PDF состоят только из статических документов, но, как ни удивительно, формат PDF поддерживает Javascript со своей собственной стандартной библиотекой. Современные браузеры (Chromium, Firefox) реализуют эту возможность в рамках своих PDF-движков. Однако API, доступные в браузерах, значительно более ограничены.
Пример использования:
https://github.com/ading2210/doompdf
Demo https://doompdf.pages.dev/doom.pdf
➡️ GitHub Ready | #урок
DoomPDF — это библиотека Python, которая позволяет конвертировать HTML-документы в PDF с помощью Chromium. Она проста в использовании, поддерживает стили CSS и отлично справляется с задачей создания профессиональных PDF.
Вы можете предположить, что файлы PDF состоят только из статических документов, но, как ни удивительно, формат PDF поддерживает Javascript со своей собственной стандартной библиотекой. Современные браузеры (Chromium, Firefox) реализуют эту возможность в рамках своих PDF-движков. Однако API, доступные в браузерах, значительно более ограничены.
Пример использования:
from doompdf import make_pdf
make_pdf(
input_html="example.html",
output_pdf="output.pdf"
)
https://github.com/ading2210/doompdf
Demo https://doompdf.pages.dev/doom.pdf
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤1
GOverlay — инструмент с открытым исходным кодом, целью которого является создание графического пользовательского интерфейса для управления оверлеями Linux.👉 Это свежий проект, который находится на стадии активной разработки, поэтому новые функции в него добавляются постепенно. Но тестить уже можно.
Клик
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3