Упс, это мой так сказать внутренний юмор(напоминалочка)
Пожалуй, спрячу от неокрепших умов )) Спс
Кто ищет, тот всегда найдет.

Не "Биксоджей", а "Биксодж".

Поскольку учил я французский, то за консультацией обращался к переводчику Гугла,
он в конце говорит «джей», ну а с корпорацией добра спорить…
В гугл би-экс-оу-джи )) Джей в английском это J.
Когда нажимаю кнопку Прослушать, мне слышится в конце джей, а вам?

Странно, но мне нравятся все вариации чтения названия, уже предложенные )
Осталось спросить, а что думают по этому поводу носители языка

Это потому что там джи с долгим и [i:]. Да, русскоязычными он воспринимает как «ий»/«ей», как пример, нидерландское koffie с долгим [i:] превратился в «кофей» (еще есть форма «кофий»). У вас видимо так же получилось)))
deniskreshikhin, а на ваш взгляд, предложенный rumkin вариант Биксодж может быть правильным?
Я думаю, даже англичане на это не ответят, т.к. «x» не может в английском следовать за согласным.
Если читать по буквам, то «би-экс-оу-джи». Если читать как слово, то будет что-то вроде «бксог» или «бзог».
Спасибо, короткое название просто поудобней, буду пользоваться им.
Вспомнился анекдот :)
Русский, французский и китайский лингвисты решили написать имена друг друга, каждый на своём языке.

— Моя фамилия Ге, — сказал француз китайцу.
— В китайском языке два иероглифа Ге, но, к сожалению, ни один из них не подходит для фамилии.
— Почему?
— Потому что один имеет значение «колесо», а другой передает звук, с которым лопается мочевой пузырь осла.
— А что плохого в колесе?
— Мужское имя не может быть круглым. Для твоего имени мы возьмем иероглиф Шэ, означающий «клавиатура», «корнеплод», «страница», а также прилагательное «бесснежный» и дополним его иероглифом Нгу, означающим мужской род. В конце я пишу иероглиф Мо — «девственный».
— Но это, мягко говоря, не совсем…
— Никто не будет считать тебя девственником, просто без иероглифа Мо иероглифы Ше-Нгу означают «сбривающий мамины усы».

— Хорошо, теперь я напишу твое имя.
— Моя фамилия Го.
— Отлично, я начну твою фамилию с буквы G.
— Что означает буква G?
— У нас, европейцев, сами по себе буквы ничего не значат, но чтобы проявить к тебе уважение, я поставлю перед G букву H — во французском она все равно не читается.
— Отлично! Дальше O?
— Нет, чтобы показать, что G — произносится как Г, а не как Х, надо после G поставить букву U, а также H — чтобы показать, что U не читается сама по себе, а только показывает, как правильно читать G, и буквы EY, показывающие, что слово не длинное и скоро закончится.
— Hguhey… дальше O?
— Нет, О во французском произносится как А или Ё, в зависимости от стоящих по соседству букв, ударения и времени года. Твое чистое О записывается как AUGHT, но слово не может кончаться на T, поэтому я добавлю нечитаемое окончание NGER. Вуаля!

Русский лингвист поставил бокал на стол, взял листочек и написал «Го» и «Ге».
— И всё?
— Да.

Француз с китайцем почесали в затылке.
— Хорошо, а какая у тебя фамилия?
— Щекочихин-Крестовоздвиженский.
— А давайте просто выпьем? — первым нашёлся китаец.

Русский кивнул и француз с облегчением поднял тост за шипящие дифтонги.
Бииксоуджи, если быть точным. У гугла какой-то свой, видимо, «английский».
Если не будет новых версий, поправлю в статье на Бииксоуджи.
Название мне стало напоминать не безызвестный фильм Джуманджи.
Не-е. deniskreshikhin правильно сказал. b — би, x — экс, о — оу, g — джи
Может быть этот «какой-то свой английский» делала команда из Гарварда или MIT'а (3-е и 6-е места)? ;)

When in Go, do as Gophers do.


Не следует тесты в другой репозиторий отправлять. Они мешать не будут. Достаточно, чтоб имя у них подходило под маску *_test.go. По этой теме можно ещё документацию пакета go/build почитать.


Кроме того не принято использовать CAPS_CASE для констант. Effective Go #mixed-caps.


Тип Node не используется нигде, кроме внутренностей. Можно его скрыть из видимости. Достаточно написать node. Аналогично с Section, Index и внутренними константами. Кстати golint вам об этом укажет.


Ещё по можно почитать CodeReviewComments.


Мааленький момент. Не документируйте файлы. Документируйте сущности. Неплохо было бы добавить либеральную лицензию и заодно убрать из файликов упоминание о себе любимом. Ну или по возможности сократить в одну строчку и написать её перед package main. Не забудьте пустую строку после такого комментария, иначе оно уже как документация будет.


