После мучений с отладкой сложных MVEL скриптов + MavenClassloader, обнаружил, что механизм динамического разрешения зависимостей есть в языке Groovy. К тому же отладка Groovy скриптов возможна и в Idea и в Eclipse.



Вы спросите зачем нужно динамическое разрешение зависимостей? Некоторые вещи проще делать так, а некоторые возможно только так.

В публикации вы найдете работающее решение для Groovy в виде одного jar файла и загрузчик классов из репозитариев maven для Java приложения. Узнаете про особенности работы Grape «из коробки». Чтобы не быть голословным и были понятны возможности Grape…

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

С чего все началось, оно же «А зачем оно мне вообще надо?»:

1. хотелось изучить что-то новое и полезное в производстве;
2. надоело писать много букв на Java, но и радикально переписывать все, скажем на Python, совсем не хотелось;

С учетом таких желаний выбор пал на обзор альтернативных JVM-based языков.
После обзора остановились на Scala. Понравились компактный синтаксис, strong typing, возможность писать в ОО-стиле и заявленное хорошее взаимодейтствие с Java-кодом в обе стороны. Тот факт, что Scala уже активно используют такие крупные компании, как Twitter, LinkedIn, Foursquare и так далее, внушил определенную уверенность в будущем языка.
У нас уже имелся проект на Maven с юнит-тестами на JUnit, поэтому важно было легко включить Scala без существенных затрат на адаптацию инфраструктуры.
Итак, по порядку.

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

Но сначала обо мне. Меня зовут Дэвид Поллак.

Пару недель назад (статья написана в августе — прим. перев.) мы описывали новую систему классов в ES6 в тривиальных случаях создания конструктора объекта. Мы показали, как можно писать код типа такого:

class Circle {
    constructor(radius) {
        this.radius = radius;
        Circle.circlesMade++;
    };

    static draw(circle, canvas) {
        // Canvas drawing code
    };

    static get circlesMade() {
        return !this._count ? 0 : this._count;
    };
    static set circlesMade(val) {
        this._count = val;
    };

    area() {
        return Math.pow(this.radius, 2) * Math.PI;
    };

    get radius() {
        return this._radius;
    };
    set radius(radius) {
        if (!Number.isInteger(radius))
            throw new Error("Circle radius must be an integer.");
        this._radius = radius;
    };
}

К сожалению (как некоторые заметили), у нас не было тогда времени чтобы поговорить о всей мощи ES6 классов. Как и в традиционных системах классов (а-ля Java и С++), в ES6 возможно наследование, когда один класс берет за базу другой и расширяет его.

Кто я

Я — Александр Кашеверов. По образованию — магистр радиофизики. По профессии — веб-разработчик, работаю в компании DataArt с 2011 года, с 2009 увлекаюсь IT и веб-технологиями.

О чем статья, коротко

Рассмотрим, что такое веб-компоненты и polymer. Немного поразмышляем на тему развития веба. Посмотрим на технические детали, примеры, поддержку браузерами, тестирование. Коротко, понятно, по делу. С картинками.

Вступление

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

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

Для уменьшения головной боли хорошо бы, если в контексте веб:

• CSS не пересекался.
• Области видимости JS не пересекались.
• HTML был понятным и читаемым, никаких лишних элементов.

Пару месяцев назад я взяла на себя обязательство по самопросвещению. Есть в иных конторах такая тема — сотрудника, раз в полгода ревьюят и говорят «давай к следующему ревью ты изучишь Spring, паттерны (какие?) и функциональное программирование!» Идея была бы неплоха если бы цели не ставили так размыто. Пропустим пока спринг и паттерны — на выходных я бросилась в атаку на ФП.

Общие-туманные сведения о ФП у меня конечно были — анонимные классы в Java я писать умею — с похожими способностями Python и JavaScript знакома.

Начну с простых упражнений на Scala — решила я. Выбрала Scala поскольку основной рабочий инструмент у нас Java — ну были еще варианты Clojure, Groovy и Java8 (что-то еще?) — но с ними авось попробую потом.

Поставила себе цели (а правильно ли я ФП поняла?):

• Решать задачи в функциональном стиле
• Т.е. по возможности не использовать явных циклов и ветвлений
• А также избегать мутабельных коллекций и т.п.

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

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

Способы «общения» компонентов

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

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



Это чем-то напоминает WI-FI в кафе, когда все могут обмениваться сообщениями со всеми, но при этом есть роутер (диспетчер), который обеспечивает существование «эфира» и отдает сообщения только тем, кому они адресованы.

