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

Условный Постгрес выплюнет миллион записей за доли секунды. Забрать этот же миллион из другого сервиса — приключение на неделю. Тут и метрики, лимиты, квоты, сетевые спайки, etc… А когда таких запросов несколько, сервис ложится спать.

Fast, powerful, yet easy to use template engine for Go. Optimized for speed, zero memory allocations in hot paths. Up to 20x faster than html/template

SQL Polyglot is a quick way to see if a particular SQL feature is supported in different database systems. Write a query and see it run anywhere from PostgreSQL to DuckDB without leaving your browser.

package src

type config struct {
    // Required
    foo, bar string

    // Optional
    fizz, bazz int
}

// Each optional configuration attribute will have its own public method
func (c *config) WithFizz(fizz int) *config {
    c.fizz = fizz
    return c
}

func (c *config) WithBazz(bazz int) *config {
    c.bazz = bazz
    return c
}

// This only accepts the required options as params
func NewConfig(foo, bar string) *config {
    // First fill in the options with default values
    return &config{foo, bar, 10, 100}
}

func Do(c *config) {}

You’d use the API as follows:

package main

import ".../src"

func main() {
    // Initialize the struct with only the required options and then chain
    // the option methods to update the optional configuration attributes
    c := src.NewConfig("hello", "world").WithFizz(0).WithBazz(42)
    src.Do(c)
}

Task is a task runner / build tool that aims to be simpler and easier to use

version: '3'

tasks:
  hello:
    cmds:
      - echo 'Hello World from Task!'
    silent: true

By wrapping errors and building well-formatted error messages, we can keep better track of where errors are happening. I often just add the name of the function being called to my error messages, but we can make the message say whatever we want. For example, I’ll often include parameter information in the error so I know which inputs caused the error.

• Оригинальный пост

В этом посте рассматривается широкий спектр тем, связанных с созданием сервисов на Go:

• Структурирование серверов и обработчиков с расчётом на максимальное удобство поддержки;

• Советы и рекомендации по оптимизации сервисов под быстрый запуск и правильное отключение;

• Обработка стандартных задач, применимых ко множеству типов запросов;

• Глубокое исследование правильного тестирования сервисов.

In this post I describe a couple of practice that makes the process of writing code faster, more predictable and straightforward

Thanks to generics, there are some interesting new ways to program in Go. This article explains how we can use functional programming techniques like Map, Filter, and Reduce, and what kind of problems they might help us to solve.

Несколько правил, чтобы держать Git приличном виде.

from bouncepaw:

Alex tells us that, for him, baking and cooking are easier than programming and soldering, because the errors there average out. As for me, this is completely inverse.

In programming, an error never fixes itself. You can observe it and fix it, you can write tests. You can run the program multiple times. It's you who fixes it, and you can understand how it's done. It's measurable!

Meanwhile, cooking is a nightmare. Burning something is routine for me. Is that too much or too little oil? For how long do I fry? What do I do with these spices? Do they really affect the taste? And to observe something, I can't rely on symbolic things like text. No, I have to look (is this color good? No idea!), smell (as if I know the difference) and taste (nothing more inaccurate).

I'm happy when something can be cooked with a timer. 15 min for buckwheat? I'm in. I'm more happy when the time is short. 4 min for this thin kind of spaghetti? Already boiling water!

I mean, even boiling water is not simple. My parents told me to wait until the correct bubbles appear. I'm waiting for the scary ones. Also, salt is supposed to make it boil faster. How much salt do I add?

And I didn't even talk about plants, which Alex also considers easy. They're not 😭

Totally agree!

Papers about programming languages involve complex notations, systems, and proofs. Static PDFs offer little support in understanding such concepts. I describe Nota, a framework for academic papers that uses the browser's interactive capabilities to support comprehension in context. Nota uses hover effects, tooltips, expandable sections, toggleable explanations, and other interactions to help readers understand a language's syntax and semantics. I demonstrate the use of Nota by rewriting a PL paper using its primitives, and also by writing this paper in Nota.

Беру любой JSON и вижу, как его можно упростить, убрав лишнюю вложенность. Вдвойне обидно, что на эту вложенность кто-то тратил время, а она не нужна!

Concurrency is the key to designing high performance network services. This talk expands on last year's popular Go Concurrency Patterns talk to dive deeper into Go's concurrency primitives, and see how tricky concurrency problems can be solved gracefully with simple Go code.

Смешной текст о том, что питон учить не надо. Я Питон не люблю, но тут совсем кринж!

Первая — программист закладывает абстракции там, где не следует.

Бритва Оккама ?

Вторая проблема — наоборот: программист не оставляет шанса поправить его код.

Бывает, проблему можно поправить функцией или макросом, но в код тянут библиотеку. Или можно купить готовое решение, но тимлид говорит: мы напишем свое через три месяца. Или разработчик насмотрелся видосов со свежей конфы и хочет проверить чужие идеи.

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

Так или иначе, если вы хотите оказаться готовым отмасштабироваться в горизонталь — стройте критические процессы на конечных автоматах и полностью асинхронно

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

A linter for Go that finds nil panics. It found several potential nil panic in Betula and Mycorrhiza codebases that I didn't bother fixing.

• https://github.com/uber-go/nilaway/

Functions that are part of your project’s source code but can never be
reached in any execution are called “dead code”, and they exert a drag
on codebase maintenance efforts.
Today we’re pleased to share a tool named deadcode to help you identify them.

This belief is, for me, not some abstruse theoretical assertion, but a deeply felt belief that essentially any question I might care to ask (about computers) has a comprehensible answer which is accessible with determined exploration and learning.

Free Encyclopedia of Programming Languages.

Генерирует фотку экрана с кодом, который вставит пользователь

This page collects common comments made during reviews of Go code, so
that a single detailed explanation can be referred to by shorthands.
This is a laundry list of common style issues, not a comprehensive style guide.

Никита рассказывает про текст и кодировки

The Go standard library is full of bad design choices from the perspective of safety of use.

The core idea is to canonicalize things. Both x < y and y > x mean the same, and, if you usethem with roughly equal frequency, you need to spend extra mental capacity to fold the two versionsinto the single “x tiny, y HUGE” concept in your head.

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

Everything you need to know about monorepos, and the tools to build them.

Заметка Ивана об htmx

Заметки о том, как писать и оформлять код на Си

If you want a single piece of advice to reduce your bug count, it’s this:
Re-read your code frequently. After writing a few lines of code (3 to 6 lines, a short block within a function), re-read them. That habit will save you more time than any other simple change you can make.

Языки программирования как люди

Для всех, кто знал SQL, но подзабыл

Я ещё так никогда не удивлялся регулярному выражению

Choosing the right tools to write a database model in Go can be overwhelming. This post describes the various approaches.

Рич Хикки рассказывает о различиях простоты и лёгкости в контексте проектирования и написания программ.

Говорит, что многие выбирают лёгкость, забывая про простоту. Со временем комплексность превращается во что-то такое, что сложно поддерживать и в чём сложно разобраться новичкам.

Нужно стремиться искать лёгкие способы делать простые программы.

Видео о том, как писать понятный код

OK, your program works. You've tested everything in sight. It's time to ship it. So you make a release version.

And the world crumbles to dust.

You get memory access failures, dialogs don't come up, controls don't work, results come out incorrectly, or any or all of the above. Plus a few more problems that are specific to your application.

Now what?

That's what this essay is all about.

The concept of stacked branches and stacked PRs