Пример очень простой, Есть сервис, где есть бек и фронт, появляется новая фича, где надо по требованиям сделать 5-6 новых едпойнтов с CRUD + бизнес логика. Используя текущую кодобазу проекта я сгенерил каркас для нового сервиса + все контроллеры + базовые sql запросы и сервис репозиторий + swagger дока за 10 минут. проверил и написал тесты вручную еще 2 часа. Потестил руками в постмане, раскатили на дев стенде и потестили с QA, потом пофиксил баги. в итоге овер 2к вполне работающих строчек кода с реализацией новой бизнес фичи за 1-2 дня, тогда как руками все это бы я делал неделю. Ну и потом фронтент нарулил также из готовых компонентов + надо было новый тоже реализовать из фигмы, но с помощью ИИ тоже все было сделано быстрее.
Да ИИ не сильно поможет, и даже может время съесть, если надо сделать что-то сложное и где надо продумать архитектуру, нарисовать UML и все такое. Но он для этого и не годится сейчас. А вот рутинные штуки где надо сделать CRUD, уже в существующей кодобазе - это оч сильно ускоряет.
Я спрашивал что он имеет ввиду, когда говорит про компарабл в рамках своего коммента, а не что такое именно в ГО. Я статью пишу прежде всего для того, что материал усвоить и получить критику.
да со слайсами nil можно делать все кроме взятия значения по индексу и сета нового значения по индексу, все остальное будет работать. Я расчитывал на то, что читатель понимает, что если я пишу манипуляции с nil, то понятно о чем я говорю и не надо разъяснять.
Для new да я не уточнил, что возвращается указатель. Но я говорил образно, что происходит. у ок, тут можно было расписать получше, спасибо
new почти никогда не используют для chan, map, slice. Да есть случаи но это оч редко и очень специфически
с нил слайсами можно делать почти все кроме взятии по индексу или записи по индексу, я тут не стал вдаваться в подробности, и надеялся, что это и так понятно читателю.
для array и struct я же привел пример, ели передавать по значению а не ссылку то оригинальный массив или структура не измениться
func main() { ar := [3]string{"f", "s", "t"} makeSomething(ar) fmt.Println(ar) // [f s t] }
Я их называю ссылочными переменными, потому много кто так делает и все понимают о чем я говорю, и все понимают когда я говорю передать по ссылки, это значит я передаю ссылку и ничто другое потому что там указан явно астериск *
Как по мне просто тупо скопировали вопросы из известного опросника для GO собесов, закинули в LLM и тупо засунули в этот пост без понимания и объяснения; В статье "Коллеги вы меня огорчаете" (откуда и были взяты вопросы) прям с самого начала написано, что нужно глубинное понимание как работает тот или иной механизм или структура в ГО, просто заучивание ответов не поможет, потому что ты получишь пару наводящих, дополнительных вопросов и будет понятно, что ты не понимаешь о чем ты говоришь.
Например вопрос про слайсы и мапы, вообще ничего нету, как там под капотом это работает, что такое ссылочные структуры в ГО и что такое структуры по значению. чем оттличаются (сюрприз там есть дескриптор или голова при создании иногда дескриптор указывает на nil а иногда на алокейт в памяти) вот что надо что бы отвечать на вопросы а не тупо объяснение что такое хэш таблица (даже вез объяснений как она работает и главного ее недостатка, причем в любом ЯП а не только ГО)
Кароче статья ни о чем, лучше почитать основную документацию, например Effective GO
Я не спорю а как раз жду таких фидбеков ) Да я изучаю GO методом практики, и что бы закрепить материал, можно кому то объяснить то, что ты учишь, мне помогает написание статьи например. Спасибо за коммент
Я на все 100% не использую, в среднем днем белые стоят на 18-25% остальные по 5-10%, ночью и того меньше, горит только синий на 1-3%, запас как говорится есть и хорошо, возможно в будущем перейду на большую банку.
Вы хоть прочитали мой коммент ? я же написал, что новая фича предполагает то, что мне надо сделать и CRUD операции и сделать новые ендпойнты.
Пример очень простой, Есть сервис, где есть бек и фронт, появляется новая фича, где надо по требованиям сделать 5-6 новых едпойнтов с CRUD + бизнес логика. Используя текущую кодобазу проекта я сгенерил каркас для нового сервиса + все контроллеры + базовые sql запросы и сервис репозиторий + swagger дока за 10 минут. проверил и написал тесты вручную еще 2 часа. Потестил руками в постмане, раскатили на дев стенде и потестили с QA, потом пофиксил баги. в итоге овер 2к вполне работающих строчек кода с реализацией новой бизнес фичи за 1-2 дня, тогда как руками все это бы я делал неделю. Ну и потом фронтент нарулил также из готовых компонентов + надо было новый тоже реализовать из фигмы, но с помощью ИИ тоже все было сделано быстрее.
Да ИИ не сильно поможет, и даже может время съесть, если надо сделать что-то сложное и где надо продумать архитектуру, нарисовать UML и все такое. Но он для этого и не годится сейчас. А вот рутинные штуки где надо сделать CRUD, уже в существующей кодобазе - это оч сильно ускоряет.
Я спрашивал что он имеет ввиду, когда говорит про компарабл в рамках своего коммента, а не что такое именно в ГО. Я статью пишу прежде всего для того, что материал усвоить и получить критику.
Comparable ? Я не очень понимаю что вы имеете ввиду под этим, приведите пожалуйста пример.
если ты значение аппенд сохранишь в ту же переменную или неважно в какую, то оригинальный слайс никак не поменяется.
func makeSomething(s []string) {
s = append(s, "item")
s[1] = "meti"
}
func main() {
ar := []string{"f", "s", "t"}
makeSomething(ar)
fmt.Println(ar) // [f s t]
}
да со слайсами nil можно делать все кроме взятия значения по индексу и сета нового значения по индексу, все остальное будет работать. Я расчитывал на то, что читатель понимает, что если я пишу манипуляции с nil, то понятно о чем я говорю и не надо разъяснять.
Для new да я не уточнил, что возвращается указатель. Но я говорил образно, что происходит. у ок, тут можно было расписать получше, спасибо
new почти никогда не используют для chan, map, slice. Да есть случаи но это оч редко и очень специфически
с нил слайсами можно делать почти все кроме взятии по индексу или записи по индексу, я тут не стал вдаваться в подробности, и надеялся, что это и так понятно читателю.
для array и struct я же привел пример, ели передавать по значению а не ссылку то оригинальный массив или структура не измениться
func makeSomething(s [3]string) {
s[0] = "first"
}
func main() {
ar := [3]string{"f", "s", "t"}
makeSomething(ar)
fmt.Println(ar) // [f s t]
}
Я их называю ссылочными переменными, потому много кто так делает и все понимают о чем я говорю, и все понимают когда я говорю передать по ссылки, это значит я передаю ссылку и ничто другое потому что там указан явно астериск *
Спасибо за коменты
Ну тут скорее всего это связанно с реализацией мапы в ГО, и как они решают проблему коллизии ключей.
Как по мне просто тупо скопировали вопросы из известного опросника для GO собесов, закинули в LLM и тупо засунули в этот пост без понимания и объяснения; В статье "Коллеги вы меня огорчаете" (откуда и были взяты вопросы) прям с самого начала написано, что нужно глубинное понимание как работает тот или иной механизм или структура в ГО, просто заучивание ответов не поможет, потому что ты получишь пару наводящих, дополнительных вопросов и будет понятно, что ты не понимаешь о чем ты говоришь.
Например вопрос про слайсы и мапы, вообще ничего нету, как там под капотом это работает, что такое ссылочные структуры в ГО и что такое структуры по значению. чем оттличаются (сюрприз там есть дескриптор или голова при создании иногда дескриптор указывает на nil а иногда на алокейт в памяти) вот что надо что бы отвечать на вопросы а не тупо объяснение что такое хэш таблица (даже вез объяснений как она работает и главного ее недостатка, причем в любом ЯП а не только ГО)
Кароче статья ни о чем, лучше почитать основную документацию, например Effective GO
https://go.dev/doc/effective_go
Я не спорю а как раз жду таких фидбеков ) Да я изучаю GO методом практики, и что бы закрепить материал, можно кому то объяснить то, что ты учишь, мне помогает написание статьи например. Спасибо за коммент
На сокетах у меня будет умный дом. Возможно и аквариум будет в этой экосистеме.
Лучше не стоит), в дальнейшем это все будет регулироваться автоматически. Пока все находится в тестовом режиме.
Потому что пока все работает в тестовом режиме, потом это все будет в хуке mounted(), возможно с неким интервалом.
Спасибо большое!
Согласен, все будет автоматизироваться. В этих статьях я начал рассказывать в каком направлении проект будет двигаться.
Вот спасибо Мил человек ) почитаю обязательно, кстати что касается пинов, есть еще же ESP32 там и пинов больше и памяти и сам проц помощнее )
Их надо прошивать, я же написал в начале статье, что у меня была ардуина свободная и отдельный
wi-fiмодуль.Так и есть, основные это белые и синий, остальные включаю только пока для красоты. Пока сама банку пресноводная, не цветет вроде.
Я на все
100%не использую, в среднем днем белые стоят на18-25%остальные по5-10%, ночью и того меньше, горит только синий на1-3%, запас как говорится есть и хорошо, возможно в будущем перейду на большую банку.Будет автономное все. Но для наблюдения и ручной корректировки я сделал
front-end, статья скоро выйдет