d'Ivan

Вам нужно реализовать свой io.Reader, и в Read уже вычитывать данные по очереди из частей файла.
Вот работающий пример реализации

package main

import (
    "io"
    "log"
    "os"
    "path/filepath"
)

type BlobReader struct {
    keys       []string
    currentKey uint64
    reader     io.ReadCloser
}

func NewBlobReader(keys []string) *BlobReader {
    return &BlobReader{
        keys: keys,
    }
}

// Read реализация интерфейса io.Reader, чтобы можно было ваш reader использовать в io.Copy
func (br *BlobReader) Read(p []byte) (int, error) {
    var err error

    // открываем каждый файл по очереди
    if br.reader == nil {
        filePath := filepath.Join(".", "blobs", br.keys[br.currentKey])
        br.reader, err = os.Open(filePath)
        if err != nil {
            return 0, err
        }
    }

    // читаем данные из текущего открытого файла, пока данные не закончатся
    n, err := br.reader.Read(p)

    // если данные в файле закончились, закрываем его
    if err == io.EOF {
        br.currentKey++
        br.reader.Close()
        br.reader = nil

        // io.EOF в err должно вернуть только у последнего файла, чтобы io.Copy считал все файлы и не завис на последнем.
        if br.currentKey < uint64(len(br.keys)) {
            err = nil
        }
    }

    return n, err
}

func main() {
    blobReader := NewBlobReader([]string{
        "2050-part1",
        "2050-part2",
        "2050-part3",
    })

    _, err := io.Copy(os.Stdout, blobReader)
    if err != nil {
        log.Fatalln(err)
    }

    log.Println("Done")
}

Еще нужно будет реализовать метод Close у вашего Reader'a чтобы небыло утечек файловых дескрипторов

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

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

Велосипед, конечно же, уже придуман, и называется расстояние Хэмминга. Только ваши флаги нужно представить в виде битовой строки.

https://stackoverflow.com/questions/4777070/hammin...

Перестать заниматься фигней и начать хранить агрегаты в базе

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

Можно в тестах требовать совпадение с некоторой абсолютной или относительной погрешностью.

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

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

1. Очень сомневаюсь.
2. Запрос Names.objects.get(name=name).count прекрасно использует индекс, если ты его, конечно, создал. 14 миллионов строк для индекса, тем более, уникального — очень мало. А если не создал, то это фулскан и очень долго

/bin/sh: cc: command not found

Спектрограмма

Лучше установить пакет так, как написано в его инструкции.
Выполните в командной строке
go get github.com/adshao/go-binance/v2

Ну и импорт потом вот так

import (
    "github.com/adshao/go-binance/v2"
)

1. Не советую такой формат использовать, для интерфейса возьмите более гибкий формат типа toml, yaml, или XML
2. Для данных используйте json или csv. Готовые решения уже есть
3. Если нужно хранить данные, которые пользователь вводит через интерфейс, то используйте какую-нибудь БД.
4. Если это десктопное прилодение, то вполне можно использовать встраиваемую БД, типа sqlite

1. Использовать queryset.iterator() чтобы избавиться от хранения всего списка объектов
   
2. Использовать StreamingHTTPResponse чтобы не буферизировать весь выхлоп
   
3. Формировать XML не целиком с помощью цикла в шаблоне, а по одному элементу (плюс хедер/футер XML)
   

Нормальная миграция подразумевает следующие характеристики:

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

Естественное применение миграций - это CI/CD. Т.е. в большинстве случаев ожидается минимальный простой приложения во время деплоя, именно поэтому миграции в большинстве своем изменяют структуры данных.
Но это совсем не означает того, что данные не могут быть изменены. Часто так бывает, что некоторые системные справочники требуют обновления или же данные пользователей требуют изменений. Например - для имени и фамилии использовалось одно поле, а теперь оно делится на два, как положено. Миграция данных в данном случае естественный и необходимый процесс, который может занять значительное время. Поэтому используется запланированный процесс выкатки приложения с его аннонсированием для пользователей. Запланированный даунтайм стандартная практика больших и сложных приложений, которые могут это себе позволить.
Если ваше приложение не может себе позволить остановку обслуживания пользователей, то для таких случаев пишется вспомогательный код, который делает обработку случаев немигрированных данных и вообще всевозможные костыли, лишь бы оно работало (основной источник гемора).

Является ли ресайз картинок частью миграции? И да и нет. Это зависит от ряда факторов - сломается ли приложение, если не будет картинки или будет старая картинка, это критичная функция или нет. Пример критичной функции - инстаграм.
Если дизайн приложения сделан правильно и функция второстепенная, то миграция происходит лишь на уровне БД, а сам ресайз на уровне приложения (скрипта во время выкатки). Пример - новый размер юзерпика, никто не умрет, если он будет больше или меньше, может выглядеть не очень какое-то время, но в конце концов он станет нормальным. Если для нового размера добавляется новый столбец, то в него во время миграции копируются данные из другого столбца, чтобы не рушить функционал.

Итак, мои ответы по вашим вопросам (как бы делал я):

1. Добавил бы миграции с внесением/удалением 2 новых столбцов. Первый для email, второй email_verified. После развертывания запустил бы скрипт верификации почты (ох нескорый и ненадежный этот процесс). По-хорошему, по первому логину просил бы проверить и верифицировать email путем отправки кода на него. Думаю, вы уже поняли, что мы попадаем в серую область того, что машинная проверка здесь неуместна. Но допустим, мы использовали машинную верификацию, все проверили, все нужно сделали. В следующей версии мы удаляем столбец email_verified.
   
2. Как правило, такие вещи данные в БД не изменяют, а значит нет необходимости в миграциях, достаточно скрипта. Но, если вы ок с простоем приложения, то можно вполне внести данный скрипт в миграцию, а также не забыть об откате этой миграции (удалять новые размеры, к примеру).
   

Как мы все видим, миграцию можно рассматривать, как в контексте СУБД, так и в контексте приложения в целом.
Общепринятая практика - рассматривать миграцию в контексте баз данных. Все остальное - скрипты и костыли в самом приложении.

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