Об обработке текстов на естественном языке сейчас знают все. Все хоть раз пробовали задавать вопрос Сири или Алисе, пользовались Grammarly (это не реклама), пробовали генераторы стихов, текстов... или просто вводили запрос в Google. Да, вот так просто. На самом деле Google понимаетот него хотите, благодаря ш, что вы тукам, которые умеют обрабатывать и анализировать естественную речь в вашем запросе.

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

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

Так как всё-таки происходит обработка таких запросов?

Добрый день! Меня зовут Михаил Емельянов, недавно я опубликовал на «Хабре» небольшую статью с примерным путеводителем начинающего Python-разработчика. Пользуясь этим материалом как своего рода оглавлением книги, я написал первые четыре главы мини-учебника «Ядро планеты Python», где постарался коротко, но достаточно ёмко раскрыть специфику, удобство, красоту и силу этого прекрасного языка.

Оригинал учебника лежит на GitHub, вы вольны сколько угодно дополнять и переделывать его. Самое главное — учебник написан на Jupiter Notebook, а это значит, что вы можете интерактивно редактировать код, мгновенно добавляя новые сущности или проясняя непонятные моменты.

Всем привет! Меня зовут Сергей, я работаю в команде Тинькофф. Сегодня я хочу рассказать, как мы в Тинькофф приходили к классической пирамиде тестирования. 

Рассказ будет в трех частях:

- Трудности, с которыми нам пришлось столкнуться, и как мы их преодолевали.

- Конкретные решения по некоторым распространенным кейсам при написании интеграционных тестов.

- Подход к написанию E2E-тестов (тестов, покрывающих взаимодействие всех систем приложения, включая back-end и пользовательский интерфейс) с использованием паттерна PageObject, пришедшего к нам из мира веб-разработки.

Я Алексей Лапаев, руководитель команды обеспечения качества мобильного приложения Тинькофф и организатор гильдии интервьюеров веб-стрима найма QA. Расскажу, как проходит отбор на вакансии QA-инженеров, что спрашивают на первичном интервью и какие секции и задачи ждут в технических блоках. 

Договоримся, что термины «тестировщик», «QA» и «инженер» равнозначны и используются с целью разнообразить слог. Профессионально мы строим команды фулстек-QA-инженеров, но идеологию затронем лишь вкратце. Материал будет полезен тем, кто интересуется процессами в крупных компаниях, видит свое будущее в качестве QA-инженера или хочет работать именно в Тинькофф. Если это про вас — добро пожаловать под кат!

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

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

Что будет, если ввести этот элемент в вашу архитектуру? И почему это особенно актуально сейчас, когда так широко распространился микросервисный подход к проектированию систем? Обсудим это сегодня. Все подробности — под катом.

Всем привет! Сегодня я расскажу о том, как мы тестируем Rest API в SM 2.0 с помощью инструмента Postman.

И сделаю это на примере реальной задачи — посмотрим сценарий пользователя (как оформляется заказ у нас на сайте), посмотрим, как это работает все изнутри, пару слов скажу о REST-запросах, расскажу про Postman. Далее мы перейдём в сам инструмент, посмотрим окружение, интерфейс, далее разберём исходные данные и приступим к решению самой задачи, и в конце немного расскажу про автотесты.

Привет! Меня зовут Ивасюта Алексей, я техлид команды Bricks в Авито в кластере Architecture. Я решил написать цикл статей об истории и развитии HTTP, рассмотреть каждую из его версий и проблемы, которые они решали и решают сейчас. 

Весь современный веб построен на протоколе HTTP. Каждый сайт использует его для общения клиента с сервером. Между собой сервера тоже часто общаются по этому протоколу. На данный момент существует четыре его версии и все они до сих пор используются. Поэтому статьи будут полезны инженерам любых уровней и специализаций, и помогут систематизировать знания об этой важной технологии.

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

В этой статье я расскажу про мелкие ментальные приёмы, которые могут помочь при формировании заметок-терминов. Основной фокус внимания будет сосредоточен на разборе текстов из учебников.

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

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

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

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

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

Эта статья завершает цикл "Управление знаниями в Obsidian". В ней будет предполагаться, что вы способны понять все техники и приемы из прошлой второй части про базовый рабочий процесс, т.к. здесь будут показаны продвинутые способы управления персональной базой знаний. В частности, статья затронет следующие темы:

• Ведение визуальной базы знаний (Excalidraw + Excalibrain)

• Создание системы для интервального повторения (Spaced repetition)

• Создание гибкой иерархии (Breadcrumbs + Excalibrain)

• Использование алгоритмов для поиска новых связей между заметками (Graph Analysis)

• Написание длинных текстов (Longform)

В этой статье будет показано как можно начать организовывать свою базу знаний в Obsidian, отталкиваясь от источников. В статье будет разобрано то, какие стоит использовать папки и теги; как создать свою первую точку входа в систему. Также будет уделено внимание способу ведения журнала (дневника). Статья будет предполагать, что вы не против автоматизации процессов в своей базе знаний, поэтому все источники будут шаблонизированы и впоследствии собраны в свои отдельные библиотеки с помощью dataview. Завершится статья подробным примером (алгоритмом) рабочего процесса.

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

— В моей базе знаний я делаю все правильно или у меня есть какие‑то существенные проблемы и недостатки?

Рассуждения хоть и субъективные, но они написаны достаточно абстрактно, чтобы всяк читающий смог примерить мысли из статьи на себя и перенести вынесенную пользу на свою уникальную, персонализированную базу знаний. Причём неважно в каком именно инструменте вы ведёте персональную базу знаний (Obsidian, Roam Research, Logseq, Trilium, Dendron, Notion, Siyuan и прочие), описанные маркеры в этой статье вас так или иначе могут сподвигнуть на какие-то продуктивные размышления или даже изменения.