https://github.com/SolidlSnake/easyvk-go/blob/master/easyvk/vk.go#L179-L183

Это ты так проверяешь наличие поля "error" в JSON ответе?

Это ты так проверяешь наличие поля "error" в JSON ответе?

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

https://godoc.org/encoding/json#RawMessage

Только в Response держать не указатель на json.RawMessage, а само значение типа json.RawMessage.

Ну и код ответа проверять нужно.

Читаю пример по ссылке и слабо понимаю пока, как это работает %)

json сохранится as is, и ты можешь дальше анмаршалить, в зависимости от наличия Error

Частичная десериализация.

О, круто, беру на заметку. Не знал.

json сохранится as is, и ты можешь дальше анмаршалить, в зависимости от наличия Error

не, суть я понял, не совсем понял как оно работает в коде. Тобишь на месте RawMessage сохраняется не обработанный json и его потом можно использовать как и массив byte?

не, суть я понял, не совсем понял как оно работает в коде. Тобишь на месте RawMessage сохраняется не обработанный json и его потом можно использовать как и массив byte?

именно так

именно так

но как это срабоатет, если json вообще может разный быть? то { "error": {...}}, то {"response":{}}

в примере, который показал Владимир, он Error объявил ссылкой на структуру, т.е. если ее не будет в ответе, там будет nil, а response останется as is, и его далее можно будет разбирать

если response отсутствует, там будет пустой слайс

Указатель.

Ух, ладно, буду вкуривать) Спасибо

Caddy 0.10 Released (Score: 101+) Link: http://j.mp/2oRDInP

А объясните еще раз, почему error и rawmessage именно ссылкой обозначены?

А объясните еще раз, почему error и rawmessage именно ссылкой обозначены?

RawMessage незачем.

RawMessage незачем.

Но у вас там именно так)

Да, но так делать смысла нет.

А то я с ссылками и указателями слаб, знаю, что надо использовать когда передаем в функцию что-то, что должно быть изменено глобально и все

Поэтому подобные места вопросы вызывают

Указатель нужен, чтобы получить nil в случае отсутствия поля error.

RawMessage незачем.

вообще-то есть зачем. ссылка 8 байт весит, а все сообщение может много, и каждый раз копирвать много в локальные переменные функции такая себе идея

вообще-то есть зачем. ссылка 8 байт весит, а все сообщение может много, и каждый раз копирвать много в локальные переменные функции такая себе идея

Пожалуй.

Указатель нужен, чтобы получить nil в случае отсутствия поля error.

https://play.golang.org/p/gdcyXpEY15

С указателем: {0x1050a180 <nil>} Без указателя: {0x1050a180 {0 []}}

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

Кто пишет на Go на продакшене или имеет какие-то серьезные проекты. Как у вас организована сборка проекта с нуля? Пользуетесь ли вы vendor директорией? Используете ли вы в своем проекте всегда последнюю версию библиотеки или зафиксированы на определенной версии? Обновляете ли вы со временем эту версию?

вендорим, зафиксирована версия, не обновляем версию

Есть ли способы просто как в nodejs/python подтянуть по списку все нужные библиотеки с нужными версиями а потом собрать проект?

есть, бери любой вендор инструмент

но подтягивать при сборке - гиблое дело, лучше вендорить

В vendor git'овские сабмодули или все обычно код просто копируют не разделяя на отдельные репозитории?

вендор библиотеки копируют код в твой репозиторий

и ты хранишь его у себя

но подтягивать при сборке - гиблое дело, лучше вендорить

А для вендоринга чем лучше пользоваться? Glide? https://github.com/Masterminds/glide У меня просто возникали с ним проблемы при использовании редактора Atom с плагином для golang - go-plus, автоматом там тул, что запускал тесты не понимал, что либы лежат в vendor папке. В итоге так и не разобравшись пришлось пока то что хотел завендорить положить по дефолтному пути ~/go/src

ну это плагин у тебя кривой, а не глайд

пользуйся нормальными IDE, типа vim

vim.. IDE... смешно конечно)

Вим слишком радикально пока :)

Решил пока с vendor'ами не заморачиваться. Попробую сейчас всё организовать в качестве сабмодулей, что бы можно было просто рекурсивно клонировать весь проект и собирать. Мне кажется просто хранить у себя отдельную копию библиотеки вместо git-ссылки на специфичную версию/коммит не очень хорошо. Правда я пока не знаю умеет ли git делать сабмодуль с ссылкой на определенную версию/коммит.

хранить у себя версию - это очень хорошо

потому что люди любят удалять/переименовывать свои репозитории

и интернет имеет свойство ломаться

¯\_(ツ)_/¯

