Представляю вашему вниманию заключительную статью из трилогии «Восстановление расфокусированных и смазанных изображений». Первые две вызвали заметный интерес — область, действительно, интересная. В этой части я рассмотрю семейство методов, которые дают лучшее качество, по сравнении со стандартным Винеровским фильтром — это методы, основанные на Total Variaton prior.
Также по традиции я выложил новую версию SmartDeblur (вместе с исходниками в open-source) в которой реализовал этот метод. Итоговое качество получилось на уровне коммерческих аналогов типа Topaz InFocus. Вот пример обработки реального изображения с очень большим размытием:

Внутри у среднего банкомата лежит от 1 до 3 миллионов рублей. Они разложены по 4 кассетам, в каждой из которых – купюры своего номинала. Замена кассет похожа на замену картриджей в принтере: модуль вынимается (и неважно, сколько там осталось денег — инкассаторы этого даже не знают по правилам безопасности), а на его место вставляется другой модуль точно по стрелке, указывающей, какой стороной и как это делать.

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

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

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

Писатель мало чем отличается от плотника: один тешет доски, другой – слова. Постараюсь это доказать. За все время моей трудовой деятельности, моя работа так или иначе была связанна с написанием текстов. Нужно было учиться писать. Постараюсь поделиться своим опытом в получении навыка в данном деле.



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

От переводчика. Занимаясь созданием и внедрением системы электронного архива, мы не раз сталкивались с ситуациями, когда организации вводят документы в систему без разбора, не уделяя должного внимания экспертизе их ценности. Об этом уже писали. В обсуждениях наших предыдущих публикаций по данному вопросу большинство участников отстаивали следующий взгляд: сохранять можно всю поступающую информацию, она в любой момент может пригодиться. Насколько обоснован такой подход в масштабах крупной организации. Что дешевле и эффективнее: сохранять все, что возможно сохранить — или же грамотно управлять информацией, своевременно удаляя все ненужное? Любопытную статью на эту тему мы нашли в блоге Джорджа Парападакиса, ECM-специалиста из компании IBM. Ее перевод мы и предлагаем вниманию наших читателей.

Sentiment analysis (по-русски, анализ тональности) — это область компьютерной лингвистики, которая занимается изучением мнений и эмоций в текстовых документах. Недавно на хабре появилась статья про использование машинного обучения для анализа тональности, однако, она была настолько плохо составлена, что я решил написать свою версию. Итак, в этой статье я постараюсь доступно объяснить, что такое анализ тональности, и как реализовать подобную систему для русского языка.

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

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

"Мама мыла раму":

(предложение
    (именная гр. (сущ мама))
    (глаг. гр. (глаг мыла)
        (именная гр. (сущ раму)))
    (. .)))

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

Нет, это статья не об игре про заражённый вирусом Манхэттен и его мутантов. Речь пойдёт о прототипах другого рода — прототипах программного обеспечения.

Прототипирование ПО становится всё более популярным и часто используемым процессом в российских IT-компаниях. Причины видятся следующие: с одной стороны – это определенная дань моде, с другой – прототипирование обещает компании ряд весомых преимуществ.

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

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

В ходе подготовки к Летнему Аналитическому Фестивалю 2012 родилась эта статья, в которой поднимаются следующие вопросы:

• Кто такие ИТ-менеджеры?
• В каких вузах их могут готовить?
• Что в вузе им должны прочитать?
• Как подготовить в вузе сотрудника для своей компании?

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

ВАКханалия

В течение последних 5-6 лет в России полным ходом идет реформа системы подготовки научно-педагогических кадров высшей квалификации (т. е. аспирантов и докторантов). Одним из элементов этой реформы является обеспечение прозрачности процесса защиты диссертации. Казалось бы, сделано было много — но каков результат? Несмотря на все заявления чиновников от образования и науки, жизнь показывает, что говорить о каких-то положительных результатах вряд ли возможно. Авторефераты, размещаемые в Интернете, все равно почти никто не читает. Количество некачественных диссертаций не уменьшилось, а наоборот, увеличилось. Система «Антиплагиат», на внедрение которой были затрачены немалые суммы, не оправдала возлагаемых на нее надежд. Казалось бы: самое время одуматься, проанализировать допущенные ошибки и наметить пути их исправления. Но вместо этого реформаторы решаются на еще одну радикальную меру.

Вступление 1.

Много думал и анализировал информацию на тему разработки игр. И чтобы не потерять, а так же поделиться с людьми, получить подсказки, советы и комментарии — решил оформить и выложить статью. На сегодняшний день “геймдизайн” все больше обретает очертания некой науки, требующей особого подхода и изучения. К сожалению, в общем доступе находится очень мало структурированной информации. Что касается иностранных авторов, имеющих большой опыт и ряд успешных проектов — зачастую их труды так и не попадают на прилавки отечественных магазинов. А изучить их в оригинале многим мешает языковой барьер.
В данной ситуации спасением служат статьи, где люди делятся впечатлениям и личным опытом по разработке игр. Эти статьи не только и не столько доносят до читателей новую информацию, сколько подают ее в новом свете, позволяя более четко осознать и отобразить в жизнь.

Вступление 2

