Текстовый редактор видео. Сцены описываются кодом, с помощью реакт компонентов. Обожаю такое
https://www.youtube.com/watch?v=gwlDorikqgY

Напомню, что Реакт — это популярный инструмент и религия (ха) для javanoscript разработчиков (специально не использую слово "библиотека"), с помощью которого описываются интерфейсы приложения. Придумано и популяризовано в Фейсбуке.

Очень нравится, что сейчас есть тренд на альтернативу графическим интерфейсам в виде текстовых.
Расскажу про свой опыт: когда горит, мне удобнее накидать черновик для презентации кодом — я не думаю о графике, фокусируюсь только на смыслах и тексте. В Кейноуте я отвлекаюсь на интерфейс и графику: отступы, стили для заголовков и прочее. Необходимо что-то двигать и нажимать мышкой.

В случае текстового интерфейса — только экран и клавиатура. This is the way

Rebiatkis, привет !
В мою компанию ищут Strong Junior/Middle Go разработчика. (не на моё место)
Если кому-то интересно - пишите мне, сконтактирую вас с эйчаром.
Работа в Киеве в офисе.

Требования:
1+ года разработки с применением Golang
Опыт работы с базами MongoDB, Redis, MySQL
Умение писать юнит-тесты и интеграционные тесты
Опыт командной работы (Git, code review)
Знание структур хранения данных и алгоритмов работы с ними
Понимание принципов работы в REST API/WebSocket

Ну и еще немного

С момента как я начал учить программирование и до прошлых выходных, мне казалось, что ООП - это сущий ад.
Каждый раз, когда видел что-то написанное с применением фабрик, например - пугался и тут же закрыл код, даже не пытаясь вникнуть. К тому же, несколько раз тупил на вопросах о SOLID'е во время собеседований.

И мне казалось, что я вообще никогда не начну эту тему понимать. Ну и если честно - я никогда не пытался.
Я был приятно удивлен, когда наткнувшись на курс о паттернах в Go, стал с интересом и усердием его проходить.
Сейчас я пока что на базовых штуках, но уже чувствую, что немного в своём познании преисполнился и скоро буду готов идти к реке 😂

Так вот, к чему я это. Знать SOLID и паттерны - хоть и не обязательно, но желательно и полезно. Это помогает писать более красивый, понятный и поддерживаемый код.

Ну и сам курс.
https://www.udemy.com/course/design-patterns-go/

Ну и еще на тему, написаного выше.

Вопросы об OOP и SOLID редко спрашивают во время собеседований на entry level junior'a. Среди трех моих собесов, когда я искал первую работу - всего один раз спросили про SOLID. Это был аутсорс, куда искали strong junior'a, чтобы продавать как мидла.

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

В итоге, мораль такова - учите паттерны, как минимум для того, чтобы проходить собесы :)

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

archived = !!+archived;

Очень сильно смеялся

Обновил наконец-то Goland.
Походу уже скипнул несколько патчей.
Из нового и классного, что я успел найти:
- Генерация структур из .json
- Поддержка go:embed
- Лайвкодинг.

Как же я раньше жил без этого прогресс бара

Очень забавно. Есть официальный драйвер для Clickhouse от их команды.
При этом, есть еще и драйвер от mail.ru, где даже Readme почти полностью такой же, как у официального репо.
Только в примерах у первого репо - sqlx, а у второго мэйлрушный dbr.
Нигде вроде не указано, что это форк

1 - https://github.com/ClickHouse/clickhouse-go
2 - https://github.com/mailru/go-clickhouse

А еще, есть очень красивый SDK для github на Go от гугла.
Тут круто всё структурировано и хорошо расписаны примеры использования.
Именно отсюда узнал про кастинг типов(а не type assertion) в Go.

Ссылка на пример кода с кастингом типов.
https://github.com/google/go-github/blob/94d2fbbfba4de5018c7b19da5bc99aa1e9769f2c/github/github.go#L266

Неочевидный stack overflow.
Кто понял - молодец. Пишите в комменты свои варианты :)

https://play.golang.org/p/Iriey5njCch

Захотелось странного. Купить/собрать Intel NUC или подобное. Игровой пк не собрать из-за майнеров и отсутствия денег отсутствия времени играть и пускать слюни. Жить на ноутах все скучнее и скучнее (вот на днях соусом MBP16 утопил, я не шучу).

Пролистываю 1к сохраненный новостей заметил пост, где автор собирает Intel NUC https://dimamoroz.com/2021/03/09/intel-nuc-for-development/

Возможно у кого-то похожая железка и/или такое мелкий ПК в ящике стола. Расскажите, зачем используете и что он вам в итоге даёт. И когда его не стоит покупать)

Noice !
https://www.instana.com/blog/practical-golang-benchmarks/

https://dave.cheney.net/2016/03/19/should-methods-be-declared-on-t-or-t

Вот пост от Dave Cheney. Тут он объясняет, почему лучше создавать методы с ресивером *T, а не T.
Если вкратце, то так нужно делать всегда, кроме случаев, когда нужно копировать значение T.
Но меня интересует скорее апендикс в конце поста:

If the method does not mutate its receiver, does it need to be a method?

Если я хочу писать на го что-то похожее на ООП. И например, создаю тип какого-то юзкейса, который инициализируется при помощи фабрики, в которую передаются какие-то аргументы, а потом использую данные, которые у меня есть в этом юзкейсе. Делаю я это по двум причинам:

1. Удобнее читается, аргументов меньше.
2. Можно создать абстракцию этого типа.

Вопрос, стоит ли так вообще делать тогда, если я никак не мутирую значения в этом типе? Интересно ваше мнение.