За последние десять лет фронтенд-разработка значительно усложнилась: от чистого HTML/CSS до таких тем, как высокая интерактивность, доступность, тестируемость и безопасность. Чтобы удовлетворить эти потребности, большинство команд разработчиков делятся на бекенд и фронтенд команды.

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

Здесь я остановлюсь и без дальнейших прелюдий, давайте создадим пример микро-фронтенда с использованием Angular elements.

Усовершенствование опыта разработки

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

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

Это побудило меня начать изучение различных методик рефакторинга Redux. Я смотрел видео, читал статьи и документы Redux. В конце-концов, я написал плагин для NgRx под названием NgRx Ducks

Обратная сторона подписки на 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));
    }
} 

1. Для чего нужен тип «Omit»?

Ответ: Это новый тип, в котором можно указать свойства, которые будут исключены из исходного типа.

Пример:

type Person = { name: string; age: number; location: string; };
type QuantumPerson = Omit<Person, 'location'>; // Аналогично следующей строке
QuantumPerson = { name: string; age: number; };

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

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

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

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

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

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

Этот пост — мой топ самых распространенных ошибок, которые встречались мне в Go-проектах. Порядок не имеет значения.

Неизвестное значение Enum

Давайте взглянем на простой пример:

type Status uint32

const (
	StatusOpen Status = iota
	StatusClosed
	StatusUnknown
)

Здесь мы создаем энумератор с помощью iota, что приведет к такому состоянию:

StatusOpen = 0
StatusClosed = 1
StatusUnknown = 2

Вредные советы для Go-программиста



В первой части публикации я объяснил, как стать «злобным» программистом Go. Зло приходит во многих формах, но в программировании оно заключается в намеренном затруднении понимания и поддержки кода. «Злые» программы игнорируют основные средства языка в пользу техник, которые обеспечивают краткосрочные выгоды, в обмен на долгосрочные проблемы. В качестве краткого напоминания, злые «практики» Go включают в себя:

• Плохо названные и организованные пакеты
• Неправильно организованные интерфейсы
• Передача указателей на переменные в функции для заполнения их значений
• Использование паники вместо ошибок
• Использование init-функций и пустого импорта для настройки зависимостей
• Загрузка файлов конфигурации с использованием init-функций
• Использование фреймворков вместо библиотек

Большой клубок зла

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

И я сделал такой. Если вы зайдете на https://github.com/evil-go, вы увидите Fall (падение), — DI фреймворк, дающий возможность внедрять любые «злые» практики, которые только захотите. Я спаял Fall с крошечным веб-фреймворком Outboy, который следует тем же принципам.

Вы можете спросить, насколько они злодейские? Давайте посмотрим. Предлагаю пройтись по простой программе Go (написанной с использованием лучших практик), которая предоставляет http endpoint. А затем перепишем ее, используя Fall и Outboy.

Вредные советы для Go-программиста

После десятилетий программирования на Java, последние несколько лет я в основном работал на Go. Работать с Go — здорово, прежде всего потому, что за кодом очень легко следовать. Java упростила модель программирования C ++, удалив множественное наследование, ручное управление памятью и перегрузку операторов. Go делает то же самое, продолжая двигаться к простому и понятному стилю программирования, полностью удаляя наследование и перегрузку функций. Простой код — читаемый код, а читаемый код — поддерживаемый код. И это здорово для компании и моих сотрудников.

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

Привет, Хабр! Предлагаю вашему вниманию перевод статьи основателя сервиса 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, но причину объясню позднее.