#web #buffalo Вышла версия 0.8.0 веб-фреймворка Buffalo. Из основного: шаблонный движок Plush теперь будет по-умолчанию, упаковщик статики go.rice заменен на gobuffalo/packr https://blog.gobuffalo.io/buffalo-v0-8-0-released-33f1786eadf

#web #buffalo Вышла версия 0.8.0 веб-фреймворка Buffalo. Из основного: шаблонный движок Plush теперь будет по-умолчанию, упаковщик статики go.rice заменен на gobuffalo/packr https://blog.gobuffalo.io/buffalo-v0-8-0-released-33f1786eadf

о, кстати, кто-нибуть пробовал буффало?

смотришь на доки, все вроде супер

нормальная штука

только как будто они из него джангу очередную лепят :)

от шаблонов в стиле Go вон отходят...

смешной вопрос. А можно ли вообще в go иметь короткие функции(в смысле количества строк). Походив по гитхабу да и по стандартной библиотеке, я понял что 50-100 строчные функции это норма. Или есть какие примеры проектов где все функции коротенькие-коротенькие?

один вопрос — зачем?

человек просто не видел длинные функции

это понятно, но зачем?

смешной вопрос. А можно ли вообще в go иметь короткие функции(в смысле количества строк). Походив по гитхабу да и по стандартной библиотеке, я понял что 50-100 строчные функции это норма. Или есть какие примеры проектов где все функции коротенькие-коротенькие?

Приходи в продакшен на Java - вот там длинные.

Чтобы легко помещались в экран и за один взгляд было полностью понятно, что она делает.

смешной вопрос. А можно ли вообще в go иметь короткие функции(в смысле количества строк). Походив по гитхабу да и по стандартной библиотеке, я понял что 50-100 строчные функции это норма. Или есть какие примеры проектов где все функции коротенькие-коротенькие?

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

у меня 53 строки вмещается на экран

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

т.к. мало синтаксического сахара

Чтобы легко помещались в экран и за один взгляд было полностью понятно, что она делает.

может, стоит задуматься и попробовать программировать не на нокле 1100?

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

Вот я именно про то же. Думал может есть какие примеры как компактные функции писать

Вот я именно про то же. Думал может есть какие примеры как компактные функции писать

Можно проверку ошибок в одну строчку писать

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

Тоже верно. Но функции в 200 строк это уже жесточайшая лапша

А пайплайны писать не делая функцию длинной как то не получается

Тоже верно. Но функции в 200 строк это уже жесточайшая лапша

а?

Вот он научит тебя писать компактно ?

Grender, a #golang package for rendering JSON/XML data and HTML templates : https://github.com/dannyvankooten/grender

наследование шаблонов мне нравится

Разница в этих двух реализациях? Может быть, во втором случае во время ожидания, управление может передаться другой горутине или я ошибаюсь? 1) for { ... time.Sleep(5 * time.Second) } 2) for { ... <-time.After(5 * time.Second) }

в обоих случаях может

Т.е. если не использовать функционал каналов - то они тождественны?

