Elasticsearch - мощный поисковый движок и распределенная система хранения документов. При правильной конфигурации, всю магию поиска выполняет именно он, а клиентскому приложению остается лишь сгенерировать запрос в виде Query DSL и подождать ответа.

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

Если вам интересно узнать, как это можно сделать, то добро пожаловать под кат!

Как-то прочел на Хабре статью «Перевозим волка, козу и капусту через реку с эффектами на Haskell», которая так понравилась, что решил написать фреймворк для всего класса задач о переправах, используя мультипарадигменное проектирование. Наконец удалось найти время, и вот, спустя почти год, фреймворк готов. Теперь персонажи, их взаимодействия и описание искомого результата задаются через domain-specific language, который позволяет решать любые головоломки подобного рода с пошаговым выводом. Ниже приводится поэтапный разбор реализации DSL. Статья подойдет тем кто изучает язык Kotlin или просто интересуется примерами его использования. Некоторые малозначимые детали (вроде импортов и вывода) для кратости опущены.

Фото с сайта Unsplash.com

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

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

К старту курса о разработке на С++ мы перевели статью о персональном регистраторе молний — небольшом устройстве, сообщающем об ударах молнии поблизости. Оно даже сообщает, на каком расстоянии ударила молния; при этом, по словам автора, собрать его самому обойдётся дешевле, чем купить в магазине. Ещё один очевидный плюс — вы сможете отточить свои умения в схемотехнике.

В основу устройства положен детектор молний AS3935 с ВЧ-каналом производства DFRobot. Детектор обнаруживает электромагнитное излучение молнии и с помощью специального алгоритма преобразовывает эту информацию в информацию о расстоянии до удара.

Несколько лет назад я услышал от одного коллеги историю. Он в то время работал начальником отдела технической документации в IT компании. Дело было на собрании, посвященном знакомству с новым техническим директором. Тот, пожав моему коллеге руку и узнав о его роли, пошутил: “Документация? Так ее же не читает никто! Двадцать первый век на дворе”.

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

• PostgreSQL для хранения данных
• Redis для координации очередей фоновых заданий (и некоторых ограниченных атомарных операций)

Сценарий 1: очередь заданий

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

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

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

Но мы – круче. В определённых условиях мы умеем надувать огромные перламутровые пузыри, которые потом годами не лопаются. Толку от них нет, но… Красиво же!

Мемы становятся всё дороже.

Уже были и NFT, которые продаются за миллионы, и «обезьяны» с Реддита, вкладывающие в акции Gamestop, чтобы обанкротить хедж-фонды с активами в несколько десятков миллиардов. А теперь Илон Маск вовсю форсит Dogecoin.

Вчера SpaceX объявила, что собирается запустить спутник, который они назовут DOGE-1, к Луне. И теперь принимает Dogecoin на свой кошелек, чтобы сделать это возможным. Запуск спутника будет оплачен исключительно криптовалютой.

Изначально полет должен был состояться в конце 2021 года, но по словам старшего вице-президента Sierra Nevada Corporation (SNC) Стива Линдси, главную роль в задержке сыграла пандемия COVID-19. Конкретная дата запуска пока не названа – все будет зависеть от времени, к которому корабль будет полностью готов, и от НАСА, с которым у SNC заключен контракт на доставку грузов к МКС.  

Мы уже разбирали “Одностраничный устав ООО с двумя директорами электронно и открытие счёта в банке дистанционно” и “Хороший договор — короткий договор”, теперь поговорим про счёт.

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

Попробуем выкинуть всё лишнее и сделать понятно и красиво. Здесь в основном речь пойдёт о России, но и заграничные счета бывают запутанными. Немного скажу и про Европейский Союз.

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

К старту курса об этичном хакерстве мы перевели размещённую на сайте Black Hat биографию основателя этой серии мероприятий по кибербезопасности. Джефф Мосс родился в Калифорнии, США, в январе 1975 года, он — эксперт по компьютерной и интернет-безопасности, хакер. Первый опыт работы с компьютером он получил в возрасте 10 лет и был восхищён возможностью общаться и вести взрослые разговоры с людьми по всему миру. У него ещё не было водительских прав, Джефф не мог голосовать, но мог общаться с людьми намного старше его, которых нисколько не волновали ни его возраст, ни внешность.

Это вольный перевод поста одного из сильных разработчиков Postgres - Andres Freund. Кроме того что разработчик сильный, так еще и статья довольно интересная и раскрывает детали того как работает ОС Linux.

Довольно часто можно слышать заявления что постгресовые соединения используют слишком много памяти. Об этом часто упоминают сравнивая процессную модель обработки клиентских соединений с другой моделью, где каждое соединение обслуживается в отдельном потоке (thread).

Как по мне, здесь есть что обсудить...