programrails

Я прочёл книгу Jeffrey Richter, CLR via C#, Fourth Edition. Прочёл на английском языке - от корки до корки. В C# при этом я новичок, но уже до Рихтера кое-что прочёл.

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

Я есмь лоза, а вы ветви; кто пребывает во Мне, и Я в нем, тот приносит много плода; ибо без Меня не можете делать ничего.
Кто не пребудет во Мне, извергнется вон, как ветвь, и засохнет; а такие ветви собирают и бросают в огонь, и они сгорают.
где был ты, когда Я полагал основания земли? Скажи, если знаешь.
при общем ликовании утренних звезд, когда все сыны Божии восклицали от радости?
На это он сказал: вот, я вижу четырех мужей несвязанных, ходящих среди огня, и нет им вреда; и вид четвертого подобен сыну Божию.

И вот так - практически вся книга - только по-английски. Рихтер обладает уникальным талантом запутать на ровном месте простые и понятные вещи. При этом он часто говорит лишь так, чтобы его нельзя было однозначно понять. У него патологическое стремление высосать из пальца мнимые сложности там, где их нет.
Примеры кода он любит давать обязательно в виде километровых простыней - чтобы "утопить" нужные 2-3 (объясняемые) строки кода в пучине (абсолютно тут не нужного, но при этом довольно сложного) длинного кода.
Рихтер - это человек, кому следует законодательно запретить писать книги. Полнейшая бездарность с точки зрения умения объяснить что-либо. Сам он, несомненно, что-то знает - но избегает ответственности объяснить, как положено - из-за своего малодушия, думаю.
Все, кто его хвалят - скорее всего, просто не прочитали его до конца. А я прочёл. Последний раздел (многопоточность) - вообще практически нечитаемый.
Повсюду в книге ненужное многословие, напускание тумана на ровном месте. У этого человека явно проблемы с психикой - он может лишь бесконечно "ходить вокруг до около", но неспособен "взять быка за рога".
Книга его в значительной степени - просто мусор - выброшенные на помойку время и деньги. Пора, наконец, это признать - вместо бесконечного нашего низкопоклонства перед Западом. Читая его книгу, я постоянно испытывал острое желание дать ему палкой по голове. Теперь, к сожалению, придётся читать что-нибудь другое - с нормальным (хотя бы) объяснением. Я просто в ярости от этой книги. Нет ни малейшего сомнения в том, что весь этот материал не составляло никакой проблемы объяснить гораздо более простым и ясным языком. Весь раздел многопоточности по большому счёту прошёл полностью мимо, понять там что-либо практическое так и не удалось. Да как же так? Я бы понял, если бы хотя бы отдельные места остались непонятными - но не целый же раздел книги целиком?
И неважно, то я что новичок в C#. Важно то, что я прочёл до этого много других правильных книг, и знаю, как их следует писать. Этот автор "говорит много, но так, чтобы в итоге ничего не сказать".

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

Далее - устройтесь на галеру джуниором за еду. Что такое "галера", написано уже даже в Википедии. Никуда больше Вас не возьмут - если нет блата. Через 6 месяцев - смените работу на не-галеру.

Конечно, не всё так просто, надо бы по-хорошему пойти учиться в ВУЗ по специальности "программирование". Или же постараться в домашних условиях проэмулировать такое вузовское обучение - изучая теорию, например, "устройство операционных систем (Линукс)", языки типа С, С++, Ассемблер. Структуры алгоритмы обработки данных. Но теории, вообще-то, не так уж и много - специфичной для программиста. Также надо практиковаться в разных областях программистского знания, нужен обязательный практикум по программированию.

Если хотите простой совет - читайте книги и тренируйтесь дома писать программный код. Выберите, например, Python, и прочтите некое достаточно большое число учебников по нему (сколько - намеренно не скажу) - тогда Вы и сами в себе почувствуете силы пойти на джуниора. Профессия тестировщика мне лично не нравится, я бы на Вашем месте сразу метил в программисты. Что такое "программист" - это большое количество прочитанных учебников по программированию + большой практикум решения разнообразных задач - на разных языках - что, скорее всего, достигается путём работы в разных местах - ну, может, некоторые уникумы и дома так ухитряются прокачаться? Теоретически можно себе представить, что Вы сделаете некий некоммерческий проект на Python дома, его начнут посещать тысячи, Вы будете бесплатно такой проект обслуживать - и на том вырастите свою квалификацию.

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