Такая организация позволяет, например, «бесплатно» получить слабое связывание компонентов. Недостаток ее в том, что при росте числа компонентов и соответственно числа событий становится сложно уследить за именами событий и за тем, кому какие события нужны для правильной работы. Появляются пространства имен и имена событий из чего-то типа «Событие1» превращаются в «Состояние_приложения1.Компонент2.Событие1». И что совсем невозможно делать при такой организации это компоновать события. Например требование «сделай что-то когда событие Б возникнет после двух событий A» выливается в тонну локальных переменных, хранящих последние данные из событий и счетчики самих событий.

Те, кто хоть немного знаком с проектом OpenStreetMap, вероятно, слышали о паре принципов, которые заложены в его основу: «any tags you like» и тот факт, что первично в этом проекте наполнение картографической базы данных, а не то, как содержимое этой базы отображает стиль Standard на osm.org. Но так ли все хорошо и радужно с семантической структурой этой базы данных, учитывая первый принцип? Читая русскоязычную ветку форума OSM, я решил разобраться в ситуации и описать ее здесь.

Примечание переводчика. В будущей версии Scala (“Don Giovanni”) анонсирована поддержка типов объединения (union types). Miles Sabin, широко известный в узких кругах как создатель Shapeless, демонстрирует в этой статье 2011 года, как создать типы объединения уже сейчас.
UPD. Представленный в статье подход не позволяет получить настоящих типов объединения и кроме того может существенно повлиять на время компиляции. Типы пересечения (A with B), использованные в статье, также отличаются от классических, поскольку не обладают свойством коммутативности. Подробности об экспериментальном проекте Dotty, в рамках которого будут решены эти и другие проблемы, можно посмотреть в замечательной презентации Дмитрия Петрашко darkdimius — разработчика компилятора Scala в EPFL.

Scala имеет очень выразительную систему типов. Однако она не включает (по крайней мере как примитивы) всех вожделенных элементов. Есть несколько поистине полезных типов, подпадающих под эту категорию — это типы полиморфных функций высшего ранга (higher-rank) и рекурсивные структурные типы. Но о них я расскажу подробнее в следующих постах, а сегодня я собираюсь показать вам, как в Scala мы можем создать типы объединения (union types). В ходе объяснения я пролью немного света на изоморфизм Карри-Ховарда и покажу, как использовать его в наших целях.

Много свободного времени только у студентов. Если вы не студент, то должны появиться очень веские причины для того, чтобы начать изучать новый язык программирования. Особенно это касается Java-программистов, потому что этот язык является лидером в своём сегменте. Тем не менее причины для изучения нового языка есть.

Апериодическая мозаика Соколара-Тейлора

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

10. Синъити Мотидзуки заявил о доказательстве им abc-гипотезы. Событие попало в конец списка, поскольку до сих пор его доказательство не поддержано большим кругом математиков. Иначе оно занимало бы первое место. А пока, к разочарованию заинтересованных сторон, оно находится в лимбе.

9. Тернарная проблема Гольдбаха. «Начиная с 7, любое нечётное число является суммой трёх простых». Ещё с 1937 года это утверждение верно для достаточно больших нечётных чисел, но в 2013 году перуанский математик Харальд Гельфготт проверил это утверждение на компьютере для чисел вплоть до 10³⁰. Независимо от него это сделал и Дэвид Плат.

Разрешите представить вам перевод статьи Нолана Лоусона «У нас проблемы с промисами», одной из лучших по теме из тех, что мне доводилось читать.

У нас проблемы с промисами

Дорогие JavaScript разработчики, настал момент признать это — у нас проблемы с промисами.

Нет, не с самими промисами. Их реализация по спецификации A+ превосходна. Основная проблема, которая сама предстала передо мной за годы наблюдений за тем, как многие программисты борются с богатыми на промисы API, заключается в следующем:

— Многие из нас используют промисы без действительного их понимания.

Если вы мне не верите, решите такую задачку:

Вопрос: В чем разница между этими четырьмя вариантами использования промисов?

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);

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

В данной статье я бы хотел рассказать вам о том, как сделать автоподгружаемый список простейшим в реализации для разработчика и максимально эффективным и быстрым для пользователя. А также о том, как нам в этом здорово поможет RxJava с ее главной догмой — «Everything is Stream!»

