GitHub *

Здравствуйте!

Издательство «Питер» рассматривает возможность выпустить книгу по системе управления версиями Git.

Хотим посоветоваться с будущими читателями: какое издание вам будет наиболее интересно в русском переводе?
Мы сразу исключили книги ознакомительного уровня и выбрали три кандидатуры:

1. Новое издание (декабря 2014) книги Скотта Шакона



(Хотим сразу предупредить, что данная книга получится самой дорогой — розничная цена может достигать 1500 руб. Необходимо учесть это при принятии решения).

2. Классику от O'Reilly



3. Более краткое, но не сильно уступающее в информативности издание от Manning



Просьба голосовать:

При разработке перл-модулей приходится делать много работы, которая практически не связана с задачами и кодом модуля — начиная от создания десятка типовых файлов/каталогов и заканчивая выполнением десятка одинаковых операций необходимых для выпуска новой версии.

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

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

Далее кратко описаны имеющиеся на начало 2015 года средства, которые могут облегчить процесс разработки перл-модулей, сделать ваши модули более современными, и упростить другим разработчикам доработку ваших модулей. Я постарался перечислить их основные плюсы и минусы, но т.к. сам пользовался не всеми то буду дополнять/исправлять этот список в соответствии с вашими комментариями.

 Цель статьи: дать пару идей для автоматизации, а может даже и рабочий инструмент для создание T4-болванок под решения типовых задач, производимых с классами/интерфейсами в работе.

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

Обнаружена новая критическая уязвимость CVE-2014-9390 в Git, позволяющая выполнить произвольные команды на клиенте.

Суть уязвимости заключается в возможности совершить коммит в .Git/config, что равносильно служебному пути .git/config на регистронезависимых файловых системах. Это дает возможность инициировать запуск произвольных команд на клиенте. В общем случае уязвимости подвержены рабочие станции на Windows и Mac OS X, Linux-системы будут подвержены в случае использования регистронезависимых файловых систем.

Утро прошло в экспериментах по поводу обхода из cygwin с помощью способов, описанных в статье «Краткая инструкция: GitHub через Tor».

Второй способ работает замечательно, но с помощью его нельзя, допустим, установить плагины в vim с помощью Vundle. Третий способ не работает. В случае захода по http сообщает, что нету, а при https жалуется на SSL сертификат. Ну и, конечно, неудобно, что надо постоянно запускать браузер. Torsocks на Windows не работает.

По сообщению заместителя руководителя Роскомнадзора Максима Юрьевича Ксензова сайт github.com исключен из реестра запрещённых сайтов РФ.

Ввиду того,что администрация GitHub предприняла меры по удалению запоещенной информации, доступ к ресурсу на территории РФ возобновлен

— Максим Ксензов (@mksenzov) 5 декабря 2014

Предлагаю использовать 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 тысяч.