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



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

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

Меня зовут Сэми Камкар, я исследую проблемы безопасности, но не профессионально, а ради собственного удовольствия, как и большинство здесь присутствующих. Я известен как «Narcissistic Vulnerability Pimp», или «сводник самовлюблённой уязвимости», являюсь автором вируса Samy Worm, созданным на MySpace несколько лет назад, и одним из основателей компании IP PBX Fonality. Меня также называют Chick Magnet, «магнитом для цыпочек», и я фанат Леди Гага. А ещё я люблю наличность.



На этом слайде Вы видите ребят, которые оказали мне большую услугу – они позволили мне вообще не прикасаться к компьютеру некоторое время. Несколько лет назад ко мне в дом ворвались представители USSS, United States Secret Service Electronic Crimes Task Forces, оперативной группы по расследованию киберпреступлений Секретной службы США. Они изъяли все мои компьютеры, забрали мой ноутбук, мобильник, проигрыватели CD и DVD-дисков и даже игровую приставку Xbox. Дело закончилось судом, который запретил мне пожизненно прикасаться к компьютерам, однако пару лет назад меня «разбанили», и теперь я снова с Вами, однако без доступа к MySpace.

Меня зовут Эрик Батлер, а это Карл Кошер, и мы хотим поговорить с Вами о чтении, создании, загрузке и использовании кода на 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.

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

На хабре публикуют перевод статей про участие в open source продуктах и складывается впечатление что жизнь, полная энтузиастов, где-то за границей. Что новичку страшно участвовать в крупных проектах, что у него обязательно должны быть там кураторы и его pull request вместе с ним точно пройдет через все круги ада.

Опыт друга, новичка в open source, говорит об обратном. Первый его pull request #11680 приняли в звездный spring-boot без обсуждения и без единого комментария от мейнтейнеров. Его исправления будут доступны уже в версии 2.0.0.RC1



Не боги горшки обжигают. Рассуждения о возможности стать контрибьютором крупного проекта на github…

Хотя большинство PHP-разработчиков умеют пользоваться Composer, не все делают это эффективно или лучшим возможным образом. Поэтому я решил собрать советы, которые важны для моей повседневной работы. Большинство из них опираются на принцип «От греха подальше»: если что-то можно сделать несколькими способами, то я выбираю наименее рискованный.

Увидев в очередной раз базворд GitFlow я психанул и решил перевести описание более простой и менее проблемной схемы работы с ветками под названием GitHub Flow. Именно её имеет смысл использовать по умолчанию, переходя к какой-то другой лишь в случае непреодолимых обстоятельств.

Создайте ветвь

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

Интересно верит ли кто-либо еще что работу разработчика можно измерить количеством строк кода? Попробуем вместе развенчать этот старый, как мир, миф своими красными глазами.


Сложно ли изменить две строчки кода?

В разделе trending на GitHub отображается список проектов, активно набирающих звезды в течение дня, недели или месяца. Все самое интересное, что появляется в open source для каждого языка программирования, всегда оказывается в этом списке. Сегодня хочу поделиться способом, как с помощью GitHub уведомлений подписаться на появление новых «звездных» проектов и не пропустить что-нибудь полезное для себя.

При разработке документации мы руководствуемся не только стандартами, но и удобством её использования. Стандарты определяют состав и форму документации, а формат строится исходя из удобства. Разработчик Сергей Бочаров рассказывает о пути Markdown-документа и о проблемах, которые приходится решать в обмен на простоту использования этого формата.

У меня иногда складывается впечатление, что не он служит для нас, а мы служим для этого формата. Поэтому — сэр Markdown.

В свободное и не свободное время[1] я развиваю несколько своих проектов на github, а также, по мере сил, участвую в жизни интересных для меня, как программиста, проектах.

Недавно один из коллег попросил консультацию: как выложить разработанную им библиотеку на github. Библиотека никак не связана с бизнес-логикой приложения компании, по сути это адаптер к некоему API, реализующему определённый стандарт. Помогая ему, я понял что вещи, интуитивно понятные и давно очевидные для меня, в этой области, совершенно неизвестны человеку делающему это впервые и далёкому от Open Source.

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

Так что из себя представляет стильный, модный, молодёжный Open Source проект в 201* году?

Если вы захотели воспользоваться публичным ресурсом вроде GitHub или GoogleDrive для хранения своего репозитория, но при этом не готовы делиться со всем миром результатами своего труда, то вам поможет шифрование файлов в гит-репозитории. Это не сверхсекретная технология и на эту тему есть некоторое количество небольших статей в интернете (и даже на Хабре), но все они являются вариацией куска документации git посвященного атрибутам и тему совершенно не раскрывают. Кроме этого, в процессе использования git в этом режиме появляются ньюансы использования, которые не всегда легко понять и решить и которые я в этой статье постараюсь осветить.

Hacktoberfest близко. Как перестать бояться и начать контрибьютить? С кем обсудить самые полезные открытые проекты? Если вы любите опенсорс так же, как и мы, то приходите в гости в наш московский офис 7 октября. Будет кодовикторина, общение с нашими ведущими разработчиками, много опенсорса, свободный микрофон для рассказов о проектах и Hack Time в отличной компании. Под катом — подробности про мероприятие и темы, которые мы обсудим.

Happy Hacktoberfest!

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

В последнее время все больше и больше компаний, таких как Google, Microsoft, JetBrains, выкладывают в открытый доступ исходный код как небольших, так и крупных проектов. Positive Technologies славится не только высококлассными специалистами по информационной безопасности, но и большим количеством профессиональных разработчиков. Это позволяет ей также вносить свой посильный вклад в развитие движения Open Source.

У PT есть следующие GitHub-организации, поддерживающие открытые проекты компании:

• Positive Technologies
• Open DevOps Community
• Positive Research
• Positive JS
• LibProtection

Некоторое время назад на отличной конференции maintainerati я пообщался с несколькими друзьями-мейнтейнерами о масштабировании по-настоящему больших проектов open source и о том, как GitHub подталкивает проекты к определённому способу масштабирования. У ядра Linux абсолютно иная модель, которую мейнтейнеры-пользователи GitHub не понимают. Думаю, стоит объяснить, почему и как она работает и чем отличается.

Ещё одной причиной для написания этого текста стала дискуссия на HN по поводу моего выступления «Мейнтейнеры не масштабируются», где самый популярный комментарий сводился к вопросу «Почему эти динозавры не используют современные средства разработки?». Несколько известных разработчиков ядра энергично защищали списки рассылки и предложение патчей через механизм, похожий на пулл-реквесты GitHub, Но по крайней мере несколько разработчиков графической подсистемы хотели бы использовать более современный инструментарий, который гораздо легче автоматизировать скриптами. Проблема в том, что GitHub не поддерживает тот способ, которым ядро Linux масштабируется на огромное число контрибуторов, и поэтому мы просто не можем перейти на него, даже для нескольких подсистем. И дело не в хостинге данных на Git, эта часть явно в порядке, а дело в том, как на GitHub работают пулл-реквесты, обсуждение багов и форки.