Как всем известно, люди делятся на две категории:
1. Те, кто любит отправлять голосовые сообщения
2. Те, кто кто надеются, что для первых приготовлен отдельный котел
Но мы здесь не для того чтобы осуждать какую-то из этих категорий. Читать сообщения я люблю больше, чем слушать и здесь я расскажу, как я попробовал решить для себя эту проблему.
Эта секция написана уже после статьи, чтобы читатель посмотрел, а надо ли ему что-то отсюда или нет, но это забавное приключение, как всегда.
Что будет ниже:
• Поиск open source решения для общения голосом, шаринга экрана, включения видео и чатов в режиме peer-to-peer, без лишних бекендов
• Запуск этого решения в открытую в github pages
• Заворачивание этого решения на приватный сервер
• Простенькое закрытие доступа туды через basic http auth
• Заключение с описанием некоторых замечаний и потенцевальных возможностей
Привет. Гоу разберем почему вам может быть полезно вносить вклад в сообщество программистов. Речь пойдет про запросы на внесение изменений через форк проекта.
Привет, Хабр!
Это исследователи из NSS Lab ИТМО и создатели сообщества ITMO.OpenSource. Мы считаем, что важно делать не просто науку, а открытую науку, результатами которой можно легко воспользоваться. Поэтому пишем об открытом коде, проводим митапы «Scientific Open Source» и разрабатываем научные решения с открытым кодом. Эта статья написана на материале исследования, которое мы презентовали на последнем митапе. В ней поговорим об открытом научном коде, посмотрим, как с ним обстоят дела в разных организациях, и поделимся подборкой репозиториев, которые могут решать различные научные задачи.
Довольное большое количество собеседующих заглядывает на гитхаб. Первые хотят убедиться, что у вас есть в наличии хоть какой‑то написанный вами надеюсь код. Вторые хотят побольше в этот код повникать, чтобы посильнее вас потеребонькать на техническом собеседовании. Уже не знаю для чего… для поднятия собственного это, может быть. Или может хотят сбить с вас спесь вместе с денежными запросами) Хотя последняя категория собеседующих на моей практике попадалась всего два раза:
Hola, Amigos! На связи Артем Салеев, технический директор и Арсений Захаров, frontend-разработчик агентства продуктовой разработки Amiga. Сегодня расскажем, как мы реализовали задачу для крупного заказчика: разместить на сайте «размытые» картинки, которые бы разблюривались по пользовательскому взаимодействию.
Глубину осознания библиотеки можно проверить, написав её самостоятельно. Возможно, новорожденное решение будет ограниченным и не найдёт свою аудиторию, но оно навеки принадлежит автору и подтверждает реальное понимание работы технологии.
Так произошло и со мной. Я решил написать полноценный функционал для работы с зависимостями и, так как я Android-разработчик, адаптировать для работы в привычной среде для моих привычных задач.
Делюсь написанным — вдруг вам это поможет прокачать технические скиллы и создать собственную библиотеку.
Снова рад приветствовать всех читателей статьи! Продолжаю рубрику "Без про-v-ода" в которой я рассказываю про беспроводные технологии, сети, устройства, их эксплуатацию и тестирование на безопасность. Сегодня хочу рассмотреть с вами так же некоторые инструменты для тестирования на безопасность, а так же любопытный инструмент против любителей халявы.
Дисклеймер: Все данные, предоставленные в данной статье, взяты из открытых источников, не призывают к действию и являются только лишь данными для ознакомления, и изучения механизмов используемых технологий.
Наверняка вы создавали open source проекты и выкладывали их на GitHub, но я уверен, что очень немногие из вас создавали документацию для этих проектов. В этой статье я расскажу, как создавать и публиковать доки максимально просто.
Документация будет создаваться на основе исходного кода, она будет обновляться при каждом коммите и при этом будет доступна через интернет. Документирование происходит через Doxygen, в качестве хостинга выступает GitHub, а за обновление документации отвечает GitHub Pages.
Я работаю над созданием 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?
Снова рад приветствовать всех подписчиков и читателей! Сегодня хочу представить вашему вниманию несколько инструментов OSINT подходящих для сканирования сети и сбора информации об организациях. В этой статье подробно разберём установку, настройку и использование каждого инструмента, так же разберём случаи для чего эти инструменты нам могут пригодиться.
Дисклеймер: Все данные, предоставленные в данной статье, взяты из открытых источников, не призывают к действию и являются только лишь данными для ознакомления, и изучения механизмов используемых технологий.
Привет, Хабр!
Хочу поделиться своими мыслями и опытом («сыном ошибок трудных») в организации своей базы знаний, регулярно приобретаемых после прочтения разных книг, статей, просмотра видосов, прохождения курсов и прочих самообразовательных активностей.
Начнем с краткой предыстории, потом опишу сам подход в целом, далее пробежимся по нескольким вариантам реализации и в конце остановимся на том, что для меня оказалось самым оптимальным.
Первый раз столкнулись с Git и не понимаете, что это такое?
Устали бездумно выполнять серию комманд чтобы закинуть свой проект на GitHub?
Хотите понять, чем отличается merge, rebase, push и pull?
Надоело видеть ошибку о non fast-forward merge и не понимать, что с этим делать?
Сейчас попробуем разобраться в этом всем.
Привет! Я всегда мечтала, чтобы в инструментах для работы с командной строкой заранее сообщалось, насколько популярны те или иные конфигурационные опции, предусмотренные в них, например:
o «В принципе, никто этим не пользуется»
o «Этой опцией пользуется 80% аудитории, стоит ознакомиться»
o «У этой опции предусмотрено 6 возможных значений, но в реальной практике применяется всего 2 из них».
Так что я решила спросить пользователей Mastodon, какие у них любимые опции конфигурации git:
А какие опции git config вы больше всего любите выставлять? В настоящее время у меня в ~/.gitconfig установлены только git config push.autosetupremote true и git config init.defaultBranch main, вот интересуюсь, а что выставляют другие люди.
Как обычно, получила КУЧУ отличных откликов и так узнала множество очень популярных опций конфигурации git, о которых ранее никогда не слышала.
Далее перечислю их по порядку, при этом (очень примерно) попытаюсь начать с наиболее популярных.
Все описанные опции документированы на странице man git-config, а также на этой странице.
Автор оригинала Скотт Чакон — сооснователь GitHub и основатель нового клиента GitButler. Этот клиент ставит во главу угла рабочий процесс и удобство разработки, в том числе код-ревью, и не является просто очередной обёрткой над CLI git.
Вам хочется использовать ванильный Git, чтобы управлять репозиторием с объёмом 300 ГБ в 3,5 млн файлов, которые без проблем получают пуш каждые 20 секунд от 4000 разработчиков? Тогда читайте дальше!
Вот агенда блога — наша блогенда:
Введение
Приветствую дорогих читателей канала, наверняка в жизни случались у многих такие ситуации в которых очень бы хотелось обеспечить безопасность личных данных от посторонних глаз, или же как-либо скрыто передать информацию таким образом, чтобы никто и не догадывался о факте того, что вы впринципе передали какую-то важную информацию. Поэтому сегодня хочу представить вашему вниманию несколько интересных инструментов для шифрования и сокрытия информации с открытым исходным кодом.
Год назад в нашей команде решили внедрить средства анализа пулл-реквестов, т.к. некоторые разработчики уделяли мало времени код ревью, в итоге фичи долго не могли оказаться на проде. Выбрали решение на основе Github Action, начали собирать статистику, улучшать процессы, но и столкнулись с ограничениями.
Ну а там, где есть недостатки, можно сделать своё веб-приложение, пара недель разработки на Ruby on Rails и минимальный набор функций был реализован в PullKeeper'е. Спустя год доработок функционал приложения значительно улучшился, появились первые сторонние компании, которые стали его использовать и анализировать свои пулл-реквесты.
Сегодня всё чаще требуется учитывать географическую привязку и выполнять поиск в локальном окружении клиента. Иными словами, регулярно возникает необходимость найти что-то (или кого-то) рядом с конкретным пользователем. «Где ближайший банкомат?», «Кто из друзей поблизости?», «Какие тут аптеки?». Подобные запросы миллионами поступают в сервисы геолокации каждый день, при этом существующие подходы к решению этой задачи не исчерпали возможностей оптимизации. Наверняка вы не раз сетовали на то, как долго обновляются метки на карте.
В этой статье эксперт отдела перспективных исследований российской компании «Криптонит» Игорь Нетай рассказывает о способе ускорить обнаружение объектов, принадлежащих одному географическому региону с произвольно заданными размерами. Материал станет частью научной работы о перспективах применения H-кривых в геохешинге.
С помощью рассмотренной в этой статье алгоритмической оптимизации можно быстрее выполнять поиск в различных масштабах — от полушария Земли до конкретного здания.
Координаты одной строкой
Удобство географической персонализации постепенно вытеснило паранойю, и во многих онлайн-сервисах теперь открыто используются данные о местоположении пользователей и различных объектов. Делаете заказ через интернет? Вам предложат забрать его в пункте выдачи поближе к дому. Вызываете такси? Сначала запрос передаётся водителям рядом с вами. Ищете кафе? На карте отобразятся ближайшие.
Все эти алгоритмы сводятся к решению одной и той же задачи: они определяют, какие координатные точки из базы данных входят в тот же условно заданный регион, что и указанная в запросе целевая точка (как правило, обозначающая местоположение пользователя). Для этого используется система кодирования географических координат в виде значений хеш-функции, называемых геохеши.
Данное приложение было создано для красивого и удобного показа изменений во Vue 3 проекте в его документации на VitePress. После оно было сделано универсальным, и может быть подключено в любой HTML странице как Web component или микрофронтенд.
Попробовать - https://vuesence.github.io/release-timeline/. Слева вверху можно указать любой публичный репозиторий.
