Добрый день, сегодня хотелось бы рассказать, как наша команда работает с базами данных. У нас в компании в основном используется Oracle и в нашей команде много людей, кто умеет хорошо его готовить. Нам изначально хотелось получить полный доступ к его возможностям: иерархическим запросам, аналитическим функциям, передаче объектов и коллекций, как параметров запросов, и, может быть, если не будет другого способа — хинтам. Модель у нас не очень сложная, поэтому сознательно отказались от ORM.

В качестве основы взяли Apache DbUtils и сделали для него простую обёртку на Scala. Ниже я расскажу, как возможности Scala, особенно её последней версии 2.10, помогли упростить работу с базой данных.

А пытливых читателей, кто дочитает до конца, ждёт сюрприз.

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

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

Осторожно, 4 мегабайта!

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

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

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

Тернарный оператор ?:

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

Type var = condition ? valTrue : valFalse;

и

Type var;
if(condition)
  var = valTrue;
else
  var = valFalse;

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

Дисклеймер: для понимания этой статьи требуются начальные знания теории графов, в частности знание поиска в глубину, поиска в ширину и алгоритма Беллмана — Форда.

Введение

Наверняка вы сталкивались с задачами, которые приходилось решать перебором. А если вы занимались олимпиадным программированием, то точно видели NP-полные задачи, которые никто не умеет решать за полиномиальное время. Такими задачами, например, является поиск пути максимальной длины без самопересечений в графе и многим известная игра — судоку, обобщенная на размер . Полный перебор крайне долгий, ведь время его работы растёт экспоненциально относительно размера входных данных. Например, время поиска максимального пути в графе из 15 вершин наивным перебором становится заметным, а при 20 — очень долгим.

В этом посте я расскажу как можно оптимизировать большинство переборов, чтобы они стали работать на порядки быстрее.

JRE позволяет абстрагироваться от конкретной платформы, делая написание кросс-платформенного кода намного проще. Конечно до идеала Write once, run anywhere не дотягивает, но жизнь облегчает существенно.

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

Подавляющее большинство современных процессоров имеют кэш-память для хранения часто используемых данных. Кэш-память делится на блоки (Сache line). Механизмы реализующие Cache coherence обеспечивают синхронизацию кэш-памяти между ядрами процессора(ов) в компьютерной системе.

Термин false sharing означает доступ к разным объектам в программе, разделяющим один и тот же блок кэш-памяти. False sharing в многопотоковом приложении, когда в одном блоке оказываются переменные модифицируемые из разных потоков, ведет к снижению производительности и увеличению нагрузки на Cache coherence механизмы. Подробно о том как это происходит, можно прочесть в статье на эту тему.

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

Пакет java.util.concurrent, входящий в состав HotSpot JDK, предоставляет следующие инструменты для написания многопоточного кода:

• Atomic
• Locks
• Collections
• Synchronization points
• Executors
• Accumulators _jdk 1.8_

Решил внедрить АОП логирование на проект и не внедрил. Как и почему, собственно и хочу поделиться.

Я не буду описывать суть и принципы АОП, а опишу только те проблемы, с которыми я столкнулся, и решения которых заняло много времени.
У меня было в распоряжении Spring, WebLogic, google.com и проект, куда я хотел внедрить АОП логирование. Скажу сразу, до этого я никогда не работал с АОП.

Проблема № 1

Spring AOP – использует proxy-based подход.

Если у нас есть класс (СlassA) с методами (methodA, methodB), при этом methodB() вызывает methodA() и аспект (допустим after) который должен выполняться при вызове methodA():

[ english version ]

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

Поэтому было решено набросать свой, ведь это всего 3-5 классиков в данном случае. Основные требования: быстрота и динамическая генерация запросов. При этом быстрота это не просто тысячи RPS, а в идеале — когда стресс упирается только в пропускную способность сети и работает с любой свободной машины.

Не секрет, что уже около полугода RedHat продвигает собственный облачный продукт, причем не привычное хранилище файлов, а сервис для облачных вычислений, с бесплатной версией Developer Edition. В качестве одной из поддерживаемых платформ указывается Java, что для многих может оказаться весьма кстати на фоне достаточно малого числа бесплатных Java – хостингов. Причем, если брать java, то тут предлагается одна из современнейших платформ, а именно Jboss AS 7.1, что означает совместимость с большинством технологий и проектов, разрабатываемых под эгидой Jboss. Широкие возможности сервиса сочетаются с простотой, при этом разработчики настолько уверены в качестве и доступности сервиса, что не постеснялись даже написать про него «easy-peasy».

Недавно пришлось попробовать OpenShift в работе, как Java – хостинг для небольшого частного проекта. Впечатления, если кратко – да, у разработчиков RedHat всё получилось, все подробности далее…

    

