Егор Полянский

Минимум:

• Схема/диаграмма взаимодействия с API, а так же внутренней логики
  
• Документация по всем методам/точкам входа
  
• По параметрам методов
  
• Возвращаемому результату
  
• Ограничения самого API, методов и параметров
  
• Подробное описание ошибок и кодов ошибок
  

Остальное — в зависимости от особенностей конкретного API и фантазии разработчика.

qiangxue/go-rest-api на гитхабе — там cmd/internal/pkg с разбивкой по фичам, сразу видно где logger, где config, где роутер. Ещё go.dev/doc/modules/layout — официальная дока. golang-standards/project-layout тоже смотрят, но это не стандарт, а community-сборник. Вариаций много, единого правильного нет.

Интерфейс в Го, это структура с двумя полями.
1. Указатель на данные (в вашем случае на структуру User с age и name)
2. Указатель на таблицу виртуальных методов.
В таблице виртуальных методов как раз перечислены методы, которые реализованы на структуре и на рантайме через нее Го понимает, что можно вызывать, а что нельзя.

В статье https://habr.com/ru/articles/856272/ можете почитать подробнее, там описано как работает itab (таблица виртуальных методов).

Можно ли даже при созданном вручную String() использовать метод String() из стандартной библиотеки?

String в стандартной библиотеке это не метод на структуре. Это код, который через рефлексию смотрит что ему пришло и вызывает соответствующий форматтер. Одно из условий, которые он проверяет, это как раз, имплементит ли объект интерфейс Stringer, поэтому в вашем коде вызывается этот метод.
Использовать стандартный форматтер структуры получится разве что костылями, дергая вручную более "тупые" методы стандартной библиотеки или через пакет reflect вытащить данные из структуры.

Как это вообще может помочь в целом в работе и какие есть юзкейсы для этого?

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

Документация по самому проекту и его архитектуре в частности. Заказчик ставит задачу, на основе этой задачи разрабатывается ТЗ, а на основе ТЗ - частное ТЗ со всеми деталями проекта, в том числе и архитектурой. Вот вам несколько примеров:
Вот ещё один отличный пример: описание структуры JSON - https://www.json.org/json-ru.html

MSI обычно модная с кучей индикаторов. У меня даже на геймерском гигабайте есть четыре крохотных светодиодика. Кстати, мать может не стартовать, если к ней не подключен монитор. Да-да, именно так! У меня мать без монитора не стартует.
Бипер иметь при себе, если тачки собираешь сам - обязательно. Сними со старого компа, раньше ставили на всех.

Наиболее распространённый метод — IntroSort. Если рекурсия ушла глубоко, переключиться на другой метод. Постоянные n log n и не теряются классные свойства QuickSort.

Да, есть методы именно на быстрой сортировке, но, видимо, умные люди всё испытали и ничего лучшего не нашли.

Да, можно. Для этого надо в качестве pivot'а выбрать медиану. если это сделать за O(n) в худшем случае, то общая сложность QuickSort'а будет O(n log n).

Для выбора медианы за O(n) есть, например, вот такой алгоритм. В каких-то источниках его еще называли алгоритмом кнута-пратта-мориса-ривеста-тарьяна. Кажется, но я их найти не могу, так что я какие-то фамилии напутал, но помню, что там было 5 великих информатиков.

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

Dual-Pivot Quicksort должен решать проблему с почти отсортированными массивами, но у него тоже существует worst case сценарий с n^2 (массив уже отсортирован полностью по убыванию либо возрастанию), но этого хотя бы можно избежать, добавив проверку, что массив уже отсортирован (делается в один проход)

В унимодальной функции разности соседних элементов сначала неотрицательные а потом неположительные. И наоборот, если разности такие, то, очевидно, сначала функция возрастает (возможно, ступенчато) а потом убывает.

Вы доказали, что частичные разницы не возрастают. Тут могут быть 3 варианта:
1) они все неотрицательные. Функция унимодальна (монтонность с максимумом в конце - частный случай унимодальности).
2) они все неположительные. Монотонно убывающая функция.
3) есть и положительные и отрицательные. Но раз разности не могут возрастать, после первого 0 могут идти только нули а после отрицательного только отрицательные. А заначит разности выглядят ровно так, как у унимодальной функции.

а общее число перераспределений для n добавлений уменьшается как O(logn). Почему тогда в таком случае для n последовательности append-ов общая сложность равна O(n), а не O(n logn)?

Потому что эти распределения разного размера. Первое - совсем маленькое. Второе чуть больше и т.д. Чтобы суммарно было O(n Log n), каждое из них должно быть пропорционально n.

1+4+10+⋯≤O(n)

Вот это и есть ответ. Первые слагаемые маленькие. Получается геометрическая прогрессия, которая дает линейную сумму от n.

Потому что, здесь вступает в игру такое понятие как амортизированная сложность. Для динамических массивов, которые увеличиваются в несколько раз (т.е. не + 10, а *2 например), амортизированная сложность - O(1).
Поэтому, у тебя O(n) * O(1) = O(n) (амортизированное)

В такой реализации это плохо видно, но можно переписать основной цикл так:

j = Len(B)-1
for i in range(len(A)):
  while j >= 0 and A[i] + B[j] > c:
    --j;
  if A[i] + B[j] == c:
    found = True
    break

В этом случае после цикла while поддерживается инвариант, что a[i]+b[j] <= c и это максимальное такое j.
Ведь, если этот инвариант поддерживался для пердыдущей итерации, то у нас было a[i-1] +b[j] <=c и a[i-1]+b[j+1]>c. Отсюда получается, a[i]+b[j+1] >= a[i-1]+b[j+1] > c. Т.е. если мы уменьшим j в цикле while инвариант останется действовать - это будет самое большое j, т.ч. a[i]+b[j] <= c.

А этот инвариант гарантирует, что когда в цикле по i переберется значение из ответа, j гарантированно будет указываать на j из ответа. Потому что, если существуют i', j', т.ч. a[i']+b[j'] = c, то можно увеличить j' пока b там не меняется, т.ч. b[j']>b[j'], отсюда получается a[i']+b[j'] <=c и a[i']+b[j+1] > c - а это и есть наш инвариант. Т.е. на итерации i=i' найдется именно j=j'.

В settings.json добавьте "code-runner.runInTerminal": true, и должно быть вам счастье
После этого в терминале появиться возможность ввода данных