Priority queues are data structures that provide more flexibility than simple sorting, because they allow new elements to enter a system at arbitrary intervals.

с таковым из англоязычной Википедии:

In computer science, a priority queue is an abstract data type which is like a regular queue or stack data structure, but where additionally each element has a "priority" associated with it. In a priority queue, an element with high priority is served before an element with low priority.

Ну идиот, что сказать. Плюс, русский перевод добавляет порой неточности. И даже опечатки в коде добавляет. Хотя читать Скиену следует всё-таки на русском - но то и дело поглядывая в англоязычный оригинал. Русский переводчик явно старался - это заметно. Но, всё-таки, в редких случаях допускал неточности. Я пробовал читать и по-английски - ввиду дебилизма автора, это получалось супермедленно. Всё-таки русский переводчик как мог, сгладил этот дебилизм (пусть и допустив редкие ошибки при этом), поэтому по-русски читается куда как более гладко, и гораздо быстрее.

Многочисленные хвалебные отзывы о Скиене - это ошибка и глупость. Я не смог его прочесть, бросил на 130 странице, убив в 2-3 раза больше времени, чем на обычную книгу. Скиена - просто негодяй. Он даже и не пытается что-либо толком объяснить - либо делает это с явным отвращением. Причём я пробовал читать Скиену и в оригинале - практически ничем не лучше - точно такая же абсолютно мусорная книга. Читать Скиену, если и можно - то только имея за плечами десяток уже прочитанных хороших книг по алгоритмам - чтобы понимать, что этот недоумок опустил между строк.

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

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

Скиена - это мусорная книга.

Я подозреваю, что американской фирме нанять self-employed на постоянную работу (российский ИП на удалёнку) - вообще есть нарушение американских законов. Потому что имеет место подмена трудового договора на договор подряда - действие, запрещённое не только в России (и подлежащее административке), но и в США по американским законам (вроде бы - но точно не знаю). По крайней мере, я где-то на забугорном форуме видел такие рассуждения. Кроме того, непонятно, как быть со страховкой. В теории, российский ИП должен по-хорошему покупать российскую страховку на себя - и так, чтобы её покрытие оказалось достаточным, чтобы в случае своих неправильных действий покрыть убытки американской стороны. А для этого и миллион долларов покрытия страховки может оказаться мало - в средней американской компании миллион убытков по вашей вине может за 2 дня вылететь. И в контракте надо прописывать, что страховая ответственность длится только на период контракта - но не после. А российскому ИП обычно трудно что-то там диктовать удалённому работодателю - ведь за окном полно желающих (в драку за оффером).
Почему такое не распространено - потому что слишком геморно - для солидных иностранцев. Как правило, удалённых работников ищут только несолидные иностранные нищеброды - в погоне за экономией копейки. С ними так неприятно иметь дело - они же нищие. И проекты у них идиотские и никому не нужные - как правило. Мне кажется, что единственный правильный путь - создать свой бизнес в России, и его представительство за рубежом. Вот тогда ещё есть шанс на какую-то стабильную занятость. Либо работать в России сотрудником такого бизнеса. Либо вариант, когда американская сторона открывает филиал в Москве, а вы там работаете. В общем, нужен некий мощный посредник - между Вами и американской стороной - посредник, который вы либо создадите своими руками, либо как-либо сумеете воспользоваться чужим посредничеством. Все остальные планы "из России как ИП найти хорошую стабильную удалёнку на США" - всё это в 90% случаев лишь влажные мечты наивных юношей. Всё не так просто. И вообще - можно условно считать, что "удаленной full/part time работы (не фриланс) на США" просто не существует - как таковой. Если, конечно, вы не гражданин США, живущий в России. Всё, что реально - это только перебиваться случайными короткими контрактами - находить которые настолько нелегко - что подумаешь лишний раз - а "оно мне надо"?

Выбор книги по алгоритмам: Кормен или Скиена?

Здесь Какую литературу можно найти по golang?

Здесь Какую литературу можно найти по golang?

Я бы рекомендовал изучение в такой последовательности:

Beginner level (синтаксис языка):

1. Начать с golang-book.ru . Это на русском и довольно неплохо для начинающего.

2. https://golang.org/doc/effective_go.html - это уже на английском, но всё равно толково и хорошо заходит после 1-го пункта. Кратко, по делу, без воды, достаточно понятно.

