GitHub *

Вы уже слышали о новом подходе JAMstack? Возможность писать веб-приложения на любимом фреймворке, управлять контентом из админ панели, а на выходе получать полностью валидные HTML-страницы построенные согласно с самыми последними рекомендациями SEO, PWA и a11y.

Интересно? Тогда вот список рассматриваемых вопросов в этой статье:

• Что это за новый стек и зачем он нужен?
• Как запустить базовое приложение используя Gatsby?
• Работа с Contentful и создание первой порции данных
• Как связать Contentful и Gatsby используя GraphQL?
• Настроить автоматический деплоймент используя Netlify

(с)

Гитхаб — это не просто площадка для хостинга и совместной разработки IT-проектов, но и огромная база знаний, составленная сотнями экспертов. К счастью, сервис предоставляет не просто инструменты для работы с открытым исходным кодом, но и качественные материалы для обучения. Мы выбрали некоторые популярные репозитории и отсортировали их по количеству звезд в порядке убывания.

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

От переводчика: публикуем для вас статью Даррена Барнса, который делится своим опытом работы с GitHub. Его советы будут полезны, в первую очередь, новичкам. Возможно, и опытный кодер найдет что-то для себя.

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

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

По работе приходится участвовать в разных проектах, поэтому я хорошо знаю, как работают все мои коллеги. Помню, что компания начала использовать Git буквально за пару недель до моего прихода. На мониторах разработчиков кругом висели наклейки с напоминанием: сначала add, потом коммит, затем пуш.


Они не знали, зачем. Программистам просто сказали строго следовать инструкции, иначе беда. Но проблемы возникали так часто, что я решила провести семинар по Git.

Сегодня мы анонсируем два важных нововведения на GitHub, которые сделают его более доступным для разработчиков: неограниченные бесплатные приватные репозитории и более удобный продукт для компаний. Подробности под катом!

Эта новость опубликована на The Next Web, с пометкой:

"Из-за ошибок в планировании, мы опубликовали эту новость на день раньше снятия эмбарго на разглашение. Фича всё ещё не запущена, о ней официально расскажут завтра. Когда это произойдёт, мы обновим пост новым официальным анонсом".

А ещё есть вот такой замечательный тред в Twitter:

Ясно, что человек писал это дрожащими руками — точно так же, как я сейчас пишу дрожащими руками этот перевод.

Фейк ли это? Нет. Есть и официальное подтверждение в твиттере GitHub, так что — назад дороги нет.

Фичу явно выкатывали на спех, до сих пор на сайте не поправлена часть текстов, касающихся тарифов, а попытка даунгрейднуть план встречает таким вот опасно выглядящим сообщением:

В общем, запасаемся попкорном, скрещиваем пальцы на ногах и ждём годноты!

В канун празднования нового 2019 года команда PVS-Studio решила сделать приятный подарок всем контрибьюторам open-source проектов, хостящихся на GitHub, GitLab или Bitbucket. Им предоставляется возможность бесплатного использования статического анализатора PVS-Studio для развития открытых проектов.

«Умные разработчики любят работать с умным кодом. Открывая качественные исходники, вы привлекаете талантов»


Иллюстрация Kevin Ma

«Вы знаете о проектах Facebook с открытым исходным кодом?»

Такой вопрос задал инженерам Джеймс Пирс, бывший директор программы по открытым исходным кодам Facebook. Он изучал причины, почему те пришли в компанию. Согласно его презентации на O'Reilly's Open Source Convention, две трети инженеров Facebook знали об этой программе до прихода в компанию, а половина сказали, что это «положительно повлияло на их решение работать в Facebook».

