Какой классный бесплатный сервис!
https://vectorizer.ai
Превращает растровую картинку в векторную с помощью AI.
https://vectorizer.ai
Превращает растровую картинку в векторную с помощью AI.
🔥9🐳2
Ищу себе нормальны VPN. Нашел крутой, но нет серверов в рф, написал в поддержку и спросил почему. Ответ убил:
The reason we don’t have servers in Russia is that the Russian government requires anyone who routes Internet traffic to log.
Once we found out that they wanted or required us to log we removed our servers from the data center there.
It was our choice to remove those data centers because of our strict no logging policy.
С одной стороны меня радует подход, но с другой этот впн не закроет все мои потребности🔥2👍1
Перевод:
Выдержка из файла /scripts/web, включенного в состав оригинального netcat в 1995 году.
Интернет - отстой. Это могучий унылый клубок, построенный из тысячи
крошечных унылых косяков, скрепленных пластырем, и теперь эти допотопные
невежественные придурки, которые никогда не слышали о "рукопожатии TCP", хотят запустить
*коммерцию через эту чертову штуку. Да боги. Добро пожаловать на телевидение следующего
века - шесть миллионов каналов бесполезного дерьма на выбор, и
и примерно столько же безопасности, как в сегодняшней кабельной индустрии!
Сильно устав от болезненных браузеров в заднице, я решил
создать минималистичный клиент. Он не обрабатывает POST, только GET, но
большинство обработчиков CGI-форм, очевидно, все равно игнорируют этот метод.
Несомненным преимуществом является то, что он не передает никакой другой информации
серверу, например, Referer: или информацию о вашей локальной машине, как, например.
Netscum пытается это сделать!
Со времен первой версии этот клиент стал почти минималистичным,
но теперь он экономит много текста. А с netcat в качестве бэкенда, это
полностью соответствует требованиям. У вас нет netcat? Возьмите его здесь, в /src/hacks!
_H* 950824, обновлено 951009 и далее.🔥2😱1
(Слайс структур, удовлетворяющих интерфейсу) != (слайс интерфейсов).Пример:
https://goplay.space/#BGyrAUzsKAn
package mainможно исправить через дженерики:
import "fmt"
func main() {
arr := []SomeStruct{
{1},
{2},
}
Printer(arr) // нельзя передать
}
// Структура SomeStruct с единственным методом Print
type SomeStruct struct {
id int
}
func (s SomeStruct) Print() {
fmt.Println(s.id)
}
// Printer принимает слайс интерфейсов
func Printer(arr []Printable) {
for _, item := range arr {
item.Print()
}
}
type Printable interface {
Print()
}
func Printer[T Printable](arr []T) {
for _, item := range arr {
item.Print()
}
}
но даже так, если есть метод с ресивером указателем, то слайс структур не передать и надо делать слайс указателей на структуры, а это мне тоже не нравится. Сижу грущу. Другой язык что ли попробовать😁3😱1
If you had a J in your name you could get hired as a java programmerhttps://youtu.be/Nsjsiz2A9mg?t=1350
О, круто! Роберт Мартин называет чистую архитектура архитектурой Якобсона! (Ivar Jacobson)
Когда оборачиваешь доступ к апи в объект, то можно сделать сперва методы, которые соотносятся с эндпоинтами самого апи 1 к 1. А уже потом, используя эти методы создавать публичные методы удобные для всего остального кода.
Я раньше так и делал, но неосознанно, а сейчас явно прочитал, что это нормальная идея у Фаулера:
Я раньше так и делал, но неосознанно, а сейчас явно прочитал, что это нормальная идея у Фаулера:
Sometimes a good strategy is to build the Gateway in terms of more than one object. The obvious form is to use two objects: a back end and a front end. The back end acts as a minimal overlay to the external resource and doesn’t simplify the resource’s API at all. The front end then transforms the awkward API into a more convenient one for your application to use. This approach is good if the wrapping of the external service and the adaptation to your needs are reasonably complicated, because each responsibility is handled by a single class. Conversely, if the wrapping of the external service is simple, one class can handle that and any adaptation that’s needed.👍1🤔1
Не нравятся каналы, где отключены негативные реакции. Слабаки...
(Накидайте какашек)
(Накидайте какашек)
💩26👍4🤮2🖕1
#книги
Vlad Khononov - Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy
01.07.2023 - 23.07.2023
Хотя по факту я читал ее дольше т.к. начинал и на середине остановился из-за того, что понял, что надо читать делая заметки, а читал тогда еще с телефона.
Книга хорошая. Отличный рейтинг на амазоне, считаю, что ее хорошо читать, как первую книгу в DDD.
Вообще в DDD есть 2 главные книги, это:
1. Синяя Eric Evans - Domain-Driven Design - классика DDD
2. Красная Vaughn Vernon - Implementing domain-driven design
Когда я разбирался, что читать, то видел совет начинать с красной т.к. она более прикладная, а не чистая теория, как в синей. Совершенно бесполезный совет. Красная книга читается плохо, дак еще и использует термины, определения которых нет в книге (конечно нет, они в синей находятся). Синюю я тоже читать не хотел т.к. и рейтинг тоже не самый высокий и еще большая. И я наткнулся на текущую книгу с огромным рейтингом и отличными отзывами. Ее и начал, а синюю запланировал на потом.
Самое полезное, что узнал:
1. Как можно делить то, чем занимается компания на домены. Выделяется три домена Core, Generic и Supporting. И это открывает глаза, когда пробуешь определить, где в компаниях какой домен и в каком домене работаешь сам (оказалось, что я в supporting домене). Супер понравился такой способ классификации. В зависимости от него еще софт пишется по-разному, а где-то лучше вообще не писать, а купить или взять готовое решение (в Generic домене)
2. Наконец-то прочитал определения паттернов Aggregates, Entities, Value Object и т.д. Я в целом их и так знал, но в каждой книге то, что уже знаешь открывается по-новому. Еще это добавило понимания некоторых элементов чистой архитектуры - тот же слой Entities образован от названия паттерна.
3. Глава про архитектуру Layered и Hexagonal заставила наконец-то разобраться с кашей терминов, которые используются для названия слоев итд. Теперь у меня есть отличное понимание, где какой и какой как называется.
4. Ну и конечно наполнил свой obsidian конспектом и иногда просто короткими заметками, чтобы определенные темы мог найти поиском и разобраться в теме более подробно используя такие заметки из разных книг
Vlad Khononov - Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy
01.07.2023 - 23.07.2023
Хотя по факту я читал ее дольше т.к. начинал и на середине остановился из-за того, что понял, что надо читать делая заметки, а читал тогда еще с телефона.
Книга хорошая. Отличный рейтинг на амазоне, считаю, что ее хорошо читать, как первую книгу в DDD.
Вообще в DDD есть 2 главные книги, это:
1. Синяя Eric Evans - Domain-Driven Design - классика DDD
2. Красная Vaughn Vernon - Implementing domain-driven design
Когда я разбирался, что читать, то видел совет начинать с красной т.к. она более прикладная, а не чистая теория, как в синей. Совершенно бесполезный совет. Красная книга читается плохо, дак еще и использует термины, определения которых нет в книге (конечно нет, они в синей находятся). Синюю я тоже читать не хотел т.к. и рейтинг тоже не самый высокий и еще большая. И я наткнулся на текущую книгу с огромным рейтингом и отличными отзывами. Ее и начал, а синюю запланировал на потом.
Самое полезное, что узнал:
1. Как можно делить то, чем занимается компания на домены. Выделяется три домена Core, Generic и Supporting. И это открывает глаза, когда пробуешь определить, где в компаниях какой домен и в каком домене работаешь сам (оказалось, что я в supporting домене). Супер понравился такой способ классификации. В зависимости от него еще софт пишется по-разному, а где-то лучше вообще не писать, а купить или взять готовое решение (в Generic домене)
2. Наконец-то прочитал определения паттернов Aggregates, Entities, Value Object и т.д. Я в целом их и так знал, но в каждой книге то, что уже знаешь открывается по-новому. Еще это добавило понимания некоторых элементов чистой архитектуры - тот же слой Entities образован от названия паттерна.
3. Глава про архитектуру Layered и Hexagonal заставила наконец-то разобраться с кашей терминов, которые используются для названия слоев итд. Теперь у меня есть отличное понимание, где какой и какой как называется.
4. Ну и конечно наполнил свой obsidian конспектом и иногда просто короткими заметками, чтобы определенные темы мог найти поиском и разобраться в теме более подробно используя такие заметки из разных книг
🔥4
В прошлом, когда облигации были на бумаге, каждый купон был отрывным листком, который содержал информацию о купонной выплате (обычно в процентном соотношении к номинальной стоимости) и дате, когда эта выплата должна была быть произведена. Купонные выплаты обычно осуществлялись периодически, например, каждые шесть месяцев.
Владелец облигации мог отрывать каждый купон и обналичивать его в банке или другом финансовом учреждении для получения процентной выплаты. Таким образом, термин "купон" возник из практики отрывать эти листки от облигации, как купоны, чтобы получить доход от инвестиции.
Владелец облигации мог отрывать каждый купон и обналичивать его в банке или другом финансовом учреждении для получения процентной выплаты. Таким образом, термин "купон" возник из практики отрывать эти листки от облигации, как купоны, чтобы получить доход от инвестиции.
👍5