После прочтения этих 2 пунктов у Вас уже будут базовые понятия о языке.

Intermediate level (concurrency - многопоточность):

Как ни пытался, не смог определить какую-то конкретную универсальную книгу. На этом уровне много плохих книг, сложно выделить что-то хорошее. Относительно неплохими для этого уровня (пока что) показались:

(продолжаем последовательность изучения Go по пунктам):

3. Базовый веб сервер на Go Статья, без которой дальнейшее трудно заходит (книгоавторам всем дружно лень такое нормально объяснить).

4. M. Curtis - Level Up Your Web Apps With Go
Читал - и не понимал - что происходит? Чувак явно пишет рельсы на Go! Всё такое до боли знакомое... Что такое? А потом смотрю в профиле https://www.linkedin.com/in/mal-curtis/ - так он же пишет на работе на Ruby on Rails! Так что книжка отлично зайдёт рельсовикам, осваивающим Go. Книга неплохая, автор явно старался. Автор, ты хороший человек.

5. K. Cox-Buday - Concurrency in Go. Tools and Techniques for Developers. Книга не очень удачная, но пока я не успел найти что-то получше. Автор - женщина, и глупая. Книга читается мучительно и крайне медленно. Охват материала неплох - но объяснения косноязычные, с водопадом лишних слов и эмоций, примеры кода неоправданно переусложнены, ряд тем вообще остались бы непонятыми, если бы не гугление. Читаю и матерюсь на каждом шагу.
PS Последние 2 главы пошёл уже такой горячечный бред, что я просто не смог заставить себя читать этот ужас. Бросил. В общем, далее параграфа Queuing читать не стоит. Книга прекрасно иллюстрирует тезис, что, какими бы умными ни были женщины, они всё равно дуры, и нечего им в программировании делать (кроме разве что 1С).
К сожалению, книгу прочесть всё-таки надо, ибо охват хорош - а заменить книгу особо нечем (в смысле другой книгой, продаваемой за деньги - разве что статьями).

Есть ещё книга N. Kozyra - Mastering Concurrency in Go - но у неё ужасные отзывы - да и я пытался читать другую книгу по Go у этого же автора - и мне также крайне не понравилось.
Смешно сказать - но по Go нет ни одной путёвой книги про Concurrency (единственное, ради чего Go был создан)!

6. Лучшее объяснение Go Context, что я пока видел. Оно даже лучше официального (написанного индусом, и оттого плохого).

7. M. Tsoukalos - Mastering Go - но только Chapter 10: Concurrency in Go – Advanced Topics - и исключая параграф Worker pools (он ошибочный - там ничто не сдерживает размножение горутин - какой же тогда это пул).
Средне-удовлетворительная глава, звёзд с небес не хватает, интереснее всего был параграф Sharing memory using goroutines - частный пример Катькиного Confinement'а.

Advanced level (микросервисы на Go):

Я пытался читать N. Jackson - Building Microservices with Go - это оказалось невозможным, книгу написал какой-то сумасшедший безумец, находящийся в состоянии наркотического опьянения. Отзывы на Амазоне это подтверждают.

Также я попытался читать M. Ryer - Go Programming Blueprints (2 ed) - только главу Chapter 10: Micro-services in Go with the Go kit Framework - не понравилось. Примеры кода сложноваты (автор пытается построить реальную систему - ну и дурак - вместо того, чтобы ограничиться демо-примером), объяснения сопутствующего материала никакие (по сути, их нет). Бесполезная глава. Несколько тем свалены вместе - но ни одна толком не объяснена. Очень слабенький автор.

Вердикт: нормальной книжки по теме "Go микросервисы" пока не обнаружено. Придётся изучать эту тематику из статей и инструкций по использованию микросервисных Go-фрэймворков - вот списочек фрэймворков:

• gRPC (а вместе с этим и его пререквизит - гнуснейшая мерзость protobuf)
  
• Go Micro
  
• Go kit
  
• Gizmo
  
• Kite
  

