GitHub *

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

Навеяно публикацией «Github опять заблокирован».

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

Почему-то сразу пришла в голову мысль об I2P.

И это действительно оказалось несложно.

В списке самых популярных репозиториев Github за неделю на первое место вышел набор иконок Material Design, разработанный в компании Google.

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

Github предоставляет всем своим пользователям создать статический блог в домене github.io. При это предлагает использовать Jekyll. Но сегодня мы поговорим о том, как сделать блог на гитхабе с cms ghost.

Наконец-то я созрел, чтобы начать свой веб-проект. Очередной todo-менеджер, который агрегирует задачи с нужных мне источников. Планировался как проект для души, такой чистый и правильный. Никаких компромиссов в архитектуре и технологиях. Только best-practices, только хардкор. И, конечно же, кнопать это все собрался в любимой Intellij IDEA.

После 7 лет Java, последних двух вперемешку с Scala, захотелось попробовать Groovy. Для сборки, конечно же Gradle — популярно и удобно. Рельсы показались слишком «заезженные», так что решил использовать Spring для веб, причем по современному, через Spring Boot. И все было просто замечательно, только с ORM не сложилось. На работе мы Hibernate выпилили, заказчик лично невзлюбил (не смейтесь и такое бывает — отдельная история) и заменили своим велосипедом. Негативный опыт и нежелание тянуть монстра ради пары сущностей сделали свое — хибернейту твердое нет! Захотелось попробовать что-то совсем другое. По воле случая наткнулся на Ebean, который и был выбран.

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

Несолько минут назад я получил сообщение от гитхаба с информацией о новой программе Student Developer Pack, о которой я и хочу с вами поделиться.

Програма Student Developer Pack расчитана на студентов, которые не могут себе позволить использование дорогостоящих подписок на платные сервисы для разработки.

* бесплатные, но на различных условиях.
Привет, Хабр. Пару часов назад мне пришло на почту письмо от гитхаба. Краткий пересказ: нет ничего более ценного чем практический опыт, но для огромного количества студентов многие профессиональные инструменты недоступны из-за высокой цены. И мы (гитхаб) с нашими партнерами решили создать Student Developer Pack — дать бесплатный доступ к отличным инструментам разработчика и собрать всё это в одном месте.
Если у вас имеется аккаунт на Гитхабе, и вы зарегистрированы в студенческой программе(GitHub Education, если нет — то регистрируетесь и получаете пак), то можно получить довольно большой список инструментов:

Вступление

Одним прекрасным, светлым утром, будучи потрясенным от того, что температура за окном, как казалось, была градусов на 5 больше чем обычно, я почувствовал наплыв небывалой ранее освещенности и в мой мозг прокралась идея — «а ведь те, офферы и аккаунты, которые продаются на „черном рынке“ — они же ворованные всевозможными фишинг-сайтами и стилерами, а насколько я знаю стилеры — все логи должны храниться на каом-то хосте в сети интернет».

UPD: Ресурс исключён из реестра

Вот что сейчас можно увидеть при попытке зайти на Github:



Провайдер — дом.ру. Комментарии излишни.

Команда Atom опубликовала roadmap. Впервые это объявлено на discuss, затем добавлено в FAQ и расписано в issues, потому новость вполне официальная, хотя её всё ещё нет в блоге. На скрине список на стабилизацию API.
UPD. Из интересного:

• У команды разработчиков Atom нет жестких сроков
• В текущем роадмапе отсутствует поддержка отличных от UTF-8 кодировок (линк на коммент)
• Хотя официальная поддержка больших файлов (>2МБ) только планируется — в последних сборках расширение (до 10МБ) обходится заменой пары строк в коде

На сайте Оксфордского института интернета можно найти солидную коллекцию визуализаций данных об интернете, составленную институтом за последние три года.



Для этого поста я выбрал:

— статистику проникновения интернета по странам,
— глобальную статистику использования Тора,
— статистику активности программистов (на основе распределения пользователей и коммитов Гитхаба),
— схему магистральных кабелей интернета,
— статистику запросов и удалений данных в интернете,
— представления пользователей интернета о разных странах.

[Прим. перев.]: предлагаю вашему вниманию перевод статьи Марка Отто, разработчика 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 столкнулся впервые.

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

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

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