При написании этой статьи я сделал все возможное, чтобы сделать ее простой для чтения. Однако, в ней содержится очень сложный и нетривиальный вывод — почему методы моделирования операций, которые мы встречаем почти в каждой нотации, не дают нам удовлетворения. Я не видел подобного анализа нигде, даже в книге Криса Партриджа, которую я очень люблю: Business Objects: Re-Engineering for Re-Use. Поэтому я надеюсь, что статья будет легка и полезна одновременно.


Все модели, которые мы строим, должны так или иначе моделировать 4-х мерное пространство-время, потому что именно так мы представляем себе окружающий нас мир. Об этом рассказано в книге Криса Партриджа. Даже то, что кажется, не имеет отношения к 4-пространству, при внимательном рассмотрении оказывается оным. Правда, не всегда существующим в реальности, иногда — это воображаемый нами мир. Всем, кому интересно, как это происходит, рекомендую внимательно прочитать эту книгу. Однако, советую не обращать внимания на определение события в этой книге, — оно дано неверно.

Например, что такое болт? Это 4-х мерный объект, который ограничен в пространстве-времени определенными границами. Для моделирования болта существуют нотации, которые моделируют эти границы. Например, чертеж болта моделирует поверхность, которая ограничивает 3-х мерный объем. Добавив к этому чертежу еще 6 координат, зависящих от времени, мы получим модель поверхности 4-Д пространства — времени, которая моделирует болт.

Однако, что такое операция? Это — тоже 4-х мерный объект, который также, как и болт ограничен определенными границами в пространстве и во времени. Правда, представить себе операцию как 4-объект намного сложнее. Существуют три причины, по которым нам сложно это сделать.

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

В результате обучения человек привыкает к тому, что есть некоторые паттерны, повторяющиеся из раза в раз. Например, если поднять камень и отпустить его, он упадет на землю. И так будет всякий раз, когда повторится этот паттерн. Знание о том, что предмет падает на землю является эмпирическим опытом, не требующим объяснения. Всем, кто живет на Земле, этот факт кажется очевидным, не требует ни объяснения, ни доказательства, то есть, он понятен. Выглядит это знание как:

1. Эмпирический опыт – это множество (класс) ситуаций, которые расцениваются данным субъектом, как похожие друг на друга (субъект ронял предметы). Новые ситуации классифицируются субъектом как похожие на предыдущие и пополняют класс однотипных ситуаций.
2. Паттерн ситуаций (тип ситуаций, или модель ситуаций), который присутствует в сознании у субъекта и в котором записано, что всякий раз, когда случится подобное, тело падает на землю. Паттерн связан с эмпирическим опытом, или с классом ситуаций.

Итого: есть ситуации, модели которых хранятся в сознании у субъекта, есть модель этих моделей – паттерн, который тоже хранится в сознании у субъекта. Все вместе это дает человеку чувство понимания.

Однако, для человека, родившегося в космосе и всю жизнь проведшего в невесомости, факт того, что камень падает на землю, не будет являться очевидным, и потребует объяснения.

Некоторое время назад, вернувшись после полугодового отпуска в функциональном мире, назад в ООП, я в который раз наступил на привычные грабли: случайно изменил состояние.

private double fBm(Vector2D v, int y)
{
    double result = 0f;
    double freq = Frequency;

    for (int i = 0; i < Octaves; ++i)
    {
        result += NoiseFn(permutation, v * freq) * Amplitude;
        freq *= Lacunarity;
        Amplitude *= Gain; // <-- Вот тут.
    }

    return result;
}

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

Для создания модели предметной области сначала строится модель наших представлений. Описание наших представлений содержится в метамодели (например, в нотации BPMN). Метамодели, в свою очередь, строятся на основе мета-метамодели. Однако, наши представления имеют очень непростую структуру, которая до сих пор не имеет формального описания. Поэтому построение метамодели и мета-метамодели сильно затруднено. Попытку описать эту структуру предприняли греки, когда придумали основы логики. Способы нашего мышления изучали математики, когда столкнулись с парадоксами, пытаясь построить основы своей науки. Казалось бы, прогресс есть, но по какой-то причине, остановившись на формальном описании инструментов логического вывода, математики не сделали попытку применить полученные наработки к моделированию нашего мира (наверно, потому что для них – это прикладная задача, не вызывающая интереса).



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

Кнопка или ссылка?

Я знаю хабр не для жалоб,

но доколе

использовать ты будешь

— ссылки вместо кнопок <UserName />‽

Автор иллюстрации <Marat Hilmanov> gray-monkey@yandex.ru

Если коротко:

Используйте для кнопок — кнопки, а для ссылок — ссылки.

Для кнопок использовать
ссылки
— не комильфо.

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

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

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

В рамках нашего рассуждения я осознанно постараюсь уйти от каких-либо терминов и устоявшихся выражений, ибо как говорил У. Куайн – термины это всего лишь имена в рамках онтологий не имеющие никакого практического значения для решения задач логики и понимания чего-либо в частности.[1] Поэтому, с его позволения, будем опираться на единичные дескрипции Рассела, а проще говоря, давать полные описания в ущерб существующим устоявшимся терминам.

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

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



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

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

Всем привет! Меня зовут Владимир Баранов, я занимаюсь ASO и обладаю экспертизой в оптимизации приложений, начиная от малобюджетных читалок, заканчивая приложениями с многомиллионной аудиторией: дейтингами, играми и чатами.