По мимо прочего неплохо иметь ссылку на документацию прямо сверху README. Вот она: https://godoc.org/github.com/claygod/Bxog

Не следует тесты в другой репозиторий отправлять. Они мешать не будут. Достаточно, чтоб имя у них подходило под маску *_test.go. По этой теме можно ещё документацию пакета go/build почитать.

Знаю, это я из своих соображений.

Кроме того не принято использовать CAPS_CASE для констант. Effective Go #mixed-caps.

Как-то не обращал внимания. В принципе, поправить можно, хотя привычно большими буквами.

Тип Node не используется нигде, кроме внутренностей. Можно его скрыть из видимости. Достаточно написать node. Аналогично с Section, Index и внутренними константами. Кстати golint вам об этом укажет.

Кстати да, собирался убрать из области видимости, но хотел оставить в названиях большие буквы.
Впишется ли в норму вариант вместо Node -> bNode?

Мааленький момент. Не документируйте файлы. Документируйте сущности. Неплохо было бы добавить либеральную лицензию и заодно убрать из файликов упоминание о себе любимом. Ну или по возможности сократить в одну строчку и написать её перед package main. Не забудьте пустую строку после такого комментария, иначе оно уже как документация будет.

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

По мимо прочего неплохо иметь ссылку на документацию прямо сверху README. Вот она: https://godoc.org/github.com/claygod/Bxog

Добавил.

lain8dono, спасибо за комментарий, побольше бы таких!
Впишется ли в норму вариант вместо Node -> bNode?

Не особо, но лучше. Это будет выглядеть странновато для читающих код, хотя чуть лучше для читающих только документацию. Кстати node не на столько уж большая структура для того, чтоб выделять её в отдельный файл. Лично я оставил бы её в файле index.go.


Кстати нижнего подчёркивание в именах вообще следует избегать.


Линтёр ругается вот так:

`


$ golint -min_confidence 0
config.go:3:1: should have a package comment, unless it's in another file for this package
config.go:8:6: don't use underscores in Go names; type type_hash should be typeHash
config.go:12:2: don't use ALL_CAPS in Go names; use CamelCase
config.go:13:2: don't use ALL_CAPS in Go names; use CamelCase
config.go:20:2: don't use ALL_CAPS in Go names; use CamelCase
config.go:24:2: don't use ALL_CAPS in Go names; use CamelCase
config.go:27:2: don't use ALL_CAPS in Go names; use CamelCase
config.go:30:2: don't use ALL_CAPS in Go names; use CamelCase
config.go:33:2: don't use ALL_CAPS in Go names; use CamelCase
config.go:36:2: don't use ALL_CAPS in Go names; use CamelCase
config.go:39:2: don't use ALL_CAPS in Go names; use CamelCase
config.go:44:2: don't use ALL_CAPS in Go names; use CamelCase
config.go:45:2: don't use ALL_CAPS in Go names; use CamelCase
config.go:46:2: don't use ALL_CAPS in Go names; use CamelCase
config.go:47:2: don't use ALL_CAPS in Go names; use CamelCase
index.go:1:1: should have a package comment, unless it's in another file for this package
index.go:12:6: exported type Index should have comment or be unexported
index.go:26:2: don't use underscores in Go names; var c_hashes should be cHashes
index.go:28:6: don't use underscores in Go names; var c_node should be cNode
index.go:45:10: if block ends with a return statement, so drop this else and outdent its block
index.go:73:3: don't use underscores in Go names; var c_node should be cNode
index.go:80:3: don't use underscores in Go names; var c_hash should be cHash
index.go:102:5: don't use underscores in Go names; var new_node should be newNode
index.go:123:57: don't use underscores in Go names; method parameter c_hashes should be cHashes
node.go:3:1: should have a package comment, unless it's in another file for this package
node.go:7:1: comment on exported type Node should be of the form "Node ..." (with optional leading article)
node.go:14:2: don't use underscores in Go names; var new_node should be newNode
route.go:1:1: should have a package comment, unless it's in another file for this package
route.go:13:6: exported type Route should have comment or be unexported
route.go:40:9: if block ends with a return statement, so drop this else and outdent its block
route.go:46:1: exported method Route.Method should have comment or be unexported
route.go:51:1: exported method Route.Id should have comment or be unexported
route.go:51:17: method Id should be ID
route.go:56:17: method parseUrl should be parseURL
route.go:57:6: don't use underscores in Go names; var array_sec should be arraySec
router.go:3:1: should have a package comment, unless it's in another file for this package
router.go:14:1: comment on exported type Router should be of the form "Router ..." (with optional leading article)
router.go:21:1: comment on exported function New should be of the form "New ..."
router.go:26:1: comment on exported method Router.Add should be of the form "Add ..."
router.go:31:9: if block ends with a return statement, so drop this else and outdent its block
router.go:36:1: comment on exported method Router.Start should be of the form "Start ..."
router.go:52:1: comment on exported method Router.Params should be of the form "Params ..."
router.go:55:5: don't use underscores in Go names; var c_route should be cRoute
router.go:66:1: comment on exported method Router.Create should be of the form "Create ..."
router.go:81:1: comment on exported method Router.Test should be of the form "Test ..."
section.go:3:1: should have a package comment, unless it's in another file for this package
section.go:7:1: comment on exported type Section should be of the form "Section ..." (with optional leading article)
section.go:10:2: don't use underscores in Go names; struct field type_sec should be typeSec
section.go:13:29: don't use underscores in Go names; func parameter type_s should be typeS
server.go:3:1: should have a package comment, unless it's in another file for this package
server.go:16:9: if block ends with a return statement, so drop this else and outdent its block (move short variable declaration to its own line if necessary)

`