Хочу отметить, что на написание материала оказало влияние выступление на Sociality Rocks 2011 Henric Suuronen — руководитель студии Wooga, разработчика Bubble Island и других хитов. Особого внимания заслуживает статья Андрея Плахова “Геймдизайнерам о программистах или как программировать программистов”. По аналогии с той статьей возникла мысль, что программировать можно и пользователей тоже. Программировать их модель поведения, чтобы их развлекать и извлекать нужные нам ценности — платежи, удержание в игре, привлечение новых игроков. И одним из инструментов удержания служит набор функций в приложении, который можно условно назвать игровым циклом. Об этом мы и поговорим далее

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

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

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

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

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

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

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

От переводчика. Как часто вы обращаетесь к собственному домашнему фотоархиву? Конечно же, вы регулярно просматриваете свежие фотографии, иллюстрирующие совсем недавние события из вашей жизни. Еще вы посылаете их друзьям по электронной почте, размещаете в блогах и социальных сетях… Но проходит месяц — и воспоминания о событии стираются, и фотографии утрачивают былую значимость. Глядя на те же самые фото через год вы, возможно, вообще не вспомните, когда и зачем все это было снято. По мере разрастания фотоархива к вам приходит в голову вполне разумная идея: оставить лишь те фотографии, которые отражают действительно значимые события (например, свадьбу или защиту диссертации) и к которым вы будете время от времени обращаться​ Но чем больше времени проходит — тем менее осуществимым становится такой план. Вы просто физически не сможете просмотреть такое количество фотографий и определить, что нужно оставить, а что — удалить. Поэтому в такой ситуации вы, скорее всего, примете самое простое решение: приобретете жесткий диск большей емкости и перенесете фотоархив на него. Впрочем, к большинству фотографий вы все равно не будете обращаться.
Приведенный выше пример показывает, что частота обращения к документам со временем снижается. А теперь представьте себе, что речь идет не о домашнем фотоархиве, а об огромном массиве документов предприятия или организации. Для структурированного хранения документах в организациях внедряется специальное ПО — системы электронного архива (СЭА). В соответствии с определением, ставшим уже общепринятым и зафиксированным в стандарте MoReq, СЭА предназначены прежде всего для хранения бизнес-значимых документов. Однако часто бывает так, что в таких системах хранятся документы, утратившие свою значимость (например, видеозаписи выступлений на конференции по проблемам электронной коммерции, которые уже много лет как перестали быть актуальными или утратившие юридическую силу приказы и распоряжения, срок обязательного хранения которых давно истек).
Занимаясь разработкой и внедрением собственной системы электронного архива, мы часто сталкиваемся с тем, что вопросам экспертизы ценности переводимых в цифровой вид материалов в организациях в подавляющем большинстве случаев не уделяется внимания. В результате в систему вводится все подряд, без разбора. Ввод и хранение лишних документов всегда сопряжены с дополнительными временными и финансовыми затратами.
Как выстроить подход к управлению записями с учетом неизбежного уменьшения частоты обращения к документом? Как выработать политику архивного хранения с учетом темпов устаревания информации, характерных для нынешней эпохи?
Размышления на эту тему представлены в статье Сьюзан Гудман (США), специалиста по управлению записями Банка Америки.

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

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

От переводчика. Занимаясь разработкой и внедрением системы системы электронного архива, мы уделяем достаточно большое внимание проблемам теории и методологии ECM. Недавно на сайте консалтинговой компании Doculabs мы нашли интересную статью, посвященную организационно-методологическим аспектам проблем внедрения ECM-решений. Автор выделяет типовые случаи неудачного внедрения ECM и пытается проанализировать их причины. Многие из описываемых проблем актуальны и для современной российской практики.
Приглашаем к обсуждению всех, чья профессиональная деятельность так или иначе связана с ECM-проблематикой.

Неудачи, с которыми приходится сталкиваться при внедрении ECM-решений, можно условно разделить на 3 группы:

1. Неспособность адаптировать ECM-систему под нужды и потребности конкретной организации.
2. Неспособность уложиться в конкретные сроки: внедрение ECM-решений обычно занимает больше времени, чем это изначально предполагалось.
3. Невозможность уложиться в рамки планируемого бюджета.

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

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

От переводчика. Выбор ECM-системы — дело очень непростое. Публикаций, в которых описываются и сравниваются между собой различные программные решения — много, а вот лишенных рекламного характера материалов, представляющих собой беспристрастный анализ — мало. Сегодня мы хотели бы предложить вниманию наших читателей перевод статьи, написанной Нэнси Грэхем Морлэнд, сотрудницей Государственного архива штата Нью-Йорк. Автор занимает принципиально неангажированную позицию: в тексте даже не упоминаются названия каких-либо конкретных программных продуктов. Конечно, высказываемые в статье соображения во многом являются спорными. Но в то же время автор, документовед по специальности, смотрит на проблему выбора ECM-системы взглядом рядового пользователя и указывает на ряд моментов, на которые технические специалисты зачастую не обращают внимания.
Публикуя данный текст, мы также хотели бы пригласить читателей к обсуждению следующих вопросов: какие функции должно включать ПО для работы с электронными документами? каких функций, по вашему мнению, не хватает в используемых вами СЭД/СЭА.

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

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