Специальная теория относительности - удивительная теория, которая опровергла многие представления о мире, в которых человечество не сомневалось всю историю своего существования.

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

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

Для иллюстраций я написал интерактивный визуализатор СТО, работающий в браузере. Ссылка на него и исходники проекта в конце статьи.

Готовитесь к собеседованию за рубежом и переживаете за свой английский? Хотели бы работать в международной компании, но сомневаетесь, хватит ли языка? Не уверены, поймут ли ваш акцент? Тогда эта статья может помочь.

Меня зовут Андрей Столбовский, последние 5 лет я работал в Яндексе, а в прошлом году перешёл в Амазон и теперь работаю Software Development Manager в AWS Redshift – это мой первый полноценный опыт работы в международной компании. 

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

Итак, поехали. 

В Clickhouse есть интересный код: при вызове одной функции происходит перевод области памяти исполняемого кода программы на использование Huge Pages. В процессе весь код программы копируется на новое место, память, использовавшаяся изначально для кода программы возвращается ОС, а потом запрашивается снова. Эта статья основана на соответствующей части доклада с Я.Субботника.

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

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

Иногда в разговоре с коллегами я говорю «спокойно, действуем ровно по учебнику». Но тут есть большая доля лукавства, т.к. одной книги где были бы собраны базовые принципы я так с ходу назвать не могу. По большей части это сборная солянка из разных книг, личного опыта и историй, рассказанных коллегами. Что-то освещено в одной из книг Фаулера, что-то есть в курсах от AWS.

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

Я давно лелеял мечту изучать лингвистику в Кембриджском университете. Каждое лето он проводит среди абитуриентов конкурс эссе на лингвистические темы; и профессор, отвечающий за связь факультета лингвистики с абитуриентами, посоветовал мне ради подготовки к поступлению поучаствовать вне конкурса. Летом 2016 тема эссе звучала так: «Часто утверждают, что наш язык влияет на наше мышление. Как это утверждение можно трактовать? Оцените его, приводя примеры из межъязыковых сравнений и/или психолингвистических экспериментов.» Осенью того года я получил от профессора крайне лестную оценку моего эссе; и тем не менее, в Университет меня не приняли. Этим летом я решил сдуть с того эссе виртуальную пыль, и перевести его на русский.

Меня все сильнее раздражает, сколько людей готовы записывать в REST API любой интерфейс на основе HTTP. Сегодня приведу в качестве примера SocialSite REST API. Это же вызовы удаленных процедур (RPC). Он просто выкрикивает RPC. Связность между элементами на экране настолько сильная, что это творение заслуживает рейтинга X.

5 лет назад мы форкнули Manticore из open source версии некогда популярного open source поискового движка Sphinx 2.3.2. У нас было два пакетика травы, семьдесят пять ампул мескалина, три C++ разработчика, один саппорт-инженер, опытный пользователь, менеджер, мать пятерых детей, помогающая нам на полставки и гора багов, крэшей и технических долгов. И вот, по прошествии 5 лет и сотен новых пользователей мы готовы сказать, что Manticore можно использовать как альтернативу Elasticsearch и для полнотекстового поиска и для аналитики данных.

В этой статье хочется: вспомнить как всё начиналось и что было до SOLR и Elasticsearch, максимально объективно обрисовать текущую ситуацию, попытаться понять куда нам двигаться дальше.

Введение

«Деньги любят счет» - это пословица, как никакая другая, очень точно описывает всю суть успешного распоряжения своими деньгами.

На сегодняшний день существует множество инструментов и сторонних сервисов (Blockfolio, Coinmarketcap, Cryptocompare и т.п.) для ведения учета и контроля своего инвестиционного криптопортфеля.

Также существуют инструменты для работы в Google Sheets. В таблицах есть функция GOOGLEFINANCE("BTCUSD"), которая позволяет учитывать курс биржи в паре доллара к биткоину. А в аддонах к таблицам можно найти CRYPTOFINANCE. Эта функция опирается на данные CoinMarketCap и подтягивает их по API. Данные обновляются всякий раз, как вы открываете или перезагружаете документ.

У вышеуказанных функций есть свои недостатки, например GOOGLEFINANCE имеет сильно ограниченное число криптовалютных пар. У CRYPTOFINANCE есть большинство криптовалютных пар имеющихся на различных биржах, но есть свои ограничения по количеству запросов. Поначалу я сам пользовался сервисом CRYPTOFINANCE на платной основе. Но в процессе эксплуатации понял что нужно делать что-то своё. Чтобы было максимально гибко, просто и доступно каждому.

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

Бесплатный скрипт

Для учёта инвестиций я написал свой собственный скрипт. Скрипт циклично собирает нужную информацию с криптовалютных бирж посредством API которые они предоставляют. Сейчас скрипт поддерживает 7 криптобирж:

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

Появилась вчера на Хабре такая вот статья. Когда компания, занимающаяся ИТ-безопасностью заявляет, что spf/dkim/dmarc не работают и существует минимум 18 способов подменить адрес на (вашем!) почтовом сервере, это вызывает озабоченность и желание разобраться в вопросе. Я прочитал оригинальную статью и кратко изложил свое понимание вопроса. Если тема для вас актуальна рекомендую непременно прочитать оригинал.

Для таргетинга мы в Ozon используем сегменты, в которые группируем пользователей по интересам. Интересы могут быть определены через систему трекинга событий. Последние в свою очередь формируются в процессе взаимодействия пользователя с маркетплейсом Ozon. На основе сегментов мы отправляем нотификации, рассылаем письма, показываем рекомендации, баннеры, страницы с товарами и цены на товары, участвующие в маркетинговых акциях. В принципе, на сегменты можно завязать любую механику. Мы даже А/В тесты иногда проводим с ними.

