Forwarded from Neural Machine
Я собираюсь пожаловаться, боже мой, в мире так много людей.
Ребят, я решил вернуться к тому, чтобы вести канал.
И начну, пожалуй, с рассказа о том, как я вернулся в neovim из Goland.
Решил вернуться я по нескольким причинам:
1. В виме дико удобные хоткеи, а я очень люблю хоткеи.
2. Раздражает необходимость отдавать 1.5гб оперативки на то, чтобы просто редактировать текст.
Хоть это и красиво подсвеченный текст со всякими там возможностями редактирования и рефакторинга.
Но факт остаётся фактом, редактор нужен для того, чтобы редактировать текст.
Всякие штуки с гитом я всё равно всегда делал в терминале в основном.
3. Не хотелось пользоваться вимом, потому что думал, что там нет встроенной поддержки дебага и рефактора.
Оказалось, дебаг там есть и очень даже не плохой, с помощью guru можно легко делать всякий ренейм и многое другое.
В первый раз когда вкатывался в вим не обратил внимания на тутор от создателя vim-go.
Короч, там всё классно и наглядно, а главное - с нуля с учетом установки самого вима(точней neovim).
Сам туториал можно найти здесь.
Вот пользуюсь третий день, уже даже запилил первый пул, который делал только в виме.
Конечно, пока что, я возможно даже немного медленней пишу код, т.к привыкаю, но думаю, что в скором это даст свои плоды.
А еще, мне кажется(или я просто плохо смотрел), Goland не использует guru во всю, например GoCallees, GoChanPeers и т.д, а ведь штуки удобные, хоть и немного медленные.
Если будет у кого-то желание - могу поделиться своим конфигом, я там подобавлял чуть всяких штуковин под себя.
Но мой vimrc - это пока что work in progress, так что советы и всякие ресурсы по теме тоже приветствуются.
И начну, пожалуй, с рассказа о том, как я вернулся в neovim из Goland.
Решил вернуться я по нескольким причинам:
1. В виме дико удобные хоткеи, а я очень люблю хоткеи.
2. Раздражает необходимость отдавать 1.5гб оперативки на то, чтобы просто редактировать текст.
Хоть это и красиво подсвеченный текст со всякими там возможностями редактирования и рефакторинга.
Но факт остаётся фактом, редактор нужен для того, чтобы редактировать текст.
Всякие штуки с гитом я всё равно всегда делал в терминале в основном.
3. Не хотелось пользоваться вимом, потому что думал, что там нет встроенной поддержки дебага и рефактора.
Оказалось, дебаг там есть и очень даже не плохой, с помощью guru можно легко делать всякий ренейм и многое другое.
В первый раз когда вкатывался в вим не обратил внимания на тутор от создателя vim-go.
Короч, там всё классно и наглядно, а главное - с нуля с учетом установки самого вима(точней neovim).
Сам туториал можно найти здесь.
Вот пользуюсь третий день, уже даже запилил первый пул, который делал только в виме.
Конечно, пока что, я возможно даже немного медленней пишу код, т.к привыкаю, но думаю, что в скором это даст свои плоды.
А еще, мне кажется(или я просто плохо смотрел), Goland не использует guru во всю, например GoCallees, GoChanPeers и т.д, а ведь штуки удобные, хоть и немного медленные.
Если будет у кого-то желание - могу поделиться своим конфигом, я там подобавлял чуть всяких штуковин под себя.
Но мой vimrc - это пока что work in progress, так что советы и всякие ресурсы по теме тоже приветствуются.
GitHub
GitHub - fatih/vim-go: Go development plugin for Vim
Go development plugin for Vim. Contribute to fatih/vim-go development by creating an account on GitHub.
Forwarded from 🇺🇦 Go for two :)
How to Make Your Code Reviewer Fall in Love with You:
1. Review your own code first
2. Write a clear change list denoscription
3. Automate the easy stuff
4. Answer questions with the code itself
5. Narrowly scope changes
6. Separate functional and non-functional changes
7. Break up large change lists
8. Respond graciously to critiques
9. Be patient when your reviewer is wrong
10. Communicate your responses explicitly
11. Artfully solicit missing information
12. Award all ties to your reviewer
13. Minimize lag between rounds of review
https://mtlynch.io/code-review-love/
1. Review your own code first
2. Write a clear change list denoscription
3. Automate the easy stuff
4. Answer questions with the code itself
5. Narrowly scope changes
6. Separate functional and non-functional changes
7. Break up large change lists
8. Respond graciously to critiques
9. Be patient when your reviewer is wrong
10. Communicate your responses explicitly
11. Artfully solicit missing information
12. Award all ties to your reviewer
13. Minimize lag between rounds of review
https://mtlynch.io/code-review-love/
mtlynch.io
How to Make Your Code Reviewer Fall in Love with You
Best practices for code review when you're the author.
Указатели как поля в структуре.
Наткнулся на код, в котором для полей используются ссылочные типы, например,
Какой-то явной необходимости в этом нет, всё было работало и без этого.
Уточнил, оказалось, что это такая конвенция, потому что поинтер можно проверить
А для каждого другого типа нужно сравнивать с нулевым значением.
Плюс к этому всему в коде куча конструкций вроде:
Лучше уж написать ф-цию, которая возвращает поинтер на конкретный тип.
Ну, я решил немного изучить вопрос и наткнулся на вот этот тред.
Если коротко:
Есть смысл использовать *T как поле в случае маршалинга, когда нужно передавать нулевое значение не смотря на omitempty. Например, поле int и нам нужно передавать 0, в случае с указателем, значение в json смаршалится как 0.
В случае с nil - поля не будет в json'e.
Таким образом, можно разделять случаи когда поле не было передано и когда поле имеет нулевое значение.
Но мне кажется, что это нужно настолько редко :)
Интересно было бы начать здесь тред по этому вопросу и услышать ваше мнение.
Наткнулся на код, в котором для полей используются ссылочные типы, например,
*bool, *string и т.дКакой-то явной необходимости в этом нет, всё было работало и без этого.
Уточнил, оказалось, что это такая конвенция, потому что поинтер можно проверить
v != nil и т.дА для каждого другого типа нужно сравнивать с нулевым значением.
Плюс к этому всему в коде куча конструкций вроде:
isTrue := trueОни мне не кажутся красивыми.
a.someFlag = &isTrue
Лучше уж написать ф-цию, которая возвращает поинтер на конкретный тип.
Ну, я решил немного изучить вопрос и наткнулся на вот этот тред.
Если коротко:
Есть смысл использовать *T как поле в случае маршалинга, когда нужно передавать нулевое значение не смотря на omitempty. Например, поле int и нам нужно передавать 0, в случае с указателем, значение в json смаршалится как 0.
В случае с nil - поля не будет в json'e.
Таким образом, можно разделять случаи когда поле не было передано и когда поле имеет нулевое значение.
Но мне кажется, что это нужно настолько редко :)
Интересно было бы начать здесь тред по этому вопросу и услышать ваше мнение.
Stack Overflow
Difference using pointer in struct fields
We can create structs in golang this way. Examples below:
What are differences between these two?
// Usual way
type Employee struct {
firstName string `json:"name"`
salary int ...
What are differences between these two?
// Usual way
type Employee struct {
firstName string `json:"name"`
salary int ...
Нашел интересную дырку в монге.
Ну, скорее всего это предсказуемое поведение, но неочевидное.
Если пытаешься конкурентно апдейтнуть один и тот же документ с
Происходит так из-за того, что операции в монге атомарны в пределах одного документа.
А если документа нет - то нет и атомарности :)
Ну, скорее всего это предсказуемое поведение, но неочевидное.
Если пытаешься конкурентно апдейтнуть один и тот же документ с
upsert:true (в случае если документа не существует) - создаётся два документа. Происходит так из-за того, что операции в монге атомарны в пределах одного документа.
А если документа нет - то нет и атомарности :)
Предыдущее актуально для старых версий монги.
Начиная с версии 4.16 - это поведение исправили.
Начиная с версии 4.16 - это поведение исправили.