GitHub *

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

Хочу поделиться своими мыслями и опытом («сыном ошибок трудных») в организации своей базы знаний, регулярно приобретаемых после прочтения разных книг, статей, просмотра видосов, прохождения курсов и прочих самообразовательных активностей.

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

Первый раз столкнулись с Git и не понимаете, что это такое?

Устали бездумно выполнять серию комманд чтобы закинуть свой проект на GitHub?

Хотите понять, чем отличается merge, rebase, push и pull?

Надоело видеть ошибку о non fast-forward merge и не понимать, что с этим делать?

Сейчас попробуем разобраться в этом всем.

Привет! Я всегда мечтала, чтобы в инструментах для работы с командной строкой заранее сообщалось, насколько популярны те или иные конфигурационные опции, предусмотренные в них, например:

o    «В принципе, никто этим не пользуется»

o    «Этой опцией пользуется 80% аудитории, стоит ознакомиться»

o    «У этой опции предусмотрено 6 возможных значений, но в реальной практике применяется всего 2 из них».

Так что я решила спросить пользователей Mastodon, какие у них любимые опции конфигурации git:

А какие опции git config вы больше всего любите выставлять? В настоящее время у меня в ~/.gitconfig установлены только git config push.autosetupremote true и git config init.defaultBranch main, вот интересуюсь, а что выставляют другие люди.

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

Далее перечислю их по порядку, при этом (очень примерно) попытаюсь начать с наиболее популярных.

Все описанные опции документированы на странице man git-config, а также на этой странице.

Автор оригинала Скотт Чакон — сооснователь GitHub и основатель нового клиента GitButler. Этот клиент ставит во главу угла рабочий процесс и удобство разработки, в том числе код-ревью, и не является просто очередной обёрткой над CLI git.

Вам хочется использовать ванильный Git, чтобы управлять репозиторием с объёмом 300 ГБ в 3,5 млн файлов, которые без проблем получают пуш каждые 20 секунд от 4000 разработчиков? Тогда читайте дальше!

Вот агенда блога — наша блогенда:

• Предварительное извлечение.
• Граф коммитов.
• Монитор файловой системы.
• Частичное клонирование.
• Разреженный checkout.
• Scalar.

Сегодня всё чаще требуется учитывать географическую привязку и выполнять поиск в локальном окружении клиента. Иными словами, регулярно возникает необходимость найти что-то (или кого-то) рядом с конкретным пользователем. «Где ближайший банкомат?», «Кто из друзей поблизости?», «Какие тут аптеки?». Подобные запросы миллионами поступают в сервисы геолокации каждый день, при этом существующие подходы к решению этой задачи не исчерпали возможностей оптимизации. Наверняка вы не раз сетовали на то, как долго обновляются метки на карте.

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

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

Координаты одной строкой

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

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

Предисловие

Простой python-cкрипт для парсинга спортивной статистики по баскетболу с популярного сайта

Как-то я столкнулся с довольно тривиальной, но новой для себя задачей - оптического распознавания символов (OCR). Так сложилось, что готовые инструменты (типа tesseract-ocr) мне не подошли, поэтому пришлось изобретать велосипед. Но к этому процессу я решил подойти со всей отвественностью: проверить несколько подходов, определить их примущества, недостатки и выбрать наиболее подходящий для конкретной задачи. По итогу это мини-исследование вылилось в данную обзорную статью. Здесь я хочу привести примеры нейросетевых моделей, характерных для различных этапов становления области компьютерного зрения (далее - CV) в том виде, в котором мы его знаем сейчас.

Привет, Хабр! На связи технический директор MTC RED Денис Макрушин и команда Advanced Research Team: Павел Гусь, Иван Бессарабов и Андрей Сомсиков.

В январе разработчики GitLab нашли в своей системе две критические уязвимости. Из-за ошибок в верификации злоумышленники могут захватывать учётки пользователей и менять содержимое репозиториев. Такой тип атак называется RepoJacking. Мы изучили другой хостинг кода — GitHub — и нашли 1 300 потенциально уязвимых открытых репозиториев. Чем это опасно для разработчиков и их проектов — под катом.

Когда-то давно меня попросили разработать модель динамики полета АСП (авиационного средства поражения) в отечественном ПО, в среде SimInTech, причем разработать не с нуля, а тупо повторив уже созданную ранее модель в Матлабе (с Симулинком), и любезно выложенную в публичный доступ на гитхабе.

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

Всем привет! Этой мой первый пост на Habr (да и вообще где либо, за исключением GitHub). Хочу поделиться работой, на реализацию который у меня ушло около месяца, но тем не менее сейчас используя ежедневно и планирую развивать в дальнейшем. Задумка была таковой, что бы донести любой (бесплатный) контент до телевизора используя под рукой только телефон, например, если я еду в метро или нет желания (вставать с дивана) и возможности подойти к компьютеру. На самом деле причина реализации сей творения чуть глубже и проще, под управление я передал дело подбора контента на повседневный вечер супруге. За источник контента отвечает трекер Кинозал, который, к слову, я использую уже 4 года и меня он устраивает во всем.

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

