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

Всем привет!

Закончилась одна из самых хардкорных конференций по Java – JPoint 2019, она проходила в седьмой раз и как всегда побила рекорд по посещаемости, в этот раз мероприятие привлекло более 1700 специалистов в области Java-разработки.

«Одноклассники» принимали участие во всех конференциях JPoint. Начиная с 2013 мы активно поддерживаем JPoint и на своих стендах устраиваем для участников различные активности по проверке знаний Java. В этом году у нас были знаменитые «нерешаемые» задачи от ведущих разработчиков OK.ru. Участники конференции, правильно ответившие на вопросы, получили призы.

Справедливости ради надо сказать, что из 600 листочков с задачами, которые мы раздали, обратно было получено менее 100, средний балл равен примерно 0.25.

Лучшим оказалось решение, набравшее 4 балла из 5 возможных.

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

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

К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

5 и 12 декабря JetBrains организует два вебинара, посвященных свежему релизу Kotlin 1.3. На вебинарах Роман Елизаров и Николай Иготти расскажут о том, как начать использовать корутины, Kotlin/Native и Multiplatform Projects. Андрей Бреслав ответит на вопросы зрителей о Kotlin 1.3 и планах на будущее. Задайте ваши вопросы Андрею в Твиттере с хэштегом #kotlinask_13 уже сейчас или в YouTube-чате во время вебинара.

Оба мероприятия бесплатны для участия и будут транслироваться на YouTube канале JetBrains TV. Вебинары и Q&A сессия пройдут на английском языке. Зарегистрируйтесь, чтобы получить ссылку на трансляцию перед вебинаром.

Привет, Хабр!

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

Когда: 21 июня, четверг, с 19:00.
Где: Москва, ул. Большая Полянка, д.2/10, стр. 1 (Corporate Innovations Hub).



Регистрация на событие открыта, подробности – под катом.

Привет Хабр! Сегодня клиенты Pyrus заливают нам около 60GB данных ежедневно. Наша технология хранения информации многократно доказала свою надежность. Компания развивается, и мы озаботились вопросом выбора БД на ближайшие 10 лет. Наша цель — быть готовыми к 100-кратному росту и при этом не менять платформу каждые 2-3 года. Конкуренция на рынке баз данных развита: представлено много решений, большая часть из них open source и/или бесплатные. Ищем «идеальное решение»™ для нашей задачи.

Я работаю в MacOS, почти не использую Finder и все время провожу в консоли. Именно поэтому стараюсь сделать работу из консоли как можно более удобной.

Относительно недавно мне на глаза попалась утилита FZF. И уже через неделю стала незаменимой.

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

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

Уже 6 лет проводится ежегодное соревнование Russian AI Cup. За это время чемпионат оброс постоянной аудиторией и у многих заядлых участников появился небольшой набор инструментов и хитростей, которые помогают им в разработке. Я участвовал в этом соревновании 3 раза и также обзавелся рядом заготовок и скриптов, о которых и хочу рассказать в данной статье.

Отличная новость — как и в прошлом году мы будем транслировать главный зал HighLoad++ с самыми интересными докладами совершенно бесплатно!

Трансляция HighLoad++

Не забудьте нажать на "Напомнить", а также подписаться на наш канал. Мы постоянно выкладываем в нём видеозаписи наших докладов.

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

Полное расписание доступно на сайте (PDF, HTML), а подкатом мы расскажем о самых интересных докладах.

Sql, RegExp, Gradle — что их объединяет? Всё это примеры использования проблемно-ориентированных языков или DSL (domain-specific language). Каждый такой язык решает свою узконаправленную задачу, например, запрос данных из БД, поиск совпадений в тексте или описание процесса сборки приложения. Язык Kotlin предоставляет большое количество возможностей для создания собственного проблемно-ориентированного языка. В ходе статьи мы разберемся, какие инструменты есть в арсенале программиста, и реализуем DSL для предложенной предметной области.