Я начал с gRPC. Сначала прочёл официальную доку по protobuf (включая раздел о Go). Дока оказалась достаточно вменяемой. Но зато официальная дока по gRPC уже оказалась совершенно паршивой. Там 2 примера - попроще и посложней. Писали доку явно последователи тех, кто писал доку к первому ангуляру (т.е. те, кому я бы отрубил обе руки по самые плечи). Понять что-либо без исходников (к статье) - нереально. Но - исходники ещё надо найти, ибо в статье ссылки на них ... нет. Оказалось, исходники тут: https://github.com/grpc/grpc-go/tree/master/exampl... . Но даже с ними - всё довольно непросто понять - даже в простейшем примере. Потому что авторы умолчали о многих важных моментах. Т.к. им в падлу шевельнуть задницей лишний раз. В общем, есть нужда в нормальном авторе, кто опишет, что такое gRPC. Попробуйте почитать статью от Шизы - это слегка окультуренный сокращённый пересказ сложного случая.

Рассмотрим Go Micro. Продукция очередного кретина (да ещё и спорного качества). Что, скажите, можно понять из таких "объяснений"? Кстати, ищите в Яндексе термин "Service Discovery" - здесь нужно понимать, что это. Посмотрите и Consul. Вот ещё разумная статья о Go-микросервисах. И ещё я понял - без предварительного изучения protobuf и gRPC понять Go Micro будет затруднительно (если вообще возможно). Желаю вам никогда не встретить на работе продукцию этого дегенерата. Go Micro показался мне китайским фонариком со встроенными компасом, радиоприёмником, часами, зарядкой, отвёрткой, точилкой для карандашей, ногтерезкой, и т.д.

Идём дальше. Go kit производит намного более лучшее впечатление. Правда, документация не полная - автору не хватило терпения её закончить. Но всё же разобраться можно - есть исходники-примеры, снабжённые подробными комментариями. Автор мне понравился.

Почитайте полезную статью-сравнение.

Приложение:

Гоняться за русскоязычными книгами по Golang не рекомендую. Я прочёл на русском:
- А. Донован, Б. Керниган - Язык программирования Go
Это совершенно отвратительная бездарная книга.
и просмотрел оглавление русскоязычной книги:
- М. Саммерфильд - Программирование на языке Go
Хотя я её не читал, но беглый просмотр её оглавления создаёт самое негативное впечатление о книге. Такое ощущение, что это целенаправленная диверсия против изучающего golang, с целью развести его на время (прочтения) и деньги (при покупке). Марк Саммерфилд - это профессиональный графоман, посмотрите сами на его карьерный путь: https://www.linkedin.com/in/qtrac/

Обе перечисленные книги (доступные онлайн бесплатно в электронном виде как векторный PDF), хотя и русскоязычные, настоятельно не рекомендую.

М. Батчер, М. Фарина - Go на практике - на русском языке - эта книга вроде бы достаточно неплохая, но она для опытного разработчика - и она не излагает системно - а отрывисто.

Пытаться читать спецификацию языка также не рекомендую - ничего не поймёте:
https://golang.org/ref/spec

Заключение

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

Англоязычных книг по Golang в электронном виде бесплатно - много, более 30 (а то и под 50). Многие написаны индусами, или оторванными от жизни вузовскими преподами, или какими-то левыми любителями Go (у таких "книг" даже нет ISBN). Есть даже книги, написанные неграми! Все такие книги требуют осторожного выбора. Почему именно Go вызвал у окружающих непреодолимые позывы к графоманству? Такое впечатление, что многие авантюристы решили "срубить баблишка" на "хайповой" теме. Действительно, найти хотя бы нормальную книгу (не говоря уже о хорошей) - оказывается по факту крайне непросто - почему-то именно к Go примазались многочисленные негодяи и бездари - как ни в каком ином языке программирования.

Всё, о чём я рассказал в этом посте, доступно бесплатно онлайн в электронном виде (Либген, к примеру).

В общем-то, основное внимание при изучении Go следует уделить его возможностям по многопоточности (concurrency), которые включают низкоуровневые механизмы (как в C++) типа мьютекса и высокоуровневые механизмы типа каналов. Собственно, это как раз то самое, зачем Go вообще понадобился. Вторая по значимости тема в Go, как мне кажется, это микросервисы.

Если для начинающих - Олиферы - однозначно. В Сети есть бесплатное 5-е издание Олиферов в формате DjVu - идеального качества. Все остальные перечисленные книги также есть в Сети в электронном виде бесплатно, но в них или недостаточно системный подход к изложению материала, или же просто они устарели (например, нет описания CIDR), или имеют плохой перевод (Таненбаум). Читая Олиферов, чувствуешь, что это редкая порода преподов, которые действительно хотят объяснить понятным языком - а не выпендриться своей учёностью (или замаскировать своё незнание пышными словесами): https://www.olifer.co.uk/we/we.htm