Первоначально сегменты создавались вручную: поступал запрос от заказчика, после чего проводилась аналитическая работа по сбору требований. Количество заявок на создание сегментов со временем только увеличивалось. Чтобы автоматизировать процесс создания сегментов мы решили сделать конструктор сегментов для DMP — Data Management Platform. Это относительно молодой проект, ему чуть больше двух лет, но он полностью себя оправдал. Сегодня расскажу вам о нашем опыте. Меня зовут Евгений Чмель, и я руковожу командой DMP & CDP.

Налоговая отдаёт данные ЕГРЮЛ  по организации в виде PDF. Посредники за автоматический доступ по API хотят денег. На многих сайтах часть данных закрыто, часть функций недоступны бесплатно, и полно рекламы. 

Особенно интересно, что на некоторых сайтах предоставляющих данные по API имеется логотип Сколково. Это такой высокотехнологический бизнес, наверное, открытые данные продавать.

Налоговая просит 150 000 рублей в год за доступ к данным ЕГРЮЛ в виде сваленных в архивы XML-файлов. У ФНС классный бизнес. Вы проявляйте должную осмотрительность при выборе поставщиков, но доступ к данным за деньги. Если вы хотите получить доступ и к реестру индивидуальных предпринимателей (ЕГРИП), то платите ещё 150 000 рублей в год. Согласитесь 300 000 рублей в год приличная сумма.

Остальные реестры данных у налоговой доступны бесплатно. Однако, без базы ЕГРЮЛ их вряд ли можно использовать. Самая частая операция в бизнесе подставить реквизиты из ЕГРЮЛ по ИНН.

Сформировалась целая отрасль, можно сказать, торговцев воздухом открытыми данными, создающих ВВП из воздуха как бухгалтеры, работающие руками там, где должны работать программы. Сколько компаний платит налоговой по 300 000р. в год?! Сколько программистов занято написанием одинаковых по функциям парсеров, которые переводят данные из XML налоговой в SQL и JSON?! Сколько серверов заняты под одинаковые функции?! Где добавочная стоимость? Все вроде при деле, а за чей счёт банкет?

Ну, ладно, “скандалить, критиковать каждый может”(с) как говорил бессмертный товарищ Райкин. “А что ты предлагаешь?” — резонно вы меня спросите. А я вам отвечу.

Привет! Меня зовут Аркадий. Последние пару лет я в основном занимаюсь развитием поиска по тексту в команде TQM (Tinkoff Quality Management) в банке Тинькофф. Наш продукт — это речевая аналитика по звонкам, чатам и другим активностям, контроль качества, анализ и прочее. Более подробно о продукте можно прочитать на странице бизнес-решений. Примерный объем нашего индекса в проде — 16 Тб, около 450 млрд сущностей.

Каждый раз, когда встает вопрос о полнотекстовом поиске, команда оказывается перед выбором: а надо ли? Уже есть полнотекстовый поиск в Postgres, а тут придется заказывать серверы, строить кластер. Но чем чаще пользователю требуется что-то найти, тем чаще приходится смотреть в сторону специализированных поисковых движков.

Как пишут сами разработчики Elasticsearch, он нужен именно «для поиска, вы же знаете» (you know, for search) и не сможет заменить полноценное хранилище данных. Зато достаточно быстрый, очень надежный и хорошо горизонтально масштабируется (при наших объемах). 

Мы в TQM используем Elastic потому, что он гибкий, широко известный, имеет удобный и простой синтаксис, множество библиотек для работы как на Python, так и на C# (NEST). Хорошо скейлится под наши объемы (1—30 Тб). Kibana также очень удобна, мы используем ее для мониторинга, консоль Kibana применяем для запросов. А еще по сравнению с тем же Sphinx, Elastic удобно масштабировать (просто добавляем шарды, ноды, и он сам распределяет данные по ним). В случае с тем же Sphinx нам пришлось бы писать этот распределенный поиск самим, и не факт, что у нас получилось бы хорошо с первого раза. 

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

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

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

Данный обзор охватывает сразу несколько тем. Мы начнем с устройства решающего дерева и градиентного бустинга, затем подробно поговорим об XGBoost и CatBoost. Среди основных особенностей алгоритма CatBoost:

• Упорядоченное target-кодирование категориальных признаков
• Использование решающих таблиц
• Разделение ветвей по комбинациям признаков
• Упорядоченный бустинг
• Возможность работы с текстовыми признаками
• Возможность обучения на GPU

В конце обзора поговорим о методах интерпретации решающих деревьев (MDI, SHAP) и о выразительной способности решающих деревьев. Удивительно, но ансамбли деревьев ограниченной глубины, в том числе CatBoost, не являются универсальными аппроксиматорами: в данном обзоре приведено собственное исследование этого вопроса с доказательством (и экспериментальным подтверждением) того, что ансамбль деревьев глубины N не способен сколь угодно точно аппроксимировать функцию . Поговорим также о выводах, которые можно из этого сделать.

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

Несмотря на то, что я считаю себя криптографом, меня не особенно привлекает слово "крипто". Не думаю, что я уже староват, но я гораздо чаще кликаю на мемы в духе "Интернет всё помнит" о том, как "крипто" раньше означало "криптография", чем на последние новости об NFT.

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

Эта статья является заключительным конспектом книги «От монолита к микросервисам». Материал статьи посвящен декомпозиции БД во время процесса разложения монолита на микросервисы.

Извлечение микрослужбы не «делается» до тех пор, пока код приложения не будет работать в его собственной службе, а данные, которыми он управляет, не будут извлечены в его собственную логически изолиро­ванную БД. Однако в какой последовательности извлечения должны выполняться?