nano_e_t_4

Тут два варианта - костыльный и сложный.

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

Для отслеживания я обычно использую утилиты Руссиновича, хотя есть и такие программы как - Ashampoo UnInstaller, Revo Uninstaller, и.т.д.

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

привидите пожалуйста пример где именно обращение к инвентарю и что именно там в инвентаре за код.

и отчасти Константин Китманов ошибается. а freeExec отчасти верно вам говорит. что при ссылке на объект у вас доступ к полям и методам будет.

и вот что важно бы вам уяснить, на ВЫКЛЮЧЕННЫХ объектах не работает НИКАКОЙ ПОИСК.
GetComponentInChildren - это тоже ПОИСК. и все ему подобное не сможет ничего найти на выключенных объектах.
может в инвентаре у вас не просто получение значения
inventory.ItemList[0].cost
а что то в духе

inventory.GetItemInfo(0);
///
void ItemInfo(int itemIndex)
{
something.GetComponent<T>();
}

и такое не будет отрабатывать, потому не ленитесь побольше кода прикладывать)) хотя и весь проект целиком тоже не стоит. хм, тут не просто угадать))

currentTarget:

event.currentTarget.getAttribute('имя_атрибута')

Или, есть вариант атрибут вообще не устанавливать, а передавать в обработчик нужное значение:

onClick={e => props.arrowHandler(e, VALUE)}

Это у вас случайно не YAML?
Если да, то https://godoc.org/gopkg.in/yaml.v2
Какое расширение файла?

redux-thunk

Если лайаут одинаковый на каждом маршруте:

render() {
  return(
    <Wrapper>
      <Header />
      <Main />
      <Footer />
    </Wrapper>
  );
}

в компоненте Main располагаете Switch с маршрутами.

Если на разных страницах он может быть разный. То можно сделать контейнеры для контента:

const MainPageLayout = ({ children }) => (
  <Wrapper>
    <Header />
    <PageContent>
      {children}
    </PageContent>
    <Footer />
  </Wrapper>
);

и оборачивать в него код страницы:

const SomePage = () => (
  <MainPageLayout>
    {/* page code */}
  </MainPageLayout>
);

а в главном компоненте расположить Switch с маршрутами.

Компонент Router лучше расположить над всем приложением:

<Provider>
  <Router>
    <App />
  </Router>
</Provider>

Смотрите гайд по CSS и HTML здесь: htmlbook.ru/blog/obrezaem-dlinnuyu-stro
Тега не существует.
С помощью JavaScript/jQuery можно так же сделать полное раскрытие текста при клике, убрав ненужные правила CSS.

Тег cut - это кастомный тег. В HTML спецификации такого нет.

Возможно вас заинтересует вот эта либа https://dollarshaveclub.github.io/shave/ . Она как раз про обрезку текста и html.

Или ищите по сочетанию js truncate html

Есть ли еще какая нибудь технология для асинхронных запросов к бэкэнду кроме ajax? В качестве бэкэнда golang

На чем бекенд - разницы особо нет (обычно).

Есть ВебСокеты, вполне себе асинхронно (при должном подходе), глобальная разница между ним и AJAX'ом в том, что соединение поддерживается на постоянной основе.

Ещё есть socket.io, тоже что-то наподобии сокетов, но не подскажу точно, как именно оно работает, очень давно использовал и подзабыл...

Это невалидный json. Соответственно это вообще не json. Или превратите это в json или пишите парсер этого чуда.

В Го есть такая системная переменная как $GOMAXPROCS, по-умолчанию она равна количеству процессорных ядер. Её значение определяет, сколько процессов будет запущено планировщиком го. Горутины распределяются между этими процессами. Если одна горутина заняла все вычислительное время одного процесса (как в вашем случае бесконечный цикл for, ибо он не прерывается операциями ввода/вывода или другими случаями ожидания ресурсов), то если $GOMAXPROCS=1, другие горутины будут ждать освобождения единственного процесса.
Когда вы меняете цикл на таймер, в момент вызова time.Wait процесс освобождается и может выполнить другую горутину.

cd $GOPATH
go get -u github.com/golang/lint/golint

Можно strace rabbitmqctl report сделать и посмотреть, что оно делает внутри.
У меня оно меньше секунды выполняется.

Лень двигатель прогресса. Хороший пример - принцип DRY - Don't repeat yourself. Я весьма подозреваю что вы стараетесь соблюдать этот принцип когда делаете макеты или чем вы там занимаетесь. Так же я весьма уверен что вы хотя бы пытались чуть автоматизировать рутину своей повседневной работы. Так же у вас могли быть ситуации когда вы переиспользовали какие-то элементы. Мало ли.

