Под Новый Год мы с женой пересматриваем одну популярную магическую сагу — хочется знаете ли в жизни волшебства. В IT волшебства тоже хватает — от танцев с бубнами до самых современных технологий, принцип работы которых проще объяснить тёмной магией. Так, например, бытует мнение, что настройка service mesh — это магия, подвластная лишь волшебникам DevOps. Но у нас в Альфа-Банке разработчики исторически не маглы, а, как минимум, полукровки, поэтому имеют право приобщиться к волшебному миру.

В этой серии статей я хочу поделиться опытом изучения технологии service mesh, а именно Istio, на примере практической задачи, возникшей какое то время назад в одной из систем Альфа Банка, системным архитектором которой я являюсь.

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

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

У нас было 2 ТБ данных на 4 информационных системы, 237 таблиц, 221 хранимая процедура, свыше 30 тысяч строк кода, ванильная версия PostgreSQL и потребность в реализации обратного потока данных в Oracle. Не то чтобы мы были экспертами в создании потоков данных между СУБД, но я знал, что рано или поздно нам придется этим заняться. 

Всем привет!

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

Ещё отмечу, что это не какие-то мои наработки, а лучшие практики рынка, которые я решила собрать в одном месте. Поэтому ссылок будет много)

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

Начнём с того, что я поздравляю вас(потому что начинается всё самое интересное), если наступил тот счастливый момент, когда ваша компания настолько подросла, что для дальнейшего развития, ей просто необходимо познакомиться с целями внедрения системы аналитики:

Я провел в изучении JMM много часов и теперь делюсь с вами знаниями в простой и понятной форме.

В этой статье мы подробно разберем Java Memory Model (JMM) и применим полученные знания на практике. Да, в интернете накопилось достаточно много информации про JMM/happens-before, и, кажется, что очередную статью про такую заезженную тему можно пропускать мимо. Однако я постараюсь дать вам намного большее и глубокое понимание JMM, чем большинство информации в интернете. После прочтения этой статьи вы будете уверенно рассуждать о таких вещах как memory ordering, data race и happens-before. JMM — сложная тема и не стоит верить мне на слово, поэтому большинство моих утверждений подтверждается цитатами из спеки, дизассемблером и jcstress тестами.

Чего от разработки ПО хотят разработчики, продакты и владельцы бизнеса?

Одного и того же - побольше дофаминчика (гормон счастья), поменьше кортизольчика (гормон стресса). Притом источники и дофамина, и кортизола у них одни и те же. Дофамин вырабатывается, когда фичи выпускаются в срок и без багов, а кортизол - когда сроки срываются и вылазят баги и регрессии. Бизнесу будет ближе финансовая версия — срыв сроков и баги очевидным образом приводят к увлечению стоимости разработки. Что приводит к выбросу кортизола уже у владельцев.

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

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

Вместо того, чтобы затеряться в тысяче комментариев под статьей автора, о не самой сладкой жизни в США, я решил описать свой опыт по тем же предложенным темам. Благо недавно я вышел на финишную прямую по легализации и есть некоторая уверенность в том, что в Россию я не вернусь. Давайте опишем все в той же стилистике моих личных впечатлений, спустя 3,5 года жизни в Техасе. 

Эта статья является пересказом моего доклада на Java-конференции SnowOne 2021 года. LJV — проект, созданный в 2004 году как инструмент для преподавания языка Java студентам. Он позволяет визуализировать внутреннее устройство структур данных. В этом докладе я запускаю LJV на разных структурах (от String до ConcurrentSkipListMap) в разных версиях Java и разбираю, что там внутри, как оно менялось от версии к версии, и как это всё работает.

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

Сегодняшние лидеры САПР-индустрии: Autodesk, Hexagon, Nemetschek, Bentley, Trimble - хорошо готовятся к будущим угрозам: стандартной тактикой больших корпораций стал агрессивный захват новых рынков и поглощение возможных конкурентов на ранних стадиях развития. 

В результате вся САПР-индустрия стала похожа на олигополию, в которой доминирует группа из нескольких компаний. И их положение на вершине становится всё более непоколебимым.

Аннотации - это форма метаданных. Они предоставляют информацию о программе, при том сами частью программы не являются.

1. Идеальный. От рождения до смерти следить за зубами.
2. Типовой. Обратить внимание на свои зубы в возрасте примерно 30–40 лет. Вылечить кариес, наладить правильную гигиену. Это когда не просто горизонтальными движениями щёткой по зубам. И зайти к ортодонту и ортопеду. Если вы достоверно точно знаете, что с опорным аппаратом зубов у вас всё ОК, то можете пропустить этот шаг.
3. Сложный. Когда вам уже 60 лет и вставную челюсть не хочется. Это, конечно, уже не про экономию, а про съёмные протезы и профилактику пародонтита.

