GitHub *

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

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

Статья для разработчиков, которые устали от сложностей Git и хотят навести порядок в своих проектах. Я расскажу про Jujutsu (jj) — современную альтернативу, которая меняет подход к контролю версий. Без веток, без stash, без мучительных rebase -i — только чистая история и удобный workflow, который позволит вам фокусироваться на написании кода, а не на борьбе с системой. Готовые примеры и наглядная демонстрация возможностей внутри.

Политика найма в большинстве компаний оставляет желать лучшего. Они просто тратят своё и наше время (я как-то проходил собеседование из 9 этапов!). Они охотятся на передовых программистов и при этом даже не могут отличить реальных людей от LLM. Короче, в манибол они явно не играют.

Для соискателей картина тоже выглядит тоскливо. Некоторые из лучших знакомых мне программистов (среди которых мейнтейнеры компилятора Rust) не могут найти работу, так как теряются под воздействием стрессовых факторов собеседования. Одному такому человеку, который уже более 4 лет работает с Haskell и более 2 лет — с Rust, рекрутёр прямо сказал, что он «не технарь». Плюсом ко всему компании могут неделями, а порой и месяцами мурыжить людей, не давая понять, приняли их на работу или нет.

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

Зачем? — У меня и самой был запрос на такую программу. Программу с кучей «нестандартных» символов. Существующие решения не отвечали моим потребностям и тогда я решила создать своё, подходящее под мои хотелки: многоязычный ввод, ввод типографских, математических и даже алхимических символов. И теперь я надеюсь, что сие «изобретение» окажется полезным не только для меня.

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

В статье представлен обзор на DSL KeyPad и его основные фичи, благодаря которым вы сможете печатать с внушительным арсеналом символов, имея всего-то две языковые раскладки: русскую и английскую. Румынский? Немецкий? Или может быть Вьетнамский? Старославянский? Да легко — множество комбинаций и ряд фич позволит вам писать на куче языков. Да хоть Германские руны и Глаголицу печатать. Прилагаются и широкие возможности кастомизации под свои нужды.

А это примеры названий языков и систем, написанные с помощью моей программы:

Қазақ тілі, Хуэйзў йүян, Забони тоҷикӣ, Йағнобӣ зивок, Аԥсуа бызшәа, Авар мацӏ, Українська мова, Словѣньскъ ѩꙁꙑкъ, Црногорски језик, Ли́мба Рꙋмѫнѣскъ, Итәнмәӈин крвэԓхатас, Даһур Усүүэ, Эвэды̄ турэ̄н, Азәрбајҹанҹа, Башҡорт теле, Тэлэңгэт, Чӑваш чӗлхи…

Ænglisċ sprǣċe, Français, Tiếng Việt, Hànyǔ Pīnyīn, Norrœnt mál, Limba Română, Español, Język polski, Čeština, Bokmål, Tamaziɣt, Türkçe, Sää’mǩiõll…

git commit -m "WIP" — три слова, после которых начинается настоящий ад.

Доброго времени суток. Такая технология как Git в представлении не нуждается. Все знают add, commit, push — это как азбука. Но что делать, когда что‑то пошло не так? Ошибочный коммит прокатился по ветке? Надо срочно переключиться, но незавершенные правки мешают? Нужно перенести только одно исправление из другой ветки?

Знакомая ситауция? Тогда давайте разберем 5 команд, которые выходят за рамки базового workflow и реально спасают репутацию (и ваши нервные клетки).

Пользователи GitHub часто используют принудительные пуши (git push --force), чтобы переписать историю коммитов — например, когда случайно закоммитили секреты и хотят удалить их из репозитория. 

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

В статье покажу, как вычислял такие коммиты с помощью GitHub Archive и вытаскивал из них секреты, за которые мне выплатили $25 000 по багбаунти. А еще поделюсь open-source инструментом, который позволит вам самостоятельно искать подобные утечки.

Привет, Хабр!

Меня зовут Андрей. Я техник и системный админ. И хоть я незрячий, продолжаю разрабатывать инструменты для автоматизации, системного мониторинга и просто удобной жизни за компьютером. Этот пост — о моём первом публичном проекте, который я решил выложить на GitHub и рассказать о нём на Хабре.

