GitHub *

По мере распространения Go и Rust появляется всё больше программ, которые состоят из одного бинарника без каких-либо нестандартных зависимостей, и которые мы устанавливаем руками, скачивая релиз с GitHub: либо потому, что данного приложения ещё нет в вашем дистрибутиве, либо потому, что просто хочется всегда иметь актуальную версию, а не ждать, когда её затянут в дистрибутив.

Ставить (а особенно обновлять) такие приложения руками – занятие неблагодарное, особенно когда их количество становится больше одного-двух – и хочется какой-то автоматизации. У меня таких программ около десятка, и довольно долгое время я пользовался различными наколеночными скриптами вроде этого для поддержания их актуальности. Но bash-скрипт – это всё-таки как-то несерьёзно, и поэтому всегда хотелось чего-то более управляемого в виде нормального приложения. Найти что-то готовое, что удовлетворяло бы всем моим потребностям, мне сходу не удалось – поэтому некоторое время назад решил пойти моим излюбленным путём и написать своё приложение под эту конкретную задачу.

Привет, Хабр!

Несколько недель назад, в этом посте, мы представили CLI для Eppie — p2p почты с шифрованием и открытым протоколом. Сегодня мы хотим рассказать о GUI приложении, которое уже доступно на GitHub. Если вы читали нас раньше, можете пропустить введение и сразу перейти к разделу «Как пользоваться». Ну а все остальные, кто увлекается децентрализованными технологиями и думает о приватности данных, — поехали.

В жизни каждого программиста С++ рано или поздно возникает задача, которую кто-либо уже решил. Однако найти это решение бывает очень непросто в силу разных причин: оно недостаточно разрекламировано, либо имеет нечеткую документацию, или возникает проблема языкового барьера, ну, или поисковики просто плохо ищут).

Столкнувшись много раз подряд с тем, что найти что-то толковое довольно непросто, я решил попробовать распутать это узел и предложить для русскоязычных читателей свой справочник классных библиотек на С++. Я исходил из этого источника. Это очень многогранный и объемный список библиотек языка С++, но, скажем так, у меня были к нему вопросы. Потому я сделал перевод, затем значительно улучшил его в плане содержания (далее объясню, как, почему и зачем). На выходе получилось около 1000 библиотек. Как в сказке). Они, конечно, не покрывают все возможные задачи и предметные области, но поверьте, они затрагивают действительно многое.

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

Генерация видео теперь open source? Наконец-то я нашёл время, чтобы добавить генерацию видео из текста и изображений в свой open source проект Wunjo CE. В этой статье мы рассмотрим, как это работает, сравним его с похожими решениями, изучим основы подхода и его альтернативы.

Кратко: сохраняем лог git в файл и кидаем в браузер тут.

Привет Хабра. Год назад я писал о разных визуализаторах статистики git и своем велосипеде. За это время удалось внести много улучшений, в том числе существенно увеличить набор ачивок для программистов. Но настал творческий тупик и мне уже не хватает фантазии придумывать новые ачивки. Они должны быть смешные, с издевкой и легко переводиться на другие языки. Может у вас будут идеи?

Меня зовут Денис, я тимлид команды R&D в Naumen Service Management Platform.

Так как наш продукт написан в основном на Java, мы с большим нетерпением ждали очередной LTS релиз в прошлом году, предвкушая мощь виртуальных потоков и крутизну доработанного pattern matching.

В этой статье расскажу, с какими препятствиями на пути миграции систем на Java 21 столкнулась наша команда, что мы получили после обновления и стоит ли вообще обновляться.

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

Я работаю на VS Code, и я, to be honest, так и не понял, с какой стати .gitignore "не игнорирует" .env. Причем спокойно "игнорирует" другие файлы, директории.

Всё же, нужно действовать, исходя из конкретного кейса, но если вы не хотите, чтобы какой-нибудь John Doe воспользовался данными из вашего .env, то вы перешли по верной ссылке. Вы же не отдаете ключи грабителю с фразой "Грабьте мой дом", верно?

По мнению Артема Закируллина*, одна из фундаментальных проблем, с которой сталкиваются разработчики при анализе кода – высокая когнитивная нагрузка. Это не абстрактное, а реальное ограничение возможностей, которое стоит времени и денег. На чтение и понимание кода, тратится больше времени, чем на его написание. Поэтому, разработчику нужно постоянно задаваться вопросом: не пишет ли он код, чтение которого создает чрезмерную когнитивную нагрузку?

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

И это уже третья статья (первая и вторая) из цикла «Chrome Windows 7».

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

StarForce, DENUVO, VMProtect в Chrome?

Тетрадь, дневник — ваше лицо. А круто оформленный профиль на гитхабе — статус вашей занятости. Чем больше участий в проектах, тем безработнее... Пока молодые специалисты оформляют свои страницы с "Lib-Meta-Neo ML-Scientist 10 years of expirience" на LinkedIN настоящий амбассадор HR и трудового найма бегут на GitHub. Именно там выискиваются самые закостенелые гики программирования, вносящие тридцать пять тысяч коммитов в безбюджетные опенсорс проекты; именно там рождаются гении, разрабатывающие AAA-проекты геймдева на ассемблере. 

Все это шутки. 

Но реальность такова, что многие из рекрутеров не против оценить ваш профиль. Подавать себя, как в маркетинге, важно. И неплохо бы сразу представить всю статистику развернуто перед глазами, чтобы бедный HR не искал ваши коммиты, а гордо проведенные тысячи часов в GitHub не остались за кадром. Каждый проект служит материальным доказательством способностей разработчика, позволяя потенциальным соавторам или работодателям оценить его стиль программирования, навыки решения задач и умение управлять проектами. 

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

