GitHub *

В этой публикации я расскажу о том, как создать GitHub Pages для AngularJS-проектов, которые были созданы с помощью генераторов Yeoman. gh-pages удобен тем, что позволяет наглядно увидеть веб-страницу, а не ее исходный код. Как написано в описании gh-pages, они используются для статических HTML-страниц [1]. Однако, и в случае AngularJS-фреймворка, gh-pages могут быть полезны.

Git — штука не то чтобы особо сложная, но гибкая. Иногда эта гибкость приводит к забавным последствиям. К примеру, посмотрите на этот коммит на GitHub. Он выглядит как нормальный коммит, но если вы клонируете себе данный репозиторий, то такого коммита в нем не найдете. Потому что это потерянный коммит, более известный как git loose object или же orphaned commit. Под катом — немного про внутренности Git, откуда такое берется и что делать, если оно вам встретилось.

Когда наш проект только зарождался, он базировался на гипотезе, что почти для любой библиотеки можно найти changelog, а если найти нельзя, то можно построить его из коммит-мессаджей. Но реальность оказалась не столь радужной, как нам того хотелось: то файл changelog в каком нибудь безобразном формате попадётся, то его перестали вести, а продукт меж тем развивается, то что нибудь ещё. И тогда мы поняли, что распарсить мир – мало, надо его менять.

Изменить что-то за один миг — необычайно сложная задача

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



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

Вчера случилось долгожданное для SourceTalk событие: наконец вышел полноценный релиз. Для тех кто о проекте слышит первый раз или уже успел забыть: SourceTalk — это сервис для обсуждения исходных кодов в реальном времени, по изначальной задумке — что-то вроде Campfire или HipChat для разработчиков, но возможно вы уже успели познакомиться с более близким аналогом, вышедшим в прошлом году — Gitter. О непростом пути, пройденном за два года развития от прототипа до релиза, можно прочитать в моей статье на Мегамозге. Здесь же я опишу только текущий функционал.

Встречайте — 1C: Enterprise Development Tools.

Начну с предыстории.

Два года назад Борис Нуралиев, директор фирмы «1С», дал большое интервью сообществу INFOSTART.RU. Самым популярным вопросом был про усовершенствование среды разработки для программистов 1С.

На днях, произошел очень интересный этап в истории развития 1С – была выпущена новая среда разработки под 1С — 1C:Enterprise Development Tools.

1C:EDT – это новая среда для разработки под «1С: Предприятие 8», которая основана на базе открытой платформы Eclipse.
Да, да, да – встречайте, во всех странах СНГ и не только – Eclipse с разработкой на русском языке!
(под катом много больших картинок)

Критикуешь – предлагай

Нас нередко ругают на Хабрахабре за то, что статьи недостаточно технические, а описание работы программы плохо детализировано. Но на самом деле каждый читатель понимает, что описать в одном посте абсолютно все – просто невозможно, потому что несколько лет развитие DRP шло во множестве направлений.

Часть из них связана непосредственно с исполняемым файлом, пресловутым .exe'шником; другая – с созданием архива и, что немаловажно, индекса драйверов; третья – с тестированием приложения и отдельных версий драйверов для различного оборудования как на разных версиях ОС Windows, так и на железных стойках. Часть из этих решений мы отдаем в тестирование пользователям, проявившим особенный интерес.

Всем владельцам проектов на Google Code пришло соответствующее письмо.
Сокращенный перевод новости:

Начиная с сегодняшнего дня, мы прекращаем возможность создания новых проектов на Google Code. Сервис будет закрыт примерно через 10 месяцев к 25 января 2016 года. Ниже перечислены ссылки на инструменты миграции, спроектированные для того, чтобы помочь вам перенести ваши проекты.

Сроки:
12 Марта, 2015 — Создание новых проектов отключено.
24 Августа, 2015 — Переход в режим «только для чтения».
25 Января, 2016 — Закрытие сервиса. Будет доступно скачивание архива проекта включая исходный код, багтрекер и вики. Архив будет доступен до конца 2016 года.

Гугл будет продолжать предоставлять Git и Gerrit хостинг для таких проектов как Android и Chrome. Мы по-прежнему будем поддерживать зеркала таких проектов, как Eclipse, kernel.org и другие.

Здравствуйте, меня зовут Александр, и я пишу велосипеды по выходным программист.



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

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

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

Издательство «Питер» рассматривает возможность выпустить книгу по системе управления версиями 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, который и был выбран.

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