Нужно смотреть исходники, но думаю в DI вся красота Martini и есть. Как тут написали — код становится компактнее, добавлять переменные в часть handlers проще, добавлять middlewares проще.
Но если без DI обходиться, но можно делать примерно так:
type CustomHandler struct {
Mongo *mgo.Session
Handler func(http.ResponseWriter, *http.Request, *mgo.Database, *sessions.Session)
}
func (ha *CustomHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
db := ha.Mongo.Clone().DB("")
ha.Handler(w, r, db)
}
и потом при регистрации handlers писать примерно так:
func MyHandler(w http.ResponseWriter, r *http.Request, db *mgo.Database) {
// implementation goes here...
}
Тоесть определяется CustomHandler struct и поскольку ее Handler реализует метод ServeHTTP он может быть использован как Handler стандартным http пакетом из библиотеки Go.
Вы можете перенаправлять запросы с nginx на Go приложение через proxy_pass. Разработчики Go рекомендуют все же не использовать Go-сервер без nginx/apache или другого подобного сервера, так как они лучше справляются с рядом задач. Например ssl handshake, gzip, spdy и прочее. Хотя все это конечно можно и в самом Go сервере сделать.
Кроме того положительный момент – пока nginx/apache запущен как root — само приложение может быть запущено от имени обычного пользователя.
Тоже так думаю. Даже пример проекта с оф. сайта martini в видео впечатляет. Думаю по размерам сообщества — martini сейчас самый популярный среди Go frameworks.
Радует и martini-contrib с дополнительными плюшками вроде oauth, распознавания языков, gzip и т.п. Хотя gzip и обработку ssl я бы оставил все-таки на nginx. В Go 1.3 планируются изменения в tls пакете — найдены уязвимости и они решили изменить там немного API.
Небольшой комментарий: если следовать правилам именования констант в Go (тому, который выложил Brad Fitzpatrick) — они не должны как в других языках быть все заглавными буквами. Хотя как по мне именно так их удобно воспринимать в коде. А вообще очень много полезного рассказали в этих статьях от написания API до тестирования.
Кстати есть CI написанный на Go и использующий Docker контейнеры: github.com/drone/drone
Вопрос к знатокам: Если не используется martini — как вы передаете в HandlerFunc параметры вроде открытого соединения mgo или сессии? Пока что я выхожу из ситуации используя closures. Как пример:
Хотя лично мне подход dependency injection нравится, многие разработчики Go негативно к нему относятся. Точнее даже не к нему, а к тому что в martini большую роль играет использование reflect. Если почитать статьи от Russ Cox и других, включая также официальные статьи по Go — там описывается, что reflect лучше использовать как можно реже.
Поэтому на мой вопрос в IRC на канале #go-nuts какой они предпочитают Go framework (а ведь есть же beego, martini, web.go, revel) рассказали, что предпочитают стандартный net/http или на крайний случай gorilla toolkit.
Другая проблема с которой можно столкнуться — версии пакетов. Хотя go get позволяет удобно выгружать сторонние packages, их версии не проверяются и для этого существует отдельное обсуждение и отдельные пакеты — например godep (запоминает commit sha, создает своего рода аналог virtualenv, но для Go приложений). Есть и множество других пакетных менеджеров, но в целом вопрос версий остается открытым.
P.S. Язык Go мне нравится, просто поделился мыслями после прочтения статьи. Автору спасибо!
Насколько понимаю это я – будет соревнование проектов – насколько хороший будет питч, насколько ребята продумали свои бизнес-модели, чего добились на текущий момент и т.д. Думаю будет очень даже интересно понаблюдать :-)
Если почитать про Go, там вообще специально сделано так, что структура проекта сама по себе позволяет обойтись без cmake и ему подобных и для сборки просто делаешь go build…
Спасибо за статью, буду ждать продолжения.
P.S. Вспомнил почему-то как собирал KDE 4.0 из какого-то экзотического overlay Gentoo :-)
Я не автор статьи, но попробую ответить на ваши вопросы (имею опыт работы системного/бизнес-аналитика):
— проблема, когда требования устаревают до окончания описания ТЗ — реальная проблема и в BABOK версии 3 над этим активно работают. В рассылке для волонтеров на его написание указывалось, что они хотят сосредоточиться на Agile подходе. Следует учесть, что полностью писать ТЗ заранее нужно далеко не везде и не всегда.
— потребителей документов может быть много – от руководства до программистов. Созданное ТЗ – это документ, имеющий ценность для бизнеса, ценность для разработчиков и т.д. Часто ожидается что с ТЗ будет работать некий менеджер проектов, который распределит работу между разработчиками. Из опыта работы разработчика – общаясь с заказчиком напрямую разработчики пишут код и много раз его переделывают, в то время как написанное качественно ТЗ значительно снижает кол-во переписываний кода (в чем согласно BABOK одна из основных задач бизнес-аналитика).
— для этого есть отдельный knowledge area в BABOK, как «Solution assessment and validation».
С удовольствием отвечу на вопросы, если у вас они есть :-)
Надеюсь после этого комментария ваше ЧСВ увеличилось.
Кроме того, мой знакомый пытался ввезти Google Glass в Украину и их не пропустили. Потому мне стало интересно – может таки их можно ввозить и это только ему так повезло. И вообще не думал что такой вопрос вызовет столько негативной реакции здесь.
P.S. Не понял при чем тут олени на аватарке и навозная джинса.
Я искал команду и опыт. Инвесторы нам не нужны сейчас, а если и будут нужны, мы 10 раз подумаем стоит ли с ними связываться. Абсолютно согласен, что надо получать деньги с клиентов, а не от инвесторов.
Спасибо! Я согласен с вашим мнением насчет стартап-инкубаторов. Никто кроме создателя не видит всего и даже если есть конкуренты (а они обычно всегда есть прямые или косвенные), надо делать проект и смотреть является ли свое решение и исполнение лучше конкурентного.
Мы идею доведем до запуска и некоторые советы были довольно полезными. Спасибо за комментарий :-) Незнаю за что -1 кармы сделал кто-то, но я хотел поделиться впечатлениями.
Из-за того, как поиск выглядел и работал до этого я его почти не использовал, но уже с возможностью переключаться по языкам и выбирать код, репозиторий или пользователя думаю буду пользоваться чаще.
Кто не видел — советую послушать доклад Владимира Агафонкина на KyivJS, если таковой имеется.
Вот ссылка на слайды доклада про Leaflet, а точнее почему на взгляд создателя библиотеки его проект стал таким популярным. Может кому-то будет интересно.
Сколько читаю подобных статей, столько убеждаюсь что все возможно и весь мир открыт для нас, если мы хотим действительно начать действовать и таки начнем действовать :)
Но я зарегистрирован в социальных сетях, чтобы держать связь с людьми, а не для того чтобы не давать какие-то свои данные. Более того, по-умолчанию я рассматриваю все что пишу как доступную всем информацию.
Хотя если получится перетянуть пользователей массово на эту сеть – почему бы и нет :)
Но если без DI обходиться, но можно делать примерно так:
и потом при регистрации handlers писать примерно так:
Ну и пример MyHandler:
Тоесть определяется CustomHandler struct и поскольку ее Handler реализует метод ServeHTTP он может быть использован как Handler стандартным http пакетом из библиотеки Go.
Кроме того положительный момент – пока nginx/apache запущен как root — само приложение может быть запущено от имени обычного пользователя.
Радует и martini-contrib с дополнительными плюшками вроде oauth, распознавания языков, gzip и т.п. Хотя gzip и обработку ssl я бы оставил все-таки на nginx. В Go 1.3 планируются изменения в tls пакете — найдены уязвимости и они решили изменить там немного API.
Небольшой комментарий: если следовать правилам именования констант в Go (тому, который выложил Brad Fitzpatrick) — они не должны как в других языках быть все заглавными буквами. Хотя как по мне именно так их удобно воспринимать в коде. А вообще очень много полезного рассказали в этих статьях от написания API до тестирования.
Вопрос к знатокам: Если не используется martini — как вы передаете в HandlerFunc параметры вроде открытого соединения mgo или сессии? Пока что я выхожу из ситуации используя closures. Как пример:
http.HandleFunc("/my/path/", func(w http.ResponseWriter, r *http.Request) { MyPathHandler(w, r, db, session })Поэтому на мой вопрос в IRC на канале #go-nuts какой они предпочитают Go framework (а ведь есть же beego, martini, web.go, revel) рассказали, что предпочитают стандартный net/http или на крайний случай gorilla toolkit.
Другая проблема с которой можно столкнуться — версии пакетов. Хотя go get позволяет удобно выгружать сторонние packages, их версии не проверяются и для этого существует отдельное обсуждение и отдельные пакеты — например godep (запоминает commit sha, создает своего рода аналог virtualenv, но для Go приложений). Есть и множество других пакетных менеджеров, но в целом вопрос версий остается открытым.
P.S. Язык Go мне нравится, просто поделился мыслями после прочтения статьи. Автору спасибо!
От себя и своей команды хочу написать, что вся команда HappyFarm просто супер! Спасибо за поддержку и помощь!
Будем стараться и двигаться вперед! :-)
Если почитать про Go, там вообще специально сделано так, что структура проекта сама по себе позволяет обойтись без cmake и ему подобных и для сборки просто делаешь go build…
Спасибо за статью, буду ждать продолжения.
P.S. Вспомнил почему-то как собирал KDE 4.0 из какого-то экзотического overlay Gentoo :-)
— проблема, когда требования устаревают до окончания описания ТЗ — реальная проблема и в BABOK версии 3 над этим активно работают. В рассылке для волонтеров на его написание указывалось, что они хотят сосредоточиться на Agile подходе. Следует учесть, что полностью писать ТЗ заранее нужно далеко не везде и не всегда.
— потребителей документов может быть много – от руководства до программистов. Созданное ТЗ – это документ, имеющий ценность для бизнеса, ценность для разработчиков и т.д. Часто ожидается что с ТЗ будет работать некий менеджер проектов, который распределит работу между разработчиками. Из опыта работы разработчика – общаясь с заказчиком напрямую разработчики пишут код и много раз его переделывают, в то время как написанное качественно ТЗ значительно снижает кол-во переписываний кода (в чем согласно BABOK одна из основных задач бизнес-аналитика).
— для этого есть отдельный knowledge area в BABOK, как «Solution assessment and validation».
С удовольствием отвечу на вопросы, если у вас они есть :-)
Кроме того, мой знакомый пытался ввезти Google Glass в Украину и их не пропустили. Потому мне стало интересно – может таки их можно ввозить и это только ему так повезло. И вообще не думал что такой вопрос вызовет столько негативной реакции здесь.
P.S. Не понял при чем тут олени на аватарке и навозная джинса.
Кто-то привозил Google Glass в Украину? :-)
Я искал команду и опыт. Инвесторы нам не нужны сейчас, а если и будут нужны, мы 10 раз подумаем стоит ли с ними связываться. Абсолютно согласен, что надо получать деньги с клиентов, а не от инвесторов.
Мы идею доведем до запуска и некоторые советы были довольно полезными. Спасибо за комментарий :-) Незнаю за что -1 кармы сделал кто-то, но я хотел поделиться впечатлениями.
Из-за того, как поиск выглядел и работал до этого я его почти не использовал, но уже с возможностью переключаться по языкам и выбирать код, репозиторий или пользователя думаю буду пользоваться чаще.
Вот ссылка на слайды доклада про Leaflet, а точнее почему на взгляд создателя библиотеки его проект стал таким популярным. Может кому-то будет интересно.
Спасибо за статью!
Но я зарегистрирован в социальных сетях, чтобы держать связь с людьми, а не для того чтобы не давать какие-то свои данные. Более того, по-умолчанию я рассматриваю все что пишу как доступную всем информацию.
Хотя если получится перетянуть пользователей массово на эту сеть – почему бы и нет :)