Всем привет! Как я обещал в комментариях, заливаю на GitHub свои программы. Начну с DisType Pro. Репозиторий тут, но перед тем как писать о том, что я хочу сделать и в чем мне нужна помощь, расскажу об истории этой программы:


DisType pro.

Всем привет, если вы не в курсе, мы начали публиковать переводы релизных статей ГитЛаба.
Если вы пропустили предыдущие, вот ссылки: 8.10, 8.9, 8.8

ГитЛаб выпускает релизы 22 числа каждого месяца.
Перевод поста про релиз 8.11 в работе, а пока представляю на ваш суд еще одну статью из блога ГитЛаба про различие терминологии у GitLab, GitHub и Bitbucket.

---

В зависимости от рабочих задач и потребностей клиентов разработчикам приходится использовать разные платформы управления репозиториями. Типичный разработчик участвует в каком-нибудь открытом проекте на GitHub, а на работе хостит проект одного клиента на GitLab, а другого — в Mercurial и на Bitbucket. Переключения между платформами осложняются тем, что в них одни и те же вещи могут называться совершенно по-разному. В этой статье мы поможем вам сопоставить различия и заодно объясним, почему мы выбрали именно такие названия.

Начиная с версии 8.4 в GitLab значительно улучшился процесс миграции репозиториев из GitHub. Теперь GitLab импортирует не только репозитории, но ещё и вики-страницы, тикеты и пулл-реквесты. При этом большинство сущностей не меняют своего названия. Например, специфические термины Git, такие как commit или push, везде одинаковы. Не меняются и такие общие термины, как users, webhooks и issues.

Github — важная часть жизни современного разработчика: он стал стандартом для размещения opensource-проектов. В «2ГИС» мы используем гитхаб для разработки проектов web-отдела и хостинга проектов с открытым кодом.

Хотя большинство из нас пользуются сервисом практически каждый день, не все знают, что у него есть много фишек, помогающих облегчить работу или рутинные операции. Например, получение публичного ключа из URL; отслеживание того, с каких сайтов пользователи приходят в репозиторий; правильный шаринг ссылок на файлы, которые живут в репозиториях гитхаба; горячие клавиши и тому подобное. Цель этой статьи — рассказать о неочевидных вещах и вообще о том, что сделает вашу работу с гитхабом продуктивнее и веселее (я не буду рассматривать здесь работу с API гитхаба, так как эта тема заслуживает отдельной статьи).

Содержание

• Трюки с URL
• Горячие клавиши
• Тикеты и пулл-реквесты
• Github markdown
• Аккаунт
• Работа с репозиториями
• Поиск кода
• Командная строка и Github
• User scripts
• Github-вандализм
• Дополнительные Github-ресурсы
• Полезные ссылки

В числе самых обсуждаемых последних новостей в сообществе разработчиков были новые тарифы GitHub (см., например, здесь).

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

Некоторые прибегают к альтернативному решению и разворачивают GitLab (или другой git-сервис) на собственном или арендованном сервере.

Но и у этого решения есть свои подводные камни: GitLab очень требователен к системным ресурсам. Для частных лиц гораздо проще платить 7 долларов в месяц за GitHub, чем арендовать сервер надлежащей конфигурации.

Из сказанного, однако, не следует, что у GitHub на сегодняшний день альтернативы нет. Об одном весьма интересном и перспективном решении мы хотели бы рассказать в этой статье. Знакомьтесь: Gogs. Этот инструмент будет интересен как для индивидуальных разработчиков, так и для небольших компаний.

В этой статье не будет психологических исследований на тему open-source и разработки.
Не будет анализа open-source проектов с помощью R или Python.
И не расскажу о том, как правильно контрибьютить.
Возможно я даже буду говорить какие-то банальные вещи.

Но я всего лишь хочу поделиться тем, как участие в open-source проектах сделало мою жизнь разработчика ярче и продуктивнее.

От автора: В статье приведены мои слайды и заметки с выступления от 25 июня 2016 года на конференции WordCamp Europe. Говорил я примерно то же самое.



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

Программное обеспечение поедает мир

