Java *

Apache Cassandra — это одна из популярных распределенных дисковых NoSQL баз данных с открытым исходным кодом. Она применяется в ключевых частях инфраструктуры такими гигантами как Netflix, eBay, Expedia, и снискала популярность за свою скорость, способность линейно масштабироваться на тысячи узлов и “best-in-class” репликацию между различными центрами обработки данных.

Apache Ignite — это In-Memory Computing Platform, платформа для распределенного хранения данных в оперативной памяти и распределенных вычислений по ним в реальном времени с поддержкой JCache, SQL99, ACID-транзакциями и базовой алгеброй машинного обучения.

Apache Cassandra является классическим решением в своей области. Как и в случае с любым специализированным решением, её преимущества достигнуты благодаря ряду компромиссов, значительная часть которых вызвана ограничениями дисковых хранилищ данных. Cassandra оптимизирована под максимально быструю работу с ними в ущерб остальному. Примеры компромиссов: отсутствие ACID-транзакций и поддержки SQL, невозможность произвольных транзакционных и аналитических транзакций, если под них заранее не адаптированы данные. Эти компромиссы, в свою очередь, вызывают закономерные затруднения у пользователей, приводя к некорректному использованию продукта и негативному опыту, либо вынуждая разделять данные между различными видами хранилищ, фрагментируя инфраструктуру и усложняя логику сохранения данных в приложениях.

Возможное решение проблемы — использование Cassandra в связке с Apache Ignite. Это позволит сохранить ключевые преимущества Cassandra, при этом скомпенсировав ее недостатки за счет симбиоза двух систем.

Как? Читайте дальше, и смотрите пример кода.

Давно ли вы участвовали в лотерее или розыгрыше? Приходилось ли вам самим их устраивать? Даже если ответы: никогда и нет, уверен, что вы знаете что это такое.

А какие у вас ассоциации от слов «лотерея» и «розыгрыш»? У меня — разноцветные шары с номерами и лотерейная машина, из которой разноцветные шары выпадают по одному и определяют победителя.

Вот и мне некоторое время назад понадобилось “определить” победителей розыгрыша бесплатных места на курс “Разработчик Java” в Otus.ru. Задача звучала просто: есть N email-ов, нужно выбрать среди них случайным образом M email-ов тех, кто будет учиться бесплатно.

Сложность задачи была в том, что это были email-ы всех, кто успешно прошел входное тестирование курса. То есть email-ы программистов. Я представил себе, как я “достаю из кармана” M email-ов и говорю: “Вот эти победили”. И… мне никто не верит. Даже если победители начинают радостно писать в общий чат: “Спасибо, как мы рады!”, мне все равно никто из оставшихся не поверит. Да я бы и сам не поверил, если бы мне просто сказали «победили эти».



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

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

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

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

Продолжаем рассказ о языке цейлон. В первой части статьи Сeylon выступал как гость на поле Kotlin. То есть брались сильные стороны и пытались их сравнить с Ceylon.

В этой части Ceylon выступит как хозяин, и перечислим те вещи, которые близки к уникальным и которые являются сильными сторонами Ceylon.

Поехали:

Наш сегодняшний собеседник – Dave Cramer, один из ключевых контрибьюторов в PostgreSQL, автор и мэнтейнер драйвера JDBC для Посгреса на протяжении более 15 лет.

Dave не очень часто выступает на публике. Нам крупно повезло, он согласился приехать на PG Day'17 Russia, чтобы провести практикум / мастер-класс по оптимизации и эффективному использованию Java в PostgreSQL вместе со своими коллегами-контрибьюторами в pgjdbc, Álvaro Hernández Tortosa и Владимиром Ситниковым. Не менее интересным намечается доклад Дэйва, посвященный скрытым возможностям драйвера.

Беседа получилась интересная. Дэйв – очень лаконичный собеседник, отвечающий коротко и по делу. Нам удалось обстоятельно поговорить о текущем состоянии дел в разработке драйвера JDBC и роли Дэйва в этом процессе. Он также поделился своим мнением о применении Java для разработки хранимых процедур и видением текущего состояния международного сообщества PostgreSQL. Не оставили мы без внимания и традиционный анонс предстоящего мастер-класса.