Проект называется AutoCraft Bot. Это гибрид: Telegram-бот и десктопное приложение на Python. Он управляет компьютером, запускает плагины, делает скриншоты, работает с голосом, поддерживает REPL и Telegram API — и всё это в виде одного .exe

Сегодня расскажу, как построил систему, которая клонирует и сканирует тысячи публичных GitHub-репозиториев — и находит в них утекшие секреты.

В каждом репозитории я восстанавливал удаленные файлы, находил непривязанные («висячие») объекты, распаковывал .pack-файлы и находил API-ключи, активные токены и учетки. А когда сообщил компаниям об утечках, заработал более $64 000 на баг-баунти.

Как же меня бесят статьи в духе “Как всего за 139 рублей в месяц развернуть свой сайт-визитку на vps”. Какие 139 рублей за сайт-визитку, совсем уже стыд потеряли?!

В этой статье я вам пошагово расскажу и покажу как бесплатно разместить и вести ваш личный сайт (блог, cv, wiki). Вам даже отдельный домен не нужен (всё будет «из коробки»), хотя в последнем шагом мы и его прикрутим. От вас нужны будут базовые знания git и просто уметь работать с markdown.

8 лет назад я исправил опечатку в чужом репозитории, а сейчас регулярно делаю коммиты в проекты, которые использую, и даже вошел в core team библиотеки с 27000 звёзд на GitHub

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

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

Когда я впервые решил создать свой open-source проект, мне казалось, что главное – это хорошая идея и рабочий код. Я взялся за разработку библиотеки для сетевых клиентов и UI-компонентов, вложил в неё два года работы и, наконец, выложил на GitHub. Но вместо успеха меня ждал холодный душ – библиотека получила всего 10 звёздочек.

Тогда я осознал ключевую проблему open-source: одна только идея не работает. Если проект плохо оформлен – его никто не найдёт. Документация и описание –  не менее важны, чем сам код. В следующем проекте я учёл ошибки. Когда правильно оформил проект, он начал находить аудиторию, получать звёзды и фидбек от разработчиков.

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

Git стал стандартом де-факто в мире разработки программного обеспечения. Это мощная система контроля версий, которая позволяет командам эффективно сотрудничать, отслеживать изменения и управлять кодовой базой. Новичку Git может показаться сложным из-за обилия команд и концепций. Однако правда в том, что для выполнения 90% повседневных задач достаточно уверенно владеть небольшим набором ключевых команд.

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

В этой статье я делюсь реальным опытом продвижения Open Source проекта на GitHub за 2 года. Мы развенчаем мифы о быстром наборе звезд и узнаем из моего опыта, как я на самом деле привлекал трафик и продвигал проект Wunjo. Поговорим о том, что реально работает для увеличения видимости на GitHub и как маркетологи, разработчики пет-проектов и владельцы продуктов могут применить эти методы для продвижения.

Хабр, привет! Меня зовут Барилко Виталий, я разработчик / директор / главный идеолог программы Управление IT-отделом 8 и работаю в компании Софтонит. Мы разрабатываем ПО для автоматизации ИТ-отделов. Сегодня хочу поговорить про conventional commits и про свой личный опыт работы с коммитами. На самом деле это бездонная тема, о которую сломано много копий. Кто-то пишет и делает коммиты так, кто-то эдак. В посте попробую поразмышлять о том, как делать не надо и о придуманных на этот счет правилах и договоренностях.

Начинающие (а иногда этим грешат и опытные) разработчики, не до конца понимают принципы создания и работы над коммитами в git. Тут имеется ввиду не механика и команды типа “git commit …”, а общие и глобальные вещи. Например:

1. А когда делать коммиты?
2. Что в них писать?
3. Есть ли какие-то общие правила для их создания?
4. Как не надо коммитить?

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

Прошло два года...

Какие настройки git config сейчас следует устанавливать по умолчанию? Ниже рассмотрены избранные настройки, менять которые не стесняются даже разработчики самого Git.

Несколько недель назад я написал о настройке Git help.autocorrect и поведал странную историю о том, как её значение стали задавать в децисекундах.  

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

В этом посте я разберу некоторые (пожалуй, малопонятные) настройки Git, которые сам активировал во всех моих проектах. Я подробно расскажу о них, поясню, как они действуют, и почему их, пожалуй, стоит выставить по умолчанию.

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