Для всех, кто хочет выучить Go.
Упорядоченный список того, что стоит выучить с ссылками на ресурс.
Часть - это материал, написанный самим автором, другая часть - ссылки на сторонние, в том числе официальные, ресурсы.
Велкам!

https://github.com/hoanhan101/ultimate-go

Встречайте tinyhttp, крошечная и быстрая альтернатива Express без легаси

Авторская статья (написанная мною, @talentless_guy), о том, зачем я начал писать свой фреймворк, какие проблемы он решает, и как начать им пользоваться. Будет интересно тем, кто пишет бекенд на Express, и хотел бы попробовать что-то новое, но с тем же API.

p.s. готовится статья про процессную многозадачность (на русском) в Node.js, в будущем будет опубликована

#jsarticle #javanoscript #backend #nodejs #tinyhttp #express #typenoscript

Судя по опросу в прошлом, здесь есть те, кто пишет на js.
Мой товарищ написал свой фрэймворк, похожий на Express,но без легаси кода.

Проект активно развивается и уже набрал больше 7к скачиваний и больше 200 звезд на гх.
Кому интересен бэкенд на js - советую попробовать, будет интересно ваше мнение 🙂

Разных сервисов с free tier планом для разработчиков куча, это круто.
Но их настолько много, что сложно даже разобраться.

Нашел офигенный список с детальным описанием бесплатных фич всех крупных и не очень платформ.
Список не ограничивается только клауд провайдерами, там много разного, так что, зацените!

https://github.com/ripienaar/free-for-dev

Скорее всего, это не очень объективная метрика для оценки продуктивности.
Но мне всегда нравится в конце рабочего дня смотреть, сколько времени я кодил/на каких языках/в каких репо.
Поэтому, пользуюсь Wakatime, который можно прикрутить к любому редактору.
В моём случае это - NeoVim.
Работает идеально, главвное чтобы на компе был правильно установлен Python.

Оставляю ссылку, если кто-то тоже захочет себе поставить.
https://wakatime.com/

Кстати, интересно, замеряете ли какие-то метрики продуктивности?
Если да, то напишите, пожалуйста, какие и чем.

Можно в комменты, можно в личку мне(@mlvni)
Если наберется пара-тройка интересных инструментов - сделаю подборку и расскажу о них тут.

На канал я не забил. У меня был переезд, сейчас я в Украине. Скоро снова возьмусь за канал с новыми силами. Ожидайте ;)

programmin is no magic
my project:

Шедевральный абзац о плохих логах и тех, кто их создаёт.

Сегодня со мной случилось забавное и неожиданное открытие.
Приняли мой pr в дев ветку, я предварительно проверил всё, в докере билд проходил.
Из дева автоматически билдится новый образ в dockerhub.
В итоге захожу на докерхаб и статус моего билда - Failed.
Немного порылся и выяснилось, что если ты кладешь в репо файл с окончанием test.yaml - запускаются автотесты на этот контейнер.
Так я и узнал, что докерхаб умеет в автотесты.

Вот дока: https://docs.docker.com/docker-hub/builds/automated-testing/

Интересная статья об обработке нескольких ошибок в го. И, кстати, да, я решил вернуться. Сейчас работаю на удаленке, поэтому времени на написание постов будет побольше.

https://medium.com/a-journey-with-go/go-multiple-errors-management-a67477628cf1

Во многих источниках по concurrency в go видел рекомендацию о том, что одна горутина не должна принимать из канала и одновременно писать в него.

Раньше не понимал почему, вплоть до момента, пока не столкнулся с последствиями такого решения в проде (автором того куска кода был не я).
В моём примере был локальный буфер для кликхауса, который собирал определенное количество строчек и потом делал bulk в сам кх.

Так вот, эти строки он получал из канала, складывал в массив. Потом по сигналу от тикера делал запись. В случае, если запись была неудачной - засовывал всё из массива обратно в канал. Размер канала 2000, одновременно с тем, как записи возвращались обратно в канал, они так же поступали в него из других горутин.
При этом, горутина, которая должна была читать что-то из канала была заблокирована и канал переполнялся и получался deadlock.

Вывод: одна горутина не должна одновременно читать и записывать в канал, получится deadlock. Нужно либо создавать другой, резервный канал для записи из этой горутины, либо запускать внутри этой горутины еще одну, которая будет записывать.

Ну всё, теперь будут нормальные комменты. Так что вы это, пишите, если что.

Я тут за пару часов написал маппер из map[string]interface{} в объекты.
Написал пару тестов, вроде всё работает, но нужно еще тестить и оптимизировать.
Там куча рефлекта и скорее всего, читать это неудобно. Потом отрефакторю, но это не точно.
Критика важна и приветствуется!

https://github.com/Koshqua/structmap

Очень уж нравится, как Goland работает в сплит скрине.

Понял, что еще больше нравится, как работает телеграм.

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

https://xuri.me/toml-to-go/

У нас на работе есть небольшая библиотека, там много разных книг и некоторые из них о Go. Давно хотел что-то оттуда взять и наконец дошли руки. Взял почитать "The way to Go" Ivo Balbaert.
В книге есть хорошее введение в язык с объяснением истории и идеи создания. Для меня читать это - уже немного поздно, было бы круто найти эту книгу, когда я только начинал учить Go.

Но, что меня действительно заинтересовало, так это раздел о concurrency.
Только начал читать и наткнулся на прикольную штуку, которая лежала прямо в stdlib. А именно, функцию runtime.Gosched().

Если вкратце, эта функция "освобождает" процессор, на котором выполняется текущая горутина и "передаёт" ресурсы другой горутине, чтобы та тоже могла выполниться. Нашел хороший тред на StackOverflow с детальным объяснением того, как это работает. Не уверен, что это можно применить в production приложениях, но штуковина точно интересная. И, самое забавное, она уже давно была у меня на виду, но как-то не обращал на неё внимания.

https://stackoverflow.com/questions/13107958/what-exactly-does-runtime-gosched-do/13108469

На днях получил задачу написать сервис для подсчета некоторой статы из стороннего апи.
И так исторически сложилось, что всё, что считает статистику у нас на NodeJS.
В итоге, пишу сервис на ноде и, сказать честно, мне понравился js.

Особенно понравилось то, как работает асинхронность, всё очень просто и понятно.
Некоторый опыт с нодой был до этого, т.к я с неё начинал, но это было давно, поэтому есть ощущение, будто учу язык с нуля и это правда захватывающе.

Могу сделать вывод, что иногда интересно переключаться на другие технологии.
Особенно круто, что нельзя, например, написать код на js'е так же, как я написал бы его на go, поэтому приходится больше думать о структуре и периодически подглядывать в доки. Сервис пока не дописал, но уже на полпути, чувствую, что буду очень доволен, когда закончу эту таску.