Компания Microsoft активно выпускает новые версии TypeScript. Товарищи разработчики объявили о выпуске бета версии TS версии 1.6 аж второго сентября. А уже 16 сентября был выпущен релиз. Скоростные ребята. Но при этом релиз как-то прошел незамеченным (не для всех, но все же). На Хабре как-то не было упоминаний (я не нашел). А посему немного информации по улучшениям.

Одна из мощных фич этой версии заключается в нативной поддержке синтаксиса React/JSX. Но это не все. Вот перечень некоторых нововведений:

• Генераторы ES6
• Локальные типы
• Алиасы на генерик типы
• Классовые выражения (анонимные классы)
• Поддержка JSX
• Абстрактные классы и методы
• Новый флаг –init
• Новая секция “exclude” в конфигурационном файле tsconfig.json

Рассмотрим наиболее интересные из них. Го под кат, если интересно.

Ну, на самом деле не очень…

Когда-то мы публиковали на Хабре курс по машинному обучению от Константина Воронцова из Школы анализа данных. Нам тогда предлагали сделать из этого полноценный курс с домашними заданиями и разместить его на Курсере.

И сегодня мы хотим сказать, что наконец можем выполнить все эти пожелания. В январе на Курсере пройдёт курс, организованный совместно Яндексом (Школой анализа данных) и ВШЭ. Записаться на него можно уже сейчас: www.coursera.org/learn/introduction-machine-learning.


Сооснователь Coursera Дафна Коллер в офисе Яндекса

Курс продлится семь недель. Это означает, что по сравнению с ШАДовским двухсеместровым курсом он будет заметно упрощен. Однако в эти семь недель мы попытались вместить только то, что точно пригодится на практике, и какие-то базовые вещи, которые нельзя не знать. В итоге получился идеальный русскоязычный курс для первого знакомства с машинным обучением.

Кроме того, мы верим, что после прохождения курса у человека должна остаться не только теория в голове, но и скилл «в пальцах». Поэтому все практические задания построены вокруг использования библиотеки scikit-learn (Python). Получается, что после прохождения нашего курса человек сможет сам решать задачи анализа данных, и ему будет проще развиваться дальше.

Под катом можно прочитать подробнее обо всех авторах курса и узнать его примерное содержание.

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

startReadSocket((data) -> {
   startWriteFile(data, (result) -> {
      if (result == ok) ...
   });
});

мы можем переписать так:

data = readSocket();
result = writeFile(data);
if (result == ok) ...

Здесь readSocket() и writeFile() — сопрограммы, в которых асинхронные операции вызываются следующим образом:

byte[] readSocket() {
    byte[] result = null;
    startReadSocket((data) -> {
	    result = data;
	    resume();
    });
    yield();
    return result;
}

Методы yield() и resume() сохраняют и восстанавливают контекст выполнения, со всеми фреймами и локальными переменными. Происходит следующее: при вызове readSocket() мы планируем асинхронную операцию вызовом startReadSocket() и выполняем yield(). Yield() сохраняет контекст выполнения и поток завершается (возвращается в пул). Когда асинхронная операция будет выполнена, мы вызовем resume() перед выходом из callback'a, и тем самым возобновим выполнение кода. Управление снова получит основная функция, которая вызовет writeFile(). writeFile() устроен аналогично, и всё повторится.

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

У нас вышла книга Мурата Йенера и Алекса Фидома.

Книга «Java EE. Паттерны проектирования для профессионалов» — незаменимый ресурс для всех, кто желает более эффективно работать с Java EE, а также единственная книга, в которой рассмотрены как теория, так и практика использования паттернов проектирования на примерах реальных прикладных задач.

Авторы знакомят читателя и с фундаментальными, и с наиболее передовыми возможностями Java EE 7, досконально рассматривают каждый из паттернов и демонстрируют, как эти паттерны применяются при решении повседневных прикладных задач.

Как я делал свою первую карту на Leaflet.js.

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

Итак задание было следующее: есть черно-белый планшет (маленький кусок карты города) размером 5913x7863 пикселей в формате .bmp + .shp слои.

(изначально карты были отрисованы в формате .dwg (формат автокада), но это закрытый формат и с ним ничего не сделаешь, поэтому ребятам пришлось сохранить каждый слой отдельно в .shp + атрибутивные данные в .dbf)

Из этого всего нужно сделать онлайн карту, основной функционал которой — это вывод атрибутов при нажатии на слой и включение/отключение этих слоёв.

Выбор пал на leaflet.js, так как это оболочка с открытым кодом, на ней сделаны OSM и мой любимый 2GIS. К тому же он хорошо работает на мобильных устройствах.