«Какого же размера он должен быть? Бывает ли идеальный размер? Если бы теоретически можно было полностью его контролировать, то насколько большим его нужно делать?»

Вы гуглите, находите множество ресурсов, сайтов и статей наподобие этой, которые анализируют тему и делают примерно такой вывод:

«Слишком маленькое количество строк может не отображать полностью изменения, а чрезмерно большой PR может утомить проверяющих, что усложнит выявление проблем или написание осмысленного отзыва»

И хотя вы понимаете логику автора, в то же время осознаёте, то теоретический ответ может быть лишь смутным, что «серебряной пули» не существует. Как всегда, в жизни всё сложнее.

Однако моя статья будет немного о другом:

«Мы проанализируем PR примерно 30 тысяч разработчиков, чтобы проверить, как размер PR коррелирует с временем внедрения, полученными комментариями и отказами во внесении изменений, чтобы найти статистически наилучший размер и понять, что на него влияет.»

Пояснение: тем, кто экспериментирует с данными, особенно после прохождения курсов/обучения в сфере данных, приведённое выше может напомнить о фразе «Корреляция не означает причинно-следственной связи». Да, они будут абсолютно правы. Мы попытаемся рассмотреть под разными углами, как эта корреляция варьируется в зависимости от компании, разработчика и общего объёма коммитов кода, а также под другими углами, которые могут помочь нам понять, какие другие значения могут по каким-то причинам отвечать соответствующим паттернам. Однако это «всего лишь» числа и корреляции, они не объясняют своих причин, поэтому любые наши предположения о причинах, скорее, субъективны и не подтверждены научными исследованиями.

Сегодня мы затронем сторону, отличную от написания кода. Мы займемся оформлением и написанием документации, как правильно делать коммиты и как оформлять код.

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

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

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

Недавно в своих ежедневных чтениях я наткнулся на явление, о котором думал уже много лет: феномен утечки информации людей, использующих SSH. Этот тип утечки информации не является новым явлением. Я давно предупреждал об этой опасности своих друзей, использующих SSH, но мой голос услышали лишь несколько человек. Поэтому я решил дать пояснения по этому поводу, потому что я считаю, что необходимо понимать этот риск в ИТ-сообществе, особенно в нынешней ситуации. Я буду исходить из предположения, что у вас, дорогой читатель, есть опыт работы с SSH.

Как настроить GitHub Actions и не заплакать: пошаговая инструкция

Привет всем! Меня зовут Виталий, я фронтендер в Mish. Решил недавно освоить полноценный автоматический деплой проекта, чтобы все работало само. Расскажу и вам, что из этого получилось.

В статье буду разговаривать о деплое только фронтенда. Про деплой бэкенда расскажу в следующем материале.

Специалист отдела перспективных исследований компании «Криптонит» Игорь Нетай изучил процесс потери точности вычислений и написал библиотеку, доступную на GitHub, которая помогает разработчикам контролировать точность расчётов на каждом этапе вычислений. Данная библиотека особенно актуальна в сфере машинного обучения и анализа (больших) данных, где накопление ошибок может сильно искажать результат.

Работаю я в бюрократизированной конторе с плохими процессами. Текучка тут достаточно большая. Люди приходят и уходят. Менеджмент на уровне дна. В какой-то момент в команду докинули нового разработчика (с неясными целями и задачами). Ну вроде парень умный, вроде что-то делает, вроде не просто так.

Спустя четыре месяца (испытательный закончился) у многих закрались подозрения, что на самом деле парень ничего не делает. Но как доказать это со стороны объективно? Решили посмотреть историю коммитов. Оказалось, он почти не коммитил (последний месяц вообще перестал), а на совещаниях ссал в уши ездил по ушам. Парень продолжил работать на прошлой работе и был преподом на курсах. Такой вот overemployed, с двумя зарплатами по ставке синьора.

Ему предложили перевестись в другой отдел. Менеджеру все сошло с рук. Часть разрабов сидела с лицами «‎а что так можно было?»‎. А я понял, что нельзя так просто взять и посмотреть статистику коммитов.

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

У нас в ИТ-команде Сравни есть принцип: в любой непонятной ситуации вместо того, чтобы раз за разом решать похожие проблемы, лучше сделать инструмент, который поможет системно решать целый класс таких задач. Шаблонизация, автоматизация занимают важное место у нас в бэклогах. Поэтому эксперименты с Copilot от GitHub и OpenAI, наверное, были для нас неизбежны.

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

В этой статье я расскажу о том, как и зачем подписывать и верифицировать коммиты в git при помощи gpg.