Криптовалюты, финансы, распределенные системы
Это первая из статей, посвященных веб-серверу Angie. Мысль создать цикл статей возникла в процессе разработки курса по администрированию Nginx и Angie. Приходилось сталкиваться с темами, которые довольно слабо описаны в открытых источниках, либо не описаны вообще. В планах описать типичные области его использования с реальными примерами доступным языком. Так как большинство решений и конфигов будет совместимо с Nginx, надеюсь цикл будет полезен сообществу.
Существует множество исследований и экспериментов, которые прямо гласят: переработки могут быть полезны только краткое время, не более пары месяцев или даже недель. Интернет завален публикациями про их вред, но воз и ныне там. И многие современные менеджеры так и норовят загрузить сотрудников по полной, а в идеале — и на выходных, чтобы работали по 60, 80 или даже 100 часов.
Историй будет много, хватит минимум на 3 части.
В этот раз мы с вами рассмотрим, какие события прошлого и настоящего поддерживают в многих современных руководителях веру в переработки и прочую корпоративную глупость.
Группа экспертов GitHub провела анализ популярных open-source AI проектов, созданных за последние 99 дней. В статье вы узнаете об этих проектах и почему они важны для индустрии AI.
Если вы читаете этот материал, скорее всего вы уже знаете что поднять свой почтовик это страдание и внезапно нетривиальная задача. Цель статьи - без лишней лирики дать пошаговый мануал тем, кто хочет настроить свой собственный мейлер и не платить деньги mailgun и подобным SMTP-relay сервисам.
Эпоха Ренессанса стала рассветом не только науки и искусства, но также криптографии. Некоторые шифры этого периода для криптографа – все равно что Сикстинская капелла или Мона Лиза для ценителя живописи. При этом именно в эпоху Возрождения шифрование превратилось из магической абракадабры и способа пустить пыль в глаза читателю в полноценный рабочий инструмент для защиты ценных сведений.
В блог Бастиона снова заглянула Анастасия Ашаева – кандидат исторических наук, старший научный сотрудник Московского музея криптографии. Эксперт рассказала о шифровании эпохи Ренессанса.
Сразу оговоримся, что в этой статье речь идет в основном об историческом контексте, информация по некоторым шифрам дается дозировано. Ведь криптография не существует в отрыве от исторических реалий — ее развитие неразрывно связано с потребностями людей и временем. Зато следующая публикация цикла будет всецело посвящена шифрам и криптографическим разработкам — с подробными описаниями, иллюстрациями и даже таблицами.
А пока настраиваемся на прекрасное (как-никак, говорим о Возрождении) и поехали!
Вопрос "какая репликация MySQL лучшая?" звучит часто. Ответ, как водится в сложных системах, – "зависит от ситуации". Нет универсального решения. Выбор оптимального метода репликации всегда компромисс. Приходится искать золотую середину между тем, насколько данные должны быть одинаковыми везде, скоростью работы, бесперебойностью и тем, насколько сложно все это настроить. Посмотрим внимательнее на главные способы. Это поможет сделать осознанный выбор.
Пока большие модели соревнуются в увеличении контекстных окон, а их создатели — в маркетинговой находчивости, мы продолжаем следить за наиболее важными событиями в мире ИИ. В апреле OpenAI выкатила сразу несколько GPT — от флагманов до микроскопических версий. Anthropic наконец научила Claude гуглить и разослала его в университеты. Midjourney вернулась в строй, а Google устроила парад апдейтов — от визуального поиска до генерации кино.
В нашем традиционном дайджесте — главные новости, свежие исследования и полезные AI-инструменты: от агентов на любой вкус и цвет до ИИ-тренера по флирту. Ну что, поехали?
Выбрать AI для кода непросто. Сравнили Bolt, v0, Lovable, Replit, Cursor, Windsurf в 5 задачах: от прототипов (текст/Figma) до игр и full-stack приложений.
Тесты показали: один строит прототип за 15 секунд, другой собирает игру в один промпт. Узнайте, какой инструмент эффективен для вашей цели.
Мы живем в эпоху сдвига парадигм. Цифровая физика - это не какая-то отдельная научная дисциплина, а, скорее, такая вот новая парадигмы мышления, согласно которой в основе реальности лежит информация, нечто вроде нейронных сетей или чистая математика, а значит Вселенная вычислима в принципе и сама представляет собой некий процесс вычисления.
Когда речь заходит о производительности в Go, большинство разработчиков полагаются на стандартные библиотеки и встроенные инструменты оптимизации, но компилятор Go не всегда генерирует оптимальный машинный код. В таких случаях можно взять дело в свои руки и использовать ассемблерные инструкции для ускорения критически важных участков.
Ассемблер может показаться сложным и пугающим, но он открывает большие возможности для работы с низкоуровневыми оптимизациями. Готовы разобраться, как это работает? Тогда погнали!
Привет, Хабр! Меня зовут Игорь Панасюк, я работаю в Яндекс, преподаю в ИТМО, а также в свободное время выступаю на конференциях, делюсь опытом в соцсетях и помогаю развитию Go-сообщества.
Я много лет жил в городе, окруженном карьерами, где огромные горнодобывающие машины стали частью привычного пейзажа. Там можно было видеть роторные экскаваторы: за день они вынимали такой объем горной породы, что можно заполнить стадион, а то и не один. А еще — фронтальные погрузчики, легко поднимающие десятки тонн породы, гидравлические экскаваторы с ковшами размером с грузовик, буровые установки, пробивающие твердый камень, и штабелеукладчики, способные насыпать или, наоборот, убрать целый холм.
Практическое руководство по изучению и тестированию техник обхода WAF с помощью продвинутых настроек SQLMap и proxychains.
Введение
В современном быстро меняющемся мире кибербезопасности веб-фаерволы (WAF) играют важнейшую роль в защите сайтов от вредоносных воздействий, таких как SQL-инъекции. Однако и злоумышленники, и этичные хакеры постоянно ищут новые методы для тестирования и обхода таких мер защиты.
В этом руководстве я покажу, как использовать SQLMap, ProxyChains и tamper-скрипты для проверки и оценки эффективности WAF. Вы узнаете, как настроить эти инструменты и проводить сканирование, соблюдая этические стандарты и лучшие практики.
GrapheneOS — это операционная система с открытым исходным кодом (FOSS), основанная на проекте Android Open Source Project (AOSP), которая в первую очередь сосредоточена на улучшении конфиденциальности и безопасности. Хотя мы все хотели бы иметь наилучшую безопасность и конфиденциальность, к сожалению, такие улучшения редко приходят без потерь в удобстве и простоте использования. В этой статье мы рассмотрим, как максимально использовать улучшения Graphene и как эти меры влияют на пользовательский опыт, предлагая практические решения.
Эта статья является попыткой объединить информацию и знания о мобильной безопасности и конфиденциальности в рамках проекта GrapheneOS.
От переводчика: в ходе моей работы в нигерийском финтехе пришлось мне создавать с нуля одну платежную систему. Я тогда ничего толком не понимал в вопросах бухгалтерии, в том как именно лучше хранить платежи и балансы. Но было подозрение, что примитивный вариант с одной циферкой баланса в аккаунте пользователя слишком прост, чтобы быть правильным.
Разобраться и избежать кучи граблей в этом деле мне помогла данная статья. При этом информации по теме "как сделать свою платежную систему" довольно мало, а в учебниках по бухучету программисту сходу разобраться не так просто (и очень нудно). Надеюсь, этот материал окажется полезным тем, кто только собирается что-то такое делать.
Сразу извиняюсь за возможные неточности в русскоязычных финансовых терминах — я все-таки программист, а не бухгалтер, и с русской терминологией в этой сфере недостаточно знаком.
Многие компьютерные системы, использующие реляционные БД, хранят в них какую-то финансовую информацию о балансах и транзакциях. При этом при проектировании и разработке такой БД часто встает вопрос, а как именно хранить эту информацию. Обычно выбор стоит между дешевой "простой записью" и более сложной "двойной записью".
Лука Пачоли, автор самой старой (15 век) дошедшей до нас книги с описанием принципов двойной записи
В системе с "простой записью" числовые значения записываются только один раз. В системе с "двойной записью" каждое значение записывается дважды, как кредит (положительное значение) и как дебет (отрицательное значение). При этом есть набор правил, определяющих связь между этими значениями. Эти правила вам легко опишет любой опытный бухгалтер, хотя он может и не представлять, как именно они могут быть представлены в реляционной БД.
Основные правила таковы:
Регулярно в своей практике и практике коллег встречаю доказательства тому утверждению, что большее сокращение затрат на процессы (в том числе и разработки) можно решить организационными изменениями.
«Нужный человек не в том месте может перевернуть мир».
Никакие технические решения не дадут того же эффекта. В принципе, чаще они даже не срабатывают, так как нет привычки работать «правильно» у самих сотрудников. Все попытки автоматизировать хаос приводят только к интенсификации этого хаоса.
В этой статье я расскажу на одном личном примере, как посредством организационных изменений можно значительно сократить временные затраты на процесс (в моем примере — это процесс разработки), одновременно с этим повысить качество продукта этого процесса.
А точно ли самый простой жанр?
Почему визуальные новеллы — это далеко не всегда «тонны текста со статичными картинками», а полноценный, трудоемкий жанр.
Когда мы с небольшим составом в команде только начали делать визуальную новеллу, в голове звучал вопрос: «Это же вроде легкий жанр… Просто текст, картинки и немного музыки, да?»
Прошло уже больше года разработки. Сотни часов. И теперь у меня встречный вопрос: а точно ли он простой?
Происхождение всего сущего – один из тех детских вопросов, на которые человечество искало ответы тысячелетиями, выдумывая всевозможные мифы о сотворении мира, развивая философские концепции и разрабатывая научные теории. Древнейшие и наиболее универсальные мифологические нарративы повествуют о мировом океане, символизирующем первозданный хаос. В этот океан ныряет утка и достаёт со дна песок, или из плавающего в океане мирового яйца вылупляется некое божество, или божества создают мир путём пахтания горой мирового океана, или они приносят в жертву великана-первочеловека, или божества были вылизаны из солёных камней языком коровы, появившейся из растаявшего инея, и т.д. Когда-то эти сказки всех устраивали, но с началом научной революции учёные стали находить более разумные объяснения. И вот, после четырёх столетий проб и ошибок, у нас наконец есть космологическая модель, которая даёт исчерпывающее объяснение того, как возникла и эволюционировала Вселенная.
Что же мы видим? Теорию Большого взрыва понимают и признают единицы – остальные в лучшем случае сомневаются, а в худшем – активно её отрицают, изобретая новые мифы, выискивая тайные смыслы в старых и повторяя одни и те же глупые вопросы. А был ли Большой взрыв? Что было до Большого взрыва? Как всё могло образоваться из ничего? Неужели Вселенная – бесплатный обед? Или у неё обязательно должен быть Творец? Почему Вселенная расширяется, а мы – нет? Где записан генетический код Вселенной? Что происходило в первые секунды жизни Вселенной? Большой взрыв уже закончился или продолжается до сих пор? И кому ещё, как не Универсальному объяснителю, придётся терпеливо давать на них ответы в этой статье, опровергая популярные заблуждения? Ну, раз больше некому – поехали!
В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos, Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.
Переход от монолита к микросервисной архитектуре приносит гибкость и масштабируемость, но и создает новые сложности. Одна из ключевых проблем –согласованность данных и транзакции. В монолите обычно можно обернуть несколько операций одной ACID-транзакцией: либо все операции выполняются успешно, либо при ошибке происходит полный откат. В мире микросервисов такой прямолинейный подход не работает. Каждый сервис автономен, у каждого своя база данных, и общаются они через сеть. Как результат, гарантировать атомарность и целостность процессов, охватывающих несколько сервисов, непросто. Возникает риск частичных обновлений: одна часть системы изменилась, а другая – нет, что приводит к неконсистентным (несогласованным) состояниям данных.
Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC). Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel), паттерн Outbox, а также кратко упомянем eventual consistency, транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.