Поменяют аддрес библиотеки - поменяю аддреса в проекте. Конечно хранить именно копию надежнее, но мне как-то это не сильно нравится. Всеравно что я у себя бы node_modules в проектах на node.js сохранял.

Не уверен, что npm-подобное хранилище было бы лучшем решением, но мне кажется оно было бы более надежным. Всё-таки ник на github'е действительно может поменять какой-нибудь тип от которого зависит куча проектов. Но я новичок, в Go всего месяц и скорее всего тот ещё невежда

у нас тут подкаст начался http://golangshow.com/online/

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

все нормальные люди хранят код у себя

всегда есть вероятность атомной войны

все нормальные люди хранят код у себя

только в твоем мире. в остальном мире есть нормальные менеджеры зависимостей

это видимо свойство низкоуровневых языков - все таскать с собой. в высокоуровневых все подкачивают через менеджеры.

только в твоем мире. в остальном мире есть нормальные менеджеры зависимостей

+

это видимо свойство низкоуровневых языков - все таскать с собой. в высокоуровневых все подкачивают через менеджеры.

Это свойство серьезных компаний vs стартапчиков на коленочке. В стартапчике, если отваливается github, проект перестает собираться и все идут курить. В серьезной компании падение github-а никто не замечает.

Это свойство серьезных компаний vs стартапчиков на коленочке. В стартапчике, если отваливается github, проект перестает собираться и все идут курить. В серьезной компании падение github-а никто не замечает.

это утрирование и подмена понятий.

И проект не перестаёт собираться, тк копии исходников лежат на компутерах

Ребята, не знаю аглийского языка, поэтому имею трудности в поиске нужной информации. А вопрос такой: хочу написать приложение для Android на Go. Что максимально можно сделать на Go для Adroid, я имею ввиду можно ли написать интерфейс или все таки без Java не обойтись? Буду рад ссылкам на полезные источники.

Ребята, не знаю аглийского языка, поэтому имею трудности в поиске нужной информации. А вопрос такой: хочу написать приложение для Android на Go. Что максимально можно сделать на Go для Adroid, я имею ввиду можно ли написать интерфейс или все таки без Java не обойтись? Буду рад ссылкам на полезные источники.

Прогать и не знать английский не есть гут.

Ну вопрос в другом. Это я и сам понимаю)

Ребята, не знаю аглийского языка, поэтому имею трудности в поиске нужной информации. А вопрос такой: хочу написать приложение для Android на Go. Что максимально можно сделать на Go для Adroid, я имею ввиду можно ли написать интерфейс или все таки без Java не обойтись? Буду рад ссылкам на полезные источники.

у меня вопрос другого плана - на сколько это извращение писать на го под андроид? или "почему бы и нет?"

на самом деле интересно есть ли смысл ?

это утрирование и подмена понятий.

конечно, https://habrahabr.ru/post/280039/

Ребята, не знаю аглийского языка, поэтому имею трудности в поиске нужной информации. А вопрос такой: хочу написать приложение для Android на Go. Что максимально можно сделать на Go для Adroid, я имею ввиду можно ли написать интерфейс или все таки без Java не обойтись? Буду рад ссылкам на полезные источники.

https://m.habrahabr.ru/post/277705/ Попробуй отсюда

конечно, https://habrahabr.ru/post/280039/

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

И проект не перестаёт собираться, тк копии исходников лежат на компутерах

clean && build и нету их. А вообще не кажется слишком рискованным надеятся на закешированные копии? 😃

clean && build и нету их. А вообще не кажется слишком рискованным надеятся на закешированные копии? 😃

Ну как минимум первое время всё будет продолжать компилиться))

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

Когда такое затрагивает твой проект и бизнес, тебе не важно, какая вероятность у этого события. "Все свое ношу с собой" и душе спокойнее, и надежнее.

Когда такое затрагивает твой проект и бизнес, тебе не важно, какая вероятность у этого события. "Все свое ношу с собой" и душе спокойнее, и надежнее.

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

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

https://godoc.org/encoding/json#RawMessage

Спасибо за наводку) Помимо более элегантного способа проверки ошибки еще и избавился от вложенных структур, которые мазолили глаза)

увы, сильные мира сего - это 1% от количества, и 99% от ресурса на инфраструктуру, со всеми вытекающими

Т.е. если в одной из библиотек от которой зависит программа обнаруживается фатальный баг и её надо обновить, то просто заново все файлы копируешь теряя все преимущества git'a? Мне кажется такой способ породит больше багов чем падение github'a.

какие такие преимущества

каие преимущества git в аццких его субмодлулях век бы их не видать

Т.е. если в одной из библиотек от которой зависит программа обнаруживается фатальный баг и её надо обновить, то просто заново все файлы копируешь теряя все преимущества git'a? Мне кажется такой способ породит больше багов чем падение github'a.

go get -u ...?