Только найдите Олиферов 5-е издание (а то есть и более ранние) - чтобы не читать устаревшее.

А уже после Олиферов - читайте всё остальное в этом списке - благо, что платить ничего не надо, всё бесплатно.

UPDATE.

Досталек Л., Кабелова А. «TCP/IP и DNS в теории и на практике.»

Лично мне категорически не понравилась книга:

Язык программирования Go (Алан А. А. Донован, Брайан У. Керниган )

Прочёл её в оригинале на английском языке и могу сказать: это просто верх бездарности - данная книга. Она поразительно неуклюжа внутри. Объяснение материала вызывает постоянное раздражение своей нелогичностью, непоследовательностью - какие-то рваные куски логического мышления. Хочется просто обматерить авторов. А ведь при желании как просто, хорошо и удобно можно было бы изложить и объяснить весь материал. Но нет - у авторов явно нет такого желания - хотя, скорее, у них просто тараканы в голове. Даже английский язык авторов и то плох - своей корявостью - в сравнении с другими англоязычными учебниками. Настолько, что порой приходилось подглядывать в русский перевод данной книги (выполненный, кстати, очень качественно) - чего я никогда не делаю (я всё читаю только в оригинале, даже если есть перевод - потому что перевод всегда искажает смысл).

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

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

Или такая вещь - сначала идёт текстовое объяснение сути работы куска кода - и лишь ПОТОМ идёт сам этот кусок кода. Во то время как сначала надо приводить код - а лишь потом его текстовое объяснение. Это раздражает - и такая нелепица - в большом и в малом. Некоторые важные мелочи вообще не объясняются (остаются за кадром) - авторы забывают о том, что человеку это может быть неизвестно/непонятно. Ход изложения материала недостаточно последовательный. Слишком много громоздких и чересчур сложных примеров. Короче, сплошной идиотизм. Авторы органически неспособны излагать учебный материал в правильной форме. И это при том, что (вроде бы) один из них находился в команде разработчиков языка. Но, как видно, это ещё не значит, что он способен адекватно объяснить язык Go. Целые куски глав со сложными примерами приходится, скрипя зубами, пропускать (при чтении). Часть примеров бессмысленно переусложена - и зачем-то дублирует уже объяснённый материал.

Как говорил Задорнов - "ну тупые они, тупые" - трудно подобрать более точную характеристику к авторам данной книги.

Оба варианта - доступны бесплатно в электронном виде в PDF, русский, правда, только как скан (что неудобно, хоть скан этот и весьма приличного качества). Меня ещё смешит запредельно-грабительская цена на русский перевод книги, не вздумайте выкидывать деньги на это барахло.

В итоге - книга прочитана - но я чувствую, что систематических знаний по Go у меня как не было, так и нет. Так, какие-то жалкие обрывки. Надо теперь что-то иное читать. Убил бы авторов.

Я лично думаю, что тесты - это образчик типично западного лицемерия - как в сказке Андерсена "Голый король". Тесты - это чушь собачья (точнее, чушь свинячья). Полезность тестов - вымышленна. Тесты были изобретены на Западе - и они чужды по духу русскому человеку - ввиду своего чудовищного (типично Западного) лицемерия. Сторонники тестов пытаются что-то там такое невразумительное говорить (в защиту тестов) - но никто им не торопится верить - отсюда, собственно, и появился данный вопрос на данном форуме - если бы полезность тестов была реальна - люди бы не спрашивали, зачем они нужны - а просто пользовались бы ими. Все, кто выступает в защиту тестов - я думаю, лишь послушно повторяют цитаты из западных учебников - вместо изложения своих собственных мыслей. Конечно, ведь так хотят работодатели - так как же можно выступить против них?

Где, скажите, убедительно-неопровержимые доказательства нужности тестов как таковых? Их нет. Взамен предлагается просто поверить на слово в "полезность" тестов. Кроме того, написание тестов отнимает уйму времени и само по себе является источником ошибок. Намного быстрее и эффективнее просто проверить руками тот или иной функционал - чем писать для этого тест - как правило, на чрезвычайно неудобном, корявом и глючном тестировочном языке.

