Textocat API — это облачный SaaS анализа текстов. Качественное извлечение полезной информации из текстов — сложная задача и требует серьезной экспертизы. Миссия команды Textocat — сделать процесс обработки текстов настолько легким для использования, чтобы его мог включить в свой арсенал любой современный разработчик. Используя Textocat API, вы можете быстро прототипировать приложения на основе текстовой аналитики и превращать их в свой бизнес. В данной публикации мы покажем, насколько легко интегрировать в любое приложение возможности Textocat API по распознаванию упоминаний сущностей (объектов) и поиску документов на русском языке.

Возможности Textocat API Beta

В начале апреля мы запустили бета-тестирование Textocat API. В этой версии мы предлагаем разработчикам бесплатно использовать часть функционала сервиса со следующими возможностями:

• распознавание упоминаний сущностей (entity recognition) в коллекциях документов на русском языке;
• хранение обработанных коллекций;
• полнотекстовый поиск с учетом выделенных типов сущностей.

Привет, Хабр. Кубака официально с вами (давно пора).

Для тех, кто о нас не слышал — рады познакомиться, мы делаем мониторинг javascript-ошибок на сайте.
А в этом году запустили аналитику поведения пользователей Vision. О ней и хотим рассказать.



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

Взаимодействие различных сервисов с использованием АPI, из новаторства превращается в обыденность. Количество бесплатных и платных API уже исчисляется тысячами, и с каждым днем их число активно растет. А почему бы и нет? Продажа удаленных запросов к своему новаторскому сервису может принести больше прибыли, чем распространение услуг через свою площадку. И пусть, в таком случае, уже ваши клиенты ломают голову и тратят деньги на привлечение аудитории. Используя свой опыт работы, я предлагаю краткий обзор лучших решений по реализации API на сегодняшний день.

Что такое NAXSI ?

NAXSI = NGINX ANTI XSS & SQL INJECTION
Проще говоря, это файрвол веб-приложений (WAF) для NGINX, помогающий в защите от XSS, SQL-инъекций, CSRF, Local & Remote file inclusions.
Отличительными особенностями его являются быстрота работы и простота настройки. Это делает его хорошей альтернативой например mod_security и апачу.

Зачем нужен NAXSI ?

Очевидно, лучше всего защищаться от вышеперечисленных атак правильно написанным кодом. Но есть ситуации, когда WAF (и в частности naxsi), поможет:

• Низкое качество кода сайта, при отсутствии возможности/ресурсов все выкинуть и переписать нормально.
• “Закрытый” код, в котором невозможно исправить ошибки.
• Неизвестное качество кода в важном для бизнеса участке.

Привет, хабралюди!

По долгу службы приходится работать с веб-разработчиками, которые иногда пишут свои скрипты с рерайтами, которые им приходится адаптировать для nginx. Мне же приходится разгребать то, что там написано.

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

2006 год. На форуме специалистов SQL неожиданно поднимается вопрос о целесообразности моделирования бизнес-процессов в CRM-системах. Звучат слова: долго, дорого, Siebel, не нужно, сложно.
2014 год. Все чаще клиенты просят посоветовать CRM с возможностью построения и запуска бизнес-процессов. В чем причина? Первое подозрение — где-то услышали и теперь тянутся за модой. На вопрос «Зачем?» поступает взвешенный ответ: «Устали от беспредела и путаницы в организации работ. Хотя бы в часто повторяющихся действиях нужен порядок». Нельзя не согласиться с тем, что основное назначение регламентации бизнес-процессов в компании — именно порядок. Признайтесь, приятно осознавать, что многие процессы в организации проходят четко, слаженно, быстро, с минимальной нервозностью.

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

Парящий полет (первая статья)

• Параплан
• Дельтаплан
• Планер

Моторный полет (под катом)

• Самолет
• Мотодельтаплан (дельталет)
• Паратрайк (аэрошют)
• Парамотор (карлсон, мотопараплан)
• Мотопланер

Первый раз за штурвал самолета я сел в 18 лет. До первого самостоятельного вылета налетал 25 часов и совершил около 100 взлетов и посадок. Сейчас мой суммарный налет на всем, что летает — порядка 400 часов. Это жутко мало, чтобы считать себя опытным пилотом, но достаточно, чтобы подсесть на “летную иглу”. Приглашаю и вас стать авиазависимыми.

