Кнопка или ссылка?

Я знаю хабр не для жалоб,

но доколе

использовать ты будешь

— ссылки вместо кнопок <UserName />‽

Автор иллюстрации <Marat Hilmanov> gray-monkey@yandex.ru

Если коротко:

Используйте для кнопок — кнопки, а для ссылок — ссылки.

Для кнопок использовать
ссылки
— не комильфо.

Я обожаю GitHub Pages. Я использую их для всего, что только можно и пытаюсь избежать кода на стороне сервера как чумы. Я пушу изменения в репозиторий и они тут же отображаются для пользователей без каких-либо хуков или дополнительных шагов. Бесплатность делает их еще привлекательнее. Когда пришло время публиковать мою книгу, естественно, я хотела чтобы сопровождающий вебсайт был на GitHub Pages.

Но была одна проблемка: я хотела красивые урлы, например http://play.csssecrets.io/pie-animated, которые бы редиректили на демки на dabblet.com. Любой нормальный человек бы скорее всего стиснул зубы и использовал какой-нибудь серверный язык для этого. Но я же не совсем нормальная :)

Если ваш проект хранится только у вас на диске, то с поломкой диска вас ожидают неприятности. Даже регулярный бэкап не всегда сможет вас спасти.

Некоторые разработчики могут наворотить в проекте столько всего, что сами в шоке. А вспомнить, что и где делалось, затруднительно. Та еще неприятность.

Система контроля версий поможет вам избежать этих проблем. В случае необходимости можно совершить восстановление или откат изменений. Просмотреть и подтвердить или отменить правки. Ну а командная работа без системы контроля версий просто немыслима.

Если вы вдруг не знакомы, то я хочу немного познакомить вас с системой управления версиями по имени Git. Под катом вас ожидает описание того, как использовать GitHub вместе с Visual Studio.

«В следующие два года нужно не пытаться изобразить из себя что-то особенное, а просто быть достаточно умным, чтобы компоновать то, что человечество уже создало» (с) bobuk

Год назад на внутреннем хакатоне наши ростовские ребята за ночь скрестили визуальный текстовый редактор, «Типограф Муравьева» и антиплагиат-сервис. Получилась штука, которая помогала быстро подготовить и отправить публикацию в блог.

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


Старик Гутенберг был бы доволен

Оно позволяет людям читать занятные истории, как дядька-водолаз 40 лет поднимает затонувшие корабли в Баренцевом море, а писателям на популярные нетехнические темы — немного зарабатывать на текстах.

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

TL;DR: github.com/limonte/dear-habr

Уважаемая администрация ТМ, вы сделали и поддерживаете лучший русскоязычный IT-блог. Вы отлично справляетесь со своей задачей, но я верю, что пришло время сделать шаг вперёд и стать чуточку ближе к своим пользователям.



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

Мы часто забываем похвалить то, что отлично выглядит и работает, принимая это как само собой разумеющееся.

Восполняя этот пробел, хочу ответственно заявить:

Хабр, ты лучший по функционалу и UI не только в рунете, ты — абсолютный чемпион. И пусть меня кто-нибудь поправит в комментариях, приведя IT-блог на любом языке, который удобнее Хабра.

В этом эссе описана схема работы Git. Предполагается, что вы знакомы с Git достаточно, чтобы использовать его для контроля версий своих проектов.

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

Текст разбит на серии команд, работающих с единым проектом. Иногда встречаются наблюдения по поводу структуры данных графа, лежащего в основе Git. Наблюдения иллюстрируют свойство графа и поведение, основанное на нём.

После прочтения для ещё более глубокого погружения можно обратиться к обильно комментируемому исходному коду моей реализации Git на JavaScript.

Я выступал на DomCode в ноябре 2015 года (отличная конференция, кстати; проходила в маленьком красивом городке) и рассказывал о своем списке правил для построения open source сообществ. Один человек позже попросил меня объяснить, почему я советую мерджить патчи быстро, не дожидаясь завершения тестирования непрерывной интеграции (Continuous Integration) и без перепроверки кода. Я буду называть эту стратегию optimistic merging (ОМ). И сейчас я расскажу о некоторых ее плюсах.