Известна фраза от Марка Андреессена, создателя браузера Netscape: «программное обеспечение поедает мир». Я хочу уточнить, что мир поедает ПО с открытым кодом, и у меня есть парочка аргументов в пользу моей версии.

Во-первых, результаты опроса 2015 года «будущее открытого ПО»: «78% анкетируемых сказали, что частично работают при поддержке ОПО, и 66% сказали, что создают ПО для клиентов на основе ОПО. Эти цифры почти удвоились с 2010 года».

Во-вторых, Надья Эгбал [Nadia Eghbal], проводящая интересные исследования экономики ОПО, подсчитала, что «Доля ОПО в приобретённом за $1 миллиард Instagram составляла не менее $143 миллионов».

Мне кажется, у этого кембрийского взрыва ОПО есть несколько причин:

2,8 млн репозиториев, 3 ТБ исходного кода и метаданных

Google в сотрудничестве с Github выложила для общественного пользования полную актуальную базу всех open-source репозиториев через интерфейс BigQuery. (Проверка свободной лицензии осуществляется через API.)

Наборы данных Google BigQuery Public Datasets содержат информацию о более чем 2,8 млн свободных репозиториев, о более чем 2 млрд файлов (исходный код последних версий 163 млн файлов), 145 млн коммитов и т.д. Общий размер базы — около 3 терабайт.

Раньше архивы Github выкладывались на Github Archive. Теперь всё это богатство доступно для полнотекстового поиска и анализа через простые SQL-запросы. Github обещает обновлять наборы данных еженедельно.

Думаю, нет нужды рассказывать хабрапользователю что такое Git / GitHub, pre-commit и как наносить ему hook справа. Перейдем сразу к делу.

В сети много примеров хуков, большинство из них на shell'ах, но ни один автор не уделил внимание одному важному моменту — хук приходится таскать из проекта в проект. На первый взгляд — ничего страшного. Но вдруг появляется необходимость внести изменения в хук, который уже живет в 20 проектах… Или внезапно нужно переносить разработку с Windows на Linux, а хук на PowerShell'е… Что делать? ??????? PROFIT…

«Лучше так: 8 пирогов и одна свечка!»

Примеры, конечно, сильно утрированы, но с их помощью выявлены неудобства, которых хотелось бы избежать. Хочется, чтобы хук не требовалось таскать по всем проектам, не приходилось часто «допиливать», но чтобы при этом он умел:

• выполнять проверку отправляемого в репозиторий кода на валидность (например: соответствие требованиям PEP8, наличие документации итд);
• выполнять комплексную проверку проекта (юнит-тесты итд);
• прерывать операцию commit'а в случае обнаружения ошибок и отображать подробный журнал для разбора полетов.

И выглядел приблизительно так:

python pre-commit.py --check pep8.py --test tests.py

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

Теперь платить нужно за число пользователей, а не приватные репозитории

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

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

Всем привет!
Хочу представить вам собственную разработку для создания API-документации. Она еще немного «сыровата», поскольку я уделил ей всего неделю, кроме того, я не являюсь веб-разработчиком. Однако на данном этапе, с целью написания API-документации для своего будущего проекта, она меня полностью устраивает.

Сама разработка находится на GitHub: github.com/gatools/restful-visual-editor

Заинтересовавшихся — милости прошу под кат.

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

Привет, Хабр!
Вчера мы выпустили новую версию нашего инструмента для code review и навигации по репозиториям, Upsource. Давайте посмотрим, что нового в этом релизе.

Поддержка PHP, Kotlin и JavaScript
С самого первого релиза мы стремились сделать инструмент для code review, который был бы таким же умным, как IDE от JetBrains. Поэтому, начиная с первой версии в Upsource были такие возможности, как навигация по коду и статический анализ для Java проектов, аналогичные тем, что вы можете найти в IntelliJ IDEA. Эта функциональность помогает лучше понять изменения в проекте и разобраться в том, какие потенциальные проблемы могли прокрасться в эти изменения, или как можно еще улучшить качество кода. Однако, мы решили не останавливаться на поддержке только Java-проектов и сегодня мы рады сообщить вам, что в версии 3.0 аналогичная функциональность доступна и для проектов на PHP и Kotlin. Также мы довели до ума поддержку JavaScript, которая была доступна и раньше, но находилась в экспериментальной стадии.



