Совсем недавно я решился на покупку личного ноутбука. Разработка open-source проекта (приложение для Flipper) и смена места работы вынудили меня больше не использовать рабочий ноутбук для личных целей. И тут уже жалко было отдавать стоимость поддержанной Hyndai Solaris за ноутбук (на работе у меня топовая конфигурация 16" MacBook).



Поэтому решено было поумерить свой пыл и взять нищебродский самый дешевый MacBook Air 13" за 80 тысяч рублей. Однако, на mac Docker сжирает непомерное количество ресурсов, поэтому после покупки пришлось думать как же решить эту проблему. Сразу же пришла идея вынести Docker Engine куда-нибудь в онлайн. Сказано — сделано.

Михаил Салосин (далее – МС): – Всем привет! Меня зовут Михаил. Я работаю бэкенд-разработчиком в компании MC2 Software, и я расскажу об использовании Go в бэкенде мобильного приложения «Смотри+».



Кто-нибудь из присутствующих любит хоккей?



Тогда это приложение для вас. Оно – для «Андроида» и iOS, служит для просмотра трансляций разных спортивных событий в онлайне и в записи. Также в приложении есть различная статистика, текстовые трансляции, таблицы по конференциям, по турнирам и прочая информация, полезная для болельщиков.



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

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

Вот список тем, которые мы будем обсуждать в этой статье:

• Что такое ngrx
• Преимущества использования ngrx
• Недостатки использования ngrx
• Когда использовать ngrx
• Действия, Редукторы, Селекторы, Хранилище и Эффекты

Продолжение статьи с примером использования: «Angular: пример использования NGRX».

Обратная сторона подписки на Observable

У Observables есть метод subscribe, который вызывается с помощью callback-функции, чтобы получить значения, отправляемые (emit) в Observable. В Angular он используется в компонентах/директивах, а особенно в router-модуле, NgRx и HTTP.

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

@Component({...})
export class AppComponent implements OnInit {
    subscription: Subscription
    ngOnInit () {
        const observable = Rx.Observable.interval(1000);
        this.subscription = observable.subscribe(x => console.log(x));
    }
} 

Тут вот праздники скоро. Спросил недавно друг «как мне это все пережить?». Я сначала объяснял, а потом решил написать статью на Хабр. Рассказанное — услышит один человек, а написанное — прочитают сотни!

Меня, если честно, достаточно сильно раздражают всевозможные застолья. Потому что гораздо приятнее посидеть с паяльником или читая книгу, а не "… хорохорясь, ерепенясь и валяясь, как колода..." провести выходные. Но традиции-с, будь они неладны, формировались столетиями и не умея пить — бывает достаточно сложно вписаться в коллектив, найти нужный подход и т.д. Особенно грешат этим делом всевозможные руководящие кадры из старого поколения. Что же делать тем, для кого алкоголь и необходимость его употреблять — это просто лишняя головная боль? Самый простой ответ — НЕ ПИТЬ, но на практике полностью это очень сложно реализовать. Эффективнее в наших реалиях принять тезис «алкоголь — просто инструмент» и учиться с ним правильно работать и использовать для решения своих задач с минимизацией ущерба для здоровья.

Статью кладем в закладки и рассылаем всем друзьям, подчиненным и т.д. и т.п. Есть время подготовиться и встретить новогодние корпоративы во всеоружии. Практически уверен, что многое из описанного активно используют те, кто «не напиваться» обязан по долгу службы. Простой же обыватель чаще про это не думает, полагаясь на удачу и легкую руку. И чаще всего оказывается в проигрыше. Предупрежден = вооружен, поэтому под катом читаем, как победить в битве с алкоголем.

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


Это был тест на внимательность. Восьмой город будет под катом.

Сразу скажем — BeerPHP не про “напиться по профессиональному признаку”. Это про общение. Развиртуализироваться на нейтральной территории и в максимально неформальной обстановке — это здорово, а пить что-то крепче чая при этом вовсе необязательно. Мы поговорили с организаторами из нескольких городов, как проходят их встречи и почему разработчики приходят на них.

*FAANG — акроним 5 крупнейших tech компаний (Facebook, Apple, Amazon, Netflix and Google), предоставляющих одни из самых хороших возможностей для разработчиков, которые мечтают/планируют/хотят приобщиться к волне IT-эмиграции.

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

К сожалению, на практике подобный процесс поиска работы часто заканчивается неудачами. Сайты со списком вакансий — один из самых низкоэффективных способов, по крайней мере в США.

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

Необходимое вступление

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

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

Столь малые гарантии поднимают вопросы о причинах, по которым статья пишется. Я считаю, что этим вещам должны учить везде, где учат программированию, вплоть до уроков информатики в школах с углублённым её изучением. Тем не менее, для меня стала пугающе нормальной ситуация, когда я узнаю, что собеседник мой коллега, причём работающий уже не первый год, но про инкапсуляцию «что-то там слышал». Необходимость собрать всё это в одном месте и давать ссылку при возникновении вопросов зрела давно. А тут ещё и мой «pet-project» дал мне изрядно пищи для размышлений.

Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.

Перевод статьи подготовлен для студентов профессионального курса «Framework Laravel»

---

Введение

Эта статья посвящена основам создания событийных CQRS-систем на языке PHP и в фреймворке Laravel. Предполагается, что вы знакомы со схемой разработки с использованием командной шины и имеете представление о событиях (в частности, о публикации событий для массива слушателей). Чтобы освежить эти знания, вы можете воспользоваться сервисом Laracasts. Кроме того, предполагается, что вы имеете определенное представление о принципе CQRS. Если же нет, я настоятельно рекомендую прослушать две лекции: «Практикум по порождению событий» Матиаса Верраса (Mathias Verraes) и «CQRS и порождение событий» Грега Янга (Greg Young).

Классическое PHP-приложение — однопоточность, тяжелая загрузка (если вы, конечно, не пишите на микрофреймворках) и неизбежная смерть процесса после каждого запроса… Такое приложение тяжелое и медленное, но мы можем дать ему вторую жизнь гибридизацией. Чтобы ускорить — демонизируем и оптимизируем утечки памяти, чтобы добиться большей производительности — внедрим собственный сервер РНР-приложений RoadRunner на Golang, чтобы добавить гибкости — упростим PHP-код, расширим стек и разделим ответственность между сервером и приложением. По сути, заставим наше приложение работать, как если бы мы писали его на Java или другом языке.

Благодаря гибридизации ранее медленное приложение перестало страдать 502 ошибками под нагрузками, уменьшилось среднее время ответа на запросы, производительность увеличилась, а деплой и сборка стали проще за счет унификации приложения и избавления от лишней обвязки в виде nginx + php-fpm.


Антон Титов (Lachezis) — технический директор и соучредитель SpiralScout LLC с опытом активной коммерческой разработки на PHP в 12 лет. Последние несколько лет активно внедряет Golang в стек разработки компании. Об одном из примеров Антон рассказал на PHP Russia 2019.

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

Что такое Makefile-ы?

Makefile — невероятно полезный инструмент автоматизации, который можно использовать для запуска и сборки приложений не только на Go, но и на большинстве других языков программирования.

Его часто можно увидеть в корневом каталоге множества Go приложений на Github и Gitlab. Он широко используются в качестве инструмента для автоматизации задач, которые часто сопровождают разработчиков.

Если вы используете Go для создания веб-сервисов, то Makefile поможет решить следующие задачи:

• Автоматизация вызова простых команд, таких как: compile, start, stop, watch и т. д.
• Управление специфичными для проекта переменными окружения. Он должен подключать файл .env.
• Режим разработки, который автоматически компилируется при изменении.
• Режим разработки, который показывает ошибки компиляции.
• Определение GOPATH для конкретного проекта, чтобы мы могли хранить зависимости в папке vendor.
• Упрощенный мониторинг файлов, например, make watch run = «go test. / ...»

Привет, Хабр! Предлагаю вашему вниманию перевод статьи основателя сервиса Meetspaceapp Nick Gauthier «Building Minimal Docker Containers for Go Applications».

Время чтения: 6 минут

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

Часть 1: Наше «приложение»

Для тестирования нам потребуется какое-нибудь маленькое приложение. Давайте будем фетчить google.com и выводить размер HTML.

package main

import (
    "fmt"
    "io/ioutil"
    "net/http"
    "os"
)

func main() {
    resp, err := http.Get("https://google.com")
    check(err)
    body, err := ioutil.ReadAll(resp.Body)
    check(err)
    fmt.Println(len(body))
}

func check(err error) {
    if err != nil {
        fmt.Println(err)
        os.Exit(1)
    }
}

Если мы запустимся, то получим только какое-то число. У меня вышло около 17К. Я целенаправленно решил использовать SSL, но причину объясню позднее.

Кратко о спецификациях:

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

На сегодня существует два (если знаете другие проекты, напишите пожалуйста в комментариях) успешных и популярных проекта на PHP, позволяющих описывать бизнес-правила в спецификациях и фильтровать наборы данных. Это RulerZ и Happyr Doctrine Specification. Оба проекта являются мощными инструментами со своими преимуществами и недостатками. Сравнение этих проектов потянет на целую статью. Здесь же я хочу рассказать, что нам привнес новый релиз в Doctrine Specification.

Всем привет, сегодня поговорим о том, как подружить Symfony 4, JSON RPC и OpenAPI 3.

Данная статья рассчитана не на новичков, вы уже должны понимать как работать с Symfony, Depedency Injection и другими «страшными» вещами.

Сегодня рассмотрим одну конкретную реализацию JSON RPC.

Привет, меня зовут Василий Богонатов. Я один из тех, кто приложил руку и голову и вложил свою душу в сервис распределённых персистентных очередей сообщений Yandex Message Queue. Сервис вышел в общий доступ в конце мая, но внутри Яндекса он уже давно и активно используется в разных продуктах.

Сегодня я хочу рассказать читателям Хабра об очередях сообщений вообще и о Yandex Message Queue в частности. Сначала я хочу объяснить, что такое «распределённая персистентная очередь сообщений» и зачем она нужна. Показать её практическую ценность, механику работы с сообщениями, поговорить про API и удобство использования. Во второй половине материала мы посмотрим на техническую сторону: как в наших очередях используется Yandex Database (это надежный фундамент нашего сервиса), как выглядят наивный и улучшенный подход к построению архитектуры, какие проблемы вызывает распределённость и как их можно решить.

Привет, Хабр! Меня зовут Тимур Шагиахметов, я PHP-разработчик в Badoo.

Производительность приложения — один из важнейших критериев качества работы программиста. В вопросах оптимизации PHP-приложений помощником является профайлер.

Недавно мы рассказывали о том, какими инструментами пользуемся для профилирования. Напомню: одним из инструментов для анализа производительности, когда непонятно, какие части кода повлияли больше всего на увеличение времени формирования ответа, является XHProf. Это расширение для PHP, которое позволяет профилировать код на боевом сервере и впоследствии  улучшать его.

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

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

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

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

Хорошим тоном считается выносить работу с БД в сервисы. А сервисы нужно тестировать.

Для тестирования сервисов можно подключить тестовую базу данных, а можно замокать Менеджер сущностей и репозитории. С первым вариантом всё понятно, но не всегда есть смысл разворачивать БД для тестирования сервиса. Об этом и поговорим.

Привет, Хабр! Этой статьей я начинаю серию циклов (или цикл серий? в общем, задумка грандиозная) о внутреннем устройстве PostgreSQL.

Материал будет основан на учебных курсах по администрированию, которые делаем мы с Павлом pluzanov. Смотреть видео не все любят (я точно не люблю), а читать слайды, пусть даже с комментариями, — совсем «не то».

Конечно, статьи не будут повторять содержание курсов один в один. Я буду говорить только о том, как все устроено, опуская собственно администрирование, зато постараюсь делать это более подробно и обстоятельно. И я верю в то, что такие знания полезны прикладному разработчику не меньше, чем администратору.

Ориентироваться я буду на тех, кто уже имеет определенный опыт использования PostgreSQL и хотя бы в общих чертах представляет себе, что к чему. Для совсем новичков текст будет тяжеловат. Например, я ни слова не скажу о том, как установить PostgreSQL и запустить psql.

Вещи, о которых пойдет речь, не сильно меняются от версии к версии, но использовать я буду текущий, 11-й «ванильный» PostgreSQL.

Первый цикл посвящен вопросам, связанным с изоляцией и многоверсионностью, и план его таков:

1. Изоляция, как ее понимают стандарт и PostgreSQL (эта статья);
2. Слои, файлы, страницы — что творится на физическом уровне;
3. Версии строк, виртуальные и вложенные транзакции;
4. Снимки данных и видимость версий строк, горизонт событий;
5. Внутристраничная очистка и HOT-обновления;
6. Обычная очистка (vacuum);
7. Автоматическая очистка (autovacuum);
8. Переполнение счетчика транзакций и заморозка.

Ну, поехали.

Перевод обучающей статьи разработчика из SendGrid о том, когда и зачем можно и нужно использовать «традиционные» методы синхронизации данных в Go.

Уровень чтения: средний (intermediate) — эта статья подразумевает, что вы знакомы с основами Go и моделью concurrency, и, как минимум, знакомы с подходами к синхронизации данных методами блокировок и каналов.

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

Технология GraphQL за последние несколько лет, после того, как компания Facebook перевела её в разряд опенсорсных, стала весьма популярной. Автор материала, перевод которого мы сегодня публикуем, говорит, что попробовал работать с GraphQL в среде Node.js и на собственном опыте убедился в том, что эта технология, благодаря её замечательным возможностям и простоте, неслучайно привлекает к себе столько внимания. Недавно он, занимаясь новым проектом, перешёл с Node.js на Golang. Тогда он и решил испытать совместную работу Golang и GraphQL.