подскажите. а если у меня есть схема json, что то вроде { "anyOf": [ { "type": "object", "properties": { "timestamp": { "type": "string" }, "external_id": { "type": "string" ... 1. могу я её как то валидировать? 2. могу получать go-ные структуры из схемы (как из примера пакета я видел утилиты но не из схемы)

Недавно смотрел реализацию fifo, очень смутили вот эти 2 строчки: q.tail.next = n q.tail = n Разве вторая строчка не присвоит адрес переменной n? Какой тогда смысл в 1 строке?

Как это работает?

Т.е. если не использовать функционал каналов - то они тождественны?

второй зря использует пару мутексов, что внутри канала

подскажите. а если у меня есть схема json, что то вроде { "anyOf": [ { "type": "object", "properties": { "timestamp": { "type": "string" }, "external_id": { "type": "string" ... 1. могу я её как то валидировать? 2. могу получать go-ные структуры из схемы (как из примера пакета я видел утилиты но не из схемы)

1. google => golang json schema 2. google => golang json schema to struct

подскажите. а если у меня есть схема json, что то вроде { "anyOf": [ { "type": "object", "properties": { "timestamp": { "type": "string" }, "external_id": { "type": "string" ... 1. могу я её как то валидировать? 2. могу получать go-ные структуры из схемы (как из примера пакета я видел утилиты но не из схемы)

Стурктуры - нет

map[string]string тоже

вообще желательно полную json с пометками - где могут появится другие поля а где нет

А что за пометки?

ну примечания от тебя

что фиксированно, а что нет

Если полностью меняется - то можно через rawmessage поэлементно распарсивать

геморройно но возможно

Хотя погоди. У тебя схема по структуре а сам файл описываетс схемой

для валидации по схеме есть пэкедж https://github.com/xeipuuv/gojsonschema

Структуры из схемы не получится. Максимум - изврат в виде interface{}

не совсем так

я бы пробегал по файлу (валидному!), брал rawmessage, затем в зависимости от типа обрабатывал и складывал в разные структуры или мапы

не совсем так

Делись инфой=) Самому тоже надо.

вариантов валидных, без interface{}, два

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

2. создаем ту же самую структуру, но к ней приклеиваем кастомный анмаршалер, сеттеры-геттеры и поле "мой реальный тип"

я всегда хожу путем 1

потому, что 2 - это ява какая-то

а если один из типов - "перечень объектов"?

такой себе вариант

Вот такое как разрулить?

https://pastebin.com/8KJxpXAX

на кавычки не обращайте внимания, на коленке придумал

Да что далеко ходить, вот: { list: [1,3,4,"bingo",true] }

вот это разрулить нельзя никак

разве в go нет библиотек для работы с json по типу как это сделано в C?

а?!

как это сделано в с?

*void?

для каждой ноды или значения тип JsonNode

да пожалуйста

JsonNode->isArray() jsonNode->childs()

анмаршальте в map[string]interface{}, и будет вам счастье

только оно не счастье, а говноедство

JsonNode->isArray() jsonNode->childs()

динамическая типизация как она есть. ненавижу :)

if(JsonNode->type() == "int") { return JsonNode->int() }

так будет не очень эффективно, зато можно любой json обрабатывать и без Interface{}

if(JsonNode->type() == "int") { return JsonNode->int() }

куда это return можно сделать-то?

как функцию для такого return оформить?

это псевдокод

там может быть val := JsonNode->int()

ну вот и как его в реальный-то превратить в языке со строгой типизацией?

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

Думаю, что такая идея имеет право на существование

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

чтобы что? цель какова?

обрабатывать json не зная его точной структуры

Можно ещё попробовать это: https://github.com/Jeffail/gabs

а зачем его обрабатывать, не зная его структуры?

А почему все сразу отсекают interface{} из вариантов? Тайп-кастами как раз можно разобрать любую структуру, тем более, что соответствие типов Json и go однозначно определено: https://blog.golang.org/json-and-go

можно то можно, просто неудобно

Готовенькое хотят все

подскажите. а если у меня есть схема json, что то вроде { "anyOf": [ { "type": "object", "properties": { "timestamp": { "type": "string" }, "external_id": { "type": "string" ... 1. могу я её как то валидировать? 2. могу получать go-ные структуры из схемы (как из примера пакета я видел утилиты но не из схемы)

и вообще вопрос был по моему вообще не о динамических json'ах

А почему все сразу отсекают interface{} из вариантов? Тайп-кастами как раз можно разобрать любую структуру, тем более, что соответствие типов Json и go однозначно определено: https://blog.golang.org/json-and-go

потому, что писать свою динамическую типизацию поверх статической - это путь в ад

потому, что писать свою динамическую типизацию поверх статической - это путь в ад

А если купить индульгенцию?

у кого?

я вот не продаю

наоборот, сразу кричу - "несите дрова!"