Весь синтаксис, представленный в статье, я объясню максимально просто, однако, материал рассчитан на практикующих инженеров, которые рассматривают Kotlin, как язык для построения проблемно-ориентированных языков. В конце статьи будут приведены недостатки, к которым нужно быть готовым. Используемый в статье код актуален для Kotlin версии 1.1.4-3 и доступен на GitHub.

В продолжение темы «доступным языком про Ignite / GridGain», начатой в предыдущем посте (Для чего нужен Apache Ignite), давайте рассмотрим примеры использования продукта «для простых смертных».

Терабайты данных, кластеры на сотни машин, big data, high load, machine learning, микросервисы и прочие страшные слова — всё это доступно Ignite. Но это не значит, что он не годится для менее масштабных целей.

Сегодня мы рассмотрим, как Ignite может легко хранить любые ваши объекты, обмениваться ими по сети и обеспечивать взаимодействие .NET и Java.

Уже несколько лет подряд мы проводим Russian AI Cup — нехилый такой конкурс для всех неравнодушных к программированию в целом, к построению ИИ, просто к написанию ботов для игр или автоматизации чего бы то ни было. Естественно, и этот год не будет исключением. Итак, Mail.Ru Group в сотрудничестве с Саратовским государственным университетом официально объявляют о дате старта Russian AI Cup 2017 и счастливы предложить задачу этого года. Жёсткие битвы, макбуки за первые места и минус полтора месяца из жизни разработчика — всё на месте, всё как вы любите. Добро пожаловать под кат за подробностями!

Григорий Сапунов (Intento)

Меня зовут Григорий Сапунов, я СТО компании Intento. Занимаюсь я нейросетями довольно давно и machine learning’ом, в частности, занимался построением нейросетевых распознавателей дорожных знаков и номеров. Участвую в проекте по нейросетевой стилизации изображений, помогаю многим компаниям.

Давайте перейдем сразу к делу. Моя цель — дать вам базовую терминологию и понимание, что к чему в этой области, из каких кирпичиков собираются нейросети, и как это использовать.

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

Дальше я расскажу про важные тренды, что происходит в этой области. Затем мы углубимся в архитектуру нейросетей, рассмотрим 3 основных их класса. Это будет самая содержательная часть.

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

Довольно давно я опубликовал на Хабре статью, где рассказал про свой проект, TeaVM. С тех пор много всего произошло с ним, в том числе одна важная вещь, про которую речь пойдёт ниже и ради которой я решил снова написать на Хабр. Но для начала кратко напомню, про что проект.

Итак, TeaVM — это компилятор байт-кода Java в JavaScript. Идея создания TeaVM пришла мне, пока я работал full-stack Java разработчиком и использовал для написания фронтэнда GWT. В те времена (а это где-то лет 5 назад) не были широко распространены инструменты вроде node.js, webpack, babel, TypeScript; Angular был в первой версии, а альтернатив вроде React и vue.js не было вообще. Тогда ещё на полном серьёзе люди тестировали сайты в IE7 (а некоторые, кому не повезло с заказчиками, даже IE6). В целом, экосистема JavaScript была гораздо менее зрелой, чем сейчас, и без боли писать на JavaScript было нельзя.

GWT мне нравился тем, что на фоне всего этого он казался адекватным решением, хотя и не лишённым своих недостатков. Основные проблемы перечислены под катом:

Я расскажу о такой проблеме, как хеширование паролей в веб-сервисах. На первый взгляд кажется, что тут все «яснопонятно» и надо просто взять нормальный алгоритм, которых уже напридумывали много, написать чуть-чуть кода и выкатить все в продакшн. Но как обычно, когда начинаешь работать над проблемой, возникает куча подводных камней, которые надо обязательно учесть. Каких именно? Первый из них — это, пожалуй, выбор алгоритма: хоть их и много, но у каждого есть свои особенности. Второй — как выбирать параметры? Побольше и получше? Как быть с временем ответа пользователю? Сколько памяти, CPU, потоков? И третий — что делать с computational DoS? В этой статье я хочу поделиться некоторыми своими мыслями об этих трех проблемах, опытом внедрения нового алгоритма хеширования паролей в Яндексе и небольшим количеством кода.

