​​Пока что мой neovim выглядит вот так, после всех этапов из гайда, который я отправил в предыдущем посте.
Дополнительно я установил NERDTree, это файловый браузер.
https://github.com/preservim/nerdtree - NERDTree.

Около месяца искал тул с помощью которого можно найти весь неиспользуемый код.
Казалось, что на проекте его куча и хотелось от него избавиться.
И в итоге долгих поисков я нашел вот этот потрясающий линтер: https://github.com/dominikh/go-tools.
Который не только ищет неиспользуемые методы/поля/структуры/глобальные переменные, но и помогает писать идеоматичный код.
И вообще, делает намного больше, чем встроенный golint. К тому же, у него очень крутая документация.

Вот примеры тех алертов, которые он выдаёт:
Если использовать литералы создание слайсов.

 should use make([]string, 0) instead (S1019)

Если значение переменной после присваивания нигде не используется:

 this value of findCond is never used (SA4006)

И, кстати, по итогу на проекте было не так уж много “мертового” кода, что очень порадовало.

Сегодня расскажу про первоапрельские Request For Comments (пару лет назад я про них уже упоминал). RFC — массив документов, описывающих интернет-протоколы и различные технические вопросы, связанные с их использованием, по сути, основная база стандартов интернета, если слово "стандарт" тут вообще применимо; на данный момент их почти 9 тысяч. Инженеры порой любят пошутить, и время от времени стали появляться первоапрельские RFC (википедия знает уже больше 50).

Самая известная (хотя и не первая) шутка опубликована в 1990 году в RFC 1149 "передача IP-пакетов голубиной почтой". Стандарт указывает, что "пропускная способность ограничена длиной лапки", "broadcasting не поддерживается", "MTU в среднем повышается с возрастом носителя" и другие полезные сведения. Позже стандарт расширялся, например, в RFC 2549 (поддержка QoS) и в RFC 6214 (поддержка IPv6). В 2001 году протокол был практически реализован в Bergen Linux user group, было отослано 9 ping пакетов и получено 4 reply:

--- 10.0.3.1 ping statistics ---
9 packets transmitted, 4 packets received, 55% packet loss
round-trip min/avg/max = 3211900.8/5222806.6/6388671.9 ms

Среди других первоапрельских RFC упомяну RFC 2324+RFC 7168 о "гипертекстовом протоколе по управлению кофейником" (очень похожим на мою старую курсовую), RFC 3251 "электричество поверх IP", RFC 5514 "IPv6 поверх социальных сетей" (позже также реализованная) и RFC 7511 "живописная маршрутизация для IPv6".

В этом году опубликовали RFC 8774 "The Quantum Bug", но я пока не читал. А ещё я когда-то давно рисовал интерактивные "созвездия RFC" — граф взаимного цитирования этих документов. Почитать/посмотреть можно тут.

Весь предыдущий месяц занимался тестами. Ну и совсем немного писал новые фичи и исправлял баги, которые где-то вылазили.
И вот, момент истины, у меня по всем пакетам (почти) test coverage 70-85%, и я ожидаю увидеть хотя бы 60% по всей репо.
В итоге, я как-то это всё неправильно замерил и получил 17%. Очень расстроился, весь день недоумевал, как это вообще может быть.
В итоге вот нашел правильный скрипт для замера tc, ну и отправки показатель в CI системы(если кому нужно) и у меня 62%.
Теперь можно спать спокойно.

Вот тут можно почитать об этом: https://blog.seriesci.com/how-to-measure-code-coverage-in-go/

Пока GoLand 👋, привет VSCode ✋. Go кор команда перебирает бразды правления над этим плагином.

https://blog.golang.org/vscode-go

Очень крутая и понятная лекция о фундаментальном устройстве баз данных.

https://www.youtube.com/watch?v=c4_5rqvmDFU

no one: ..
parsers:

Чувак круто рассказывает про vim.
Не смотря на то, что у vim крутая дока и можно всё прочитать - намного проще когда кто-то просто выделяет самое главное и основное.
Так что вот, самое главное и основное про vim.

https://www.youtube.com/channel/UC8ENHE5xdFSwx71u3fDH5Xw

