Аналогичные мысли давно обсуждаем в чате distributed. Эпоха ллм, конечно, прекрасна. Стало на порядок легче систематизировать или даже тестировать гипотезы.
Вдруг на что-то натолкнет, кстати. https://github.com/distributed-community/dmf
Не. У меня дока — часть разработки, потому там линтинг идет по простым вещам - линтинг маркдауна, например, обычным маркдаун линтом. Но просто потребности не возникало делать прям в большой документации.
Звучит довольно прокачано, хоть и несколько перегружено не для энтерпрайза. Себе придумал маркдаун шаблон c4+arch42 с mermaid схемами. Линтинг и прочее уже на уровне CI, кодогенерации, мэйкфайла, etc. Но тут как раз про близость к коду и версионируемость + использование для агентов и редактирование агентами в том числе.
Тоже с самого начала карьеры это начал замечать и недоумевал, почему настолько неадекватная повсеместная корпоративная культура, которую уще так яростно защищают и оправдывают. Только как будто зумеры на массовом уровне стали этому противостоять. https://habr.com/p/493038/
Я считаю, что основная проблема на рынке не в ллм, и даже не в хр. А в наклепанных шарагами под копирку специализдах с вайтбордингом головного мозга, отбирающих на открытые позиции мыслящих как они, а не умеющих работать работу.
Сколько надушнили из-за всякой фигни. Автор - красавчик! Не просто что-то придумал, а смог смотивироваться это реализовать. Да ещё и в железе! Не без зависти пишу.
Вспоминаю, как порой геморройно пирогами что-то связанное с кафкой после длительного перерыва. И все может казаться всратым и не удобным. И вот иметь подобные туториалы в обсидиан может быть полезным. Спасибо!
раньше использовал вайпер с коброй. Но там вот реально надо было вроде отдельный init файл делать, директории с подкомандами и прочим. Т.е. уже решения для прям сложных гуевых приложений, в которых есть команды приложения и их собственные параметры и т.д.
Я как раз люблю собирать параметры в какие-то структуры и потом ее использовать, не дергая какой-то объект за методы. Вот пример моего config.go текущего пет-проекта. Т.е. весь боилерплэйт умещается в одном файлике, который кладется рядом с main.go в папку cmd. А в main уже параметры читаются из структуры.
package main
import (
"fmt"
"os"
"strings"
"github.com/knadh/koanf"
"github.com/knadh/koanf/parsers/json"
"github.com/knadh/koanf/parsers/toml"
"github.com/knadh/koanf/parsers/yaml"
"github.com/knadh/koanf/providers/confmap"
"github.com/knadh/koanf/providers/env"
"github.com/knadh/koanf/providers/file"
"github.com/spf13/pflag"
)
// Config is application config struct
type Config struct {
Logger struct {
Level string `koanf:"level"`
} `koanf:"logger"`
Sentry struct {
DSN string `koanf:"dsn"`
TracesSampleRate float64 `koanf:"tracesSampleRate"`
} `koanf:"sentry"`
DB struct {
URL string `koanf:"url"`
}
GRPC struct {
Port int `koanf:"port"`
}
Services []ServiceConfig `koanf:"services"`
}
// ServiceConfig is a config for a service
type ServiceConfig struct {
Type string `koanf:"type"`
Parameters map[string]string `koanf:"parameters"`
}
const (
ServiceConfigTypeAsset = "asset"
ServiceConfigTypeUser = "user"
ServiceConfigTypePrice = "price"
ServiceConfigTypePortfolio = "portfolio"
ServiceConfigTypeTrade = "trade"
)
func getConfig() (*Config, error) {
var err error
k := koanf.New(".")
// Default values
defaults := map[string]interface{}{
"sentry.tracesSampleRate": 1.0,
}
err = k.Load(confmap.Provider(defaults, "."), nil)
if err != nil {
return nil, fmt.Errorf("can't load default config parameters: %w", err)
}
// Load command line and configs
f := pflag.NewFlagSet("config", pflag.ContinueOnError)
f.Usage = func() {
fmt.Println(f.FlagUsages())
os.Exit(0)
}
f.String("c", "", "Path to config file")
err = f.Parse(os.Args[1:])
if err != nil {
return nil, fmt.Errorf("can't parse command line arguments: %w", err)
}
// Load the config files provided in the commandline.
cFile, _ := f.GetString("c")
switch {
case strings.HasSuffix(cFile, "toml"):
if err := k.Load(file.Provider(cFile), toml.Parser()); err != nil {
return nil, fmt.Errorf("error loading file: %w", err)
}
case strings.HasSuffix(cFile, "yaml"):
if err := k.Load(file.Provider(cFile), yaml.Parser()); err != nil {
return nil, fmt.Errorf("error loading file: %w", err)
}
case strings.HasSuffix(cFile, "json"):
if err := k.Load(file.Provider(cFile), json.Parser()); err != nil {
return nil, fmt.Errorf("error loading file: %w", err)
}
}
// Load ENV
err = k.Load(env.Provider(ServiceName+"_", ".", func(s string) string {
return strings.ReplaceAll(strings.ToLower(
strings.TrimPrefix(s, ServiceName+"_")), "_", ".")
}), nil)
if err != nil {
return nil, fmt.Errorf("can't load env variables: %w", err)
}
// Unmarshal configs to struct
var config Config
err = k.Unmarshal("", &config)
if err != nil {
return nil, fmt.Errorf("can't unmarshal config: %w", err)
}
return &config, nil
}
Тут еще от нехер делать засунуты томл, json. ОБычно все запускаю в ENV так как с компоуза удобнее. Так что можно еще сократить, но накладные расходы на поддержку парсинга конфигов вряд ли фатальны.
Недавно открыл для себя mermaid как доступный способ кодом "рисовать" диаграммы. Поддерживаются различные виды, в том числе в бете поддреживаются С4 диаграммы. Автоматически рендерится в схемы на гитлабе, обсидиане. В вскод тоже работает, как минимум с установкой расширения (точно не помню). Т.е. можно без каких-либо отдельных инструментов вести ту же документацию сразу в гит-репозиториях в маркдауне и при этом не надо тащить картинками схемы - все изменения будут фиксироваться, как и изменения другого текста.
Добавлю только, что офисная работа и вообще работа на территории работодателя - это не какой-то артефакт из глубины веков. До эпохи индустриализации люди обычно работали примерно там же, где и жили. Да, сама по себе жизнь человека, вынужденного работать для выживания, не была лучше, но сам факт разделения места жизни и места работы начался с необходимости, а продолжился тупым масштабированием дурных практик, приведших к сверхцентрализации ресурсов и другим проблемам вроде маятниковой миграции.
Согласен с идеей про то, что обязанности и ответственность должны быть согласованы с ресурсом человека. А в компаниях с наймом любят нагружать людей, давая максимум чутка денег.
Но такие же можно и сказать про другие "руководящие" роли. Нередко продукт менеджеров нанимают, а потом ожидают выполнения от них скорее функций сержантов, которые пушат разрабов на овертаймы и завершение тасок любой ценой.
В конечном итоге все равно приходишь к мысли, что самое лучшее: когда свой проектик или какой-то движ, людей на найм не надо - либо под конкретные задачи самозанятые, либо уже партнёры нормальные. Не нужно городить огромные вертикальные структуры и вот это все. Но таким образом много ниш отрежешь.
Вообще, в Go можно уйти от возврата ошибок в сторону того же отправления всех ошибок в специальный канал.
Однако, предвижу тонны проблем с дебаггингом, так как в стектрейсах и сентри, скорее всего точка отстрела ошибки будет в той гороутине, которая тащит и как-то "обрабатывает" ошибки из канала. Т.е. могут возникнуть трудности с определением места возникновения ошибки.
Мы уже живём не в нулевых и даже не в десятых. Мир опенсорса давно переживает попытки сделать монетизируемой работу активистов. На данный момент для меня наиболее живой и активный проект - gitcoin на базе эфириума, где периодически даже я кидаю какие-то деньги на гранты проектам
А потом оказалось, что активные донатеры иногда получают эирдропы денежные от других взлетевших проектов. То есть чтобы помогать опенсорсу и распределенным индивидуалистическим решениям даже не обязательно быть идеальным и щедрым.
В опесорсе есть много проектов, которые сами по себе плохо монетизируемые из-за их важных качеств. Вряд-ли вы сможете тупо продавать ядро Линукс или такой же корджс. Но при этом деньги могут ходить через полноценные продукты, частью которого является такой софт.
Вообще, ожидать от масс субъектности и какой-то запредельной просвещенности as is - несколько инфантильно. Средний человек по максимуму не будет вникать в проблемы каких-то проф инструментов и их разработчиков. Для этого работают отдельные специалисты и целые некоммерческие орг.
Но даже многие os задроты не ходят понимать социальные и экономические механизмы общества, а к попыткам развития всяких криптоинститутов относятся примерно так же, как циничные деды из мира юриспруденции и банкинга - ниазлетит/нидадут/детскиезабввы/пузырь. В эпохи санкций глупо
Именно поэтому в свободных проектах тоже нужны не только колеры, но и всякие продуктологи, экономисты и т.д. То есть люди, которые не только про код и технологии, но и про не менее важное: рынки, боли, и т.п. Опрометчиво надеяться, что левоанархических идеалов достаточно.
Но в матрикс вроде это понимали, и заявляли несколько лет назад о движении в сторону полностью распределенной архитектуры. Вообще, самое важное тут - отвязать айдентити. Т.е. чтобы ваш адрес в сети не был прибит к серверу, который может перестать существовать или "скурвится". Иначе это ведет к потере контактов, а не только логов общения.
Аналогичные мысли давно обсуждаем в чате distributed. Эпоха ллм, конечно, прекрасна. Стало на порядок легче систематизировать или даже тестировать гипотезы.
Вдруг на что-то натолкнет, кстати. https://github.com/distributed-community/dmf
Не. У меня дока — часть разработки, потому там линтинг идет по простым вещам - линтинг маркдауна, например, обычным маркдаун линтом. Но просто потребности не возникало делать прям в большой документации.
Звучит довольно прокачано, хоть и несколько перегружено не для энтерпрайза. Себе придумал маркдаун шаблон c4+arch42 с mermaid схемами. Линтинг и прочее уже на уровне CI, кодогенерации, мэйкфайла, etc. Но тут как раз про близость к коду и версионируемость + использование для агентов и редактирование агентами в том числе.
https://github.com/foxcool/architecture-doc-template
Ага, вот только, как не было толком вакансий по перл, и не припомню, чтоб ко мне из-за него стучались, так и нет.
Реально пришел дед и базы навалил!
Тоже с самого начала карьеры это начал замечать и недоумевал, почему настолько неадекватная повсеместная корпоративная культура, которую уще так яростно защищают и оправдывают. Только как будто зумеры на массовом уровне стали этому противостоять. https://habr.com/p/493038/
Я считаю, что основная проблема на рынке не в ллм, и даже не в хр. А в наклепанных шарагами под копирку специализдах с вайтбордингом головного мозга, отбирающих на открытые позиции мыслящих как они, а не умеющих работать работу.
Сколько надушнили из-за всякой фигни. Автор - красавчик! Не просто что-то придумал, а смог смотивироваться это реализовать. Да ещё и в железе! Не без зависти пишу.
Вспоминаю, как порой геморройно пирогами что-то связанное с кафкой после длительного перерыва. И все может казаться всратым и не удобным. И вот иметь подобные туториалы в обсидиан может быть полезным. Спасибо!
Ага, так может быть удобнее
раньше использовал вайпер с коброй. Но там вот реально надо было вроде отдельный init файл делать, директории с подкомандами и прочим. Т.е. уже решения для прям сложных гуевых приложений, в которых есть команды приложения и их собственные параметры и т.д.
Я как раз люблю собирать параметры в какие-то структуры и потом ее использовать, не дергая какой-то объект за методы. Вот пример моего config.go текущего пет-проекта. Т.е. весь боилерплэйт умещается в одном файлике, который кладется рядом с main.go в папку cmd. А в main уже параметры читаются из структуры.
Тут еще от нехер делать засунуты томл, json. ОБычно все запускаю в ENV так как с компоуза удобнее. Так что можно еще сократить, но накладные расходы на поддержку парсинга конфигов вряд ли фатальны.
Есть ещё koanf, у которого можно из желаемых источников собирать параметры в структуру
Плохой тимлид начинается с идеи, что он является каким-то начальником.
Недавно открыл для себя mermaid как доступный способ кодом "рисовать" диаграммы. Поддерживаются различные виды, в том числе в бете поддреживаются С4 диаграммы. Автоматически рендерится в схемы на гитлабе, обсидиане. В вскод тоже работает, как минимум с установкой расширения (точно не помню). Т.е. можно без каких-либо отдельных инструментов вести ту же документацию сразу в гит-репозиториях в маркдауне и при этом не надо тащить картинками схемы - все изменения будут фиксироваться, как и изменения другого текста.
Статья хорошая.
Добавлю только, что офисная работа и вообще работа на территории работодателя - это не какой-то артефакт из глубины веков. До эпохи индустриализации люди обычно работали примерно там же, где и жили. Да, сама по себе жизнь человека, вынужденного работать для выживания, не была лучше, но сам факт разделения места жизни и места работы начался с необходимости, а продолжился тупым масштабированием дурных практик, приведших к сверхцентрализации ресурсов и другим проблемам вроде маятниковой миграции.
Согласен с идеей про то, что обязанности и ответственность должны быть согласованы с ресурсом человека. А в компаниях с наймом любят нагружать людей, давая максимум чутка денег.
Но такие же можно и сказать про другие "руководящие" роли. Нередко продукт менеджеров нанимают, а потом ожидают выполнения от них скорее функций сержантов, которые пушат разрабов на овертаймы и завершение тасок любой ценой.
В конечном итоге все равно приходишь к мысли, что самое лучшее: когда свой проектик или какой-то движ, людей на найм не надо - либо под конкретные задачи самозанятые, либо уже партнёры нормальные. Не нужно городить огромные вертикальные структуры и вот это все. Но таким образом много ниш отрежешь.
Вообще, в Go можно уйти от возврата ошибок в сторону того же отправления всех ошибок в специальный канал.
Однако, предвижу тонны проблем с дебаггингом, так как в стектрейсах и сентри, скорее всего точка отстрела ошибки будет в той гороутине, которая тащит и как-то "обрабатывает" ошибки из канала. Т.е. могут возникнуть трудности с определением места возникновения ошибки.
Мы уже живём не в нулевых и даже не в десятых. Мир опенсорса давно переживает попытки сделать монетизируемой работу активистов. На данный момент для меня наиболее живой и активный проект - gitcoin на базе эфириума, где периодически даже я кидаю какие-то деньги на гранты проектам
А потом оказалось, что активные донатеры иногда получают эирдропы денежные от других взлетевших проектов. То есть чтобы помогать опенсорсу и распределенным индивидуалистическим решениям даже не обязательно быть идеальным и щедрым.
В опесорсе есть много проектов, которые сами по себе плохо монетизируемые из-за их важных качеств. Вряд-ли вы сможете тупо продавать ядро Линукс или такой же корджс. Но при этом деньги могут ходить через полноценные продукты, частью которого является такой софт.
Вообще, ожидать от масс субъектности и какой-то запредельной просвещенности as is - несколько инфантильно. Средний человек по максимуму не будет вникать в проблемы каких-то проф инструментов и их разработчиков. Для этого работают отдельные специалисты и целые некоммерческие орг.
Но даже многие os задроты не ходят понимать социальные и экономические механизмы общества, а к попыткам развития всяких криптоинститутов относятся примерно так же, как циничные деды из мира юриспруденции и банкинга - ниазлетит/нидадут/детскиезабввы/пузырь. В эпохи санкций глупо
Именно поэтому в свободных проектах тоже нужны не только колеры, но и всякие продуктологи, экономисты и т.д. То есть люди, которые не только про код и технологии, но и про не менее важное: рынки, боли, и т.п. Опрометчиво надеяться, что левоанархических идеалов достаточно.
У федерации, конечно, есть и существенные минусы, схожие с минусами централизованных - привязка к конкретному серверу.
https://t.me/darkfox_info/52
Но в матрикс вроде это понимали, и заявляли несколько лет назад о движении в сторону полностью распределенной архитектуры. Вообще, самое важное тут - отвязать айдентити. Т.е. чтобы ваш адрес в сети не был прибит к серверу, который может перестать существовать или "скурвится". Иначе это ведет к потере контактов, а не только логов общения.