Привет, хабражители! Сегодня я хотел бы рассказать о том, как можно воспользоваться бесплатным решением от RedHat для размещения своих сайтов в облаке на примере Play! Framework. Не буду описывать отдельно каждый из продуктов, т.к. про них уже не раз писали, расскажу лишь об их взаимодействии и моей схеме для автоматизации сборки и развертывания.

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

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

Основные требования — простота, возможность запуска в текстовом режиме и независимость от архитектуры.

Наверняка вы хоть раз видели химические источники света — светящиеся палочки, которые начинают работать после «переламывания». Внутри — стеклянная капсула, которая при этом ломается, и начинается какая-то мистическая химическая реакция. Мне всегда было интересно разобраться, как это работает.

Энергия связи молекул, освобождающаяся во время химической реакции — может выделится в виде тепла (к чему мы все привыкли), а в редких случаях может — в виде излучения кванта света. Излучение света во время химической реакции называется хемилюминесценцией. Существуют 2 наиболее распространенных реакции с хемилюминесценцией: окисление Люминола и окисление TCPO в присутствии органических красителей.

Отличие в том, что Люминол светится сам, а TCPO — передает энергию молекулам органического красителя (вроде Родамина), и таким образом можно управлять цветом свечения выбирая краситель. Про TCPO (включая его синтез) можно посмотреть на YouTube (использование синтез), а вариант с Люминолом — под катом.

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

В этот раз перейдём к коллекциям. Стандартная библиотека для коллекций в Scala настолько богата, что может предложить готовые методы даже для самых требовательных разработчиков. В каких случая применять какие методы обычно не описывается и всё познаётся на опыте. Обычно, в начале все узнают filter и map, на этом дело может ограничиться, ведь с определённой фантазией можно реализовать множество алгоритмов только на этих функциях. Однако, эти способы могут быть неоптимальны или рождать невозможные для предметной области результаты, которые, однако же, придётся обработать.

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

2 месяца назад e-Legion и JetBrains провели очередную конференцию для Scala-разработчиков в Санкт-Петербурге — Scaladev.

На мероприятии выступили представители из e-Legion, Jetbrains, Huawei Research, Grid Dynamics и GridGain. Выступление Павла Фатина (JetBrains) «Поддержка компиляции в Scala Plugin с использованием Zinc» уже выкладывали в блоге Jetbrains, кто пропустил — вот ссылка.

В этом же посте будет доклад и презентация Рафаэля bugzmanov Багманова из компании Grid Dynamics. В своем докладе он рассказал о своем опыте реализации типичного веб-приложения для enterprise-проекта на Scala.


Презентация

После закрытия Гуглом своих API для перевода проблема поиска онлайн-сервис для машинного перевода стала особенно актуальной.
В Интернете много сервисов перевода с громкими именами: Промт, Прагма и пр. Нет никакой проблемы в PHP смоделировать обращения к страницам сервисов и получить результаты перевода. Но есть проблема: почти все сервисы в ответ на простой GET или POST запрос отдают не результат перевода, а целиком страницу во всей красе, начиная с DTD. Как говорят у нас на Украине, “дурных нэма”.
После анализа было выяснено, что есть только два сервиса, которые отдают в ответ на запрос только результат перевода: Яндекс и Bing от Microsoft.

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


Элементарно. Так что теперь усложним задание — пусть наше значение имеет контекст. Пока что вы можете думать о контексте просто как о ящике, куда можно положить значение:


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

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

Так как карьера программиста тесно связана с процессором, неплохо бы знать как он работает.

Что происходит внутри процессора? Сколько времени уходит на исполнение одной инструкции? Что значит, когда новый процессор имеет 12, или 18, или даже 31-уровневый конвейер?

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

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

Эта статья рассказывает, как устроен вычислительный конвейер x86 процессора.

С распространением распределенных систем управления версиями (DVCS), таких как Git и Mercurial, я все чаще вижу дискуссии на тему правильного использования ветвления(брэнч) и слияния(мердж), и о том, как это укладывается в идею непрерывной интеграции (CI). В данном вопросе есть определенная неясность, особенно когда речь заходит о feature branching (ветвь на функциональность) и ее соответствие идеям CI.

Простой (изолированный) Feature Branch

Основная идея feature branch заключается в создании нового брэнча, когда вы начинаете работать над какой-то функциональностью. В DVCS вы делаете это в своем собственном репозитории, но те же принципы работают и в централизованных VCS.

Я проиллюстрирую свои мысли следующим рядом диаграмм. В них основная линия разработки (trunk) отмечена синим, и двое разработчиков, отмеченные зеленым и фиолетовым (Reverend Green и Professor Plum).