Писать же тесты ДО написания кода - это вообще ВЕРХ абсурда. Неужели непонятно, НАСКОЛЬКО противоестественно это занятие? Это просто дичь какая-то. Даже сами западные авторы учебников по тестированию об этом пишут - я прочёл несколько западных учебников по тестированию, пытаясь найти хоть какой-то смысл в тестах - они пишут, что BDD хорошо не более чем в 20% случаев.

Использовать тесты как защиту на будущее - "если что-то поломается при новых правках"? Ну извините, а не слишком ли дорогая цена - для 90% проектов? Да, может быть, на каком-нибудь миллионно-посещаемом сайте это и оправдано экономически - но на подавляющем большинстве сайтов - едва ли.

И вообще - даже если и идея автоматизирования тестирования и носит разумное зерно - почему нужно СПЕЦИАЛЬНО вручную писать тесты? В лучшем случае, это должно быть сделано так: ты тестируешь РУКАМИ какую-то фичу - а программа при этом АВТОМАТИЧЕСКИ запоминает всю последовательность ручных тестировочных действий (и потом воспроизводит при нужде). Только так это имеет право выглядеть. Я немного утрирую, конечно - но суть в том, что это безумный абсурд - писать тесты руками - тратя на это уйму времени и генерируя тем самым новые ошибки.

Короче, я для себя лично пока что решил так: писать тесты только для западных заказчиков - чтобы их душа была спокойна. И делать тесты как можно правдоподобней при этом - максимально выдавая их под якобы действительно нужную и полезную вещь (с точки зрения западного менталитета). Вот моя чисто практическая рекомендация. У них там на Западе множество идиотизмов, не понятных (и чуждых) русскому человеку - и это один из них.

Так что я действительно искренне не понимаю - зачем нужны тесты - и считаю, что они и не нужны на самом деле - а нужны исключительно для введения в заблуждение западных заказчиков - и больше ни для чего. Во всяком случае, в том (нелепом) виде, в котором они (тесты) существуют сейчас. Я же свой код тестирую руками - и это намного лучше и эффективней тестов. Да, я не говорю, что я не тестирую свой код - тестирую обязательно (а как же без этого) - но только руками. Может быть, и есть в отдельных случаях смысл написать именно тест - если руками тяжело и долго воспроизводить тестировочно-проверочную последовательность действий - но это как исключительный случай. Западное же требование покрытия кода тестами под 80-90% - вообще полная чушь - бездумная и шаблонно-тупая. Они ведь там тоже не семи пядей во лбу - а главное, что на Западе категорически запрещено думать своей головой - это только в России пока позволено (и то не каждому, как очевидно).

Я против тестов (в нынешнем их виде). Тем более, я против TDD. Но я не против тестирования - но только ручного.

Излагайте свои доводы - но только СВОИ, а не где-то вычитанные.

Моё личное ИМХО:
1. Для того, чтобы выносить мозг нормальным людям при собеседованиях. Это их основная и главная область применения.
А ещё для динамического хранения данных. Смысловой аналог функции malloc в языке СИ, только более извращённо-вывернутый - "недовернувшаяся функция" (т.е. зависшая в памяти по сути). Человек, подвешенный за кишки. Отличие от malloc в том, что malloc просто выделяет кусок памяти под данные - а тут кусок памяти выделен под "данные + их некий обработчик" в одном флаконе.
2. Если говорить о веб-разработке - то на фронтэнде. Если не могут или не хотят хранить данные по-человечески - в куках, локальном хранилище, БД.

Насколько мне известно, бэкэндеру это вообще не нужно - только фронтэндеру. Ведь на бэкэнде всегда есть БД - и эти извраты ни к чему.

ng-book - отвратительнейшая книга, спущенные в унитаз несколько дней. Поначалу вроде бы ничего - но потом... Редкий случай - эту книгу даже на Амазоне НЕ советуют покупать. Автор явно что-то курил непосредственно перед написанием книги - в манере написания текста прослеживаются характерные признаки (стенограмма сказанного человеком, который бредил - в медицинском смысле).

Проблема решена.

В кабинете Payoneer есть обмен валюты

Действительно, так оно и оказалось. С недавних пор Payoneer ввёл обмен фунтов, евро, долларов друг на друга прямо в кабинете пользователя. Так что я без проблем поменял пришедшие фунты в доллары - и комиссия при этом оказалась достаточно скромной. Теперь остаётся просто вывести доллары (бывшие фунты) с Payoneer - как обычно.