Американская компания Aeros заявила об успешном первом летном испытании своего гибридного самолета-дирижабля Aeroscraft. Воздушное судно в длину 64 метра. Оно продемонстрировало функцию вертикального взлета и посадки, а также способность развивать скорость 222 км/ч. Согласно прогнозам специалистов, новый самолет-дирижабль может быть введен в эксплуатацию в течение ближайших нескольких лет. Использовать его планируется в качестве воздушного круизного лайнера – конструкция Aeroscraft позволяет орудовать большое количество комфортабельных кают для пассажиров и не только. Впрочем, создатели самолета-дирижабля не исключают и других вариантов его использования. В частности, в их планы входит создания грузовой версии Aeroscraft, достигающей в длину 137 метров и способной перевозить до 60 тонн грузов.

Мое детство прошло среди людей которые все время на чем то летали. Строили, разрабатывали новое и тут же на нем летали. В 5 лет для меня стало открытием, что кто то в этом мире может не летать. К своим 26 годам я успел попробовать почти все на чем можно летать. Хочу поделиться своим опытом и рассказать о доступных возможностях.
Что бы начать летать у Вас есть такие варианты:

1. Парители (в этой статье)

• Параплан
• Дельтаплан
• Планер

2. Моторный полет (вторая статья)

• Легкий самолет
• Мотодельтаплан
• Паратрайк
• Парамотор
• Мотопланер

В нашей команде работает более 30 человек. Мы разрабатываем масштабируемые решения для web. Живем в Томске, Санкт-Петербурге и в Москве. Для организации совместной работы над задачами мы использовали task-трекер. Во время проектов создавались ценные наработки и нужно было организовать работу со знаниями. Мы пробовали различные wiki-системы. Оказалось, что большая часть наших знаний создается при решении текущих задач. Мы сталкивались с проблемами:

• Заносить и вести все задачи в task-трекере неудобно, и поэтому сотрудники все время переходят на общение через мессенджеры.
• Много знаний оседает в e-mail и месенджерах. Перенос знаний из переписки в task-трекер и wiki отнимает много сил и времени.
• Если при планировании проекта в wiki была записана вся концепция проекта, то с каждым днем различий между информацией в wiki и реальным положением дел становится все больше, и поддержка базы знаний становится неоправданно трудоемкой.

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

Перед тестированием всегда стояли и стоят две задачи – помочь команде поддерживать высокий уровень качества разработки и делать это, не задерживая весь процесс. И это справедливо не только для наших проектов в Яндексе, где мы работаем над очень большим количеством сервисов. Часто основная задача и вовсе формулируется как увеличение скорости тестирования при сохранении должного уровня качества. Скорость процесса разработки, приверженность ценностям частых и быстрых релизов – это основополагающие факторы для успеха любого продукта. У команды больше возможностей маневра, команда быстрее находит и исправляет ошибки, быстрее получает фидбек. Как же ускоряться, не теряя качества, как достичь дзена непрерывной доставки изменений?



Сегодня мы покажем, что Continuous Delivery — это просто и весело! А пользу от него можно получить, встроив его даже частично. Мы в тестировании Яндекса уже несколько лет используем подобный подход для наших библиотек с открытым исходным кодом — Allure Framework или Yandex QATools. Процесс прост, значительно масштабируем и может применяться как для огромных команд из одного человека, так и для маленьких командочек из десятков человек. А самое главное — весь инструментарий доступен в Open Source!

Кстати, до 30 сентября можно подать заявку и поступить в нашу Школу автоматизации процессов разработки в Питере. Обучение в ней бесплатное и будет состоять не только из курса лекций — обязательным этапом станет командная работа над учебным проектом.

А теперь вернёмся к теме. Представьте картину: уютное рабочее место, вы пишете код, добавляете юнит-тесты и отправляете изменения в систему контроля версий, а через пару часов они «выезжают» на боевые сервера. И все при этом работает.

Давно собирался написать об этом, но, модная болезнь прокрастинация брала вверх…

Знакомство со Scratch

Когда сыну Артёму исполнилось 7 лет и он пошел в школу, мы ему подарили компьютер, чтобы он не отставал от жизни. Несколько месяцев он играл в разные игры, наслаждался, развлекался и т.п. Мне стало немного обидно, что такой дорогой и сложный прибор как компьютер используется только для развлечений, и я решил придумать, как использовать компьютер для обучения. А чему можно научиться на компьютере? Конечно, программированию! Тут я и вбил в «Яндекс» заветную фразу «обучение детей программированию».