GitHub pull requests
Если ваша команда использует GitHub pull requests как основной процесс code review, мы рады сообщить, что теперь вам на помощь может прийти вся умная функциональность Upsource. Для этого достаточно подключить Upsource к вашему GitHub репозиторию и Upsource будет рассматривать ваши pull requests как code review. Все комментарии и активность в них, конечно же, будет синхронизована с GitHub.

В своей работе вы используете MySQL, Postgres или Mongo, а может даже Apache Spark? Хотите знать с чего начинались эти проекты и куда они движутся сейчас? В этой статье я представлю соответствующую визуализацию

Здравствуйте!
Продолжаю серию публикаций по учебному Java Enterprise проекту Topjava (Maven/Spring/Security/JPA(Hibernate)/Rest(Jackson)/ Bootstrap(CSS)/ jQuery+plugin).

Небольшая тема четвертого занятия: улучшаем качество кода

Полезные ссылки:

1. Контрактное программирование, Программирование по контракту
2. Comparison Preconditions in Java
3. QAPlug vs FindBugs
4. QAPlug tutorials
5. Codacy Home

В далёком 2012 на Хабре обсуждались «рестриктеры», «делитеры», «цензурасты», а также «абузо-устойчивые» провайдеры в статье про то, что был предложен новый HTTP-статус для цензуры, а точнее для ресурсов, доступ к которым ограничен из-за проблем с законом.

Собственно статус HTTP 451 был предложен Тимом Брэйем из Google, а виновником (в прямом и переносном смысле) переполоха стал в очередной раз заблокированный, заабузенный, зацензуренный и великий The Pirate Bay.

Почему это важно? Потому что вы, наверное, как и я, пользуетесь GitHub, программируете не только для души и, возможно, владеете доходными интернет-ресурсами.

Вы уже находитесь в правовом поле авторского права.

Github — это больше, чем просто сервис для хостинга кода и система контроля версий. Это настоящая социальная сеть для программистов, и неудивительно, что иногда хочется поставить значок , чтобы отметить чей-нибудь комментарий. Теперь это стало возможным. С сегодняшнего дня на Github появились эмодзи-реакции на пулл-реквесты, баги и комментарии.



Github надеется, что это сделает общение более эффективным.

Вчера, 17 февраля, команда разработчиков Github анонсировала новый функционал, которого пользователям, участвующим в групповой разработке, могло серьезно недоставать: теперь в GitHub есть шаблоны для Issue и Pull-реквестов.

Cегодня Dash наконец открыл исходный код ПО «dashvend», на котором работает концепт — аппарат по продаже газировки (вызвавший фурор на последней Биткойн-конференции в Майами). Теперь желающие могут создавать собственные вендинговые устройства на базе технологии мгновенных платежей Dash InstantX (эта технология уже поддерживается в мобильных кошельках Dash).

На этот раз я бы хотел предложить к прочтению [вольный] перевод статьи Тома Престон-Вернера, одного из сооснователей GitHub, в которой он рассуждает о том, какие выгоды компания может извлечь из открытия своих проектов, какие проекты открывать не стоит и какова Единственно Правильная Лицензия. Хочу также отметить, что мнение переводчика не всегда совпадает с мнением автора оригинала. Ссылка на оригинал, как всегда, под текстом перевода.

Когда Крис и я начинали работу над GitHub в конце 2007, мы разделили работу на две части. Крис работал над Rail-приложением, а я работал над Grit, первым в истории адаптером Git для Ruby. После шести месяцев разработки, Grit стал достаточно законченным, чтобы обслуживать GitHub во время нашего публичного запуска сайта и мы встали перед интересным вопросом:

Стоит ли нам открыть исходники Grit или оставить его проприетарным?

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

Я видел много проектов, где конфигурация подкладывается в файловую систему в виде properties/json/xml файлов с непостижимыми уму переоределениями в момент загрузки. И что же на самом деле использует приложение становится ясно только после просмотра лог файлов компонента либо во время отладки.