
Хотите довести до дурки любимого преподавателя компьютерных наук или навсегда прослыть «особенным» среди коллег сразу после (немедленного) увольнения?
Читайте про патентованный метод.
Software Engineer, Bachelor of Computer Science
Хотите довести до дурки любимого преподавателя компьютерных наук или навсегда прослыть «особенным» среди коллег сразу после (немедленного) увольнения?
Читайте про патентованный метод.
Технология CORS и действующее в браузерах правило ограничения домена – те вещи, которые часто понимаются превратно. Ниже я объясню, что они собой представляют, и почему пора перестать волноваться по их поводу.
Замечание: я собираюсь рассказать о CORS и правиле ограничения домена как о единой сущности, поэтому далее часто буду употреблять эти термины как синонимы. Дело в том, что они, по сути – части одной системы, работают в сочетании друг с другом и помогают вам решать, что можно сделать с какими ресурсами смешанного происхождения. В принципе, если ваши запросы поступают из разных источников, то вам придётся иметь дело с правилами, политиками и механизмами CORS.
Прежде всего, отмечу, что CORS — это огромный костыль, помогающий снизить влияние ошибок, передающихся с унаследованным кодом. В этой системе защита предоставляется как по принципу отказа от участия (opt-out) в попытке частично купировать XSRF-атаки против незащищённых или немодифицированных сайтов, так и по принципу активного участия (opt-in), чтобы на сайте включалась активная самозащита. Но ни одной из этих мер не достаточно, чтобы решить целенаправленно созданную проблему. Если на вашем сайте используются куки, то вы обязаны деятельно позаботиться о его безопасности. (Ладно, это касается не любого сайта, но лучше перестрахуйтесь. Выделите время на тщательный аудит вашего сайта или выполните описанные ниже простые шаги. Даже придерживаясь самых разумных паттернов, вы всё равно можете подставиться под XSRF-уязвимости).
Как мы с вами знаем, SSH — надежный и безопасный протокол для удаленного управления системами, который является неотъемлемой частью работы у многих. Однако, что делать, когда стандартные порты SSH заблокированы или закрыты, например, в строго защищенных корпоративных сетях или в облачных средах с жесткой политикой безопасности? Или что делать, если под рукой есть только браузер и нет возможности использовать обычный терминал?
Одним из таких решений является WebTTY — мощный инструмент, который обеспечивает доступ к терминалу удаленного сервера через веб-браузер, используя технологию WebRTC и веб-технологии для создания безопасного и зашифрованного соединения. Это решение позволяет обойти ограничения, такие как заблокированные стандартные SSH-порты, и предоставляет простой и удобный способ взаимодействия с командной строкой сервера без необходимости открытия дополнительных портов, что особенно полезно в средах с жесткими сетевыми ограничениями или за фаерволами.
В этой статье мы рассмотрим, как WebTTY может быть использован для доступа к SSH-портам через браузер, даже если они закрыты, как его можно настроить и когда его можно использовать. Основана цель данного материала – познакомить вас с таким вариантом подключения и показать, как использовать данный инструмент. Надеюсь, что представленные примеры и объяснения помогут вам оценить его возможности и найти полезные применения в вашей практике.
Привет, Хабр!
Меня зовут Никита Соболев, я опенсорс разработчик и core-разработчик CPython.
Давайте поговорим про одну из самых сложных частей интерпретатора CPython – вызов Python кода из C кода. Почему сложных? Потому что Python может резко и внезапно менять стейт всего кода на C. А особо злобный код на Python вообще часто приводит к [1] 88503 segmentation fault python
Данный пост создан по материалам из моего канала в Телеграмеopensource_findings
: https://t.me/opensource_findings/842
Под катом – кишки питона, я предупредил!
Во время работы над аддоном для Jakarta-валидации мне пришлось писать логику по проверке изменений в модели по собственной аннотации CheckExistingByConstraintAndUnmodifiableAttributes.
Долго разглядывал получившейся код, и в голову пришла светлая (наверное) идея: почему бы не вынести все это в полноценный настраиваемый класс?
До появления YOLO большинство способов обнаружения объектов пытались адаптировать классификаторы для детекции. В YOLO же, обнаружение объектов было сформулировано как задача регрессии на пространственно разделенных ограничивающих рамок (bounding boxes) и связанных с ними вероятностей классов.
В данной статье мы узнаем о системе YOLO Object Detection и как реализовать подобную систему в Tensorflow 2.0.
Обнаружение объектов является достаточно популярной задачей компьютерного зрения, которая включает в себя идентификацию и обнаружение объектов на изображениях или видео. Данная задача является частью многих приложений, например, таких как беспилотные автомобили, робототехника, видеонаблюдение и т.д. За прошедшие годы разработано множество алгоритмов и методов для поиска объектов на изображениях и их положениях. Наилучшее качество выполнения таких задач достигается при использовании сверточных нейронных сетей.
Одной из самых популярных архитектур нейронных сетей для таких задач, является YOLO (you only look once), созданная в 2015 году. С тех пор появилось довольно много версий данных алгоритмов. Последние выпуски сети предназначены для таких задач как распознавание, обнаружение и сегментация изображений.
Этот учебник поможет вам легко создать yolov4 в облаке с включенным графическим процессором, чтобы вы могли выполнять обнаружение объектов за миллисекунды!
Написать этот материал меня побудило... отсутствие хороших статей по корутинам в C++ в русскоязычном интернете, как бы странно это не звучало. Ну серьезно, C++20 существует уже несколько лет как, но до сих пор почти все статьи про корутины, что встречаются в рунете, относятся к одному из двух типов. Или обзор начинается с самых глубин и мелочей, пересказывая cppreference, а потом автор выдыхается и все сводится к "ну а дальше все понятно, возьмите и примените это в своем коде", что напоминает известную картинку с совой. Либо иногда в статьях рассматривается применение корутин на примере генераторов, и этим все и ограничивается. Но, давайте будем честны, генераторы — это замечательно, но за все время моей многолетней карьеры разработчика я, вероятно, делал что‑то подобное генераторам разве что разок, в то время как асинхронный ввод‑вывод приходится использовать почти в каждом проекте. И поэтому меня гораздо больше интересует реализация асинхронного ввода‑вывода с использованием корутин, а не генераторы. Поэтому пришлось разбираться во всем самому.
Cache API - сравнительно старый API для управления хранилищем кэша, доступный уже во всех современных браузерах и являющийся частью ServiceWorker.
Разберемся, как мы можем его использовать, сравним с другими методами организации кэша на стороне клиента, а также реализуем новостную ленту с применением Cache API.
Идея создания цифровых двойников прочно вошла в умы всех людей, занятых модернизацией производства во всем мире. О работе команды TechnologiCS в этом направлении мы уже говорили в статье «TechnologiCS 7.9 – цифровизация всего жизненного цикла продукции на базе одной системы». Теперь пришло время обсудить элементы инфраструктуры взаимодействия пользователей с цифровым двойником. Ведь автоматизировать сбор разнородных данных и собрать на них каркас цифрового двойника не является конечной целью в процессе создания модели производства – необходимо организовать работу сотрудников с огромным объемом все увеличивающейся информации. И не просто наладить работу, а сделать ее комфортной и эффективной. Для этого следует иметь в арсенале удобные точки взаимодействия с цифровым двойником, упрощающие работу и доставляющие необходимую информацию пользователю «just in time».
Здесь мы расскажем о таких инструментах в составе цифрового двойника TechnologiCS, как очки дополненной реальности, терминалы рабочих, мобильные точки доступа, Bluetooth-метки и сервисы визуальной аналитики.
Ян Флеминг, автор романов о Джеймсе Бонде, отпраздновал завершение книги «Казино Рояль» покупкой позолоченной печатной машинки — именно такая могла быть у супергероя, чтобы после спасения мира набивать мемуары. Ум, ирония и крутой нрав — в одном знаковом поступке.
В этом году мы получили 1022 заявки на конкурс «Технотекст 2023» и, как ни удивительно, кроме дикой усталости и суток с протоколами напролёт, они принесли нам огромное удовольствие от творчества и полёта мысли людей с очевидно золотыми клавиатурами. Многих авторов мы знаем, кого‑то когда‑то сами выпустили из песочницы и самое удивительное вот что: почти все авторы — не профессиональные писатели, а люди, которые сели и написали крутой, полезный, нужный и востребованный материал. Люди, которые поделились знаниями, умениями или просто скрасили трудовые будни сотен тысяч хабровчан классным текстом. Такой вот скрытый удивительный талант, который нашёл свою реализацию. В общем, вам бы книги писать, да IT не отпускает.
Недавно на Хабре проскакивала новость о Magnit Tech++ Meet Up, и в ней упоминалась задачка, которая меня заинтересовала. В оригинале задачка формулируется так:
Определена функция с сигнатурой:
void do_something(bool a, int b, std::string_view c)
Определить функцию, принимающую в произвольном порядке аргументы типов bool
, int
, std::string_view
и вызывающую функцию do_something
с переданными параметрами в качестве аргументов.
Я придумал несколько решений этой задачки, а здесь предлагаю два варианта ее решения - сначала банальный (и плохой), а затем самый с моей точки зрения оптимальный.
Знаете, я никогда не задумывался, насколько плоха или хороша инициализация переменных в языке C++. Я просто использовал ее. И не имел никаких проблем. Но недавно я посмотрел пару видео, пролистал несколько статей и да, я должен признать… она действительно ужасна. Один очень серьезный человек даже сказал, что мы, как сообщество программистов, виновны в том, что C++ не настолько хорош, насколько он мог бы быть.
Ну ладно, давайте включим воображение и посмотрим, что мы могли бы изменить, чтобы улучшить данную ситуацию. Тех, кто уже понял о чем речь, сразу хочу успокоить. Слишком глубоко в эту кроличью нору мы не полезем. Разберем лишь то, с чем сталкивается каждый, а также гипотетические способы наведения во всем этом какого-то минимального порядка.
Я думаю, что вы не раз уже гуглили, заглядывали в статьи, манифесты IT-гигантов о лучших практиках проектирования API. Я тоже.
Но в большинстве из них всё ограничивается описанием URL ресурса, мотивацией использовать пагинацию, сложными словами про кэширование и SSL. Это, безусловно, необходимо для общего понимания технологий, но практически не помогает, когда ты сидишь перед пустой страницей и надо начать “проектировать контракт”.
Я работаю тимлидом направления системного анализа в X5Tech и за все время развития карьеры сталкивалась с большим количеством кейсов проектирования Web систем. IT продукты в большинстве очень динамичны: постоянно изменяются требования, появляются новые, итеративно улучшается пользовательский опыт (по принципу 20% усилий на 80% результата, а остальное доделаем потом).
Часто при проектировании мне помогала следующая идея: было бы здорово проектировать контракт так, чтобы при малейшем изменении/добавлении бизнес-правил его не приходилось сильно трансформировать, так как API является стыковочным звеном между разными слоями приложения. По ходу повествования я приведу пару примеров, чтобы проиллюстрировать такие изменения.
В этой статье предлагаю спроектировать контракт по шагам, и на каждом из них я расскажу про общие рекомендации из копилочки “Полезное”, а также про личные правила и практики, полученные долгим опытом работы над постоянно меняющимися ИТ-продуктами, которые помогут для “дальновидного” проектирования GET REST API.
В предыдущей статье про Qt roadmap я обещал рассказать про Qt 3D Studio и текущую ситуацию с лицензиями. Qt 3D Studio уже было выпущено два (пока писал статью, вышел третий) внутренних релиза, но статьи про неё пока не будет, так что сегодня расскажу про лицензии.
Система лицензирования Qt и раньше не особо отличалась простотой, но сейчас она особенно усложнилась, так как добавились (и добавляются) новые продукты и вместе с ними дополнительные условия соответствующих лицензий. Официальный сайт не сильно помогает разобраться, хотя и содержит текст условий и соглашений.
Но речь пойдёт не сразу про лицензии, сначала я хочу рассказать немного о компании, чтобы было понятно, кто именно сейчас занимается разработкой/распространением фреймворка и вообще стоит за Qt.