В работе почти каждого человека непременно есть цифры, от которых зависит всё. Посещаемость сайта, время отклика или количество коммитов — что угодно! И если поместить эти цифры на самое видное место, они сразу становятся либо отличным способом оперативно принимать решения, либо просто наглядным инструментом мотивации. А самый лучший способ сделать это — это собственный дешборд, информационное табло, которое можно повесить на самом видном месте в офисе.

Как разработчик, вы возможно в курсе о Google Hosted Libraries. Google предоставляет простой и быстрый способ, как включить в ваши веб-сайты 12 самых популярных JavaScript-библиотек.

Но что, если вы – вебмастер и хотите использовать преимущество быстрых CDN при использовании в других менее популярных проектах? Или же вы – разработчик и хотите сделать ваш проект более удобным в использовании и более доступным другим пользователям.

Здесь в игру вступает jsDelivr. jsDelivr – это бесплатная и свободная CDN, созданная для того, чтобы помочь разработчикам и вебмастерам. В ней нет ограничений по популярности и разрешены все типы файлов, включая библиотеки JavaScript, плагины jQuery, CSS-фрэймворки, шрифты и многое другое.

«Всем привет, меня зовут Егор Камелев и сегодня я расскажу вам…»
Если вы уже слышали эти слова, то, скорее всего уже встречались с одним или несколькими из моих обучающих видео по работе в Axure. Прошло уже довольно много времени с тех пор, как я добавил первое из них (тогда ещё для Акшуры какой-то древней версии), и я решил сделать некий сводный список того, что уже есть, чтобы вам не пришлось мучиться с поиском на моём канале. Да, конечно, в этом списке только те ролики, которые имеют отношение в Акшуре седьмой версии! Итак, поехали.

Я работаю в команде семантического веба в Яндексе. Мы занимаемся тем, что создаем продукты на основе семантической разметки, делаем свои расширения и участвуем в развитии стандарта Schema.org.

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



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

Микроразметка состоит из словаря и синтаксиса.

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

Сначала пару слов, чтобы все понимали, что есть что. Под микроразметкой в целом (или семантической разметкой) мы подразумеваем разметку страницы с дополнительными тегами и атрибутами в тегах, которые указывают поисковым роботам на то, о чем написано на странице.

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

Стандартов синтаксиса, как и словарей, несколько. В этой статье мы и разберем на практических примерах наиболее распространенные:

• Microdata — Микроданные (словарь Schema.org чаще всего встречается именно в этом синтаксисе);
• Microformats.org — Микроформаты (напоминаем, что это объединенный стандарт синтаксиса и словаря);
• RDFa и RDFa Lite (в упрощенном виде RDFa рекомендуется создателями словаря Open Graph. Также встречается с другими словарями, например, со словарем Dublin Core или Data Vocabulary);
• JSON-LD — расширение JSON.

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

Once upon a time В 2004 году разработчики из W3C создали стандарт, который, по их мнению, подходил для «представления всего в мире». Так появился синтаксис RDFa (Resourse Description Framework in attributes), который позволяет однозначно транслировать HTML-разметку с семантическими данными в RDF.

На внедрение любой IT-системы требуется много времени, сил и средств. А когда речь идет о таком глобальном решении, как BPM-система, внимания приходится уделять еще больше.

Нельзя запускать проект, опираясь на возможности наскоро выбранного продукта и обещания вендора, есть масса аспектов, которые нужно обдумать и взвесить. А последствия неправильного выбора и осознание своей ошибки уже во время работы, «на половине пути» может стоить дорого.

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

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

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



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

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

Создание и управление средами разработки расстраивает вас, замедляет работу или отвлекать вас от разработки? У вас возникают трудности из-за того, что ваше локальное окружение и окружение при деплое отличаются? Если это так, у меня есть для вас решение — PuPHPet!

Введение

Я не могу с уверенностью сказать за вас, но одна из моих любимых мозолей* в разработке — это окружение, будь то создание и поддержание его для различных проектов с различными потребностями, обеспечение взаимодействия команды разработчиков, (особенно, распределенной), или настройка сред для разработки, тестирования и боевого окружения. Все это может быть трудоемкой задачей, особенно когда выполняется вручную.

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