GitHub *

[Прим. перев.]: предлагаю вашему вниманию перевод статьи Марка Отто, разработчика GitHub, бывшего разработчика Twitter, создателя самого известного CSS фреймворка Bootstrap. В этой статье он рассказывает о внутреннем устройстве CSS проектов GitHub.


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

Несколько фактов

Обзор нашего текущего состояния CSS:

• В качестве препроцессора мы используем SCSS.
• У нас есть более 100 отдельных исходных файлов стилей, которые мы компилируем перед выкаткой в продашн.
• Исходники компилируются в 2 отдельных CSS файла (чтобы избежать проблемы с максимальным количеством селекторов для IE<10).
• Эти 2 файла весят в сумме около 90 kb.
• Мы не используюм какую-нибудь особенную «CSS архитектуру».
• Для определения размера мы выбрали пиксели, но все же у нас есть немного «em-ов».
• Мы используем Normalize.css, смешанный с несколькими нашими собственными стилями для сброса свойств.

О публикации кода на Github или другом открытом хостинге часто говорят, как о такой живительной эвтаназии, после которой патчи, фиксы, сообщения о проблемах и прочие коммиты от сторонних разработчиков польются рекой. У меня пока противоположный опыт. В парочку моих относительно заметных проектов вообще никто и ничего реально не привнес, не говоря уж об остальных проектах. Более того, я несколько раз делал очень серьезные изменения/улучшения в чужие проекты, но их авторы морозились и не приняли изменения. Исходя из этого я развил теорию: мол, вся эта открытость и коллаборация — это красивые слова, реально все пилят что-то свое и зарабатывать деньги или пиар кому-то другому совершенно не горят желанием. Чтобы проверить теорию, я посчитал кое-какую статистику по всем репозиториям на Github, у которых больше 700 звездочек, таких чуть больше 4 тысяч.

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

Студент Anish Athalye из массачусетского института сделал интересную визуализацию активности GitHub. GitLive позволяет в реальном времени видеть активности пользователей со всего мира.

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

Многие опытные пользователи github-а знают, что отнюдь не для всего обязательно нужно использовать командную строку. Все это так.

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

Сейчас вы с трудом найдете профессионального разработчика, который не пользуется системой контроля версий (VCS) такой, как Git.
Но есть и не мало тех среди нас, кто не использует VCS по причине предвзятого мнения о системах контроля версий.
Ниже несколько мифов и отговорок, которые препятствуют внедрению в рабочий процесс разработчика Git (или любой другой VCS).

Компания Microsoft завела аккаунт на Github, где будет публиковать исходные тексты некоторых своих программ.

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

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

Post-publish: Некоторые оговорки касательно «старой версии» нужно уже воспринимать всерьёз — на Github уже установлен Jekyll 2.2.0. Топик писался, когда актуальной на гитхабе была версия 1.5.1.


Cложилась интересная ситуация. Jekyll нынче на версии 2.1.1, а Github собирает сайты устаревшей (но надёжной) версией 1.5.1 (на данный момент, актуальная информация здесь). На этом некоторые уже споткнулись, получив ошибки сборки, когда согласно документации с сайта Jekyll всё в порядке. Избегать подобных казусов легко – нужно использовать не jekyll, а github-pages, чтобы версии совпадали с развёрнутыми на гитхабе. Свежие версии, ценой некоторых усложнений в процессе публикации, тоже можно использовать. Способ широко известен и будет описан далее, но сначала нужно разобраться, «зачем всё это?»

Переход на 2.х потихоньку идёт. Нововведения круты и их многие ждут с нетерпением. А стоит ли? Давайте подумаем… но сначала введём в курс дела тех, кто с Jekyll столкнулся впервые.

Вчера Github объявил о поддержке PSD в дополнение к текущим графическим форматам. Появился отличный повод облегчить жизнь дизайнерам и фронтэндщикам, очень надеюсь на понимание первыми необходимости и приобщение.
Ссылка на новость в блоге гитхаба.

В нашей небольшой компании (6 backend + 4 frontend разработчика) для code review (далее CR) мы использовали Gerrit. Gerrit используется, например, для разработки Android. Это инструмент, дающий очень много свободы в настройке процесса CR, но мы от него отказались. Почему? Он прекрасен для суровых backend парней, который легко делают interactive rebase, merge, resolve conflict, amend commit и т.д. Люди из frontend команды по ночам плачут в подушку от тягот рабочего процесса в Gerrit.

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

Мы пришли к Bitbucket. Под катом ответы на вопросы почему Bitbucket и почему не GitHub.

Гитхаб продолжает расширять области своего применения — руководство компании видит Гитхаб в будущем не только как инструмент для программистов, но и как универсальное хранилище любых текстовых данных. На нём уже есть репозитории, в которых пишутся книги, законопроекты, публикуются статистические данные. А на прошлой неделе появилась возможность присвоить любому своему репозиторию идентификатор DOI. Это позволит ссылаться на данные или код из репозиториев Гитхаба в научных работах и статьях общепринятым в научной среде способом.

Github является незаменимым сайтом, на котором разработчики проводят многие часы. Некоторым хочется добавить удобства в повседневную работу. Расширение Octotree для Firefox/Chrome/Safari делает именно то, чего так не хватало на Github, а именно, отображает исходный код в виде дерева.

