Привет,
Грядёт JavaOne Russia 2013 в Москве! Уже давно открыт публичный Call For Papers, где до 15 февраля каждый желающий может заявить свой доклад. В этом посте мы размышляем над темами наших докладов. Пока что у нас такие предположения, и, продолжая традицию, будем рады услышать обратную связь от сообщества, что бы вам хотелось услышать больше, глубже и новее:
Читать полностью »
| На php отправка mail реализуется одной строчкой кода! А на java- нужно 3 недели??! (из разговоров с разработчиками и менеджерами) |
Статья не о том, как отправлять почту на java. Моя цель — показать сложности модульной разработки больших приложений (на примере разработки ERP River).
Только что вернулся с интересного мероприятия: более сотни студентов из четырнадцати университетов три дня писали код под руководством коммиттеров из Open Source проектов (одним из которых был Kotlin). И это только начало :)Читать полностью »
Добрый день/вечер/утро, уважаемые читатели и Вы, %username%!
Я занимаюсь разработкой приложений для Android, обожаю эту операционную систему и хочу поделиться своим опытом использования в своих проектах диалоговых окон. В первую очередь эта статья записка очень пригодится начинающим в области разработки для Android.
Также для новичков в этой отрасли рекомендую сперва прочитать вот этот пост уважаемого Hoorsh.
А теперь приступим к рассмотрению данного вопроса (у которого есть несколько подводных камней) под катом.
Читать полностью »
Думаю многимам знакома книга «Этюды для программистов» Чарльза Уэзерелла. Если нет, то здесь можно прочитать интервью с автором и небольшой обзор книги. Мне самому совсем недавно попала данная вещь в руки, и было решено обязательно реализовать одну из задачек.
Итак предлагаю разобрать с вами один из этюдов. Писать будем на Java, поработаем с графикой и GUI + разберем алгоритм перебора с возвратом для нахождения нашего решения. Мало вероятно, что статья заинтересует профи, но вот новичкам, а особенно тем, кто только изучает Java, статья может оказаться полезной.
Всем заинтересовавшимся – добро пожаловать!
Читать полностью »
Все начилось с того, что при разработке геопорталов с использованием ArcGis, заказчики все чаще стали говорить что-то типа: " Нам все нравится, а вот можно все тоже самое сделать, но с использованием открытого ПО", подразумевая при этом замену связки MSSQL+ ArcGis Server + ArcGis Javascript (Silverlight) Toolkit на Postgres (PostGis) + Geoserver + Openlayers.
Ну вобщем-то их понять можно т.к. меняется 1-2-3 млн руб на 0 руб. Особой проблемы в большинстве своем это не представляло, векторные данные переводятся либо через SHP файлы, либо через конвертеры из MSSQL в PostGis (либо просто через запросы SQL). Остался вопрос с растровыми данными. Например есть хорошо прорисованный, настроенный и многоуровневый кэш карты России. В ArcGis он хранится либо в компактном виде (в виде бандлов понятного только ArcGis формата) либо некомпактный, то есть тайлы карты просто лежат в директориях. Тут я обрадовался и подумал, что во втором-то случае точно будет все просто. А нет — тайлы конечно разбиты по уровням однако имеют странные имена и могут лежать в странных подпапках, а с геопривязкой этого кэша вобще беда.
Но потом пришло очень простое и быстрое решение — просканировать свой же сервис (так как сервис отдает тайлы по понятному URL вида "...MapServer/tile/Z/Y/X" где Z — номер уровня, а X и Y номера тайлов по горизонтали и вертикали соответственно). Теперь остался другой вопрос — как эти привязанные тайлы положить на Geoserver? В Geoserver для таких целей используется Image Pyramid Plugin, точнее не совсем для таких — его в основном используют для упрощения работы с гигантскими TIFF файлами, скрипт gdal_retile из пакета gdal проходится по TIFF файлу и создает множество мелких геопривязанных тайлов на разных уровнях, разбитых по папкам с номерами уровней.
Вот собственно и все исходные данные. По ним я сначала написал приложение на родном C#, но решил следовать путем настоящего OSS и переписал на Java, естественно выложив код на GitHub.
С каждым днем слово java все больше и больше воспринимается уже не как язык, а как платформа благодаря небезызвестному invokeDynamic. Именно поэтому сегодня я бы хотел поговорить про виртуальную java машину, а именно — об так называемых Performance опциях в Oracle HotSpot JVM. Потому что сегодня почти не встретить людей, которые знают что-то больше чем -Xmx, -Xms и -Xss. В свое время, когда я начал углубляться в тему, то обнаружил огромное количество интересной информации, которой и хочу поделится. Отправной точкой, понятное дело, послужила официальная документация от Oracle. А дальше — гугл, эксперименты и общение:
Начну, пожалуй, с самой интересной опции — DoEscapeAnalysis. Как многие из Вас знают, примитивы и ссылки на объекты создаются не в куче, а выделяются на стеке потока (256КБ по умолчанию для Hotspot). Вполне очевидно, что язык java не позволяет создавать объекты на стеке на прямую. Но это вполне себе может проделывать Ваша JVM 1.6 начиная с 14 апдейта.
Про то, как работает сам алгоритм можно прочитать тут (PDF). Если коротко, то:
Для реализации данного алгоритма строится и используется так называемый — граф связей (connection graph), по которому на этапе анализа (алгоритмов анализа — несколько) осуществляется проход для нахождения пересечений с другими потоками и методами.
Таким образом после прохода графа связей для любого объекта возможно одно из следующих следующих состояний:
Если объект NoEscape, то он может быть создан на стеке. Если объект NoEscape или ArgEscape, то операции синхронизации над ним могут быть удалены.
Вполне очевидно, что благодаря такого рода анализу, производительность отдельных частей программы может возрасти в разы. В синтетических тестах, на подобии этого:
for (int i = 0; i < 1000*1000*1000; i++) {
Foo foo = new Foo();
}
скорость выполнения может увеличится в 8-15 раз. Хотя, на казалось бы, очевидных случаях из практики о которых недавно писалось (тут и тут) EscapeAnalys не работает. Подозреваю, что это связано с размером стека.
Кстати, EscapeAnalysis как раз частично ответственен за известный спор про StringBuilder и StringBuffer. То есть, если Вы вдруг в методе использовали StringBuffer вместо StringBuilder, то EscapeAnalysis (в случае срабатывания) устранит блокировки для StringBuilder'а, после чего StringBuilder вполне превращается в StringBuilder.
Читать полностью »
Приветствую всех хабравчан!
Совсем недавно реализовывала интересную, на мой взгляд, задачу в андроид приложении и решила поделится опытом с вами.
Задача заключается в следующем: смена цветовой гаммы приложения по одному клику. Так называемая реализация скинов для приложения.
Опять на собеседованиях по Java спрашивают про hashCode и equals? А кто из собеседующих сам ответит на вопрос, как вычисляется Object.hashCode() и System.identityHashCode()? Насколько дорог вызов этих методов? Как их можно ускорить в HotSpot JVM? Держу пари, едва ли кто даст правильный ответ. Разве что, кто прочитает эту статью.
Читать полностью »
Один мой друг, историк по профессии, подкинул мне замечательную идею об использовании древней мнемонической и счетной систем в современной криптографии. В процессе его рассказов об узелковой письменности Инков, я начал соображать, что все новое — хорошо забытое старое и было бы не плохо как-то применить древний опыт в современном мире. Первое, что пришло в голову — криптография. Это самое очевидное — просто сконвертировать узлы с ниток в байты и шифр готов. С одной стороны все казалось понятным, но потом я вспомнил про криптостойкость и другие параметры шифров и понял, что не обладаю достаточным опытом и знаниями в области криптографии, чтобы в одиночку разработать новый шифр.
Дальше я решил попытаться представить некий эзотерический язык программирования, конструкции которого могут быть записаны с помощью узелковой письменности Кипу. Поначалу казалось, что это невозможно: я придумывал язык и пытался написать на нем программу вычисления факториала. Первые три черновика спецификаций ушли в урну: языки никуда не годились. Они выглядели как полагалось для эзотерических языков, но не помогали мне решать поставленную задачу, т.к. не были полными по Тьюрингу. Энтузиазм потихоньку угасал и эта задача казалась мне не по-плечу. Собравшись с силами, я решил, что если смогу написать программу вычисления факториала — то язык работает.
Четвертая версия языка оказалось удачной: я написал факториал, затем генерацию последовательности Фибоначи и дюжину простых примерчиков аля “сумма чисел от 0 до 99”. Язык получился что надо: необычный, крайне эзотерический, с простой и понятной идеей. Главное — язык может решить любую (ну или почти любую) задачу которую можно выразить в виде вычислимой функции.