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

Итак, что дано:

• Есть большой репозиторий, содержащий множество папок. Каждая папка – это отдельный проект.

Что необходимо сделать:

• Одну из папок перенести в отдельный репозиторий с сохранением ее истории коммитов.

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

Я использовал стандартный гитовый filter-branch. За основу я взял следующие статьи:

• Moving Files from one Git Repository to Another, Preserving History
• Splitting a subfolder out into a new repository

В этом посте я хочу немного адаптировать процесс для лучшего восприятия.

Важным условием корректности построенного эскиза является непротиворечивость наложенных ограничений. Если наложено меньше ограничений, чем требуется, некоторые параметры не могут быть однозначно определены, поэтому могут изменяться в некотором диапазоне значений. В таких случаях говорят, что чертеж имеет степени свободы (Degrees Of Freedom; DOF). Анализ степеней свободы позволяет инженеру-конструктору накладывать только необходимое и достаточное количество ограничений, не позволяя системе уравнений быть переопределенной (overconstrained), и не позволяя оставить какую-либо степень свободы без наложенных ограничений.
Часть 1: Введение
Часть 2: Эскиз
Часть 3: Степени свободы и уравнения ограничений
Часть 4: «Неисповедимы пути Решателя» или «Червоточины Ньютона»

Сегодня в выпуске:

• Настраиваем continuous integration c travis ci
• Настраиваем отчеты о test coverage с coveralls
• Мониторим статус зависимостей с david
• Настраиваем автоматическое обновление зависимостей с greenkeeper
• Улучшаем сообщения коммитов с commitizen
• Генерируем changelog и release notes с conventional-changelog
• Управляем задачами с zube

На прошлой внутренней конференции разработчиков Контура я выступал с докладом. В моей презентации был слайд, на котором были перечислены известные российские ИТ-компании, разделенные на два столбца. Между компаниями в правом и левом столбцах было одно весомое различие.

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

Отличие их состояло в том, что они активно распространяют свои технологии и знания — делятся с профессиональным сообществом открытым кодом и понятными мануалами, выступают на конференциях. Они осознанно вкладываются в развитие своих opensource-проектов. Технологии и описания многих из них лежат в открытом доступе на специально созданных сайтах tech.yandex.ru, opensource.mail.ru, techno.2gis.ru/opensource, и известны многим разработчикам за пределами компаний.

Если вы вдруг решили заняться благотворительностью (почти) и сделать что-то подобное в своей компании, надеюсь, мой текст поможет ответить на вопросы: нужно ли это вам, сколько ресурсов потребуется и что в итоге получится. У нас вышел такой сайт: tech.skbkontur.ru.

Всем привет от Translation Gang!

Vue.js нам показалось мало. Планов громадьё, причём даже за пределами русского языка, фронтенда и веба вообще, но на практике пока что далеко от Vue не убегали — благодаря стараниям theOnlyBoy мы оперативно перевели документацию фреймворка сверхвысокого уровня Nuxt.js.

• Официальный сайт с переводом
• Репозиторий на GitHub

Сам фреймворк ещё молодой и немного сырой, как и его документация — но что есть, то мы перевели, и как только обновляются оригинальные доки — тут же обновляем и перевод. Надеемся, вам понравится!

[Пятничное]

Всегда хотел сделать свой график активности пользовательского профиля на Гитхабе. Например, выкладывать коммиты каждый день так, чтобы через год этот график превратился в какую-нибудь картинку, пусть и с ограничением по размерам в 52×7 квадратиков-пикселей (52 недели в году × 7 дней в неделе).

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

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

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

но доколе

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

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

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

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

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

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

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

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