Так вот... CSS это тупая таблица стилей. Селектор и стили, ничего сверх умного тут придумать нельзя. Лет 5-10 назад было довольно модно держать один мегажирный CSS файл на 10К+ строк и радоваться жизни внося все больше изменений и т.д. Соответственно даже если вы соблюдаете всякие правила модульной верстки и все такое, у вас возникает несколько проблем:

• организация стилей, то есть держать все в одном файле не удобно особенно когда проект длится годами
• Дублирование стилей и селекторов. По мере развития проекта появляются какие-то снипиты которые можно реюзать. Так же у вас может появиться масса однообразных селекторов отличающихся лишь немного. При модульных подходах вложенности редко имеет место быть но все же имеет. Но не будем забывать что большинство фигачит селекторы просто так. В итоге если мы переместили блок или переименовали класс какого-то блока нужно отредактировать еще массу селекторов.
• Привязка размеров и параметров к другим стилям, например у вас в стилях задана ширина блока, от нее зависят другие параметры, отступы для других блоков и т.д. Да, в css3 появился calc для этого но это было относительно недавно и только с недавних пор можно почти без опаски использовать эту штуку.
• Таблицы стилей, как и HTML ориентированы на удобный разбор этого добра машиной, но не человеком. Человек же существо ленивое и как-то вот лень лишний раз скобку поставить или точку с запятой. Просто лень.

Есть так же хорошее правило, или идея если хотите.... Если код можно сгенерить - его лучше сгенерить. То есть для решения всех выше перечисленных проблем придумали препроцессоры. Они как бы были и раньше всех этих scss/less/stylus но как-то не решали всех проблем и т.д. Что в итоге было предложено (перечисляю в том же порядке что и в списке выше).

• У CSS есть такая штука как @ import. Но не очень круто импортировать сотню стилей в продакшене. Стоит сделать так что бы все стили были склеены при сборке проекта. Эта идея в итоге развилась и если разработчик использует это дело правильно, можно зайти в любой файл со стилями и увидеть список всего от чего зависят эти стили. Какие стили подключаются и т.д. Причем один файл с зависимостями может быть подключен в нескольких файлах а препроцессор сам разберется как и куда все вставлять сгенерив максимально оптимизированный по структуре файл. А разработчик получил четкую структуру файлов и возможность быстро найти где что и от чего зависит.
• С селекторами проблему предложили решить наиболее логичным вариантом. Если у нас есть вложенные селекторы, то имеет смысл определять их внутри блока этого селектора. Это существенно упрощает поддержку стилей. Так же для управления снипитами и прочим добавили миксины - эдакие параметризованные или нет функции которые выплевывают шматок CSS. До появления штук вроде autoprefixer это был единственный способ писать поддерживаемые стили, использовать плюшки CSS3 и вообще новые плюшки и не сойти с ума от префиксов. Префиксы это только пример, там могут быть самые разные штуки позволяющие грамотно производить реюз стилей
• Проблему зависимостей значений стилей друг от друга решили... собственно самым очевидным способом - переменные. Это удобно, легко поддерживать и в умелых руках это мощный инструмент. Нужно поменять базовые цвета - не нужно лазить по 100500 блоков и править значения руками, можно поправить переменные и все будет хорошо.
• Насколько я помню SCSS/LESS не стремились решить эту проблему. Какие-то решения образовывались сами собой с течением времени. В плане минимализма и выразительности пожалуй сейчас самая крутая штука это stylus.

Что в итоге произошло. В один прекрасный момент какие-то там рубисты придумали SCSS (они вообще не любят все что не в стиле ruby в плане минимализма и выразительности). Затем чуваки подумали и сказали, SCSS это круто но почему-то они используют синтаксис знакомый именно Ruby разработчикам а не обычные для CSS конструкции. В итоге реализовали LESS, причем его уже реализовали на javascript, что с наличием node.js позволило это все добро еще на одной платформе собирать. А так как под эту платформу и так плодили препроцессоры оно удачно вписалось.

Далее уже шли какие-то модификации дальнейшие, вроде того же Stylus, где синтаксис упростили просто до нельзя.

Личное мнение. На сегодняшний день я не вижу смысла использовать чистый CSS хоть на малых хоть на больших проектах. Вот вообще никакого.

Вам нужен type assertion - приведение к типу.

if pqError, ok := err.(*pq.Error); ok {
...
}

Оно возвращает стандартную ошибку.
Надо привести к pg.Error

Как-то так:
https://github.com/lib/pq/blob/a6140c91df5fb930610...