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

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

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

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

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

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

Введение

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

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

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

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

Разработчики из 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. Я решил, что шутка слишком хороша, чтобы оставаться шуткой.

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

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

Задача

Есть приложение, сгенерированное с помощью 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.

Меня зовут Крис Литтлбери, я работаю старшим испытателем систем безопасности от проникновений в компании Knowledge Consulting Group, которая расположена в округе Колумбия. Я люблю конструировать всякие интересные вещи, придавая обычным устройствам необычные функции. Например, вот этот контроллер XBox Live быстро обнаруживает пожар. Я использовал его всего один раз, скомбинировав с микропроцессором Arduino. На второй картинке показано устройство для замены пятой передачи в коробке передач моего автомобиля, которое улучшает пробег. Я люблю делать вещи своими руками.



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

Меня зовут Эрик Батлер, а это Карл Кошер, и мы хотим поговорить с Вами о чтении, создании, загрузке и использовании кода на SIM-картах. Этот проект стартовал в прошлом году, когда я узнал о мероприятии Tourcamp 2012, лагере хакеров на побережье штата Вашингтон, таком выездном DEFCON'е. Никаких отелей, жизнь в палатках на открытом воздухе, это был уже второй лагерь, первый мне очень понравился, я пригласил друзей и мы решили туда отправиться. Это мероприятие посвящалось запуску сети GSM в нескольких районах США, и моей задачей было добыть для этого несколько SIM-карт.



Я ничего не знал о том, что из себя представляют SIM-карты, поэтому мне пришлось изучить вопрос и выяснить следующее:

• SIM, или Subscriber Identification Module – это модуль идентификации абонента мобильной связи;
• на SIM-карте есть ключ идентификации IMSI и симметричный ключ Ki;
• в неё встроен модуль безопасности, который не позволяет ни извлечь, ни клонировать ключи;
• они используются операторами связи GSM, а в настоящее время и LTE (сеть Verizon стандарта 4G);
• могут также запускать приложения.

Последний пункт меня удивил, потому что никогда раньше не слышал, что сим-карты могут работать с приложениями. Оказывается, давным-давно, когда не было ни «айфонов», ни «андроидов», приложения располагались на сим-карте. Телефон был простой звонилкой – Вы могли вытащить из него «симку» и переставить в другой телефон вместе со всеми своими контактами, программами и так далее. Некоторые операторы, например, Telcom, являлись собственниками сим-карт, контролируя установленные на них приложения.

В этом выступлении речь пойдёт о штрих-кодах – одномерных и двухмерных баркодах, или матричных кодах. Кодировании, декодировании, некоторых уловках, вспомогательных вещах, неразрешенных проблемах. В отличие от одномерного линейного штрих-кода, где информация закодирована в последовательности и толщине вертикальных полосок, двухмерный баркод, или 2D-код содержит информацию и по вертикали, и по горизонтали.

Мой доклад состоит из следующих пунктов:

• быстрое введение в суть баркодов;
• кодировка и чтение баркодов;
• сканеры;
• простые трюки с баркодами;
• скрытые атаки;
• чтение выбранных образцов;
• нерешённые проблемы и вызовы;
• принципы безопасного использования баркода.

Баркод был придуман в 1948 году Сильвером и Вудландом из Технологического института Дрексель. Первая попытка использования баркода была предпринята в 1950 году – Ассоциация Американских Железных дорог решила использовать его для идентификации вагонов и потребовалось свыше 17 лет для того, чтоб пометить 95% составов и после система так и не заработала. В это время люди считали баркоды бесполезными.



Но уже в 1966 году Национальная Ассоциация продуктов питания предложила наносить баркоды на продукты, чтобы ускорить процесс их идентификации на кассе и заработать побольше денег. В 1969 году эта же Ассоциация создала промышленный стандарт Универсального Продуктового Идентификационного кода (позже UPC), который стал использоваться с 1970 года.

В 1981 году Министерство обороны США потребовало, чтобы все продукты, поставляемые для армии, маркировались Code 39 – штрихкодом, позволяющим кодировать большие латинские буквы, цифры и символы и Вы далее увидите, почему это было плохой идеей.

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

Одна из распространённых ошибок — попытка работодателя отфильтровать кандидатов по профилям GitHub. Многие по-прежнему думают, что можно оценить способности разработчика, взглянув на его вклад в проекты с открытым исходным кодом. Например, в последнем списке вакансий на Hacker News куча объявлений с просьбой указать профиль GitHub в своём заявлении о приёме на работу.

Есть несколько правильных статей, почему нельзя требовать от кандидатов профили GitHub. Особенно рекомендую «Этика неоплачиваемого труда и сообщество Open Source» и «Почему GitHub — не резюме». Обе статьи отлично объясняют причины, почему при найме не следует спрашивать о вкладе в свободные проекты. Но я не о том, что это неэтично или что GitHub не слишком подходит для демонстрации проектов.

Я о том, почему эти профили просто малополезны.

Разреженность данных

Если посмотрите публичный профиль лучшего инженера-программиста, с которым я когда-либо работал, то увидите примерно такое:

Привет! 6 февраля Telegram ввел возможность добавлять на свой сайт виджет для авторизации пользователя через его аккаунт в Telegram. Виджеты по виду реализации на сервере делятся на два вида — обработать данные пользователя «здесь и сейчас» в JavaScript или же перенаправить данные в параметрах URL на указанный адрес. Также саму кнопку можно настроить внешне: изменять размер, закругление углов, отключать и включать фотографию.

Материал — руководство по настройке авторизации пользователя через Telegram-аккаунт на вашем сайте с помощью пакета django-telegram-login.