Как стать автором
Обновить
25.78

GitHub *

Веб-сервис для хостинга и разработки IT-проектов

Сначала показывать
Порог рейтинга
Уровень сложности

Впечатления от сорокá дней ежедневной работы над открытым исходным кодом на Гитхабе

Время на прочтение4 мин
Количество просмотров39K
Утром 1 октября 2013 года календарь проделанной работы над открытым исходным кодом, расположенный на моей гитхабовской странице, выглядел вот как:

[скриншот календаря]

Это не было простой случайностью. Я нарочно решил (руководствуясь GTD-соображениями) достаточно долгое время стараться каждый день чего-нибудь делать на Гитхабе, а затем (если дело пойдёт) поделиться на Хабрахабре наиболее ценными впечатлениями от именно такой манеры работы (назовём её, скажем, calendar-driven development), когда впечатления накопятся.

И поделяюсь.

Читать дальше →
Всего голосов 69: ↑54 и ↓15+39
Комментарии43

GitHub Flow: рабочий процесс Гитхаба

Время на прочтение10 мин
Количество просмотров125K
Краткое предисловие переводчика.
Захватывающе интересная статья одного из разработчиков «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 (и т. п.) не создаёт проблем.

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


Читать дальше →
Всего голосов 111: ↑105 и ↓6+99
Комментарии47

Для этого есть карта

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

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

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

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

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

Читать дальше →
Всего голосов 74: ↑68 и ↓6+62
Комментарии17

Подключение картинок к описаниям проблем на Гитхабе

Время на прочтение1 мин
Количество просмотров12K
Говорят, одна картинка стóит тысячи слов. Меньше слов — это одна из важнейших целей команды Гитхаба, поэтому сегодня мы выпустили в свет подключение картинок к описаниям проблем.

[анимированный скриншот]

Довесок.  А если вы пользуетесь Хромом, то сможете вставить (paste) картинку в поле комментария — и она закачается да подключится.
Всего голосов 56: ↑38 и ↓18+20
Комментарии21

Истории

GitHub внедрил новую систему уведомлений, которая лучше предыдущей, но внедрил он её нехорошо

Время на прочтение5 мин
Количество просмотров10K
6 августа 2012 года во блоге Гитхаба появилась новость, посвящённая внедрению новой системы уведомлений и звёзд. Я намерен сперва подробно пересказать новость, а затем вкратце упомянуть о том, что мне не нравится в этой новости.

(В пересказе уместно для полноты употребить все иллюстрации из первоисточника — а их восемь, и притом размер их значителен. Поэтому мобильным пользователям рекомендую перед чтением добраться до точки бесплатного Wi-Fi, посетителям интернет-салонов с оплатою за траффик — добраться до домашнего безлимита, и так далее, и так далее.)

Интерфейс уведомлений


Первая и наиболее заметная новинка заключается в изменении интерфейса уведомлений:

[интерфейс уведомлений]

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

Во-вторых, список уведомлений разбит на группы по репозиториям. Раньше уведомления располагались просто в обратном хронологическом порядке по мере их поступления, то есть сплошной кучею. Нынешний порядок более логичен: он позволяет читателю не переключать своё внимание от репозитория к репозиторию.

Звёзды


Другая новинка заключается в появлении системы звёзд. Чтобы выразить свой интерес к репозиторию, ранее его было принято добавлять в наблюдаемые (watched), а теперь все репозитории, ранее вами так помеченные, попадают на страницу звёзд (stars):

Читать дальше →
Всего голосов 67: ↑49 и ↓18+31
Комментарии15

Блог на Jekyll и Github

Время на прочтение2 мин
Количество просмотров37K

Блог на Jekyll и Github


Для ведения блога существует множества прекрасных решений: posterous, blogger, wp… Выбирать можно и выбирать нужно, если вы хотите вести свой блог конечно. Сейчас я расскажу об относительно новом гик-решении в блоговедении — это Jekyll блог на базе Github.
Jekyll — это простой генератор статичных сайтов, аля блог. Он содержит шаблоны для создания логики сайта. Благодаря Github Pages — сайт можно хостить на Github. Это просто. Создаете репозиторий «Название сайта».github.com и публикуете туда код вашего сайта на Jekyll. Commit+Push и Github автоматически обновляет ваш сайт.
Читать дальше →
Всего голосов 43: ↑40 и ↓3+37
Комментарии37
12 ...
34

Вклад авторов