Александр
Это я так мало ли кому интересно
Александр
Идентичных записей*
Pawel
скорость чтения в sqlite - это такая штука, которая зависит от дохера чего, нет смысла говорить о ней как о коне в вакууме
Diasko
Diasko:
Народ подскажите на счёт либо для клиента WSDL/SOAP, на гидхабе нашел надо тестить, может кто работает с ними
Roman
есть ли кодогенератор для монги?
Roman
Сегодня днем мне посоветовали storm заместо sqlite, вообщем результат такой на 5200 идентичных данных размер базы в 8 раз больше у storm однако скорость чтения на треть выше
это еще с учетом, что storm весьма криво написан
Alexander
Diasko:
Народ подскажите на счёт либо для клиента WSDL/SOAP, на гидхабе нашел надо тестить, может кто работает с ними
ничего не понятно. если нужна тулза, чтобы дернуть SOAP-сервис - скачайте SOAP UI. если нужен кодогенератор , чтобы сделать клиента по готовой всдл - ну погуглите. вот, сходу https://github.com/hooklift/gowsdl
Dmitry
стремление к единообразию наверно
Max
единоужасию
Dmitry
а можно увидеть примеры пакетов где ты не можешь выбрать название ?
Vladimir
AbstractUserInfromationInterfaceFactoryFactory?
Vladimir
так каждый раз ты решаешь
Dmitry
uinfofty
Dmitry
следующий
Cat
а почему бы не snake_case?
Dmitry
ну tempconv мне тоже кажется неудачным
Cat
> Ни camelCase, ни snake_case не рекомендуются
да это-то понятно, я просто предлагаю
> суффиксы определенные в именах, вроде _linux, _arm64
(да, я знаю, что это так, но..) звучит сомнительно, как будто не смогли другого способа резолвить платформы
Cat
> а вот с camelCase что мешает - неясно.
очевидно же! — слишком похоже на с++
A
Ну, по-моему тут без разницы, camelCase или snake_case. Лишь бы можно было хотя бы два слова полных поставить рядом. А ни то ни другое - нельзя. И куда податься? :(
A
И если у запрета snake_case есть ещё какая-то техническая причина, то с запретом camelCase всё выглядит так, будто там причина - религиозная.
Dmitry
If you cannot avoid a bad name, it is very likely that there is a problem with your overall structure and code organization.
Cat
Cat
я знал, что ты спросишь!
Nurzhan
Временно сворачивает?
Sergei
а package types не напрягает, не? :)
Cat
но допустим пакет будет называться temporal_convolution и будет вычислять эту темпоральную конволюцию
Dmitry
Cat
ммм, как классно читается
Cat
но допустим пакет будет называться temporal_convolution и будет вычислять эту темпоральную конволюцию
я к тому, что tempconv осмысленности не прибавит
Dmitry
придумывая абстрактные имена вы получаете абстрактные короткие имена
Dmitry
давайте рассматривать реальные примеры
Cat
A
давайте рассматривать реальные примеры
Ну, mockEditor тот же, выше писал. "Правильное" имя тут явно проигрывает в информативности.
Dmitry
Ну, mockEditor тот же, выше писал. "Правильное" имя тут явно проигрывает в информативности.
а что за mockeditor ? мне вот непонятно - это действительно редактор ? а что он делает в пакетах ?
A
//Ну, если быть точным, mockgen - пакет, mocked - редактор, приложуха отдельная.
Dmitry
ну он имеет отношение к мокам или это рандомное название ?
A
Всё имеет. Ну, там mockgen/mocked нормальные названия, просто к тому, что два слова читаются и воспринимаются легче одного с сокращениями. Особенно когда кто-то со стороны заглядывает.
A
Кстати, по поводу именования директорий: её имя же всегда совпадает в итоге с именем пакета. Делать другие - сопоставления нужно тогда держать в голове. Делать те же - неудобно просматривать структуры проектов, больно уж лаконично могут называться некоторые.
Dmitry
окей я понял. но описание того что делает пакет полностью в имени - это не есть гуд. для этого есть документация
A
Насколько хорошо массовое разъезжание между именами пакетов и именами директорий иметь? :)
Dmitry
тебе нужно имя которое ассоциировалось бы с тем что делает пакет а не полностью описывает его
Dmitry
думаю это очеь плохо
A
Просто если в коде ещё норммально mockgen использовать, то тому, кто просматривает структуры репозиториев явно удобнее понять, что к чему, по именам директорий.
Но начать делать разные - плохо, согласен. Потому что слой сопоставления имен директорий с именами пакетов нужно в голове держать разработчикам.
Dmitry
людям придется держать в памяти и названия директорий и названия пакетов
A
Всё так. Но вот куда податься-то теперь?
БТВ, довольно часто встречаются большие проекты, которые забивают на всё и используют несколько слов в именах директорий. После этого как-то и самому не стыдно станвоится. ;)
Cat
окей я понял. но описание того что делает пакет полностью в имени - это не есть гуд. для этого есть документация
Верно! поэтому нужно назвать не mocked, а mockvim! (чтобы не путать с linux's `ed`)
Dmitry
ed не настолько популярен чтобы путать с ним
Dmitry
и что то мне подсказывает что слово editor в пакете не есть правильно. это больше название для готового приложения а не для пакета
A
Всё так, я же писал выше, ed - собирается в приложуху, а переиспользуемый пакет, он с gen.
A
Но если использовать именование директорий в стиле пакетов, там та же проблема. Если нет - проблемы нет, но уже и соблазн на какие-то пакеты "неправильные" имена директорий распространить. Так и происходит в итоге. :)
Dmitry
ну для готового приложения мне кажежтся можно использовать и MockEditor
Dmitry
ага, теперь я понял
Dmitry
да есть неясность в этом плане.
Dmitry
но вот смотри https://github.com/golang-standards/project-layout/tree/master/cmd здесь запросто используют подчеркивания
Nazar
routes.PathPrefix("/dist").Handler(http.FileServer(http.Dir(CONF.WorkDir + "status/")))
ребзя
Nazar
есть такой движ
Nazar
как сделать что бы файл с status/dist/build.js был доступен по assets228/build.js
Dmitry
Dmitry
как видишь все юзают _ в названии директорий исполняемых файлов. так что mock_edtor это хорошее название
A
но вот смотри https://github.com/golang-standards/project-layout/tree/master/cmd здесь запросто используют подчеркивания
У influx ещё есть два варианта наименований директорий, в отличие от других из примеров. Если честно, не совсем понимаю, по какому принципу они выбирают подчеркивание использовать или дефис (influx-tools, influx_inspect).
Dmitry
У influx ещё есть два варианта наименований директорий, в отличие от других из примеров. Если честно, не совсем понимаю, по какому принципу они выбирают подчеркивание использовать или дефис (influx-tools, influx_inspect).
я тоже, но вобще то рекомендуется следовать соглашениям по именованиям утилит в линуксе. а в это я не силен
Dmitry
наверняка стоит избегать - в названии - потому что может быть принято за флаг
A
Не, за флаг не будет принято. :)
Dmitry
почему нет? при быстром взгляде трудно заметить есть там пробел перед дефисом или нет .
сравни (influx-tools) и (influx -tools) при взгляде со стороны пользователя
Cat
пользователь не знает про флаги
A
Просто есть пакеты, где люди используют и camelCase, видел, где делали подчеркиванием, где-то дефисом, но везде что-то одно. А Influx отличается просто тем, что тут несколько вариантов сразу.
Будто это не вопрос предпочтения, а глубинный смысл есть, который я не уловил пока.
Anonymous
коллегия,
1) что думаете про фреймворки? https://blog.usejournal.com/top-6-web-frameworks-for-go-as-of-2017-23270e059c4b
2) юзаете ли какие-либо не-веб фреймворки?
Cat
он не будет воспринимать, есть там пробел, или нет
ему пофигу
пользователь сам не будет писать никакие флаги
Dmitry
Просто есть пакеты, где люди используют и camelCase, видел, где делали подчеркиванием, где-то дефисом, но везде что-то одно. А Influx отличается просто тем, что тут несколько вариантов сразу.
Будто это не вопрос предпочтения, а глубинный смысл есть, который я не уловил пока.
это не пакеты, не путай. это имена приложений.
Dmitry
пакет там main
Dmitry
пользователь сам не будет писать никакие флаги
да ладно ? а если я пишу флаги я уже не пользователь ?
A
Понимаю, но всё равно должны же быть соглашения какие-то, с учетом, что это в той же иерархии вместе с пакетами лежит.
Cat
да ладно ? а если я пишу флаги я уже не пользователь ?
у пользователей, которые сами пишут флаги, уже набит глаз на пробелы