Объектно-ориентированный язык программирования
Вам когда-нибудь приходилось писать на хорошо знакомом языке под никогда ранее невиданную платформу? Странное ощущение. Кодабра делится опытом, как максимально быстро разобраться с незнакомым окружением и начать жить.
Хочу рассказать вам о новом языке программирования, который называется Kotlin, и объяснить, почему вам стоит использовать его в своём следующем проекте. Раньше я предпочитал Java, но в последний год пишу на Kotlin везде, где только можно. И в данный момент я не представляю себе ситуации, в которой лучше было бы выбрать Java.
Kotlin разработан в JetBrains, и участие тех же людей в создании наборов IDE, таких как IntelliJ и ReSharper, хорошо заметно по самому языку. Он прагматичен и краток, благодаря чему написание кода превращается в приятный и эффективный процесс.
Хотя Kotlin компилируется в JavaScript и скоро будет компилироваться в машинный код, я сконцентрируюсь на его первичной среде — JVM.
Итак, несколько причин, почему вам следует полностью переходить на Kotlin (порядок случаен):
Давным давно, когда деревья компьютеры были большими, а процессоры одноядерными, все приложения запускались в один поток и не испытывали сложностей синхронизации.
Современные же приложения стремятся использовать все имеющиеся ресурсы, в частности, все доступные CPU.
К сожалению, использовать стандартные структуры данных при многопоточной обработке не представляется возможным, поэтому в Java 5 появились потокобезопасные структуры данных,
т.е. функционирующие исправно, при использовании из нескольких потоков одновременно, и расположились они в пакете java.util.concurrent.
На самом деле, потокобезопасные, но неэффективные, структуры данных, как, например, Vector и Hashtable, появились еще в Java 1.0.
В настоящий момент, они не рекомендуются к использованию.
Однако, не взирая на всю технологическую мощь, заложенную в пакет java.util.concurrent, обработка информации потокобезопасными коллекциями возможна лишь в рамках одного компьютера, а это порождает проблему масштабируемости.
А что если нужно, в реальном времени, обрабатывать информацию о 100 миллионах клиентов,
когда датасет занимает 100Тб, а каждую секунду нужно совершить 100+ тысяч операций?
Вряд ли это возможно, даже на самом крутом современном железе, а если и возможно — только представьте себе его стоимость!
Намного дешевле добиться такой же вычислительной мощности объединив множество обычных компьютеров в кластер.
Остается лишь вопрос межкомпьютерного взаимодействия привычными средствами, схожими по API с потокобезопасными коллекциями из пакета java.util.concurrent и дающими те же гарантии, но не на одном компьютере, а на всем кластере.
Понимание модели ввода/вывода вашего приложения может привести и к пониманию различий между приложением, работающим с нагрузкой, под которой оно создавалось, и тем, которое лицом к лицу столкнулось с реальным способом своего применения. Возможно, если ваше приложение невелико и не создаёт большой нагрузки, то для него это не так важно. Но по мере роста трафика использование ошибочной модели ввода/вывода может погрузить вас в мир боли.
Как и в большинстве других ситуаций с несколькими возможными решениями, дело не в том, какой из вариантов лучше, дело в понимании компромиссов. В этой статье мы сравним Node, Java, Go и PHP из-под Apache, обсудим модели ввода/вывода в разных языках, рассмотрим достоинства и недостатки каждой модели и прогоним простенькие бенчмарки. Если вас волнует производительность ввода/вывода вашего следующего веб-приложения, то эта статья для вас.
Терминология — это важнейшая вещь в любом деле. Не договорившись о терминах невозможно преуспеть. Что с этим в программировании? В частности в Java? Не очень хорошо, если не сказать плохо.
Как уже знают все Android-разработчики, Google недавно объявила об официальной поддержке Kotlin в Android. Многие риски, связанные с использованием этого замечательного языка в Android-проектах, сняты. Но актуальным, особенно для очень крупных проектов, каким является Badoo, остаётся вопрос о скорости сборки. Я был рад обнаружить, что в сети уже есть исследования на эту тему, и переводом одного из них хочу поделиться.
Итак, если вы переводите приложение с Java на Kotlin, будет ли оно компилироваться дольше?
Введение
Доброго времени суток, дорогой читатель. Я уже давно хотел написать статью на хабре и вот наконец-то этот момент настал. Из последних тем, которыми я занимался и о которых мне есть что рассказать — это была реализация SSO для одного сервиса. Хочу здесь сразу уточнить, что в принципе SSO через Facebook и Google уже было в сервисе до моего прихода. Моей же задачей было реализовать его через протокол SAML.
SSO (Single Sign-On), — технология единого входа пользователей, благодаря которой владея одной лишь учетной записью пользователь может посещать множество различных сервисов.
SAML — это популярный XML-протокол для реализации SSO. Как правило большие организации (enterprise) используют именно его, как проверенный и надежный вариант.
В нашем сервисе появление этой фичи как раз и было обусловлено частыми запросами enterprise заказчиков на его реализацию. Такого рода заказчики централизованно ведут актуальную базу пользователей, вводят свои политики безопасности и т.п. Соответственно и доступ к контенту в сервисе становится более безопасным и контролируемым, чего в конце концов они и хотят.
В последнее время имена GridGain и Apache Ignite нередко мелькают в интернетах. Однако, судя по комментариям (например, здесь), мало кто понимает, что же это за продукт и с чем его едят.
В этой статье я попытаюсь доступным языком объяснить, и на примерах кода показать, что умеет Apache Ignite.
