Сегодня расскажу про первоапрельские 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 😂

​​tinyhttp - современный и быстрый веб-фреймворк для Node.js, являющийся альтернативой Express

Основные преимущества:

Не зависит от легаси модулей по типу object.assign

Совместим с промежуточными обработчиками для Express

Есть поддержка ассинхронных обработчиков

Существует готовый набор обработчиков для общих задач по типу логгирования и парсинга кук

Написан на TypeScript и как следствие есть типизация из коробки

Фреймворк находится в ранней разработке, поэтому не весь функционал из Express до конца перенесён.

P.S. Создателем фреймворка является автор канала (@talentless_guy), если есть фидбек по поводу tinyhttp, то пишите в личку (или в наш чат) :D

#backend #webdev #javanoscript #typenoscript #tinyhttp #express #nodejs

Как выглядит машинное обучение в 2020 — даешь алгоритму ДВА (!!) примера кода, а он на основе них выдает тебе верстку по запросу в духе «мне красную кнопку пожалуйста и заголовок с таким вот текстом»:

twitter.com/sharifshameem/status/1282676454690451457