Веб-сервис для хостинга и разработки IT-проектов
Как всем известно, люди делятся на две категории:
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?
Привет, Хабр!
Хочу поделиться своими мыслями и опытом («сыном ошибок трудных») в организации своей базы знаний, регулярно приобретаемых после прочтения разных книг, статей, просмотра видосов, прохождения курсов и прочих самообразовательных активностей.
Начнем с краткой предыстории, потом опишу сам подход в целом, далее пробежимся по нескольким вариантам реализации и в конце остановимся на том, что для меня оказалось самым оптимальным.
Первый раз столкнулись с 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 разработчиков? Тогда читайте дальше!
Вот агенда блога — наша блогенда:
Сегодня всё чаще требуется учитывать географическую привязку и выполнять поиск в локальном окружении клиента. Иными словами, регулярно возникает необходимость найти что-то (или кого-то) рядом с конкретным пользователем. «Где ближайший банкомат?», «Кто из друзей поблизости?», «Какие тут аптеки?». Подобные запросы миллионами поступают в сервисы геолокации каждый день, при этом существующие подходы к решению этой задачи не исчерпали возможностей оптимизации. Наверняка вы не раз сетовали на то, как долго обновляются метки на карте.
В этой статье эксперт отдела перспективных исследований российской компании «Криптонит» Игорь Нетай рассказывает о способе ускорить обнаружение объектов, принадлежащих одному географическому региону с произвольно заданными размерами. Материал станет частью научной работы о перспективах применения H-кривых в геохешинге.
С помощью рассмотренной в этой статье алгоритмической оптимизации можно быстрее выполнять поиск в различных масштабах — от полушария Земли до конкретного здания.
Координаты одной строкой
Удобство географической персонализации постепенно вытеснило паранойю, и во многих онлайн-сервисах теперь открыто используются данные о местоположении пользователей и различных объектов. Делаете заказ через интернет? Вам предложат забрать его в пункте выдачи поближе к дому. Вызываете такси? Сначала запрос передаётся водителям рядом с вами. Ищете кафе? На карте отобразятся ближайшие.
Все эти алгоритмы сводятся к решению одной и той же задачи: они определяют, какие координатные точки из базы данных входят в тот же условно заданный регион, что и указанная в запросе целевая точка (как правило, обозначающая местоположение пользователя). Для этого используется система кодирования географических координат в виде значений хеш-функции, называемых геохеши.
Предисловие
Простой python-cкрипт для парсинга спортивной статистики по баскетболу с популярного сайта
Как-то я столкнулся с довольно тривиальной, но новой для себя задачей - оптического распознавания символов (OCR). Так сложилось, что готовые инструменты (типа tesseract-ocr) мне не подошли, поэтому пришлось изобретать велосипед. Но к этому процессу я решил подойти со всей отвественностью: проверить несколько подходов, определить их примущества, недостатки и выбрать наиболее подходящий для конкретной задачи. По итогу это мини-исследование вылилось в данную обзорную статью. Здесь я хочу привести примеры нейросетевых моделей, характерных для различных этапов становления области компьютерного зрения (далее - CV) в том виде, в котором мы его знаем сейчас.
Привет, Хабр! На связи технический директор MTC RED Денис Макрушин и команда Advanced Research Team: Павел Гусь, Иван Бессарабов и Андрей Сомсиков.
В январе разработчики GitLab нашли в своей системе две критические уязвимости. Из-за ошибок в верификации злоумышленники могут захватывать учётки пользователей и менять содержимое репозиториев. Такой тип атак называется RepoJacking. Мы изучили другой хостинг кода — GitHub — и нашли 1 300 потенциально уязвимых открытых репозиториев. Чем это опасно для разработчиков и их проектов — под катом.
Когда-то давно меня попросили разработать модель динамики полета АСП (авиационного средства поражения) в отечественном ПО, в среде SimInTech, причем разработать не с нуля, а тупо повторив уже созданную ранее модель в Матлабе (с Симулинком), и любезно выложенную в публичный доступ на гитхабе.
Я подумал - почему бы и нет, ведь в Симинтеке есть практически все требуемые блоки, а каких нет, я доработаю по образу и подобию. Без погружения в детали, в конце концов так оно и вышло. Но мне справедливо возразили - а чем докажешь, что твоя модель считает в точности так же, в динамике, как и исходная матлабовская модель?
Всем привет! Этой мой первый пост на Habr (да и вообще где либо, за исключением GitHub). Хочу поделиться работой, на реализацию который у меня ушло около месяца, но тем не менее сейчас используя ежедневно и планирую развивать в дальнейшем. Задумка была таковой, что бы донести любой (бесплатный) контент до телевизора используя под рукой только телефон, например, если я еду в метро или нет желания (вставать с дивана) и возможности подойти к компьютеру. На самом деле причина реализации сей творения чуть глубже и проще, под управление я передал дело подбора контента на повседневный вечер супруге. За источник контента отвечает трекер Кинозал, который, к слову, я использую уже 4 года и меня он устраивает во всем.
Иногда бывает так, что вы отправляете на проверку пул-реквест, который оказался существенно больше, чем вы ожидали. И у вас возникает вопрос:
«Какого же размера он должен быть? Бывает ли идеальный размер? Если бы теоретически можно было полностью его контролировать, то насколько большим его нужно делать?»
Вы гуглите, находите множество ресурсов, сайтов и статей наподобие этой, которые анализируют тему и делают примерно такой вывод:
«Слишком маленькое количество строк может не отображать полностью изменения, а чрезмерно большой PR может утомить проверяющих, что усложнит выявление проблем или написание осмысленного отзыва»
И хотя вы понимаете логику автора, в то же время осознаёте, то теоретический ответ может быть лишь смутным, что «серебряной пули» не существует. Как всегда, в жизни всё сложнее.
Однако моя статья будет немного о другом:
«Мы проанализируем PR примерно 30 тысяч разработчиков, чтобы проверить, как размер PR коррелирует с временем внедрения, полученными комментариями и отказами во внесении изменений, чтобы найти статистически наилучший размер и понять, что на него влияет.»
Пояснение: тем, кто экспериментирует с данными, особенно после прохождения курсов/обучения в сфере данных, приведённое выше может напомнить о фразе «Корреляция не означает причинно-следственной связи». Да, они будут абсолютно правы. Мы попытаемся рассмотреть под разными углами, как эта корреляция варьируется в зависимости от компании, разработчика и общего объёма коммитов кода, а также под другими углами, которые могут помочь нам понять, какие другие значения могут по каким-то причинам отвечать соответствующим паттернам. Однако это «всего лишь» числа и корреляции, они не объясняют своих причин, поэтому любые наши предположения о причинах, скорее, субъективны и не подтверждены научными исследованиями.
Сегодня мы затронем сторону, отличную от написания кода. Мы займемся оформлением и написанием документации, как правильно делать коммиты и как оформлять код.
Все, что вы увидите в данной статье, будет касаться прочитанных мною материалов и полученного опыта.
В мире разработки программного обеспечения правильное оформление документации играет ключевую роль в обеспечении ясности и понятности проекта. Особенно важным этапом в этом процессе является создание и поддержание README файлов в Git репозиториях. README файлы - это первое, что увидит разработчик, приступая к работе с проектом, и хорошо оформленная документация может значительно упростить процесс взаимодействия с кодом.
В данной статье мы рассмотрим ключевые аспекты оформления документации в Git репозитории, обсудим лучшие методики и практики для создания качественной документации. Независимо от того, являетесь ли вы опытным разработчиком или новичком в области Git, эта статья поможет вам создать четкую, структурированную и информативную документацию для вашего проекта. Погружайтесь в мир оформления документации, улучшайте ваши проекты и делитесь своими идеями с сообществом разработчиков Хабр!
Недавно в своих ежедневных чтениях я наткнулся на явление, о котором думал уже много лет: феномен утечки информации людей, использующих SSH. Этот тип утечки информации не является новым явлением. Я давно предупреждал об этой опасности своих друзей, использующих SSH, но мой голос услышали лишь несколько человек. Поэтому я решил дать пояснения по этому поводу, потому что я считаю, что необходимо понимать этот риск в ИТ-сообществе, особенно в нынешней ситуации. Я буду исходить из предположения, что у вас, дорогой читатель, есть опыт работы с SSH.