Not invented here — источник инноваций и причина успеха?

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

Очень часто в компаниях выступают против синдрома «not invented here». Я, как менеджер проектов, прекрасно понимаю соображения такого толка. Велосипеды — это лишние затраты, удлинение сроков разработки, сложность и дороговизна поддержки продукта в будущем, зависимость от разработчиков велосипеда и все такое прочее.

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

Не случайно поэтому Гугл выделяет 20% на свободное творчество, и это рождает такие великолепные переосмысления старых вещей, как почтовый клиент Gmail.

Но обо все по порядку. В этой статье я хочу коротко рассказать о трех «велосипедах», которые произвели революцию в своей области.

Думаю многим известна особенность PostgreSQL, которая приводит к эффекту раздувания таблиц, или table bloat. Известно что она проявляет себя в случаях интенсивного обновления данных, как при частых UPDATE так и при INSERT/DELETE операциях. В результате такого раздувания снижается производительность. Рассмотрим почему это происходит и как с этим можно бороться.

Linux на моём компьютере уже 5 лет стоит как основная операционная система. Пришлось проходить через всякое: ставить разные дистрибутивы, как для фана, так и для работы. Почти все шесть лет я сидел на Gnome 2, и сейчас бы сидел, если бы не новый ноутбук, нормально работающий только на третьем ядре из-за каких-то драйверов. А с новым ядром пришла новая проблема: новые оболочки. В этом топике я просто опишу свои мысли насчет оболочек, чем они удобны или не удобны лично для меня. Так что, можете сразу ставить после каждого предложения ИМХО.

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

Это было примерно месяц назад. К нам в офис приехал Василий. Он топ-менеджер компании, производящей оборудование для театральных сцен. С порога заявил, что ему нужна MES-система или APS-система и что он еще не до конца решил, какая из них. «Почему именно MES-система?» — спросил я.

— Я уже несколько месяцев занимаюсь изучением вопроса, связанного с решением наших производственных проблем. Встречался с представителями нескольких компаний, производящих MES и APS системы. Они сказали, что их системы как раз и решают наши проблемы. Причем мне сказали, что только такие системы и способны решить наши проблемы. У вас тоже MES система?

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

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

В настоящей статье я хотел бы сделать обзор популярных алгоритмов для решения задачи нахождения максимальной общей подпоследовательности или LCS (longest common sequense). Так как акцент сделан на обучении, а не на реальном использовании, в качестве языка для реализации выбран Python, что позволит сократить количество кода и сконцентрироваться на основных идеях.

Открою не Америку, но шкатулку Пандоры: в Java-коде много бойлерплейта. Типовые геттеры, сеттеры и конструкторы, методы ленивой инициализации, методы toString, hashCode, equals, обработчики исключений, которые никогда не выбрасываются, закрывалки потоков, блоки синхронизации. Проблема заключается даже не в том, чтобы написать всё это — современные среды разработки справляются с такими задачами нажатием нескольких клавиш. Сложность в поддержании бойлерплейта в актуальном состоянии по мере внесения модификаций в код. А в некоторых случаях (многопоточность, реализация методов hashCode и equals) и сам шаблонный код написать без ошибок — далеко не простая задача. Одним из решений проблемы является генерация кода, и в этой статье я расскажу про проект Lombok — библиотеку, которая не только может избавить вас от бойлерплейта, но и сделать это максимально прозрачно, с минимальной конфигурацией и, что немаловажно, с поддержкой на уровне среды разработки.

Браузеры, поддерживающие HTML5, и платформа HTML5 для Windows 8 Metro сегодня становятся серьезными кандидатами для разработки современных игр.

Благодаря canvas, у вас есть доступ к аппаратно-ускоренной поверхности, на которой вы можете отображать контент вашей игры и с помощью некоторых трюков и ухищрений вы сможете достигнуть великолепной производительности рендеринга до 60 кадров в секунду. Подобная непрерывность действительно важна в играх, так как чем плавнее игра (анимация), тем лучше чувствует себя игрок.

Цель данной статьи — дать вам несколько подсказок, как выжать максимум мощности из HTML5 Canvas. Статья состоит из двух основных частей [вы читаете первую]. David Rousset скоро опубликует вторую часть.

В статье я буду показывать ключевые идеи на одном и том же примере — это эффект 2D-туннеля, который я написал для Coding4Fun-сессии на TechDays 2012 во Франции.

Вступление

Тернист и извилист путь Java-платформы к правильному способу записи строчек в лог-файлы. История logging в Java довольно познавательна в плане изучения особенностей Open Source, в том числе его взаимодействия с корпорациями и единичными программистами. Я собираюсь рассказать столько, сколько возможно, об истории развития Java logging, а также о том, к чему все пришло и как жить дальше.

Timsort, в отличии от всяких там «пузырьков» и «вставок», штука относительно новая — изобретен был в 2002 году Тимом Петерсом (в честь него и назван). С тех пор он уже стал стандартным алгоритмом сортировки в Python, OpenJDK 7 и Android JDK 1.5. А чтобы понять почему — достаточно взглянуть на вот эту табличку из Википедии.



Среди, на первый взгляд, огромного выбора в таблице есть всего 7 адекватных алгоритмов (со сложностью O(n logn) в среднем и худшем случае), среди которых только 2 могут похвастаться стабильностью и сложностью O(n) в лучшем случае. Один из этих двух — это давно и хорошо всем известная «Сортировка с помощью двоичного дерева». А вот второй как-раз таки Timsort.

Алгоритм построен на той идее, что в реальном мире сортируемый массив данных часто содержат в себе упорядоченные (не важно, по возрастанию или по убыванию) подмассивы. Это и вправду часто так. На таких данных Timsort рвёт в клочья все остальные алгоритмы.

Статья "Недопонимание CAP-теоремы" и комментарии к ней свидетельствуют, что непонимание действительно есть. И связано оно не только с неправильным толкованием термина «partitioning», но и с ментальными ошибками на других уровнях. Попробую внести ясность.

В рамках JSR-299 “Contexts and Dependency Injection for the Java EE platform” (ранее WebBeans) была разработана спецификация описывающая реализацию паттерна внедрения зависимости, включенная в состав Java EE 6. Эталонной реализацией является фреймворк Weld, о котором и пойдет речь в данной статье.

К сожалению в сети не так много русскоязычной информации о нем. Скорее всего это связано с тем, что Spring IOC является синонимом dependency injection в Java Enterprise приложениях. Есть конечно еще Google Guice, но он тоже не так популярен.

В статье хотелось бы рассказать об основных преимуществах и недостатках Weld.

К сожалению, на данный момент Hibernate не обладает необходимыми механизмами интеграции для работы в OSGi среде, хотя подвижки в этом направлении заметны (начальная OSGi-фикация путём разделения пакетов в 4-ой ветке). Это побуждает разрабатывать собственные механизмы, что требует немалых дополнительных усилий.

Эта статья предназначается для тех разработчиков, кому интересно: как можно использовать Hibernate со связкой Spring+OSGi; что такое паттерн Extender; как реализовать ClassLoader со специфичным поведением; как поддерживается Hibernate в Spring Framework и немного о расширении этого кода. Разумеется, для чтения статьи необходимо разбираться в технологиях Spring, Hibernate, OSGi, а также понимать основные проблемы выполнения кода в многопоточной среде. Те же кто незнаком с использованием Spring Framework в OSGi среде могут обратиться к вводной статье «Использование Spring в OSGi-контейнере».

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