Эта текст покрывает ответы на некоторые совсем базовые вопросы и вместе с тем сразу погружает в проблематику получения ответа на вопрос: "как работать лучше? однопоточно, многопоточно или многопоточно, но на ThreadPool?". Ответ на этот вопрос может изначально показаться очень простым и понятным, однако реальность совершенно иная: всё как и везде сильно зависит от ситуации: от типа задачи, от её размера, от прочих условий, которые так просто в голову сами собой не придут.

А потому мы пройдёмся в первую очередь по IO-/CPU-bound операциям, стоимости создания потока, базовым основам работы пула потоков (но только основы), а далее -- углубимся в анализ чёрного ящика: от чего зависит производительность пула потоков? Каков объём работы приемлим для того чтобы в него планировать?

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

Также отмечу, что материал постепенно переходит от начального уровня сложности 🥤 через ⚠️ средний уровень к ☠️ высокому, о чём вы сможете узнать по пиктограммам.

Привет, меня зовут Александр, я старший разработчик ПО в Центре разработки Orion Innovation и я люблю делиться своими мыслями с людьми, разумеется, любимые форматы – статьи на Хабре и доклады на конференциях и митапах. Сложно представить доклад без презентации, о них и хочу поговорить.

Практически 10 лет слова презентация, слайды, PowerPoint(KeyNote) были для меня равносильны. Однажды мне необходимо было продемонстрировать большое количество кода (80 из 100 слайдов содержали код), и моя работа в PowerPoint превратилась в «День сурка»...

[Осторожно: много изображений]

1. Спать регулярно, ложиться и вставать в одно и то же время — самое важное. 
2. Биоритмы — частично наследуются, частично регулируются стилем жизни. На них можно влиять самому.
3. Нормальное время отхода ко сну около 22:00. Сова и жаворонок — это отклонение на ±1-2 часа. Больше — это нарушение и сдвиг фазы сна, чаще из-за внешних раздражителей.
4. Самая частая причина плохого сна и тяжелого засыпания — неправильный свет.
5. Для сдвига режима на 1 час организму нужен 1 день на адаптацию.
6. Невозможно «доспать» бессонную ночь. Досыпание устраняет только 30% последствий недосыпа.
7. Прежде, чем искать причины плохого сна, исключите психологические проблемы (тревожность, депрессию), нарушения щитовидки, дефицит железа, диабеты, сердечно-сосудистые заболевания и патологию почек и мочеполовой системы.
8. Водителям и пассажирам: 17 часов без сна равны 0,5 промилле, 21 час без сна — 0,8 промилле.
9. В постели без сна больше 15 минут не находиться — совет при бессоннице. 
10. Самые физиологичные будильники — те, что светятся. 

В этом году десять лет исполнилось Computer Science Center — образовательному проекту, созданному при участии JetBrains, Школы анализа данных и Computer Science клуба. Сегодня CS центр — это очные курсы в Питере и Новосибирске (а ещё дистанционные для жителей других городов), пять направлений обучения и больше трёхсот невероятно классных и талантливых выпускников. Истории некоторых из них мы хотим вам рассказать.

Первая героиня — Анастасия Лавренко, выпускница 2018 года. Сейчас Настя руководит разработкой образовательной платформы Stepik, а в свободное время и сама делает открытые онлайн-курсы. В интервью она рассказала, почему пошла учиться в CS центр, как попала в Stepik, и поделилась личным топом онлайн-курсов для программистов.

Многие не знают, что некоторые сложные для написания и неэффективные для выполнения SQL-запросы можно легко выразить и эффективно выполнить в графовой базе данных. Это справедливо даже для тех, кто уже знает, что графовые алгоритмы являются наиболее эффективным, а иногда и единственным решением для сложных бизнес-задач, таких как кластеризация пользователей (с использованием Лувенского алгоритма), поиск инфлюенсеров - людей или компаний (алгоритмом PageRank) или прогнозирование поведения пользователей для персональных рекомендаций (алгоритмом label propagation).

В этой статье мы опишем SQL запрос с 24 JOIN в корпоративный knowledge graph и покажем, что задачу можно решить в графовой базе данных - и это будет понятней, более легко поддерживаться и эффективно выполняться. Пример взят из проблемы, описанной в сообществе: https://community.tigergraph.com/