Привет, Хабр! В очередной раз на глаза попался очень интересный репозиторий. Эта шпаргалка по самым тайным и функциональным возможностям Git и GitHub появилась благодаря выступлениям Зака Холмана одну из статей которого я уже переводил Git and GitHub Secrets на Aloha Ruby Conference 2012 и More Git and GitHub Secrets на WDCNZ 2013. Стоит сказать о том, что проект набрал свыше 1000 старов менее чем за 12 часов. Приведу несколько примеров:

Hub — Git Wrapper

Hub — это оболочка над Git, которая сокращает потраченное время на лишнее нажатии клавиш при работе с Git.

$ hub clone tiimgreen/toc
> git clone https://github.com/tiimgreen/toc.git

На hub можно сделать алиас git и все будет выглядеть еще удобнее:

# Remote
$ git remote add rtomayko
> git remote add rtomayko git://github.com/rtomayko/CURRENT_REPO.git

#Fetch
$ git fetch mislav
> git remote add mislav git://github.com/mislav/REPO.git

#Fork
$ git fork
[ repo forked on GitHub ]
> git remote add -f YOUR_USER git@github.com:YOUR_USER/CURRENT_REPO.git

На хабре есть пост habrahabr.ru/post/195054 «Как бесплатно получить Micro аккаунт на GitHub студенту в России» от 24 сентября 2013 года и больше никаких упоминаний об этой интересной программе от Github'а.
А тем временем, 10 февраля 2014 года Github запустил отдельный сайт education.github.com и сообщили в своем блоге, что они уже много лет предлагают образовательные скидки и более чем 1200 учебных классов и 7000 студентов воспользовались этим предложением на данный момент.
Теперь же они эту программу запустили официально, сделали отдельный сайт и предложили следующее:

• Бесплатную Micro подписку для студентов и преподавателей
• Бесплатные Github-организации для использования в классах
• 25% скидка во всех остальных случаях для использования в учебных целях

Однажды мне потребовалось создать gist, а еще я активно пользуюсь Notepad++. После того, как найти плагин для работы с gist в Notepad++ мне не удалось (есть только под Sublime), я решил написать свой. Ну и к тому же это было хорошим опытом в написании плагинов и работе с github api.
Сразу выкладываю ссылку на исходники:
NppGist sources и сам плагин: NppGist (для его подключения просто перенесите файл в папку plugins в папке Notepad++).



Под Notepad++ плагины можно писать на нескольких языках: C++, Ada, Delphi, .NET, но я остановился на последнем из-за скорости разработки и из-за того, что я лучше его знаю.

Для разработки было использовано следующее:

1. NppPlugin.NET — шаблон Notepad++ плагина для .NET платформы.
2. ServiceStack.Text — сериализация и десериализация JSON (высокая производительность и небольшой размер).
3. hurl.it — удобный онлайн-инструмент для составления и тестирования GET, POST, DELETE и других запросов.
4. NUnit — юнит-тестирование.

Тем, кому интересно знать, как писать плагины под Notepad++, добро пожаловать под кат.

7 марта мы добавили ко графикам вашего вклада учёт часовых зон. GitHub используется повсеместно — и мы хотим, чтобы это отразилось в его возможностях. Если вам довелось работать из Японии, Австралии или Улан-Батора, мы хотим учитывать ваш вклад с вашей точки зрения.

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

Испортить вашу нынешнюю полосу продуктивной работы мы не хотим, так что учёт часовых зон начнётся только для вклада, совершённого после понедельника 10 марта 2014 года (Temps Universel Coordonné).

Желаем весело провести время (вашей зоны)!

GitHub сегодня анонсировал запуск GitHub Developer Program, предназначенной для лучшего информирования разработчиков о происходящих изменения и коллективной работы над улучшением сервиса.



Члены GitHub Developer Program будут получать уведомления об изменениях в GitHub API, а также самый ранний доступ к новым функциям. У участников программы кроме того будет возможность запросить лицензию разработчика для GitHub Enterprise и размещать свои инструменты для рассмотрения на новой странице интеграции, также запущенной сегодня.

От переводчика: вчера без официального объявления на Гитхабе были опубликованы несколько десятков репозиториев, содержимое которых свидетельствовало о том, что команда Гитхаба уже давно ведёт разработку нового текстового редактора для программистов и готова представить его публике. Несколькими часами позже заработал и официальный сайт редактора atom.io, на котором сейчас можно запросить инвайт на бета-тестирование, ознакомиться с документацией и плагинами к редактору. Эта статья — перевод двух первых постов из блога проекта Atom, посвящённых концепции и архитектуре редактора.

Представляем Atom

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

Sublime и TextMate предлагают удобство, но лишь ограниченную расширяемость. С другой стороны, Vim и Emacs обладают огромной гибкостью, но сложны в освоении и требуют изучения специфических скриптовых языков для модификаций.

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

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


Темная тема интерфейса

Как часто вы не могли вспомнить ту или иную команду в Git, Vim, Linux, C++? Сколько времени вы тратите на поиск ответа в man или в интернете? Пробовали ли вы когда-нибудь писать свои собственные справочники и чем это заканчивалось? Хотели бы вы немного помочь вашей памяти?
Разрешите вам помочь. Под катом небольшая история эволюции моих справочников и утилита Dic.