PG Day: Dave, расскажи вкратце о себе: кто ты, чем занимаешься, как проводишь свободное время?

Dave: Привет, меня зовут Дэйв Крамер, я работаю с языком PostgreSQL уже 15-16 лет, начиная с 2000-го года, и основной сферой моей деятельности здесь является работа с драйвером JDBC, потому что раньше я был программистом Java. Я также занимался некоторыми процедурными языками, например, pl/R. Что меня интересует в PostgreSQL? Продвижение сообщества, его развитие.

В середине 2013 с выходом Java 8, язык начал поддерживать lambda-выражения, с тех пор минуло 4 года, было выпущено множество update-ов, грядет уже и выход Java 9 (которую, вероятно, мы сможем увидеть в этом году, не смотря на постоянные переносы сроков), таким образом на стыке времён, хотелось бы подвести итоги и оценить производительность нового в java и старого, как мир инструмента, дав ему количественную оценку.

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

Приступим.

Приветствую, читатель!

Хочу познакомить тебя с молодой, но многообещающей библиотекой Replication Framework для платформы .NET (возможно, при наличии достаточного интереса к теме в дальнейшем будет также реализована Java-версия). Библиотека является портабельной (portable) и может быть использована в любом проекте под Microsoft .NET или Mono.

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

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

Для создания фреймворка будем использовать Java-аннотации и Java Reflection API.

Итак, начнем.

В нашем онлайн-университете для программистов открылся новый факультет. Теперь в GeekUniversity студенты смогут освоить Java-разработку на Middle-уровне и гарантированно начать карьеру сразу после обучения.

GeekUniversity — совместный образовательный проект Mail.Ru Group и IT-портала GeekBrains. Программу обучения и спецкурсы для факультета разрабатывают Avito, Альфа-банк, МТС, Тинькофф, DeliveryClub.

Привет, Хабр! Есть несколько способов проверять аргументы на правильность. Например, для проверки на null можно использовать:

1. if (!ReferenceEquals(arg, null)) throw…
2. Code Contracts: Contract.Requires(!ReferenceEquals(arg, null))
3. Guard.IsNotNull(arg, nameof(arg))

