17–18 июня в Москве состоится OFFZONE 2019 — международная конференция по кибербезопасности, где свои разработки и практические исследования представят крутые специалисты из 8 стран. %Username%, предлагаем тебе убить сразу много зайцев — посетить мероприятие бесплатно, получить заряд от решения интересных задач и побороться за оффер от BI.ZONE прямо на нашем стенде. Читать полностью »
Несколько месяцев назад меня вдруг поразила мысль, что я понятия не имею о принципах работы компьютерного железа. Я до сих пор не знаю, как работают современные компьютеры.
Я прочитал книгу «Но откуда он знает?» Кларка Скотта с детальным описанием простого 8-битного компьютера: начиная с логических вентилей, ОЗУ, транзисторов процессора, заканчивая арифметико-логическим устройством и операциями ввода-вывода. И мне захотелось реализовать всё это в коде.
Хотя я не настолько интересуюсь физикой микросхем, но книга просто скользит по волнам и красиво объясняет электросхемы и как биты перемещаются по системе — от читателя не требуется знание электротехники. Но мне недостаточно текстового описания. Я должен видеть вещи в действии и учиться на своих неизбежных ошибках. Так я начал реализацию схем в коде. Путь оказался тернист, но поучителен.
Читать полностью »
Я выступил с этим докладом на английском языке на конференции GopherCon Russia 2019 в Москве и на русском — на митапе в Нижнем Новгороде. Речь в нём идёт о bitmap-индексе — менее распространённом, чем B-tree, но не менее интересном. Делюсь записью выступления на конференции на английском и текстовой расшифровкой на русском.
Мы рассмотрим, как устроен bitmap-индекс, когда он лучше, когда — хуже других индексов и в каких случаях он значительно быстрее них; увидим, в каких популярных СУБД уже есть bitmap-индексы; попробуем написать свой на Go. А «на десерт» мы воспользуемся готовыми библиотеками, чтобы создать свою супербыструю специализированную базу данных.
Очень надеюсь, что мои труды окажутся для вас полезными и интересными. Поехали!
Читать полностью »
Обычно с приходом тепла DevDay уходит на каникулы. На этот раз решили, что ждать осени — непозволительно. В последний день весны приглашаем вас присоединиться к Golang DevDay. Будет и мягкий переход «из не-Go в Go» для тех, кто только присматривается к языку, и выступления похардкорнее.
Под катом подробности, расписание и ссылка на регистрацию.
Читать полностью »
Разработка компилятора — очень тяжёлая задача. Но, к счастью, с развитием проектов наподобие LLVM, решение этой задачи значительно упрощается, что позволяет даже программисту-одиночке создать новый язык, близкий по производительности к C. Работа с LLVM осложняется тем, что эта система представлена огромным объёмом кода, снабжённого небольшой документацией. Для того чтобы попытаться этот недостаток исправить, автор материала, перевод которого мы сегодня публикуем, собирается продемонстрировать примеры кода, написанного на Go, и показать, как они транслируются сначала в Go SSA, а потом — в LLVM IR с использованием компилятора TinyGO. Код Go SSA и LLVM IR был немного отредактирован, из него было удалено то, что не относится к приводимым тут пояснениям, ради того, чтобы эти пояснения оказались бы более понятными.
Golang — отличный язык программирования с широким спектром возможностей. В этой статье показано, как на Go можно написать клиент и сервер для протоколов HTTP/1.1 и HTTP/2.
Читать полностью »
Хотел бы рассказать про новый CLI tool который я написал для решения одной старой проблемы.
Terraform уже давно стал стандартом в Devops/Cloud/IT сообществе. Вещь очень удобная и полезная чтоб заниматся infrastructure as code. Есть много прелестей в Terraform а так же много вилок, острых ножей и граблей.
С Terraform очень удобно делать новые вещи и потом ими управлять, менять или удалять. А что делать тем у кого есть огромная инфраструктура в облаке и не создано через Terraform? Переписывать и пересоздавать все облако как то дорого и небезопасно.
Я сталкивался с такой проблемой на 2 работах, самый простой пример когда хочешь что все было в гите виде терраформ файлов, а у тебя 250+ бакетов и писать их для терраформа руками как то много.
Есть issue еще с 2014 года в terrafom которую закрыли в 2016 с надеждой что будет import.
Вообщем все как на картинке только справа налево
Читать полностью »
Данная статья описывает новые компоненты фреймворка для имитационного моделирования, ранее представленного в статье «Простая система имитационного моделирования на Go». По мере расширения фреймворка появилась возможность моделировать более сложные системы, например, провести моделирование работы ресторана.
Читать полностью »
Не так давно коллега ретвитнул отличный пост How to Use Go Interfaces. В нем рассматриваются некоторые ошибки при использовании интерфейсов в Go, а также даются некоторые рекомендации по поводу того, как их все-таки стоит использовать.
В статье, упомянутой выше, автор приводит интерфейс из пакета sort стандартной библиотеки, как пример абстрактного типа данных. Однако, мне кажется, что такой пример не особо хорошо раскрывает идею, когда речь заходит о реальных приложениях. Особенно о приложениях, реализующих логику какой-нибудь бизнес области или решающих проблемы реального мира.
Также при использовании интерфейсов в Go зачастую возникают споры об оверинжиниринге. А еще бывает так, что, после чтения подобного рода рекомендаций, люди мало того что прекращают злоупотреблять интерфейсами, они пытаются практически полностью от них отказаться, тем самым лишая себя использования одной из сильнейших концепций программирования в принципе (и одной из сильных сторон языка Go в частности). На тему типичных ошибок в Go кстати, есть неплохой доклад от Stive Francia из Docker. Там в частности несколько раз упоминаются интерфейсы.
В общем, я согласен с автором статьи. Тем не менее, мне показалось, что тема использования интерфейсов, как абстрактных типов данных в ней раскрыта довольно поверхностно, поэтому мне хотелось бы немного развить ее и поразмышлять на эту тему вместе с вами.
В процессе перехода от монолитного приложения к микросервисной архитектуре мы сталкиваемся с новыми проблемами.
В монолитном приложении обычно достаточно просто определить, в какой части системы произошла ошибка. Скорее всего, проблема в коде самого монолита, либо в базе данных. Но когда мы начинаем искать проблему в микросервисной архитектуре, всё уже не так очевидно. Нужно найти весь путь, который прошел запрос от начала до конца, выделить его из сотен микросервисов. Причём многие из них еще и имеют собственные хранилища, в которых также могут возникать как логические ошибки, так и проблемы с производительностью и отказоустойчивостью.
Я долго искал инструмент, который помог бы справиться с такими проблемами (писал об этом на Хабре: 1, 2), но в итоге сделал собственное опенсорсное решение. В статье я рассказываю о преимуществах подхода service mesh и делюсь новым инструментом для его реализации.