GitHub – крупнейшая библиотека, созданная разработчиками для разработчиков. Главная прелесть хостинга в его идеологии: отдавать также легко, как и получать. Здесь можно найти самые разные IT-проекты как легальные, так и не совсем. Пользуясь открытостью, кто-то роется в исходниках в корыстных целях – чтобы потом использовать их уязвимости для банального шантажа, а кто-то с помощью репозиториев прокачивает свои профессиональные скилы. Давайте разберемся, как не закопаться в миллионах источников и какие перки можно заполучить.

То, что знания не принадлежат лишь узкому кругу избранных, уже признают и транснациональные корпорации. На основе одного исходного кода вырастает несколько новых – так и развиваются технологии, которыми в итоге начинает пользоваться весь мир. Такие гиганты, как Apple, Google, Facebook, Microsoft – разместили и продолжают постоянно обновлять свои репозитории на GitHub. Да что уж, если даже Министерство обороны США заводит хранилище на хостинге https://github.com/Code-dot-mil/code.mil с лозунгом «Помогите нам стать лучше». И каждое новое предложенное полезное решение – это очередной выученный урок в карьере разработчика.

Формат open-source проектов хорош тем, что позволяет участникам общаться также, как мы делаем это в социальных сетях. Помните про принцип соревновательности! К примеру, некто постит вариант реализации идеи. Другие участники, на интересе, либо желая покуражиться предлагают хаки. В итоге – сообщество плюсует авторам лучших решений.

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

Предлагаю вниманию прототип статьи под названием «Бесплатный PVS-Studio для всех, кто развивает открытые проекты на GitHub». Прошу подойти к данной теме конструктивно и высказывать предложения и критику по делу. Интересно мнение, насколько предложенный вариант разумен и удобен? Что можно улучшить? Какие дополнительные ограничения можно добавить? Кто бы из вас воспользовался/не воспользовался и почему?

Ещё раз подчеркну, что статья является пробной и имеет своей целью организовать дискуссию. Если Вы наткнулись на этот пост в 2019 году, то просим перейти к новой версии статьи.

Еженедельно из репозитория NPM загружается более 1,9 миллионов копий библиотеки EventStream. Она используется во многих крупных проектах для простой и удобной работы с потоками в Node.JS. Среди прочих, эта библиотека обрабатывает потоки и в популярном криптокошельке Copay (впрочем, об этом позже).

21 ноября 2018 года случилось странное. GitHub-пользователь @FallingSnow сообщил, что в одной из зависимостей event-stream спрятан вредоносный код, который фактически представляет собой бэкдор неизвестной функциональности.

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

Последние пару недель были непростыми для нашей команды. Выпускали OpenCV 4, а вместе с ним готовились к Intel's OpenVINO toolkit R4, в состав которого входит OpenCV. Думаешь, отвлекусь на время, посмотрю, как обычно, форумы про OpenCV, да комментарии пользователей, и тут на тебе, модно стало говорить что OpenCV не IoT, что под Raspberry Pi собрать — припоя не хватает, что на ночь make -j2 ставить — утром будет готово, если повезёт.

Поэтому предлагаю дружно взяться за руки и посмотреть, как же можно собирать библиотеку OpenCV для 32-битной операционной системы, исполняемой на ARM процессоре, используя ресурсы машины с 64-битной OS, движимой отличной архитектурой CPU. Колдовство Кросс-компиляция, не иначе!

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

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

Большинство разработчиков знают и любят github pages. На случай, если вы не встречались с ними — этот сервис даёт возможность создать статический сайт из вашего репозитория, который будет доступен на домене smth.github.io. Это безумно удобно для всякой временной статики, документации, небольших простых сайтов и так далее. Не приходится думать о каком-то дополнительном веб сервере.

Так же там есть возможность привязать к репозиторию свой домен — тогда всё будет совсем красиво. Даже поддержка SSL есть.

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

Оптическое распознавание символов (OCR) — это процесс получения печатных текстов в оцифрованном формате. Если вы прочитали классический роман на цифровом устройстве или попросили врача поднять старые медицинские записи через компьютерную систему больницы, вы, вероятно, воспользовались OCR.

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

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

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