Это будет первая статья цикла “Популяризация ASO”. В этом цикле я опишу все этапы оптимизации приложения, какими сервисами пользуюсь и на что нужно обращать внимание при проведении оптимизации.

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

Добавлю в копилку статей Хабра о Бинарном поиске еще одну. Речь пойдет о кастомной реализации, может быть полезно всем, кто часто использует в работе ВПР для сравнения больших списков или для поиска данных в больших массивах.

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

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

Лекция 1. «Введение в информационный поиск»

Алексей Воропаев, руководитель группы рекомендаций Поиска Mail.Ru, дает определение понятия информационного поиска и делает обзор существующих поисковых систем, рассказывает об индексации и поисковых кластерах.

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

Те кто сталкивался с задачами автоматизированного анализа резюме, представляют современное состояние дел в этой области — существующие парсеры в основном ограничиваются выделением контактных данных и ещё нескольких полей, таких как «должность» и «город».

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

Живой пример (кусок XML результата анализа резюме от одного из лидеров области Sovren):

    <EmployerOrg>
        <EmployerOrgName>ООО Звезда-DSME</EmployerOrgName>
        <PositionHistory positionType="directHire">
            <Title>Ведущий специалист отдела развития информационных систем</Title>
            <OrgName>
                <OrganizationName>ООО Звезда-DSME</OrganizationName>
             </OrgName>

Парсер Sovren прекрасно справился с выделением полей. Ребята не зря занимаются этим делом без малого 20 лет!

Но что дальше делать с «Ведущий специалист отдела развития информационных систем»? Как понять, что же это за должность, насколько опыт работы этого человека релевантен для той или иной вакансии?

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

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

От переводчика:

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

Я тогда выразил своё недоумение автору и попросил его выровнять текст на 80 символов. Но после непродолжительной дискуссии в коментариях дали ссылку на описание форматирования исходников литературных текстов по семантическому принципу. Идея, заложенная в этом принципе в общем довольно простая, но я был поражён её глубиной, которой, пусть и запоздало, хочу поделиться с окружающими.

Хочу предупредить, что не все ссылки в статье работоспособны, но я решил оставить их как есть — мало ли что.

С постоянно растущим объемом текстовой информации и уровнем развития инструментов web-визуализации возникает желание все эти объемы визуализировать. Демонстрация возможности такой визуализации — задача, которая была поставлена перед командой студентов в рамках работы ABBYY Labs и курса “Промышленное программирование” на Факультете инноваций и высоких технологий (ФИВТ) в МФТИ (если вы ещё ни разу не читали в нашем блоге о студенческих лабораториях ABBYY, есть смысл вернуться вот к этому посту).

Пятнадцати третьекурсникам-разработчикам и четырем четверокурсникам-менеджерам, студентам ФИВТ, было предложено за три месяца исследовать современные open-source решения визуализации структурированных данных и затем, выбрав для себя тему, визуализировать текстовую информацию на естественном языке. Переход от неструктурированной информации к структурированной предлагалось осуществить при помощи семантико-синтаксического парсера ABBYY Compreno.

По итогам опроса в “WRIO Internet OS. Введение”, это первый пост в серии призванной раскрыть технические детали. Информация сможет заинтересовать разработчиков желающих использовать в своих проектах следующие технологии: JSON-LD, блокчеин, Node.js и React. В конце поста вы найдете опрос, который позволит нам узнать, какая следующая тема была бы полезной и интересной для хабросообщества.

Вводное видео о проекте:
www.youtube.com/watch?v=JUiMijJ6tEg English version
www.youtube.com/watch?v=DxA6t2kax_k Русская версия

Сегодняшняя тема: Linked Data и JSON-LD. На примере своего опыта мы расскажем чем данный формат интересен и какие преимущества он предоставляет.

Постановка задачи

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

На уровне предприятия производятся следующие работы:

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

Как-то так получилось, что за последнюю неделю я посмотрел довольно большое количество выступлений на разных крупных и не очень конференциях. И часто там говорили об очень важных, в теории, вещах: производительности, доступности, прогрессивном улучшении.
Но, судя по моему опыту и ощущениям, на практике никто этим не занимается, кроме самых крупных компаний. Эти ощущения подтверждает, например, подкаст Веб-стандартов: там при обсуждении каких-то технологий или практик, постоянно звучат слова "мы это у себя не используем", "только если заказчик пнёт".
Я бы хотел проверить, так ли это, проведя небольшой опрос. Думаю, результаты будут интересны многим, приглашаю обсудить вопросы, ответы и вообще эту тему в целом в комментариях.
P.S. Я в опросе довольно вольно использую термин "стандарты". Понятно, что для некоторых вещей стандартов нет, но придумывать какое-то альтернативное название не вижу смысла.

Уже меньше месяца осталось до «очной ставки» NeoQUEST-2016. Она пройдет в Питере 7 июля, вход традиционно свободный, нужно лишь зарегистрироваться на сайте! Доклады, конкурсы, демонстрации атак, Twitter-викторина — все это (и не только!) ждет гостей мероприятия с 11:00 до 18:00 в КДЦ «Club House».

Тем временем подоспел разбор еще одного задания online-этапа NeoQUEST-2016, и в этот раз поговорим о SPARQL-инъекциях и о CSRF атаках через сообщения Telegram. Задание содержало в себе 3 разных ключа, один ключ получался с помощью SPARQL-инъекции в запросе ID пользователя, второй и третий ключи — с помощью инъекции и CSRF-атаки.