Возможно, кто-то еще помнит, как писали SMS, а иногда и письма, «транслитом». Но зачем транслитерация сегодня, когда везде уже unicode? К сожалению, унаследованные приложения выходят из эксплуатации намного медленнее, чем хотелось бы. Например, и сегодня используются томографы, не допускающие кириллицу в именах пациентов. При том, что информационная система, используемая тем же отделением, прекрасно кириллицу понимает. И оператору томографа нужно не просто позвать пациента на исследование, но и правильно записать его фамилию в какие-нибудь документы. Похожие ситуации могут встретится в разных местах.

То есть, возникает задача как-то передать текстовые данные в унаследованную систему, чтобы:

• человек — оператор унаследованной системы смог прочесть полученный текст «по звучанию»
• при необходимости можно было бы однозначно восстановить исходный кириллический текст

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

1. использовать только буквы в узком смысле, без знаков препинания и диакритических элементов (это заодно позволит сохранить регистр)
2. каждую исходную букву преобразовывать независимо от остальных (без сложностей вроде «в начале / в конце слова» и т.п.)
3. замены как можно более короткие, в идеале одно-буквенные
4. правила обратного преобразованния как можно проще, например, замены должны соответствовать условию Фано
5. близкие по звучанию замены, в представлении «обычного человека» — на практике это некая смесь из латыни, английской, французской, немецкой и, иногда, испанской фонетики

Конечно, перечисленное не совсем требования (кроме первых двух), а, скорее, эвристики.

Можно найти много готовых вариантов транслитерации кириллицы в латиницу. Но среди них не нашлось ничего, что бы удовлетворяло всем требованиям в приемлемой степени. То использует диакритические символы, как стандарты, то выбрасывает буквы (обычно «Ъ»), то предлагают необратимые (щ —> shch) или фонетически дикие (ш —> w) варианты замены, или имеют другие фатальные недостатки.

Значит, делаем свой велосипед. Собственно, нужно составить таблицу соответствия, и описать алгоритм преобразования туда и обратно.

Как находить тексты похожие по смыслу? Какие есть алгоритмы для поиска текстов одной тематики? – Вопросы регулярно возникающие на различных программистских форумах. Сегодня я расскажу об одном из подходов, которым активно пользуются поисковые гиганты и который звучит чем-то вроде мантры для SEO aka поисковых оптимизаторов. Этот подход называет латентно-семантический анализ (LSA), он же латентно-семантическое индексирование (LSI)

Это логическое продолжение статьи "Построение графа социальной сети с помощью Drupal и Feeds"

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

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

В продолжение темы, начатой статьёй «13 причин не быть управленцем» и продолженной в «5 причин быть управленцем», хочу обратить внимание на такой аспект работы абстрактных «управленцев», как продукт их труда. Из своего опыта знаю, что недостаточное понимание этого аспекта свойственно как разработчикам, так и самим «управленцам». А где недостаточное понимание – там и конфликты, и холивары, и пренебрежительное отношение как к собственной работе, так и к работе коллег.

Мартин Л. Эббот и Майкл Т. Фишер, авторы книги «Искусство масштабируемости», перечисляют наиболее распространенные архитектурные, организационные и технологические проблемы масштабировании в product-группах. Список был сформирован на основе их опыта, а также в ходе коммуникаций с клиентами и лег в основу первой книги.

Архитектурные ошибки

Доброго времени суток. Это статья — перевод заинтересовавшего меня поста в блоге аспиранта Университета штата Нью-Йорк в Стоуни-Брук. Статья в доступной форме описывает основные концепции функционального программирования, их преимущества и недостатки. Думаю она будет полезна широкому кругу читателей, которые сомневаются, нужно ли им углубляться в мир функционального программирования или нет. Пожелания, предложения и замечания по переводу и терминологии принимаются по личной почте.

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

UPD: альтернативный вариант перевода вы можете найти на rsdn (спасибо flamingo за ссылку).

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



Многие из нас помнят

'до Java 7' мучения:

        BufferedReader reader = null;
        try {
            reader = new BufferedReader(
                        new InputStreamReader(
                            new FileInputStream(FILE_NAME), Charset.forName("UTF-8")));
            String line;
            while ((line = reader.readLine()) != null) {
                System.out.println(line);
            }
        } catch (IOException e) {
            // log error
        } finally {
            if (reader != null) {
                try {
                    reader.close();
                } catch (IOException e) {
                    // log warning
                }
            }
        }

Новый тренд на HighLoad++ — множество докладов об использовании оперативной памяти. Слово Константину Осипову, разработчику платформы Tarantool, автору доклада «Что особенного в СУБД для данных в оперативной памяти».

Ты отвечал в MySQL за производительность, как так получилось, что ты решил разрабатывать свою СУБД?

В MySQL я руководил одной из команд разработки сервера, за производительность там отвечали все.

MySQL по многим параметрам был работой мечты, но, к сожалению после того, как мы стали частью Oracle, многое изменилось.

