GitHub *

Что не так с Disqus?

Для некоторых современных программистов не существует систем контроля версий кроме Git, но на практике Subversion всё ещё востребован, а Mercurial имеет своих ярых сторонников. Быстрый поиск в подкрепление.

В результате DevOps'ы не монопроектных компаний встречаются с необходимостью автоматизировать работу с весьма разными системами. При этом у каждой есть свои нюансы и неизбежно появляются скрытые ошибки в сценариях, выстреливающие в самый неподходящий момент. Возникает потребность в предсказуемом поведении с минимальной "гибкостью", а не пёстрым букетом возможностей.

Недавно я столкнулся с задачей переноса папки с проектом из одного репозитория в другой на 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: «Неисповедимы пути Решателя» или «Червоточины Ньютона»

Сейчас мало кого удивишь инструментами управления зависимостями проекта вроде npm, composer, bundler, pip, maven, cargo и других. Их общий недостаток — невозможность управлять непосредственно средой выполнения. Такая задача решается через nvm, php-build, rvm, virtualenv, sdkman, rustup и прочие глобальные "манагеры" версий runtime, обычно написанные под Bash/Zsh.

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

Далее разброд и шатание настегает Continuous Integration & Delivery, где ручные танцы с бубном установки инструментов и активирования конкретных версий совершенно не приветствуются, а в идеале требуется в принципе максимально абстрагироваться от используемых технологий и довести процесс до примитивных нейтральных команд: подготовить к релизу, затегить, скачать, подготовить, построить, упаковать, выложить, проверить, одобрить(подписать), выкатить.

Тут сам собой напрашивается инструмент, унифицировано работающий поверх уже существующих технологий,
который из себя и представляет FutoIn CID — FutoIn Continuous Integration & Delivery tool.

Построение геометрии любой детали в SolveSpace начинается с проектирования эскиза (sketch). Эскиз представляет собой набор замкнутых контуров (циклов, loop), каждый из которых не должен иметь самопересечений и пересечений с другими контурами. Контуры состоят из примитивов (entity). Примитивы объединяются в контуры с помощью ограничения "точка-к-точке" (points coincident).
Часть 1: Введение
Часть 2: Эскиз
Часть 3: Степени свободы и уравнения ограничений
Часть 4: «Неисповедимы пути Решателя» или «Червоточины Ньютона»

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

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

Вступление

С возрастом моя работоспособность не становится выше. Теперь я не могу сидеть по 6 часов не вставая: спина, шея, глаза — все это начинает рано или поздно болеть.

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

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

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

Отличие их состояло в том, что они активно распространяют свои технологии и знания — делятся с профессиональным сообществом открытым кодом и понятными мануалами, выступают на конференциях. Они осознанно вкладываются в развитие своих 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 дней в неделе).

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