Мне на глаза попался документ с правилами и рекомендациями по процессу ревью кода внутри компании. Я решил, что такой полезной информацией надо поделиться с внешним миром. С благословения автора я публикую работу.

Привет. Меня зовут Сергей, последние пять лет я работаю в Яндексе. За это время участвовал в разработке одиннадцати проектов. Писал код на JavaScript, Python и C++. Некоторые проекты делал в одиночку, другие разрабатывал в группе из восьми человек. Но в каждой команде, на всех проектах, вне зависимости от языка программирования я использовал код-ревью.

С помощью код-ревью я постоянно узнаю что-то новое. Иногда, глядя на чужой код, хочется воскликнуть: "А что, так тоже можно?". В чужом коде я нахожу интересные приёмы и беру их себе на вооружение. Много новых знаний черпаю из комментариев к моему коду. Для меня стало открытием, что люди любят делиться своим опытом. Даже когда я разрабатываю проект в одиночку, то прошу ребят из другой команды посмотреть мои пулреквесты. Это мотивирует писать красивый и понятный код.

Но так было не всегда. Когда-то ревью было для меня наказанием. Я мог неделю с вдохновением писать код, вкладывая в него все силы. Отправлял пулреквест, трижды пинговал ревьювера, а в ответ получал сухое "вроде ок" или, что ещё хуже, десятки комментариев не по существу.

Мне на ревью приходили пулы из пяти тысяч строк. Я часами пытался разобраться в коде, по сотне раз скроллил от функции к тесту и обратно. Писал десятки бесполезных комментариев о пропущенной точке с запятой. Всё это жутко меня раздражало. Часто откладывал ревью на потом, и у меня накапливались десятки непросмотренных пулов.

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

Код проекта доступен в репозитории

Введение

Когда я читал описания внешнего вида персонажей в книгах, мне всегда было интересно, как бы они выглядели в жизни. Вполне можно представить себе человека в целом, но описание наиболее заметных деталей – задача сложная, и результаты разнятся от человека к человеку. Много раз у меня не получалось представить себе ничего, кроме весьма размытого лица у персонажа до самого конца произведения. Только когда книгу превращают в фильм, размытое лицо заполняется деталями. К примеру, я никогда не мог представить себе, как именно выглядит лицо Рэйчел из книжки "Девушка в поезде". Но когда вышел фильм, я смог сопоставить лицо Эмили Блант с персонажем Рэйчел. Наверняка у людей, занимающихся подбором актёров, уходит много времени на то, чтобы правильно изобразить персонажей сценария.

Эта статья — продолжение статьи про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений применимо к решениям на платформе InterSystems.

Рассмотрим такие темы как:

• Контейнеры 101
• Контейнеры на разных этапах цикла разработки ПО
• Continuous Delivery с контейнерами

Наш коллега, Скотт Хансельман, продолжает изучать тестирование и покрытие кода в .NET Core. Он уже успел рассказать о некоторых инструментах для улучшения качества тестирования, и сегодня рассказывает еще об одном: AltCover. Заглядывайте под кат!

Разработчики из GitHub на прошлой неделе выложили в открытый доступ исходники своего балансировщика нагрузки — GLB Director. Команда трудилась над этим проектом несколько лет.

Чем примечательно их решение, как оно устроено, и кто еще передавал системы распределения нагрузки в open source, рассказываем далее.

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

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

Эти скрипты со-временем совершенствуются, убираются баги, оптимизируются. Поэтому появляется вопрос, как синхронизировать новые версии скриптов с теми, которые в проектах.

Тут есть несколько вариантов:

Первый вариант:

Создать один репозиторий и поместить туда все скрипты. Затем этот репозиторий подключается как подмодуль к проекту и используется.

Минусы:

1. в проект копируются все скрипты включая ненужные.
2. подмодуль не commit-ится в репозиторий проекта, поэтому если будет недоступен удаленный репозиторий подмодуля, то мы не сможет выкачать проект целиком.

Второй вариант:

Каждый скрипт отдельно хранить на Github gist и подключать нужные как подмодули
Минус тот-же, что и в первом варианте во втором пункте.

Третий вариант:

Использовать Git Subtree.

(Данное решение является альтернативой для Git submodules)