Несколько моих коллег ушли в MariaDB, кто-то основал свою компанию (SeveralNines, FromDual). Я никогда не чувствовал себя «недогруженным», а с уходом многих ключевых разработчиков работа вообще превратилась в марафон по передаче знаний. Сопротивление поглощению, желание начать всё с чистого листа, бунт против медленного принятия решений большой компанией, нежелание по разным причинам уезжать в США, в конце концов, хорошее предложение от Mail.Ru, которому к этому моменту уже было около года — и я ушёл.

Если бы знал, куда ухожу, ещё десять раз подумал бы. Иногда вообще не было веры, что удастся сделать что-то полезное, чем будут пользоваться за пределами Mail.Ru, да и сейчас Tarantool очень далёк пока от «идеальной СУБД».

Мы продолжаем публиковать материалы с летней конференции Bitrix Summer Fest. На этот раз хотим поделиться выступлением Александра Сербула, посвящённым текущим трендам в сфере машинного обучения, доступным методикам, а также практическим способам использования математики для увеличения конверсии и удержания клиентов.

Материал ни в коем случае не претендует быть формальным и научно строгим. Воспринимайте его как лёгкое, весёлое, полезное и ознакомительное «чтиво».

8 октября 2015 года SanDisk Corporation и HP объявили о начале долгосрочного партнёрства, которое направлено на разработку новой технологии в категории SCM (Storage Class Memory). Ядром сотрудничества станут наработки Hewlett-Packard в области создания запоминающего устройства, основанного на концепции мемристора, и опыт SanDisk, связанный с энергонезависимой памятью ReRam.



Усилия компаний в данном проекте направлены на создание новых корпоративных решений, построенных по технологии Memory-Driving Computing. Это – компьютерная архитектура, в которой память играет ключевую роль в выполнении вычислений. Кроме того, сотрудничество будет распространяться и на оснащение решений HP для центров обработки данных твердотельными накопителями (SSD, Solid State Drives) от SanDisk.

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

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

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

В последние годы логический момент для этого, казалось бы, настал. Стоимость оперативной памяти падала, падала, и упала совсем. Еще в начале века казалось, что 256 МБ памяти для сервера — это нормально, и даже много. Сегодня нас не удивишь параметром 256 ГБ оперативной памяти на сервере начального уровня, а с промышленными серверами вообще настал полный коммунизм, любой благородный дон может набрать хоть терабайт оперативной памяти на сервере, если захочет.

В последние несколько лет MongoDB приобрела огромную популярность среди разработчиков. То и дело в интернете появляются всякие статьи, как очередной молодой популярный проект выкинул на свалку истории привычные РСУБД, взял в качестве основной базы данных MongoDB, выстроил инфраструктуру вокруг неё, и как все после этого стало прекрасно. Даже появляются новые фреймворки и библиотеки, которые строят свою архитектуру целиком на Mongo (Meteor.js например).

По долгу работы я примерно 3 года занимаюсь разработкой и поддержкой нескольких проектов, которые используют MongoDB в качестве основной БД, и в этой статье хочу рассказать, почему на мой взгляд с MongoDB далеко не все так просто, как написано в мануалах, и к чему вы должны быть готовы, если вдруг решите взять MongoDB в качестве основной БД в ваш новый модный стартап :-)

Все что описано ниже можно воспроизвести с использованием библиотеки PyMongo для работы с MongoDB из языка программирования Python. Однако скорее всего с аналогичными ситуациями вы можете столкнуться и при использовании других библиотек для других языков программирования.

или «Прекратите характеризовать хранилища данных как CP или AP»

Джеф Ходжес в своем прекрасном посте «Заметки о распределенных системах для новичков» рекомендует использовать САР теорему для критики найденных решений. Многие, похоже, восприняли этот совет слишком близко к сердцу, описывая свои системы как «СР» (согласованность данных, но без постоянной доступности при сетевой распределенности), «АР» (доступность без согласованного состояния при сетевой распределенности), или иногда «СА» (означает «Я всё ещё не читал статью Коды (Coda Hale) почти 5-летней давности»).

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

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

САР использует слишком узкое определение

Если вы хотите ссылаться на САР как на теорему (а не на расплывчатый концепт в маркетинговых материалах к вашей базе данных), вы должны быть точны. Математика требует точности. Доказательство сохраняется только если вы вкладывается в слова, то же самое значение, что было использовано при доказательстве. И оно опирается на очень точные определения:

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

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

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

«Люди сталкиваются с проблемами, когда начинают активно пользоваться компьютером», говорит 25-летний основатель компании DriverPack Solution (DPS) Артур Кузяков. Многие из проблем пользователей Windows, по словам Кузякова, связаны с установкой драйверов.

DPS устанавливает драйвера автоматически. К 2014 году программа принесла своему создателю порядка $1 миллиона чистой прибыли.

Вот уже как неделю английская версия the art of command line висит в секции trending на Github. Для себя я нашел этот материал невероятно полезным и решил помочь сообществу его переводом на русский язык. В переводе наверняка есть несколько недоработок, поэтому милости прошу слать пулл-реквесты мне сюда или автору оригинальной работы Joshua Levy вот сюда. (Если PR отправите мне, то я после того, как пересмотрю изменения отправлю их в мастер-бранч Джоша). Отдельное спасибо jtraub за помощь и исправление опечаток.

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