fedor_malyshkin

Как-то думал и понял, что свои собственные возможности мы часто ограничиваем самостоятельно. Например говоря: «Это слишком сложно для меня» или «Я не смогу это сделать».

Когда переступаешь через это – понимаешь, что всё вовсе не так сложно и вполне реализуемо, ну а после выполнения можно и плоды труда пожинать…

В оригинальной работе посвящённой ССГ (А.В. Гладкий «Синтаксические структуры естественного языка») всё дано в достаточно точном математическом виде. Это имеет ярко выраженные плюсы и минусы.

Плюсы:

• Свойства ССГ абсолютно понятны

Минусы:

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

Главные пороки деревьев подчинения:

Всегда мучался вопросом – «Почему лингвистические системы и работы, посвящённые им, такие сложно-замудрённые?»

Ответ нашёл в цитате из одной книги:

«…

Прежде всего, можно заметить, что качество перевода тем выше, чем полнее и принципиальнее модель языка, лингвистический компонент системы автоматического перевода.

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

В связи, с возникшей недавно потребностью работе с данными в JSON-формате, решил исследовать вопрос о существующих библиотеках для работы с JSON для С/С++.

Сразу хочу оговориться, что детального рассмотрения всего множества библиотек для работы c JSON я представлять не собирался. На текущий момент их существует более-менее большое кол-во. Вот список с сайта json.org (http://www.json.org):

Для тех, кто пытается использовать стандартный подход к разработке многопотоковых приложений, хочу представить перевод статьи фирмы «iMatrix» (бывший со-разработчик «RabbitMQ» и текущий разработчик библиотеки «ZMQ»), в котором ключевые программисты фирмы высказывают своё мнение о подобном подходе.

По мере появления свободного времени буду дополнять перевод...

Спустя какое-то время поиска по Интернету понял, что мне необходимо в вопросах HTML: запрос в Google по ключу «admin template» - дал то, что я искал.

• Модули должны иметь возможность стартовать, останавливаться и перезапускаться в любое время. Так, что бы не приходилось перезапускать или перенастраивать другие модули. Когда Ваше приложение выйдет на «боевые» сервера (денежный уровень) – перезапуск всей системы будет строить ОЧЕНЬ дорого.
• Модули должны иметь возможность запускаться в нескольких экземплярах (желательно без переконфигурированя) – вопрос в полном использовании аппаратных мощностей (об этом в следующем посте).
• Обмен должен производиться данными, которые не имеют привязки к языку, ОС, или аппаратной платформе, но имеют поддержку или средства обработки в любом языке и не портятся на другой аппаратной платформе. Это я понял, когда начал передавать данные с Ruby (32-bit Windows) на C++ (64-bit Linux). Я выбрал XML.
• Блокирующие вызовы должны быть исключены как класс – все пишут медленный или глючный код и ждать пока что-то будет заниматься перебором массивов или какой-то модуль перезапустят - слишком дорого. Этот принцип следует закладывать уже в прототипах.

• Протокол должен быть простым, но гибким (не ограниченным). Например, возьмите в качестве примера почтовые сообщения – кроме самого текста письма есть ещё заголовки (не поля «От», «Тема» и прочее, а системные). В них хранится и информация о маршруте движения, как оно было обработано, что в нём, формат, размер и прочая полезная информация.
• Он должен быть записан и задокументирован (форматы, взаимодействие модулей для всех случаев). Почему? Добавьте ещё 2-х разработчиков и узнаете.

• Веб-приложение не зависит от платформы (где работает браузер – там работает и оно)
• Это проще и нагляднее
• Веб-приложение всё так же остаётся представителем трехзвенной архитектуры, что оставляет возможность перемещать части как угодно
• Реализовать закрытое соединение проще простого