В статье я рассмотрю только третий вариант (все примеры кода — для C#, однако некоторые из них будут полезны и в Java).

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

@BenchmarkMode(Mode.Throughput)
@Fork(1)
@State(Scope.Thread)
@Warmup(iterations = 10, time = 1, batchSize = 1000)
@Measurement(iterations = 40, time = 1, batchSize = 1000)
public class Chaining {

    private String a1 = "111111111111111111111111";
    private String a2 = "222222222222222222222222";
    private String a3 = "333333333333333333333333";

    @Benchmark
    public String typicalChaining() {
        return new StringBuilder().append(a1).append(a2).append(a3).toString();
    }
    
    @Benchmark
    public String noChaining() {
        StringBuilder sb = new StringBuilder();
        sb.append(a1);
        sb.append(a2);
        sb.append(a3);
        return sb.toString();
    }

}

Результат:

Benchmark                  Mode  Cnt      Score      Error  Units
Chaining.noChaining       thrpt   40   8408.703 ±  214.582  ops/s
Chaining.typicalChaining  thrpt   40  35830.907 ± 1277.455  ops/s

Итого, конкатеницая через цепочку вызовов sb.append().append() в 4 раза быстрее… Автор из статьи выше утверждает, что разница связана с тем, что в случае цепочки вызовов генерируется меньше байткода и, соответственно, он выполняется быстрее.

Ну что ж, давайте проверим.

Вводная

Мне часто в проектах приходится сталкиваться с фреймворками по работе с БД. Концептуально, эти фреймворки можно разбить на 2 больших класса:

• ORM-ориентированные
• SQL-ориентированные

Некоторые из них хороши, какие-то не очень. Но субъективно могу сказать: SQL-ориентированные уступают в развитии ORM-ориентированным. Подчеркну, в развитии, а не в возможностях. Хоть изменить эту чашу весов и не получится, но предложить необычный взгляд на мир SQL-ориентированного подхода — вполне. Кому интересно, добро пожаловать под кат

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

Почему я решил написать эту небольшую статью? Хотя ажиотаж вокруг этой темы и спал, всё равно она остаётся довольно популярной, находятся как «клиенты», готовые платить очень большие деньги, так и желающие научиться это делать самому. Я работал с одной «студией», которая берет шестизначные суммы за эту работу, при этом кидая своих разработчиков и мелких клиентов. Так вот, чтобы в этой сфере не было монополии, и все увидели, насколько легко это делается, я и решил написать статью.


_{На примере моего пустого сообщества-песочницы}

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

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

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

В предыдущей статье — часть 1, обзорная — я рассказал о том, зачем нужны распределенные структуры данных (далее — РСД) и разобрал несколько вариантов, предлагаемых распределенным кешем Apache Ignite.

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

Итак:

Всем привет! Возможно, вы знаете, что 20-21 июня в Амстердаме пройдет In-Memory Computing Summit 2017 – Europe. Все детали тут.



Мероприятие, ставшее уже традиционным в США, с этого года также будет ежегодно собирать экспертов из Европы и Азии на новой европейской площадке. На различных секциях конференции выступят представители компаний ING, Intel, Tata Consultancy Services, The Glue, Redis Labs, ScaleOut Software и WSO2.

У меня есть несколько бесплатных билетов, которыми я с удовольствием поделюсь с вами.
Напишите мне на почту mkuznetsov@gridgain.com или в личные сообщения на Хабре. От вас — ФИО и название компании на английском языке, адрес электронной почты и мобильный телефон.

Приезжайте, будет круто!

В последнее время активную популярность набирает Kotlin. А что если попробовать выбрать более экзотические языки, и применить к ним те же аргументы? Статья написана по мотивам этой, практически повторяя все аргументы за Kotlin. Основная задача: показать, что Ceylon может практически тоже самое, что и Kotlin, применительно к Java. Но кроме этого у Ceylon есть кое-что еще, что будет описано в следующей статье.

Хочу рассказать о новом языке программирования, который называется Ceylon, и объяснить, почему вам стоит использовать его в своём следующем проекте. Раньше я писал на Java (много и долго, более 10 лет, начиная с Java 1.4 и заканчивая Java 8), и Java мне нравилась. Затем на меня большое впечатление произвела Scala, в результате чего Java как язык стал любить несколько меньше. Но судьба свела меня с языком Сeylon, и в последние полтора года мы пишем на Ceylon везде, где только можно. В реальных коммерческих проектах, правда внутренних. И в данный момент я не представляю себе ситуации, в которой лучше было бы выбрать Java, я не рассматриваю Java как язык, на котором стоит начинать новые проекты.

Ceylon разработан в Red Hat, автор языка — Gavin King, известный по такому фреймворку как Hibernate. Он создавался людьми, которые хорошо понимают недостатки Java, основная цель заключалась в решении сугубо прикладных задач, обеспечение максимально легкой читаемости кода, избегание любых неоднозначностей и подводных камней, во главу всего стала предсказуемость и структурная красота языка. Также большое внимание уделялось приемлемому времени компиляции. В настоящее время версия языка 1.3.2, непосредственно я познакомился с языком, когда вышла версия 1.2.0.

Хотя Ceylon компилируется в JavaScript, я сконцентрируюсь на его первичной среде — JVM.

Итак, несколько причин, почему вам следует полностью переходить на Ceylon (порядок совпадает с одноименными пунктами соответствующей Kotlin статьи):

Преамбула

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

Казалось бы, собери библиотеку и выложи её в локальный maven-репозитарий, а потом уже собирай приложение. Но хочется, чтобы можно было поправив код в библиотеке сразу попробовать изменения в приложении и при этом сохранить раздельное хранение кода библиотеки и приложения, включая настройки IDE и прочее.

С помощью gradle и символических связей в файловой системе такое можно легко устроить.