Для обучения использовалось 144 картинки. Размер может быть разным, но желательно должен быть в пределах разумного. Картинки должны иметь формат PNG. После считывании изображения используется бинаризация – процесс преобразования цветного изображения в черно-белое, то есть каждый пиксель нормализуется в диапазон от 0 до 255, где 0 – это черный, 255 – белый.

Чтобы обучить сверточную сеть, нужно больше изображений, чем имеется. Было принято решение разделить изображения на части. Так как обучающая выборка состоит из картинок разного размера, каждое изображение было сжато до 448х448 пикселей. В результате получилось 144 изображения в разрешении 448х448 пикселей. После чего все они были нарезаны на неперекрывающиеся окна размером 112x112 пикселей.

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

Целью настоящей работы является практическое изучение средства управления поддеревьями Git.

Начиная с ревизии 1.7.11 upstream-репозиторий Git, в каталоге contrib/subtree, содержит средство автоматизации работы с поддеревьями.

Сервис git-subtree(1) фактически является полезной надстройкой, использующей функции git-read-tree(1) и git-write-tree(1). Поэтому ссылки в командах git-subtree(1) add/pull/push:

  git subtree add --prefix=<subdir> <remote> <ref>

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

Кроме того, если заранее добавить удаленный репозиторий в конфигурационный файл локального репозитория .git/config, с помошью команды:

bash-4.4$ git remote add build-system ../../remote/build-system.git

где build-system является именем удаленного репозитория ../../remote/build-system.git, то в дальнейшем, при использовании команд git-subtree(1) add/pull/push, мы сможем ссылаться на upstream-репозиторий remote/build-system.git по имени.

На данный момент git-subtree(1) практически не развивается, а лишь поддерживается в актуальном состоянии для текущей степени развития проекта Git.

Однако git-subtree(1) является наиболее популярным и мощным средством работы с поддеревьями.

Покупка корпорацией Microsoft сервиса GitHub полностью завершена. Недавно новый CEO GitHub, Nat Friedman, поделился вступительным анонсом, который мы выкладываем здесь. Подробности о будущем сервиса под катом.

Проект git-subrepo существует достаточно давно, однако упоминаний о нем незаслуженно мало. Автором git-subrepo является Ingy döt Net.

Если посмотреть на историю комитов master-ветки проекта, то может показаться, что проект остановился в развитии 2 года назад. Однако работы над проектом ведутся и хочется надеяться, что скоро будет выпущена версия 0.4.0.

Важным свойством данного средства является то, что на стороне пользователя нет необходимости устанавливать git-subrepo до тех пор, пока пользователь не решит делать комиты в upstream-репозитории подпроектов. Кроме того, пользователь получает полностью готовое и настроенное дерево исходного кода в момент копирования основного репозитория посредством стандартной команды git-clone(1).

Роковые 43 секунды, которые вызвали суточную деградацию сервиса

На прошлой неделе в GitHub произошёл инцидент, который привёл к деградации сервиса на 24 часа и 11 минут. Инцидент затронул не всю платформу, а только несколько внутренних систем, что привело к отображению устаревшей и непоследовательной информации. В конечном счете данные пользователей не были потеряны, но ручная сверка нескольких секунд записи в БД выполняется до сих пор. На протяжении почти всего сбоя GitHub также не мог обрабатывать вебхуки, создавать и публиковать сайты GitHub Pages.

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

Все мы давным давно хотим нормальную инкапсуляцию в JS, которую можно было бы использовать без лишних телодвижений. А ещё мы хотим удобные конструкции для объявления свойств класса. И, напоследок, мы хотим что бы все эти фичи в языке появились так, что бы не сломать уже существующие приложения.

Казалось бы, вот оно счастье: class-fields-proposal, который спустя долгие годы мучений коммитета tc39 таки добрался до stage 3 и даже получил реализацию в хроме.

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