17–18 июня в Москве состоится OFFZONE 2019 — международная конференция по кибербезопасности, где свои разработки и практические исследования представят крутые специалисты из 8 стран. %Username%, предлагаем тебе убить сразу много зайцев — посетить мероприятие бесплатно, получить заряд от решения интересных задач и побороться за оффер от BI.ZONE прямо на нашем стенде. Читать полностью »
28 февраля мы провели SphinxSearch-meetup SuperJob. Рассказываем, что обсуждали участники, делимся видео и презентациями.
Обычно с приходом тепла DevDay уходит на каникулы. На этот раз решили, что ждать осени — непозволительно. В последний день весны приглашаем вас присоединиться к Golang DevDay. Будет и мягкий переход «из не-Go в Go» для тех, кто только присматривается к языку, и выступления похардкорнее.
Под катом подробности, расписание и ссылка на регистрацию.
Читать полностью »
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.
Вообщем все как на картинке только справа налево
Читать полностью »
Не так давно коллега ретвитнул отличный пост How to Use Go Interfaces. В нем рассматриваются некоторые ошибки при использовании интерфейсов в Go, а также даются некоторые рекомендации по поводу того, как их все-таки стоит использовать.
В статье, упомянутой выше, автор приводит интерфейс из пакета sort стандартной библиотеки, как пример абстрактного типа данных. Однако, мне кажется, что такой пример не особо хорошо раскрывает идею, когда речь заходит о реальных приложениях. Особенно о приложениях, реализующих логику какой-нибудь бизнес области или решающих проблемы реального мира.
Также при использовании интерфейсов в Go зачастую возникают споры об оверинжиниринге. А еще бывает так, что, после чтения подобного рода рекомендаций, люди мало того что прекращают злоупотреблять интерфейсами, они пытаются практически полностью от них отказаться, тем самым лишая себя использования одной из сильнейших концепций программирования в принципе (и одной из сильных сторон языка Go в частности). На тему типичных ошибок в Go кстати, есть неплохой доклад от Stive Francia из Docker. Там в частности несколько раз упоминаются интерфейсы.
В общем, я согласен с автором статьи. Тем не менее, мне показалось, что тема использования интерфейсов, как абстрактных типов данных в ней раскрыта довольно поверхностно, поэтому мне хотелось бы немного развить ее и поразмышлять на эту тему вместе с вами.
В этой статье я расскажу как использовать pinba совместно с clickhouse и grafana вместо pinba_engine и pinboard.
На php-проекте pinba — пожалуй единственный надёжный способ понять, что происходит с производительностью. Правда обычно pinba внедряется только тогда, когда уже наблюдаются проблемы и не понятно «где копать».
Часто никто понятия не имеет сколько раз в секунду/минуту вызывается тот или иной скрипт и начинают оптимизировать «на ощупь», начиная с тех мест, что кажутся логичнее.
Кто-то анализирует логи nginx, а кто-то медленные запросы в бд.
Конечно pinba не была бы лишней, но есть несколько причин, почему она есть далеко не на каждом проекте.
Читать полностью »
"Что? Что вообще здесь написано?" спросите вы. Сейчас все разложу.
Когда начинал изучать язык — не думал что зайду в этот узкий случай. Это также не рационально как и изменять итерируемую коллекцию.
Значимо изменить маршализацию структуры в json можно только через метод MarshalJSON(), написав там полную реализацию маршализации. Как именно? На это документация Go ни ответов, ни рекомендаций не даёт, предоставляя, так сказать, полную свободу. А как воспользоваться этой свободой так, чтобы не нагородить кучу костылей, перенеся всю логику в MarshalJSON(), и потом не перепиливать эту бедную постоянно разрастающуюся функцию при очередных кастомизациях json?
Решение на самом деле простое:
(Второго пункта не будет, первого хватит.)
