Я думал, что достиг желанного. Один из моих open-source проектов начал набирать небольшую аудиторию фолловеров на GitHub. Больше никакой нытливой неуверенности в себе, ведь около тысячи наблюдателей за звёздами следят за моим проектом — это всё, что нужно для подтверждения ценности. Это то, что можно вспоминать в моменты неуверенности. Напоминание, что я действительно достиг того, чего стою на самом деле. Никогда не думал, что звёзды могут отвернуться от меня.

* * *

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

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

Какое-то время я хотел убрать комментарии из своего блога; в основном, потому что здесь вообще мало комментариев, да и не хочется возиться с лишними «тормозами» от Disqus. Посмотрев на время загрузки Disqus, я был потрясён тем, что приходится терпеть посетителям сайта по моей вине (кроме тех, кто использует блокировщики вроде Privacy Badger и uBlock Origin.

Эта статья заточена под Hugo, но код легко адаптируется для любого сайта.

Что не так с Disqus?

Вот как выглядит типичный журнал запросов с включенным Disqus.

А вот лог после отключения Disqus.

ЧЕГО!?

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

Итак, что дано:

• Есть большой репозиторий, содержащий множество папок. Каждая папка – это отдельный проект.

Что необходимо сделать:

• Одну из папок перенести в отдельный репозиторий с сохранением ее истории коммитов.

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

Я использовал стандартный гитовый filter-branch. За основу я взял следующие статьи:

• Moving Files from one Git Repository to Another, Preserving History
• Splitting a subfolder out into a new repository

В этом посте я хочу немного адаптировать процесс для лучшего восприятия.

Github это незаменимый инструмент, прочно вошедший в жизнь практически каждого разработчика.

Хотя многие из нас используют его постоянно, не все знают, что существует большое количество сторонних (и бесплатных) сервисов и инструментов, которые тесно интегрированы с github и расширяют его функциональность.

В данной статье мы уделим внимание, в основном, инструментам, работающим в инфраструктуре npm. Полный список сервисов, интегрирующихся с github, можно посмотреть на странице github integrations directory.

Сегодня в выпуске:

• Настраиваем continuous integration c travis ci
• Настраиваем отчеты о test coverage с coveralls
• Мониторим статус зависимостей с david
• Настраиваем автоматическое обновление зависимостей с greenkeeper
• Улучшаем сообщения коммитов с commitizen
• Генерируем changelog и release notes с conventional-changelog
• Управляем задачами с zube

1 марта произошло очень важное событие, которое прошло почти незамеченным, несмотря на свою значимость. Github обновил terms-of-service, в которых появилось несколько пунктов, которые ставят под угрозу все репозитории под GPL, CC-*-SA и другими лицензиями.

Скорее всего, если вас привлекло название статьи, то вы начинаете свой путь знакомства с системой контроля версий Git. В данной статье я приведу 10+ видео о пошаговом вхождении в контроль версии используя Git. Данного курса будет вполне чем достаточно для работы с такими популярными сервисами как GitHub и Bitbucket.

Однажды мой знакомый, который только начинал свой путь в ИТ кинул мне данный мемчик что слева, с вопросом "А чем плохо то?", поэтому чтобы понимать данную шутку и уметь работать с самым популярным на сегодня VCS (Version Control System) рекомендую к ознакомлению серии видеоуроков, которую я привел ниже.

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

[Пятничное]

Всегда хотел сделать свой график активности пользовательского профиля на Гитхабе. Например, выкладывать коммиты каждый день так, чтобы через год этот график превратился в какую-нибудь картинку, пусть и с ограничением по размерам в 52×7 квадратиков-пикселей (52 недели в году × 7 дней в неделе).

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

У Git есть строгие обязательства по обратной совместимости: многие продвинутые возможности скрыты за разнообразными опциями, а не применяются как поведение по умолчанию. К счастью, Git также поддерживает и алиасы, так что вы можете создавать свои собственные команды, которые делают всю характерную для Git магию. Под катом — подборка полезных (или как минимум забавных) алиасов, определённых в моём .gitconfig.

«В следующие два года нужно не пытаться изобразить из себя что-то особенное, а просто быть достаточно умным, чтобы компоновать то, что человечество уже создало» (с) bobuk

Год назад на внутреннем хакатоне наши ростовские ребята за ночь скрестили визуальный текстовый редактор, «Типограф Муравьева» и антиплагиат-сервис. Получилась штука, которая помогала быстро подготовить и отправить публикацию в блог.

Одно время штука жила как сайд-проект, затем нам дали немного ресурсов — ну, как внутреннему стартапу. В итоге получилось удобное коллективное медиа без редакции.


Старик Гутенберг был бы доволен

Оно позволяет людям читать занятные истории, как дядька-водолаз 40 лет поднимает затонувшие корабли в Баренцевом море, а писателям на популярные нетехнические темы — немного зарабатывать на текстах.

Давайте посмотрим, что учитывать при разработке подобного сервиса, и что выбрать, чтобы без костылей.

TL;DR: github.com/limonte/dear-habr

Уважаемая администрация ТМ, вы сделали и поддерживаете лучший русскоязычный IT-блог. Вы отлично справляетесь со своей задачей, но я верю, что пришло время сделать шаг вперёд и стать чуточку ближе к своим пользователям.



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

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

Восполняя этот пробел, хочу ответственно заявить:

Хабр, ты лучший по функционалу и UI не только в рунете, ты — абсолютный чемпион. И пусть меня кто-нибудь поправит в комментариях, приведя IT-блог на любом языке, который удобнее Хабра.

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

Эссе концентрируется на структуре графа, на которой основан Git, и на том, как свойства этого графа определяют поведение Git. Изучая основы, вы строите своё представление на достоверной информации, а не на гипотезах, полученных из экспериментов с API. Правильная модель позволит вам лучше понять, что сделал Git, что он делает и что он собирается сделать.

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

После прочтения для ещё более глубокого погружения можно обратиться к обильно комментируемому исходному коду моей реализации Git на JavaScript.

[Прошедшему Году литературы посвящается]

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

Для пытливых разработчиков до сих пор остается актуальным вопрос использования табуляции и пробелов для форматирования кода. Могут ли они быть взаимозаменяемы: например, 2 пробела на табуляцию или 4? Но единого стандарта нет, поэтому иногда между разработчиками возникает непонимание. Кроме того, различные IDE и их компиляторы обрабатывают табуляцию также по-своему.

Решением вопроса обычно становится соглашение о правилах форматирования в рамках проекта или языка программирования в целом.

Команда разработчиков из Google исследовала проекты в репозитории Github. Они проанализировали код, написанный на 14 языках программирования. Целью исследования было выявить соотношение табуляций и пробелов — то есть, наиболее популярный способ форматирования текста для каждого из языков.

Всем привет! Как я обещал в комментариях, заливаю на GitHub свои программы. Начну с DisType Pro. Репозиторий тут, но перед тем как писать о том, что я хочу сделать и в чем мне нужна помощь, расскажу об истории этой программы:


DisType pro.

Github — важная часть жизни современного разработчика: он стал стандартом для размещения opensource-проектов. В «2ГИС» мы используем гитхаб для разработки проектов web-отдела и хостинга проектов с открытым кодом.

Хотя большинство из нас пользуются сервисом практически каждый день, не все знают, что у него есть много фишек, помогающих облегчить работу или рутинные операции. Например, получение публичного ключа из URL; отслеживание того, с каких сайтов пользователи приходят в репозиторий; правильный шаринг ссылок на файлы, которые живут в репозиториях гитхаба; горячие клавиши и тому подобное. Цель этой статьи — рассказать о неочевидных вещах и вообще о том, что сделает вашу работу с гитхабом продуктивнее и веселее (я не буду рассматривать здесь работу с API гитхаба, так как эта тема заслуживает отдельной статьи).

Содержание

• Трюки с URL
• Горячие клавиши
• Тикеты и пулл-реквесты
• Github markdown
• Аккаунт
• Работа с репозиториями
• Поиск кода
• Командная строка и Github
• User scripts
• Github-вандализм
• Дополнительные Github-ресурсы
• Полезные ссылки

В числе самых обсуждаемых последних новостей в сообществе разработчиков были новые тарифы GitHub (см., например, здесь).

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

Некоторые прибегают к альтернативному решению и разворачивают GitLab (или другой git-сервис) на собственном или арендованном сервере.

Но и у этого решения есть свои подводные камни: GitLab очень требователен к системным ресурсам. Для частных лиц гораздо проще платить 7 долларов в месяц за GitHub, чем арендовать сервер надлежащей конфигурации.

Из сказанного, однако, не следует, что у GitHub на сегодняшний день альтернативы нет. Об одном весьма интересном и перспективном решении мы хотели бы рассказать в этой статье. Знакомьтесь: Gogs. Этот инструмент будет интересен как для индивидуальных разработчиков, так и для небольших компаний.

Теперь платить нужно за число пользователей, а не приватные репозитории

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

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

В далёком 2012 на Хабре обсуждались «рестриктеры», «делитеры», «цензурасты», а также «абузо-устойчивые» провайдеры в статье про то, что был предложен новый HTTP-статус для цензуры, а точнее для ресурсов, доступ к которым ограничен из-за проблем с законом.

Собственно статус HTTP 451 был предложен Тимом Брэйем из Google, а виновником (в прямом и переносном смысле) переполоха стал в очередной раз заблокированный, заабузенный, зацензуренный и великий The Pirate Bay.

Почему это важно? Потому что вы, наверное, как и я, пользуетесь GitHub, программируете не только для души и, возможно, владеете доходными интернет-ресурсами.

Вы уже находитесь в правовом поле авторского права.

Вчера, 17 февраля, команда разработчиков Github анонсировала новый функционал, которого пользователям, участвующим в групповой разработке, могло серьезно недоставать: теперь в GitHub есть шаблоны для Issue и Pull-реквестов.