Кстати go vet тоже ругается. Недостижимый код в файлах route.go:42 и router.go:30.


Знаю, это я из своих соображений.

Если вы о том, что там другое имя пакета, то это не аргумент. Попробуйте. Всё заработает. http://stackoverflow.com/a/31443271 Плюсом будет возможность сделать так:


$ go get github.com/claygod/Bxog
$ cd $GOPATH/src/github.com/claygod/Bxog
$ go test
....

Кстати, а у вас есть бенчмарк на костыль с хешированием? На сколько это лучше/хуже чем map[string]T?

Кстати, а у вас есть бенчмарк на костыль с хешированием? На сколько это лучше/хуже чем map[string]T?

Прямого нет, делал две версии поиска и сравнивал по общему бенчмарку. Но однозначно могу сказать, что сгенерировать хэш дешевле. Если бы вернуть старый алгоритм со строками, то думаю, сотня ns/op тут же набежала бы. И ещё я заметил, что с строками результат какой-то менее стабильный (больший разброс), хотя возможно это сугубо субъективно.
Но однозначно могу сказать, что сгенерировать хэш дешевле.

Однозначно об этом может сказать ТОЛЬКО правильно написанный бенчмарк. Более того. Вы заменяете стандартную функциональность языка собственным костылём. Следовательно далеко не лишним будет описание вашего алгоритма хеширования и объяснения, почему так лучше/быстрее/сильнее/выше и т.д. Желательно ещё и минусы (которые в любом случае есть) такого подхода обозначить.


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


Если очень хочется посоревноваться, то можно начать с https://github.com/gin-gonic/go-http-routing-benchmark


Кстати. Ваши тесты не заработают практически везде, кроме винды
$ go test -v            
# github.com/claygod/BxogTest
bxog_test.go:22:2: cannot find package "github.com/claygod/bxog" in any of:
    /usr/lib/go/src/github.com/claygod/bxog (from $GOROOT)
    /home/lain/gocode/src/github.com/claygod/bxog (from $GOPATH)
FAIL    github.com/claygod/BxogTest [setup failed]
Ваши тесты не заработают практически везде, кроме винды

Не соображу сразу… из-за того, что bxog в импортах написан с маленькой буквы? Плз, подскажите.

Если очень хочется посоревноваться, то...

Нет, я сделал бенч только для того, чтобы показать, что роутер не тормозной.

Следовательно далеко не лишним будет описание вашего алгоритма хеширования и объяснения, почему так лучше/быстрее/сильнее/выше и т.д. Желательно ещё и минусы (которые в любом случае есть) такого подхода обозначить.

Согласен, ключевой момент стоит осветить.
Тип Node не используется нигде, кроме внутренностей. Можно его скрыть из видимости. Достаточно написать node. Аналогично с Section, Index и внутренними константами. Кстати golint вам об этом укажет.


Поправил, в https://godoc.org/github.com/claygod/Bxog теперь только публичные функции роутера для API
На Гитхабе в
Settings
Necessary changes in the configuration of the multiplexer can be made in the configuration file config.go
ссылка с config.go ведёт в никуда.
Спасибо, пофиксил
В связи с тем, что в Golang теперь request содержит нативный контекст, роутер переделан на передачу параметров через него, что с одной стороны, немного замедлило роутер, с другой, позволило из аргументов хэндлера исключить третий параметр. Кроме того, получение параметров через встроенный контекст достаточно наглядно, к примеру вот так: req.Context().Value(«name»)).(string)
Ради большего перфоманса вернул старый вариант и сделал ещё пару изменений (см. в конце статьи).
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.