Выводит дерево каталогов и файлов (если указана опция -f). Например:
go run main.go . -f
├───main.go (1881b)
├───main_test.go (1318b)
└───testdata
├───project
│ ├───file.txt (19b)
│ └───gopher.png (70372b)
├───static
│ ├───css
│ │ └───body.css (28b)
│ ├───html
│ │ └───index.html (57b)
│ └───js
│ └───site.js (10b)
├───zline
│ └───empty.txt (empty)
└───zzfile.txt (empty)
В этом задании мы пишем аналог unix pipeline.Когда STDOUT одной программы передаётся как STDIN в другую программу Но в нашем случае эти роли выполняют каналы, которые мы передаём из одной функции в другую.
Само задание по сути состоит из двух частей:
- Написание функции ExecutePipeline которая обеспечивает нам конвейерную обработку функций-воркеров, которые что-то делают.
- Написание нескольких функций, которые считают нам какую-то условную хеш-сумму от входных данных
Расчет хеш-суммы реализован следующей цепочкой:
- SingleHash считает значение crc32(data)+"~"+crc32(md5(data)) ( конкатенация двух строк через ~), где data - то что пришло на вход (по сути - числа из первой функции)
- MultiHash считает значение crc32(th+data)) (конкатенация цифры, приведённой к строке и строки), где th=0..5 ( т.е. 6 хешей на каждое входящее значение ), потом берёт конкатенацию результатов в порядке расчета (0..5), где data - то что пришло на вход (и ушло на выход из SingleHash)
- CombineResults получает все результаты, сортирует (https://golang.org/pkg/sort/), объединяет отсортированный результат через _ (символ подчеркивания) в одну строку
- crc32 считается через функцию DataSignerCrc32
- md5 считается через DataSignerMd5
В чем подвох:
- DataSignerMd5 может одновременно вызываться только 1 раз, считается 10 мс. Если одновременно запустится несколько - будет перегрев на 1 сек
- DataSignerCrc32, считается 1 сек
- На все расчеты у нас 3 сек.
- Если делать в лоб, линейно - для 7 элементов это займёт почти 57 секунд, следовательно надо это как-то распараллелить
Есть функиця, которая что-то там ищет по файлу. Но делает она это не очень быстро. Надо её оптимизировать. Задание на работу с профайлером pprof. Цель задания - научиться работать с pprof, находить горячие места в коде, уметь строить профиль потребления cpu и памяти, оптимизировать код с учетом этой информации. Написание самого быстрого решения не является целью задания.
Для выполнения задания необходимо чтобы один из параметров ( ns/op, B/op, allocs/op ) был быстрее чем в BenchmarkSolution ( fast < solution ) и ещё один лучше BenchmarkSolution + 20% ( fast < solution * 1.2), например ( fast allocs/op < 10422*1.2=12506 ). По памяти ( B/op ) и количеству аллокаций ( allocs/op ) можно ориентироваться ровно на результаты BenchmarkSolution ниже, по времени ( ns/op ) - нет, зависит от системы.
Это комбинированное задание по тому, как отправлять запросы, получать ответы, работать с параметрами, хедерами, а так же писать тесты.
Задание не сложное, основной объёма работы - написание разных условий и тестов, чтобы эти условия удовлетворить.
У нас есть какой-то поисковый сервис:
- SearchClient - структура с методом FindUsers, который отправляет запрос во внешнюю систему и возвращает результат, немного преобразуя его
- SearchServer - своего рода внешняя система. Непосредственно занимается поиском данных в файле
dataset.xml
. В продакшене бы запускалась в виде отдельного веб-сервиса.
Требуется:
- Написать функцию SearchServer в файле
client_test.go
, который вы будете запускать через тестовый сервер (httptest.NewServer
, пример использования вhttp/server_test.go
) - Покрыть тестами метод FindUsers, чтобы покрытие было максимально возможным, а именно - 100%. Тесты писать в
client_test.go
. - Так же требуется сгенерировать html-отчет с покрытием. См. пример построения тестового покрытия и отчета в соответствующей лекции (напоминаю, для этого ваш код должен находиться внутри GOPATH).