🐹 Докладывают наши лучшие специалисты на go.

Пришел апдейт по дженерикам https://blog.golang.org/generics-next-step:
- на контракты забили
- говорят новый design draft сильно понятнее и проще
- выпустили тулзу, которая позволяет пописать на go с generic’ми прямо сейчас. Она просто транслирует код в обычный код без дженериков. В релизе все будет работать по другому.
- они (go team) все еще задаются вопросом нужны ли дженерики, в т.ч. есть шансы, что они могут так и не появиться
- самый ранний релиз, в котором могут появиться — go 1.17, август 2021
stay tuned 🍿

#golang

​​Получается, я уже почти две недели работаю в vim.
И, хочу сказать, пока что - мне всё очень нравится.
Не заметил никаких неудобств или недостатка функционала.
И в итоге, получается действительно быстрее за счет хоткеев и работы только с клавиатурой.
Плюс, вместо обычных vscod’овских 900мб памяти, vim занимает 15-20мб. И это очень спасает, т.к у меня всего 8гб памяти.
Прикреплю внизу список плагинов, которые я установил для работы с Go.
Если кому-то интересно - могу скинуть файл конфига целиком.

​​Стала интересна такая штука.

У меня есть две сущности, которые разные по смыслу, но поля у них одинаковые.
Мне нужно было доставать эти сущности из бд и что-то с ними делать.
Так вот, я хотел, чтобы для этих сущностей был один и тот же стракт.
Единственная разница между ними - это bson тэги для правильного парсинга из монго.
Так вот, я написал функцию с помощью reflect’a которая динамически в зависимости от условия генерирует тэги для нужных полей.
В итоге я хотел с помощью type assertion интерфейс с измененными тэгами конвертировать обратно в структуру.
И к сожалению, это невозможно, так как в го типы с разными тегами - это разные типы.

Решил засесть за вот этот список - https://github.com/jwasham/coding-interview-university.
Про него раньше писал Сергей Сурганов у себя на канале https://news.1rj.ru/str/internet9000/1207, но всё как-то не доходили руки.

Идея этого учебного плана в том, что бы из software developer’a сделать software enginer’a.
Автор пишет, что в крупных компаниях вроде Google, Amazon и т.д эти понятия трактуются по-разному.
Первое - не предусматривает глубокого знания computer science, а второе - требует серьезных знаний в CS.

Список просто огромный и самое крутое - это то, что кто-то собрал это за нас, то есть можно просто взять и выучить то, что интересно.
Но вообще, автор пишет что стоит идти сверху вниз, не пропуская пунктов.
Сейчас смотрю вот это выступление https://www.youtube.com/watch?v=0SARbwvhupQ, в котором рассказывается о “мифе гениального разработчика”, о том, почему не стоит бояться выставлять свой код на показ и почему это хорошо, когда кто-то корректирует твои ошибки.

Крутой пост о том, как правильно учиться от создателя списка, который я кидал вчера.
Конечно, это немного заморочливо, но так можно правда сохранить информацию в голове.
Я лично кучу раз наступал на грабли чрезмерного потребления информации без нотирования и практики.
Если вкратце, суть в повторении.

https://startupnextdoor.com/retaining-computer-science-knowledge/

Когда пытаешься исправить баг в час ночи

А там гитхаб обновил UI. Красиво!
https://github.blog/changelog/2020-06-23-design-updates-to-repositories-and-github-ui/

Давно ничего не было, был занят переездами. Сейчас временно обосновался на одном месте, можно снова писать сюда.
Наткнулся на интересную статью в которой объясняется, почему обработка ошибок в го - крутая, а не надоедливая,плюс автор объясняет почему она именно такая какая есть.

П.С сегодня у меня др, а каналу исполнится год 22-о июля. Было бы круто, если б к этому моменту мы набрали 100 подписчиков, так что если у вас есть друзья/знакомые/коллеги, которым может быть интересен мой канал - буду рад, если поделитесь с ними.🥳

https://rauljordan.com/2020/07/06/why-go-error-handling-is-awesome.html

Ouch

Ох кому-то будет балдежно ревьюить этот pr 😂