Стандартная практика для многих сообществ — пессимистичный мерджинг (ПМ). Это когда нужно сначала дождаться, пока тестирование непрерывной интеграции завершится, потом пересмотреть код, потом протестить патчи на ветви и затем дать фидбэк автору. Тогда только он может пофиксить патчи, и весь этот цикл начнется заново. На этой стадии сопровождающий запросто может сказать: «Мне не нравится, как вы это сделали» или «Это не совпадает с нашем видением проекта».

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

Тематическое моделирование — подраздел машинного обучения, посвященный извлечению абстрактных «тем» из набора «документов». Каждый «документ» представлен мешком слов, т.е. множеством слов вместе с их частотами. Введение в тематическое моделирование прекрасно описано проф. К. В. Воронцовым в лекциях ШАД [PDF]. Самая известная модель ТМ — это, конечно, Латентное размещение Дирихле (LDA). Константину Вячеславовичу удалось обобщить все возможные тематические модели на основе мешка слов в виде аддитивной регуляризации (ARTM). В частности, LDA тоже входит в множество моделей ARTM. Идеи ARTM воплощены в проекте BigARTM.

Обычно тематическое моделирование применяют к текстовым документам. Мы в source{d} (стартап в Испании) перевариваем биг дату, полученную из GitHub репозиториев (и скоро примемся за каждый публично доступный репозиторий в мире). Естественным образом возникла идея интерпретировать каждый репозиторий как мешок слов и натравить BigARTM. В этой статье пойдет речь о том как мы выполнили по сути первое в мире тематическое исследование крупнейшего хранилища open source проектов, что из этого получилось и как это повторить. docker inside!

[Прошедшему Году литературы посвящается]

Это была очередная пятница в тихом, уютном баре с лучшими друзьями… Разговор шел как обычно: новости, работа, шутки и опять по кругу. В поисках темы для разговора, потягивая из пивных кружек, почему-то вспомнили о стихах :) И тут каждый стал припоминать, что он еще помнит с тех далеких школьных лет. Если спотыкался, остальные подсказывали, ежели кто помнил, было довольно весело и интересно. Возвращаясь домой в тот вечер, я подумал: а что если сделать простое веб-приложение, чтобы каждый мог вспомнить эти прекрасные произведения русской поэтической мысли? Дизайн приложения уже крутился в голове, и я засел за разработку…

Итак, требовалось: опубликовать книгу с иллюстрациями онлайн так, чтобы ее можно было дописывать и переписывать, и извещать об этом читателей. Быстрое и изящное решение под катом.

Для пытливых разработчиков до сих пор остается актуальным вопрос использования табуляции и пробелов для форматирования кода. Могут ли они быть взаимозаменяемы: например, 2 пробела на табуляцию или 4? Но единого стандарта нет, поэтому иногда между разработчиками возникает непонимание. Кроме того, различные IDE и их компиляторы обрабатывают табуляцию также по-своему.

Решением вопроса обычно становится соглашение о правилах форматирования в рамках проекта или языка программирования в целом.

Команда разработчиков из Google исследовала проекты в репозитории Github. Они проанализировали код, написанный на 14 языках программирования. Целью исследования было выявить соотношение табуляций и пробелов — то есть, наиболее популярный способ форматирования текста для каждого из языков.

Китайский удостоверяющий центр WoSign, который специализируется на выдаче бесплатных SSL-сертификатов, по ошибке выдал дублирующие сертификаты для базовых доменов Github и Университета Центральной Флориды обычному пользователю.

Ошибку обнаружил один из студентов учебного заведения — по словам сотрудника Mozilla Джерваза Маркхама (Gervase Markham), описавшего эту историю, все случилось еще в апреле 2016 года, но известно об этом стало только сейчас.

Всем привет! Как я обещал в комментариях, заливаю на 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

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