GitHub *

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

Jekyll — генератор статических сайтов. Это означает, что на вход ему даётся какая-либо информация, а на выходе получается набор HTML-страничек. Всё отлично когда сайт простой или даже одностраничный. Но что насчёт более сложных сайтов? Справится ли Jekyll? Будет ли удобно?

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

На первый взгляд, задача применения размерных ограничений к чертежу кажется не сложнее упражнения из школьного учебника. Точно так же показалось и мне, когда я впервые узнал о ней. В то время я работал в компании, которая занималась разработкой программного комплекса для проектирования индивидуальных жилых домов с подготовкой проектной документации "под ключ". В этом проекте я занимался разработкой алгоритма генерации многоскатных крыш, а впоследствии и всего геометрического ядра на основе Булевых операций, поэтому за дальнейшей историей я следил издалека. В какой-то определенный момент, заказчику захотелось, чтобы проектировщики могли просто указать размеры комнат, углы эркеров и ширину дверных проемов, а программа автоматически рассчитала бы все остальные параметры внешнего и внутреннего устройства дома. Эта мысль возникла у заказчика спонтанно, и поэтому срочно нужно было сделать “точно так же, как в CATIA”. Наш тимлид подошел к решению задачи с энтузиазмом и начал разрабатывать прототип. Он решал сотни уравнений в MathCAD, весь кабинет был завален графиками частных решений для двух, трех, четырех точек… Его изначальное предположение о том, что задачу можно решить аналитически, потерпело фиаско: на дворе был 2005, а это значило, что в интернете невозможно было найти хоть какую-то информацию по данной теме. В результате, после двух месяцев напряженных исследований, данную функциональность пришлось исключить.
Часть 1: Введение
Часть 2: Эскиз
Часть 3: Степени свободы и уравнения ограничений
Часть 4: «Неисповедимы пути Решателя» или «Червоточины Ньютона»

Недавно мы выпустили инструмент с открытым исходным кодом GraphQL Voyager. Удивительно, но он попал на первую страницу новостей Hacker News и GitHub, и в первые несколько дней получил 1000+ звезд. Сейчас у него уже более 1600 звезд.*

Людям понравился гладкий интерфейс, интерактивные функции и анимация. Мы использовали TypeScript, React, Redux, webpack и даже PostCSS, но это НЕ еще одна статья об этом. Давайте заглянем под капот...

22 мая компания GitHub объявила, что следующая версия их API будет использовать разработанную Facebook технологию под названием GraphQL.

В итоге GraphQL может прийти на смену самому популярному на сегодняшний день типу API — REST API.

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

Данная статья — инструкция по прикручиванию базовой непрерывной интеграции (build-test-deploy) к гитхабовским C/C++ проектам с CMake сборкой — по непонятным причинам, на Хабре такого до сих пор не проскальзывало. Впрочем, если моё гугл-фу подвело меня, и таки проскальзывало — не беда. Лишний туториал, описывающий всё под несколько другим углом и предостерегающий от неповторимого набора набитых автором шишек, совершенно точно не повредит.

Введение

Доброго времени суток, дорогой читатель. Я уже давно хотел написать статью на хабре и вот наконец-то этот момент настал. Из последних тем, которыми я занимался и о которых мне есть что рассказать — это была реализация SSO для одного сервиса. Хочу здесь сразу уточнить, что в принципе SSO через Facebook и Google уже было в сервисе до моего прихода. Моей же задачей было реализовать его через протокол SAML.

SSO (Single Sign-On), — технология единого входа пользователей, благодаря которой владея одной лишь учетной записью пользователь может посещать множество различных сервисов.

SAML — это популярный XML-протокол для реализации SSO. Как правило большие организации (enterprise) используют именно его, как проверенный и надежный вариант.

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

Что не так с Disqus?

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

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