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



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

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

Alyson La, Data science в GitHub: В октябре этого года я отпраздновала свой пятилетний юбилей работы в GitHub. 5 лет назад я была бухгалтером, который ничего не знал о программировании, не говоря уже об использовании Git и GitHub.

Теперь я энтузиаст Data Scientist, который знает некоторые вещи о написании кода с помощью Git & GitHub. Частично благодаря изучению этих технологий я сделала этот карьерный переход.

Но даже работая в GitHub, изучать Git и GitHub было сложно! Поэтому я хочу поделиться 5-ью советами по использованию GitHub с другими людьми, новичками программирования.

Совет № 1: Измените редактор по умолчанию

Для многих людей текстовый редактор при использовании Git через терминал — VIM. VIM может быть ужасным, страшным для нового или казуального хакера. Или даже для ветеранов-хакеров как @haacked.


Если вы когда-нибудь столкнетесь с конфликтами слияния (а вы их встретите, см. совет №4), вы попадете в VIM, чтобы исправить конфликт, и вам нужно будет знать конкретные команды VIM для редактирования документа иначе вам захочется плакать. Больше года у меня была заметка на мониторе для напоминания основных команд VIM, таких как i (для редактирования) и: wq (для сохранения и выхода). Чтобы избежать боли, вы можете просто выбрать другой текстовый редактор.

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

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

На просторах интернета можно найти множество описаний и примеров по созданию telegram bot-ов.Но Telegram Bot Api имеет ограниченный функционал. Для решения задачи по выгрузке сообщений из Telegram по ключевому слову необходимо использовать Telegram API. За основу была взята библиотека TLSharp. Стоит сразу прояснить, что дальнейшая работа возможна только для зарегистрированных пользователей в Telegram.

Стартом работы с API служит регистрация приложения:

1. Заходим на сайт Телеграмма и вводим свой номер телефона. Вводим код подтверждения.
   
   
2. Попадаем на страницу разработчика. Для завершения регистрации необходимо заполнить поля, характеризующие ваше будущее приложение.
   
   
3. Получаем api_id и api_hash.

Один из моих текущих проектов связан со сбором данных из 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…

Файлы КОМПАС-3D содержат информацию о документе: наименование и обозначение чертежа, фамилию разработчика, проверяющего и утверждающего, вид документа, формат, количество листов. Когда на предприятии используется система для автоматизации документооборота, проектировщику очень часто приходится вводить эту информацию вручную.


Добавление документа в систему документооборота (Карточка документа)

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

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

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

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

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

Из всех моих разговоров с коллегами о разных аспектах разработки программного обеспечения одна тема всплывает чаще других. Да что там «чаще» — она повторяется снова и снова, как заезженная пластинка — это беседы на тему того, чем плох GitFlow и почему его стоит избегать.

Статья "Удачная модель ветвления для Git" описывающая метод, получивший в последствии название «GitFlow» стала де-факто стандартом того, как нужно начинать использовать Git в вашем проекте. Если поискать в Google что-то типа "git branching strategy" то вот как раз этот метод будет описан по первой ссылке (а скорее всего и по нескольким следующим).

Лично я ненавижу GitFlow и за последние годы убедил много команд разработчиков перестать его использовать, чем, как мне кажется, сохранил им уйму времени и нервов. GitFlow заставляет команды организовывать управление изменениями кода хуже, чем оно может быть реализовано. Но поскольку это такой популярный метод (по крайней мере в результатах поисковика), то команды без достаточного опыта, которые ищут «что-то, хотя бы как-то работающее» находят именно его при быстром поиске, да ещё и видят слово «успешный» прямо в заголовке статьи с его описанием — ну и начинают бездумно использовать. Я хочу хотя бы немного изменить этот паттерн поведения, описав в этой статье более простую и не менее успешную стратегию использования веток Git, которую я внедрил во многих командах. Часто эти команды пробовали использовать GitFlow, но испытывали проблемы, которые, пропали с переходом на ThreeFlow.

Я называю эту стратегию ThreeFlow потому, что в ней есть ровно три ветки. Не четыре. Не две. Три.

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


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

История фреймворка React: как Фейсбук приобрел Инстаграм и почему это привело к открытию исходного кода React.js

Сегодня React — одна из самых популярных в мире библиотек JavaScript для пользовательского интерфейса: более 70 тыс. «звезд» на Гитхабе, не менее 1100 авторов и миллионы скачиваний каждый месяц — кроме того, этот фреймворк используется более чем в 4 тыс. компаний. Но когда Фейсбук впервые показал React миру, это мало кого обрадовало.

Мы решили погрузиться в историю рождения одной из самых популярных технологий в мире разработки ПО — React, и пригласили Пита Ханта (Pete Hunt), стоявшего у истоков этой библиотеки (сейчас он генеральный директор компании Smyte), чтобы он наконец-то рассказал о том, для чего создавали React, почему эта технология стала популярной в Фейсбуке после приобретения Инстаграма, и как она в итоге вышла в люди.

Основные моменты

От приложения Facebook Camera к приобретению Инстаграма

Марк (Цукерберг) собрал всех и говорит: «Мобильные устройства «выстрелят», поэтому срочно бросаем всё и переводим ресурсы на мобильные разработки». Мне казалось, это какая-то сумасшедшая идея: мы не могли поддерживать работу самого большого фотосайта в сети, имея горстку людей в команде. Совершенно бессмысленно переводить людей на разработку приложений для iOS и Android, которые составляют совсем небольшую долю нашего трафика. Но оказалось, что Марк был на 100% прав — поэтому я и не генеральный директор Фейсбука…

Мы разработали приложение Facebook Camera, и даже гордились тем, что получилось… Но пришел Инстаграм — и наш проект канул в Лету…

Ребятам из Инстаграма дали гараж на территории Фейсбука, где можно было сидеть и спокойно пилить свою идею. Они пользовались надежными системами безопасности Фейсбука, но кроме того продолжали использовать AWS, а еще — разрабатывали собственную стратегию продукта, насколько я могу судить… И я был первым сотрудником из Фейсбука, которого перевели в Инстаграм…

Переведено в Alconost