Привет, Хабр!

На связи Андрей из сообщества ITMO.OpenSource. Мы считаем, что важно делать открытую науку, поэтому пишем об открытом коде, проводим митапы «Scientific Open Source» и разрабатываем научные решения с открытым кодом.

Мы убеждены, что открытая наука – это не просто код на github, но и совокупность факторов, которые позволяют этим кодом эффективно воспользоваться: запустить, модифицировать, внедрить в другие проекты. Поэтому я решил перевести популярную статью JS-разработчицы Киры Окли «Art of README». Несмотря на разницу в экосистемах (я пишу преимущественно на Python), мне кажется, многие идеи этой статьи актуальны для любого проекта на любом языке.

В конце марта в блоге GitHub вышла статья, как защищаться от уязвимостей типа RepoJacking. В первых строчках автор советовал использовать пакетные менеджеры типа NPM и PyPI, чтобы киберугроза этого вида «не угрожала пользователю напрямую». Можно было бы вздохнуть с облегчением, но читатели Хабра уже знают об исследовании команды МТС RED ART, которое позволило найти более 1300 уязвимых для RepoJacking репозиториев.

Меня зовут Андрей Сомсиков, я — руководитель команды МТС RED ART. В этой статье — вторая часть нашего исследования уязвимых репозиториев на GitHub. Мы нашли уязвимости в популярных библиотеках: для разработки на Ruby, для электронных замков и даже для пользователей Reddit и Minecraft. Но не всё так страшно! В конце дам рекомендации от всей нашей команды по борьбе с уязвимостями в популярных хостингах кода.

Как всем известно, люди делятся на две категории:

1. Те, кто любит отправлять голосовые сообщения

2. Те, кто кто надеются, что для первых приготовлен отдельный котел

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

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

Что будет ниже:

• Поиск open source решения для общения голосом, шаринга экрана, включения видео и чатов в режиме peer-to-peer, без лишних бекендов
• Запуск этого решения в открытую в github pages
• Заворачивание этого решения на приватный сервер
• Простенькое закрытие доступа туды через basic http auth
• Заключение с описанием некоторых замечаний и потенцевальных возможностей

Привет, Хабр!

Это исследователи из NSS Lab ИТМО и создатели сообщества ITMO.OpenSource. Мы считаем, что важно делать не просто науку, а открытую науку, результатами которой можно легко воспользоваться. Поэтому пишем об открытом коде, проводим митапы «Scientific Open Source» и разрабатываем научные решения с открытым кодом. Эта статья написана на материале исследования, которое мы презентовали на последнем митапе. В ней поговорим об открытом научном коде, посмотрим, как с ним обстоят дела в разных организациях, и поделимся подборкой репозиториев, которые могут решать различные научные задачи.

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

Так произошло и со мной. Я решил написать полноценный функционал для работы с зависимостями и, так как я Android-разработчик, адаптировать для работы в привычной среде для моих привычных задач. 

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

Введение

Рад вновь приветствовать читателей в своей любимой рубрике "ШХ" что является сокращением от "Шерлок Холмс" и разумеется серия таких статей напрямую относится к OSINT. Сегодня на практике попробуем некоторые инструменты и попробуем узнать больше о человеке исходя из его никнейма. В качестве цели я возьму одно из своих имён "VI.......TE".

Дисклеймер: Все данные, предоставленные в данной статье, взяты из открытых источников, не призывают к действию и являются только лишь данными для ознакомления, и изучения механизмов используемых технологий.

Я работаю над созданием Graphite, источником вдохновения для которого стал внутренний инструментарий Facebook. Когда я решил создать стартап с друзьями, то никогда раньше не слышал о Mercurial, хотя всегда страстно любил инструменты разработчика. Мой предыдущий опыт разработки включал в себя личные проекты, домашнюю работу в колледже, разработку для iOS в Google и развитие инфраструктуры в Airbnb. На протяжении всей моей карьеры использование git было таким же естественным, как воздух. Он настолько популярен, что лично я считал его единственным подходящим инструментом для создания изменений в коде и управления ими.

Забавно, что специалист по Mercurial Грегори Gregory Szorc работал рядом со мной в Airbnb, хотя я знал его только как приятного коллегу, но не представлял, что он контрибьютор.

В 2021 году мои коллеги по команде Томас и Ник раскрыли мне глаза. Они пришли из Facebook и, к моему удивлению, едва знали Git. Зато они имели глубокое понимание паттернов Mercurial и рабочего процесса Facebook на основе «многослойных diff» (stacked diff). Со временем они убедили меня в полезности этого паттерна и мы развернули направление развития компании, чтобы реализовать многослойные diff для разработчиков GitHub.

Но пост посвящён не нашему стартапу. Он о важном вопросе, не дававшем мне покоя последние три года. Почему фейсбукеры не пользуются Git? Зачем они выбрали Mercurial и создали на его основе собственные рабочие процессы? Я знаю что Google не пользуется Git, но это логично, культура разработки Google возникла на пять лет раньше Git. Facebook же был основан примерно в то же время, что и создан Git, около 2004 года, и ко времени, когда Facebook начал серьёзно выбирать инструментарий для управления исходниками, Git был старше и популярнее Mercurial. Так почему же Facebook не использует Git?