Attacker & Defender

Прежде чем переходить к алгоритмам и построению схемы хеширования, надо вообще понять, от чего же мы защищаемся и какую роль в безопасности веб-сервиса должно играть хеширование паролей. Обычно сценарий таков, что атакующий ломает веб-сервис (или несколько веб-сервисов) через цепочку уязвимостей, получает доступ к базе данных пользователей, видит там хеши паролей, дампит базу и идет развлекаться с GPU (и, в редких случаях, с FPGA и ASIС).

Привет.

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

Оглавление:
Часть 1: Введение и лексический анализ
Часть 2: Реализация парсера и AST
Часть 3: Генерация кода LLVM IR
Часть 4: Добавление JIT и поддержки оптимизатора
Часть 5: Расширение языка: Поток управления
Часть 6: Расширение языка: Операторы, определяемые пользователем
Часть 7: Расширение языка: Изменяемые переменные
Часть 8: Компиляция в объектный код
Часть 9: Добавляем отладочную информацию
Часть 10: Заключение и другие вкусности LLVM

6.1. Введение

Добро пожаловать в главу 6 руководства “Создание языка программирования с использованием LLVM”. К данному моменту у нас есть полнофункциональный язык, хотя и минимальный, но, тем не менее, полезный. Но по-прежнему осталась одна проблема. В нашем языке мало полезных операторов (нет, например, деления, логического отрицания, и даже сравнений, за исключением оператора сравнения «меньше»).

Этот проект выполнен в соавторстве с Митей Теряевым — талантливым frontend-разработчиком.

Что такое Паспорт и зачем он нужен?

Задача нашей команды — простой и безопасный онлайн-доступ ко всем сервисам банка. Со стороны клиента это кажется вполне очевидным. Например, после авторизации в едином аккаунте Google пользователю доступны все сервисы компании. И это нормально и правильно — зачем заново входить в Диск, Документы, Музыку или Заметки, если ты уже успешно залогинился в Почте?



«Юрики» (Альфа-Бизнес), «физики» (розница), «зарплатники» (Альфа-Зарплата) — независимые системы, которые делали разные команды, оторванные друг от друга.

Прошли годы…

В статье автор пытается проанализировать почему существуют торговые системы написанные на Java. Как может Java соперничать в области высокой производительности с C и C++? Далее размещены небольшие размышления о достоинствах и недостатках использования Java в качестве языка программирования/платформы для разработки систем HFT.

Привет, Хабр! Меня зовут Настя, и я не люблю очереди. Поэтому я расскажу вам, на примере Альфа-Лаборатории и наших исследований, каким образом можно организовать инфраструктуру и архитектуру для прогона тестов, чтобы получать результат в разы быстрее. Например, нам удалось добиться такой цифры, как 5 минут суммарного времени прохождения тестов на приложение. Для этого нам пришлось поменять подход к запуску Selenium Grid.

Прежде чем начну рассказывать про сам selenium grid и все, что связано с ним, я хочу пояснить суть проблемы, которую мы пытались решить.

В прошлом году мы внедряли DevOps как процесс. И в один момент, автоматизируя все и вся, мы поняли, что time to market для каждого артефакта на этапе тестирования не должен превышать 30 минут. Концептуально мы хотели, чтобы некоторые релизы проходили автоверификацию, если приемочное тестирование им не нужно. Для тех артефактов, которые нужно проверять руками, 30 минут — это время, за которое тестировщик получает результаты прогона автотестов, анализирует их, а также делает приемочное тестирование. При этом автотесты должны автоматически запускаться в рамках нашего pipeline.