Рубрика «гитхаб» - 2

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

image
Читать полностью »

Пару дней назад в репозиторий WebMConverter был сделан коммит, исправляющий слово retard (тормоз, тупица) в описании проекта. Ранее описание проекта было «WebM for Retards», что было изменено на «WebM for Gits». Владелец репозитория показал текст письма, который послал ему гитхаб:
image
Читать полностью »

Предлагаю использовать Tor для доступа к сайтам, к которым отсутствует прямой доступ.

image

Читать полностью »

На Гитхабе скоро появится продвинутый редактор кода. Никакого официального объявления об этом команда Гитхаба пока не сделала, однако уже опубликованы около семидесяти репозиториев, по которым можно примерно представить себе функционал будущего редактора. Официальный сайт редактора, atom.io, пока не содержит только заставку с одним словом: «Soon» («скоро»). В некоторых репозиториях есть и скриншоты будущего редактора:

Гитхаб скоро запустит текстовый редактор с богатым функционалом
Темная тема интерфейса
Читать полностью »

image

За несколько дней до наступления 2014 года Гитхаб успел перешагнуть отметку в 10 миллионов репозиториев. Причём больше половины из них — 5,5 миллиона — было создано в этом году. Гитхаб, несмотря на уже огромные размеры, продолжает расти экспоненциально. Если на создание первого миллиона репозиториев ушло три года и восемь с половиной месяцев, то последний миллион нарегистрировали за сорок восемь дней.
Читать полностью »

image

От команды Гитхаба всё чаще слышны высказывания о том, что совместная разработка ПО — далеко не единственный сценарий применения их сайта. Сооснователь и CEO Гитхаба Том Престон-Вернер заявил недавно: «Мы хотим, сделать Гитхаб настолько гибким и простым, чтобы им могли пользоваться юристы, чиновники, кто угодно… Сейчас мы постоянно обсуждаем со множеством людей то, как они используют Гитхаб, и как ещё его можно использовать».

Уже есть несколько примеров использования Гитхаба не для разработки софта, а для написания книг, законов, публикации наборов данных. А 15 октября на Гитхабе открылся раздел government.github.com, специально предназначенный для проектов, связанных с электронным правительством, открытыми данными, гражданскими инициативами и законотворчеством. Список государственных учреждений, общественных организаций, правительств и муниципалитетов, использующих Гитхаб, уже насчитывает десятки наименований.
Читать полностью »

Краткое предисловие переводчика.

Захватывающе интересная статья одного из разработчиков «GitHub Inc.» о принятом в компании рабочем процессе потребовала употребить пару специальных терминов при переводе.

То понятие, для которого на английском языке достаточно одного слóва «workflow», на русский приходится переводить словосочетанием — «рабочий процесс». Ничего лучше не знаю ни сам я, ни при помощи гуглоперевода — так что и мне, и читателям придётся с этим мириться, хотя бы и поневоле.

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

К сожалению, некоторые переводчики бывают склонны грубо убивать сочную метафору «иньекции» (или даже «впрыскивания», если угодно), содержающуюся в термине «code injection», так что и его также переводят словосочетанием «внедрение кода». Эта путаница огорчает меня, но ничего не могу поделать. Просто имейте в виду, что здесь «внедрением кода» я стану назвать внедрение его именно в производство (на продакшен), а не в чей-нибудь чужой код.

Я стремился употреблять словосочетание «в Гитхабе» в значении «в компании GitHub Inc.», а «на Гитхабе» — в значении «на сайте GitHub.com». Правда, иногда разделять их сложновато.

Проблемы git-flow

Повсюду путешествую, преподавая Git людям — и почти на каждом уроке и семинаре, недавно мною проведённом, меня спрашивали, что я думаю о git-flow. Я всегда отвечал, что думаю, что этот подход великолепен — он взял систему (Git), для которой могут существовать мириады возможных рабочих процессов, и задокументировал один проверенный и гибкий процесс, который для многих разработчиков годится при довольно простом употреблении. Подход этот также становится чем-то вроде стандарта, так что разработчики могут переходить от проекта к проекту и из компании в компанию, оставаясь знакомыми с этим стандартизированным рабочим процессом.

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

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

Рабочий процесс Гитхаба

Читать полностью »

Не так давно мы начали рендерить 3D-модели на Гитхабе. Сегодня мы с удовольствием объявляем о новейшем прибавлении в семействе визуализаций — о геоданных. Любой файл .geojson в репозитории на Гитхабе теперь станет автоматически отображаться в качестве интерактивной карты (с возможностью листания), снабжённой вашими геоданными.

[скриншот 2013-06-13 10:23:32]

Люди ужé используют Гитхаб для хранения разных геоданных, от почтовых индексов Чикаго и до радиостанций сообществ да путей движения известных в истории ураганов, так что мы с нетерпением ожидаем увидеть дальнейшие плоды сотрудничества сообществ.

«Под капотом» мы используем Leaflet.js для отображения данных geoJSON поверх специальной версии базового слоя карты улиц MapBox — упрощённого, чтобы данные ваши на нём воссияли. Лучше же всего — то, что картооснова использует данные OpenStreetMap; так что, если пожелаете улучшить какой-либо участок её, редактируйте тотчас же.

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

Читать полностью »

Enterprise версия программы FizzBuzz с правильной архитектуройЗдравствуй, хабрачитатель. Я – редактор блога ABBYY. Сегодня утром ко мне пришли разработчики, принесли вот этот текст и попросили напечатать. Я не смогла придумать, почему этот текст должен появиться в корпоративном блоге, но разработчики говорят, что он смешной и принесёт радость людям. Так тому и быть!

Устали от полных кривизны и костылей сложных в поддержке программ? Постоянно слышите о правильной архитектуре, но так и не видели ее? Встречайте на Гитхабе Enterprise-версию программы FizzBuzz, показывающую, как должно выглядеть серьезное решение с правильной архитектурой.
Читать полностью »

Первое погружение

image Я решил начать изучение распределённой системы управления версиями файлов GIT с веб-интерфейса Гитхаба. Причем, меня интересовала прежде всего такая теоретическая возможность: участие в коллективной разработке какого-нибудь маленького (но, очень ответственного) проектика, без необходимости установки какого-либо дополнительного программного обеспечения, ограничиваясь лишь веб-интерфейсом, доступным из любого браузера, и, быть может, встроенным Блокнотом (для, более комфортной правки исходного кода).

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js