Одним из моих любимых развлечений в детстве была родительская печатная машинка. Когда она была свободна, я часами сидел и печатал: книги, брошюры, газеты. Каждое издание выходило тиражом в три экземпляра — под копирку. Иллюстрации и переплёт были выполнены вручную. У меня до сих пор сохранились некоторые забавные образцы моей тогдашней издательской деятельности.
Ты написал код, отправил его на ревью. Во время ревью тебе указали на ошибку в коде и вернули задачу на доработку.
Здесь мы не рассматриваем ошибки в бизнес-логике написанного кода — только ошибки на уровне интерпретатора/компилятора, из-за которых приложение «падает».
Как Unicode уничтожает большинство ваших предположений о том, как на самом деле работают строки
Когда речь идет о написании чего-то простого, мы, программисты, обычно действуем интуитивно. В случае с простыми вещами мы полагаемся на четкий набор предположений вместо конкретных знаний о том, как эти вещи работают. Например, мы предполагаем, что если b = a + 1, то b больше a, или что если мы применим функцию malloc для какого-то буфера, то получим необходимое количество памяти для записи. Мы не заглядываем в документацию всякий раз, когда имеем дело с мелочами.
Мы делаем так, потому что тотальная проверка замедлит работу. Однако если бы мы все-таки провели проверку, мы бы обнаружили, что обычно ошибаемся в своих предположениях. Существует арифметическое переполнение, в результате которого a + 1 может быть значительно меньше, чем a. Иногда malloc дает нам null вместо буфера и мы оказываемся в пролете.
Нам обычно приходится обжечься на таких вещах, чтобы хотя бы немного изменить свои предположения. И даже тогда мы обычно исправляем их весьма условно.
Столкнувшись с досадной ошибкой переполнения, мы можем скорректировать свое предположение о целых числах в виде «a + 1 больше a, если отсутствует вероятность, при которой a представляет собой очень большое число». И мы действуем исходя из этого, вместо того, чтобы обдумать четкие правила, по которым работает переполнение.
Уточненные предположения – это опыт. Чаще всего они позволяют нам работать быстрее и правильнее. Однако мы можем вообще переместить некоторые вещи, например, правильную обработку malloc, из нашей внутренней категории «простые вещи» во внутреннюю категорию «сложные вещи». И тогда мы действительно можем пойти и уточнить, как они работают.
Перевод статьи с сайта компании FilingDB, составляющей базу данных из документации европейских компаний
Согласно распространённым представлениям, извлечение текста из PDF не должно быть такой уж сложной задачей. Ведь вот он, текст, прямо у нас перед глазами, и люди постоянно и с большим успехом воспринимают содержимое PDF. Откуда взяться трудностям в автоматическом извлечении текста?
Оказывается, точно так же, как работа с именами людей сложна для алгоритмов из-за множества пограничных случаев и неправильных предположений, так и работа с PDF сложна из-за чрезвычайной гибкости PDF-формата.
Основная проблема в том, что PDF не предполагался как формат для ввода данных – его разрабатывали, как канал вывода, дающий возможность тонкой подстройки вида итогового документа.
Читать полностью »
Недавно мне пришлось столкнуться с необходимостью достать текст из офисных документов (docx, xlsx, rtf, doc, xls, odt и ods). Задача осложнялась требованием представить текст в формате xml без мусора с максимально удобной для дальнейшего парсинга структурой.
Решение использовать Interop сразу отпало по причине его громоздкости, во многом избыточности, а также необходимости устанавливать на сервер MS Office. В результате, решение было найдено и воплощено на внутреннем проекте. Однако, поиск оказался настолько сложен и не тривиален в силу отсутствия каких-либо общедоступных мануалов, что мной было принято решение написать в свободное от работы время библиотеку, которая решала бы указанную задачу, а также создать написать что-то вроде инструкции, чтобы разработчики прочитав ее смогли, хотя бы поверхностно, разобраться в вопросе.
Прежде, чем перейти к описанию найденного решения, предлагаю ознакомиться с некоторыми выводами, которые были сделаны в результате моих изысканий:
Сразу оговорюсь, что в настоящий момент библиотека еще не готова, но она активно пишется (на столько, на сколько это позволяет свободное время). Предполагается, что будут написаны отдельные посты для каждого формата и параллельно, вместе с их публикацией, будет обновляться репозиторий на гитхабе, откуда можно будет получить исходники.
Невозможно объективно измерить, какие девушки красивее: блондинки или брюнетки, смуглые или белокожие, высокие или миниатюрные. Но можно посчитать, какие черты внешности упоминают чаще, когда говорят о красоте.
У меня была неделя на эксперименты, наши движки анализа данных,16 тысяч русских романов и повестей XIX века и 15 тысяч современных длинных произведений. И, конечно, не было никаких размеченных данных.
Основная идея была в том, чтобы выделить из этой горы текстов фрагменты с описаниями красивых женщин, а потом из этих фрагментов извлечь частотные черты внешности.
Вот визуализация того, что получилось. Точнее, одного из распространённых вариантов.
Цвет глаз, волос, платье, рост, воспитание — всё это можно выделить из корпуса текстов.
Конечно, не всё так просто и однозначно как на рисунках, но примерное представление вы уже получили. Теперь давайте расскажу про детали и последовательность действий. Читать полностью »
В рамках своего проекта я столкнулся с задачей сделать текущий сайт компании мультиязычным. Более точно: создать возможность быстро и просто перевести сайт на английский, польский, итальянский и т.д.
Поиск в интернете показал, что существующие варианты создания мультиязычного сайта крайне громоздки и неэффективны. Подключать сторонние библиотеки зачастую проблемно, а советы по написанию своего решения связаны с большим объёмом однотипной работы.
Написание альтернативного метода смены локали заняло у меня всего несколько часов, а поддержание семантического единства и вовсе сводит к минимуму изменения при последующем добавлении новых страниц.
Исходные файлы примера сайта с автоматическим переводом можно скачать на github
Читать полностью »
На предыдущем уроке мы рассмотрели, как выводить многострочный текст с помощью параграфа. Описанный способ требует ручного обхода массива выводимых строк. На данном уроке мы рассмотрим альтернативный способ, лишенный этого недостатка. В его основе лежит интерфейс ksTextParam и метод ksTextEx.
Прежде чем перейти к рассмотрению документированных способов создания составных строк, нам нужно познакомиться с таким объектом, как параграф. Он представляет собой автоматически форматируемый блок текста, состоящий из нескольких строк. На данном уроке мы рассмотрим вопросы построения простых параграфов.