Юля: Так, кто вчера менял мою процедуру?
Лёша: не я
Максим: не я
— Ребят, может Git заведём ?
Серёжа: давно пора!
прошло 2 недели…

Юля: ребяяят?
— Юль, а ты не коммитила?
Юля: damn нет(…

Вот так всё и началось. Ну а что, каждый символ и каждую строчку коммитить?

А может всё это будет происходить само?) На этом моменте в голову начинают приходить
DDL-триггеры, Temporal table и картина складывается. Решено, будем хранить версии внутри
SQL Server'a !)

Всем привет!

Хочу представить вашему вниманию небольшую разработку — Box-shadows Device (#bSd).
Это инструмент, который чем-то напоминает конструктор или css редактор. В нем вы можете создавать девайсы на любой вкус и кошелек.

Сегодня Mislav Marohnić объявил о том, что разработчики Github избавились от jQuery на фронтенде GitHub.com. Казалось бы, в самом этом факте нет ничего примечательного, если бы не один интересный момент.

Проблема выбора нового фреймворка для фронтенда была решена радикально — решено было обойтись без фреймворков в принципе. Вместо них были использованы следующие средства:

• querySelectorAll (который предположительно был вдохновлен когда-то именно jQuery),
• fetch для работы с AJAX,
• delegated-events для обработки событий,
• полифиллы для работы с DOM,
• пользовательские элементы (Custom Elements), которые сейчас на подъеме.

Помимо Custom Elements, ничего другого из Web Components было решено не использовать. Разработчики присматривались к Shadow DOM и были бы не против прибегнуть к нему — однако, в силу того, что на полифиллах скорость поиска в DOM оставляет желать лучшего, им пришлось пока отложить эту затею.

Зачем разработчикам в принципе потребовалось все это сделать? По их словам, для того, чтобы «отдавать» посетителям меньше килобайт, иметь возможность использовать более явно выраженный синтаксис для выполнения манипуляций с DOM, а также ради возможности использовать библиотеку Flow.JS для статического анализа типов. По словам разработчиков, процесс ухода с jQuery занял годы.

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

В Твиттере какое-то время назад запостили шутку в честь приобретения Майкрософтом ГитХаба — страницу сайта, перестилизованную в стиле Windows 98. Я решил, что шутка слишком хороша, чтобы оставаться шуткой.

Всем привет!

В современном дизайне, при создании сайтов и приложений, многие разработчики применяют эффект глубины и объема, нередко обращаясь к таким css свойствам как box-shadow и drop-shadow. Некоторые считают, что в 2018 году это тренд. И действительно, немало как иностранных, так и российских сайтов, которые в 2018 году стали чаще применять тени.

Это всё же случилось. Недавние сливы оказались правдой.

Факт продажи официально подтвердили в своих блогах и GitHub, и Microsoft.

Привет всем!

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



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

На днях журналисты издания Business Insider получили из неофициальных источников информацию о том, что корпорация Microsoft ведет переговоры с сервисом GitHub о его возможной покупке. О какой сумме идет речь — неизвестно, но еще в 2015 году GitHub оценили примерно в $2 млрд. Тогда инвестфонд Sequoia Capital вложил в стартап около $250 млн. В настоящее время ценник GitHub может быть гораздо выше и составлять $5 млрд или больше. Готова ли Microsoft заплатить такую цену? Пока неясно.

В августе экс-CEO компании Крис Ванстрах заявил, что компания получает ежегодный доход в размере около $200 млн. Финансовые дела компании обстоят вполне неплохо, она продолжает развиваться.

Задача

Есть приложение, сгенерированное с помощью create-react-app. Нужно развернуть его на github.io.

Проблемой является то, что Github Pages работает только со статическим кодом и Jekyll.

Я 10 лет разрабатываю ПО, участвовал в нескольких open source-проектах и в многочисленных не-open source-проектах, работал в больших и малых командах, и везде мы использовали Github в качестве репозитория версионирования.

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

В данной статье хотелось бы рассказать про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений на платформах InterSystems.

Рассмотрим такие темы как:

• Git 101
• Методологии разработки (Git flow)
  
  • GitHub flow
  • GitLab flow
• GitLab
• GitLab CI

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



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

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

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

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

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

В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.